Doris

Apache Doris 是一款高性能、实时的分析型数据库（OLAP），以其出色的查询速度、简洁的架构和高度兼容 MySQL 协议而著称

Doris 是一款关系型数据库，但它专攻在线分析处理（OLAP）​​ 领域，与传统面向事务处理（OLTP）的关系型数据库（如 MySQL）在架构、存储模型和适用场景上存在显著差异

组件类型	角色名称	主要职责
​前端 (Frontend, FE)​​	Leader / Follower	负责元数据管理、查询语句的解析与规划、集群节点管理。Leader 和 Follower 通过一致性协议（如 Paxos）保证元数据的高可用
	Observer	仅负责扩展集群的查询能力，不参与元数据写入和选举，从而实现读写分离
​后端 (Backend, BE)​​	-	负责数据存储（通常多副本存储）和查询计划的具体执行，是分布式计算和存储的节点

 

 

 

 

 

 

 

 

🚀 工作原理与核心特性

1. ​MPP 架构与查询执行​

   Doris 采用大规模并行处理架构。当用户通过 MySQL 客户端发送一个 SQL 查询请求后，FE 的 Leader 节点会负责接收、解析并优化该 SQL，生成一个分布式的查询执行计划。这个计划会被拆分成多个片段，并分发给相关的多个 BE 节点。每个 BE 节点会并行处理自己负责的数据分片，最后将中间结果汇总给某个 BE 节点进行最终聚合，并将结果返回给客户端。这种“分而治之”的模式极大地提高了复杂分析的查询效率

2. 列式存储与高效压缩​

   Doris 采用列式存储，即将同一列的数据连续存放在一起。这样做的好处非常明显：当查询只涉及部分列时，可以避免读取整行数据，大幅减少 I/O 开销。同时，由于同一列的数据类型相同，通常也能获得更高的数据压缩比

3. 向量化执行引擎​

   为了充分发挥现代 CPU 的处理能力，Doris 实现了向量化执行引擎。它改变了传统数据库一行一行处理数据的方式，改为一次处理一批数据（一个向量）。这减少了函数调用开销，提高了 CPU 缓存命中率，并能利用 SIMD 指令进行并行计算，在宽表聚合等场景下，性能提升可达数倍

4. 丰富的数据模型与索引​

   • ​数据模型​：Doris 提供了三种核心数据模型以适应不同场景

     • ​聚合模型 (Aggregate Key)​​：预定义聚合规则（如 SUM、MAX），在数据导入时自动聚合，非常适合报表统计。

     • ​唯一键模型 (Unique Key)​​：支持按主键进行更新删除，实现行级数据更新，适用于需要保证唯一性的维表。

     • ​明细模型 (Duplicate Key)​​：存储最原始的明细数据，不进行任何聚合，适用于日志分析等需要完整数据的场景。

   • 索引技术​：Doris 支持丰富的索引，如前缀索引​（基于排序键快速定位）、Bloom Filter 索引​（高效判断数据块中是否包含某值）和倒排索引​（支持任意字段的快速检索），这些索引能有效加速数据过滤

 

Doris 的列式存储是其高性能查询的核心基石

Doris 的列式存储是其高性能查询的核心基石

对比维度	行式存储 (如MySQL)	Doris列式存储	列式存储的优势
​数据布局​	将一整行数据（如用户ID、姓名、年龄）连续存储在一起。	将每一列的数据分别连续存储（所有用户ID在一起，所有姓名在一起）。	查询时只读取需要的列，​极大减少I/O开销​
​压缩效率​	一行内数据类型不同，压缩效率相对较低。	同一列数据类型相同、内容相似，​可实现极高压缩比​（如5:1至20:1）	节省存储空间，减少磁盘读取和数据网络传输的数据量
​适用场景​	​OLTP​：频繁的增删改查、需要读取整行数据的操作。	​OLAP​：对海量数据进行聚合、分析和报表查询，通常只涉及部分列。	为分析型查询量身定制，性能可提升数倍至数十倍

 

 

 

 

 

 

 

 

🔩 列式存储的内部架构

Doris 的列式存储并非简单地将列数据堆砌在一起，而是通过精密的层次化结构进行组织和管理，以实现高效的数据存取

• 数据组织层次​：Doris 的数据从大到小分为 Table → Partition（分区） → Tablet（数据分片） → Rowset（数据版本集） → ​Segment（数据段）​。Segment 是列式存储的最小物理单元，每个 Segment 文件内部，数据是按列存储的

• ​智能编码与压缩​：针对不同的数据类型，Doris 会自动选择最有效的编码和压缩方案。例如，对于重复度高的字符串，会使用字典编码，将其转换为数值，大幅减少存储空间；对于小范围的整数值，会使用位填充编码等技术。Doris 支持多种压缩算法（如LZ4、ZSTD），并能根据数据类型自动选择最优策略

 

