Doris简介

1. Doris介绍

Apache Doris最早诞生于2008年，最初只为解决百度凤巢报表的专用系统。在08年那个时候数据存储和计算成熟的开源产品非常少，Hbase的导入性能只有大约2000条/秒，在这种不能满足业务的背景下，Doris诞生了，并且跟随百度凤巢系统一起正式上线。
Apache Doris是一个现代化的MPP分析性数据库产品。仅需要亚秒级响应时间即可获得查询结果，有效地支持实时数据分析。Apache Doris可以满足多种数据分析需求，例如固定历史报表，实时数据分析。

2. Doris架构

Apache Doris的整体架构如下图所示：

2.1 Frontend(FE)

主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作。

• Leader和Follower: 主要是用来达到元数据的高可用，保证单节点宕机的情况下，元数据能够实时地在线恢复，而不影响整个服务。
• Observer：不参与选举，用来扩展查询节点,同时起到元数据备份的作用。observer不参与任何的写入, 只参与读取。

2.2 Backend(BE)

主要负责数据存储、查询计划的执行。数据的可靠性由BE保证，BE会对整个数据存储多副本或者是三副本。副本数可根据需求动态调整。

2.3 Broker

Broker是Doris集群中一种可选进程，主要用于支持Doris读写远端存储上的文件和目录，如HDFS、BOS和AFS等。

2.4 MySQL Client

客户端使用MySQL协议，高度兼容MySQL语法，支持标准SQL，用户可以通过各类客户端工具来访问Apache Doris。

3. Doris功能特点

3.1 支持标准SQL接口

在使用接口方面，Doris采用MYSOL协议，高度兼容MYSOL语法，支持标准SOL。用户可以通过各类客户端工具来访问Doris，并支持与BI工具的无缝对接。

3.2 列式存储引擎

在存储引擎方面，Doris采用列式存储，按列进行数据的编码压缩和读取，能够实现极高的压缩比，同时减少大量非相关数据的扫描，从而更加有效地利用I0和CPU资源。

3.3 支持丰富的索引结构

Doris支持比较丰富的索引结构，减少数据的扫描

3.4 支持多种存储模型

在存储模型方面，Doris支持多种存储模型，对不同的场景做了有针对性的优化。

3.5 支持物化视图

Doris支持强一致的物化视图，即物化视图的更新和选择都在系统内自动进行，不需要用户手动选择，从而大幅减少了物化视图的维护代价。

3.6 MPP架构设计

在查询引擎方面，Doris采用MPP的模型，节点间和节点内都并行执行，也支持多个大表的分布式Shuffle Join，从而能够更好应对复杂查询。

3.7 支持向量化查询引擎

在计算机系统的体系结构中，存储系统具有层级结构，典型服务器计算机的存储层次结构如图所示：
由上图可知，从内存读取数据速度是从磁盘读取数据速度的1000倍，从CPU缓存中读取数据的速度最快是从内存中读取数据的速度的100倍，从CPU寄存器中读取数据的速度为 300ps(1000ps=1ns)，是CPU缓存的3倍还多。从寄存器中访问数据的速度，是从内存访问数据速度的300倍，是从磁盘中访问数据速度的30万倍。
从CPU寄存器中访问数据对程序的性能提升意义非凡。向量化执行就是在寄存器层面操作数据，为上层应用程序的性能带来了指数级的提升。
为了实现向量化执行，需要利用CPU的SIMD指令。SIMD的全称是single instruction multipledata，即用单条指令操作多条数据，通过数据并行以提高性能的一种实现方式(其他的还有指令级并行和线程级并行)，它的原理是在CPU寄存器层面实现数据的并行操作。
Doris查询引擎是向量化的査询引擎，所有的内存结构能够按照列式布局，达到大幅减少虚函数调用，提升缓存命中率，高效利用SIMD指令的效果。在宽表聚合场景下其性能是非向量化引擎的5~10倍。

3.8 动态调整执行计划

Doris采用了Adaptive Query Execution技术，可以根据Runtime Statistics动态调整执行计划，如通过Runtime Filter技术在运行时生成Filter推到Probe侧，并且能够将Filter自动穿透到Probe侧最底层的Scan节点，从而大幅减少Probe的数据量，加速Join性能。Doris的Runtime Filter支持I/Min/Max/Bloom Filter.

