数据架构的本质到底是什么？

Posted 2022-01-27 大鱼的数据人生

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了数据架构的本质到底是什么？相关的知识，希望对你有一定的参考价值。

我们搞数据的，按道理对数据架构应该比较熟悉吧，但自己最近却越来越迷糊了，因为发现很多讲数据管理的书，对数据架构的定义并不一致，有些出入还比较大。

自己赶紧去找权威的定义，发现搜出来的信息也是一地鸡毛，因此特意写这篇文章来探个究竟，即耳熟能详的数据架构到底是什么？

一、业界看法

首先我们来看看DAMA、华为、工业界、DCMM及央行等各领域对于数据架构的具体描述：

1、DAMA：《DAMA数据管理知识体系指南第二版》

定义：

识别企业的数据需求，并设计和维护总蓝图以满足需求，使用总蓝图来指导数据集成、控制数据资产、并使数据投资与业务战略保持一致。

目标：

识别数据存储和处理要求；设计结构和计划以满足企业当前和长期的数据需求；战略性地位组织做好准备，快速的发展其产品、服务和数据，以利用新兴技术中固有的商机。

构成：

（1）数据模型：企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。企业数据模型包括数据实体（如业务概念），数据实体间的关系、关键业务规则和一些关键属性，它为所有数据和数据相关的项目奠定了基础。

（2）数据流设计：定义数据库、应用、平台和网络（组件）之间的需求和主蓝图。这些数据流展示了数据在业务流程、不同存储位置、业务角色和技术组件间的流动。

2、工业大数据应用技术国家工程实验室：《数据治理：工业企业数字化转型之道》

定义：

讲企业业务实体抽象为信息对象，将企业的业务运作模式抽象为信息对象的属性和方法，建立面向对象的企业数据模型，数据架构实现从业务模式向数据模型的转变，业务需求向信息功能的映射，企业基础数据向企业信息的抽象。

构成：

（1）数据分布：包括数据目录、数据资源全景图、数据地图分布应用。

数据目录：作为数据共享交换的基础数据，对促进企业内部数据共享与交换、对外上报和公示相关信息都非常重要；

数据资源全景图：是企业全部数据资产的总体视图，既包括分布、流向和交互关系，又包括数据治理、数据服务和数据后期应用的完整视图。

数据地图分布应用：是指站在数据资产全景图的视角查看企业各数据域，在每一个数据域下，可以识别企业各项业务的核心数据主题，明确各个主题间的交互关系，将数据实体分类、形成企业级数据地图。

（2）数据主题域：是最高层级的、以各个主题概念及其之间的关系为基本构成单元的数据主题集合。企业应划分统一的数据主题域，形成统一的企业数据视图。

（3）数据关联关系：首先包括实体、属性、主键、外键、关系及基数，其次包括数据血缘关系，最后包括数据流转关系。

（4）数据模型：包括概念数据模型、逻辑数据模型及物理数据模型。

3、华为：《华为数据之道》

定义：

是指以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范。

目标：

定义好整个运作过程中涉及的各种人、事、物资源，并实施有效的治理，从而确保各类数据在企业各业务单元间高效、准确地传递，上下游流程快速地执行和运作。

构成：

（1）数据资产目录：通过分层结构的表达，实现对数据的分类和定义，建立数据模型的输入，形成完善的企业资产地图，也在一定程度上为企业数据治理、业务变革提供了指引。基于数据资产目录可以识别数据管理责任，解决数据问题争议，帮助企业更好地对业务变革进行规划设计，避免重复建设。

（2）数据标准：数据标准定义公司层面需共同遵守的属性层数据含义和业务规则，是公司层面对某个数据的共同理解，这些理解一旦确定下来，就应作为企业层面的标准在企业内被共同遵守。

（3）数据模型：是从数据视角对现实世界特征的模拟和抽象，根据业务需求抽取信息的主要特征，反映业务信息（对象）之间的关联关系。数据模型不仅能比较真实地模拟业务（场景），同时也是对重要业务模式和规则的固化。

