第十六章：数据治理之数据架构：数据模型和数据流转关系

本章我们说一下数据架构，说到数据架构，就很自然的想到企业架构、业务架构、软件架构，因为个人并没有对这些内容进行深入了解，所以这里不做比对是否有相似或者共通的地方，仅仅来说一下我理解的数据架构。

1、什么是架构

要说数据架构，先说说什么是架构，怎么定义架构这个词？

架构的本质是对复杂系统的解耦与重组。

“把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的目标，这就是架构。”

提炼关键词有三个：切分成不同的部分、不同部分之间相互沟通、完成整体所需的目标。

用日常生活中的"分工协作"思想来理解：当面对一个庞大整体（例如建造城市、设计操作系统）时，通过结构化拆分将整体分解为具有明确边界的功能模块（例如建筑中的地基/框架/管道，软件中的前端/后端/数据库），定义各模块的职责范围与交互规则，最终通过标准化接口实现模块间的有机协作。

架构的价值体现在三个方面：

效率提升：通过专业化分工提升各模块的执行效率。
风险隔离：单一模块的变更不会导致系统性崩塌。
持续演进：模块化设计使局部创新成为可能。

2、什么是数据架构

理解了架构，我们再说说数据架构。在说什么是数据架构之前，先说下为什么要有数据架构。

现实里某个事物的庞大复杂，所以需要架构，同样，企业内不同业务产生的数据，特别庞大、复杂，就需要数据架构。

数据是由业务产生。在业务的运行过程产生的数据，被记录到数据库不同的表中，此时的数据已经相当于被打散了再进行的记录，不能直观的反应出数据对应的业务了。数据架构就需要将已经被打散的数据，重新进行划分、组合来反映业务情况。

通过数据反映业务，自然也就能够数字化的衡量业务、评估业务、优化业务、发现新的业务机会。也就是让业务变的可量化了。

这个过程中，需要做两件事情，一件就是这个业务有多少个模块，也就是给切分成不同的部分。

第二件，就是不用模块之间的联系，也就是让不同部分之间相互沟通。

使用数据领域的术语的话，第一件事就是确定数据模型。第二件事就是明确数据流转。

所有，个人定义什么是数据架构？数据架构就是数据模型以及数据流转关系。

3、数据架构设计需要的理论知识

要设计一个好的数据架构，需要两方面的理论知识。

一方面是对于业务的理解，另一方面就是数据建模理论的知识了。

对于业务的理解：

对于业务的理解，在维度业务篇【业务：最熟悉的“陌生人”】中已经进行了介绍。里面详细的介绍了业务的宏观上的、和微观上的理解。详细的信息可以再回过头去看一看。
数据建模理论的知识：

数据建模的理论知识，就有是一个比较大的领域了。这方面的知识也完全不是一两句话能够说清楚的。

不过，推荐一本相关书籍《Star Schema 完全参考手册》，当然，数据仓库建模相关的书很多，个人只参考过这个，觉得很好

4、数据架构的目的

在第一节【什么是架构】中，我们提炼了架构的第三个关键词是“完成整体所需的目标”。

那么数据架构的目的是什么？

数据架构的目的是让数据中台加工好的数据，能够更加高效、顺畅的使用。

如果架构设置的不合理，数据能不能用，答案一定是可以的。数据都在，多关联几次，增加一些逻辑，可能最终结果也能实现。

如果架构合理那，就不需要复杂的关联，可以快速的获取到需要的数据，节省资源，提升效率，让数据的运转更加高效、顺畅。

而且，不合理的架构，在效率提升、风险隔离、持续演进，这些好架构能够获得的优点，也都不存在了。

5、数据模型设计--如何有效切分

业务本身是复杂的，如何对这个复杂的业务进行切分，其实就是一个数据模型设计的过程，也就是数据建模的过程。

之前在五大维度【业务篇】中介绍了建模的四个步骤，第一步就是：确定业务流。

这个业务流切分最好做到，高内聚，低耦合。

高内聚的目的就是为了专业化，这样子业务域的运作效率就高，松耦合的目的是子业务域之间的沟通成本最好低一点，这样整体的运作效率就越高。