⚡ 加速查询的“组合拳”：索引与向量化

仅仅减少I/O还不够，Doris 通过多种索引和向量化执行技术进一步加速查询。

1. ​多级索引机制​

   • ​前缀索引（Short Key Index）​​：在数据写入时，Doris 会根据建表时指定的排序列（如 (user_id, event_time)）对数据进行排序，并为每间隔一定行数的数据生成一个前缀索引。在点查询或范围查询时，可以快速定位到数据所在的大致范围，避免全表扫描

   • ​Zone Map（Min/Max）索引​：Doris 会为每个数据块（Block）内的每一列自动记录其最小值和最大值。当执行查询时，如果查询条件超出了这个范围，整个数据块就会被直接跳过，从而减少扫描量。这对于时间范围过滤等场景非常有效。

   • ​Bloom Filter 索引​：特别适用于高基数列（如用户ID、订单号）的等值查询。它可以快速判断一个值肯定不存在于某个数据块中，从而高效过滤掉大量不相关的数据

2. ​向量化执行引擎​

   Doris 的查询引擎是向量化的。这意味着，它处理数据时不再是传统的“一次一行”，而是 ​​“一次一批”​​ 。CPU 可以批量处理列数据，充分利用现代CPU的SIMD（单指令多数据流）指令集，实现并行计算，极大提升了CPU的计算效率，尤其在宽表聚合场景下，性能可达非向量化引擎的5-10倍

 

💡 列式存储的适用场景与权衡

选择列式存储需要权衡其优劣势，它并非万能钥匙。

• ​优势场景​：Doris 的列式存储非常适合在线分析处理（OLAP）​​ 场景，例如：

  • ​聚合报表​：快速计算销售总额、用户日活等。

  • ​即席查询​：分析师灵活地探索数据，进行多维度分析。

  • ​大规模数据扫描​：对亿级甚至更大量级的数据进行复杂条件过滤和聚合

• ​需要考虑的方面​：列式存储也有其不擅长的地方。由于写入时需要将一行数据拆解到不同的列位置存储，​频繁的单行写入或更新（OLTP场景）成本较高​ 

  不过，Doris 通过批量数据导入来规避这一问题，将写入开销分摊，从而在实时和离线数据接入上都表现出色

 

OLTP和OLAP是两种截然不同的数据处理系统，它们像是一个企业运营的“左右脑”：一个负责实时处理具体业务，另一个负责深度分析辅助决策。了让你快速把握核心区别，我用一个表格来汇总它们的主要特点：

特性维度	OLTP (联机事务处理)	OLAP (联机分析处理)
​核心目标​	高效、准确地处理日常事务​ (如订单、支付)	支持复杂分析与决策支持​ (如销售趋势分析)
​数据焦点​	​当前数据，细节的，反映最新状态	​历史数据，聚合的，集成的，用于分析趋势
​数据库设计​	高度规范化的关系模型，面向应用	星型或雪花模型，多维数据模型，面向主题
​读写模式​	​读写频繁，平衡负载，频繁修改数据	​以读为主，几乎不修改数据，复杂查询
​响应要求​	毫秒级响应，超高吞吐量	响应时间通常较长（秒级甚至分钟级）
​典型用户​	业务操作人员，前台员工，终端客户	数据分析师，决策人员，高级管理人员
​数据量级​	相对较小 (MB到GB)	海量数据 (GB到TB甚至更大)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🔄 二者如何协同工作

尽管OLTP和OLAP如此不同，但在现代企业数据架构中，它们紧密协作，形成一个完整的数据流水线：

1. ​数据产生与记录​：所有日常业务操作（如用户下单、库存增减）都在OLTP系统中实时发生，确保每一笔事务准确无误

2. ​数据整合与沉淀​：OLTP系统中的数据会定期（例如每天夜间）通过ETL（抽取、转换、加载）过程，被提取、清洗、整合后加载到数据仓库中。这个过程将分散的、面向事务的数据转换成统一的、面向分析的数据模型。

3. ​分析与洞察​：数据分析师和业务决策者使用OLAP工具对数据仓库中的历史数据进行多维、交互式的深度分析，生成报表和洞察，为战略决策提供支持

这种分工协作的优势在于，它将高并发的实时事务处理（OLTP）与消耗大量资源的复杂分析查询（OLAP）分离开来，避免了二者在同一个数据库中相互争抢资源，从而保证了业务系统的稳定性和分析系统的高效性

 

💎 简单总结

总的来说，OLTP是业务的“执行者”，关心的是“如何做”，追求速度和准确性；而OLAP是管理的“洞察者”，关心的是“为什么”，追求深度和趋势