本文将主要介绍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缓存导致查询时需即时加载）、排队执行（查询并发超阈值或内存资源不够）、集群网络抖动（网络拥塞等）。物化视图服务通过从Impala管理服务器获取该数据模型或SQL模板的历史查询profile信息来进行前述因素的判定。

对于上述情况，物化视图创建请求直接拒绝，并返回拒绝的原因。

SQL优化

若是BI的数据模型场景，对通过了预检查的创建请求，还需要对其传入的“裸”物化视图SQL（模型SQL）进行优化。我们先说原因，再说如何进行优化。

为什么要进行物化视图SQL优化？本质上说是为了提升前述的物化视图使用效果。从实践经验看，数据模型SQL中可能涉及TB甚至PB级别的大表，这些表一般是按日期，比如天进行分区，模型中会对多个分区表按分区字段进行关联。大部分情况下，在数据模型层面并没有约束大表的分区范围，也就是说，如果完全按数据模型SQL进行物化视图构建，所需消耗的计算和存储资源可能是单个图表查询的数十、上百倍甚至更高倍数。为了提升数个图表查询的性能而消耗过多的资源显然是不可取的。而现实情况是，图表查询中的分区范围往往是有明显的规律性的，一般集中在最近一个季度，大部分都是一个星期内的时间，如下图所示：

本着最优的投入产出比，我们就可以基于以往的查询规律，将物化视图的作用域缩短到某个分区范围内，比如昨天、最近一周、最近一个月等等。

那么具体是如何做的呢？NDH Impala做的很多优化都用到了Impala查询Profile，在实现物化视图系统时也不例外。在进行物化视图SQL优化时，会从历史查询中筛选出属于该数据模型的所有图表查询SQL，分析其Profile信息，进一步过滤出待优化的SQL集合。这些SQL一般满足如下一个或多个条件：查询耗时超过阈值（已排除队列等待、元数据加载等因素）、消耗的内存资源超过阈值、扫描数据量超阈值、扫描的行数超阈值等。

经过前述条件筛选后，还可根据图表查询的触发类型等维度区分优化的优先级，比如用户触发的图表查询优先级高于BI后台进行结果预缓存的查询。

对于筛选出来的SQL集合，逐个解析SQL语句，提取各事实和维度表的分区范围，并按大小进行排序。默认取最大的分区范围作为物化视图的有效范围，若该范围过大，则根据配置的参数选择更加合适的分区范围，比如选择90%以上查询都在其中的范围值。

多物化视图

基于上面的优化逻辑，对一个数据模型，会创建至少一个物化视图，但也可能创建多个物化视图，这主要跟用户在该数据模型上创建的图表特点有关，比如，往往需要给列表筛选器单独创建物化视图。

先解释下什么是列表筛选器。下图是用于展示Impala慢查询的图表，可分为红框和蓝框两部分，其中红框用于进行过滤条件筛选，筛选的结果在蓝框中展示。红框中有倒三角下拉标记的这些控件就是列表筛选器。

以hostname筛选器为例，其用于查看某几个特定Coordinator上的慢查询。要对其进行筛选，首先就需要获取可选的Coordinator节点，这就需要执行一条查询SQL：对存放Impala历史查询信息的basic_info表的hostname列全表扫描并group by取结果。由于默认是不带分区过滤的全表扫描，因此无法命中物化视图，且由于全表扫描，查询性能较差，因此会专门为没有分区过滤条件的一个或多个列表筛选器创建物化视图。

分区物化视图

为了能够提高物化视图的数据更新效率，在创建物化视图时会判断是否能够对物化视图数据进行增量更新。物化视图服务通过解析物化视图SQL，判断各表是否用分区字段进行关联，若是，则可以创建分区物化视图，在进行数据更新时，只需要处理前一天新产出的数据。

SQL更新

SQL更新指的是物化视图创建后，在使用过程中，根据用户/业务查询行为的变化，动态调整物化视图SQL。可以通过物化视图的查询命中率来评估是否需要调整。这里所说的命中率是指同个数据模型下的图表查询，能够命中物化视图的百分比。

假设某个数据模型的物化视图，创建后的命中率一直高于80%，若最近几天命中率下降到50%以下，那么可能有两种情况导致，一种是数据模型被修改，另一种是图表或筛选条件发生变化。对于前一种情况，有数BI产品会通过服务视图服务提供的接口自动触发物化视图SQL更新。

对于后一种情况，需要物化视图服务通过后台的分析线程周期性分析查询命中率，在命中率明显变差后，触发物化视图SQL更新。