（4）数据分布：定义了数据产生的源头及在各流程和IT系统间的流动情况。

4、国标：《DCMM数据管理成熟度模型》及央行：《金融业数据能力建设指引》

定义：

通过组织级数据模型定义数据需求,指导对数据资产的分布控制和整合，部署数据的共享和应用环境，以及元数据管理的规范。

构成：

（1）数据模型：使用结构化的语言将收集到的组织业务经营、管理和决策中使用的数据需求进行综合分析,按照模型设计规范将需求重新组织。从模型覆盖的内容粒度看，数据模型一般分为主题域模型、概念模型、逻辑模型和物理模型。

主题域模型是最高层级的、以主题概念及其之间的关系为基本构成单元的模型，主题是对数据表达事物本质概念的高度抽象。

概念模型是以数据实体及其之间的关系为基本构成单元的模型，实体名称一般采用标准的业务术语命名。

逻辑模型是在概念模型的基础上细化，以数据属性为基本构成单元。

物理模型是逻辑模型在计算机信息系统中依托于特定实现工具的数据结构。

（2）数据分布：针对组织级数据模型中数据的定义，明确数据在系统、组织和流程等方面的分布关系，定义数据类型，明确权威数据源，为数据相关工作提供参考和规范。通过数据分布关系的梳理，定义数据相关工作的优先级，指定数据的责任人，并进一步优化数据的集成关系。

（3）数据集成和共享：是建立起组织内各应用系统、各部门之间的集成共享机制，通过组织内部数据集成共享相关制度、标准、技术等方面的管理，促进组织内部数据的互联互通。

（4）元数据管理：元数据管理是关于元数据的创建、存储、整合与控制等一整套流程的集合。

二、架构的本质

可以看到，业界各方对于数据架构都给出了自己的解释，似乎都有道理，但又有不一致的地方，为什么呢？

我觉得这些都是表象，关键是还是要能深入数据架构概念的本质，看看它的底层逻辑到底是什么，然后才能给出更好的解答，虽然1000个人心中有1000个哈姆雷特，但一定有稳定不变的东西在那里，这就是我们需要掌握的东西，否则人云亦云，学到什么时候才是个头呢？

首先来理解架构这个概念。

先举一个例子：

在最早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定，这个时候效率不是很高，但一旦出现了分工，力量就强大多了，因为分工后，每个人可以做最为擅长的事情，但这个时候必须要通过某些机制合在一起，让每个人能交易到自己不擅长生产的东西。

在每个人都必须自己完成所有生活必须品的生产的时候，是没有架构的，一旦产生的分工，就把所有的事情，切分成由不同角色的人来完成，最后再通过交易，使得每个个体都拥有生活必须品，这实际上就形成了社会的架构。

那么怎么定义架构呢？

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

再拿建筑来举例加强一下理解。

最开始人类是住在山洞里，住在树上的，主要是为了躲避其他猛兽的攻击，以及减少自然环境的变化。为了完成这些目标，人类开始学会在平地上用树木和树叶来建立隔离空间的设施，这就是建筑的开始。但是完全隔离也有很多坏处，慢慢就产生了门窗等设施。建筑的本质就是从自然环境中，划出一块独占的空间，但是仍然能够通过门窗等和自然环境保持沟通。这个时候架构就已经开始了。

人们对建筑的需求慢慢的越来越多，空间的切分也会变成很多种，组合的方式也会有很多种，比如每个人住的房子，需要区分厨房、洗手间、书房、卧室等等，这个时候人们就开始有意识的去设计房子，架构师就慢慢的出现了。一切都是为了满足人的越来越高的需求，提升质量，减少时间，更有效率的切分空间，并且让空间之间更加有机的进行沟通。这就是建筑的架构以及建筑的架构的演变。

总结一下，什么是架构，就是：

（1）根据要解决的问题，对目标系统的边界进行界定。

（2）并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。

（3）并对这些切分出来的部分，设立沟通机制。

（4）根据（3），使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