3.9 采用CBO和RBO查询优化器

数据库SOL语句执行流程如图所示：
在SQL优化器中最重要的一个组件是査询优化器(query optimizer)，在海量数据分析中一条SOL生成的执行计划搜索空间非常庞大，查询优化器就是对执行计划空间进行裁剪，减少搜索空间的代价。查询优化器对于SOL的执行非常重要，不管是关系型数据库系统 Oracle、MySOL，还是大数据领域中的Hive、SparkSQL、Flink SQL，都会有一个查询优化器进行SOL执行计划优化。
有的数据库系统会采用自研的查询优化器，有的则会采用开源的查询优化器插件。如Oracle数据库的査询优化器是Oracle公司自研的一个核心组件，负责解析SOL，其目的是按照一定的原则来获取目标SQL在当前情形下执行的最高效执行路径;而Apache Calcite则是一个优秀的开源查询优化器插件。
查询优化器主要解决的是多个连接操作的复杂查询优化，负责生成、制订SQL的执行计划，目前主要有两种查询优化器:基于规则的优化器(rule-based optimizer，RBO)与基于代价的优化器下面分别大致了解RBO和CBO(cost-based optimizer,CBO)的原理。

1. RBO
   RBO按照硬编码在数据库中的一系列规则来决定SQL的执行计划，只要我们按照这套规则来写SOL语句，无论表中的数据分布和数据量如何都不会影响这套规则下的执行计划。以Oracle数据库为例，RBO根据Oracle指定的优先顺序规则，对指定的表进行执行计划的选择，如在规则中索引的优先级大于全表扫描。
   通过以上内容可以了解到RBO对数据不敏感，但在实际的场景中，数据的量级以及数据的分布会严重影响SOL执行性能，故这也是RBO的缺点所在，RBO生成的执行计划往往不是最优的。
2. CBO CBO根据优化规则对关系表达式进行转换，按照表、索引、列等信息生成多个执行计划，然后根据统计信息(statistics)和代价模型(cost model)计算各种可能执行计划的代价，即cost，从中选用代价最小的执行方案，作为实际运行方案。
   CBO依赖数据库对象的统计信息，这些信息包括SQL执行路径的IO、网络开销、CPU使用情况等，目前各大数据库和大数据的计算引擎都倾向于使用CBO，或者结合使用RBO和CBO(可以基于两者选择最优的执行计划，提高效率)。例如Oracle从10g版本开始彻底放弃了 RBO，MySQL使用的也是CBO:在大数据领域中，Hive在0.14版本引入CBO，Spark计算框架使用的是Catalyst查询引擎(基于Scala开发)，这种査询引擎支持RBO和CBO，Flink计算框架使用的是Calcite查询弓擎(开源)，这种查询引擎也是同时支持RBO 和CBO。
   同样，Doris在优化器方面也是使用CBO和RBO结合的优化策略，RBO支持常量折叠、子查询改写、谓词下推等，CBO支持Join Reorder。目前CBO还在持续优化，主要集中在更加精准的统计信息收集和推导，以及代价模型预估等方面。

3. Doris使用场景

1. 报表分析：比如实时看板，面向用户或者客户的高并发报表分析，如面向网站主的站点分析、面向广告主的广告报表分析。
2. 即席查询：自助分析，查询模式不固定，要求较高的吞吐量。
3. 统一湖仓构建：利用一个平台满足统一的数仓建设需求，简化烦琐的大数据软件栈。
4. 数据湖联邦查询：Doris通过外部表的方式联邦分析位于Hive、Iceberg、Hudi中的数据，可以避免数据复制，使查询性能大幅提升。

4. Doris2.X新特性

4.1 全新查询优化器Cascades替代Volcano(火山)优化器

全新查询优化器采取了更先进的Cascades框架、使用了更丰富的统计信息、实现了更智能化的自适应调优，在绝大多数场景无需任何调优和SQL改写即可实现极致的查询性能，同时对复杂SQL支持得更加完备、可完整支持TPC-DS全部99个SQL。