2.3 视图使用

判断一个查询能否命中某个物化视图并在命中后自动改写使其查询物化视图表，这是个数据库领域十分有技术含量的工作，有多篇顶级论文提出了不同的解法。在Impala物化视图服务中，命中判断和透明改写的核心是基于Apache Calcite提供的两种算法[1]。但光靠Calcite现有的能力还不足以满足线上规模使用的要求，Impala物化视图服务在此基础上做了大量的优化。本小节先简述Calcite改写实现，再介绍所做的增强。

Calcite透明改写能力

总的来说，目前有三种物化视图改写实现，分别是基于语法、基于规则和基于结构进行查询命中判断并改写。其中，基于语法的改写方式通过文本匹配或者语法匹配实现，将查询的文本与物化视图的文本或语法树进行比较，完全匹配即可进行改写。该方式实现难度低、改写效率最高，但只能匹配完整的查询语句或子查询，适用范围太小。

Apache Calcite实现了基于规则和基于结构的物化视图改写方式，详见“Substitution via rules transformation”[2] 和“Rewriting using plan structural information”[3]。

基于规则的改写方式使用范围较广，可以对大量重写，功能实现也较为简单，改写匹配速度快，其局限是改写依赖转换规则来寻找等价关系，因此需要穷举所有可能的转换关系来实现复杂视图的重写。一些复杂的视图不可能穷举所有的等价关系，例如存在很多的 Join 联接或者复杂的 Project 关系，基于规则的改写适用的范围取决于规则的数量。

基于结构的改写方式由微软在 2001 年 SIGMOD 论文《Optimizing queries using materialized views: A practical, scalable solution》[4] 系统化的提出。其将查询表示为 SPJG 标准形式 (Join-Select-Project-GroupBy)，提取查询中的 Join，Projects，Filters，Grouping 和 Aggregations 五种表达式，运用一系列的步骤分别与物化视图对应的表达式进行匹配并得到补偿表达式。

基于结构的改写相比基于规则的方式更容易扩展，使用范围更广，不足之处在于搜索成本较高。在实践中发现，使用后者对复杂SQL（比如存在10+以上表关联）进行改写时，其性能远不如前者，尤其是该查询SQL还命中了多个物化视图时，可能无法达到优化查询性能的目的，甚至适得其反。因此，Impala物化视图服务会同时使用基于规则和基于结构的改写实现，并使用前者作为默认的改写方式。

改写能力优化

为了增强改写能力，提高改写性能，Impala物化视图服务对改写方式进行了优化，主要包括元数据缓存、命中预判定、支持更多SQL语法和改写校验等，如下图所示。

元数据缓存

前文的物化视图服务架构图提到物化视图信息（既物化视图元数据）是持久化在MySQL中的，而对用户查询进行透明改写需要用到物化视图元数据，显然，每次进行改写时都从MySQL加载元数据会对改写性能造成很大影响，因此，需要在Impala Coordinator缓存物化视图元数据信息。

进一步，原生的Calcite改写框架在执行改写前，需要基于物化视图元数据信息（MaterializationActor.Materialization）动态生成物化视图改写对象（RelOptMaterialization），这是一个比较耗时的过程，假设某个用户查询有10个候选物化视图，仅构造物化视图改写对象可能就需要耗费数百毫秒甚至数秒时间。为了降低改写过程的耗时，需在Coordinator提前构造RelOptMaterialization并将其缓存。

为了确保缓存的元数据是最新的，Coordinator会每隔数秒（可配置）从MySQL获取新增或更新过的物化视图信息，构建MaterializationActor.Materialization和RelOptMaterialization对象并替换原有的缓存对象。

命中预判定

Calcite物化视图改写过程是串行的，也就是系统会逐一判断每个候选的物化视图是否能够成功改写物化视图。元数据缓存能够缩短每次判断的时间，但无法减少判断次数。为此，我们加入了命中预判定来减少候选的物化视图个数。

目前采用的命中预判定策略类似上述的基于语法的改写实现，如果查询SQL和物化视图SQL一样，无需走命中判定和改写，直接返回改写后SQL。更通用的方法是根据SQL语句自身的一些特点，设置一些规则，提前过滤掉部分不可能用于改写的物化视图。这些规则包括但不限于：

• 判断满足物化视图中涉及的表均在查询SQL中
• 判断满足查询返回的selectList属于物化视图selectList的子集
• 若查询SQL存在Sort算子（定义见下文），判断是否满足Sort算子的校验
• 若匹配的物化视图对象数量仍超过阈值，再通过归一化SQL进行匹配筛选