看了上面的例子，你就能完全理解DAMA对架构做的一个更抽象的定义，即架构是对组件要素的设计，旨在优化整个结构或系统的功能、性能、可行性、成本和用户体验。在国际标准ISO/IEC/IEEE 42010:2011中，将架构定义为：“系统的基本结构、具体体现在架构构成的组件、组件之间的相互关系以及管理其设计和演变的原则”。

三、数据架构的本质

1、数据是业务的映射

建筑架构的目的是让人们住的更舒服，那数据架构的目的当然是让存储和使用数据的应用或系统能够更顺畅的运转，因此，无论是DAMA还是《华为数据之道》都在强调这一点，特别是华为，直接点出了数据架构的目的就是“确保各类数据在企业各业务单元间高效、准确地传递，上下游流程快速地执行和运作”。

企业为实现价值创造，从输入客户要求开始到交付产品及服务给客户获得客户满意并实现企业自身价值的E2E（端对端）业务过程就是业务流。

业务对象是指业务流中涉及的人、事、物，业务对象承载了业务运作和管理涉及的重要信息，业务对象会随着事件的驱动在业务流中流转，业务对象的载体是数据，流动的信息也是数据，这些数据只有满足下游的要求，业务流才能顺畅流动起来，否则价值创造过程就会受阻或停滞。

IT承载的是业务流以及数据，IT支撑每一个作业以及作业输出的数据，通过IT实现数据之间的集成，流程的自动化。

可以这么说，业务是由业务对象和业务流构成的，数据则是业务的映射。

2、数据如何有效切分

业务一般是非常复杂的，为了方便管理业务，首先需要切分业务，每个切分的子业务域最好是高内聚，松耦合。高内聚的目的就是为了专业化，这样子业务域的运作效率就高，松耦合的目的是子业务域之间的沟通成本最好低一点，这样整体的运作效率就越高，现在DDD（领域驱动的设计）本质就是为了达成这个目标。

子业务域是专业化的业务对象的集合，对业务的要求自然映射到了对业务对象的要求，那如何实现业务对象“高内聚，松耦合”的设计呢？

这自然是数据模型要完成的事情，数据模型代表了业务切分的结果。

因此，数据模型是数据架构的核心构件，国标DCMM对于数据模型的描述非常到位，分为四个层级，主题域模型、概念模型、逻辑模型和物理模型，这些模型的设计体现了切分的思维，也体现了切分的粒度变化。

3、数据如何有效流转

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

（1）明确数据实体在哪个源头产生

（2）数据实体出现在业务流的哪个环节

（3）数据实体出现在哪个流转系统

数据流设计要确保数据语言的一致性，促进业务流能够顺利的运转，就好比人类分工了以后，需要通过统一货币才能促进交易一样。现在数据治理特别强调数据源的一致性，要求业务数据必须认证数据源，在公司范围内统一发布，目的就是统一语言。

因此，无论是叫数据流还是数据分布，都属于数据架构的核心构件，这是业界的共识。

我认为数据模型和数据流（或叫数据分布）是数据架构最本质的东西，其让业务切分的合理并且切分后沟通顺畅。

四、数据架构的衍生

DCMM将数据集成和共享纳入数据架构的范畴，我觉得主要是业务流的内涵扩大导致的结果，因为以前的业务流仅局限在OLTP系统内部，OLAP起来后，通过集成多方业务流的数据，可以产生更有价值的数据。

这些价值数据通过共享手段反哺到业务流，可以促进业务流的进一步优化，从这个角度来讲，数据集成和共享应该纳入数据架构，因为它起到了提升沟通效率的作用，这是与时俱进的结果。

随着数据被纳入生产要素，这个趋势估计会越来越明显吧，当然，这仅是我的一个猜测，毕竟只有DCMM一家这么做。

华为把数据资产目录和数据标准当成数据架构的组件，应该是管理提升的需要，但并不是数据架构必需的。

