doris

doris

Partition & Tablet

• Partition
  逻辑分区往往根据业务通过用户指定的分区列进行范围划分，可以视为逻辑上最小的管理单元，好比导入和删除操作就是partition。

  • list partition
    

    • 比较规则：前闭后开

    • 多列分区：分配数据规则，先判断第一个字段然后判断第二个字段，如果前一个数据行的分区字段落在分区临界值则比较后一个字段来判断数据最终落在那个分区。
      eg: 2022-02-01,100的数据如果按月份落库就会落在二月份中，但是如果按照上文判定规则比较第二个字段，落在了一月份的数据中，

      

  • range partition
    

• Tablet
  分区内，对用户指定的分桶列进行hash后分桶，每个分桶就是一个数据分片，也是数据划分的最小物理和逻辑单元。数据的移动、复制等操作就是针对tablet。
• 单分区&复合分区
  • 单分区
    只做hash分布- 只分桶。
  • 复合分区
    第一级：Partition 分区。 当前只支持整型和时间类型。
    第二级：Distribution 分桶。
• 动态分区
  • 在0.12版本之后新加入的功能，只支持单分区列的range partition。
  • 可建表指定，也可以alter table 指定。
  • 需要参数指定开启。
  • 支持ttl
  • 动态分区和静态分区可以相互转换，但同一时间只可以拥有一种分区状态。

聚合类型

• 类型分类
  min max sum replace
• 列的分类
  维度列、指标列
• 引擎分类
  OLAP（默认）、Mysql、Hive、Broker

数据模型

• Aggregate
  • 优势：支持min max sum replace，设计表时分为维度列和指标列。
  • 劣势：count（*） 会非常慢，优化建议使用固定sum指标列值为1，逐条累计即可。设计好的聚合类型，二次计算局限性很大，好比金额列你进行了sum操作，后续想要统计cost列的最小值，只能从明细表中统计很慢，这就说明了在设计之初，聚合模型定义的重要性。
  • 会发生聚合的操作
    • 导入
    • Compaction（合并）
    • 查询
• Uniq
  设计表时指定 uniq key 来约束唯一插入。
• Duplicate
  数据明细设计表类型，插入的数据都保留。

Rollup

从base表中二次聚合而来，并且在物理上是独立存储的。

• 获得更粗粒度的聚合结果。

eg: aggregate key: id name age ;score(sum),

默认为group by id name age => sum(score)

如果指定了rollup，我们还可以生成如下聚合的结果:

alter table t_name add rollup roolupname (keys,natures)

rollup(id,name,score):group by id name => sum(score)

rollup(id,score):group by id => sum(score)

使用的时候根据聚合列的聚合类型使用即可:select id,sum(score) from table group by id 就会在之前聚合模型表的基础上使用rollup机制生成新的聚合结果，该统计是否使用了rollup可以使用explain来查看。

• 调整前缀索引

如果在Duplicate明细表中，对未使用到前缀索引特性的key指定了rollup，建立rollup表（源码中命名为物化索引 ），则会使得指定查询可以使用优化后的前缀索引了。

物化视图

• 持久化重复经常使用的相同子查询结果
• Doris自动维护物化视图的数据，无论新的导入或者删除操作都能保证和物化视图表的数据一致性。
• 查询时，会从base表中分析匹配到最优物化视图。
• 物化视图 vs rollup
  • rollup不能对Duplicate 明细模型的base表进行预聚合。
  • 物化视图支持更丰富的聚合函数。
  • rollup支持的，视图都支持，视图算是rollup的一个超集。

查询优化

统计去重类的聚合会使用BitMap与HyperLogLog进行优化。

设置参数

• 查询配置

  show variables like '%exec_mem_limit%'
  

• 更改配置

  # 当前session 生效
  set exec_mem_limit = 8987988878;
  # 全局永久生效
  set global exec_mem_limit = 8987988878;
  

BroadCast/Shuffle Join

属于join优化，在进行多表join时，会先尝试过滤判断join的各表中是不是存在小表，小表会被广播到各个大表所在的节点上，形成一个内存hash表，然后流式读出大表的数据进行Hash Join（此种join为 BroadCast Join），但是小表如果在其能拿到的内存范围内无法加入到hash内存表中，就会造成内存超限，这时doris会自动切换至Shuffle Join，即将小表和大表的都按照Join的key进行hash，然后进行分布式join，这个对内存的消耗就会分摊到集群的所有计算节点上。

Colocation Join

数据join查询本地化，将拥有一组相同Colocation Group Schema的Table组成一个Colocation Group ，就会保证这些关联表的数据分片落在同一个BE节点上。这样就能保证当相关表进行join时，数据本地化拉取，提升查询效率。

具体实现：在建表时，在properties属性中使用 "colocate_with" = "group name" 指定 colocate group 来约束相关联的表在同一组实现数据本地化拉起。指定的组名没有则创建，有就会加入。移除组属性使用alter table t_name set ("colocate_with" = "") 即可。