加入收藏 | 设为首页 | 会员中心 | 我要投稿 惠州站长网 (https://www.0752zz.com.cn/)- 办公协同、云通信、物联设备、操作系统、高性能计算!
当前位置: 首页 > 教程 > 正文

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

发布时间:2018-07-10 15:52:03 所属栏目:教程 来源:陈**明
导读:副标题#e# 【资讯】本文主要介绍饿了么大数据团队如何通过对计算引擎入口的统一,降低用户接入门槛;如何让用户自助分析任务异常及失败原因,以及如何从集群产生的任务数据本身监控集群计算/存储资源消耗,监控集群状况,监控异常任务等。 饿了么 BDI-大数据

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

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

  主机失败率监控

  任务性能分析

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

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

  任务性能分析

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

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

  任务自助优化方案

  任务失败原因分析

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

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

  失败原因自助分析

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

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

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

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

  Grace 架构

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

  逻辑架构如下图:

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

  Grace 逻辑架构

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

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

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

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

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

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

  总结

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

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

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

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

  作者:陈**明

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

(编辑:惠州站长网)

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

推荐文章
    热点阅读