Apache Doris 极速1.0版本解析与未来规划 - 网站源码_资源分享

编者按：此次撷取的主轴是Apache Doris全速1.0版的导出与今后的总体规划。

那时的撷取主要紧紧围绕上面几各方面文本进行：

Apach Doris优点参阅Apache Doris1.0版导出Apache Doris今后总体规划Apache Doris开放源码街道社区

具体来说如是说下Apache Doris，右图为Apache Doris官方网站上的两张图，能窥见Doris在整座大统计数据数据结构设计中的话语权。

从下游TP控制系统统计数据数据、业务埋点统计数据数据、web端笔记等透过格式化/流处置控制系统，历经研磨之后储存到doris中，doris能间接对内提供更多查阅服务项目，包括动态液晶电视、布季夫财务报表、网络流量统计数据、自助式查阅、使用者肖像等。

与此同时doris作为暗含储存的统计数据应用服务项目，能透过doris提供更多的connector（spark, flink等）加载doris中统计数据数据和其它大统计数据数据系统中的统计数据数据进行联邦政府查阅，来防止统计数据数据行尸的情况。

因此，doris另一方面也有完整的MPP查阅层，他们能透过外貌的形式来对其它的统计数据管理工具进行统计数据数据挖掘，比如说能透过ODBC协定来相连全力支持所有ODBC的统计数据资料库mysql, oracle, sql Server等，与此同时也对ES进行了广度的集成，为ES提供更多了一个分布式控制系统的sql查阅层，能化解ES在sql查阅各方面的严重不足，也能借助ES在中文信息、检索上的一种高效率的处理操控性。

这就是目前Doris在整座大统计数据数据处置中的功能定位。

接下去从doris的机能起程，如是说呵呵为何优先选择doris以及doris有这些优点。

01 Apache Doris 优点参阅

这里他们将对doris的6个机能逐个进行如是说。

1. Becoming构架

Becoming构架，是他们在结构设计之初为使用者提供更多的一个优势和便利。从上图能窥见Doris的构架是非常简单的。

整座构架主要有两类角色：FE（Frontend）和BE(Backend)。其中，FE主要负责元统计数据数据的储存，使用者请求的接入，以及查阅计划的导出。BE则主要负责查阅计划的执行，统计数据数据的储存。

除了这两个进程之外，Doris不再依赖任何第三方服务项目。也就是说他们的部署和运维相对而言都是比较简单的。与此同时在上层也提供更多了mysql协定的兼容。全力支持标准的sql语法方便使用者零成本地接入到控制系统中来。

2.高效率自运维

上图能看到，使用者的统计数据数据能透过使用者建表时定义的分区分桶来进行统计数据数据切片，最终使用者的统计数据数据是以分片的形式储存在整座分布式控制系统集群中的各个节点中，因此节点之间的分片能自动均衡和修复，比如说当前有3个BE节点，当他们增加第四个BE节点的时候，控制系统会自动按分片粒度将统计数据数据均匀分布在新增服务器上来保证多个服务项目器的负载是接近的和相同的，与此同时在出现某一个统计数据数据的副本损坏的时候，doris内部也会在短时间内将副本补齐到一个健康状态来保证副本的可用性和可靠性。整座过程不需要人工介入，与此同时整座过程也不会影响到使用者的查阅，导入等机能。

所以在容灾和自运维各方面相对便利。

3. 高并发场景全力支持

他们知道一个olap领域的统计数据资料库更偏向于高吞吐、复杂场景下的快速处置，doris除了这种复杂的AD-hoc查阅，与此同时也能提供更多高并发的点查，在单机情况下能全力支持1000QPS的请求全力支持，因此是可横向扩展的。主要得益于2个各方面：

①分区裁剪

他们能透过查阅优化器，以及统计数据数据的分区分桶的形式，将查阅条件功能定位到具体分区及分桶中，这样一个查阅所占用的资源将足够小，因为最终只是功能定位到某一台机器的某一个片上，这样整座集群全力支持高并发的请求就能变多。

