读数据架构知识体系指南17数据网格(下)

1. 数据域

1.1. 设计面向领域架构的过程被称为领域驱动设计(DDD)，是一个非常困难和耗时的过程

1.2. 分析数据应由与之关系最密切的业务领域拥有，领域分为数据源或主要消费者

1.3. 面向源领域的数据

• 1.3.1. 是与数据来源的业务源头密切对应的分析数据

• 1.3.2. 数据从源应用程序的业务数据库复制到域中，并转换为协作分析数据

• 1.3.3. 面向源的域可以有一个或多个来源：数据通常来自该域的业务系统，但也可能是其他域的运行或分析数据

1.4. 汇总的域数据

• 1.4.1. 汇总的域数据是组合或集成了其他域数据的分析数据，通常用于提升查询性能

• 1.4.2. 可将生产领域和销售领域的数据组合，便于简单快速生成损益表或便于与消费者使用的数据模型

1.5. 面向消费者的域数据

• 1.5.1. 面向消费者的领域数据是经过转换的分析数据，以满足一个或多个特定部门或用例的需求

• 1.5.2. 面向消费者域几乎总是从源对齐域接收数据

1.6. 非供应商的人员很难理解供应商的源对齐域，因此而独立创建了供应商的消费者对齐域

• 1.6.1. 在供应商的消费者对齐域中，数据模型被简化，供应商术语易于理解

2. 不同拓扑

2.1. 网格类型1

• 2.1.1. 所有域使用相同的拓扑

• 2.1.2. 逻辑上每个域都有自己的数据湖，但从实体上而言，所有域的数据在一个数据湖中

• 2.1.3. 当多个实体数据湖相距几公里，会存在进行数据合并的性能问题

• 2.1.4. 拥有一个物理数据湖可以大大简化数据的安全和监控，以及灾难恢复备份工作

2.2. 网格类型2

• 2.2.1. 域使用与网格类型1相同的技术

• 2.2.2. 不是所有域共有一个企业数据湖，而后各自有自己的数据湖

• 2.2.3. 所有数据湖使用相同的技术

• 2.2.4. 这使得基础设施真正实现了去中心化，但也带来了连接所有数据湖的技术挑战以及合并来自多个域的数据性能问题

2.3. 网格类型3

• 2.3.1. 每个域可使用任何技术和任何云提供商，并拥有自己的数据湖

3. 数据网格与数据编织

3.1. 数据网格和数据编织都是重要的概念，但它们扮演着不同的角色，不应被混淆

3.2. 数据编织的核心是一个架构框架，设计用于数据网格内的一个或多个域

3.3. 数据网格则是一个整体概念，包含技术、战略和方法、战略和方法

3.4. 数据编织的技术构架基础可以量身定制，以支持数据网格中各种错综复杂的组件

• 3.4.1. 它们之间的关系不是竞争或互换，而是协同作用

• 3.4.2. 一个数据网格可能包含多个数据编织，每个数据编织都是根据各自领域的独特需求量身定制的

3.5. 可以将数据网格中的每个域视为自己的生态系统

• 3.5.1. 域可以建立、完善和运行自己的数据结构、确保其符合特定要求和目标

• 3.5.2. 数据网格为分散和面向域的数据方法提供了蓝图，而数据编织则为这些域提供了架构和技术基础设施

• 3.5.3. 将它们结合起来使用，可以实现更集成、更高效的数据基础设施

• 3.5.4. 也适用于将数据网格与现代数据仓库或数据湖仓架构相结合

4. 神话

4.1. 使用数据网格是快速解决所有数据难题的灵丹妙药

4.2. 数据网格将取代数据湖和数据仓库

4.3. 如果数据仓库都失败，数据网格将解决该问题

4.4. 构建数据网格代表一切进行了中心化

4.5. 可使用数据虚拟化创建数据网格

• 4.5.1. 真正的数据网格方案与使用了数据虚拟化的数据编织之间是有巨大区别的

5. 疑虑

5.1. 哲学和概念问题

• 5.1.1. 为了将团队统一到一个公共的数据网格认识上来，需要考虑成立一个跨职能的管理委员会来决定功能定义和标准

• 5.1.2. 可以采用利益相关者研讨会和形成文件的定义方式确保所有人一致

• 5.1.3. 小规模试验项目可对这些定义进行实际性测试，进而判断是否采用

• 5.1.4. 在实现数据网格时，开放社区和定期审查有助于维护该统一战线

• 5.1.5. 拥有一份真实单一数据来源，从而使组织的决策建立在可靠数据上，不存在数据真实性的模糊或者分歧的情况

• 5.1.6. 每人都基于相同信息组合进行工作，使得业务更高效、更有成果

• 5.1.7. 在数据网格中，数据可从一个域读入、转换，被另外一个域存储

• 5.1.7.1. 这种动态拓扑极大增加了维护单一真实来源的难度

• 5.1.8. 如果组织建立严格的数据管理制度以及采用中心化的数据目录​，那么完全可以实现数据网格

• 5.1.8.1. 伴随着跨域数据质量标准以及数据域之间的强力合作，不仅仅单一真实数据源是可行的，也增强了网格灵活性和扩展性

