饿了么大数据离线计算引擎实践

背景

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

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

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

1、功能模块

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

 

 

 

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

2、逻辑架构

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