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

　　饿了么大数据集群每天运行的 Spark&MR 任务 25W+，这些数据详细记录了每一个 Mapper/Reducer 或者 Spark 的 Task 的运行情况，如果能够充分利用，将会产生巨大的价值。即充分利用集群本身数据，数据驱动集群建设。

　　这些数据不仅可以有助于集群管理人员监控集群本身的计算资源、存储资源消耗，任务性能分析，主机运行状态。还可以帮助用户自助分析任务运行失败原因，任务运行性能分析等。

　　饿了么大数据团队开发的 Grace 项目就是在这方面的一个示例。

　　Grace 使用场景

　　你对集群任务运行状况详细数据没有明确认识的话，很容易当出现问题时陷入困境，从监控看到集群异常后将无法继续进一步快速定位问题。

　　当经常有用户找你说，我的任务为什么跑失败了?我的任务为什么跑的这么慢?我的任务能调一下优先级么?不要跟我说看日志，我看不懂。我想大家内心都是崩溃的。

　　当监控发出 NameNode 异常抖动，网络飚高，block 创建增加，block 创建延时增大等告警时，应该如何快速定位集群运行的异常任务?

　　当监控发出集群中 Pending 的任务太多时，用户反馈任务大面积延迟时，如何快速找到问题根本原因?

　　当用户申请计算资源时，到底应该给他们分配多少资源?当用户申请提高任务优先级时如何用数据说话，明确优先级到底应该调到多少?当用户只管上线不管下线任务时，我们如何定位哪些任务是不再需要的?

　　还有，如何通过实时展示各 BU 计算资源消耗，指定 BU 中各用户计算资源消耗，占 BU 资源比例。

　　以及如何从历史数据中分析各 BU 任务数，资源使用比例，BU 内部各用户的资源消耗，各任务的资源消耗等。

　　以下示例展示一些 Grace 产出数据图表，有关 BU、用户、任务级别的数据不方便展示。

　　监控队列

　　从下图可以方便的看到各队列最大最小资源，当前已用资源，当前运行任务数，Pending 任务数，以及资源使用比例等，还可以看到这些数据的历史趋势。

　　各队列任务情况

　　队列资源使用趋势

　　任务监控

　　可以查看指定队列中运行中任务的任务类型，开始时间，运行时长，消耗当前队列资源比例，以及消耗当前 BU 资源比例等。

　　可快速定位计算资源消耗多并且运行时间长的任务，快速找到队列阻塞原因。

　　指定队列任务情况

　　监控主机失败率

　　可以监控集群所有主机上的 Task 执行失败率。已有监控体系会对主机的 CPU，磁盘，内存，网络等硬件状况进行监控。

　　这些硬件故障最直观的表现就是分配在这些有问题的主机上的任务执行缓慢或者执行失败。

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

　　主机失败率监控

　　任务性能分析

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

　　任务性能分析

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

　　任务自助优化方案

　　任务失败原因分析

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

　　失败原因自助分析

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

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

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

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

　　Grace 架构

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

（编辑：核心网）

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