OLAP on 纪伟的个人博客

Doris 学习笔记（二）：进阶与实战

Sun, 14 Jun 2026 11:00:00 +0800

写在前面

承接上一篇，本文聚焦 Doris 的实战核心：表设计、分区与分桶、索引体系、查询优化、物化视图、Colocate Join，以及典型应用场景（实时数仓 / 多维分析）。基于 Doris 2.1.x。

一、表设计核心：分区与分桶

Doris 一张表的物理结构是 Partition（分区）→ Bucket（分桶）→ Tablet（数据片）。表设计是否合理，80% 取决于分区和分桶。

1.1 分区（Partition）

分区是逻辑切分，最常见的是按时间分区。

CREATE TABLE access_log (
    dt DATE, ts DATETIME, user_id BIGINT, page VARCHAR(128), cost_ms INT
)
DUPLICATE KEY(dt, ts, user_id)
PARTITION BY RANGE(dt) ()
DISTRIBUTED BY HASH(user_id) BUCKETS 4
PROPERTIES(
  "dynamic_partition.enable" = "true",
  "dynamic_partition.time_unit" = "DAY",
  "dynamic_partition.start" = "-30",       -- 保留最近 30 天
  "dynamic_partition.end"   = "3",         -- 预创建未来 3 天
  "dynamic_partition.prefix" = "p",
  "dynamic_partition.replication_num" = "1"
);

动态分区：
  - 自动按天创建/删除分区
  - 常用配置：start=-30（删历史 30 天前的），end=3（预创建 3 天）

为什么必须分区：
  - 按时间裁剪：SELECT ... WHERE dt='2026-06-01' 只扫一个分区
  - 生命周期管理：TTL 删旧分区，比逐行删除快几个数量级
  - 避免扫描全表：OLAP 查询 99% 都是按时间筛选

1.2 分桶（Bucket / Tablet）

分桶是物理切分，决定数据如何分布到 BE 节点，以及查询并行度。

`1`	`DISTRIBUTED BY HASH(user_id) BUCKETS 8`

关键选择：
  1. 分桶列：
     - 选高基数、常用于过滤/JOIN 的列
     - 一般选 user_id、order_id 等
     - 不要选 dt（dt 已经是分区列，重复使用没意义）
     - 不要选低基数列（如性别：会造成数据倾斜）

  2. 分桶数（BUCKETS）：
     - 单 Tablet 大小推荐 1~10GB
     - 估算：每天数据量 / (单 Tablet 大小) = 分桶数
     - 例：每天 100GB 数据，单 Tablet 2GB → BUCKETS = 50

  3. 并发度：
     - 一条查询的并行度 ≈ 涉及 Tablet 数
     - 太少（如 1 个）查询无法并行
     - 太多（如几千个）元数据开销大

1.3 估算分桶数的公式

假设：
  - 日增量 100GB（含索引、压缩后实际存储约 30GB）
  - 单 Tablet 推荐 1~2GB
  - 按天分区

分桶数 = 单分区数据量 / 单 Tablet 大小
       = 30GB / 1.5GB
       ≈ 20 桶

后验：通过 SHOW PARTITIONS 查看每个 Tablet 的大小，调整。

二、索引体系

Doris 的索引分两类：内置索引（建表自动）和显式索引（用户创建）。

2.1 前缀索引（Prefix Index）

Doris 默认对Key 列的前 36 字节建立前缀索引，类似 MySQL 的聚簇索引。

CREATE TABLE t (
    dt DATE, ts DATETIME, user_id BIGINT, page VARCHAR(128)
)
DUPLICATE KEY(dt, ts, user_id)   -- 这三列自动建立前缀索引
...

含义：
  WHERE dt='2026-06-01'                      ✅ 走前缀索引
  WHERE dt='2026-06-01' AND ts > '10:00'      ✅ 走前缀索引
  WHERE user_id = 1001                        ❌ 不走（跳过了 dt、ts）

设计建议：
  - Key 列顺序按"查询过滤频率从高到低"排
  - 通常顺序：dt → ts → user_id → ...
  - Key 列总长度 ≤ 36 字节（超出部分不进入前缀索引）

2.2 倒排索引（Inverted Index）

Doris 2.0+ 引入，对字符串/数值列做全文检索，类似 Elasticsearch。

ALTER TABLE access_log
ADD INDEX idx_page (page) USING INVERTED
PROPERTIES("parser" = "english")
;

