四、Doris物化视图

使用场景: 

   在实际的业务场景中，通常存在两种场景并存的分析需求：对固定维度的聚合分析 和 对原始明细数据任意维度的分析。

   例如，在销售场景中，每条订单数据包含这几个维度信息（item_id, sold_time, customer_id, price）。在这种场景下，有两种分析需求并存：

• 业务方需要获取某个商品在某天的销售额是多少，那么仅需要在维度（item_id, sold_time）维度上对 price 进行聚合即可。
• 分析某个人在某天对某个商品的购买明细数据。

在现有的 DorisDB 数据模型中：

• 如果仅建立一个聚合模型的表，比如（item_id, sold_time, customer_id, sum(price)）。由于聚合损失了数据的部分信息，无法满足用户对明细数据的分析需求。
• 如果仅建立一个 Duplicate 模型，虽可以满足任意维度的分析需求，但由于不支持 Rollup， 分析性能不佳，无法快速完成分析。
• 如果同时建立一个聚合模型和一个 Duplicate 模型，虽可以满足性能和任意维度分析，但两表之间本身无关联，需要业务方自行选择分析表。不灵活也不易用。

MVs使用 

---

   物化视图的出现主要是为了满足用户，既能对原始明细数据的任意维度分析，也能快速的对固定维度进行分析查询的需求。

• 

从定义上来说，MVs就是包含了查询结果的数据库对象，可能是对远程数据的本地Copy；也可能是聚合后的结果。说白了，就是预先存储查询结果的一种数据库对象。

在Doris中的物化视图，就是查询结果预先存储起来的特殊的表。它的优势在于：

• 对于那些经常重复使用相同的子查询结果的查询性能大幅提升
• Doris自动更新物化视图的数据，保证Base 表和物化视图表的数据一致性。无需额外的维护成本

说明注意：

• 物化视图的创建当前为异步操作。创建物化视图的语法会立即返回结果，但物化视图的生成操作可能仍在运行。
• base表中的分区列，必须存在于创建物化视图的group by聚合列中
• 目前只支持对单表进行构建物化视图，不支持多表JOIN ？
• 聚合类型表（Aggregation)，不支持对key列执行聚合算子操作，仅支持对value列进行聚合，且聚合算子类型不能改变。
• 物化视图中至少包含一个KEY列
• 不支持指定物化视图查询 ？

 

创建物化视图 

---

 

首先你需要有一个Base表，基于这个Base表的数据提交一个创建物化视图的任务，任务中定义好物化视图如何构建。 然后Doris就会异步的执行创建物化视图的任务了。

如上图以一个销售记录表为例：比如我们有一张销售记录明细表，存储了每个销售记录的id，销售员，售卖时间，和金额。 提交完创建物化视图的任务后，Doris就会异步在后台生成物化视图的数据，构建物化视图。在构建期间，用户依然可以正常的查询和导入新的数据。创建任务会自动处理当前的存量数据和所有新到达的增量数据，从而保持和Base表的数据一致性。 用户无需担心一致性问题 。  

Flag :

• 如上图：创建表时不指定模型类型时，默认的是按什么类型的模型创建？
• 物化视图支持增量更新，但明细的订单存在多次更新的场景，所以应该建立单一主键模型，搞不定聚合数据的正确性？

 

查询  

---

 物化视图创建完成后，用户的查询会根据规则自动匹配到最优的物化视图。

• 

 

如上图：有一张销售记录明细表，并且在这个明细表上创建了三张物化视图。一个存储了不同时间不同销售员的售卖量，一个存储了不同时间不同门店的销售量，以及每个销售员的总销售量。 当查询7月19日各个销售员都买了多少钱时，我们 可以匹配mv_1物化视图， 直接对mv_1的数据进行查询。

 

自动匹配过程 

---

  

自动匹配的过程分为两个步骤：

• 对候选集合进行一个过滤。只要是查询的结果能从物化视图数据计算（取部分行，部分列，或部分行列的聚合）出都可以留在候选集中，过滤完成后候选集合大小 >= 1
• 从候选集合中根据聚合程度，索引等条件选出一个最优的也就是查询花费最少物化视图。

 