• 5.1.9. 实现一个数据网格有着巨大风险，尤其是相比数据仓库的公认成功来看

• 5.1.10. 数据网格的前提是，每个源系统可动态拓展来满足顾客需求

• 5.1.10.1. 当某些数据资产成为生态系统中的“热点”​，查询或使用量激增时，这一点就会变得特别具有挑战性

5.2. 在去中心化环境中组合数据

• 5.2.1. 总是需要从多个域进行数据组合，以便进行查询或生成报告

• 5.2.2. 每个域往往只关注满足自己分析需求的数据产品

• 5.2.3. 数据所有者会忘记思考将自己的数据与其他域的数据结合的方法，也对自己的数据模型域与其他的融合投入很少

• 5.2.4. 为防止CDM中的ID在多个域中重复，*可以使用全局唯一标识符(GUID)或建立集中式ID管理系统来分配唯一ID

• 5.2.5. 随着域构建其产品和数据模型，其他域和消费者将使用他们的数据，并根据这些数据模型组合来自多个域的数据

• 5.2.6. 要解决跨域数据清理不一致的问题，可以建立一个集中管理框架，为清理或标准化数据设定标准定义

• 5.2.6.1. 提供数据清理模板或共享库，以节省时间并确保统一性

• 5.2.6.2. 治理委员会或数据管理员可以帮助执行这些标准，从而更容易地将来自多个域的数据合并在一起，而不会出现问题

5.3. 去中心化的其他问题

• 5.3.1. 聚合域和消费者对齐域（见第13章）并不是去中心化的

• 5.3.2. 要创建聚合域，就需要从多个域中获取数据，并将这些数据集中起来

• 5.3.3. 为了使聚合域和消费者对齐域能与数据网格的原则相协调，应考虑共享治理和专门数据管理员来管理这些域

• 5.3.4. 利用数据虚拟化尽量减少重复，并实施API层进行抽象

• 5.3.4.1. 通过强大的元数据和审计跟踪保持透明度

• 5.3.5. 在中心化构架中，一个团队负责所有数据的安全

• 5.3.6. 跨域时，很难选择和实施相互一致的技术

5.4. 复杂性

• 5.4.1. 数据网格背后的理念非常复杂

• 5.4.2. 数据网格的支持者声称数据网格的复杂性与组织的复杂性正好相反，但这种复杂性也延伸到了组织的复杂性上

• 5.4.3. 分布式团队涉及了更多人员，而且他们不一定能有效沟通

5.5. 重复

• 5.5.1. 不可能总是直接从这些不可变数据访问原始数据，因为通常存在安全或即时检索的问题

• 5.5.2. 要想对源数据做任何处理，就必须复制一份数据并将其存储到数据湖中

• 5.5.3. 数据网格可能会导致更多数据副本，因为域可能需要从其他域复制数据，以完成其数据产品或创建聚合或面向客户的域

• 5.5.4. 复制数据的问题延伸到数据产品

• 5.5.4.1. 如果数据产品被复制，其元数据也会被复制，这样就会产生多个需要保持同步的相同元数据副本

5.6. 可行性

• 5.6.1. 迁移到数据网格是一项艰巨的任务，需要在组织变革和技术实施方面投入巨资，远远超过其他数据架构

• 5.6.2. 导致更高的成本和更长的时间线，可能需数月甚至数年后才能投入生产

5.7. 人员

• 5.7.1. 需要为每个域寻找和聘用高级工程技术人员以及其他技术工人

5.8. 域层面的障碍

• 5.8.1. 该域主管与中央IT部门制定了在未来几个月内创建分析功能的计划

• 5.8.2. 提供可信的激励措施，以弥补额外的工作、麻烦和延误

• 5.8.3. 获得每个域对实施数据网格的支持

• 5.8.4. 获得高层管理人员的支持

• 5.8.5. 传达清晰的愿景，展示每个域的益处

• 5.8.6. 开展试点项目，展示新方法的有效性

• 5.8.7. 提供经济和非经济奖励，鼓励参与

• 5.8.8. 建立持续沟通的透明渠道

• 5.8.9. 通过标杆域提供支持

6. 成功实施数据网格的建议

6.1. 如果已有数据解决方案，并决定构建一个数据网格，建议你采用中心辐射模式，将数据网格作为中心式数据解决方案的扩展来构建

6.2. 可以使用新数据创建新的数据网格，但要根据业务需求使用当前的集中式数据解决方案对这些域进行补充

6.3. 随着时间的推移，不断将新数据中添加更多新域，慢慢地将集中式数据迁移到数据网格中，不要试图一下子就将所有集中式数据转换成数据网格

6.4. 逐步实施数据网格的方式有助于管理对现有数据架构进行彻底改造带来的风险

6.5. 逐步实施新领域的方式可以一边吸取经验教训，一边据此做出必要的调整，并将这些经验教训应用到后续的，可以创建一个更强大的系统

6.6. 随着时间的推移，中心辐射式方法为企业文化转变铺平了道路，促进了数据产品负责人、工程师和业务利益相关者之间的跨职能、领域驱动型合作

6.7. 零散的数据网格实施是一种战略方法，可以进行仔细规划、风险管理并与业务目标保持一致