ALTER TABLE access_log ADD INDEX idx_user (user_id) USING INVERTED;
ALTER TABLE access_log BUILD INDEX;

-- 用法：直接 WHERE，自动用索引
SELECT * FROM access_log
WHERE page MATCH_ANY 'home list detail';

SELECT * FROM access_log WHERE user_id = 1001;

特点：
  - 大幅提升等值/范围查询
  - 支持全文检索（MATCH_ALL / MATCH_ANY）
  - 替代了老版本的 BITMAP_INDEX（更通用）

2.3 Bloom Filter 索引

针对高基数列的等值查询，简单且高效：

1
2
3

ALTER TABLE access_log SET (
  "bloom_filter_columns" = "user_id,page"
);

适用：
  - 高基数列（user_id, trace_id 等）
  - 等值查询（=）
  - IN 列表查询

不适用：
  - 低基数列（性别、状态）
  - 范围查询（>, <）
  - 加入了反而浪费空间

2.4 索引选型

场景	推荐索引
Key 列前缀范围查询	前缀索引（自动）
高基数列等值	Bloom Filter
字符串全文检索	倒排索引
低基数列等值/范围	倒排索引

三、查询优化

3.1 CBO 优化器

Doris 默认开启 CBO（Cost-Based Optimizer）。

1
2
3

-- 查看实际执行计划
EXPLAIN VERBOSE
SELECT dt, COUNT(*) FROM access_log GROUP BY dt;

CBO 会考虑：
  - 表的统计信息（行数、基数、选择率）
  - JOIN 顺序（小表驱动大表）
  - 是否广播 vs 重分布

需要：定期 ANALYZE TABLE 让统计信息新鲜

`1`	`ANALYZE TABLE access_log WITH SYNC;`

3.2 JOIN 策略

Doris 有三种 JOIN 执行方式：

1. Broadcast Join（广播）
   小表（< 1GB 默认）广播到所有 BE 节点
   适合：大表 JOIN 小表（如事实表 JOIN 维度表）

2. Shuffle Join（重分布）
   两表都按 JOIN KEY 重分布，再本地 JOIN
   适合：大表 JOIN 大表

3. Colocate Join（同分布，零 Shuffle）
   两表 JOIN KEY 类型一致、分桶方式一致、副本一致
   适合：频繁 JOIN 的大表（如订单表 JOIN 用户表）

Colocate Join 配置示例：

-- 1. 建一个 colocate group
ALTER TABLE orders SET ("colocate_with" = "user_grp");
ALTER TABLE users  SET ("colocate_with" = "user_grp");

-- 2. 两表都按 user_id 分桶，自动按相同方式分布
-- 3. JOIN 时 FE 识别到 colocate，跳过网络 Shuffle
SELECT a.order_id, b.name
FROM orders a JOIN users b USING(user_id);

1
2
3

性能差异（实测）：
  Shuffle Join：  ~10s（网络 + 落盘）
  Colocate Join： ~1s（零 Shuffle）

3.3 Runtime Filter

大表 JOIN 小表时，FE 会动态生成一个过滤条件下推到扫描节点。

-- 大表 JOIN 小表，会自动启用 Runtime Filter
SELECT count(*)
FROM access_log a
JOIN user_dim b ON a.user_id = b.user_id
WHERE b.country = 'CN';

原理：
  1. 先扫描 user_dim（小表）过滤后拿到 user_id 集合
  2. 把这个集合推给 BE 节点扫描 access_log 时使用
  3. 大表扫描时直接过滤掉不匹配的行

效果：扫描数据量减少 10~1000 倍

3.4 常见慢查询排查

-- 1. 看查询 Profile
SET enable_profile = true;
-- 跑一次慢查询，然后 Web UI → QueryProfile 查看每一步耗时

-- 2. 慢的常见原因
--    - 没走分区裁剪：扫描了所有分区
--    - 没走索引：Key 列顺序设计不当
--    - 数据倾斜：某个 Tablet 特别大
--    - JOIN 错：用了 Shuffle 而非 Colocate

-- 3. 看 Tablet 分布是否均衡
SHOW TABLET FROM access_log;

四、物化视图（Materialized View）

物化视图 = 预计算 + 自动重写查询。

4.1 同步物化视图（Rollup）

适合单表聚合加速，写入时自动维护：

CREATE MATERIALIZED VIEW mv_user_pv AS
SELECT dt, user_id, COUNT(*) AS pv
FROM access_log
GROUP BY dt, user_id;

