SQL on Hadoop在快手大数据平台的实践与优化

为了保证核心任务的稳定性，将ETL集群进行了分级，分为核心集群和一般集群。在客户端连接HS2的时候，我们会对任务优先级判定，高优先级的任务会被路由到核心集群，低优先级的任务会被路由到一般集群。

HiveServer2服务内部流程图

BeaconServer服务

BeaconServer服务为后端Hook Server服务，配合HS2中的Hook，在HS2服务之外实现了所需的功能。当前支持的模块包括路由、审计、SQL重写、任务控制、错误分析、优化建议等。

• 无状态，BeaconServer服务支持水平扩展。基于请求量的大小，可弹性调整服务的规模。



• 配置动态加载，BeaconServer服务支持动态配置加载。各个模块支持开关，服务可动态加载配置实现上下线。比如路由模块，可根据后端加速引擎集群资源情况 ，进行路由比率调整甚至熔断。



• 无缝升级，BeaconServer服务的后端模块可单独进行下线升级操作，不会影响Hook端HS2服务。




SQL on Hadoop平台在使用中遇到的痛点

使用新引擎进行加速面临的问题

• Hive支持SPARK与TEZ引擎，但不适用于生产环境。
• SQL on Hadoop的SQL引擎各有优缺点，用户学习和使用的门槛较高。
• 不同SQL引擎之间的语法和功能支持上存在差异，需要大量的测试和兼容工作，完全兼容的成本较高。
• 不同SQL引擎各自提供服务会给数仓的血缘管理、权限控制、运维管理、资源利用都带来不便。




智能引擎的解决方案

• 在Hive中，自定义实现引擎。
• 自动路由功能，不需要设置引擎，自动选择适合的加速引擎。

• 根绝规则匹配SQL，只将兼容的SQL推给加速引擎。

• 复用HiveServer2集群架构。

智能引擎：主流引擎方案对比

智能引擎：HiveServer2自定义执行引擎的模块设计

基于HiveServer2，有两种实现方式。JDBC方式是通过JDBC接口，将SQL发送至后端加速引擎启动的集群上。PROXY方式是将SQL下推给本地的加速引擎启动的Client。

JDBC方式启动的后端集群，均是基于YARN，可以实现资源的分时复用。比如AdHoc集群的资源在夜间会自动回收，作为报表系统的资源进行复用。

智能引擎：SQL路由方案设计架构

路由方案基于HS2的Hook架构，在HS2端实现对应 Hook，用于引擎切换;后端BeaconServer服务中实现路由 服务，用于SQL的路由规则的匹配处理。不同集群可配置不同的路由规则。

为了保证后算路由服务的稳定性，团队还设计了Rewrite Hook，用于重写AdHoc集群中的SQL，自动添加LIMIT上限，防止大数据量的SCAN。

智能引擎：SQL路由规则一览

智能引擎：方案优势

• 易于集成，当前主流的SQL引擎都可以方便的实现JDBC与PROXY方式。再通过配置，能简单的集成新的查询引擎，比如impala、drill等。


• 自动选择引擎，减少了用户的引擎使用成本，同时也让迁移变得更简单。并且在加速引擎过载 的情况下，可以动态调整比例，防止因过载 对加速性能的影响。


• 自动降级，保证了运行的可靠性。SQL路由支持failback模块，可以根据配置选择是否再路由引擎执行失败后，回滚到 MR运行。


• 模块复用，对于新增的引擎，都可以复用HiveServer2定制的血缘采集、权限认证、并发锁控制等方案，大大降低了使用成本。


• 资源复用，对于adhoc查询占用资源可以分时动态调整，有效保证集群资源的利用率。




智能引擎DQL应用效果

HiveServer2中存在的性能问题

FetchTask加速：预排序与逻辑优化

（编辑：晋中站长网）

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