通过以上预判定，可以大大减少参与改写的物化视图数量，提高改写效率。而且，可以提前识别不可能命中物化视图的查询SQL，减少无效的改写行为。

语法/算子支持

Calcite虽提供了基于规则和结构的改写方式，但在每种实现中，支持的语法和算子还不够多，比如不支持改写带外连接（outer join）的查询，不支持分组和排序相关的算子等。此外，Impala上大量的内置UDF函数显然也是不支持的。这些都严重限制了物化视图在业务场景中的使用，均需要我们进行增强。

Calcite不支持多表外连接场景，我们通过二次开发，在确保改写结果正确性的基础上，支持以下情况的物化视图改写：

除上图之外，从表（左连接时为右表，右连接时为左表）子查询过滤有个特殊情况可以允许改写，即当从表子查询过滤条件全为关联（on）字段且这些字段过滤条件和主表过滤一致。

Calcite也还未支持查询中包含Sort算子（包括排序、分页，即order by/limit/offset）的场景，但目前NDH Impala支撑的业务查询，绝大部分都带有Sort算子。我们增加了对包含Sort算子的查询进行改写的支持。实现上，目前是通过改写前移除查询SQL中的Sort算子，改写后校验补偿Sort算子的方案来实现。

带Group算子的查询存在改写后丢失Group算子的问题，而NDH Impala支撑的业务查询中带有Group算子的查询比例较高。因此，对Group算子改写也进行了完善，补偿方式上与Sort算子相似。

改写校验和回退

为了确保经过Calcite改写的SQL是正确的，需对改写后SQL进行校验，比如确认是否包含物化视图表。通过验证后，会增加SQL注解，用于标识该SQL非原始SQL。若改写结果校验不通过，或改写过程中出现任何异常，或改写后SQL在Impala进行解析和鉴权等处理时出现任何异常，都会替换回原始查询SQL，确保查询正常执行。

2.4 数据更新

与基于Calcite的透明改写模块不同，NDH Impala物化视图系统的数据更新模块是全新开发的，提供了多种更新方法，处理了更新失败场景并设计了可扩展的元数据更新方案。

更新方法

物化视图表的数据在创建后不能一成不变，当原始表有新数据写入或对历史数据进行更新后，需要尽快更新物化视图表数据，确保命中物化视图后查到最新的结果。对于像Impala这样的存算分离查询引擎，数据的写入和更新一般基于Hive或Spark，并不能天然地感知到表中数据的变化，在我们的方案中，提供了四种数据更新的方法，分别是依托有数大数据平台的离线数据产出日志、依托NDH的Hive Metastore（HMS） DDL日志、兜底的定期检查原始表的数据文件修改时间，最后还有手动更新。

有数大数据平台的数据血缘模块能够根据数据产出的上下游关系，推送离线数据产出日志，物化视图服务订阅产出消息，将其持久化到MySQL的产出日志表中，再由更新线程消费这些产出日志，驱动包含该原始表的一或多个物化视图进行数据更新。若原始表没有配置数据血缘，通过NDH HMS组件的DDL操作日志来驱动。相对来说，基于产出日志的更新效率更高。

如果表没有数据血缘，数据写入和更新也不走HMS，那么上述两种更新策略均失效。此时，需为物化视图配置数据更新时间窗，更新线程在物化视图进入时间窗后会定时检查物化视图中各原始表数据目录的数据文件，检查修改时间，若大于上次物化视图更新时间，这需驱动物化视图更新。

更新失败处理

若由于某种原因，物化视图更新失败，则需要进行重试，若仍然失败，则需要将该物化视图失效掉，禁止查询SQL命中该物化视图。之后在由管理员介入进行问题排查。

元数据更新

前文提到的物化视图的创建、定义更新、数据更新和禁用等行为，均需要创建或更新物化视图元数据。尤其是数据更新时，还需要修改物化视图用于进行命中判定的物化视图SQL。下面举个简单的例子：

SELECT XXXXXX
FROM `music_db`.`xxxx` AS `t1`
INNER JOIN `music_iplay`.`xx` AS `t2` ON CAST(`t1`.`userid` AS VARCHAR(255)) = `t2`.`user_id`
LEFT JOIN `music_iplay`.`xxx` AS `t3` ON `t1`.`day` = `t3`.`dt` AND `t1`.`unionid` = `t3`.`union_id`
LEFT JOIN `music_iplay`.`xxxxxxx` AS `t4` ON `t2`.`live_type` = `t4`.`live_type` AND `t2`.`dt` = `t4`.`dt` AND `t2`.`user_id` = CAST(`t4`.`user_id` AS VARCHAR(255))
WHERE `t1`.`day` = partitionColumn_1

