6个人如何维护上千规模的大数据集群呢？

　　运行中的任务是最灵敏的反应，一旦检测到某主机失败率过高，可触发快速自动下线保障业务正常执行。后续可以结合硬件监控定位主机异常原因。

　　主机失败率监控

　　任务性能分析

　　用户可自助进行任务性能分析，如下图：

　　任务性能分析

　　并且可以根据异常项按照以下建议自助调整，如下图：

　　任务自助优化方案

　　任务失败原因分析

　　对于失败的任务，用户也可以按照以下方法快速从调度系统查看失败原因，以及对应的解决办法，饿了么大数据团队会定期收集各种典型报错信息，更新维护自助分析知识库。

　　失败原因自助分析

　　除此之外，我们还可以实时监控每个任务的计算资源消耗 GB Hours，总的读入写出数据量，Shuffle 数据量等，以及运行中任务的 HDFS 读写数据量，HDFS 操作数等。

　　当出现集群计算资源不足时，可快速定位消耗计算资源多的任务。当监控出现 HDFS 集群抖动，读写超时等异常状况时，也可通过这些数据快速定位到异常任务。

　　基于这些数据还可以根据各队列任务量，任务运行资源消耗时间段分布，合理优化各队列资源分配比例。

　　根据这些任务运行状况数据建立任务画像，监控任务资源消耗趋势，定位任务是否异常。再结合任务产出数据的访问热度，还可以反馈给调度系统动态调整任务优先级等。

　　Grace 架构

　　上述示例中使用到的数据都是通过 Grace 收集的。Grace 是饿了么大数据团队开发的应用，主要用于监控分析线上 MR/Spark 任务运行数据，监控运行中队列及任务明细及汇总数据。

　　逻辑架构如下图：

　　Grace 逻辑架构

　　Grace 是通过 Spark Streaming 实现的，通过消费 Kafka 中存储的已完成 MR 任务的 jhist 文件或 Spark 任务的 eventlog 路径，从 HDFS 对应位置获取任务运行历史数据，解析后得到 MR/Spark 任务的明细数据。

　　再根据这些数据进行一定的聚合分析，得到任务级别，Job 级别，Stage 级别的汇总信息。

　　最后通过定制化的 Dr-Elephant 系统对任务明细数据通过启发式算法进行分析，从而给用户一些直观化的优化提示。

　　对于 Dr-Elephant，我们也做了定制化的变动，比如将其作为 Grace 体系的一个组件打包依赖。

　　从单机部署服务的模式变成了分布式实时解析模式。将其数据源切换为 Grace 解析到的任务明细数据。

　　增加每个任务的 ActionId 跟踪链路信息，优化 Spark 任务解析逻辑，增加新的启发式算法和新的监控指标等。

　　总结

　　随着大数据生态体系越来越完善，越来越多背景不同的用户都将加入该生态圈，我们如何降低用户的进入门槛，方便用户快速便捷地使用大数据资源，也是需要考虑的问题。

　　大数据集群中运行的绝大部分任务都是业务相关，但是随着集群规模越来越大，任务规模越来越大，集群本身产生的数据也是不容忽视的。

　　这部分数据才是真正反映集群使用详细情况的，我们需要考虑如何收集使用这部分数据，从数据角度来衡量、观察我们的集群和任务。

　　仅仅关注于集群整体部署、性能、稳定等方面是不够的，如何提高用户体验，充分挖掘集群本身数据，用数据促进大数据集群的建设，是本次分享的主题。

　　作者：陈**明

　　简介：具有多年从事大数据基础架构工作经验。目前担任饿了么数据平台研发团队资深数据工程师，主要负责饿了么离线平台及底层工具开发。

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!