原理：
  - 创建后，新写入的数据会同时写入主表和物化视图
  - 查询时优化器自动判断是否使用物化视图
  - 用户无需改 SQL，对应用透明

4.2 异步物化视图（Multi-Table）

Doris 2.1+ 支持，可以跨表、跨库聚合：

CREATE MATERIALIZED VIEW mv_daily_summary
DISTRIBUTED BY HASH(dt) BUCKETS 4
REFRESH ASYNC EVERY(INTERVAL 1 HOUR)  -- 每小时异步刷新
AS
SELECT
    a.dt,
    b.country,
    COUNT(*) AS pv,
    COUNT(DISTINCT a.user_id) AS uv,
    SUM(a.cost_ms) AS total_cost
FROM access_log a
JOIN user_dim b ON a.user_id = b.user_id
GROUP BY a.dt, b.country;

适用场景：
  - 复杂的实时大盘报表
  - 上百个 Dashboard 的指标预聚合
  - 流量减少：把 1TB 大表查询变成 10GB 物化视图查询

4.3 物化视图 vs Rollup

维度	Rollup（同步）	异步物化视图
单表/多表	单表	单/多表
维护	写入时同步	异步刷新
延迟	实时	分钟级
复杂度	简单	较复杂
推荐	简单聚合	复杂报表

五、数据导入实战

5.1 Stream Load（实时小批量）

curl -u root: \
     -H "label:order_20260614_001" \
     -H "column_separator:," \
     -H "columns:order_id,user_id,amount,created_at" \
     -T /tmp/orders.csv \
     http://localhost:8030/api/demo/orders/_stream_load

关键参数：
  - label：导入的唯一标识，保证幂等（同一 label 不会重复导入）
  - column_separator：CSV 分隔符
  - columns：CSV 列顺序 → 表列映射

返回值（成功示例）：
  {
    "Status": "Success",
    "NumberTotalRows": 1000,
    "NumberLoadedRows": 1000
  }

5.2 Routine Load（消费 Kafka）

CREATE ROUTINE LOAD rl_orders ON orders
WITH PROPERTIES (
    "format" = "json",
    "jsonpaths" = "[\"$.order_id\",\"$.user_id\",\"$.amount\",\"$.ts\"]"
)
FROM KAFKA (
    "kafka_broker_list" = "kafka:9092",
    "kafka_topic" = "orders",
    "kafka_group_id" = "doris_orders"
);

特点：
  - 持续消费 Kafka topic
  - 支持 Exactly-Once（通过 label + Kafka offset）
  - 自动容错：BE 失败自动重试

典型链路：
  MySQL → Canal/Debezium → Kafka → Doris Routine Load → 实时数仓

5.3 Broker Load（批量导入）

LOAD LABEL demo.broker_load_001
(
    DATA INFILE("hdfs://namenode:8020/data/orders/*.parquet")
    INTO TABLE orders
    FORMAT AS PARQUET
)
WITH BROKER "broker1"
PROPERTIES (
    "timeout" = "3600"
);

适合一次性大规模历史数据迁移（数百 GB ~ TB）。

六、典型应用场景

6.1 实时数仓

数据链路：
  业务 DB → Canal → Kafka → Doris Routine Load
       ↓
  Doris 实时表（明细模型 / 主键模型）
       ↓
  Doris 物化视图（按小时/天聚合）
       ↓
  BI / 报表查询

特点：
  - 秒级延迟（数据写入即可查）
  - 主键模型保证 UPSERT 一致性
  - BI 直接用 MySQL 协议连接

6.2 多维分析（OLAP）

-- 用户行为分析：UV / PV / 漏斗
SELECT
    dt,
    page,
    COUNT(DISTINCT user_id) AS uv,
    COUNT(*) AS pv,
    AVG(cost_ms) AS avg_cost
FROM access_log
WHERE dt >= '2026-06-01'
GROUP BY dt, page
ORDER BY dt, uv DESC;

为什么 Doris 适合：
  - BITMAP_UNION 高效去重（UV 计算）
  - 列存 + 向量化扫描快
  - 物化视图加速常用维度组合

6.3 日志检索

-- 利用倒排索引做日志搜索
SELECT * FROM access_log
WHERE page MATCH_ALL 'home error'
  AND ts >= '2026-06-14 00:00:00'
ORDER BY ts DESC
LIMIT 100;

