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