读数据架构知识体系指南16数据网格(上)

1. 数据网格

1.1. Zhamak Dehghani创造了数据网格(data mesh)一词

• 1.1.1. 数据网格是一个概念，而不是一种技术

• 1.1.2. 关系到公司内部组织和文化的转变

• 1.1.3. 自从2019年被首次引入以来，数据网格就吸引了很多注意

1.2. 数据网格是去中心化数据结构

• 1.2.1. 用于构建数据网状结构的技术可以遵循现代数据仓库、数据结构或数据湖仓，或者各领域甚至可以遵循不同的架构

1.3. 四个特性

• 1.3.1. 要求被指定领域内的独立团队拥有自己的分析数据

• 1.3.2. 在数据网格中，数据被当作产品来处理和提供，以帮助数据消费者发现、信任和利用数据，达到他们想要的目的

• 1.3.3. 依赖于自动基础设施配置

• 1.3.4. 利用治理来确保所有独立数据产品的安全并遵循全球规则

1.4. 失败技术几乎都因为人或流程的问题，或者企业选择错误的技术

1.5. 数据网格是一场集中与分散的较量

• 1.5.1. 关键是要找到适合自己的平衡点

• 1.5.2. 专为大型、面向域的公司量身定制，适用于面临重大扩展性挑战、资源丰富和时间充裕的企业，追求健壮方案

1.6. 现代数据仓库

• 1.6.1. 数据仓库最适合处理少量数据的企业，它们已经习惯关系数据仓库，因此过渡较为平缓

1.7. 数据编织

• 1.7.1. 随着企业的发展和多样化，管理者经常会发现自己需要处理来自无数来源的数据，每个来源的数据在大小、速度和类型上都不尽相同

• 1.7.2. 数据结构是那些需要无缝集成这些不同数据流的企业的架构选择

1.8. 数据湖仓

• 1.8.1. 可以视为一种中等方案。应将数据湖作为主要解决方案，直到发现其局限性

• 1.8.2. 可将特定数据集转移到RDW，以更好地满足企业需求

1.9. 业务的未来与数据的未来密不可分

2. 去中心化框架

2.1. 现代数据仓库、数据编织、数据湖仓都是集中式架构，所有分析数据都由IT团队创建和拥有

• 2.1.1. 集中式数据架构和云产品能够处理几乎任何数量的批量和流式数据

2.2. 中心IT团队负责

• 2.2.1. 拥有和控制数据

• 2.2.2. 整合不同来源的数据

• 2.2.3. 将数据存储到其拥有的中心位置

• 2.2.4. 建立数据模型并将其存入中央存储库

• 2.2.5. 管理与合规，包括定义和执行数据质量、安全性和隐私标准

• 2.2.6. 创建并维护数据管道和转换逻辑

• 2.2.7. 通过剖析、验证、清理和其他流程确保数据质量

• 2.2.8. 优化性能

• 2.2.9. 管理所有计算技术

• 2.2.10. 管理分析和报告工具

• 2.2.11. 存储和管理元数据

• 2.2.12. 灾难恢复和备份

• 2.2.13. 硬件和处理能力可垂直扩展

2.3. 数据网格是去中心化的

• 2.3.1. 意味着数据连同其对应的工具由组织内个别团队或"域"而不是中央机构或IT部门的单一团队拥有和管理，并按业务域分组

• 2.3.2. 领域团队负责收集、处理和管理他们自己数据，并自主决定数据使用和共享方式

• 2.3.3. 数据留在域内，最终用户可直接对数据所在地进行数据访问和查询，无须将数据复制到中央位置

  • 2.3.3.1. 带来极大的可信度，并确保数据由最专业的人员进行管理和维护

3. 数据网格四原则

3.1. 原则1：域所有权

• 3.1.1. 建议权力下放，将责任分给最靠近数据的人，以支持持续变更和扩展

• 3.1.2. 在中心化架构中，往往存在谁拥有分析数据的困惑

• 3.1.3. 多数源数据由自主的操作系统、Salesforce和微软Dynamics等CRM工具以及SAP和微软Dynamics等企业资源规划(ERP)工具生

• 3.1.4. 每个特定领域的系统和应用程序都由专门的操作人员运行，他们通常与中央IT数据平台团队几乎没有交流

• 3.1.5. 中央IT数据平台团队

  • 3.1.5.1. 很少对业务系统或者商业程序运行机理有深入了解

  • 3.1.5.2. 本不了解数据，对数据的生成一无所知，也对数据含义不了解

  • 3.1.5.3. 很难生成高质量数据和可用的分析报告

• 3.1.6. 业务数据库的负责人始终是分析数据的所有者，他们负责管理和维护数据

• 3.1.7. 责任和所有权被分散并分配给最接近数据的人员，以支持持续变化和可扩展性

• 3.1.8. 每个领域都拥有自己的运营和分析数据

3.2. 原则2：数据即产品

• 3.2.1. 建议将域提供的分析数据看作产品，将数据的消费者看作消费者

  • 3.2.1.1. 每个域有自己的团队、API代码、数据和元数据，以及基础设施

• 3.2.2. 在集中式架构中，IT团队拥有分析数据，因而对数据质量负责，但他们通常不是很了解数据，可能在数据转换时犯错误，而领域团队深入了解数据以及数业务领域环境

  • 3.2.2.1. 有助于他们识别并解决数据质量问题，中心IT团队由于缺乏商业需求理解的语境，易忽视数据质量问题

• 3.2.3. 数据所有者不应将分析数据视为输入、资产或其他人管理的流程副产品，而是将数据视为完全包含在内、由他们负责的产品

  • 3.2.3.1. 将*数据消费者（数据用户、数据分析师、数据科学家）*视为客户