上图是一个物化视图的定义SQL，有4个原始表，分别进行内连接和左连接，其中t1表为T+1分区表，分区字段day。“partitionColumn_1”是数据更新站位标志，表示查询t1表的最近分区（昨天）。与之对应，物化视图改写SQL为（假设今天为2022-8-11）：

SELECT XXXXXX
FROM `music_db`.`xxxx` AS `t1`
INNER JOIN `music_iplay`.`xx` AS `t2` ON CAST(`t1`.`userid` AS VARCHAR(255)) = `t2`.`user_id`
LEFT JOIN `music_iplay`.`xxx` AS `t3` ON `t1`.`day` = `t3`.`dt` AND `t1`.`unionid` = `t3`.`union_id`
LEFT JOIN `music_iplay`.`xxxxxxx` AS `t4` ON `t2`.`live_type` = `t4`.`live_type` AND `t2`.`dt` = `t4`.`dt` AND `t2`.`user_id` = CAST(`t4`.`user_id` AS VARCHAR(255))
WHERE `t1`.`day` = '2022-08-10'

到了第二天（2022-8-12），t1表的2022-8-11号分区数据产出，物化视图完成数据更新后，需要更新改写SQL的WHERE条件（WHERE t1.day = '2022-08-11'）并持久化到MySQL中。

SELECT XXXXXX
FROM `music_db`.`xxxx` AS `t1`
INNER JOIN `music_iplay`.`xx` AS `t2` ON CAST(`t1`.`userid` AS VARCHAR(255)) = `t2`.`user_id`
LEFT JOIN `music_iplay`.`xxx` AS `t3` ON `t1`.`day` = `t3`.`dt` AND `t1`.`unionid` = `t3`.`union_id`
LEFT JOIN `music_iplay`.`xxxxxxx` AS `t4` ON `t2`.`live_type` = `t4`.`live_type` AND `t2`.`dt` = `t4`.`dt` AND `t2`.`user_id` = CAST(`t4`.`user_id` AS VARCHAR(255))
WHERE `t1`.`day` = '2022-08-11'存放物化视图元数据的MySQL表中包含createTime和updateTime两列，分别表示物化视图元数据的创建和最后一次更新时间，Impala集群各Coordinator通过这两个字段即可获取新增或修改过的元数据，更新Coordinator内存中的物化视图缓存，确保进行查询命中判定和改写时使用的是最新的元数据。

2.5 视图管理

Impala物化视图提供了管理页面，能够进行视图信息展示，使用统计并进行一些常用的视图操作。如下图示例：

通过管理页面可以看到每个视图的基本信息，包括创建和最近更新时间、视图是否启用、视图表的记录数和数据量等。通过详情页能进一步查看视图定义，包括建表SQL、更新SQL和改写SQL等。管理页面还提供物化视图的命中明细信息，可以查看每个物化视图命中了哪些用户查询，展示那些查询的基本信息等，如下所示：

通过物化视图命中率统计还能够查看视图的使用效果，如下所示：

通过管理页面提供的信息，用户能够删除一些性价比较低的物化视图，如近期不再有查询命中，或者消耗资源过多等。

就目前来说，Impala物化视图服务更多还是聚焦在优化和增强核心模块，包括视图创建、改写和更新的效率。在管理页面上提供的信息还比较有限。

3 实践和总结

Impala物化视图服务上半年在网易云音乐的BI重点报告场景规模化落地使用，明显改善了在BI报表预缓存未命中场景下的报表查看性能体验。在落地过程中，也遇到了不少问题。

3.1 问题和挑战

遇到的问题是多方面的，在技术上主要集中在视图的命中判定和改写、视图数据更新上。经过充分调研和对比，确定前者基于Calcite快速获得能力，避免重复造车。后者由于平台依赖性较强，采用全自研的方式。

更多的困难来自于落地使用。在刚开始落地使用时，遇到直接基于BI数据模型创建的物化视图性价比较低问题（创建和更新物化视图所需资源过多，带来的查询性能提升不足以抵消增加的成本），问题原因主要是模型上没有设置分区表的分区过滤条件，比如t1表保存了近3年的数据分区，但报表上用到的t1数据仅为最近1个月。由于模型上未对分区进行筛选，导致直接基于模型SQL创建物化视图时会全量物化近3年所有的数据，其资源浪费不言而喻。在此情况下，我们引入了视图创建审核机制，先确认模型SQL的合理性，若未带分区约束，则通过Impala管理服务器保存的历史查询来确定所需的分区范围，物化视图使用的性价比明显提升。

