物化查询

docs/olap/01.OLAP概述.md

@@ -666,19 +666,119 @@ Kimball 模型从流程上看是自下而上的，即从数据集市-> 数据仓
 
 ## 预聚合数据模型
 
-Mesa 项目是 Google 大概在2014年发表的论文，实现全球复制以及高度可扩展的分析型数据仓库系统。
+Mesa 项目是 `Google` 大概在2014年发表的论文，实现全球复制以及高度可扩展的分析型数据仓库系统。
 
-在 Google 内部，Mesa 主要解决 Google 在线广告报表和分析业务，拥有准实时的数据更新能力和低延迟的数据查询性能。
 
-广告业务的特点是其数据量特别大，每次广告的展示、点击都会产生一条数据，存储这些原始数据不但会消耗大量的存储资源，也会给实时计算聚合结果（比如 “某个广告主截止目前已经消费了多少预算”）带来很大困难。
+**业务背景**
+
+在 `Google` 内部，`Mesa` 主要解决 `Google` 在线广告报表和分析业务，拥有准实时的数据更新能力和低延迟的数据查询性能。
+
+广告业务的特点是其数据量特别大，每次广告的展示、点击都会产生一条数据，存储这些原始数据不但会消耗大量的存储资源，也会给实时计算聚合结果（比如 "某个广告主截止目前已经消费了多少预算"）带来很大困难。
+
+在大数据分析场景中，核心业务是**经常需要对海量数据进行复杂的聚合操作（如求和、计数、平均值等）。这些操作可能涉及多维过滤、分组和排序**。
+
+如果每次查询都需要对原始数据来重新**实时计算，可能会导致查询延迟过高**。尤其是当数据规模达到 PB 级时。
 
-Mesa 能够处理 PB 级别的数据量，每秒完成数百万行数据的更新，每天服务几十亿次查询和数万亿次数据读取操作。
 
 Mesa 为了解决上面提到的两个问题，提出了一个预聚合的存储模型。Mesa 中的所有表都是预聚合表，以下图中的 Table A 为例：
 
-其中竖线之前的 Date、PublisherId、Country 三列是 Key 列，表示聚合的维度，语义等同于 Group-By；
+![image.png](01.OLAP概述.assets/mesa-table-examples.png)  
+
+
+其中竖线之前的 Date、PublisherId、Country 三列是 Key 列，表示聚合的维度，语义等同于 Group-By；竖线之后的 Clicks 和 Cost 列是 Value 列，表示被聚合的结果。例如第一行表示 `2013-12-31 这一天，ID 为 100 的 Publisher 在 US 一共发生了 10 次点击、价值 32 块钱`
+
+
+上面的 Table A～D 其实表示的是同一批原始数据的在四个不同维度的聚合结果，供不同的业务查询使用。是不是有点像 MOLAP 或者说 Data Cube 的概念？
+
+**本质上是一样的，都是用预先定义和计算聚合（简称 “预聚合”）来加速特定模式的查询。**
+
+
+
+## 物化视图
+
+物化视图是一种预先计算并存储的数据库对象，它基于基础表的数据生成。它类似于普通视图，但普通视图只是逻辑定义（不存储数据），而**物化视图会将查询结果实际存储在磁盘上**，当定义视图的时候，一般来说数据库只会存储该视图定义的查询语句。
+
+
+
+物化视图维护(materialized view maintenance)
+
+由于视图中的数据是从基表中查询出来的，所以一旦基表中的数据发生改变，视图就会过期，所以视图中的数据也要发生改变。保持视图物化一直在最新状态的过程称为**物化视图维护（或者叫数据刷新）**，物化视图维护的策略大概有几种：
+
+- 每当数据变更时就进行视图物化（实时刷新）
+- 周期性的进行视图物化（定时任务来定期刷新）
+- 当需要访问视图时才进行视图物化（需要查询时才来计算）
+
+
+物化视图，跟预聚合数据模型其实很类似，其本质都是**将用户定义的查询提前计算好，按用户要求自动刷新视图中的数据。**数据刷新的方式一般分为两种，**全量刷新**和**增量刷新**。
+
+- 全量刷新每次重新运行SQL，将算好的新数据全量覆盖旧数据。
+
+- 增量刷新通过特定算法，每次只计算自上次刷新以来发生变化的数据部分，然后定向更新物化视图中的部分数据。
+
+
+显然，增量刷新这种方法显著减少了刷新开销，可以更高频地更新。特别适用于大规模数据集或频繁更新的场景。
+
+
+全量刷新适用于T+1类的离线场景。常见的适用场景如下：
+
+- 数据每天批量更新一次，或者小时级别更新一次，更适合全量刷新。这类SQL通常比较复杂，全量刷新对SQL语法没有任何约束。
+
+- 在某些分钟级别延迟的场景中也可以使用全量刷新，往往这类SQL即使全量计算成本也不大，通常十几秒能完成，还可以达到一定的实时效果。
+
+增量刷新适用于**实时场景**。常见的适用场景如下：
+
+- 数据实时流入。
+
+- 需要实时更新的报表或ETL。
+
+- 对数据延迟要求高的秒级延迟需求。
+
+
+
+**物化视图查询改写**
+
+物化视图（Materialized View）的查询改写功能（Query Rewrite）
+
+这是 Oracle 数据库的一项核心优化技术，允许数据库优化器在执行用户查询时，自动将查询重写为对物化视图的访问，从而避免对基础表进行实时计算。
+
+优化器能够自动检测用户的查询，并尝试将其重写为对物化视图的访问。基本工作原理：**优化器会分析用户的查询，并将其与现有的物化视图进行匹配。如果匹配成功，优化器会生成一个新的查询计划，将用户的查询重写为对物化视图的访问。**
+
+```SQL
+
+-- 原始表
+CREATE TABLE sales (
+    id INT,
+    region VARCHAR(50),
+    amount DECIMAL(10, 2)
+);
+
+-- 物化视图
+CREATE MATERIALIZED VIEW mv_sales_summary
+    BUILD IMMEDIATE
+    REFRESH FAST ON COMMIT
+ENABLE QUERY REWRITE
+AS
+SELECT region, SUM(amount) AS total_sales
+FROM sales
+GROUP BY region;
+
+
+-- 原始查询
+SELECT region, SUM(amount) FROM sales GROUP BY region;
+
+-- 优化器改写
+SELECT region, total_sales FROM mv_sales_summary;
+```
+
+
+
+## 达梦物化视图
+
+物化视图 (MATERIALIZED VIEW) 是目标表在特定时间点上的一个副本，占用存储空间，即将查询出来的数据存储在数据库中。当所依赖的一个或多个基表的数据发生更新，必须启用刷新机制才能保证数据是最新的。
+
+物化视图可以用于数据复制（Data Replication），也可用于数据仓库缓存结果集以此来提升复杂查询的性能。
+
+
 
-竖线之后的 Clicks 和 Cost 列是 Value 列，表示被聚合的结果。
 
-例如第一行表示 2013-12-31 这一天，ID 为 100 的 Publisher 在 US 一共发生了 10 次点击、价值 32 块钱