一篇文章讲清楚什么是数据网格和数据网格的原则

针对传统集中化数据平台的困境，Zhamak Dehghani 于 2019 年 5 月撰写了一篇论文，提出了数据网格的概念。在这篇文章中，Thoughtworks 顾问描述了集中式、单体式和与域无关的数据平台的局限性。

这些平台通常采用专有企业数据仓库的形式或复杂的数据湖，其中包含“数千个无法维护的 ETL 作业、表格和报告，只有一小部分专业人员才能理解，从而导致对业务的积极影响未充分实现”，根据 Dehghani 的说法，这些数据“由一个由超专业数据工程师组成的中央团队运营，这些工程师充其量只能支持一些研发分析”。数据网格旨在通过专注于领域驱动的设计来解决这些问题，并引导领导者走向“现代数据堆栈”，以实现元数据和数据管理的集中化和分散化之间的平衡。

Thoughtworks认为，数据网格是一种面向分析和机器学习的技术方法，以去中心化的组织和技术方式分享、访问和管理数据。数据网格希望创建一种社会技术方法，旨在规模化的获取数据中的价值。从本质上讲，它创建了一个可靠的数据共享模式，与组织同步发展并持续拥抱变化。

IBM认为，数据网格是一种去中心化的数据体系结构，按特定业务领域（例如营销、销售、客户服务等）来组织数据，为给定数据集的生产者提供更多所有权。 生产者对领域数据的理解使他们能够设定专注于文档、质量和访问的数据治理策略。反过来，这可以在整个组织中实现自助服务。虽然这种联合方法消除了与集中式单体系统相关的许多操作瓶颈，但并不一定意味着您不能使用传统的存储系统，如数据湖或数据仓库。这只是意味着它们的使用已经从单一的集中式数据平台转变为多个去中心化的数据存储库。

为了实现数据网格的目标，Dehghani提出了数据网格的四个原则，包括按领域对数据的所有权和架构去中心化、数据即产品、自助式数据基础设施及联邦式计算治理。

1、按领域对数据的所有权和架构去中心化

数据网格的核心是去中心化的，并将权力下放，将其分配给最接近数据的人，从而能够支持持续的变更和扩张，它比数据湖具有更好的扩展性，因为新的数据源或新的数据消费者只意味着添加一个新的域（数据产品），而不是重新访问整个数据湖。

为了实现这个目标，我们需要构建一个按域划分的数据架构。在此架构中，领域与组织其他部分的接口不仅包括交易操作能力，还包括对域所服务的分析数据的访问。以下示例演示了面向领域的数据所有权原则，每个域可以公开一个或多个操作型 API，以及一个或多个数据API：

图片

图片

这种去中心化的组织架构有点像华为数据之道中提到的业务负责制的数据管理责任体系，华为按分层分级原则任命数据Owner，在公司层面设置公司数据Owner，在各业务领域设置领域数据Owner，这样既能确保公司数据工作统筹规划，也能同时兼顾各业务领域灵活多变的特征。

各领域数据Owner在公司数据Owner的统筹下负责所辖领域的数据管理体系的建设和优化。各业务部门是执行规则、保证数据质量，进而推动规则优化的关键环节。通过主管结构正式任命各数据主题域和业务对象的数据Owner和数据管理，数据Owner的职责包括数据管理体系建设、信息架构建设、数据质量管理、数据入湖和数据服务建设等等。

大家肯定很困惑，领域拥有数据的所有权似乎是天然的，怎么能说是进步的理念呢？现在数据集中化的目的不就是为了剥夺这种权力以便让其它领域也可以访问到领域的数据吗？

问题的关键在于原来的领域虽然拥有数据的权力，但并没有承担分享的义务，这引发了数据集中化管理的变革，但传统集中化的数据平台做过了头，在各领域数据支撑上力不从心，数据网格希望采用分布式的架构来解决集约化和灵活性的矛盾，让数据所有权回归领域，但需要承担对外数据服务的义务。

