第3章 数据模型与建表实战
第 3 章 · 数据模型与建表实战
章节摘要：这一章讨论一个老生常谈却决定成败的问题——这张表该怎么建。三种表模型的取舍逻辑、索引组合的成本收益、分区与分桶的数量估算，最终都收敛到同一个判断标准：让高频查询付出的 IO 尽可能少，让持续导入留下的版本碎片尽可能可控。最后一节用一张真实订单宽表把全部决策串成一次完整复盘。
学习目标
完成本章后，你应当能够：
- 面对任何一份业务口径文档，独立判断该用 Duplicate、Aggregate 还是 Unique 模型；
- 为 Unique 表选择读时合并或写时合并，并说出切换的代价；
- 设计一套排序列、ZoneMap 与 Bloom Filter 的最小充分索引组合；
- 用数据量与保留期推算分区粒度和桶数，而不是抄别人的模板；
- 复盘一张生产级大宽表的建模全过程并迁移到自己的场景。
核心概念速览
Doris 建表的三层结构像一棵倒置的决定树：先按数据的更新语义选表模型（决定读写成本的分摊方式），再在物理布局上做两级切分（分区管生命周期与裁剪边界，分桶管并行度与打散），最后为高频过滤列配备索引（免费的排序前缀优先，付费的精确索引按需）。每一层的失误都会被上层放大：模型选错，后期只能重建；分桶偏斜，加机器也救不了热点。
金句：表设计不是技术题，是把业务的读写曲线翻译成存储参数的翻译题。
翻译过程里最值钱的一个数字是"单桶一百万到一千万行"这条经验带。桶数决定并行度上限：一个每天千万行的分区按天分区后配十个桶，每个桶恰好落在经验带内；同样的桶数给一个日增五亿行的分区，单桶五千万行，扫描并行度与桶内压缩双双劣化。建表评审时先算这笔账——数据量的预估值、保留期、期望扫描并发，三个数一除，分区粒度与桶数自然浮出来，比背任何模板都稳。
子章节导航
- 3.1 表模型设计与取舍：三种模型的语义差异、代价结构和真实案例里的翻车现场。
- 3.2 存储结构与索引内幕：从 Rowset 到行组的物理形态，四类索引如何分工剪枝。
- 3.3 分区与分桶策略：两级切分的职责划分、数量估算公式与动态演进机制。
- 3.4 订单大宽表建模复盘：一次完整的建表拍板记录，从需求澄清到上线验收逐项留痕。
子章节之间的逻辑关系
顺序即依赖：模型语义定了读写账本（3.1），物理组织要同时迁就这份账本与扫描规律（3.2），两级切分则是把前面所有约束落到集群资源上（3.3），复盘一节（3.4）把三者折叠回同一条时间线：
语义选型 → 物理布局 → 切分布局 → 真实案例对账 3.1 3.2 3.3 3.4
前置知识与后续延伸
你需要第 2 章 BE 一节的 Rowset 概念作为地基；不要求熟悉任何特定行业。学完本章直接进入第 4 章最自然——表建好了，怎么把数据正确高效地灌进去就是下一个必答题；此后每逢第 5 章调优遇到"为什么这个 Join 慢"，也都能回到本章找到根因。
把本章的四节当成四次拍板来读会更有效：3.1 拍的是语义（数据以什么身份被合并），3.2 拍的是布局（行怎么排、索引怎么配），3.3 拍的是切分（分区粒度与桶数），3.4 拍的是整体（一次真实的全流程对账）。四次拍板的价格递减但频率递增——模型错一次伤全表，桶数偏一点只是利用率损失，理解这个梯度，你就知道评审时该在哪里寸步不让、哪里可以妥协。
还有一个建议：读完本章后，挑自己业务里最贵的一张表，用 3.4 的复盘模板反着做一次"审计"——当初每个参数为什么这么定、现在数据分布变了没有、哪些决策需要重拍。正向建模练的是推导，反向审计练的是发现，两种能力合起来才算真正过了第 3 章。