Apache Doris 架构详解

英仔cc
0 阅读15分钟

Apache Doris 架构详解

Apache Doris 是一款开源、极速、分布式、MPP 架构的实时分析型数据库（OLAP） ，专为海量数据的实时多维分析、交互式查询场景设计。相较于传统Hive、Spark SQL的离线延迟，以及MySQL、PostgreSQL的弱分析能力，Doris 实现了实时写入、秒级查询、离线实时一体、极简运维的核心能力，是当前企业实时数仓、数据大屏、用户画像、日志分析的核心组件。

本文摒弃晦涩的学术术语，以通俗逻辑、底层原理、实战代码、运维落地四个维度，全方位拆解 Doris 架构，既适合新手建立认知，也能帮助技术人员吃透核心设计思想、解决生产落地问题。

一、核心定位与设计思想（架构底层逻辑）

1.1 核心定位

简单来说，Doris 的核心使命：让海量数据的分析查询，像查MySQL一样简单、实时、高效。

它不做事务处理（不替代MySQL），不做流式计算（不替代Flink），专注解决海量结构化数据的多维聚合、过滤、排序分析，支持实时增量写入、批量离线导入，统一承接实时和离线分析场景。

1.2 四大核心设计思想（架构精髓）

Doris 所有架构设计、功能特性都围绕以下思想展开，理解这些即可吃透80%的底层逻辑：

  • 极简存算一体架构：摒弃复杂的分层架构，仅由FE（前端）、BE（后端）两类进程组成，无第三方依赖、无冗余组件，部署运维成本极低，同时支持存算弹性扩缩容。
  • MPP 并行计算：查询任务自动分片，分发到所有BE节点并行执行，多节点算力叠加，突破单节点性能瓶颈，实现海量数据秒级响应。
  • 列式存储+向量化执行：数据按列存储，分析查询仅读取需要的列，减少IO开销；搭配向量化引擎，批量处理数据，大幅提升CPU利用率，适配多维聚合分析场景。
  • 高可用无单点故障：FE、BE均支持多副本部署，元数据高可用、数据多副本冗余，节点故障自动切换，不影响集群整体服务，适配生产高可用需求。
  • 实时离线一体化：统一一套存储架构，既支持Flink/Kafka实时增量写入，也支持批量离线导入，无需区分实时、离线集群，简化数据架构。

二、整体架构总览（核心组件拆解）

Apache Doris 架构极度简洁，仅包含 FE（Frontend 前端节点）和 BE（Backend 后端节点）两大核心组件，可选Broker组件用于外部文件导入，无任何额外依赖。整体架构可概括为：FE负责调度管理，BE负责存储计算，分工明确、解耦清晰。

为方便理解，可做通俗类比：FE是餐厅前台（接待请求、分配任务、管理台账），BE是后厨（加工数据、存储数据、执行任务），Broker是外部食材采购通道。

Doris 集群整体架构.png

2.1 FE 前端节点：集群的“大脑”

FE 不存储业务数据，仅负责集群管理、SQL解析调度、元数据管理、查询协调，是整个集群的控制中心，支持多节点高可用部署，分为三种角色：

（1）Master FE（主节点）
  • 集群唯一主节点，通过选举产生，负责全局元数据写入与更新（建表、分区、数据导入、节点上下线）。
  • 维护集群所有元数据（表结构、分区信息、副本分布、节点状态），同步至所有Follower节点。
  • 处理集群管控操作，保证集群数据一致性。
（2）Follower FE（从节点）
  • 同步Master的元数据，保持与主节点数据一致。
  • 承接用户查询请求，完成SQL解析、语法校验、查询计划生成。
  • Master故障时，参与选举，自动升级为新Master，实现管控层高可用。
（3）Observer FE（观察者节点）
  • 仅同步元数据，不参与Master选举，无写入权限。
  • 核心作用：分担查询并发压力，适合高并发查询场景，横向扩展查询吞吐量。

FE 核心特性：所有FE节点均存储完整集群元数据，查询请求可任意接入任意FE节点，无查询单点瓶颈，管控层高可用、可扩展。

2.2 BE 后端节点：集群的“手脚”

BE 是集群的数据存储与计算核心，所有业务数据、索引均存储在BE节点，同时负责执行FE下发的查询、导入、 compaction（数据合并）任务，支持无限横向扩展。

