考察点
这道题考的是方法论层面的规划能力，通常在中高级岗位或聊「你从 0 怎么搭数仓」时出现。面试官想看到你知道建模之前还有一步顶层设计，而不是接到需求就建表。追问常落在「矩阵具体怎么画」「数据域怎么划分、划错了会怎样」。
参考答案
总线架构与总线矩阵
Kimball 的总线架构（Bus Architecture）核心主张是：数仓不是一个项目建出来的，而是按业务过程逐个增量建设，但要让这些独立建设的数据集市最终能拼成一个整体，前提是它们遵守同一套「总线标准」——共享的一致性维度和一致性事实。
总线矩阵（Bus Matrix）就是这个标准的可视化产物：一张二维表，行是业务过程（每张事实表），列是公共维度，交叉单元格打勾表示这个事实表用到这个维度。
日期 用户 商品 店铺 地区 渠道 营销活动
下单 ✓ ✓ ✓ ✓ ✓ ✓ ✓
支付 ✓ ✓ ✓ ✓ ✓
退款 ✓ ✓ ✓ ✓ ✓
曝光 ✓ ✓ ✓ ✓ ✓
点击 ✓ ✓ ✓ ✓ ✓
库存快照 ✓ ✓ ✓ ✓
矩阵什么时候画、解决什么问题
总线矩阵在详细建模之前画，和业务方、数据团队一起评审确认，它一次解决四个问题：
- 划清建设范围：矩阵的行就是要建的事实表清单，列就是要建的公共维表清单，一张图就是整个数仓的蓝图；
- 排建设优先级：看列——被最多业务过程打勾的维度（日期、用户、商品）是公共性最强的，必须先建；看行——业务价值最高、数据最现成的业务过程先建；
- 暴露维度共享点：下单和支付都打勾了「用户」列，意味着这两张表必须用同一个用户维度，建模时就要保证一致性，而不是各建各的；
- 支持增量演进：新业务过程上线就是矩阵加一行，对照已有列看哪些维度可复用、哪些要新建，架构不推倒重来。
数据域划分
数据域是对业务过程的聚类分组，把面向业务、高内聚的过程归到一个域里，作为数仓组织和分工的边界。常见划分（以电商为例）：交易域（下单、支付、退款、履约）、流量域（曝光、点击、浏览、搜索）、用户域（注册、登录、会员成长）、商品域（上下架、类目变更）、营销域（领券、活动参与）、客服域、风控域。
划域的依据是业务过程天然亲和性：下单和支付强关联、经常联合分析，就该在一个域；曝光点击和交易关联弱、数据量级差几个数量级，分开管。划域有几个工程影响：
- 对应表命名和库结构：
dwd_trade_order_detail、dwd_traffic_page_view，域是命名规范的第一段； - 对应团队分工：大团队按域划分 owner，域内表由固定小组维护，跨域共享靠一致性维度；
- 粒度差异隔离：流量域是天量级明细，交易域是千万级，调度优先级、存储策略、生命周期都不同，分开治理。
域划错的代价不小：两个强关联的过程分到不同域，跨域引用没人负责，最后长出重复表；域划得太细（十几个域）则管理开销压过收益。实践上中型公司 5-10 个域比较合适。
落地建议
从零搭建时的顺序是：先和业务方访谈梳理业务过程清单 → 提炼候选公共维度 → 画出总线矩阵评审 → 按亲和性聚类成数据域 → 按矩阵定维表和事实表建设顺序。矩阵不是一次性文档，新业务上线要维护更新，它是数仓的「活设计图」。很多团队建模混乱的根源不是不会维度建模，而是跳过了这一步，直接建表建到哪儿算哪儿。
可能的追问
- 总线矩阵和星型模型里的「星座」什么关系？ 矩阵是规划视图，星座是实现结果：按矩阵建出来的多张事实表共享公共维度，物理上就形成了星座模型。矩阵回答「该建成什么样」，星座是「建成后的样子」。
- 数据域和业务部门是一一对应的吗？ 不是。域按业务过程划分，一个部门可能横跨多个域（运营部既看交易又看营销），一个域也可能服务多个部门。按部门划域是按组织边界妥协的做法，容易导致重复建设。
- 矩阵里出现某列只被一个过程打勾怎么办？ 说明这个维度公共性弱，可能是该过程私有的。先确认是不是真公共维度，私有的不必进入公共维度清单，直接在该事实表内退化即可。