本文将次要介绍 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 视图创立 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))到了第二天（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/do…
[2]https://calcite.apache.org/do…
[3]https://calcite.apache.org/do…
[4] https://www.cnblogs.com/liste…
作者简介
荣廷，网易数帆数据库技术专家，10 年 + 数据库相干工作教训，目前次要负责高性能数仓和云原生数据库研发工作。