2、数据即产品

传统对集中化数据的访问通常需要先进行多次沟通，提交工单等待批准，数据网格希望减少生产者交付高质量数据的阻力，同时使消费者能快速地探索、理解和使用数据。

在过去的十年中，OLTP致力于用产品思维提升对外服务能力，包括打造丰富的 API（应用程序接口）体系、提供优秀的开发体验（可发现且易于理解的 API 文档，API 测试箱及密切跟踪质量的关键绩效指标）等等。

为了使分布式数据平台获得成功，领域数据团队也必须将产品思维应用于他们提供的数据集，将数据视为独立的产品，承担起提升数据质量的责任，包括准确性、一致性等，确保数据可供发现、检索、理解、值得信赖并有安全性的保障，领域数据产品需要具有以下基本特征：

（1）可发现的

数据产品必须易于发现。常见的实现方式是对所有可用的数据产品及其元信息（例如其所有者，来源，样本数据集等）编写目录。此中心式可发现性服务使组织里的数据消费者，工程师和科学家能够轻松找到他们需要的数据集。每个领域数据产品都必须在此中心式数据目录中注册以方便查询。请注意，这里的观点转变是从单一平台提取数据，到以可发现的方式将其数据作为产品提供到每个领域。

（2）可寻址的

在分布式体系架构中要制定通用的标准，确保数据产品有一个唯一的访问地址，不同领域存储和提供数据集的格式不同，事件可通过 Kafka 进行存储和访问，而数据集可使用 CSV 文件或序列化 Parquet 文件的 AWS S3 进行存储和访问。

（3）可信赖且真实的

没有人会使用他们不信任的产品。在传统集中化数据平台中，采集的原始数据质量往往参差不齐，需要花费大量时间进行清洗和转化。为了实现根本性的提升，领域数据产品的所有者要从源头解决数据质量问题，并通过元数据服务（比如血缘分析）来提升信任度和使用体验。

（4）自描述的语义和语法

优质的产品往往所见即所得。为了降低数据工程师和数据科学家使用数据集产品的门槛，需要对数据集的含义进行充分描述，最好以样本数据集作为示例，数据schemas 即域元数据是提供自助服务的起点。

（5）可互操作并受全球标准约束

分布式领域数据体系结构需要具备对跨领域的数据进行连接、过滤、整合的能力，其中的关键是遵循统一的标准和规则，这种标准化工作的共同关注点包括字段类型格式化，跨不同领域识别多义词，数据集地址约定，通用元数据字段，事件格式（例如 CloudEvents）等，互操作性和标准化是构建分布式系统的基础支柱之一。

（6）安全并受全局访问控制

无论架构是否中心化都必须确保产品数据集的安全性。在分布式的面向领域的数据产品中，对每个领域数据产品都要进行精细的访问控制，访问控制策略可以被集中定义但也可以应用到每个单独的数据集产品上。使用企业身份管理系统（SSO）和基于角色的访问控制策略是实现产品数据集访问控制的便捷方法。

（7）领域数据跨职能团队

领域需要增加数据产品经理和数据工程师。数据产品经理要围绕数据产品的愿景和路线图做出决策，要关注消费者的满意度，不断衡量和改进其领域拥有和生产的数据的质量和丰富性，要负责域数据集的生命周期管理，在域数据消费者的需求之间取得平衡，要为数据产品成功定义关键绩效指标 (KPI)，比如数据产品实现周期。

为了对域内数据进行优化改造，领域必须拥有数据工程师，从而与软件工程师形成互补，数据工程师虽然拥有数据开发和建模技能，但在构建数据资产时缺乏软件工程标准实践，比如持续交付和自动化测试，同样，软件工程师通常也没有使用数据工程工具集的经验，消除技能孤岛有助于创建更大的数据工程技能库。在这方面，我们已经观察到DevOps运动产生的授粉效应，比如SRE新型工程师的产生。

