1.1.2 Doris架构重组

Doris变化和升级比较大的版本是Doris 3，这也是开发时间跨度比较长的一个版本，重大的改进主要有以下几点。

❑Doris 3在架构上引入了ZooKeeper来存储元数据，解耦组件，实现了系统无单点故障，提高了系统稳定性。在Doris 3的组件中，DT（Data Transfer）模块负责数据导入，DS（Data Searcher）模块负责数据查询，DM（Data Master）模块负责集群元数据管理。数据存储在分布式Key-Value引擎中。数据导入和数据查询时，Doris 3直接读取存储在ZooKeeper中的元数据，不再依赖元数据管理组件提供的服务。

❑Doris 3在数据分布方面引入了分区。数据会按照时间进行分区（比如天分区、月分区）。在同一个分区里，数据会根据用户ID进行分布。这样，同一个用户的数据会落在不同的分区，而在进行数据查询时，多台机器能同时处理一个用户的数据，实现了单用户数据分布式计算。

❑为了实现数据的多维分析，Doris 3采用了MySQL Storage Handler方案。通过这种方案，Doris 3伪装成一个MySQL的存储后端，类似于MyISAM、InnoDB。这样既能利用MySQL对SQL的支持，也能利用Doris 3对大量数据的快速处理；同时又引入了MySQL的BKA（Batched Key Access，批量索引访问）算法和MRR（Multi-Range Read，多范围读取优化）特性，尽量将计算下推给Doris 3来完成，从而减轻MySQL的计算压力，避免了单点故障。

❑Doris 3重构了存储引擎。在多维报表分析场景中，原来底层通用Key-Value系统的弊端也逐渐显露。由于Key-Value系统只能够读取完整的Key和完整的Value，而报表分析系统中的大部分查询并不需要读取所有列，这样会带来不必要的I/O开销。同时，Key-Value系统无法感知数据内容，只能使用通用压缩算法，导致数据压缩效率低，读写性能差。为了在底层存储引擎上有所突破，百度启动了OLAP Engine项目，参考Google Mesa系统重构了存储引擎。

新的存储引擎主要有以下特点。

❑引擎端原生就支持Schema，并且所有的列分为Key列、Value列，能够和上层的业务模型相对应，查询部分列时，无须加载全部列，减少不必要的I/O开销。

❑独特的数据模型。Value列支持聚合操作，包括SUM、MIN、MAX等。在Key列相同的情况下，Value列能够按照聚合操作类型完成对应的聚合操作。而引擎存储数据类似于LSM树，这样在后台执行聚合操作时，就能够将相同Key的Value字段按照对应的聚合操作类型进行聚合，无须在外部增加数据合并作业。

❑数据批量导入，批量生效。每个批次的导入都会生成一个增量文件，并且会有一个版本号。在查询任务中，只需要在最开始的时候确定读取哪个文件，这样就会只读取生效版本的数据，不会读取没有生效版本的数据，更不会浪费CPU资源进行版本号的过滤。

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

另外，Doris 3在日常运维，包括表结构变更、集群扩容、集群缩容等方面，都做了针对性的设计，实现了自动化操作。