数据仓库系列文章二：浅谈企业数据仓库总线矩阵

Kinball在《数据仓库工具箱》一书中，详细阐述维度建模思想，并给出维度建模的众多实践。维度建模的核心内容和建设过程在实践中已经被大家所熟知，网上教程也很多，本文不做赘述。本文重点谈一谈企业数据仓库总线矩阵。

企业数据仓库总线矩阵，又称为“总线矩阵”、“业务矩阵”，是Kinball在《数据仓库工具箱》一书中提出的，指导维度模型建设的规划性文件。

为什么要谈企业数据仓库总线矩阵，一方面是它在数仓建设中非常重要，是纲领性的文件，是数仓最重要的文档交付物（Kinball认为是最重要的交付物之一，我认为可以把“之一”去掉）；另一方面，实际工作中发现很少有人提到总线矩阵更谈不上在工作中规划这份文件，更多是直接上手开发后期不停维护的节奏，希望这篇文章能让更多人了解和实践起来。

什么是企业数据仓库总线矩阵

先看示例，一家商品零售商的业务矩阵：

 图片来源于《数据仓库工具箱》一书。

总线矩阵包含业务过程、公共一致性维度。每行代表一个业务过程，每列表示一个公共维度，还包括业务过程与维度间的联系，图中每个叉号表示该业务过程与维度具有关联关系，也就是我们通常说的外键。

还可进一步扩展业务矩阵，加入主题划分和业务过程包含的度量值。如下图，某智能制造工厂业务矩阵：

主题	维度 业务过程	工厂	产线	项目	物料	日期	班次	度量
生产	生产计划	√	√	√	√	√		件数
	实际生产	√	√	√	√	√		件数
	设备停机	√	√	√		√	√	次数/时长
…	…

该工厂总线矩阵划分为生产、供应链、财务等主题，每个主题对应不同的业务过程，相互间不重叠。如生产主题中，包括生产计划、实际生产和设备停机等业务过程。

总线矩阵每个列代表维度，如：工厂、产线、物料等维度，这些维度将全局共享。

总线矩阵中每个√（也可用×表示）符合表示该业务过程同该维度关联，比如设备停机事件，相关的维度有设备所在工厂、所属产线、停产日期与停产班次。而设备和项目与物料并无直接关系，体现在总线矩阵中没有用√关联。

度量是该业务过程中包含的事实，如设备停机中次数和时长都是描述该业务过程的度量值。

如何编写业务矩阵

业务矩阵不是代码，但也不是纯文档性质，完成业务矩阵的过程中，也需要完成开发代码前期的许多准备工作。

首先完成横向，即主题域划分，业务过程的确立。主题域是一种对数据的抽象，通过将联系较为紧密的数据划分为同一主题，方便寻找和使用数据。比如，智能制造工厂中，我们将数仓划分为：生产、财务、人力、供应链、交付等主题，每个主题下包含不同的业务过程。如生产主题下包括生产计划、实际生产、设备停机等业务。通常是先确定业务过程有哪些，再按照某个规则将相关的业务划分为同一主题，常用的规则有：按业务相关性、按需求方、按应用划分等。也可以划分为多级主题，比如先按照部门划分一级主题，再按业务划分二级主题。主题域的划分没有对错，根据实际情况进行划分，让数据归纳更清晰，更好找易用，就是好的主题划分。划分主题域时，可参考这些规则：数量不能太多，建议不超过10个；不同主题间无重叠业务过程；具有一定前瞻性，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或扩展新的数据域。

其次完成纵向列，即公共一致性维度的划分以及度量值的确定。维度是我们看世界的角度，度量则是形容指标的水平，他们都是指标的重要组成。比如有个指标：“四月交付2000辆车”，“四月”和“车”是维度，“2000”是度量值，“辆”则是度量单位，维度和度量组合在一起形成月度指标。如果没有维度，“交付2000辆”则啥也代表不了。

维度的划分具有行业共同性，比如电商行业通常涉及这些维度：买家、卖家、订单、广告、货运、支付等，智能工厂中：设备、产线、工站、项目、物料、供应商等，还有一些跨行业通用的维度，如城市、日期等。维度的一致性是数据一致性的重中之重，总线矩阵是一致性维度建设的重要文件。我的观点是从讨论总线矩阵的那刻开始，数仓数据一致性问题就解决了一半。

总线矩阵中的度量通常是原子指标，指业务过程中最基本的原子指标。比如生成计划业务过程中，度量是“件数”，设备停机事件中，度量为“停机时长”。总线矩阵中描述的度量，能够给分析人员直观的了解目前数据具备的分析能力。

最后是确定业务过程同维度间的关联关系。应该分析每个业务过程，尽可能多的关联维度与业务过程，而不仅仅是当前需求需要哪些维度，否则就陷入了面向需求开发的陷阱。