数据产品涉及数据、代码资产（包括生成它的代码和交付它的代码）、元数据和相关策略。数据产品可以作为 API、报表、表或数据集在数据湖中传递，数据产品应由相同的组件构成，具体包括：

（1）数据

不同数据库、数仓以及数据湖内的运营、分析和交互数据，按照产品所有者各自负责的域进行组织。

（2）数据事件

定义和描述与数据产品相关的所有状态变化、命令或数据传输；这类事件可能由多种来源触发，包括数据产品 API（每个请求都可以是一个事件），数据变更捕获（数据中的每个变化都是一个事件），以及数据目录变更（元数据的变更事件只会向订阅者发布）。

（3）数据产品 API

使数据产品内的数据可以按照统一、一致、符合行业标准规范的约定进行访问，比如 OpenAPI 或 GraphQL、MQQT、gRPC 等机制。

（4）数据产品目录

描述位于数据产品中的数据，同时提供用户界面和 API 接口，方便用户和机器消费数据产品；数据产品目录整合在企业数据目录中，对所有数据产品提供统一的企业视图。

（5）数据产品变更捕获

捕获数据产品中所有的数据变化，并将这些变化通知订阅用户，从而简化数据产品元素在组织内和更大范围间的传播，例如公司内需要保证分析和运营数据库的一致、例如，“账户”域就有可能触发对单个“客户”域内的数据变更。

（6）数据产品变更/审计日志

跟踪和记录数据产品的所有变化，以支持联邦治理和审计要求。

3、作为平台的自助数据基础设施

将数据所有权分配给领域的主要问题之一是可能存在重复工作。幸运的是，将通用基础架构构建为平台已经是众所周知的问题，将领域不可知的基础架构功能收集和提取到数据基础架构平台中，使数据域能够自行生成其数据产品。他们需要能够使用与用户相关的工具和流程来定义其数据产品，而无需对中央平台或中心平台团队具有很强的依赖性。

在数据网格中，你拥有自主团队开发和管理自治产品，你不能有需要专业知识才能操作的专用工具是基于网格的平台的核心基础。自助数据基础架构的成功标准是减少“创建新数据产品的时间”，这将引导“数据产品”功能所需的自动化。

图片

将数据基础架构构建为平台的关键是（a）不包含任何特定于领域的概念或业务逻辑，使其保持领域不可知性（b）确保平台隐藏了所有潜在的复杂性和提供了数据基础架构组件自助服务的方式。自助数据基础架构作为平台向用户（领域的数据工程师）提供的功能种类繁多，比如：

可扩展的多语言大数据存储
加密静态和动态数据
数据产品版本控制
数据产品架构
统一的数据访问控制和记录
数据管道的实现和编排
数据产品发现，目录注册和发布
数据治理与标准化
数据产品监控/报警/日志
数据产品质量指标（收集和共享）
内存中数据缓存
联合身份管理

4、联邦式计算治理

如前所述，数据网格遵循分布式系统架构，包括一组具有独立生命周期的独立数据产品，由可能的独立团队构建和部署。然而，对于大多数用例而言，为了以高阶数据集、洞察力或机器智能的形式获得价值，这些独立的数据产品需要互操作，能够关联它们、创建联合及查找交点等等。

为了使任何这些操作成为可能，数据网格实现需要一个治理模型，该模型包含去中心化和域自主权、全局标准化的互操作性、基于动态拓扑的平台自动执行决策。由域数据产品所有者和数据平台产品所有者联合领导的决策模型，具有自治和域本地决策权，同时创建并遵守一组全局规则——适用于所有数据产品及其接口的规则——以确保健康和可互操作的生态系统。

这是一项艰巨的工作，要思考如何保持中心化和去中心化之间的平衡，哪些决策需要本地化到每个域，哪些决策应该针对所有域全局进行，最终，全局决策只有一个目的，即通过数据产品的发现和组合创造互操作性和复合网络效应。