使用场景:
在实际的业务场景中,通常存在两种场景并存的分析需求:对固定维度的聚合分析 和 对原始明细数据任意维度的分析。
例如,在销售场景中,每条订单数据包含这几个维度信息(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