②统计数据数据Cache

在doris中分为不同种类的统计数据数据Cache，比如说最基础的sql高并发查阅场景下的一些特色。

4. MPP执行引擎

Doris中是有一个完整的MPP执行引擎的。从上图能看到，他们的查阅优化器对一个sql生成树状的逻辑计划以后，根据统计数据数据分布及优化规则拆分为物理执行计划。具体来说，一个物理执行计划能在集群中多个BE节点与此同时执行，与此同时在一个BE内部他们还会把查阅计划的分片进一步拆分成多个instance，以保证在单个节点内部再一次进行并行，达到单机多核CPU的优点。

与此同时他们也引用到了Exchange节点，该节点使得MPP的完整性得到了提升，保证统计数据数据透过shuffle的形式重新分布在更多的节点上，而不仅仅只局限于统计数据数据储存所在的计算资源。

5.明细与聚合统计数据数据

doris本身是全力支持预聚合的语义的。如果同学们使用过kylin、druid就能知道它们会将统计数据数据预先计算好。在doris中，使用者能将明细的统计数据数据间接储存在base表，doris全力支持在明细表上优先选择任意维度列和指标列生成物化视图，也就是上图中的上卷表，因此doris能保证生成的所有的物化视图和明细表中的统计数据数据是强一致的，也就是说透过导入的事务性保证夺标之前统计数据数据一致性，这样使用者也不需要担心基础表统计数据数据更新，上卷表还没更新导致统计数据数据查阅的不一致性，这在doris中是不存在的。

对于使用者来说，所有查阅都是针对base表而言，查阅优化器会智能地分析查阅模式自动匹配到对应的物化视图上来进行统计数据数据的返回，一各方面透过统计数据数据一致性，其次是查阅自动路由，来保证在一个控制系统中进行明细统计数据数据和聚合统计数据数据的统一处置和分析，也降低了运维压力，比如说是否感知物化视图、表更新等问题。

6. 便携统计数据数据接入

从图中能窥见doris全力支持了非常多的统计数据数据导入形式，用户统计数据数据不管是在对象储存、kafka储存，还是流格式化控制系统中，他们都能透过一个sql命令将统计数据数据灌入倒doris中，比如说他们全力支持kafka不丢不重进行一键订阅，与此同时也提供更多了flink/spark connector能接入更丰富的统计数据管理工具写入到doris中，也能透过broker load进行大批量的一次性的统计数据数据导入，也能透过stream load进行近似流式的导入。

以上透过简单的6点如是说，概括了doris的一些优点，接下去他们进入那时的重点，对doris在前段时间刚刚透过的1.0版的导出。

—

02 Apache Doris1.0版导出

1.0版也是Doris进入孵化器以来第一个1位大版。在该版中，主要提供更多三大特点：全速、稳定、多源。

1. 全速：向量化引擎

第一点就是全速，其本质就是他们在1.0版中引进了全新的向量化引擎。向量化引擎在业界是有很多应用的，包括前几年比较火的clickhouse控制系统，是把整座向量化技术带到了工业生产领域，让大家在实际生产环境中去应用向量化技术来得到收益，所以他们在结构设计向量化引擎中也借鉴了非常多的clickhouse的优秀结构设计，来保证他们的查阅操控性得到质的提升。向量化引擎他们从5部分来为大家进行如是说。

①列式内存布局

能看到在原来的行存计算模型中，统计数据数据在内存中的表现形式是行的表现形式，在整座向量化执行引擎中，把它改成了列的表现形式，后面他们会讲到它的优势。

②向量化计算框架

与此同时在列式的表现形式中，他们还改进了向量化计算框架，能看到当他们计算a, b两列中b列的abs函数时会在原有的block基础上，增加一个结果列，将b列的填充结果增加到结果列中，然后再进行b列的结果删除。