以前数据模型的设计都是一堆乱七八糟的PDM，PDM实例化后，其数据架构已经在系统实现了，但如果你要去修改完善，会发现这些数据模型的设计信息没人管、找不到、看不懂，这阻碍了数据架构的进一步优化，因此搞个数据资产目录作为指引。现在数据资产目录作用越来越大，因为数据集成和共享的时候特别需要。

数据标准的制定则让各环节数据流上的数据可以更好的保持一致性，它是数据流的增强。

DCMM将元数据管理纳入数据架构的范畴，估计跟华为也类似，只是范围进一步扩大了。

工业大数据的数据主题域属于数据模型的一部分，数据关联关系的实体、属性等属于数据模型一部分，数据血缘关系和流转关系则属于数据流一部分。

因此，虽然DAMA、华为、工业、DCMM及央行对于数据架构的构成有不同的描述，但都包括了数据架构最本质的东西，即数据模型和数据流，至于其它的东西，那就见仁见智了。

DAMA、DCMM等数据管理框架各个能力域的划分是否合理？有内在逻辑吗？by 傅一平

人人都在讲数据治理而不问业务，这很危险 by 傅一平

数据管理咨询为什么难以成功？

谈谈华为数据之道的“不能”

华为数据之道为什么这么有吸引力？by 傅一平

部门不开放自己的数据，到底在怕什么？

数据治理项目失败，90%都是被这样搞垮的！

报表治理的15个有效策略 by 大鱼先生

数据治理的21个有效策略 by 傅一平

点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！

京东云开发者｜探寻软件架构的本质，到底什么是架构？

不论是开发人员还是架构师，我们都一直在跟软件系统打交道，架构是在工作中出现最频繁的术语之一。那么，到底什么是架构？你可能有自己的答案，也有可能没有答案。对“架构”的理解需要我们不断在实践中思考、归纳、演绎，形成自己的认知。

1 到底什么是软件架构？

定义 ”架构是什么“ 是件非常困难的事情，不同的组织对于软件架构有不同的定义，每个人心中也有自身对于系统架构定义的认知。就好比我们无法百分之百表述模型而只能产出模型不同维度的视图，对架构进行完备的定义是不可能的。

“道可道，非常道。名可名，非常名”。

行业内不同的组织和个人从不同的视角对 “什么是架构” 进行了定义或阐述。

IEEE 关于架构的定义

the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution --ANSI/IEEE

将系统架构定义为：架构是系统组织结构 + 组件及联系（组件间以及组件和环境之间） + 原则的组合。通过图形化的形式表述该架构定义如下图所示，这是一个非常简洁、概念清晰的定义，其言简意赅的表达了架构的几个核心要素：

•系统的组织：表达系统的宏观结构

•组件及联系：组件化的思维，同时突出了环境要素。组件表达了系统的模块化，组件相互之间及组件与环境之间的关联表达元素间的相互作用。

•原则：用于指导设计和系统演进的原则

大师 Martin Fowler对于架构的定义有着更加简洁的抽象，Martin Fowler 认为软件架构是：重要并且难以改变的决策。架构设计是关于权衡的艺术，架构设计过程中充满了各种各样的决策，这些决策也终将反应系统架构。

Software Architecture = Important and hard to change decisions -- Martin Fowler

而Ralph Johnson则对架构有更加 “泛化” 的定义：软件架构就是重要的东西，不论它是什么！

The software architecutre is the important stuff ! Whatever it is ! -- Ralph Johnson

以上的定义从高层抽象视角对什么是架构给予了自己的回答，相比之下，Neil Ford 从架构组成元素入手，从更偏向实践的角度对架构进行了阐述。核心思想是软件系统的架构包括以下组合元素：

•结构：应用系统所选择的架构风格，比如微服务架构、单体架构还是SOA等

•架构属性：系统的非功能性属性，比如性能、可用性、可维护性等

•架构决策：系统设计过程中重要的架构决策

•设计原则：设计过程中的指导性原则

结构

