基于 Impala 的高性能数仓实践之物化视图服务

本文将主要介绍 NDH Impala 的物化视图实现。

接上篇讲到了虚拟数仓，它们是让一个 SQL 又快又好地执行的关键。但如果某些 SQL 过于复杂，比如多张大表进行 Join 并有大量的聚合类操作，那么再优秀的执行引擎也无法保证能够秒级执行完成，虚拟数仓的弹性扩展能力也很难及时跟上，这正是物化视图能够发挥作用的场景。

1 物化视图简介

在计算机领域，物化视图是一个数据库对象，结构化保存了一个 SQL 查询的结果集，创建物化视图的过程可称为物化，是预计算的一种形式。物化视图是一个比较宽泛的概念，可能是远端数据的一份本地拷贝，也可能是一个表或多表 Join 后某些行 / 列的子集，也可以是将聚合函数作用到表或 Join 结果后的汇总类信息。

1.1 物化视图分类

根据物化视图中原始数据表的个数，可分为单表和多表物化视图；根据物化视图 SQL 中是否存在聚合类操作，可分为明细和聚合物化视图；根据物化视图的结果集在更新时是否需要全量刷新，可将其分为全量和增量物化视图，后者又可称为分区物化视图，增量数据写入新分区中。

1.2 特点与作用

普通视图仅表示一个 SQL 语句，是个逻辑概念，而物化视图则有实体对象 / 表与之对应。这样在执行查询时，就可以通过查询对应的物化视图表数据，从而快速得到查询结果。物化视图使用查询重写机制，当执行查询时，引擎自动选择合适的物化视图进行查询重写，完全对应用透明。

一般用于进行性能加速，具有比较广泛的使用场景，如果业务查询存在如下特征，即可尝试用物化视图进行加速：比如查询耗时较多且查询频次较高、相同或相似的查询多并发或周期性发生、业务对查询结果的数据实时性没有过于严格的要求，允许分钟或小时级的延迟等。具体业务方面，在数仓领域，T+1 类 BI 报表是典型的可以通过物化视图进行优化查询的场景。

1.3 使用效果评估

物化视图使用得当能够数倍，甚至数十倍提升查询性能，但其也不是万能的，如果不分场景盲目创建物化视图，其结果可能适得其反。一方面是因为物化视图的创建和更新有成本，另一方面，判定 SQL 是否命中的逻辑也在性能敏感的代码路径上引入了额外的耗时。

笔者认为，使用物化视图的效果评价需要考虑 2 个方面：首先，其是否带来了查询的性能提升。这是最基本的目标；其次，是否降低了集群总的资源消耗，包括计算资源和存储资源。这是进阶目标，在每个物化视图都有大量的查询命中时，将会明显减少每个查询对 CPU 和内存资源的需求，同时也不再需要访问原始表，减少 IO 资源消耗。

1.4 使用现状

物化视图是进行查询性能优化的重要手段，传统的商业数据库，比如 Oracle、IBM 和 SQL Server，以及目前商业数仓系统，比如 Snowflake、AnalyticDB 等，均具有强大的物化视图能力。

目前开源的数仓系统，在物化视图支持程度上相对不足，Doris、Clickhouse、Druid 等暂时仅支持单表聚合类物化视图（或称为聚合索引），也有数仓引擎已经在开发多表物化视图，比如 Meta 的 PrestoDB 等。网易 NDH Impala 在物化视图能力建设上投入较早，目前已在生产环境上规模使用，本章的后续小节主要介绍 NDH Impala 的物化视图实现和实践。

2 Impala 物化视图

2.1 设计架构

在设计 Impala 物化视图系统时，秉持了尽可能通用的原则，希望其不仅仅能够用于改写 Impala 查询 SQL，未来能够方便的集成到其他的查询引擎上。下图所示为物化视图设计架构图，包括独立的物化视图服务、嵌入在 Impala Coordinator 中的物化视图改写模块和用于优化物化视图的 Impala 管理服务器。

物化视图服务提供了多种物化视图管理的 API，包括视图的创建、定义更新、数据更新 / 同步、启用 / 禁用、视图信息展示、视图使用统计和视图删除等。Impala 管理服务器保存的历史查询信息为物化视图服务的视图创建、定义更新和视图管理提供数据支撑。物化视图服务使用 MySQL 作为元数据库，包括了视图定义、状态和使用统计等信息。Impala Coordinator 节点集成了物化视图透明改写模块，用于判断查询 SQL 是否能够命中某个 / 某些物化视图，若命中，则对其进行透明改写。

2.2 视图创建

NDH Impala 提供两种物化视图创建模式，分别适用于网易数帆的有数 BI 场景和通用场景，两者均需使用 NDH Impala 专有的管理服务器，通过历史查询信息优化来物化视图定义。前者基于有数 BI 的数据模型和图表历史查询行为来生成物化视图 SQL，后者则是通过分析历史查询信息来提取 SQL 模板信息，为满足要求的 SQL 模板创建物化视图。下面主要介绍有数 BI 场景下的视图创建，包括预检查、物化视图 SQL 优化和更新。

预检查

预检查用于在物化视图创建之前，提前剔除掉不合理或暂不支持的创建请求。主要有以下几种情况：

（1）判断是否为实时或准实时表。Impala 物化视图服务暂不支持实时场景，所以，如果待优化的 BI 数据模型或 SQL 模板中存在 Kudu 表或 Arctic/Iceberg 表，则拒绝创建请求。

（2）判断是否能够进行模糊匹配。主要包括聚合或多表关联时条件自由筛选场景，举多表外关联为例，假设表 t1 和 t2 均为分区表，分区字段均为 dt，但两表并没有通过 dt 字段进行关联，用户在查询时会灵活地为 t1 和 t2 进行 dt 分区各取不同的值 / 范围，由于外连接的非关联字段过滤在关联前和关联后进行是不等价的，因此无法模糊匹配。对于聚合场景，若物化视图对表 user 的 age 列取平均值，若查询对 user 进行了筛选，显然 age 列的平均值会失效。

（3）判断是否适合用物化视图进行优化。引起查询慢的原因很多，物化视图适合对查询本身慢进行优化，对于偶发或波动类的因素，其优化效果并不明显。这些因素包括存储层性能抖动（比如 HDFS 的 DN 或 NN 性能波动）、HMS 元数据加载（未命中 catalog 缓存导致查询时需即时加载）、排队执行（查询并发超阈值或内存资源不够）