4.2 倒排索引支持

在2.0版本中我们对现有的索引结构进行了丰富，引入了倒排索引来应对多维度快速检索的需求，在关键字模糊查询、等值查询和范围查询等场景中均取得了显著的查询性能和并发能力提升。

4.3 行列混合存储以及行级Cache

Doris1.X只支持列式存储，明细查询数百列宽表上将会放大随机读取IO，并且查询优化器和执行引擎对于此类简单 SQL的解析、分发也将带来不必要的额外开销，负责SQL解析的FE模块往往会成为限制并发的瓶颈，因此需要更高效简洁的执行方式。Doris2.X版本引入了全新的行列混合存储以及行级Cache，使得单次读取整行数据时效率更高、大大减少磁盘访问次数，同时引入了点查询短路径优化、跳过执行引擎并直接使用快速高效的读路径来检索所需的数据，并引入了预处理语句复用执行SQL解析来减少FE开销。

4.4 自适应的并行执行模型

Doris2.X版本使用Pipeline执行模型作为查询执行引擎，保证了多个混合分析负载的执行效率以及查询的稳定性。在Pipeline执行引擎中，查询的执行是由数据来驱动控制流变化的，各个查询执行过程之中的阻塞算子被拆分成不同Pipeline，各个Pipeline能否获取执行线程调度执行取决于前置数据是否就绪，实现了阻塞操作的异步化、可以更加灵活地管理系统资源，同时减少了线程频繁创建和销毁带来的开销，并提升了Doris对于CPU的利用效率。

4.5 提供原生的半结构化数据支持

在Doris 2.X版本中，提供了原生的半结构化数据支持，在已有的JSON、Array基础之上增加了复杂类型Map支持。

4.6 完善湖仓一体

Doris 2.X版本支持了Hudi Copy-on-Write表的Snapshot Query以及Merge-on-Read表的Read Optimized Query，截止目前已经支持了Hive、Hudi、Iceberg、Paimon、MaxCompute、Elasticsearch、Trino、ClickHouse等数十种数据源，几乎支持了所有开放湖仓格式和Metastore。同时还支持通过Apache Range对Hive Catalog进行鉴权，可以无缝对接用户现有的权限系统。同时还支持可扩展的鉴权插件，为任意 Catalog实现自定义的鉴权方式。

4.7 完善的多租户资源隔离

Doris在过去版本中推出了资源组(Resource Group)的硬隔离方案，通过对同一个集群内部的BE打上标签，标签相同的BE组成一个资源组。在2.X版本中增加了Workload Group资源软限制的方案，通过对Workload进行分组管理，以保证内存和CPU资源的灵活调配和管控。

4.8 优化数据高频写入

1. 2.0版本中引入了Vertical Compaction以及Segment Compaction，用以彻底解决Compaction内存问题以及写入过程中的Segment文件过多问题，降低小文件合并和写放大问题以及随之而来的磁盘I/O和CPU资源开销。
2. 在2.0版本中我们基于Merge-on-Write实现了Unique Key主键模型的复杂条件的数据更新和删除

4. Doris和ClickHouse对比

ClickHouse是俄罗斯的搜索公司Yandex开源的MPP架构的分析引擎，号称比事务数据库快100-1000倍，最大的特色是高性能的向量化执行引擎，而且功能丰富、可靠性高。

4.1 Doris优势

使用更简单，如建表更简单，SQL标准支持更好, Join性能更好，导数功能更强大
运维更简单，如灵活的扩缩容能力，故障节点自动恢复，社区提供的支持更好
分布式更强，支持事务和幂等性导数，物化视图自动聚合，查询自动路由，全面元数据管理

4.2 ClickHouse优势

性能更佳，导入性能和单表查询性能更好，同时可靠性更好
功能丰富，非常多的表引擎，更多类型和函数支持，更好的聚合函数以及庞大的优化参数选项
集群管理工具更多，更好多租户和配额管理，灵活的集群管理，方便的集群间迁移工具

4.3 两者之间选择

业务场景复杂数据规模巨大，希望投入研发力量做定制开发，选ClickHouse
希望一站式的分析解决方案，少量投入研发资源，选择Doris