• 3.2.4. 领域团队将产品思维应用到他们的数据中，以确保数据易于发现，并且是可信、可访问、安全和可理解的

• 3.2.5. 将数据看作产品的第一步是准确确定企业中数据产品的定义

• 3.2.6. 数据产品是自主、独立部署的数据单元，可传递商业价值

  • 3.2.6.1. 来自业务或交易应用程序的分析数据，由一个产品团队设计、构建和管理

• 3.2.7. 每个数据产品都是独立的，其管理完全独立于其他数据产品

  • 3.2.7.1. 解决特定的业务问题，基于目标用户的需求而设计

  • 3.2.7.2. 一个数据产品与特定的数据域相关联，因此它服务于特定的业务领域，并应与该领域保持一致

  • 3.2.7.3. 每个业务领域下通常有许多产品

• 3.2.8. 数据产品与数据作为产品不是一回事

  • 3.2.8.1. 数据作为产品是指数据所有者将数据视为完全包含的产品，由他们自己负责，而不是由其他人管理流程的副产品，并应将数据提供给其他领域和消费者

  • 3.2.8.2. 数据产品是指将数据作为产品来实施的架构

  • 3.2.8.3. 将数据集、分析模型和仪表板视为数据产品，侧重于数据的物理表示

• 3.2.9. 数据产品可能由子产品组成，每个子产品负责提供特定的数据子集或围绕主题领域组织的功能

• 3.2.10. 数据产品通过数据合同消费，数据合同是数据领域或数据产品之间协议，定义了生产者和消费者之间数据交互的格式和结构

• 3.2.11. 数据合同是一份内容丰富的文档，通常包含元数据、数据模式、数据转换信息和数据访问规则

  • 3.2.11.1. 还包含其他领域、产品或消费者访问数据产品的方式，通常通过应用程序接口、数据库、标准文件格式、事件流或图表进行访问

• 3.2.12. 领域团队直接对数据负责，因此他们可快速定位并解决任何质量问题

  • 3.2.12.1. 缩短解决问题的时间，降低了业务决策中使用不准确数据的风险

  • 3.2.12.2. 领域团队深入业务，因此他们更了解各自领域的具体数据需求

  • 3.2.12.3. 确保了数据的管理和维护符合业务需求，从而生成质量更高、相关性更强的分析数据

  • 3.2.12.4. 还必须确定其数据的业务需求

  • 3.2.12.5. 每个团队都要根据领域的要求和数据量来确定自己的资源需求

  • 3.2.12.6. 每个团队还可以根据需要独立配置和扩展资源，以应对需求波动

3.3. 原则3：自助数据基础设施即平台

• 3.3.1. 建议通过自动配置基础架构来简化数据产品的创建和管理

• 3.3.2. 在数据网格中，由于每个领域团队都拥有自己的领域数据，并将其数据视为产品，因此需要自己的工程团队和基础设施来构建、部署、监视和提供对其数据产品的访问

• 3.3.3. 将领域团队的责任从构建操作应用程序扩展到了构建分析和创建数据共享解决方案

• 3.3.4. 数据网格平台应由专业的、中心平台团队来构建

  • 3.3.4.1. 不是数据网格的一切都是去中心化的。平台必须实现领域工程团队所需的所有工具和接口，以供领域工程团队用来简化构建、测试、发布、安全、维护和与消费者或者其他数据领域之间共享数据产品的生命周期

• 3.3.5. 在数据网格中，领域工程团队不是由专家构成的，而是由普通技术人员构成，因此通过数据网格平台降低复杂性，可以让他们腾出手来利用数据进行创新

• 3.3.6. 目的是节约成本、降低复杂性、减轻领域团队的负担、减少对专业技术的需求以及自动化管理政策

3.4. 原则4：联邦计算管理

• 3.4.1. 各领域与中心数据团队应协作开展数据治理，来定义、实现、监控全局规则

• 3.4.2. 相比数据网格，中心化架构中的数据管理是相当简单的，因为采用中心化构建方法，只有一个中心数据团队拥有所有数据，并定义、实施和监视所有数据管理

• 3.4.3. 集中式方法往往会造成瓶颈，减缓决策过程，限制各个领域对其面临的不断变化的条件和具体情况做出迅速反应的能力

• 3.4.4. 可能导致缺乏本地化的专业知识和对背景的了解，因为中央团队必须管理大量数据，而无法深入了解每个领域的细微差别

• 3.4.5. 在数据网格中，中心数据团队定义监管所有管理标准和策略，包括数据质量、数据完全、规章和数据建模等

• 3.4.6. 中央数据团队由领域代表和行业专家（合规、法律、安全等方面）组成

• 3.4.7. 数据管理的实施和监控工作由各领域负责，因为他们拥有数据，也最了解数据

• 3.4.8. 在多个领域团队之间分配职责的挑战在于，可能会出现不一致和相互冲突的做法，从而导致运行效率低下和复杂性增加

• 3.4.9. 不一致性可能会导致不良数据、人们看到不该看到的数据以及其他问题

• 3.4.10. 联合数据治理将集中监督与特定领域的自主权结合在一起，这对保持整个组织的一致性和安全性至关重要

• 3.4.11. 在领域独立性和中央数据团队监督之间取得平衡

• 3.4.12. 在可能的情况下，自动实施和监控策略，并对数据进行标记以方便识别，都会有所帮助

3.5. 前两个原则是分散式的，每个域使用自己的IT团队和基础设施创建分析数据

3.6. 另外两个原则需要集中式团队，一个负责实施数据基础架构平台，另一个负责实施供所有域使用的共享管理