【讲稿】Impala在网易大数据中使用和优化实践-P2

本文是在2020 DataFunCon上所做分享的讲稿，感谢DataFun团队整理。由于篇幅较长，分为2篇来记录，这是第二篇。

上文：【讲稿】Impala在网易大数据中使用和优化实践-P1

---

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修正。

 

▌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测试的效果就可以近实时的看到了。更多的详情可以搜索《进击的 Flink ：网易云音乐实时数仓建设实践》