结构是系统架构的重要组成部分，其从宏观上表述了系统的结构组成。架构设计的核心任务之一是为系统选择合适的架构风格。比如，架构师基于上下文的权衡，可以选择模块化单体架构风格，也可以选择微服务架构风格。

架构属性

架构属性亦称质量属性，或非功能属性，通常表示系统需要具备或满足的某种 “能力”，比如高性能、可扩展性、弹性、伸缩性、容错性、可测试性、可维护性等等。架构设计的目标需要关注系统需要满足的架构属性，架构最终要体现对架构属性支持的相关架构决策。架构属性众多，系统需要关注的是这些架构属性的子集，具体的某次特定的架构设计所需要关注的架构属性需要依据问题域的上下文而具体分析。同时，不同的架构属性间可能存在冲突，这种情况同样需要架构师的权衡和决策。

架构决策

架构决策是系统架构设计过程中对解决方案的选择，其描述了系统必须遵循的规则。架构决策随着权衡分析而自然存在，其是系统架构设计的重要维度之一。并不是所有的决策都是架构决策，架构决策应该关注对系统有重要影响的部分。比如对架构风格的选择对系统存在重要影响，其改变的成本较高，理当属于架构决策的范畴。比较典型架构决策包括但不限于：

•直接影响高优先级的架构属性

•修改对外接口：对外提供的接口修改往往需要进行充分影响分析

•引入或者移除依赖：依赖的加入和移除往往标示着组件能力的引进和废弃

•改变系统的通用结构：工程结构是应用架构的重要维度之一

•迫使研发人员改变开发方式

•接受战略性技术债：重构影响较大的技术债往往对现有系统会有较大影响

注：架构决策建议以轻量级的文档化形式进行记录，参考文章《轻量级的架构决策记录机制》一文

设计原则

设计原则与架构决策不同，其本质区别是：设计原则是一种指导，而非强制的规则。架构决策需要遵守，设计原则提供参考性指引。

比如，设计原则可能是：在可能的情况下，跨系统间的通信尽可能使用异步消息机制以提高性能和降低耦合。

以上对架构的定义各有特点：

•IEEE定义更加结构化和规范化

•Martin Fowler的定义侧重架构决策的重要性

•Ralph Johnson 则更加泛化，突出 “重要” 这一核心因子

•Neil Ford则更具象化

我个人更倾向于Ralph Johnson 对于架构的抽象化定义，简单却不失对架构本质的阐述，这也是我在工作中判断架构边界的准则之一。

2 架构设计的边界

如果你是团队的架构师，你是否有以下困惑：

•系统的架构应该设计到什么粒度？

•架构设计是否要足够详细以便能直接指导开发人员开展编码工作？

如果你是团队的核心开发人员，你是否 “抱怨” 过：

•"架构设计" 太过详细，涵盖了实现的 “细枝末节”，自己除了CRUD没有发挥的空间

•"架构设计" 太过宏观，基于设计方案根本无法指导开发，自己还得重新设计

很多架构师自身对架构和设计的边界缺乏深入认知，相比于对架构边界的缩小，更多时候会出现架构设计边界放大的情况：

架构师把架构设计当作详细的技术方案设计，牢牢把控系统实现的所有细节，产出大量的设计文档，然后交由核心开发人员做代码实现的执行工作。

这种现象会导致如下问题：

•压缩了团队核心开发人员的设计发挥空间，不利于其技术水平及认知的提升

•作为架构师你真的能讲所有的细节都Cover住吗？即使耗费巨大精力完成了 “完备” 的设计，来自一线开发所面临的各种场景是否能够提前预知和捕获？

•如果需求迭代持续如此，作为核心开发人员多半会有所 “怨言”

•作为团队的架构师精力有限，持续的细节输出会耗费巨大精力，而无法关注更加宏观的层面

•.......

以上问题的根源是什么？不能明确架构设计的边界！

•架构设计与设计（实现相关）的边界或粒度问题

•团队架构师与开发人员间的职责边界

判断架构边界的前提之一是：明确架构和设计的关系！

