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 任务解析逻辑,增加新的启发式算法和新的监控指标等。 总结 随着大数据生态体系越来越完善,越来越多背景不同的用户都将加入该生态圈,我们如何降低用户的进入门槛,方便用户快速便捷地使用大数据资源,也是需要考虑的问题。 大数据集群中运行的绝大部分任务都是业务相关,但是随着集群规模越来越大,任务规模越来越大,集群本身产生的数据也是不容忽视的。 这部分数据才是真正反映集群使用详细情况的,我们需要考虑如何收集使用这部分数据,从数据角度来衡量、观察我们的集群和任务。 仅仅关注于集群整体部署、性能、稳定等方面是不够的,如何提高用户体验,充分挖掘集群本身数据,用数据促进大数据集群的建设,是本次分享的主题。 作者:陈**明 简介:具有多年从事大数据基础架构工作经验。目前担任饿了么数据平台研发团队资深数据工程师,主要负责饿了么离线平台及底层工具开发。 (编辑:惠州站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |