首页/数据/数仓建模速查/Apache Doris:MPP 实时分析数据库
湖仓与引擎63 条

Apache Doris:MPP 实时分析数据库

Doris 采用 FE 与 BE 两层架构:FE 负责元数据与查询规划,BE 负责存储与执行;兼容 MySQL 协议,适合高并发点查与实时报表。

数仓建模速查数据更新于 2026-10-13

Doris 是什么

Apache Doris 是 MPP 架构的实时分析数据库,集群由 FE 与 BE 两类进程组成:FE 负责元数据管理、查询规划与调度,BE 负责数据存储与计算执行。它兼容 MySQL 协议,用普通 MySQL 客户端就能连接,BI 工具接入成本很低。Doris 的强项是高并发点查与多维分析,配合物化视图、位图和 HLL 等结构,能在秒级响应看板查询。

基本信息

架构FE 负责元数据与规划,BE 负责存储与执行
连接协议兼容 MySQL 协议,可用 MySQL 客户端连接
典型场景实时报表、高并发点查、多维分析
常用特性物化视图、Bitmap、HLL 近似去重
数据模型明细、聚合、主键(Unique)三类

典型使用场景

  • BI 看板高并发查询:几十到上百并发的小查询,比走离线引擎更稳定
  • 实时报表:上游写入后立即可查,省掉「导入数仓再等调度」的链路
  • 明细下钻:明细模型保留原始行,支持任意维度组合过滤
  • 去重统计(日活、去重下单人数):用位图或 HLL 在毫秒级得到结果
  • 充当数仓的对外服务层:ADS 结果直接落在 Doris 供应用查询

建库建表

建库建表
CREATE DATABASE IF NOT EXISTS dw;

CREATE TABLE dw.dws_trade_store_day (
  dt DATE NOT NULL,
  store_id VARCHAR(32) NOT NULL,
  order_cnt BIGINT SUM DEFAULT '0',   -- 聚合列:同 KEY 自动累加
  pay_amt DECIMAL(18,2) SUM DEFAULT '0'
)
AGGREGATE KEY(dt, store_id)
DISTRIBUTED BY HASH(store_id) BUCKETS 16;
-- DISTRIBUTED BY 决定数据散列到各 BE 的方式,BUCKETS 为分桶数

查询与执行计划

查询与执行计划
-- 近似去重:日活统计,性能远好于精确去重
SELECT dt, bitmap_union_count(user_bitmap) AS uv
FROM dws_user_active_day
GROUP BY dt;
-- 上生产前看执行计划,确认分区裁剪与预聚合是否生效
EXPLAIN SELECT store_id, sum(pay_amt)
FROM dws_trade_store_day WHERE dt='2026-10-13' GROUP BY store_id;

三种表模型

表模型写入方式适合场景
明细模型追加写入,不做去重保留全部明细行,支持任意下钻
聚合模型按 KEY 预聚合,同 KEY 自动合并固定维度组合的汇总指标
主键模型按主键更新,保留最新版本需要覆盖更新的维表或状态表
Doris 单表就能支撑较高并发查询,适合直接承接 BI 看板;它不承担复杂数据血缘与批量重算,这些仍留在离线数仓里,Doris 更像离线的服务出口。
分区分桶决定查询与导入效率:分区常按时间切分,分桶把数据散到各个 BE。分区过细会产生大量小文件,分桶过多会让小查询调度开销上升,建议先按数据量与并发量估一个量级,再随负载调整。

易错点

  • 把明细大表全量导入 Doris 做历史回溯:存储成本高,还会挤占在线查询资源
  • 聚合模型选错:需要明细下钻时数据已被合并,无法还原原始行
  • 分区过细或分桶过多:小文件与元数据压力上升,小查询反而变慢
  • 用 Doris 承担批量重算:不为长事务与大批量加工设计,会挤占在线查询能力
  • 忽略副本分布与 BE 均衡:数据倾斜到部分节点,集群整体能力用不满

数据来源与参考

  • Apache Doris 官方文档:Architecture
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