过滤候选集执行过程 

---

 

• 

候选集过滤目前分为4层，每一层过滤后去除不满足条件的物化视图。（例如： 查询7月19日各个销售员都买了多少钱为例）

• 首先一开始候选集中包括所有的物化视图以及Base表共4个。
• 第一层 过滤先判断查询Where中的谓词涉及到的数据是否能从物化视图中得到，也就是销售时间列是否在表中存在。由于第三个物化视图中根本不存在销售时间列。所以在这一层过滤中，mv_3就被淘汰了。
• 第二层是过滤查询的分组列是否为候选集的分组列的子集，也就是 销售员id 是否为表中分组列的子集。由于第二个物化视图中的分组列并不涉及 销售员id 。所以在这一层过滤中，mv_2也被淘汰了。
• 第三层 过滤是看查询的聚合列是否为候选集中聚合列的子集，也就是对销售额求和是否能从候选集的表中聚合得出。这里Base表和物化视图表均满足标准。
• 最后一层 是过滤看查询需要的列是否存在于候选集合的列中。由于候选集合中的表均满足标准，所以最终候选集合中的表为 销售明细表 ，以及 mv_1 这两张。

 

选择最优 

---

 候选集过滤完后输出一个集合，这个集合中的所有表都能满足查询的需求，但每张表的查询效率都不同。

这时候就需要在这个集合根据前缀索引是否能匹配到，以及聚合程度的高低来选出一个最优的物化视图。

• 

例如： 从 表结构中可以看出，Base表的销售日期列是一个非排序列，而物化视图表的日期是一个排序列，同时聚合程度上mv_1表明显比Base表高，所以最后选择出mv_1作为该查询的最优匹配。  

 

查询改写 

---

 最后再根据选择出的最优解，改写查询

• 

 

 例如： 刚才的查询选中mv_1后，将查询改写为从mv_1中读取数据，过滤出日志为7月19日的mv_1中的数据然后返回即可。 

 

 特殊改写 

---

 有些情况下的查询改写还会涉及到查询中的聚合函数的改写。 比如业务方经常会用到Count、Distinct对PV、UV进行计算。

• 

 

例如上图： 广告点 击明细记录表中存放 哪个用户点击了什么广告，从什么渠道点击的，以及点击的时间。 并且在这个Base表基础上构建了一个物化视图表，存储了不同广告不同渠道的用户Bitmap值。
由于bitmap_union这种聚合方式本身会对相同的用户 user_id 进行一个去重聚合。当用户查询广告在Web端的UV的时候，就可以匹配到这个物化视图。 匹配到这个物化视图表后就需要对查询进行改写，将之前的对用户id求 count(distinct) 改为对物化视图中bitmap_union列求count。
所以最后查询取物化视图的第一和第三行求B itmap聚合中有几个值。

 

物化视图聚合函数 

---

 

 

未包含及部分函数解释 

• PERCENTILE_APPROX： 统计学中常用的分位数函数
• HLL_UNION： 适用于快速进行非精确去重计算。对明细数据使用HLL_UNION聚合，需要先调用hll_hash函数，对原数据进行转换 

 

查看物化视图：

1、查看该database下的所有物化视图

• SHOW MATERIALIZED VIEW [IN|FROM db_name]

 2、查看指定物化视图的表结构

• DESC table_name all

3、查看物化视图处理进度

• SHOW ALTER MATERIALIZED VIEW FROM db_name

4、取消正在创建的物化视图

• CANCEL ALTER MATERIALIZED VIEW FROM db_name.table_name

5、如何确定查询命中了哪个物化视图 

 

 

 

参考资料

---

• https://www.kancloud.cn/dorisdb/dorisdb/2142137
• https://www.slidestalk.com/DolphinScheduler/Doris_Core_Features_Introduction_Pre_Aggregated_Engine_and_Materialized_View
• https://ai.baidu.com/forum/topic/show/987485

标签：候选,聚合,视图,查询,mv,物化,Doris
来源： https://www.cnblogs.com/tgzhu/p/14759953.html