如何设计一套切实可行的数据仓库呢?
我们要明白，对于数据仓库的设计是不能完全依赖于业务的需求，但往往又必须要服务于业务的价值。
因此，在构建数据仓库前，我们往往会通过总线矩阵设计，来快速理解业务并规划数据仓库体系。以求从宏观的角度来描述企业的业务和数据现状，并指导后续的数据仓库建模。
不妨先来看看，祖师爷 Kimball 在书中对总线矩阵的定义：
总线矩阵：提供一种分解企业DW/BI规划任务的合理方式，行是业务过程，列是公共维度(一致性维度)，图表中的 X 表示的是哪些列与哪些行有关系，也表示这一个业务过程需要有哪些公共维度。
所以，总线矩阵和一致性维度、一致性事实共同组成了 Kimball 的多维体系结构基础。
在这种多维体系结构(MD) 的数据仓库架构中，主导的思想便是分步建立数据仓库，并由数据集市组合成企业的数据仓库。
但是，在建立第一个数据集市前，架构师首先要做的就是设计出在整个企业内具有统一解释的标准化的维度和事实，即一致性维度和一致性事实，而开发团队必须严格的按照这个体系结构来进行数据集市的迭代开发。
如果我们在建立数据仓库之初，只考虑单独的某个业务系统的数据建设，不仅无法满足一致性目标的。还会使相互有联系的系统数据由于维度不同导致关联复杂或者关联不上，数据之间互相成为了孤岛，这对于后期的扩展或者整个数仓的建设都是巨大的阻碍。
一致性维度就好比企业范围内的一组总线，不同数据集市的事实的就好比插在这组总线上的元件。
这也是称之为总线架构的原因。因此实际设计过程中，我们通常把总线架构列表成矩阵的形式，其中列为一致性维度，行为不同的业务处理过程，即事实，在交叉点上打上标记表示该业务处理过程与该维度相关，这个矩阵也称为总线矩阵(Bus Matrix)。
了解总线矩阵设计的必要性，它的作用就很容易理解了。简单来讲无非是以下三点：
帮助数据架构师清晰地梳理整个数据体系
帮助决策者(Boss)从宏观的角度了解数据仓库的整体情况
让所有的数据仓库参与者了解数据仓库的设计
如何编写总线矩阵?
首先，总线矩阵不是代码，也不是纯文档性质。在构建总线矩阵对过程中，也需要完成许多代码开发前期的准备工作。
首先完成横向，即 数据域划分，业务过程的确立。数据域是一种对数据的抽象，通过将联系较为紧密的数据划分在同一数据主题中，方便寻找和使用数据。
比如，制造业中，我们可以将数仓划分为：生产、财务、人力、供应链、交付等数据域，每个域下包含不同的业务过程。如生产域下包括生产计划、实际生产、设备停机等业务。
通常是先确定业务过程有哪些，再按照某个规则将相关的业务划分为同一数据域中，常用的规则有：按业务相关性、按需求方、按应用划分等。也可以将数据域划分为多级主题，比如先按照部门划分一级主题，再按业务划分二级主题。
数据域的划分没有对错，根据实际情况进行划分，让数据归纳更清晰，更好找易用就是好的数据域划分。划分数据域时，可参考这些规则：数量不能太多，建议不超过10个;不同主题间无重叠业务过程;具有一定前瞻性，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或扩展新的数据域。
其次完成纵向列，即公共一致性维度的划分以及度量值的确定。维度是我们看世界的角度，度量则是形容指标的水平，他们都是指标的重要组成。比如有个指标：“四月交付2000辆车”，“四月”和“车”是维度，“2000”是度量值，“辆”则是度量单位，维度和度量组合在一起形成月度指标。如果没有维度，“交付2000辆”则啥也代表不了。
维度的划分具有行业共同性，比如电商行业通常涉及这些维度：买家、卖家、订单、广告、货运、支付等，制造业中：设备、产线、项目、物料、车型等，还有一些跨行业通用的维度，如城市、日期等。维度的一致性是数据一致性的重中之重，总线矩阵是一致性维度建设的重要文件。从讨论总线矩阵的那刻开始，数仓数据一致性问题就解决了一半。
总线矩阵中的度量通常是原子指标，指业务过程中最基本的原子指标。比如生成计划业务过程中，度量是“件数”，设备停机事件中，度量为“停机时长”。总线矩阵中描述的度量，能够给分析人员直观的了解目前数据具备的分析能力。
最后是确定业务过程同维度间的关联关系。应该分析每个业务过程，尽可能多的关联维度与业务过程，而不仅仅是当前分析需要哪些维度，否则就陷入了面向需求开发的陷阱。
业务矩阵编写完成后，应组织多方参与评审，包括业务方、分析人员、架构师、产品经理等，以确定业务矩阵的最终版本。
优点
总线矩阵是数仓建设的纲领性文件，不论是从零开始一个项目，还是中途接手一个项目，总线矩阵总是最好的切入点。
总线矩阵有利于主数据管理。核心维度由数据管理责任人定义，在多个业务过程中使用，而不是被单一业务过程或部门定义，提供一致性维度，实现跨业务过程钻取的需求。总线矩阵列表示整个企业的公共维度，有助于创建核心维度列表，解决主数据管理和数据集成的需求。
总线矩阵有利于项目规划和排期。总线矩阵将业务过程按主题划分，每个主题下包含多个业务过程，各个主题中业务过程互不重叠。不同开发小组遵循该架构进行异步独立开发，每个小组承担不同数据域或同一数据域下不同业务过程，也可以进行一致性维度开发，从而实现增量式的开发。不同小组间分工更加清晰，每个人对自己在组织中承担的任务也更明确。
总线矩阵是数据一致性的重要保障。总线矩阵提倡从初期规划一致性维度，各业务过程共享一致性维度。通过一致性维度，确保维度的有序建设，减少冗余的出现。总线矩阵提供一目了然的维度能力观察，让后面开发的同学了解现有数仓数据，减少烟囱式建设的可能性。
总线矩阵可以避免面向需求开发。总线矩阵要求我们基于业务过程建设数仓，要求我们从全面的角度考虑维度建设。避免了拿到需求后盲目建设的情况，也避免后期不停维护扩展。
总线矩阵是数仓建设过程中各种角色间的沟通桥梁。架构师通过总线矩阵描述项目概况，进行任务分工;建模人员通过总线矩阵了解项目中一致性维度与业务过程关系，开展建模工作;项目经理通过总线矩阵，了解项目规模，进行排期安排，进度跟进;BI同学通过总线矩阵，了解数仓包含的业务过程与支持钻取的维度。通过总线矩阵，简化不同角色人员间沟通，更好的实现不同组织的工作配合。
基于上述优点，我认为总线矩阵是数仓建设中最重要的文档，应当由架构师在项目初期负责建设，并且长期维护和全局共享。