BE 核心能力
  • 数据存储：以列式存储形式保存用户数据，支持分区、分桶、多副本冗余（默认3副本），保障数据安全。
  • 计算执行：接收FE分发的查询分片任务，并行完成过滤、聚合、排序、关联等计算，返回结果给FE汇总。
  • 数据写入与合并：承接实时、批量数据导入，落地增量数据，后台自动执行Compaction，合并小文件、清理过期数据，优化查询性能。
  • 故障自愈：单BE节点故障时，集群自动感知，将任务迁移至其他节点，副本自动补齐，不影响业务。

2.3 Broker 组件（可选）

Broker 是独立的轻量组件，无状态、不存储数据，仅用于读取外部存储文件，适配HDFS、S3、OSS等对象存储的批量数据导入场景。日常实时导入（Flink、Kafka）无需依赖Broker。

三、核心数据架构（底层存储与模型）

理解Doris数据存储结构和数据模型，是掌握架构核心、做好表设计的关键，也是优化查询、写入性能的基础。

3.1 数据分层结构

Doris 数据从逻辑到物理分为四层，层层拆解清晰易懂：数据库Database → 表Table → 分区Partition → 分桶Tablet

  • 数据库：逻辑隔离单元，对应业务系统、数据域，与MySQL数据库概念一致。
  • 表：业务数据载体，支持标准SQL建表，定义字段、数据模型、分区分桶规则。
  • 分区（Partition） ：按时间、地区等维度拆分大表，最常用时间分区（按天/小时分区），实现数据冷热隔离、分区裁剪，大幅提升查询效率。查询时仅扫描目标分区，无需全表扫描。
  • 分桶（Tablet） ：分区内的数据进一步拆分，是Doris最小存储和副本单元。一个分区可分为多个Tablet，均匀分布在所有BE节点，每个Tablet默认3副本，保障高可用。查询任务以Tablet为单位分片并行执行。

3.2 三大核心数据模型（实战必懂）

Doris 针对不同业务场景设计了3种数据模型，核心差异在于主键更新、数据聚合方式，适配离线汇总、实时更新、明细存储三大场景。

（1）Aggregate Key 聚合模型（离线汇总场景）

核心逻辑：相同主键（Key列）的数据自动聚合合并，Value列提前定义聚合函数（sum、count、max、min），写入时自动合并，查询时无需二次聚合，速度极快。

适用场景：离线统计、指标汇总、日/小时报表，无明细更新，仅累加指标数据。

实战建表示例

 CREATE TABLE user_order_stats (
     dt DATE COMMENT '统计日期',
     user_id VARCHAR(50) COMMENT '用户ID',
     order_cnt BIGINT SUM COMMENT '订单数',
     order_amount DECIMAL(18,2) SUM COMMENT '订单金额'
 )
 AGGREGATE KEY(dt,user_id)
 PARTITION BY RANGE(dt) ()
 DISTRIBUTED BY HASH(user_id) BUCKETS 8
 PROPERTIES (
     "replication_allocation" = "tag.location.default: 3",
     "enable_vectorized_engine" = "true"
 );
（2）Unique Key 唯一主键模型（实时更新场景）

核心逻辑：主键唯一，相同主键数据自动覆盖更新，支持实时新增、修改数据，保证主键唯一性。Doris 2.1+版本支持merge-on-write写入模式，彻底解决旧版本更新性能差的问题，实现高并发实时更新。

适用场景：用户画像、订单实时状态更新、维度表实时同步、需要精准更新单行数据的场景。

实战建表示例

 CREATE TABLE user_profile (
     user_id VARCHAR(50) COMMENT '用户ID',
     user_name VARCHAR(100) COMMENT '用户名',
     user_level TINYINT COMMENT '用户等级',
     register_time DATETIME COMMENT '注册时间'
 )
 UNIQUE KEY(user_id)
 DISTRIBUTED BY HASH(user_id) BUCKETS 8
 PROPERTIES (
     "replication_allocation" = "tag.location.default: 3",
     "enable_vectorized_engine" = "true",
     "unique_key_merge_on_write" = "true" -- 开启写合并，优化更新性能
 );
（3）Duplicate Key 明细模型（通用明细场景）

核心逻辑：无聚合、无去重，完整保留所有写入明细数据，支持任意维度过滤、排序、关联，是最通用的数据模型。

适用场景：日志明细、行为轨迹、实时明细数据存储、不确定查询维度的通用场景。

