文章做者：温正湖 网易杭研数据库
编辑整理：张博后端
出品平台：DataFunTalk
缓存
导读：网易大数据平台的底层数据查询引擎，选用了Impala做为OLAP查询引擎，不但支撑了网易大数据的交互式查询与自助分析，还为外部客户提供了商业化的产品与服务。今天将为你们分享下Impala在网易大数据的优化和实践。性能优化
01服务器
Impala的定位及优点网络
Impala有哪些优点，让咱们选择Impala做为网易内部的OLAP查询引擎？架构
1. Impala在数据处理中的角色并发
先来看一下Impala在数据处理中的角色。运维
对于数据量较少的场景，例如百万数据如下的状况，能够采用传统的关系型数据库，如MySQL或者PostgreSQL等，或者一些文档数据库，好比MongoDB等。随着数据量的增大，达到上亿级别时，通常选择分析型数仓来存储，并使用OLAP引擎来查询。此等规模的数据查询，对响应时间的要求虽然比关系型数据库要低，但通常也要求在秒级返回查询结果，不能有太大的延迟。Impala、Presto、Greenplum等都在此列。当规模继续扩大到上百亿以上时，则会选择批处理引擎，如Hive、Spark来进行数据处理。性能
今天分享的Impala就是针对分析型数仓的查询引擎。分析型数仓有不少种建模方式。
以Druid和Click House为表明的宽表模型，还有以Impala等为表明的星型/雪花型的建模方式。咱们将Impala做为通用的查询引擎，比较典型的应用场景有自助数据分析、BI报表等。在分享的第三部分，有关于Impala在网易大数据平台“猛犸”中的介绍，以及在网易云音乐中的实际使用场景的说明。
2. Impala的优点
网易为何选择Impala做为OLAP查询引擎，Impala到底有哪些优点？Impala的优点，总结起来包括：
MPP 架构，去中心化
优秀的查询性能
友好的 WebUI 界面
彻底兼容 Hive 元数据
Apache 顶级项目，社区活跃度高
支持多种数据格式（ Parquet/ORC 等）
与 Kudu 结合使用，实时数仓
① 去中心化的MPP并行架构
相比于传统的关系型数据库，MPP架构能够充分发挥多服务器的特色，将数据量比较大的操做，分散在多台服务器上并行处理。这些复杂的大数据量的操做，对于单台服务器来讲是没法完成的任务。
Impala还区别于其余MPP架构的引擎的一点，是Impala有多个Coordinator和Executor，多个Coordinator能够同时对外提供服务。多Coordinator的架构设计让Impala能够有效防范单点故障的出现。
② 优秀的查询性能
Impala支持CBO（基于代价的执行优化），除此以外，Impala还对Catalog进行了缓存。缓存的信息包括：库和表的信息、HDFS数据库、统计信息等。元数据都缓存在了Impala内部，在作CBO时，可以发挥更大的优点，作出更优的选择。除此以外，Impala同时具备典型的OLAP引擎应有的特征：静态代码生成支持LLVM、JIT；支持HDFS本地读区，减小访问NameNode、DataNode和数据网络传输的开销，对性能有比较大的提高；还有算子下推，runtime filter在Join时，对与join条件以外的列能够进行动态过滤。
从咱们实际使用效果来讲，Impala性能优点很是明显。前段时间咱们对Impala、presto和spark3.0进行了对比测试。测试用例选择tpcds，并行节点8个。
总的来讲，Impala相比Presto有明显的优点，相比Spark 3.0也有必定的优点。Spark 3.0对性能作了不少优化和改进，相比之下Impala性能有一些优点，不过Impala由于支持的SQL类型少一些，有一些tpcds的测试用例并不能完成。
③ 友好的WebUI界面
通常来讲，大数据查询引擎的查询计划，比关系型数据库的查询计划复杂的多。Impala提供了一个比较友好的WebUI，在这个界面上，能看到完整的执行计划、内存使用状况、异常查询分析，也能够经过界面终止查询语句。
此外，Impala的优点还体如今：彻底兼容Hive元数据、Apache顶级项目有较高的社区活跃度、支持多种数据格式（Parquet、ORC等）、能够与Kudu结合使用等。
02
对Impala的一些加强和优化
在咱们生产实践中，也发现了Impala的一些不足，所以网易大数据团队对Impala进行了一些优化和加强。包括如下几个方面：
Impala 管理服务器
元数据同步加强
基于zookeeper的服务高可用
支持更多存储后端
其余加强和优化
1. Impala管理服务器
Impala已经提供了WebUI的状况下，为何须要一个管理服务器？
其中一个缘由，是社区版的WebUI是非持久化的，一旦Impalad异常退出，这些信息都会丢失。
咱们经过MySQL存储WebUI上的信息，将统计信息、执行信息等重要信息保存到MySQL数据库中，实现持久化保存。在此基础上，管理平台给咱们带来许多增值收益。相比于原生的WebUI，加强版的WebUI能够汇总各个coordinator执行的SQL语句，直观展现当前执行的SQL。
还能够做为集群持续优化的平台。由于记录了历史执行的SQL，能够为后续SQL优化提供依据，好比集群SQL的性能指标、随时间变化的性能表现，以及大部分SQL的执行时间。经过统计SQL执行失败的次数，出错SQL，为定位和回溯问题提供帮助。
2. 元数据同步加强
Impala对元数据的缓存，一方面大幅提高了查询性能，但另外一方面，元数据更新也带来了新的问题。由于数据能够不经过Impala客户端，而经过其余组件好比Hive进行更新，这就让Impala没法感知到元数据的更新。而老旧的元数据会致使查询失败或者性能降低。所以，须要一个机制可以让Impala及时感知元数据的更新。社区版提供了INVALIDATE METADATA这一命令，能够手动刷新元数据。不过若是一些用户不熟悉这个操做，没有更新Impala缓存的元数据，就会致使查询的问题。怎么解决这样的问题？
网易对此进行优化，引入了元数据自动同步机制：在Hive进行DDL相关操做时，记录操做日志，Impala经过消费操做日志，进行必要的Invalidate Metadata的操做，无须人工操做，大大提升了元数据缓存的可用性和实时性。对于提高Impala的查询性能，下降查询错误都有很大的帮助。
另一个是元数据的黑白名单机制，配合Impala不一样的元数据加载方式。对于启动时加载元数据的，配置黑名单，屏蔽不须要经过Impala查询的表；对于延迟加载元数据的，配置白名单，即刻加载元数据，避免首次查询时延迟过大。
另外须要提醒的是，Impala 3.x版本在元数据缓存管理上有了极大的改进，网易大数据团队也在调研中，准备从2.12升级到3.4版本。
3. 基于ZK的服务高可用
虽然每个Impalad均可以做为Coordinator，对外提供访问服务，接受客户端请求，可是缺少一个路由机制。当一个client链接的特定coordinator失效以后，就没法在进行查询了。
网易大数据团队参考Hive的实现，引入zookeeper做为访问代理，客户端首先经过zookeeper找到可用的coordinator节点，而后再提交SQL查询请求。经过这种方式，提供了更健壮的查询服务模式。
4. 支持更多存储后端
对于后端存储的支持，网易团队增长了对iceberg表的建立和查询的支持。已经在云音乐业务上使用，而且贡献给了Impala社区。
其余后端还包括对Alluxio的支持，使用Alluxio做为Impala和HDFS之间的二级缓存。这方面的详细信息，能够搜索《网易严选：基于 Alluxio+Impala 深度融合架构的 BI 系统性能优化实践》。
此外对接Elastic Search查询，充分发挥了ES倒排索引的优点。
5. 其余加强和优化
其余的加强还有：权限的优化、Hive多版本适配、支持JSON，以及社区版的一些Bug修正。
03
Impala在网易的使用案例分析
1. Impala的部署和使用
Impala两种部署方式：混合部署与独立部署。混合部署是指Impala和其余大数据组件共用HDFS。而独立部署则是为Impala配置独立的HDFS。独立部署的优点在于IO和网络通讯都有保障，对性能和稳定性的提高有帮助。可是代价也十分明显：成本上升。
Impala与Kudu结合，能够用来构建实时数仓。Kudu增量写入，按期保存到HDFS。Kudu的使用一方面提供了更新数据和删除数据的能力，另外一方面也解决了HDFS上小文件的问题。而Impala能够同时查询Kudu和HDFS上的数据。
网易内部对集群的监控，对接了网易内部的哨兵服务。能够提供准实时的告警能力。运维人员经过设置阈值，订阅告警信息，从而了解集群的监控程度。
此外，对于Impala集群的部署和使用，还有几点须要注意：
按照大业务划分不一样的集群
按照不一样的子业务或者 SQL 类型划分队列
coordinator 节点与 executor 节点分开部署
对于机器数比较少的集群，机器上可部署多个节点，增长并发
业务方重试机制，以避免 impalad 节点挂掉致使 SQL 失败
经过 impala hint 改变表的 join 方式
结合实际状况参考是否设置 mem_limit ，设置多大 mem_limit
2. 网易大数据中的Impala
在网易大数据平台“猛犸”中，Impala位于数据计算层，提供交互式查询的能力，对应的应用场景是自助分析。
在网易对外提供的产品和服务中，复杂报表和自助取数，都用到了Impala。其中自助分析服务适用于有必定SQL基础的用户，经过本身写SQL语句，查询数据。灵活性比较大，同时门槛也比较高。
网易有数的自助取数服务（easyFetch）能够经过拖拽维度和度量，方便的获取数据，并生成图表报告。后端对接的是网易有数的API。很是适合非专业人员使用数据，发挥出数据的生产力。
网易如今内部有8个Impala集群，超过200个节点，最大集群规模超过60个节点。除了内部服务外，对外的商业化服务，已经有超过20个Impala集群。
3. Impala在云音乐的使用实践
网易云音乐，有2个Impala集群，超过60个节点的规模。主要的应用场景包括：有数报表、自助分析、音乐版权、A/B测试，easyFetch等等。绝大部分应用场景下，Impala的查询时间不超过2秒。
云音乐A/B测试早期使用Spark按照小时粒度，完成从ODS到DWD层的数据清洗工做，以后生成用户分流表和指标统计表，再使用Spark关联这两张表的结果写入到Kudu中，最后使用Impala对接数据，供用户查询。这样数据延迟至少1～2小时，有些结果甚至在次日才能看到。可是对于A/B测试，可以实时看到结果才是最好的。
对此云音乐团队基于Flink作了实时性改造。将DWS变成流表，这样Impala能够同时查询T+1的结果表和流表中的实时数据。A/B测试的效果就能够近实时的看到了。
推荐阅读：