内核探究 | Apache Cloudberry：如何利用物化视图进行查询改写

物化视图（Materialized View）是一种基于特定SQL查询预先计算并存储的结果集，它能够显著提升查询操作的效率。在执行查询时，系统能够智能地识别并替换为相应的物化视图，直接返回预先计算好的结果，或者在这些结果的基础上进行进一步的数据处理。这一技术在在线分析处理（OLAP）场景中表现得尤为出色，特别是在处理大型数据表的聚合查询时，能够大幅度缩减查询所需时间，实现性能的显著提升。本文将深入探讨如何在Apache Cloudberry（以下简称“Cloudberry”）中利用物化视图来实现SQL查询的改写，同时解析其背后的技术原理与实施细节。

01 利用物化视图进行查询改写

Cloudberry依托PostgreSQL优化器的逻辑，支持利用物化视图来优化查询改写过程。我们来看一个具体示例：假设我们有一个名为T1的表，它包含两列数据：

create table t1(c1 int, c2 int); 

 create materialized view mv_t1 as select count(c1) as m_c1 from t1 where c2 > 1; 

对于原始的查询语句：select count(c1) from t1 where c2 > 1; 

我们可以将其改写为直接从物化视图mv_t1中选择所需的列m_c1：select m_c1 from mv_t1;在T1表包含数亿行数据的场景下，直接进行扫描和计算的成本非常高，即使采用并行化技术也难以显著降低开销。然而，通过利用物化视图，我们可以在短短数秒内获取到查询结果。这种改写逻辑建立在查询等价性的基础之上，确保物化视图能够完全涵盖查询所需的所有行和列，从而保障查询结果的一致性。在Cloudberry中，查询的改写过程是基于成本优化的。系统会自动对比不同的物化视图和改写方案，从中选择出最优的执行路径，以确保查询的高效执行。物化视图改写的首要任务是确定候选视图。Cloudberry提供两种类型的物化视图，每种类型都有其独特的特点和适用场景：

• 增量物化视图：实时更新，自动化维护，非常适合对数据一致性有高要求且查询相对简单的场景。但请注意，其功能具有一定的局限性。
• 普通物化视图：具有高度的兼容性，适用于查询复杂度高、实时性要求稍低的场景。目前，其改写功能正在持续优化中。

同时，Cloudberry还具备完善的普通物化视图有效性检查机制：

• 智能判断视图有效性：如果自最近一次刷新后，没有增删改查操作，则视为有效，直接提供高效查询。
• 即时标记失效：一旦数据发生更新，立即标记为失效，以确保数据的准确性。
• Delta处理复用视图：灵活应对数据修改，未来计划将此功能开源，进一步提升系统的灵活性和效率。

Cloudberry当前的物化视图改写功能主要聚焦于单表场景，能够满足大部分的使用需求。在实现过程中，连接树的检查相对简单，因为在单表查询中，只需要检查关系表的OID（对象标识符）。对于某些复杂场景，单表可能是普通表，也可能是分区表，而分区表内部可能还包含多个子分区。Cloudberry在设计时已经充分考虑了这些复杂性，以确保系统的稳定性和高效性。

02 物化视图与查询条件匹配的实现逻辑

物化视图的主要作用是加速查询响应，它通过存储预先计算好的查询结果来减少重复计算。然而，物化视图并非总能直接用于所有查询，其能否被利用取决于查询条件与物化视图条件的匹配程度。

View matching: construct rows

我们根据以下几个示例，来看查询条件与物化视图条件匹配的实现逻辑：示例一：我们先来看一个简单的场景，假设有一个基础表 T1，并基于它创建了一个物化视图 mvt1Viewcreate incremental materialized view mvt1 as select c3 from t1 where c1 = 1 and c2 = 2; Query select c3 from t1 where c1 = 1 and c2 = 3; 在这个例子中，查询的限制条件是query_quals = {c1=1, c2=3};，而物化视图的限制条件是mv_quals = {c1=1, c2=2};，我们可以通过下图来展示二者之间的数学关系。