实战建表示例

 CREATE TABLE user_behavior_log (
     dt DATE COMMENT '日志日期',
     user_id VARCHAR(50),
     event_type VARCHAR(20) COMMENT '事件类型：点击/浏览/下单',
     page_url VARCHAR(200),
     event_time DATETIME
 )
 DUPLICATE KEY(dt,user_id,event_type)
 PARTITION BY RANGE(dt) ()
 DISTRIBUTED BY HASH(user_id) BUCKETS 16
 PROPERTIES (
     "replication_allocation" = "tag.location.default: 3",
     "enable_vectorized_engine" = "true"
 );

四、核心流程解析（读写底层原理）

掌握数据写入和查询执行流程，能从底层理解Doris高性能、低延迟的原因，同时精准定位生产问题。

4.1 数据写入流程（实时/批量统一）

Doris 支持多种写入方式：Kafka 实时导入、Stream Load 实时写入、Broker Load 批量导入、Insert 语句写入，核心流程一致，分为 4 步：

  1. 请求接入：客户端写入请求发送至 FE 节点，FE 校验表结构、权限、分区合法性。
  2. 任务分发：FE 根据分桶规则，计算数据对应的 Tablet 节点，将写入任务分发至对应 BE 节点。
  3. 数据落地：BE 接收数据，先写入内存 MemTable，内存写满后落地为磁盘文件（Segment 文件），同时同步至副本节点，保证多副本一致。
  4. 后台合并：BE 后台异步执行 Compaction，合并零散小文件、聚合重复数据、清理过期版本，持续优化查询性能。

核心优势：写入过程无锁、无全局事务，异步合并不影响实时写入延迟，实现高吞吐实时写入+高性能查询兼顾。

4.2 数据查询流程（MPP并行查询）

用户执行SQL查询时，完整执行流程如下，完美体现MPP并行计算优势：

  1. 请求解析：FE 接收 SQL，完成语法解析、语义校验、权限校验。
  2. 查询优化：FE 生成逻辑执行计划，经过裁剪优化（分区裁剪、列裁剪、谓词下推），剔除无效数据扫描。
  3. 任务分片：根据 Tablet 分布，将查询任务拆分为多个子任务，分发至所有相关 BE 节点。
  4. 并行执行：所有 BE 节点并行执行子任务，读取列式数据、完成过滤、聚合、排序等计算。
  5. 结果汇总：FE 收集所有 BE 的计算结果，完成全局聚合、排序、limit 裁剪，最终返回给客户端。

通俗总结：单条SQL被拆成多份，多节点同时干活，最后汇总结果，天然比单节点数据库快数十倍。

五、核心应用场景（架构适配场景）

Doris的架构特性决定了其专属业务场景，以下是生产中最核心、最高频的落地场景：

  • 实时数据大屏：承接业务实时指标统计（订单、流量、销量），秒级刷新数据，适配大屏高并发、低延迟查询需求，替代传统Redis+MySQL方案。
  • 实时数仓（替代Hive离线数仓） ：搭建分层实时数仓（ODS/DWD/DWS/ADS），对接 Flink 实时写入，实现 T+0 数据更新，告别离线凌晨跑批的延迟问题。
  • 用户画像与精准营销：基于Unique Key模型实时更新用户标签、行为数据，支持多维用户分群、人群筛选，支撑营销活动、用户运营。
  • 日志与行为分析：存储用户行为日志、系统运行日志，支持任意维度明细查询、聚合统计，适配运维分析、产品行为分析场景。
  • 湖仓一体分析：对接 Hive、Iceberg、Hudi 数据湖，通过外部表直接查询湖内数据，无需迁移数据，统一离线、实时查询入口。

六、实战编程：常用核心操作代码

基于标准 SQL，兼容 MySQL 语法，以下是生产高频实操代码，快速上手开发。

6.1 数据库、表基础操作

 -- 创建数据库
 CREATE DATABASE IF NOT EXISTS biz_analysis;
 ​
 -- 切换数据库
 USE biz_analysis;
 ​
 -- 建表示例（明细模型，按天分区）
 CREATE TABLE app_visit_log (
     log_dt DATE,
     app_id VARCHAR(32),
     user_id VARCHAR(64),
     device_type VARCHAR(20),
     visit_cnt INT,
     stay_time INT,
     create_time DATETIME
 )
 DUPLICATE KEY(log_dt,app_id,user_id)
 PARTITION BY RANGE(log_dt) (
     START "2026-01-01" END "2026-12-31" EVERY INTERVAL 1 DAY
 )
 DISTRIBUTED BY HASH(user_id) BUCKETS 16
 PROPERTIES (
     "replication_allocation" = "tag.location.default: 3",
     "enable_vectorized_engine" = "true",
     "compaction_num_threads" = "4"
 );
 ​
 -- 简单查询（分区裁剪优化）
 SELECT app_id,COUNT(DISTINCT user_id) AS uv,SUM(visit_cnt) AS pv
 FROM app_visit_log
 WHERE log_dt = CURRENT_DATE()
 GROUP BY app_id;

