未加星标

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

字体大小 | |
[大数据资讯 所属分类 大数据资讯 | 发布者 店小二03 | 时间 2018 | 作者 红领巾 ] 0人收藏点击收藏

本文主要介绍饿了么大数据团队如何通过对计算引擎入口的统一,降低用户接入门槛;如何让用户自助分析任务异常及失败原因,以及如何从集群产生的任务数据本身监控集群计算/存储资源消耗,监控集群状况,监控异常任务等。

饿了么 BDI-大数据平台研发团队目前共有 20 人左右,主要负责离线&实时 Infra 和平台工具开发。

其中 6 人的离线团队需要维护大数据集群规模如下:

hadoop 集群规模 1300+

HDFS 存量数据 40+PB,Read 3.5 PB+/天,Write 500TB+/天

14W MR Job/天,10W Spark Job/天,25W Presto/天

此外还需要维护 Hadoop、Spark、Hive、Presto 等饿了么内部版本组件,解决公司 400+ 大数据集群用户每天面临的各种问题。

引擎入口统一

目前在饿了么对外提供的查询引擎主要有 Presto、Hive 和 Spark,其中 Spark 又有 Spark Thrift Server 和 Spark SQL 两种模式。

并且 Kylin 也在稳步试用中,Druid 也正在调研中。各种计算引擎都有自身的优缺点,适用的计算场景各不相同。

从用户角度来说,普通用户对此没有较强的辨识能力,学习成本会比较高。

并且当用户可以自主选择引擎执行任务时,会优先选择所谓的最快引擎,而这势必会造成引擎阻塞,或者将完全不适合的任务提交到某引擎,从而降低任务成功率。

从管理角度来说,大数据集群的入口太多,将难以实现统一管理,难以实现负载均衡、权限控制,难以掌控集群整体对外服务能力。

并且当有新的计算需求需要接入,我们还需要为其部署对应的客户端环境。

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

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

用户使用多种计算引擎

功能模块

针对这种情况,饿了么大数据团队开发了 Dispatcher,该组件的主要功能如下图所示:

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

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

Dispatcher 功能模块

用户所有任务全部通过 Dispatcher 提交,在 Dispatcher 中我们可以做到统一的鉴权,统一的任务执行情况跟踪。

还可以做到执行引擎的自动路由,各执行引擎负载控制,以及通过引擎降级提高任务运行成功率。

逻辑架构

Dispatcher 的逻辑架构如下图所示:

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

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

Dispatcher 系统逻辑架构

目前用户可以通过 JDBC 模式调用 Dispatcher 服务,或者直接以 Driver 模式运行 Dispatcher。

Dispatcher 接收到查询请求后,将会统一进行鉴权、引擎路由等操作,将查询提交到对应引擎。

另外,Dispatcher 还有 SQL 转换模块,当发生从 Presto 引擎降级到 Spark/Hive 引擎时,将会通过该模块自动将 Presto SQL 转换成 HiveQL。

通过 Dispatcher 对查询入口的统一,带来的好处如下:

用户接入门槛低,无需再去学习各引擎使用方法和优缺点,无需手动选择执行引擎。

部署成本低,客户端可通过 JDBC 方式快速接入。

统一的鉴权和监控。

降级模块提高任务成功率。

各引擎负载均衡。

引擎可扩展。

引擎可扩展主要是指当后续接入 Kylin、Druid 或者其他更多查询引擎时,可以做到用户无感知。

由于收集到了提交到集群的所有查询,针对每一个已有查询计划,我们可以获得热度数据,知道在全部查询中哪些表被使用次数最多,哪些表经常被关联查询,哪些字段经常被聚合查询等。

当后续接入 Kylin 时,可以通过这些数据快速建立或优化 Cube。

SQL 画像

在 Dispatcher 中最核心的是 SQL 画像模块,基本流程如下图:

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

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

SQL 路由模块

查询提交后,通过连接 HiveServer 对查询计划进行解析,可以获取当前查询的所有元数据信息,比如:

读入数据量

读入表/分区数

各类 Join 次数

关联字段多少

聚合复杂度

过滤条件

……

上述元数据信息基本上可以对每一个查询进行精准的描述,每一个查询可以通过这些维度的统计信息调度到不同引擎中。

Hive 对 SQL 进行解析并进行逻辑执行计划优化后,将会得到优化后的 Operator Tree,通过 explain 命令可以查看。

SQL 画像数据可以从这个结果收集各种不同类型的 Operator 操作,如下图所示:

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

SQL 解析示例

从直观的理解上我们知道,读入数据量对于引擎的选择是很重要的。比如当读入少量数据时,Presto 执行性能最好,读入大量数据时 Hive 最稳定,而当读入中等数据量时,可以由 Spark 来执行。

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

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

各类计算引擎数据量-执行时间分布

在初始阶段,还可以通过读入数据量,结合 Join 复杂度,聚合复杂度等因素在各种计算引擎上进行测试,采用基于规则的办法进行路由。

执行过程中记录好每一次查询的 SQL 画像数据,执行引擎,降级链路等数据。

基于这些画像数据,后续可以采用比如决策树,Logistic 回归,SVM 等分类算法实现引擎的智能路由,目前饿了么大数据团队已经开始了这方面的尝试。

在饿了么的应用中,由 Dispatcher 统一调度的 Ad Hoc 查询,由于增加了预检查环节,以及失败降级环节,每天总体成功率为 99.95% 以上,整体 PT90 值为 300 秒左右。

目前 Presto 承担了 Ad Hoc 查询的 50% 流量,SparkServer 模式承担了 40% 流量。

充分利用集群本身数据

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

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

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

Grace 使用场景

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

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

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

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

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

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

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

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

监控队列

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

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

各队列任务情况

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

队列资源使用趋势

任务监控

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

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

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

指定队列任务情况

监控主机失败率

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

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

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

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

主机失败率监控

任务性能分析

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

6个人如何维护上千规模的大数据集群?
tags: 引擎,Dispatcher,集群,数据,查询,用户,Spark,SQL,监控,BU,Presto,资源,执行,运行
分页:12
转载请注明
本文标题:6个人如何维护上千规模的大数据集群?
本站链接:https://www.codesec.net/view/577345.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 大数据资讯 | 评论(0) | 阅读(2362)