所有的架构都是设计，但设计不一定是架构！

从架构的定义看架构设计的边界，选取两个视角：

•架构是系统中重要的东西！无论它是什么（之所以重要，是因为改变的成本高）

•架构设计涵盖系统中重要的架构决策

所以，架构设计应该涵盖系统中重要的东西，这些 “重要的东西” 可能是：

•应用架构风格的选择

•子系统间信息通信的方式

•工程采取的分层以及层间约束

•工程应该遵循的开发规范

•工程引入的三方类库，或者三方框架

•高优先级的架构属性：比如某次需求建设非常关注系统的性能，或者扩展性等架构属性

•其它 "重要的东西"

架构设计涵盖了系统所需的重要的架构决策，从宏观层面对系统实现予以指引。而详细的设计则为具体的开发实现提供指导，比如，详细的E-R图设计、具体的代码级别的模式选择、某个组件的具体实现等等。

架构不是一成不变，需要持续演进，而实现相关的设计也可能在项目进行中持续变化，因此，二者不能完全割裂，而是需要在实现过程中进行双向反馈：

•架构设计信息要高效的同步至开发人员

•实现过程中的变更同样也要回向反馈至架构，以便对架构设计进行调整

在进行架构边界判定时要注意一个至关重要的因子：上下文！！！以上的判断准则必须要给定的上下文中才有价值。

比如：实现过程中大家经常会适用一些设计模式，例如策略模式。那么，这种设计模式的选择是属于架构设计还是详细的实现设计？答案就是：It depends!!! 具体情况，具体分析。

如果当前上下文，我们非常关注系统的扩展性，该架构属性是我们高优先级的架构属性，那么，核心模块的策略模式的应用可以看作是架构设计的范畴。而如果上下文中扩展性不是我们关注的高优先级的架构属性，相比我们更关注性能，那么，这种代码级的设计模式选择应该属于架构设计的范畴之外了，而需要划分到实现设计层面，交由核心开发自主决定。

3 架构模式（Patterns）与架构风格（Styles）

架构模式和架构风格是极容易混淆的两个概念，很多开发人员将其理解为同一事物，而实际上二者有本质区别。

•架构风格是系统设计的顶层抽象，从宏观视角表述我们的系统组成。更进一步，架构风格聚焦于系统的分层、模块以及交互形式。

•架构模式聚焦于对重复出现问题提供解决方案

二者概念不同，并不存在冲突，其联系如下图所示：

•架构模式可以应用于架构风格，在同一架构风格上下文内可以应用一或多种架构模式

•架构风格可以组合以产生新的架构风格

比较典型的例子是CQRS：CQRS本身是一种模式，将命令和查询的职责在不同维度进行分离。该模式我们可以在单体架构风格中使用，也可以在微服务架构风格中使用，当然也可以在SOA架构风格中使用。

4 为什么要做架构设计？

至于 “为什么要做架构设计” 也是一个古老且频繁出现的问题，有太多的文章阐述为社么要架构设计：有的宏观，有的具体，有的“务实”，有的“务虚”。我把这个问题作为一个独立章节阐述，并不是想进行大篇幅的论述，只是想突出它的重要性，这个问题值得耗费一些精力去深入理解其背后的原因。但，在此不做展开过多说明，通过一句话来进行概括：

之所以要进行架构设计，是因为：重要！

•做，收益高

•不做，成本高

5 开发人员和架构师的知识模型

作为开发人员，更加关注知识的深度，以便有足够的知识储备满足工作需要。开发人员在职业生涯的早期，应该关注于自身知识储备的增长，并保持技术深度。

作为架构师，之所以技术的广度比深度更重要，是因为架构师的重要职责之一是进行架构决策。系统架构设计是关于权衡的艺术，在特定的问题域上下文下，架构师需要在诸多可行的解决方案间进行权衡和决策，这也对其技术广度提出了要求。开发人员成长为架构师，应该更加关注知识的广度，并在几个特定领域深耕，以便有足够的知识支撑架构决策。