但审核需要人工查看每个数据模型下发的SQL，统计查询的分区区间，性价比虽提升了，但人力投入增加了，因此又逐步开发了自动进行历史查询的分区范围统计的能力，提高创建效率。引入历史查询来确定分区范围提高了性价比，但用户的查询行为不会一成不变，因此，又有了周期性的重新获取分区范围的思路，并逐步提高自动更新能力。

3.2 使用思考

物化视图是一种有效的性能提升手段，无需赘言，但从实践来看，物化视图具有较高的使用门槛，尤其是通过多表连接的物化视图，往往需要有数据库背景的研发或运维才能用好。原因如下：首先，物化视图通过SQL来表示定义，这对于不熟悉SQL的用户不友好；其次，只有充分了解用户具体会执行哪些SQL，创建的物化视图才能有足够高的查询命中率；最后，只有不断识别用户查询SQL的条件变化，才能使物化视图维持较高的查询命中率。

在大数据场景，如果数据分析师具备较强的SQL能力，那么物化视图可作为一种轻量级ETL手段，用来快速进行查询性能加速。这个主要是从敏捷和灵活性角度出发来考虑的，假设数据分析师直接通过多表连接进行自助分析和Ad-Hoc查询，由于表的数据量大或表关联多，可能性能会比较差，影响数据分析效率。若分析师向数据加工团队提需求建个新表用于分析查询，这需要新增一个ETL任务，数据加工团队可能需要排期来做，从提出需求到新表就绪可能需要数个工作日甚至数周时间，若查询的需求多而易变，那对数据加工团队是个不小的负担。这种情况下，若数据分析师具备较强的SQL能力，可以发挥物化视图服务的灵活性，无需数据加工团队介入，新表（物化视图表）的就绪时间也可以大大缩短。

但在更普遍的情况下，分析师对SQL较为陌生，比如使用BI产品进行数据分析时，传统的物化视图技术并不适合。要用好物化视图，需要在数据库/数据仓库和最终用户之间有个中间的沟通角色，对于传统的关系型数据库，这个角色就是数据库管理员（DBA），其职能包括审核业务的表结构、分析慢SQL、巡检数据库服务日志和数据库性能调优等等，DBA掌握了使用物化视图进行查询性能优化所需的信息。在大数据分析领域往往存在DBA角色缺失的情况，客观原因很多，不是本文讨论重点，在此不展开。

在这样的背景下，为了发挥物化视图的能力，需要对其进行一些变革。路径很多，其中就包括让物化视图更加智能，知道应该创建什么样的物化视图，知道什么时候应该及时调整物化视图，这正是我们在物化视图系统实现后期做的尝试。但这条路肯定是漫长的，如何尽可能避免对具体业务场景的依赖还需不断探索。比如Impala物化视图服务为有数BI产品做的智能化方案，并不一定在其他产品上有同样的效果。另一种变革的方式是从产品侧驱动，比如有数BI产品提供物化视图能力，优势包括相比数仓系统更了解用户（报表）查询行为、能够用比SQL更直观的方式来表示物化视图、在BI系统产生SQL前即可完成查询的改写、可以做得更加通用不依赖具体的数据源等。

4 小结

本文先简要介绍了物化视图定义、分类、特点和作用等基本知识，再重点介绍了NDH在Impala上实现的物化视图系统，包括基于Apache Calcite进行二次开发的透明改写能力，基于离线数据产出日志、HMS DDL日志等方式驱动的物化视图数据自动更新服务，以及视图管理模块。进一步介绍了在网易云音乐场景落地实践及经验教训，思考如何才能高效发挥物化视图的查询性能优化能力。最后需要说明的是，以上均为笔者个人的一些实践和体会，欢迎各位大佬提供意见建议、批评指正。

参考链接：

• [1] https://calcite.apache.org/docs/materialized_views.html

• [2] https://calcite.apache.org/docs/materialized_views.html#substitution-via-rules-transformation

• [3] https://calcite.apache.org/docs/materialized_views.html#rewriting-using-plan-structural-information

• [4] https://www.cnblogs.com/listenfwind/p/16029792.html

作者简介

荣廷，网易数帆数据库技术专家，10年+数据库相关工作经验，目前主要负责高性能数仓和云原生数据库研发工作。