近期的一些工作思考

[cjuexuan]

很久没有写东西了，先介绍下最近的工作变化吧，大概是今年7月份的时候，我从计算平台组转岗到了集群架构组，现在在负责大数据集群架构这一块的工作。实话说，从一个熟悉的领域切换到相对远离很久的领域，对我来说也是一次非常大的挑战，到目前为止，主观感觉是勉强跟上了节奏，未来可以做的事情仍然非常的多。 我们组主要负责大数据基础环境的稳定性，容量规划和存储治理、大数据监控告警的建设等，比如hdfs的数据清理、机器的扩容规划、yarn的资源分配等，顺便打个广告，目前还有部分hc，欢迎有兴趣的小伙伴和我联系。从我的角度去看，我们集群架构的工作目前还不够聚焦和高效，这也是我未来的一段时间需要努力改进的地方。 接下来我想要说的是大数据集群架构最近的一些思考

• 降低存储成本：
  • 目前我们将hdfs集群已经升级到Hadoop3，但是纠删码基本没用起来，这一块是未来节省成本很重要的一个增长点
  • 我们今年尝试了做混合云存储，来解决机房扩容的问题，具体来说，按照hive表的访问场景，将n天前的冷数据周期性同步到云对象存储上，并且可以选择云上的低频或者归档存储，由于大的云厂商的对象存储基本都实现了FileSystem的接口，这一块完全可以做到透明对业务无感知，在有一定商务折扣的情况下，云存储的成本可以拉到低于机房3副本存储的水平，总体还是比较划算的
  • 利用之前的小文件、冷数据分析等产品，进一步识别冷数据，再进一步挖掘任务血缘，清晰的标识每个数据的产生代价和是否可以重跑恢复等，精细化对存储进行生命周期管理
• 提高稳定性：
  • 稳定性是一个对于架构来说没有穷尽的问题，今年做SLA任务链路传递等功能，但是现阶段还是以报警为主，因为本身集群不具备更多的资源储备，所以在出现延迟的时候很难有资源来额外保障这些任务，但是今年Q3也和云厂商尝试了混合云的计算架构，具体来说我们会在云厂商那边托管一个最低保障的EMR集群，云上计算集群和自建IDC之间通过专线联通，未来我们将在应急和基于每天的计算潮汐现象使用这部分弹性的计算资源，来解决我们计算集群扩容的问题，结合上面的冷数据上云，我们未来的架构是IDC中有常规的计算资源和热的数据，云上有分时、应急使用的EMR和冷数据
  • 对于一个组件，我们通常会收集很多的metrics，硬件层面的的、软件层面的，这么多眼花缭乱的指标可能在某些具体的场景是游有用的，但是对稳定性和告警来说，我们还是需要精简和构建最能反应问题的北极星指标，这一块我希望自己能在未来的一年内通过更多的思考将指标细分，对于重点指标加强监控告警，对于一般指标只做看板展示，不去做太多告警，告警的精简也是为了让我们更能抓住问题
• 减少人的投入：
  • 现阶段大数据集群维护很多场景下还是手动挡，吃专家知识，但是这不是终局，我理解的终局一定是需要系统去承接和沉淀更多的场景化的经验，我们可以找到的一个衡量的点是人在事情中投入的比重
  • 如果让工程师持续做那些枯燥而又重复的事情，本身就是对劳动力的亵渎，我们要通过技术手段去努力降低人在系统运维中做枯燥事情的比例 从当前大环境来看，目前云厂商已经非常成熟了，如何用好云服务来降低人力、机器成本，也是我们需要长期考虑的一个方向，这一块有兴趣的小伙伴也可以一起聊一聊