至于，如何做到“高内聚，低耦合”，就需要基于对业务的了解，不同的人有不同的划分形式了。

6、数据流转关系--如何有效流转

切分只是完成了数据架构的第一步，切分后还需要确保切分后的各个部分能够高效的沟通，这依赖数据流的合理设计，数据流可以用于描述不同层级模型的映射关系，无论是主题域、还是业务环节。体现了数据在流程和IT系统上流动的全景视图，其至少需要达成以下目标：

1、明确数据实体在哪个源头产生。这个确定数据在哪个源头，我们在【数据源】模块介绍的时候，也说过。 2、数据实体出现在业务流的哪个环节 3、数据实体出现在哪个流转系统

在模型层面，如果想让数据有效流转，还有一点比较关键就是粒度的选择，确定好不同划分的部门的粒度，才能确保数据的顺畅关联流动。

7、数据架构和业务需求的先后关系

上面说了那么多数据架构的好处，但是回到实际中，马上会让你有一种“理想很丰满，现实很骨感”的感觉。

我们理想的状态是，对业务数据进行一个完整的数据架构设计，模型设计完整合理，数据流转方便高效，实际上这里面有两个变量。

第一个变量：业务的变化

假如我们做好了数据架构，先不说是一个完整的数据架构还是局部的。此时业务大调整。原本的业务数据库里面的数据记录逻辑都调整了。这时候，架构怎么办？再调整架构。业务再变那？这就变成一个永远追逐的过程了。

应对这个变量没有什么好办法。只能说数据架构适用于业务相对稳定，系统不会有大调整的公司。如果是新兴公司，就不要提稳定架构了。
第二个变量：需求的先后

抛开第一点变量，假设我们业务稳定了，就可以完全做一个全局的数据架构了吗？

这时候就又有一个需求先后的变量，或者说投入产出的问题。

建立完整的全局数据架构一定是耗时、耗力的。这么大的消耗暂时没有需求，而且也不明确什么时候能有需求。而完全按照需求来一个，做一个那？那么势必会将模型做的比较零散。

应对这个问题，个人认为就是先将核心的业务进行完整建模，边缘的业务随着需求来不断的增加。这个过程需要架构足够强壮，也需要建模发布有完善的审核流程。

8、五大维度说明

组织：

组织需要注意的是，一个领域的数据架构，需要有一个领域的审核，确定新的数据模型能够合理。这个角色一般也是数据BP来负责。
政策：

政策主要是需要让业务部门能够配合数据中台的人进行业务的了解和梳理。明确业务流程，和表对应关系等等信息。为架构设计提供业务信息。
工具：

搭建架构的过程就是一个建模的过程。虽然市面上又各种建模工具，但是个人认为没有纸笔+Excel好用。

可能也是我在做数仓建模的时候，主要就是按照这种形式来的。没有办法想象出来一个更好的工具了，看这就是局限性。没有办法知道，自己不知道的东西。

数据建模的过程就是业务信息梳理的过程，梳理业务之后的四步建模：条线划分，粒度选择、维度确认、事实确认。以及不同模型间的数据流转，等等信息都以个人经验，线下文档等形式保留。数据库表都是最终产物，中间的过程没有记录，一方面没有办法做知识沉淀，知识谁人走，很容易变成从头再来。另一方面，没办法有效升级迭代。所以，需要有一个系统将这些数据中台的潜在的巨大信息、知识能够给保留、记录出来。供后续的学习，以及架构升级做参考。
业务：

“数据是业务的映射”。将已经被打散的数据，重新映射会业务，首先需要知道，你的业务是什么样子，所以在数据架构，这个模块，业务的理解是尤为重要的。没有深入的业务理解，自然也就不会有好的模块切分。没有好的模块切分，模块间的流转关系也就不会自然顺畅了。
数据： 在架构领域，就不像前两个模块【数据源】【数据目录】一样完全不需要了解数据。这里就需要对数据进行探查，关联了。因为在数据流转过程中，需要能够明确流转是的关联关系是否合理。