一、数据架构与数据模型概述
1、DAMA DMBOK 数据架构与数据治理
数据架构及数据模型管理是数据治理体系的重要组成部分。类似于项目管理中的 PMI、PMP，国际上于 1980 年成立了 DAMA（数据资产管理协会）。DAMA 凝集了数百位专家的经验，最终形成业界通用的数据管理框架（DMBOK）。DAMA-DMBOK 数据管理框架（又称为 DAMA 车轮图)，主要由 11 个知识领域构建而成，其中数据架构和数据模型是这套方法论最重要的两个维度。
数据架构主要用来识别企业的数据需求，并设计蓝图，最终输出数据架构设计和实施路线图，详见下图所示。
2、建设数据模型的流程
数据模型的建立，业界通用的方法论如下所述：
① 前期的设计主要聚焦于业务，基于客户需求，完成概念模型和逻辑模型的设计；
② 进一步，基于企业现有的技术环境和性能要求，将概念模型和逻辑模型转化成可落地的物理模型；
③ 再进一步，将物理模型结合实际数据转化成数据库表结构（以及创建表结构对应的 DDL 脚本），最终形成数据库表字段；
④ 对于模型的设计和落地过程中的重要节点，往往会形成一套相应的企业标准，实现规范化。
不管源端系统有没有进行模型设计，数据 schema 都存在，都可以通过逆向工程抽取出来提炼成模型，这些模型更多地描述业务系统涵盖的数据范围，以及数据之间的关系；如果模型质量高，可以更好地帮助企业理解数据资产的价值。因此可以认为，所有的系统都有数据模型，只是有些模型更容易理解，也更容易对企业产生价值。
3、所有模型都是为了业务开展，不同视角，不同阶段
对于如今流行的大数据概念，人们普遍将关注点聚焦在分析侧（即 AP 侧）。实际上，大数据模型不仅仅包含 AP 侧，TP 侧（即企业的源端业务系统）在信息化或数字化过程中同样会构建出各种各样的数据产品（或系统），最终应用于企业内部或外部客户。
对于数据库底层设计，现阶段大部分企业仍然使用传统的数据库构建范式：
① 在 TP 侧，通常使用三范式模型这类 Inmon 模型；
② 在 AP 侧的数据集市，通常使用维度模型（如雪花模型、星型模型）这类 Kimball 模型；
此外，近期迭代出更多更加新型的数据模型范式，如 Data Vault 模型、统一星型模型等，覆盖范围更加广泛，可更加广泛地应用于 TP 侧和 AP 侧。
4、数据模型按阶段分类
① 业务系统模型，通常选择三范式模型；
② ODS 模型通常从业务系统直接接入，因此也选择三范式模型；
③ DWD 模型和 DWS 模型作为企业级数仓，既可采用传统的三范式模型，也可使用现代的 Data Vault 模型来构建，都支持多对多的关系；
④ 集市模型一般使用维度模型，便于实现数据的上卷和下钻等分析操作。
5、数据模型介绍
数据的关系却错综复杂，成千上万个表通过各种关系或约束互联形成复杂的结构。以生活中常见的场景为例，如房屋平面图、地图等，用不同的符号向相关用户清晰展示相关信息。
通过数据模型，用户可以清晰看到现有数据库的结构，并更直观地理解关键的概念。数据模型主要包括概念模型、逻辑模型和物理模型这三个层次。
① 概念模型：主要用来描述世界的概念化结构，是一个高层次的数据模型，由核心的数据实体或其集合，以及实体间的关系组成；
② 逻辑模型：对概念数据模型进一步的分解和细化，描述实体、属性以及实体关系；
③ 物理模型：面向特定的数据库，结合数据库特征，便于计算机实现的模型。
开发者在进行模型设计的过程中，通常会将大部分时间和精力聚焦在概念模型和逻辑模型的设计和迭代优化；物理模型则类似于对概念模型和逻辑模型的“编译”操作，通过生成并执行 DDL 脚本最终实现数据库以及相应 schema 的创建。
二、数据架构与模型解决方案
1、解决方案 1——模型设计和开发平台一体化
通过 ER 图可视化，可实现逻辑模型或物理模型的设计。以下图为例，数据包括 hub、link、Satellite 三个核心概念；使用 Data Vault 模型，可实现更加灵活的数仓自动化操作，以更便捷的方式实现模型的解耦，来构建复杂的、具有业务深度的行业模型。
完成模型的设计后，生成相应的 DDL 脚本，通过 Create 功能或 Alter 功能，最终实现模型的管理和迭代。
2、解决方案 2——数据标准管控，数据规范检查
（1）数据标准管控
在模型设计阶段，所涉及的模型字段要实现标准化；通过指定或引用相关的企业级数据标准，利用智能推荐，更加方便地实现数据表字段的选取。
数据建模工具一般具有数据标准的功能，在模型设计期间，研发人员可以通过拖拉的方式直接引用数据标准，也可以在实体设计器中，使用智能推荐的数据标准，优化数据应用模式，提升模型设计效率。
如下图所示，以电力系统模型为例，在表结构设计过程中，通过关键词（如变压器）可以直接关联到相应的数据标准，进而查询到标准的字段名称、物理类型、长度精度、业务定义等信息，进而将标准引入到实体属性中，同时实现了字段名称、数据类型、数据精度的规范，进而实现了源端业务系统数据模型质量的把控。
（2）命名词典构建
如果相关的企业或部门没有制定严格的企业数据标准，企业可以基于业务术语构建统一术语词典库（即命名词典）；借助这一词典库，解决研发人员建模时常见的“同一指标多种命名”这类易发生歧义的问题；开发人员在模型构建的过程中，对于模型实体及属性命名，自动基于词典库进行翻译，实现数据模型的命名规范，使物理模型的设计质量更高。
（3）中央模型库
多人协作集成模型，会涉及复杂的版本迭代、版本对比等版本管理问题。因此，可建立类似 git 的中央模型库，基于数据模型服务器实现数据模型设计规范、数据标准及模型设计成果的在线化管理；提供模型设计工具，实现模型设计规范、数据标准以及模型在线应用，为数据标准落地提供手段；支撑设计态及运行态模型匹配监测，实现数据模型从规范化设计到应用全过程在线管理。
（4）数据规范工具
将开发规则内置到建模过程中，开发对应的数据规范工具和数据标准一致性检查工具，以解决研发人员设计不规范、缺少数据标准约束等业务痛点，最大程度地降低数据治理的成本：
① 数据规范工具可以检测以下内容：表和字段中文名称不能为空；表和字段物理名称不能为空等多项内容。
② 数据标准一致性检查工具可以检测：数据类型、中文名、英文简称是否和标准一致性等多项内容。
3、解决方案 3——模型变更自动化、智能化
基于数据模型服务器构建数据模型库，数据库承载数据标准、命名词典、规范报告等信息；迭代优化的模型通过统一的发版系统（如 jira、confluence 等）进行统一发版，实现数据模型的存储管理和版本变更管理，并提供模型在线查看编辑和多人协作等功能。
其核心功能点在于：
① 统一模型存储，Web 模型共享和查询；
②实现模型版本管理，模型变更全历史记录；
③ 自动进行模型合规检查，标准落标报告；
④ 多人协作，同时编辑和修改模型；
⑤ 自动生成建库脚本，数据字典管理。
采用类似 git 的代码管理方式，模型设计工具从模型，分支，版本三个层面对模型进行管理，最终有效解决研发人员的模型版本管理，实现协同共享。
4、解决方案 4——数据模型和业务场景业务对象对应
大型企业除了数据模型设计，还需要对大量的业务场景做整合。业务架构包括业务流程、业务活动等，涉及大量的业务表单和对应的业务对象。在数据模型的数据实体页面，将每一个实体和业务场景中的每一个业务对象进行绑定，进而通过 Datablau 自研的模型管控体系实现血缘关系的跟踪和分析。
5、Datablau 模型管控体系简介
Datablau 模型管控体系包括事前、事中和事后这 3 个部分：
① 事前：通过统一的建模工具，进行模型设计。
② 事中：增加模型评审环节，由领域架构师、企业架构师负责模型的评审，通过资产平台进行完整性检查。
③ 事后：部署生产环境后，通过数据资产平台检查并监控模型的一致性、完整性并出具相关报告。
6、Datablau 模型管控体系与数据开发
将 Datablau DDM 工具纳入开发投产流程后，各业务模块需要进行相应的模型迁移，并使用平台提供的典型能力进行模型设计、开发测试和投产。
（1）模型导入
① 模型导入：通过导入工具，将 PD、ERWin 等工具的模型导入 DDM 中。
② 逆向工程：通过直联数据库的方式，逆向生成模型。
③ 信息补全：补充模型中缺失的字段信息，例如字段中文名称。
（2）设计阶段
① 模型设计：使用客户端设计器进行模块设计与维护。
② 影响分析：设计阶段能够显示模型的修改对下游系统的影响。
③ 字段引标：设计工具中能够引用数据标准。
（3）评审阶段
① 任务管理：提交模型时需要与任务进行关联。
② 分支管理：按照推荐的最佳实践进行分支管理，分支间按照任务进行内容合并。
③ 模型评审：模型的变更必须经过线上评审。
（4）投产阶段
① DDL 校验：将投产 DDL 与模型工具导出 DDL 比对。对于不匹配的部分，近期可以人工确认，远期改为系统认定。
7、Datablau 模型分支管理策略
版本分支管理包括设计态和运行态这两部分。数据模型按照开发与测试环境进行对应的版本管理，并基于每个分支的开发、SIT、UAT、版本等不同发布状态进行相应的管理，最终形成统一的分支管理策略。
8、模型设计和开发平台一体化
构建模型设计和开发平台一体化管理流程，实现模型设计人员从模型设计到数据架构师审批模型，再到模型脚本入业务系统库，并生成代码嵌入数据标准给到开发平台。
这套数据建模管理流程，可有效地将数据模型转化为企业数据资产。相比于直接抽取技术元数据，数据资产化模型一方面大大提升了数据的质量，另一方面增加了数据间的关系，以及各类数据背后的业务定义，使得数据信息更加全面和系统。
三、大型企业实践案例
1、企业数据架构——制造业概念模型
以制造业为例，下图呈现了制造业高阶概念模型，涉及管理类、运营类、支持类等业务板块。
2、建立企业数据架构-开发路线图——主题域模型
将上述业务板块转化为高阶的主题域模型。以汽车厂为例，首先是进行产品研发，输出产品部品即 BOM 清单；基于 BOM 清单进行装配、生产，并关联销售清单；同时 BOM 也会关联销售项目管理，最终和客户管理、订单管理、销售管理、财务管理等一系列数据进行多重关联，构建出高阶主题域模型。
3、业务现状
（1）业务现状梳理：成果（1）L1-L3 高阶流程架构
将上述主题域模型进一步细化，以采购部为例，基于采购部组织职能定位，与业务访谈输入，全面梳理采购域所包含高阶业务架构。
① L1 Category 域：企业业务的最高级别，可基于业务能力或端到端场景定义。
② L2 Process Group 流程组：企业一级域的下级能力或流程集合。
③ L3 Process 流程：一系列将输入转化为输出的相互关联的活动。流程消耗资源并且需要制定可重复执行的标准；流程需要遵从一个面向质量、速度、成本绩效要求的控制体系。
（2）业务现状梳理：成果（2）L1-L3 业务侧数据目录
基于采购部门职能，梳理采购域不同信息域下所包含标准化业务信息/表单，将其转化为业务侧的数据资产目录，支持数据认责工作。
（3）业务现状梳理：成果（3）L1-L3 业务全景图
基于采购业务价值链，绘制业务信息流图：以端到端视角审视采购业务全貌，识别业务信息来龙去脉。
4、数据资产
（1）数据资产梳理：成果 – 数据目录（L1-L5 资产清单）
以上图所示数据资产目录为例，分成主题域组、主题域、业务对象、数据实体、属性 5级；每增加一个层级，可理解成添加一个的叶子节点。
5、标准
（1）数据标准制定：成果 – 数据标准（L5 属性标准）
对于数据目录中 L5 层属性的标准化定义，通过补全数据的业务属性（名称、业务规则等）、技术属性（数据类型、长度等）以及管理属性（数据维护责任人、数据管家等），最终形成数据标准。
6、数据模型
基于数据标准构建数据模型。上图为采购域的数据模型，模型中的每个字段都与数据标准形成了映射关系。
（1）数据模型设计：ONE ID 逻辑设计
基于上述数据模型，结合实际业务构建数据应用。以采购域为例，对每个供应商进行全方位画像，包括财务信息、经营状态、业务信息等维度，构成一套供应链金融的服务模式。
（2）数据模型是数据中台的核心位置
数据模型是数据中台的核心数据资产，关系到基础数据整合，开发效率，和数据质量。数据中台主要包括 ODS 层、DWS/DWD 层，以及数据集市层等，这些中间层模型设计的规范性和灵活性，决定了数据资产的管理和应用效率。因此，如何整合好数据模型是数据中台成功的标志。
（3）全面管理和升级模型数据资产
传统的数据模型构建，往往是开发人员基于业务逻辑通过 SQL 脚本实现相应功能，并转化成存储过程，进而通过任务调度实现数据的转化。这种方式灵活、便于实现，然而会给后续的数据资产梳理、数据质量排查以及数据修复等相关工作带来麻烦。
因此，以数据模型为核心，通过对数据中台模型的管理，实现从孤井式的代码开发，到模型驱动的代码开发阶段的转变。实现了模型驱动的数据模型资产化，开发过程可审查，代码质量可靠性等转变，使中台成为企业数据资产的沉淀和发布中心，进而形成行业模型的影响力。
（4）一体化建模架构
从数据战略角度看，将业务流程、业务架构、数据责任、数据安全和入户标准等相关模块都承载到业务模型上；进一步，业务模型通过数据模型落地实现，结合相应的企业标准进行模型评审，评审通过的数据模型发布成数据资产目录，并最终进入数据湖。
由于数据模型存在迭代更新的周期性，因此在模型设计的过程中，数据标准的维护至关重要。所有的模型都是由数据标准组装而来；模型评审和模型发布作为重要的中间管控节点，最终实现自助入湖，并周期性地和生产元数据做比对。
（5）企业级信息架构的四个组件
企业级信息架构，本质上是基于一套核心的信息架构，展现成数据资产目录、数据标准、数据模型、数据分布 4 种不同的形式：
① 数据资产目录
1）通过分层架构表达。
2）对数据的分类和定义。
3）厘清数据资产。
4）建立数据模型的输入 。
② 数据标准
1）业务定义的规范。
2）统一语言，消除歧义。
3）为数据资产梳理提供标准的业务含义和规则。
③ 数据模型
1）通过 E-R 建模实现对数据及其关系的描述。
2）指导 IT 开发，是应用系统实现的基础。
④ 数据分布
1）数据在业务流程和 IT 系统上流动的全景视图。
2）识别数据的“来龙去脉” 。
3）定位数据问题的导航。
这套核心的信息架构本质上是从 4 个角度诠释企业的数据资产信息：
数据模型作为最初的设计原型，经过评审发布后形成数据资产目录最终开放到业务部门；模型内部最细颗粒度的规范形成数据标准；数据分布则体现的是某个具体的表或字段在整个业务流程体系中所处的位置，定位到对应的具体业务对象并直观地体现该业务对象的上下游关系。
（6）六项入湖标准
数据入湖的评审标准，大概包括以下这 6 个方面：
① 明确数据 Owner
由数据产生对应的流程 Owner 担任，是所辖数据端到端管理的责任人，负责对入湖的数据定义数据标准和密级，承接数据消费中的数据质量问题，并制定数据管理工作路标，持续提升数据质量
② 发布数据标准
入湖数据要有相应的业务数据标准。业务数据标准描述公司层面需共同遵守的“属性层”数据的含义和业务规则，是公司层面对某个数据的共同理解，这些理解一旦明确并发布，就需要作为标准在企业内被共同遵守。
③ 认证数据源
通过认证数据源，能够确保数据从正确的数据源头入湖。认证数据源应遵循公司数据源管理的要求，一般数据源是指业务上首次正式发布某项数据的应用系统，并经过数据管理专业组织认证。认证过的数据源作为唯一数据源头被数据湖调用。当承载数据源的应用系统出现合并、分拆、下线情况时，应及时对数据源进行失效处理，并启动新数据源认证流程。
④ 定义数据密级
定义数据密级是数据入湖的必要条件，为了确保数据湖中的数据能充分地共享，同时又不发生信息安全问题，入湖的数据必须要定密。数据定密的责任主体是数据 Owner，数据管家有责任审视入湖数据密级的完整性，并推动、协调数据定密工作。数据定级密度在属性层级，根据资产的重要程度，定义不同等级。不同密级的数据有相应的数据消费要求，为了促进公司数据的消费，数据湖中的数据有相应的降密机制，到降密期或满足降密条件的数据应及时降密，并刷新密级信息。
⑤ 制定数据质量方案
数据质量是数据消费结果的保证，数据入湖不需要对数据进行清洗，但需要对数据质量进行评估，让数据的消费人员了解数据的质量情况，并了解消费该数据的质量风险。同时数据 Owner 和数据管家可以根据数据质量评估的情况，推动源头数据质量的提升，满足数据质量的消费要求。
⑥ 注册元数据
元数据注册是指将入湖数据的业务元数据和技术元数据进行关联，包括逻辑实体与物理表的对应关系，以及业务属性和表字段的对应关系。通过连接业务元数据和技术元数据的关系，能够支撑数据消费人员通过业务语义快速地搜索到数据湖中的数据，降低数据湖中数据消费的门槛，能让更多的业务分析人员理解和消费数据。
（7）数据模型管控组织
从公司部门的组织架构角度考虑，数据模型管控的推进，需要配备相应的组织架构予以监督和支持。一方面，基于 DAMA 方法论，企业构建不同的数据治理体系维度，如数据标准、数据质量、数据模型、数据资产目录等相关内容；另一方面，基于传统的 IT 相关部门下属的各个项目小组，建议安排部分开发人员以 part-time 的方式承担部分数据治理角色，使得数据治理架构更加立体。此外，可以专门成立企业架构办（一般包括数据架构、应用架构、技术架构、业务架构这 4 层架构），与项目组联合，实现更全面、更深入的数据模型管理服务。
因此，建立虚实结合的数据组织设置，是确保数工作能充分融入业务，同时能够在应用系统中有效落地的关键。
以交通银行为例，企业共计超过 500 套业务系统，全部通过上述组织架构协作实现模型管控。
四、问答环节
Q1：按照全套组合架构实现企业级数据治理，往往会带来较高的时间成本；因此，如何平衡数据治理和开发效率？
A1：① 数据治理架构的开展，需要一定的契机；可以以企业新构建的系统作为试点；尤其是金融系统，往往 5 年左右进行一次更新换代。因此，可以选择合适的系统更新换代节点，推进数据治理架构。
② 如果企业的数据资产需求较为强烈和迫切，那么源端管控就是必要的工作。在此基础上，可以先针对部分部门或项目组，通过小范围试点方式进行推进，后期再逐步进行大范围推广。此外，可借助一些更高效的工具以提高开发效率。
Q2：主数据在数据模型中如何体现？
A2：这类问题在业内曾引起广泛的讨论。对于金融行业，客户管理系统即是客户的主数据；对于业务链条较长的企业，例如制造业企业，常用的方式是针对主数据进行模型建模。而对于主数据建模，较为传统的方式是开发相应的 MDM（主数据关系系统），典型的企业实践案例是中石油系统；然而 MDM 系统较为庞大，因此近年来主数据建模的趋势是更加轻量化，通常是在各个系统（如组织机构、客户、物料、产品等系统）对应的数据库中预留少量区域来存储对应的主数据模型，实现该系统主数据模型与各个系统的对接。总之，核心在于主数据模型的构建，轻量化是趋势。
Q3：数据质量和数据标准该如何解决？
A3：如果企业的模型设计已经落标，质量管理这部分工作相对会容易很多；由于每个物理字段对应的标准已经确定，因此基础的数据质量检测规则往往可以自动生成，而复杂的数据质量检测规则和数据标准中的认责板块挂钩，相应部门提供各自的数据质量检测相关的业务规则，最后再由业务规则转成技术规则，嵌入到系统中进行周期性运行。
