Inmon 和 Kimball 到底差在哪？别在建模流派上吵架
数仓圈有个老话题，隔一阵就会被翻出来吵一次：到底该学 Inmon，还是学 Kimball？
我见过两种常见的现场。
第一种：先做"企业级数据模型"。 团队花几个月画实体关系图，评审了一轮又一轮。业务那边等不及，各自在表格里、在手写 SQL 里把数拉出来了。等模型终于出来，已经没人再需要它。
第二种：来一个需求，建一张宽表。 来一个需求，再建一张。半年后，"客户"这个词有四张表、四种写法，同一个"放款金额"能出四个数。
▲ 两种常见的现场：一个只做了整体，一个只做了局部
这两种都不是流派选错了，而是只记住了流派的一半。下面把两边的思路讲清楚，再说怎么取舍。
一、先用大白话说清楚两种思路
Inmon：先整体，后局部。 先把全公司的数据，按"实体"（客户、账户、合同、交易）整理进一个规范的企业级仓库，尽量符合三范式，存最细粒度的数据。各部门要用，再从这个仓库里派生出"数据集市"。
打个比方：先修好总水厂，再给每个小区接水管。
Kimball：先局部，用规则拉齐。 不先管全公司，而是挑一个业务过程（放款、还款、催收），围绕它建"事实表加维度表"，建好就能用。下一个业务过程来了，再建一套，但共用同一批维度。
打个比方：先给每个小区修水塔，但所有水塔用同一套水质标准。
放到信贷场景里，Kimball 的产物大概是这样：
· 事实表：放款、还款、逾期、催收......（每个业务过程一张）
· 维度表：客户、产品、渠道、日期......（大家共用）
▲ 总水厂与多座水塔：同一个比喻的两种顺序
二、真正的分水岭：遇到问题时，两边怎么处理
比起背定义，更有用的是看它们遇到同一个问题时的行为差异：
| 遇到的问题 | Inmon 的做法 | Kimball 的做法 |
|---|---|---|
| 业务要一张新报表 | 先看企业模型里有没有，没有就先补模型，再派生集市 | 找到对应的业务过程，建事实表，复用现有维度 |
| 两个部门口径不一致 | 在企业模型里统一定义，集市只读 | 在"一致性维度"和公共指标上统一，需要有人拍板 |
| 多久能交付第一个结果 | 偏慢，要先有企业模型 | 偏快，一个业务过程就能交付 |
| 最大的风险 | 周期太长，等不到价值就耗光耐心 | 各建各的，最后变成一堆孤岛 |
两边的风险正好相反：Inmon 怕"做不完"，Kimball 怕"做散了"。
三、Kimball 怎么避免"做散"：一致性维度和总线矩阵
很多人以为 Kimball 就是"想建就建"。其实它有一个关键的约束工具，叫总线矩阵。
画法很简单：行是业务过程，列是维度，用到了就打个点。信贷场景的示意：
▲ 总线矩阵：同一列全公司只有一份定义
怎么读这张表：
· 每一行是一个业务过程，将来对应一张或几张事实表。
· 每一列 是一个维度，同一列全公司只允许有一份定义。"客户"这一列，不管放款用还是催收用，指的是同一张客户维表。
· 新增一个业务过程时，先看它要用哪几列。已有的直接复用，没有的才新建。
这张表不到一页纸，却回答了"企业级整体设计"的大部分问题，成本小得多。它是 Kimball 路线里，把"局部先行"和"整体一致"粘在一起的那层胶水。
四、为什么多数业务驱动的团队，最后走的是 Kimball
原因很朴素：需求导向、自下而上、见效快。
完整的 Inmon 路线，需要几个前提：有人长期负责企业级模型，业务相对稳定，上面愿意等。多数业务驱动的团队，这三条至少缺一条。
但要特别提醒："走 Kimball"不等于"不管整体"。 下面三件事不能省：
-
一致性维度：客户、产品、日期这类公共维度，全公司只有一份。
-
统一口径的公共指标：放款金额、逾期率这类，不允许各部门各算一遍。
-
矩阵先行：新需求来了，先对着矩阵看，不要直接建表。
这三件事不做，Kimball 就退化成了开头的第二种现场。
五、现实里最常见的是混合
纯 Inmon 或纯 Kimball 的团队其实不多，更常见的是混合：
· 公共层偏规范化，吸收 Inmon 的思路：把底层数据整理干净、整合一致，不为某个报表服务。
· 应用层偏维度化，吸收 Kimball 的思路：按业务过程组织，方便分析和取数。
这也是分层架构背后的出发点：下面求"一致"，上面求"好用"。
六、怎么选：先问三个问题
▲ 先问三个问题，再决定从哪条路起步
-
业务变化快不快？ 变得快，倾向 Kimball，别指望一次设计到位。
-
有没有人长期负责企业级模型？ 没有，就别走完整的 Inmon，没人维护的企业模型会很快过时。
-
现在的痛是"慢"还是"乱"？
· 痛在"慢"：先用 Kimball 的方式，一个业务过程一个业务过程地交付。
· 痛在"乱"（口径不一致）：先补一致性维度和公共指标，再谈别的。
七、几个常见误解
· "维度建模就是建宽表"：不是。宽表只是产物之一，维度建模的核心是事实表与维度表的分工，以及维度的共用。
· "Inmon 过时了"：做法可能不常用，但思想没过时。数据治理里讲的"企业级统一定义"，内核就是它。
· "选了流派就不能换"：现实是混用，也会随团队阶段演进。
小结
两个流派不是对立面，而是回答同一个问题的两种顺序：
· Inmon：先把整体理顺，再往下分；
· Kimball：先把一块做出来，用一致性维度把各块拉齐。
多数业务驱动的团队，适合从 Kimball 起步，同时把一致性维度和公共指标这两道关守住。
你们团队走的是哪条路？有没有遇到过"模型出来时需求已经没了"，或者"同一个词四种写法"？欢迎在评论区聊聊。
附：总线矩阵模板
| 业务过程 \ 维度 | 维度 1 | 维度 2 | 维度 3 | 维度 4 | 维度 5 |
|---|---|---|---|---|---|
| 业务过程 1 | |||||
| 业务过程 2 | |||||
| 业务过程 3 |
填表规则
· 行写业务过程，一行对应一类事实表。
· 列写公共维度，同一列全公司只保留一份定义。
· 用到就打点；新增一行前，先检查它要用哪些列，没有的列才新建。
· 每一列写上维度的责任人。