Doris概述

数据源经过各种数据集成和加工处理后，通常会入库到实时数仓Doris和离线湖仓（Hive、Iceberg和Hudi中），如下图所示。

Apache Doris被广泛应用在以下场景中。

• 报表分析

  • 实时看板（Dashboards）。

  • 面向企业内部分析师和管理者的报表。

  • 面向高并发报表分析（Customer Facing Analytics）。比如面向网站主的站点分析、面向广告主的广告报表，并发通常要求成千上万的QPS，查询延时要求毫秒级响应。

• 即席查询（Ad-hoc Query）：面向分析师的自助分析，查询模式不固定，要求较高的吞吐。

• 统一数仓构建：一个平台满足统一的数据仓库建设需求，简化繁琐的大数据软件栈。基于Doris构建的统一数仓，替换了原来由Spark、Hive、Kudu、Hbase、Phoenix组成的旧架构，架构大大简化。

• 数据湖联邦查询：通过外表的方式联邦分析位于Hive、Iceberg、Hudi中的数据，在避免数据拷贝的前提下，查询性能大幅提升。

Doris整体架构如下图所示。Doris架构非常简单，只有两类进程：

• Frontend（FE），主要负责客户请求的接入、查询解析规划、元数据的管理、节点管理相关工作。

• Backend（BE），主要负责数据存储、查询计划的执行。

这两类进程都是可以横向扩展的，单集群可以支持到数百台机器，数十 PB的存储容量。并且这两类进程通过一致性协议来保证服务的高可用和数据的高可靠，这种高度集成的架构设计极大的降低了一款分布式系统的运维成本。

从以下五个方面介绍Doris技术：

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

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

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

  • Sorted Compound Key Index：可以最多指定三个列组成复合排序键，通过该索引，能够有效进行数据裁剪，从而能够更好支持高并发的报表场景。

  • Z-order Index：使用Z-order索引，可以高效对数据模型中的任意字段组合进行范围查询。

  • Min/Max：有效过滤数值类型的等值和范围查询。

  • Bloom Filter：对高基数列的等值过滤裁剪非常有效。

  • Invert Index：能够对任意字段实现快速检索。

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

  • Aggregate Key模型：相同Key的Value列合并，通过提前聚合大幅提升性能。

  • Unique Key模型：Key唯一，相同Key的数据覆盖，实现行级别数据更新。

  • Duplicate Key模型：明细数据模型，满足事实表的明细存储。

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

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

  Doris查询引擎是向量化的查询引擎，所有的内存结构能够按照列式布局，能够达到大幅减少虚函数调用、提升Cache命中率，高效利用SIMD指令的效果。在宽表聚合场景下性能是非向量化引擎的5-10倍。

• 在优化器方面Doris使用CBO和RBO结合的优化策略，RBO支持常量折叠、子查询改写、谓词下推等，CBO支持Join Reorder。目前CBO还在持续优化中，主要集中在更加精准的统计信息收集和推导，更加精准的代价模型预估等方面。

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