③Cache亲和度

列式的布局和向量化计算框架，提供更多了以下好处，第一个是cache亲和度，在行存计算模式中，当他们计算某一列时，需要将整行加载到内存中，因此透过offset和偏移去找到对应的列，然后再将那一列的值取出进行计算，这样能窥见，当他们加载整行统计数据数据时，其实只用到了某一列，这对cache亲和度是不好的，也就是一个cache行中有效占比比较低，而在列式布局中，是一次性加载这一列，这样cache亲和度有明显提升。他们能在一个cache行中去缓存更多有效统计数据数据，如果熟悉控制系统的同学他们应该知道不同的cache级别访存的延迟会有指数级的提升，所以透过cache亲和度提升了控制系统的计算效率。

④虚函数调用

在行储存中，计算某一列值需要进行大量的switch case或者虚函数的调用，他们需要在动态运行时去判断该列的类型，根据不同的类型去调用具体实函数的实现。所以虚函数是需要在查虚函数表会严重打破多级流水，整座CPU的分支命中率和预测率都会下降，从而影响执行效率。

所以在向量化引擎中，他们引用了大量的静态模板，使大量虚函数的调用变成了在编译期间静态的类型转换，这样能保证他们的优化器在编译期间间接编译出最优代码，其次能在运行期间减少分支错误的预测等问题，使效率得到进一步提升。

⑤SIMD指令

SIMD指令集分为两个部分，第一部分是C++的编译器，能自动的实现一些SIMD指令集的优化，比如说在上图例子中：for循环结构设计两个数组的计算，该两个数组在内存中是连续储存的，第二没有两个变量之间的数值依赖，其次for计算相对简单，那么编译器则会自动的做一些多指令集的优化，能看到在自动做了SIMD指令集优化后能得到3倍的一个操控性提升。他们不需要显式地调用SIMD指令集，而是透过改变一些编程习惯等让编译器自动帮他们做操控性的提升。

第二点是手动的SIMD指令集。在一些稍微复杂的函数下，编译器没有足够的智能帮他们做指令集优化的时候，他们能手动的调用SIMD指令来进行优化，比如说上图，两个字符串比较函数中，能透过手写SIMD指令集的形式来做改进。

以上就是对向量化引擎简单得如是说，如果大家感兴趣能去右图中的链接进行进一步的学习。

在最后，他们看呵呵使用向量化引擎的效果，其实在1.0版中他们的向量化引擎还处于一个实验阶段，它是一个完整的机能集，但还有很多优化点在持续的改进，在当前版中，具体来说他们能看到在SSD的Benchmark上，也就是在多表关联的查阅场景下，大部分查阅都有着一倍以上的操控性提升。

如果在单表查阅场景下，比如说笔记分析场景，或者大宽表分析场景下，能看到他们向量化引擎的提升是非常明显的，能达到10倍的操控性提升。所以在生产环境上，平均的观感体验能达到3-5倍的提升。当然这并不是他们最终的统计数据数据，他们也会在后续的1.1和1.2版中进行持续向量化优化，在后续版中会带来更多的向量化提升。这就是1.0版在全速各方面做的工作。

2. 稳定：内存可控

doris本身是一个MPP构架的执行引擎，整座执行过程是完全依赖于内存的，无论导入还是查阅，统计数据数据的cache都是占用内存开销的，所以它本质是对内存使用比较高的一个控制系统，在之前版使用过的同学可能会发现在一些高负载场景下经常会出现Out Of Memory的错误导致进程挂掉继而重启，所以内存控制在之前版是做的不好的。

在1.0版他们把它作为专项进行了改造，他们的目标是对OOM Say No！透过一系列技术方案来保证整座进程是在内存控制范围内的，防止出现OOM的现象。

