四、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使用 


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

  • 四、Doris物化视图

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

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

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

说明注意:

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

 

创建物化视图 


 四、Doris物化视图

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

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

Flag :

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

 

查询  


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

  • 四、Doris物化视图

 

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

 

自动匹配过程 


 四、Doris物化视图 

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

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

 

过滤候选集执行过程 


 

  • 四、Doris物化视图

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

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

 

选择最优 


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

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

  • 四、Doris物化视图

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

 

查询改写 


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

  • 四、Doris物化视图

 

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

 

 特殊改写 


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

  • 四、Doris物化视图

 

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

 

物化视图聚合函数 


 四、Doris物化视图

 

未包含及部分函数解释 

  • 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、如何确定查询命中了哪个物化视图 

 

 

 

参考资料


上一篇:爬取豆瓣电影Top250和数据分析


下一篇:10g物理standby主备switchover方式切换详述