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

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

　　饿了么 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 也正在调研中。各种计算引擎都有自身的优缺点，适用的计算场景各不相同。

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

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

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

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

　　用户使用多种计算引擎

　　功能模块

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

　　Dispatcher 功能模块

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

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

　　逻辑架构

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

　　Dispatcher 系统逻辑架构

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

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

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

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

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

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

　　统一的鉴权和监控。

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

　　各引擎负载均衡。

　　引擎可扩展。

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

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

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

　　SQL 画像

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

　　SQL 路由模块

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

　　读入数据量

　　读入表/分区数

　　各类 Join 次数

　　关联字段多少

　　聚合复杂度

　　过滤条件

　　……

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

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

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

　　SQL 解析示例

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

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

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

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

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

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

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

　　充分利用集群本身数据

（编辑：核心网）

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