新版本 Doris 的倒排索引能力，可以部分替代 Elasticsearch 做日志场景。

七、小结

本文学习了 Doris 的进阶内容：

表设计核心：分区（按时间）+ 分桶（按基数列）+ 副本
索引体系：前缀索引、倒排索引、Bloom Filter
查询优化：CBO 优化器、JOIN 策略、Colocate Join、Runtime Filter
物化视图：同步 Rollup（单表）和异步物化视图（多表）
数据导入：Stream Load、Routine Load、Broker Load
典型场景：实时数仓、多维分析、日志检索

落地建议：
  - 表设计：先按时间分区，再选高基数列分桶，BUCKETS 数按数据量算
  - 模型选择：明细用 Duplicate，更新用 Primary Key
  - 索引：低基数 + 字符串检索 → 倒排；高基数等值 → Bloom Filter
  - JOIN：维度表用 Broadcast，事实表频繁 JOIN 用 Colocate
  - 加速：高频聚合查询用物化视图，复杂报表用异步物化视图

Doris 的核心价值在于用极简的部署 + MySQL 协议，覆盖实时数仓和 OLAP 分析两大场景。后续如果需要进一步深入，可以研究：

FE 元数据选主机制（BDB-JE）
BE 向量化执行引擎
CBO 优化器的代价模型
存算分离架构（Doris 3.x Cloud 版）

Doris 学习笔记（一）：基础与架构

Sun, 14 Jun 2026 10:00:00 +0800

写在前面

本文是 Doris 学习笔记系列的第一篇，介绍 Apache Doris 的核心定位、FE/BE 架构、四种数据模型的差异，以及 Docker 部署和基础 SQL 操作。基于 Doris 2.1.x 版本。

一、Doris 是什么

1.1 定义

Apache Doris 是一个高性能、实时的分析型数据库（OLAP MPP 数据库），最初由百度 PALO 项目开源，2018 年进入 Apache 孵化器，2022 年成为顶级项目。

核心特征：
1. MPP 架构      — 大规模并行处理，查询可水平扩展
2. MySQL 协议    — 兼容 MySQL 语法，可用 MySQL 客户端直接连接
3. 实时写入      — Stream Load / Routine Load 支持秒级数据可见
4. 列式存储      — 高压缩比 + 向量化执行，OLAP 查询效率高
5. 不需要外部依赖 — FE + BE 两类节点，部署简单（不需要 Hadoop/Spark）

1.2 解决什么问题

传统离线数仓（Hive / HDFS + Spark）：
  - 数据延迟：T+1，今天看昨天的数据
  - 查询慢：交互式 BI 查询几秒到几十秒
  - 链路复杂：HDFS、YARN、Hive、Spark、Presto……

Doris 试图解决：
  - 实时数仓：Flink/写入 → 秒级 / 分钟级数据可见
  - 高并发查询：单集群可扛上千 QPS 的多维分析
  - 极简运维：FE + BE 两类角色，二进制部署

1.3 同类产品对比

维度	Doris	ClickHouse	StarRocks	Druid
出身	百度 → Apache	Yandex	Doris 商业分支	Apache
SQL 兼容	MySQL 协议	自有方言	MySQL 协议	有限
实时写入	强（Stream Load）	弱（合并机制）	强	中
JOIN 能力	中上（Colocate/Broadcast/Shuffle）	强（大表 JOIN）	强	弱
物化视图	支持	不支持（用 Projection）	支持	支持 Rollup
运维复杂度	简单	中等	简单	复杂

一句话总结：
  - 选 Doris：开箱即用、运维简单、实时 + OLAP 兼顾、生态完整
  - 选 ClickHouse：单表极致性能、JOIN 强大、超大规模
  - 选 StarRocks：Doris 升级版，外表联邦查询更好，性能更激进

1.4 什么是联邦查询

联邦查询（Federated Query） 指查询引擎在查询时直接访问外部异构数据源（MySQL、Hive、Iceberg、Hudi、Kafka、ES 等），把外部表当本地表来查，甚至跨源 JOIN，不实际搬移数据。

订单表在 MySQL + 行为日志在 Doris 本地 + 用户画像在 Hive

→ 一条 SQL 直接 JOIN，Doris/StarRocks 自己协调怎么拉、怎么算

  SELECT m.province, SUM(m.amount), COUNT(DISTINCT l.user_id)
  FROM mysql_catalog.db.orders  m          -- MySQL 外表
  JOIN local.behavior_log       l USING(user_id)  -- 本地表
  JOIN hive_catalog.db.profile  h USING(user_id)  -- Hive 外表
  WHERE m.dt >= '2026-06-07'
  GROUP BY m.province;

