刚接手数据建模的活，最容易卡在两件事上：分层到底分几层、每层该放什么；概念模型、逻辑模型、物理模型这三样到底谁先谁后、各自适合什么场合。这篇不背概念定义，只给分层对照表、三要素取舍判断和一套从上到下的推进顺序，让你在需求评审和建表评审上都能说清楚自己这一步在干什么。
刚接手数据建模的活，最容易卡在两件事上：分层到底分几层、每层该放什么；概念模型、逻辑模型、物理模型这三样到底谁先谁后、各自适合什么场合。这篇不背概念定义，只给分层对照表、三要素取舍判断和一套从上到下的推进顺序。
先记住一个前提：分层和三要素都不是目的，是为了让「业务怎么理解」和「机器怎么存」这两件事可以分开改。想清楚这一点，后面每层放什么、每步做什么，判断标准就都能自洽了。
先想清楚为什么要分层，再动手分
分层的本质是把业务理解和物理存储拆开。业务口径改了，改的是中间某一层，底层原始数据不动、下游任务也不用全部重跑。不分层最常见的结果是：需求一变更，改一张表牵动几十个下游任务，时间一长没人敢动那张表，模型就僵住了。
分层的代价也要提前说清楚：链路变长、数据多落几次，链路的端到端延迟会上升，存储和计算成本也会增加。所以别默认「分层一定更好」，先看变更频率和下游消费者数量。
- 变更频率高、下游消费者多的域，值得花时间分层，把口径收敛到中间层
- 一次性的临时取数、用完就丢的分析，直接建表更省事，套分层是负担
- 实时性要求很高的链路要谨慎，多一层落地就多一次写和一次读
- 数据量很小、团队维护力量薄弱的场景，分层过多反而没人维护得过来
分层怎么切：每层该放什么、不该放什么
实操里层数不用死记，但每层的职责边界要清晰。下面这张对照表可以直接拿去评审时用，左边是层，中间是职责，右边是常被误放进去的东西。
| 层级 | 该放什么 | 不该放什么 |
|---|---|---|
| 贴源层 | 最小清洗、保留原始字段与来源标识 | 业务口径换算、指标计算 |
| 明细层 | 原子粒度事实，一行一件事，可追溯可重算 | 跨主题的汇总值 |
| 汇总层 | 按主题聚合、服务固定报表与分析口径 | 明细级的原始日志 |
| 应用层 | 直接对接看板与接口的薄表 | 复杂计算、多步嵌套逻辑 |
判断某一层是不是切歪了，有个简单的问法：这一层的每行数据，粒度是不是一致的？如果一张表里既有订单粒度的行，又混着按天汇总的行，那基本就是两层逻辑挤在了一起。
- 先定粒度对着业务问一句「一行代表什么」，把答案写下来；如果一句话说不完整，说明粒度还没定清楚。
- 再定主键粒度定完，主键自然浮出来。验证方法：拿两个真实样本，看主键能不能唯一区分。
- 最后定清洗边界哪些字段是原样透传、哪些是标准化处理，列表写清；下游看到不一致时能回头查这一步。
三要素的优缺点：概念、逻辑、物理各管一段
概念模型、逻辑模型、物理模型不是三选一，而是三道工序。把它们当成从「业务说得清」到「机器跑得动」的连续过程，很多争论就没必要了。
- 概念模型
- 只描述实体、关系和核心属性，优点是不懂技术的人也能看懂，缺点是精度低，不能直接拿去建表
- 逻辑模型
- 把实体细化到属性、主键、粒度，和具体数据库无关，优点是口径确定可评审，缺点是需要业务和开发共同投入时间
- 物理模型
- 落到具体引擎的表结构、类型、分区、索引，优点是能执行能优化，缺点是和技术绑定，换引擎要改一部分
最常见的坑是跳过概念模型直接建物理表。短期看不出问题，几周后会发现同一件事在不同表里叫不同名字，字段含义也对不上。想避免，就在立项阶段留一次概念模型的评审，哪怕只画几张实体关系图。
反过来，也不要停留在概念模型不往下走。业务方确认完实体关系之后，必须有人把它翻译成属性和粒度，否则后面建表还是各写各的。评估工具、引擎选型这类事，可以到 工具目录（/tools/speed-test） 里对照着看，别在概念阶段就纠结实现细节。
推进顺序与自检清单
顺序建议很朴素：先和业务对齐实体与关系，再定主键与粒度，最后才选类型、分区与索引。倒过来做，也就是先选引擎再想业务，通常会在第一次需求变更时翻车。
推进过程中，下面三个自检问题建议每次评审都过一遍。它们不解决所有问题，但能挡住大部分低级错误。
- 每个字段的粒度是不是都一样？有没有把上层汇总值混进明细表
- 同名字段在不同表里含义是否一致？不一致就该改名或加前缀，别靠注释解释
- 新增一个业务维度时，需要改几张表、几个下游任务？数量过多说明分层切错了
如果你在建表前想参考同类系统的字段命名和口径习惯，可以到 评测与排名（/rankings） 看看别人怎么组织公开模型信息，再去 价格追踪（/price-watch） 核对当时的成本口径，别凭印象拍数字。
什么情况下不用套这套框架
前面讲的都是通用判断，但有些场景套上去是过度设计。下面几类情况可以例外，例外的前提是你要清楚放弃的是什么。
- 临时分析、一次性导出、生命周期很短的内部工具，直接建宽表更快
- 数据量很小的内部小工具，分层的收益抵不过维护成本
- 强实时链路里多层落地会拉高延迟，可以考虑在流处理里做轻量分层
- 团队只有一两个人维护时，先保证口径统一，层数往后放
还有一种情况要单独说：如果这个模型只是为了喂一个模型训练任务或一次活动，用完就下线，那么直接把字段摊平反而更清晰。分层是给长期演进的模型准备的，不是给一次性任务准备的。
下一步把你这套模型的层数和每层职责写成一句话，再对照站内的模型资料和成本口径核一遍，很多分歧在写下来的那一刻就暴露了。→常见问题
三层模型必须都做一遍吗？
不必。需求明确、改动少的小项目可以直接从逻辑模型进物理模型。但只要涉及多方对口径、或者后续会继续扩展，先做概念模型能省下大量返工，重点是别把概念模型当成必须交付的文档，它更像一次对齐会议。
逻辑模型和物理模型能不能合并？
可以合并，但要清楚代价。合并后口径和技术细节混在一张图里，业务方看不懂，评审时也容易变成讨论字段类型而不是讨论业务定义。如果只有开发者参与、业务稳定，合并推进完全可行。
分层越细是不是越好？
不是。每多一层就多一次落库和一份维护成本，排查问题时链路也更长。判断标准是这一层有没有独立且稳定的消费者，没有就并入相邻层。分层是为了隔离变更，不是为了图上好看。