业务矩阵编写完成后，应组织多方参与评审，包括业务方、分析人员、架构师、产品经理等，以确定业务矩阵的最终版本。

优点

总线矩阵是数仓建设的纲领性文件，不论是从零开始一个项目，还是中途接手一个项目，总线矩阵总是最好的切入点。

总线矩阵有利于主数据管理。核心维度由数据管理责任人定义，在多个业务过程中使用，而不是被单一业务过程或部门定义，提供一致性维度，实现跨业务过程钻取的需求。总线矩阵列表示整个企业的公共维度，有助于创建核心维度列表，解决主数据管理和数据集成的需求。

总线矩阵有利于项目规划和排期。总线矩阵将业务过程按主题划分，每个主题下包含多个业务过程，各个主题中业务过程互不重叠。不同开发小组遵循该架构进行异步独立开发，每个小组承担不同主题或同一主题下不同业务过程，也可以进行一致性维度开发，从而实现增量式的开发。不同小组间分工更加清晰，每个人对自己在组织中承担的任务也更明确。

总线矩阵是数据一致性的重要保障。总线矩阵提倡从初期规划一致性维度，各业务过程共享一致性维度。通过一致性维度，确保维度的有序建设，减少冗余的出现。总线矩阵提供一目了然的维度能力观察，让后面开发的同学了解现有数仓数据，减少烟囱式建设的可能性。

总线矩阵可以避免面向需求开发。总线矩阵要求我们基于业务过程建设数仓，要求我们从全面的角度考虑维度建设。避免了拿到需求后盲目建设的情况，也避免后期不停维护扩展。

总线矩阵是数仓建设过程中各种角色间的沟通桥梁。架构师通过总线矩阵描述项目概况，进行任务分工；建模人员通过总线矩阵了解项目中一致性维度与业务过程关系，开展建模工作；项目经理通过总线矩阵，了解项目规模，进行排期安排，进度跟进；BI同学通过总线矩阵，了解数仓包含的业务过程与支持钻取的维度。通过总线矩阵，简化不同角色人员间沟通，更好的实现不同组织的工作配合。

基于上述优点，我认为总线矩阵是数仓建设中最重要的文档，应当由架构师在项目初期负责建设，并且长期维护和全局共享。

误区

在设计总线矩阵过程中，稍不留意便可能进入误区，影响产出质量。

不应当含有太多行，只选择感兴趣的业务过程作为矩阵的行。不重要、不需要分析的业务过程不包含在总线矩阵中，比如设备停机事件，引起设备停机原因可能有设备故障、人员缺勤，如果只需要分析设备停机原因，业务过程包括选择设备停机事件，而不需要把人员缺勤记录作为业务过程。当然业务事件是否是矩阵的行不是一成不变，比如人员考勤事件，如果人事部门需要分析考勤记录，就是我们感兴趣的业务过程。反之人事部门不需要，则不记录在矩阵行中，并且后续在人事部门需要分析时加入矩阵行中。

业务矩阵的建设应该基于业务过程，而非报表需求或分析。在实际工作中，通常会有一份完整的需求文档，罗列分析需求，并将分析需求拆分为多级的指标。不应针对每个需求建立业务矩阵的行，通常来说单个业务过程可以支持多个需求。例如在智能工厂建设中，业务人员有两个重要指标需求：设备计划外停机时间和设备计划内停机时间，计划外停机包括一些事件如设备故障、物料短缺等，计划内停机包括例行检修等。不应根据需求在业务矩阵中增加2行，而是增加一行为设备停机事件，将设备停机视为一整个业务过程。

深入分析需求，但不要面向需求建设维度模型。业务矩阵应该基于业务过程，即使没有需求我们也可以搭建业务矩阵。个人认为业务需求更多的是表明当前业务部门关注哪些业务过程，我们需要优先建设哪些业务过程的数据，即优先选择哪些业务过程组成业务矩阵的行。反应在工作量上，20%的时间分析需求，40%的时间了解业务系统和数据探查，40%的时间花在数据开发中。和BI对接的时间应当归属于分析需求中，如果发现和BI同学对接的时间占了50%以上的时间，你应该反思是不是在面向需求建设数仓。

总线矩阵的列代表维度，每列的定义应该是清晰具体的，不应太宽泛。比如“人”这个概念可能包含公司员工、上游供应商代表、下游购买合同客户等，这些群体间几乎没有重叠，并且关注不同的属性，将他们划入单一的、一般化的维度中将产生混乱。

将层次的每个级别放入一个列，而不是不同列。比如日期维度，年、月、日不应分为3个列作为3个维度存在，而是保存最小级别的维度，即只存在日维度这一个列。这种设计也称为维度表的层次整合。

总结

基于工作中碰到的情况，网上总线矩阵的介绍文章比较少，本篇文章有感而发。希望看到本篇文章后的数据开发同学，能在工作中良好运用总线矩阵，逐渐体会到它带来的好处。