6.2 实时数据写入（Stream Load）

通过 HTTP 请求实现秒级实时数据写入，是生产最常用的实时导入方式：

 # Stream Load 实时导入示例
 curl -v \
 -H "Expect:100-continue" \
 -H "Content-Type:text/plain; charset=utf-8" \
 -u root:password \
 -T data.csv \
 http://doris-fe-ip:8030/api/biz_analysis/app_visit_log/_stream_load

七、生产运维核心要点（架构运维落地）

Doris 架构极简，运维成本远低于 Hadoop、Spark 生态圈，核心运维工作集中在以下几点：

7.1 集群部署与扩缩容

  • 基础部署：生产推荐部署 3 个 FE（1Master+2Follower）、3 个及以上 BE，保障高可用。
  • 扩容：FE、BE 支持横向扩容，新增节点自动同步元数据、均衡数据副本，无需停机。
  • 缩容：下线节点前自动迁移数据，无数据丢失，不影响业务。

7.2 核心监控指标

重点监控四大维度，快速预判集群风险：

  • 写入监控：导入成功率、写入吞吐、写入延迟、失败任务数。
  • 查询监控：查询QPS、平均响应时间、慢查询数、查询失败率。
  • 资源监控：BE 节点 CPU、内存、磁盘使用率、磁盘 IO。
  • 集群健康度：副本完整性、节点在线状态、Compaction任务堆积情况。

7.3 性能调优核心

  • 表结构优化：合理选择数据模型、分区（优先时间分区）、分桶数（根据数据量调整），避免分区过大、分桶不均。
  • 查询优化：强制分区裁剪、避免全表扫描、减少大表关联、利用预聚合模型减少实时计算。
  • Compaction调优：调整 Compaction 合并线程数、合并阈值，避免小文件堆积导致查询变慢。
  • 资源调优：合理配置 BE 内存参数，避免 OOM，平衡写入与查询资源占用。

7.4 故障排查核心

  • FE故障：Master 宕机自动选举，新 Master 接管服务，无业务中断；Observer 节点故障直接下线，不影响集群。
  • BE故障：单 BE 宕机，集群自动屏蔽节点，副本迁移至其他节点，任务自动重试。
  • 写入失败：优先排查分区不存在、字段不匹配、副本异常、磁盘满四大问题。
  • 查询缓慢：优先排查未走分区裁剪、Compaction 堆积、数据倾斜、大内存查询问题。

八、架构核心优势与适用边界

8.1 核心优势

  • 架构极简：仅 FE/BE 两类组件，无 Zookeeper、HDFS 等依赖，部署运维极简，集群稳定性极高。
  • 性能极致：列式存储 + 向量化引擎 + MPP 并行，海量数据秒级查询，远超传统离线数仓。
  • 实时性强：支持毫秒级数据写入，无延迟，实现数据实时可见。
  • 兼容性好：完全兼容 MySQL 语法，学习成本低，各类 BI 工具、代码无需改造即可对接。
  • 弹性扩展：支持横向无限扩容，单集群可支撑数百节点、数十PB数据。

8.2 适用边界（避坑重点）

  • 不适用事务场景：不支持 OLTP 事务，不能替代 MySQL 做业务交易存储。
  • 不适用超高并发点查：适配分析查询，不适合百万级高并发单行点查场景（可搭配 Redis 使用）。
  • 不适用超复杂计算：不适合机器学习、流式复杂计算，需对接Flink、Spark完成预处理。

九、全文总结

Apache Doris 的架构核心可以概括为：极简分层、分工明确、并行高效、实时离线一体。FE 节点管控调度、BE 节点存储计算，搭配三种适配全场景的数据模型、MPP 并行查询架构，完美解决了传统数仓延迟高、运维复杂、实时能力弱的痛点。

在当前大数据架构中，Doris 已经成为实时数仓的核心底座，凭借低延迟、高性能、易运维的优势，逐步替代 Hive、Spark SQL 的传统离线架构，成为企业数据中台、实时分析、数据可视化的核心组件。掌握其底层架构设计思想，是做好数仓建模、性能优化、故障运维的核心基础。

avatar
文章
阅读
粉丝