联邦查询 vs 传统 ETL：

方式	数据搬移	实时性	维护成本
ETL 进数仓	需要	有延迟（T+1 / 分钟级）	高（多任务 + 调度 + 对账）
联邦查询	不需要	实时	低（建个外表即可）

典型应用：
  - 数据湖分析：直接查 S3/HDFS 上的 Iceberg/Hudi/Delta/Paimon
  - 跨库报表：业务库 MySQL + 数据仓库 Hive 不想 ETL 又想统一查询
  - 避免重复存储：数据湖一份，多个引擎查询

StarRocks 为什么在联邦查询上更强：
  - Catalog 体系成熟早，Iceberg/Hudi/Delta Native Reader 优化激进
    （直接读 Parquet/ORC，不经 Hive Metastore 中转）
  - CBO 优化器对外表统计信息、谓词下推、分区裁剪做得更细
  - 实测 Iceberg 大表查询比 Doris 快 1.5~2 倍

Doris 也补齐了大部分外表能力（Hive / Iceberg / JDBC Catalog 等），
但对数据湖 + 联邦这一块仍以 StarRocks 为优。

二、架构

2.1 整体架构

Doris 是存算耦合架构（2.1 起开始支持存算分离模式，但默认还是存算耦合）。

                    ┌────────────────────────────────────┐
                    │            客户端 / 应用             │
                    │   (MySQL Client / JDBC / Stream)    │
                    └─────────────────┬──────────────────┘
                                      │
                                      ▼
                  ┌───────────────────────────────────────┐
                  │             FE (Frontend)             │
                  │  元数据 / SQL 解析 / 查询计划 / 调度    │
                  │                                       │
                  │  ┌──────┐  ┌──────┐  ┌──────┐         │
                  │  │ FE-1 │  │ FE-2 │  │ FE-3 │         │
                  │  │Master│←→│Follw.│←→│Follw.│         │
                  │  └──────┘  └──────┘  └──────┘         │
                  └─────────────────┬─────────────────────┘
                                    │
              ┌─────────────────────┼─────────────────────┐
              ▼                     ▼                     ▼
        ┌──────────┐          ┌──────────┐          ┌──────────┐
        │   BE-1   │          │   BE-2   │          │   BE-3   │
        │ 存储+计算 │          │ 存储+计算 │          │ 存储+计算 │
        └──────────┘          └──────────┘          └──────────┘

2.2 FE（Frontend）

职责：
  - 元数据管理（数据库、表、分区、副本位置）
  - SQL 解析、查询优化（CBO 优化器）
  - 查询计划生成与调度
  - 元数据高可用（基于 BDB-JE）

角色：
  - Master FE：唯一，负责元数据写入
  - Follower FE：参与选主，可读元数据
  - Observer FE：只读，仅用于扩展查询能力

推荐部署：
  - 至少 3 个 FE（1 Master + 2 Follower），保证多数派可用
  - Observer 用于读扩展，可以任意数量

2.3 BE（Backend）

职责：
  - 数据存储（按 Tablet 分片，副本存放）
  - 查询执行（向量化执行引擎）
  - 数据导入（Stream Load / Routine Load 实际处理者）

存储结构：
  - 物理上：Table → Partition → Tablet → Rowset → Segment
  - Tablet 是数据分片和副本管理的最小单位
  - 默认每张表 3 副本（可配置）

推荐部署：
  - 至少 3 个 BE（满足默认 3 副本分布）
  - 每个 BE 单独部署在一台物理机 / 容器

2.4 一条查询的执行流程

1. 客户端发送 SQL 到任意 FE
2. FE 解析 SQL → 生成逻辑计划
3. CBO 优化器生成最优物理计划
4. FE 将计划分发到 BE 节点
5. BE 并行执行（MPP）
   - 扫描节点（Scan Node）：读本地数据
   - 计算：过滤、聚合、JOIN
   - 数据通过网络 Shuffle / Broadcast
6. 汇总结果到 FE，返回客户端

三、Docker 部署

最快的体验方式是用官方的 Docker 镜像跑一个单机版（1 FE + 1 BE）。

3.1 网络

`1`	`docker network create doris-net`

3.2 启动 FE

