当前位置:主页 > 数据驱动 >

饿了么大数据计算引擎实践与应用

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

引擎入口统一

目前在饿了么对外提供的查询引擎主要有Presto、Hive和Spark,其中Spark又有SparkThrift Server和Spark SQL两种模式,并且Kylin也在稳步试用中,Druid也正在调研中。各种计算引擎都有自身的优缺点,适用的计算场景各不相同。

从管理角度来说,大数据集群的入口太多,将难以实现统一管理,难以实现负载均衡、权限控制,难以掌控集群整体对外服务能力。并且当有新的计算需求需要接入,我们还需要为其部署对应的客户端环境。

从用户角度来说,普通用户对此没有较强的辨识能力,学习成本会比较高。并且当用户可以自主选择引擎执行任务时,会优先选择所谓的最快引擎,而这势必会造成引擎阻塞,或者将完全不适合的任务提交到某引擎,从而降低任务成功率。

 

饿了么大数据计算引擎实践与应用

 

用户使用多种计算引擎

1功能模块

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

 

饿了么大数据计算引擎实践与应用

 

Dispatcher功能模块

用户所有任务全部通过Dispatcher提交,在Dispatcher中我们可以做到统一的鉴权,统一的任务执行情况跟踪。还可以做到执行引擎的自动路由,各执行引擎负载控制,以及通过引擎降级提高任务运行成功率。

2逻辑架构

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

 

饿了么大数据计算引擎实践与应用

 

Dispatcher系统逻辑架构

目前用户可以通过JDBC模式调用Dispatcher服务,或者直接以Driver模式运行Dispatcher。Dispatcher接收到查询请求后,将会统一进行鉴权、引擎路由等操作将查询提交到对应引擎。另外,Dispatcher还有SQL转换模块,当发生从Presto引擎降级到Spark/Hive引擎时,将会通过该模块自动将Presto SQL转换成HiveQL。

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

用户接入门槛低,无需再去学习各引擎使用方法和优缺点,无需手动选择执行引擎;
部署成本低,客户端可通过JDBC方式快速接入;
统一的鉴权和监控;
降级模块提高任务成功率;
各引擎负载均衡;
引擎可扩展。

引擎可扩展主要是指当后续接入Kylin、Druid或者其他更多查询引擎时,可以做到用户无感知。由于收集到了提交到集群的所有查询,针对每一个已有查询计划,我们可以获得热度数据,知道在全部查询中哪些表被使用次数最多,哪些表经常被关联查询,哪些字段经常被聚合查询等,当后续接入Kylin时,可以通过这些数据快速建立或优化Cube。

3SQL画像

在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%流量。

充分利用集群本身数据

饿了么大数据集群每天运行的Spark&MR任务25W+,这些数据详细记录了每一个Mapper/Reducer或者Spark的Task的运行情况,如果能够充分利用,将会产生巨大的价值。充分利用集群本身数据,数据驱动集群建设。这些数据不仅可以有助于集群管理人员监控集群本身的计算资源、存储资源消耗,任务性能分析,主机运行状态。还可以帮助用户自助分析任务运行失败原因,任务运行性能分析等。

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

1Grace使用场景

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

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

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

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

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

还有,如何通过实时展示各BU计算资源消耗,指定BU中各用户计算资源消耗,占BU资源比例。以及如何从历史数据中分析各BU任务数,资源使用比例,BU内部各用户的资源消耗,各任务的资源消耗等。

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

1)监控队列

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

文章评论

互联网 自媒体专栏 智能硬件 资本动态 移动互联网 游戏 数据驱动 滚动新闻 O2O 访问移动版
Copyright © 2002-2013 搞数码网 版权所有  电话:0510-898978789 邮箱:89898989@qq.com 地址:北京市新会金水岸国商大厦B-6-B