首页  思维导图  详情

Doris

2022-04-07 13:20:25   0  举报





AI智能生成

doris知识点总结

Doris

作者其他创作

大纲/内容

OLAP Engine 特点

引擎端原生就支持 Schema，并且所有的列分为 Key 列、Value列

这样就能够跟上层的业务模型能够对应上，查询部分列时，无需加载全部列，减少不必要的 IO 开销。

独特的数据模型

Value 列支持聚合操作，包括 SUM、MIN、MAX 等。在 Key 列相同的情况下，Value 列就能够按照聚合操作类型完成对应的聚合操作。而引擎本身导入方式类似于 LSM Tree，这样在引擎后台进行 Merge 的同时，就能够将相同 Key 的数据中的 Value 字段按照对应的操作进行聚合。这样就无需外部再进行数据合并作业管理，将引擎层与业务层合并合二为一，省去不必要的 IO、CPU 开销。

数据批量导入，原子生效

对于每个批次的导入，都会有个 Delta 文件对应，并且会有个版本号。在查询的时候只是在初始化的时候来确定读取哪个文件，这样就只会读取生效版本的数据，而不会读取没有生效版本的数据，更不会浪费 CPU 来进行版本号比较过滤。

行列式存储

多行（比如1024行）数据存储在一个 Block 内，Block 内相同列的数据一同压缩存放，这样可以根据数据特征利用不同的压缩算法（比如对于时间字段使用 RLE 等）大幅提高数据压缩效率

REFER

http://doris.apache.org/master/zh-CN/getting-started/data-model-rollup.html#%E5%9F%BA%E6%9C%AC%E6%A6%82%E5%BF%B5

https://mp.weixin.qq.com/s/nrmtDMIJ9-AvgOVCgI8Zng

https://tech.meituan.com/2020/04/09/doris-in-meituan-waimai.html

https://zhuanlan.zhihu.com/p/257183139

https://baijiahao.baidu.com/s?id=1633669902039812353&wfr=spider&for=pc

百度doris历史

2008年

doris1

2009年

doris2

2010年

doris3

2012年

mysql+doris3 = OLAP引擎

2013年

Palo1上线

2014年

google 发表 Mesa：预聚合数据模型

2015年

Palo2上线

2016年

Yandex开源clickhouse

2017年

Palo开源 github

2018年

Apache Doris

refer

https://baijiahao.baidu.com/s?id=1633669902039812353&wfr=spider&for=pc

https://zhuanlan.zhihu.com/p/355312398

前缀索引

StarRocks

向量化执行引擎

https://blog.csdn.net/qq_39918081/article/details/113866669

向量化执行引擎本质上是一种批处理模型

高并发场景中，可以把大量的请求合并，改为调用批量接口

大数据下读取分布式文件系统时，如果要读取大量的小文件，可以将这些小文件打成tar包，或者批量一次打开100~500个文件

数据库插入数据时，修改单条插入为批量插入等

批处理减少了cpu的中断次数，可以更加合理的利用资源

在向量化执行引擎模型中，列式存储占据着天然的优势：

1、压缩能力的提升。同一列的数据类型相同，压缩比高。

2、IO总量小。压缩减少了一部分IO，另外投影操作时，只需要读取查询的字段。

3、支持对某一列进行向量计算

通常向量化执行引擎都是用在OLAP数仓类系统

而OLTP系统，由于使用行存，并且点查询居多，所以向量化执行的优势也很难体现出来。

两种向量化执行引擎的实现

方法一：仍使用火山模型，将一次一tuple的处理模式，修改为一次向上返回一组列存行值（例如：100-1000行）处理方式。

火山模式是从执行计划树的根节点开始向叶子节点递归调用，然后由叶子节点扫描节点，过滤出符合条件的tuple 给上层节点处理，AGG算子缓存中间结果。

右边列存执行引擎，执行逻辑基本上与左边行存执行引擎一致，但是每次扫描处理的是一组列数据集合。这样每次处理的数据变多，总体的调用次数变少，CPU的利用率得到了提高。

方法二：将整个模型改造成为层次型的执行模式，也称编译执行模型。

整个执行计划树从跟节点到叶子节点只需要调用一次。从叶子节点开始每一层都是执行完所有的操作之后，才向上返回结果

编译执行模型的缺点就是每一个节点都需要将数据进行缓存，在数据量比较大的情况下，内存可能放不下这些数据，需要写盘。

方法一的向量化执行是自上而下的批量拉取模型；方法二的编译执行是自低向上的推送模型。

原则上这两个模型是不相容的，二者只能取其一。但是也有人在尝试编译执行融合向量化：把查询树分解，部分用向量化方式，部分用编译执行方式。

https://zhuanlan.zhihu.com/p/344706733

离CPU越远访问越慢

向量化执行就是这种方式最典型的代表，这项寄存器硬件层面的特性，为上层的程序性能带来了指数级的提升。

向量化执行:简单理解为就是消除程序循环的优化。

列式存储

每列的数据存储在一起，可以认为这些数据是以数组的方式存储的，基于这样的特征，当该列数据需要进行某一同样操作，可以使用SIMD进一步提升计算效率，即便运算的机器上不支持SIMD, 也可以通过一个循环来高效完成对这个数据块各个值的计算。

SIMD (Single Instruction Multiple Data) 即单条指令操作多条数据——原理即在CPU 寄存器层面实现数据的并行操作
ClickHouse 目前使用SSE4.2 指令集实现向量化执行

前提条件

首先向量化执行引擎效率的发挥需要数据库能够提供列存表的支持。对于传统的行存表来说，谈向量化执行是不可能的。通常向量化执行引擎都是用在OLAP数仓类系统，因为通常分析型系统通常都是数据处理密集型负载，基本上都是采用顺序方式来访问表中大部分的数据，然后进行计算，最后将计算结果输出给终端用户。对于典型的OLTP点查询，这种类型的查询执行，使用行存表反而比列存表更好

向量化执行引擎的优势

向量化执行引擎可以减少节点间的调度，提高CPU的利用率

因为列存数据，同一列的数据放在一起，导致向量化执行引擎在执行的时候拥有了更多的机会能够利用的当前硬件与编译的新优化特征

因为列存数据存储将同类型的类似数据放在一起使得压缩比能够达到更高，这样可以拉近一些磁盘IO能力与计算能力的差距

需要注意的问题

通信效率问题

当前比较主流的OLAP类型的数据库架构，通常首选是MPP架构的数据库，因为MPP架构上是share nothing架构的，所以它的集群各执行节点是有通信需要的，通信效率的高低也是决定了查询执行效率。另外就是大集群情况下，如果使用tcp方式连接，连接数会受限。

数据读写争抢问题

这个问题本身不是向量化执行引擎的，而是列存带来的，因为列存储表每一列单独存储为一个文件，这样在写盘的时候有优化与没有优化的差距还是非常明显的。

列存数据过滤效率问题

列存数据过滤率问题，这个问题是源于，列存数据中的一个处理单元是由连续的N个值放在一起组成的一个Col（数组），然后再由多个Col的数组组成了一个处理单元。在进行过滤的时候如何能够更加紧凑地放置数据是需要我们考虑列存在过滤掉效率和存放之间如何优化的问题

表达式计算问题（LLVM）