docker run -d \
  --name doris-fe \
  --network doris-net \
  -p 8030:8030 \
  -p 9030:9030 \
  -e FE_SERVERS="fe1:172.20.80.2:9010:9020:9030" \
  apache/doris:fe-2.1.7

端口说明：
  - 8030：FE Web UI
  - 9030：MySQL 协议端口（用 mysql 客户端连接）
  - 9010：FE 内部通信
  - 9020：FE 元数据编辑日志

3.3 启动 BE

docker run -d \
  --name doris-be \
  --network doris-net \
  -p 8040:8040 \
  -e BE_ADDR="172.20.80.3:9050" \
  -e FE_SERVERS="fe1:172.20.80.2:9010:9020:9030" \
  apache/doris:be-2.1.7

3.4 添加 BE 到集群

# 用 mysql 客户端连接 FE
mysql -h 127.0.0.1 -P 9030 -uroot
# 默认无密码

# 查看 FE 状态
SHOW FRONTENDS;
# Expected：Alive = true

# 查看 BE 状态（首次为空）
SHOW BACKENDS;

# 添加 BE
ALTER SYSTEM ADD BACKEND "172.20.80.3:9050";

# 再次查看
SHOW BACKENDS;
# Expected：Alive = true，HeartbeatPort = 9050

3.5 Web UI

访问 http://localhost:8030 查看集群状态：

System Info → 看 FE / BE 列表
PlayGround → 直接在网页上跑 SQL

四、数据模型

Doris 提供 4 种数据模型，区别在于"同一主键（或维度）的数据如何处理"。选对模型是 Doris 表设计的核心。

4.1 明细模型（Duplicate Key）

最简单：所有写入的数据原样保留，不合并。适合日志、明细数据。

