网易基于历史查询的 Impala 集群性能优化实践
用券网信息：导读：本文将介绍基于历史查询的 Impala 集群性能优化与实践。
今天的介绍会围绕以下几点展开：
[*]配景 介绍
[*]高性能数仓建设
[*]HBO 实现计划
[*]HBO 优化实践
[*]未来成长 计划
<hr>分享嘉宾｜温正湖 网易数帆 数仓技术负责人
编辑整理｜谢小甲
出品平台｜DataFunTalk
<hr>01
配景 介绍
1. 网易数帆
网易数帆是网易旗下数字化转型技术与办事 提供商，主要由网易轻舟、网易有数、网易易智和网易易测四部分组成。
2. 网易数帆中的网易有数
网易有数目前支撑了公司内部绝年夜 部分互联网业务，包含 音乐、严选、有道、邮箱、传媒等。我们也有很多外部商业化的客户，涵盖了金融、零售、农业、能源、物流等行业领域中的企业。
3．网易有数中 Impala 的定位和应用场景
网易有数年夜 数据平台的基础设施中包含了主流的计算和查询系统，如下图所示。在这之中，Impala 主要是聚焦于交互式计算，主要应用场景包含 有数 BI、自助取数和交互式查询等。
[*]有数报表：BI 工程师可以通过敏捷 BI 进行数据剖析
[*]自助取数：无需写 SQL，采取 拖拽式自助取数
[*]交互式查询：可以通过 SQL 进行灵活的数据剖析
--
02
高性能数仓建设
1. 为何要进行高性能数仓建设
网易年夜 数据团队是国内最早一批将 Impala 作为剖析 型数仓查询引擎的团队，在历久 的使用实践中，积累了丰富的集群运维、问题排查、特性增强和性能优化经验。在这个进程 中，我们发明 仅使用社区的 Impala 版本是不敷 的，如果没有进一步的增强和优化，会对业务造成不合水平 的影响，主要涉及查询的性能和胜利 率，我们将业务痛点归类如下：
[*]痛点一：混合型业务负载挑战
一个 Impala 集群可能办事 整个年夜 业务，比如网易云音乐拥有很多个部分 ，每一个部分 会使用 Impala 做不合的事情，比如查询报表或进行 Ad-Hoc 查询或进行数据剖析 亦或仅仅是获取数据。这些不合类型的查询，在同一个 Impala 集群上可能会互相产生影响，比如资源竞争等。会导致部分业务的 SLA 无法保障。
[*]痛点二：庞杂 /聚合查询性能差
对于报表等 BI 类应用，其性能要求相比离线的任务会高很多，用户的耐受水平 通常为秒级，一般要求 5 秒以内。但 BI 类应用的有些图表查询的数据量可能较年夜 、数据连接和聚合等操作计算量较多，如此一来，定会比一般的查询性能更差一些。比如图表查询时间需要 10 秒以上，甚至数十秒，用户显然是弗成 接受的。
[*]痛点三：统计信息缺失导致慢查询
收集统计信息在数据库领域属于一个比较年夜 的技术难点。统计信息涉及到资源预估，以及执行计划的优化等。在 Hadoop 生态中的各查询引擎均没有较好解决统计信息的问题。很多查询引擎未提供统计信息的自动计算能力，就算提供了，统计信息的粒度也不敷 细。这会导致计算资源预估禁绝 确，执行计划不敷 合理，比如年夜 表作为build表或年夜 表走broadcast而不是shuffle等，这都邑 引起查询性能变差。
[*]痛点四：元数据缓存和更新问题
Impala 提供了元数据缓存，通过在集群内部缓存表、列和文件级别元数据来提升查询性能，但同时也带来了一些问题。因为离线数据产出往往通过 Hive 或 Spark，Impala 无法感知到表元数据的变更 ，进而无法及时更新元数据缓存，导致查询时因使用旧的元数据而报错。
[*]痛点五：存储层波动影响查询性能
Impala 是存算分别 的设计架构，典范 的使用场景是表元数据在 HMS 中，数据在远端的 HDFS 集群中。若不考虑 Impala 数据和元数据缓存，Impala 查询时，需要跨网络拜访HMS 和 HDFS 集群，容易因为网络、HMS、HDFS NN 或 DN 性能波动导致查询性能变差。如何消除这些波动降低对用户的影响就是一个很值得研究的问题。
[*]痛点六：集群状态周期性腐化
时不时会有业务同学会问为什么这个查询性能越来越差了啊？我什么都没做。其实导致集群状态变差的原因很多，那怕都是执行相同的查询 SQL，但因为随着时间的变更 ，需要扫描和计算的数据量变多，也可能导致集群性能变差，比如计算资源竞争越来越严重、IO 波动变频繁等。当然，更普遍的情况是由于没有控制新业务/场景的接入，导致集群承接的查询越来越多，集群不堪重负。这需要我们及时识别集群状态恶化，找出问题的原因并尽早优化，以免影响 SLA。
2. 高性能数仓——建设原则
当然，上面所述的多种类型的问题，除了元数据缓存相关外，其他的都是普遍性问题，使用同类型的数仓查询引擎也可能会遇到。为了有效解决包含Impala 在内的年夜 部分 Hadoop 查询引擎都存在的这些问题，我们提出基于 Impala 建设高性能数仓。下面先简单说明高性能数仓的建设原则，再介绍上述问题的解决计划 。
建设高性能数仓，最重要的就是要连续 增强 Impala 的核心能力，其次是要充分利用历史查询信息。
在组件之间，可以进行上下游组件的垂直优化，例如：有数 BI 等组件通过 SQL 注解，反哺 Impala 进行更智能的查询剖析 。
此外，充分利用网易有数全链路年夜 数据平台的优势，也是建设高性能数仓的另一个重要原则。
3. 高性能数仓——业务痛点解决计划
混合型业务负载上，我们引入了虚拟数仓，对业务进行物理资源隔离。实质 上虚拟数仓依旧在一个 Impala 集群上面，不合点在于是对物理资源进行了隔离。但在这种隔离条件下，会引起资源利用率变低的问题，这也是需要进行优化的。
在统计信息缺失导致慢查询的问题上，我们提供了统计信息自动计算的能力。即便拥有统计信息，它的预估依然会存在较年夜 可能禁绝 的问题，所以我们进一步基于历史查询做查询 SQL 的归一化模版，用历史查询的实际内存消耗来提升查询的内部预估精度。
存储性能上，Impala 自己 自带有本地缓存的能力，针对该内容， 我们做了进一步的增强。
庞杂 、聚合查询能力差，解决方法 无非通过提升计算能力，在资源有限的情况下，尽量压榨计算性能。比如早期使用的 Ambari 集群安排 ，一个机器只能安排 一个 Impalad，该机器的 CPU、内存资源无法充分利用，我们希望用户端可以安排 多个节点。在高版本上，我们希望可以依托 Impala 多线程（MT_DOP）的能力，通过提升计算资源利用率来进一步提升查询效率。
--
03
HBO 实现计划
1. HBO 信息来源——Impala 治理 办事 器
HBO 即基于历史查询的优化。
在使用 Impala 的进程 中，为了解决无法查看和审计集群中的查询等问题，我们引入了 Impala 治理 办事 器——Manager 组件。该组件的主要功能，是持久化保存Impala查过的那些 SQL，也会存储这些 SQL 的 Profile 信息，目前我们是将其保存在 MySQL 中。同时，对保存下来的信息，进行解析，实现结构化保存。
其实现原理如下：开启后，Coordinators 会向 Statestore 注册查询信息，例如在Statestore 上会有一个新的 Topic，这个 Topic 里面会保存那些 Coordinators 有哪些查询记录，Manager 会从 Statestore 获取查询信息，包含Hostname 以及 Query_ID，依据Hostname 向对应的 Coordinator 发送 Http 请求指定 Query_ID 的查询信息并保存到 MySQL 中。
2. 历史查询信息解析
如图中所示，治理 办事 器提供了基础的查询信息，包含 排队耗时、内存预估和实际消耗、扫描的数据量等。
此外，还保存了 Profile、Timeline 和 Summary 信息。这样，就可以排查存在性能问题的历史查询。
如左图，我们通过解析 Profile 文件，我们可以看查询的执行计划，剖析 是否可以进行优化，右图中具体展示了 Scan Node 的详细执行信息，比如下游节点期待 数据时间、扫描节点打开 HDFS 文件所耗时间等。
在 Timeline 中可以了解到查询时间消耗，如左上图的时间消耗主要是加载元数据信息，其中 "loaded-tables=1/1" 表示查询里涉及 1 个表，本次加载了 1 个表；“load-requests=28”表示总共向 Catalogd 发送了 28 次 PrioritizeLoad 类型的元数据请求；"catalog-updates=549" 表示总共等了 549 轮的 Catalog 广播更新；“storage-load-time=510879ms”表示加载文件元数据花了 510879ms。整个元数据加载的期待 时间是 9m15s。
又如上图的右下子图，查询的时间消耗主要是排队期待 上。
Impala 查询的 Summary 总结了查询各个 Fragment 和 Node 的耗时等状况，包含 并发执行的节点数、平均耗时和最年夜 耗时、预估和实际处理行数、预估和实际使用内存等。
另外我们会进行 SQL 注解，以及结构化保存。通过注解的方法 记录了相当多的信息内容。其中包含 物化视图命中状态、报表状态，以及命中物化视图对应的表的改写价值 等等。
3. 挖掘历史查询纪律
如上图，透过 SQL 注解以及其他历史查询信息，我们可以得知集群状态，了解到具体的任务排队情况，预测内存使用情况。
通过历史查询信息，我们还可以得知查询次数以及查询性能随时间变更 的一个纪律 ，得知集群忙碌 状态。
通过在成千上万的 SQL 查询中，剖析 各类不合 SQL 中的差别 ，归纳总结出 SQL 模版，用以提升 Impala 查询的内存预估效率，并为其他决策提供支持。同时，在如此多的查询信息中，很容易得知热点表/分区的信息。
4. HBO 优化实践
Impala 有较为完善的本地缓存体系，包含 元数据缓存和 HDFS 文件缓存。但也因为有缓存，所以导致了一些缓存过旧问题，因此涌现 查询时的元数据毛病 。数据缓存也同样存在问题，包含 重启失效，不命中价值 较高等。
基于如上的一些问题，我们针对本地缓存体系进行了优化。
在元数据缓存模块，所做优化包含 过滤无效表、归并 同类 DDL、裸露 同步进程和通过SQL 注解手动指定查询涉及的表信息，以及通过动态白名单驱动表元数据异步加载。
在 DataCache 增强计划 上，对于 Parquet 等文件格局 ，支持自力 配置 Footer Cache，因为 HDFS 在读文件时先会读取 Parquet 文件的 Footer Block，之后解析这个 Block 的信息，才可以进一步做过滤等其他操作，再真正去读数据。我们会优先将 Footer 块缓存，另外解决了 Cache Fill 性能退化问题。
我们还解决了 DataCache 持久化问题，以包管 重新启动后依旧留存有之前的缓存数据信息。避免了 Impala 进程重启缓存丧失 的情况。
5. 基于 HBO 的多表物化视图
物化视图目前主要用于 BI 报表场景，由于 SQL 是批量下发的，若部分 SQL 执行时间长，将会对集群造成不小的压力。BI 报表对实时性能要求较高，其查询纪律 性强、重复率高、T+1 类型较多，适合用物化视图进行加速。
物化视图的实现计划 ，目前主要包含 两方面，其一是生命周期的治理 ，这部分是我们纯自研，以自力 办事 形式安排 ，元数据存储在 MySQL。通过数据产出消息、DDL 变革 日志和文件驱动物化视图表数据更新；其二是 SQL 透明改写，该部分内容目前是以 Calcite 物化视图为基础，进行二次开发增强。因为在调研的进程 中，我们发明Calcite 提供了一个较好的框架，提供了 SQL 自动改写的能力，该能力支持多表 Join。
下面稍微展开讲下 Impala 物化视图自动改写能力。它基于一篇 SQL Server 的SIGMOD 论文来实现。从实现的角度来讲：Impala SQL 会先转酿成Calcite AST 语法树，再到 Rewrite 阶段进行重写，之后又转回为 Impala SQL，再由 Impala 继续处理。在集成方面，我们通过一个 Jar包，放入 Coordinator 的 EF 端来实现。在此处更类似一个插件，对于以后版本的升级迭代都加倍 便利 。
由于 Calcite 开源组件自己 还存在不少的缺陷，包含SQL 匹配以及改写效率上的问题，在生产环境中，我们对此进行了进一步的优化，包含 添加了 Outer Join、Group By、Limit 等算子和各类UDF 的支持。
HBO 在物化视图的使用主要是通过剖析 有数 BI 报表的历史查询记录，确认要获取优化的对象并创建物化视图。
物化视图的创建，又以不合的颗粒区分，比如：慢图表、慢申报 、慢模型。创建物化视图一定要考虑投入产出比，如何用最小的资源消耗获取最年夜 的产出，是很重要的问题。
对于一个创建好的物化视图，如何评估这个物化视图的效果？我们通过 Coordinator层面提供了一些 Metrics，它会记录每个物化视图的命中情况，命中之后改写性能消耗，还有物化视图表自身有若干 的数据量、占用了若干 空间等信息。
通过BI产品的报表数据医生也可以看到 HBO 优化的效果。
6. 基于 HBO 的内存预估优化
Impala 会为查询预分派 内存，因此，预分派 的内存决定了集群内存的使用效率，若是预估值过年夜 ，Impala 会一直占用这部分资源到 SQL 查询结束，这会平白浪费不少资源。对于这部分，我们目前通过 SQL 模板进行优化，从结果上看，我们尽可能地更正了预估的数值，提高了资源利用率。
7. 虚拟数仓与资源动态调配
所谓虚拟数仓就是一个集群中，分了多个组，每个组完成不合的业务，从而进行有效的负载隔离。它拥有两种方法 ，第一：基于zk的命名空间，Impala 上不合的 Coordinator 注册到不合的 ZK 地址，通过不合zk地址拿到不合 Coordinator 的连接，就会达到 不合的虚拟数仓上。
另外一种为同一个 ZK 地址，所有查询都邑 达到 同一组 Coordinator，可以通过 Set Request Group 的方法 来将你的查询路由到某个虚拟分组中去，这种方法 类似 Snowflake。
虚拟数仓涉及到资源的高效使用和负载均衡，我们的解决方法 是混合型虚拟数仓，也就是节点可以在不合的虚拟数仓中，又可以分为两种，一是 Executor 在不合虚拟数仓中，另一种是 Coordinator 注册到 Zookeeper 不合的 Znode 上。
--
04
未来成长 计划
1. Impala 4.1 版本
[*]已完成自研特性归并
[*]添加 Hive 2.x 版本支持
[*]推进上线中
2. 物化视图
[*]支持更多 SQL 语法和算子
[*]提升物化视图创建的自动化水平
[*]与有数 BI 产品进一步融合
3. Impala 内核优化
[*]进一步提升 HBO 内存估算能力
[*]支持更多场景的查询透明重试
[*]支持向量化执行模式
4. 集群治理 和运维
[*]支持通过 K8S 进行 Impala 集群安排
[*]资源动态调剂 和负载均衡
[*]集群健康状态诊断系统
今天的内容就到这里，谢谢年夜 家。
<hr>｜分享嘉宾｜
温正湖
网易数帆 数仓技术负责人
2010年浙年夜 硕士卒业 ，10+年数据库和存储开发经验。2013年入职网易数据库团队，一直从事关系型数据库和剖析 型数仓相关工作，专注于数据库领域技术立异 、研发和应用。
<hr>｜DataFun新媒体矩阵｜
<hr>｜关于DataFun｜
专注于年夜 数据、人工智能技术应用的分享与交流。提议 于2017年，在北京、上海、深圳、杭州等城市举办跨越 100+线下和100+线上沙龙、论坛及峰会，已邀请跨越 2000位专家和学者介入 分享。其"大众号 DataFunTalk 累计生产原创文章800+，百万+阅读，15万+精准粉丝。
页:
[1]