他们透过mem Tracker树形结构来充分控制整座控制系统各个模块，各个任务之间内存的调用关系和控制，比如说在进程级别会有一个总的Process Tracker，在Process Tracker下会挂分模块的Tracker，例如针对查阅的Query Tracker，针对导入的Load Tracker，任务的Task Tracker和 Cache Tracker。如图中的Query Trackers，他们还会针对每一个查阅上的计划分片，或者说执行分片上进一步增加细粒度的tracker，比如说能增加聚合算子的内存占用，扫描算子的内存占用，这样能精细化到每个查阅中的算子使用，保证查阅内存可用。

其次每个mem tracker是挂在总的process tracker下的，所以所有的查阅也会受到总的内存的控制，具体实现细节实际是在把每个mem tracker在线程执行的时候挂载到Thread Local 的变量上，这样一个线程内所有控制系统申请都会通过Thread Local进行捕获，与此同时他们调用TcMallocHook的形式来去把所有new, delete这些申请给hook起来，不会遗失任何一个实际内存使用，这样带来的好处：

①可观测局部内存占用。在新的版中能精确的功能定位到内存具体是被查阅，还是导入还是被cache占用，透过可观测性来快速功能定位问题。

②严格监控实际内存申请，杜绝内存超限。透过hook形式严格将内存进行限制，因此不会有超限的问题。

3. 多源：大统计数据数据生态

第三部分是大统计数据数据生态，在1.0版他们也开放了对hive外貌，iceberg外貌的的查阅机能，本质是想化解使用者引用doris的时候，但是统计数据数据已经在其它储存控制系统中存放，这样在之前版中如果想使用外部统计数据管理工具，则需要导入doris才能使用，统计数据数据迁移成本高。

① 化解统计数据数据不迁移过程中能够加速原有控制系统的查阅加速能力。

② 逐步形成完善的湖仓一体生态。在1.0版中他们已经全力支持了hive 和 iceberg的统计数据管理工具，那么针对iceberg也全力支持自动同步hive外貌，hive表不需要两张张做映射建立，而只需要提供更多hive metedata地址则能实现自动同步，他们在后续版也会逐步完善doris的生态。

这就是doris在1.0大版中整座的更新，整座1.0版相对于0.15版街道社区有116位贡献者，贡献了大概663个commit,除了上述3点如是说的机能之外，还有非常多的机能和操控性提升，欢迎大家前往doris官方网站探索。

—

03 Apache Doris 今后总体规划

接下去简单如是说下Apache Doris在今后的总体规划。

1. 湖仓一体

虽然目前已经引入了hive 和 iceberg 的机能全力支持，但是相对来说机能较简单，在接下去的工作中，会引入Multi-Catalog机制，该机制类似于presto这种sql加速控制系统，能将多源的统计数据数据统一到catalog抽象，能保证更方便接入外部数据源。现在也是在联系街道社区同学开发hudi的全力支持。与此同时也会陆续引入merge on read的全力支持，目前能理解为都是在加载copy on read的表，透过引入merge on read能加载到统计数据数据湖动态更新的统计数据数据。

2. 存算分离

存算分离本质上引用的是越来越多的上云的需求。他们能透过低价的S3的储存，达到低成本的收益，其次根据云上的弹性扩容提供更多无状态的计算节点的横向扩容，透过低成本+弹性来满足存算分离的需求。他们也能根据共享统计数据数据来保证多个业务共享，但是透过独立的计算资源来计算。

3. 动态写入

oris现在还是一个近似微批的控制系统，需要去限制批次时间，这样使用者体验就会相对较差，在后续会尝试全力支持高并发动态写入场景。还有在面临一些订单场景，他们能UNIQUE key主键模型来近似达到统计数据数据更新的效果。unique key是一个merge on read 的模型，写入速度较快，但是查阅效率会差一些，后续他们会全力支持copy on write 的统计数据数据更新，来吸收一定的写的吞吐来提高查阅的能力。