CREATE TABLE event_log (
    event_time DATETIME NOT NULL,
    user_id    BIGINT,
    event_type VARCHAR(32),
    page       VARCHAR(128),
    duration   INT
)
DUPLICATE KEY(event_time, user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 8
PROPERTIES("replication_num" = "1");

特点：
  - DUPLICATE KEY 仅用于数据排序，不合并
  - 写入即可查，无需任何聚合
  - 适合：原始日志、明细数据

4.2 聚合模型（Aggregate）

预先声明聚合方式（SUM / MIN / MAX / REPLACE / BITMAP_UNION / HLL_UNION），相同 Key 的数据自动合并。

CREATE TABLE user_metric_agg (
    dt          DATE,
    user_id     BIGINT,
    pv          BIGINT SUM,        -- 求和
    uv          BITMAP BITMAP_UNION, -- BITMAP_UNION 计数
    stay_sec    INT MAX              -- 取最大
)
AGGREGATE KEY(dt, user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 8
PROPERTIES("replication_num" = "1");

应用场景：
  - 数据仓库的汇总表（按天/小时聚合）
  - UV 统计（BITMAP_UNION）
  - 适合：查询前数据需要聚合的场景

注意：
  - 写入相同 Key 多次，只保留聚合结果
  - 读取时自动按 Key 再做一次合并

4.3 唯一模型（Unique Key，旧版）

保证主键唯一，后写覆盖前写。适合主键更新场景，但读性能不如主键模型。

CREATE TABLE user_profile (
    user_id     BIGINT,
    name        VARCHAR(32),
    age         INT,
    updated_at  DATETIME
)
UNIQUE KEY(user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 8
PROPERTIES("replication_num" = "1");

特点（旧版 Unique）：
  - 实现：Read 时合并（Merge on Read）
  - 写入：多次写同主键，最后写入的"胜出"
  - 适合：维度表、用户画像（不频繁更新）

性能提示：
  - 旧版 Unique 查询会触发合并，性能不如主键模型
  - 新版本建议优先用 Primary Key 模型

4.4 主键模型（Primary Key，新版推荐）

Doris 1.2+ 引入，真正支持高效 UPSERT 和部分列更新。

CREATE TABLE orders (
    order_id    BIGINT,
    user_id     BIGINT,
    status      VARCHAR(16),
    amount      DECIMAL(10, 2),
    created_at  DATETIME
)
PRIMARY KEY(order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 8
PROPERTIES(
  "replication_num" = "1",
  "enable_unique_key_merge_on_write" = "true"
);

特点：
  - 主键唯一约束，UPSERT 自动覆盖
  - enable_unique_key_merge_on_write = true 时
    → 写时合并（Copy on Write），读性能接近明细模型
  - 支持部分列更新（UPDATE col1 = ... WHERE pk = ...）

应用场景：
  - 订单表（订单状态机：created → paid → shipped）
  - 实时画像（频繁更新某些字段）
  - CDC 同步（MySQL binlog 实时写入）

4.5 四种模型对比

模型	主键语义	合并时机	适合场景	UPSERT 支持
Duplicate	仅排序	不合并	日志、明细	❌
Aggregate	聚合维度	写入 + 读取	汇总表、UV/PV	❌（覆盖语义）
Unique（旧）	唯一	读取时合并	维度表	✅（但慢）
Primary（新）	唯一	写入时合并	订单、画像、CDC	✅（高性能）

选型建议：
  - 日志/原始明细 → Duplicate
  - 已经按维度聚合过的统计表 → Aggregate
  - 需要主键更新（订单/画像/CDC） → Primary Key
  - 旧版 Unique 除非兼容老系统，否则用 Primary 替代

五、基础 SQL 操作

5.1 建库

1
2

CREATE DATABASE demo;
USE demo;

5.2 建表（示例：明细模型）

CREATE TABLE access_log (
    dt         DATE,
    ts         DATETIME,
    user_id    BIGINT,
    page       VARCHAR(128),
    cost_ms    INT
)
DUPLICATE KEY(dt, ts, user_id)
PARTITION BY RANGE(dt) (
    PARTITION p20260601 VALUES [('2026-06-01'), ('2026-06-02')),
    PARTITION p20260602 VALUES [('2026-06-02'), ('2026-06-03'))
)
DISTRIBUTED BY HASH(user_id) BUCKETS 4
PROPERTIES("replication_num" = "1");

关键概念：
  PARTITION（分区）：按 dt 按天分区，便于按时间裁剪和管理
  BUCKETS（分桶）：分区内按 user_id 哈希分桶，控制并行度
  副本：replication_num = 1（单机测试，生产至少 3）

5.3 数据导入

Doris 提供多种导入方式，最常用的是 Stream Load（HTTP 推送）：

# 通过 curl 推送 CSV
curl -u root: -H "label:load_001" \
     -H "column_separator:," \
     -T data.csv \
     http://localhost:8030/api/demo/access_log/_stream_load

-- 也可以在 SQL 客户端用 INSERT 插入
INSERT INTO access_log VALUES
('2026-06-01', '2026-06-01 10:00:00', 1001, '/home', 12),
('2026-06-01', '2026-06-01 10:01:00', 1001, '/list',  35),
('2026-06-01', '2026-06-01 10:02:00', 1002, '/home',  10);

导入方式对比：
  Stream Load   — HTTP 推送，适合小批量 / 实时写入
  Routine Load  — 持续消费 Kafka，做实时数仓
  Broker Load   — 从 HDFS / S3 批量导入
  INSERT INTO SELECT — 从一张表导到另一张表

5.4 查询

-- 普通查询，标准 SQL
SELECT * FROM access_log ORDER BY ts DESC LIMIT 10;

-- 按天聚合
SELECT dt, COUNT(*) AS pv, COUNT(DISTINCT user_id) AS uv
FROM access_log
GROUP BY dt
ORDER BY dt;

-- 窗口函数
SELECT
    user_id,
    dt,
    cost_ms,
    SUM(cost_ms) OVER (PARTITION BY user_id ORDER BY dt) AS cum_cost
FROM access_log;

-- 查看执行计划
EXPLAIN
SELECT dt, COUNT(*) FROM access_log GROUP BY dt;

5.5 表管理

-- 动态新增分区（按天滚动）
ALTER TABLE access_log
ADD PARTITION p20260603 VALUES [('2026-06-03'), ('2026-06-04'));

-- 查看分区
SHOW PARTITIONS FROM access_log;

-- 修改副本数
ALTER TABLE access_log SET ("default.replication_num" = "3");

-- 删除分区（不影响其他分区）
DROP PARTITION p20260601;

六、小结

本文学习了 Doris 的基础：

Doris 是什么，与 ClickHouse / StarRocks 的差异
FE / BE 架构，存算耦合的设计
Docker 部署单机版
四种数据模型（明细、聚合、唯一、主键）的差异和选型
基础 SQL：建库建表、导入、查询、分区管理

下一篇将学习 Doris 的进阶实战：表设计、索引、查询优化、物化视图和典型应用场景。