数仓总线矩阵怎么设计？
面试怎么回答
我会以业务过程为行，以一致性维度为列。先定义下单、支付、退款等稳定业务过程及事实粒度，再统一用户、商品、渠道等维度的主键、层级和历史规则，通过交叉点识别复用关系。矩阵之外还要补充度量口径、负责人、数据质量和变更版本。这样总线矩阵才能成为跨主题域的建模契约，而不是一张静态表格。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
按部门各建一套宽表，短期交付很快。
等到用户、商品、渠道口径需要跨域复用时，冲突才会集中爆发。
总线矩阵的作用，是用业务过程和一致性维度建立跨主题域的复用契约。
纵向先列业务过程
矩阵的行通常是业务过程，例如下单、支付、发货、退款、广告曝光。
业务过程必须是可识别的业务动作，不要直接写 dwd_order_detail、ads_order_summary 这样的物理表名。物理表会调整，业务过程相对稳定。
每个过程还要补充事实粒度。例如“一行代表一笔订单”与“一行代表一个订单商品”不是同一个过程粒度。
横向再列一致性维度
矩阵的列通常是用户、商品、渠道、地区、日期等一致性维度。
所谓一致，不只是字段名相同，还包括主键、编码、层级、历史版本和空值策略一致。否则两个主题域都有 user_id，也不代表能够直接关联。
交叉点表达复用关系
业务过程与维度相交的位置，表示这个过程会使用该维度。
通过交叉关系可以发现：哪些过程应该复用公共维度，哪些维度只属于局部场景，哪些角色扮演维度需要不同语义名称。
例如订单事实可能同时关联下单日期、支付日期和发货日期。它们可以复用同一个日期维度，但业务角色不同。
矩阵不能代替事实表设计
只画勾选关系还不够。每个业务过程仍要定义粒度、度量、可加性、迟到数据、变更策略和负责人。
否则矩阵看起来完整，落表时仍然可能出现重复事实、维度错配和指标口径冲突。
一个典型场景
订单域和广告域分别维护渠道名称。报表跨域分析时，同一个渠道因为编码和层级不同出现两套分类。
通过总线矩阵确认渠道是多个业务过程共享的一致性维度后，再统一渠道主键、来源映射和历史生效规则，跨域指标才具备可比性。
总线矩阵不是项目启动时画一次的文档，而应该进入模型评审、口径变更和影响分析流程。