对数据网格 Data Mesh 架构的思考

数据网格（Data Mesh）是由 Thoughtworks 提出的一种数据域驱动的分析架构，其中数据被视为一种产品，由最了解并且消费这些数据的团队来负责管理。本次我们转载了 Eric Broda 发表在 Medium.com 的博客，文章从数据网格的架构、场景、方案等多方面展开了阐述，希望能帮助大家进一步了解数据网格。

数据网格正在变革企业数据管理

大家都说数据是新黄金，但近年来，各种对数据价值挖掘的尝试不少都以失败告终。我们尝试过数据仓库，但企业间数据不一致的情况使其最终成为一片数据丛林。之后，我们又试过"数据湖"，但因为数据陈旧的问题，它很快也沦为数据沼泽！

因此，人们难免对数据网格持怀疑态度。数据网格究竟是又一次的昙花一现，还是真的能带来持久的实用价值呢？这个问题尚无定论。我曾在一家大型金融服务公司负责过现代数据网格的建立，从这段经历来看，数据网格是实用且可行的，更重要的是，它能极大加速解决方案的交付。很多文章都曾讨论过数据网格为什么能改变企业的数据版图，比如《数据网格架构模式》^[1] 以及如何从庞大的数据湖迁移到分布式的数据网格^[2]，但既然我是数据网格的忠实拥护者，这里不妨再介绍下如何构建数据网格。本文将讨论以下几个主题：

• 数据网格架构：如何利用基础技术开发数据产品，并最终将其组成企业数据网格；
• 数据网格实时同步场景：如何通过数据网格/数据产品在企业内实现近实时的数据迁移，这也许能最终解决"数据陈旧"问题；
• 数据网格 AI/ML 场景：如何利用数据网格/数据产品的数据血缘、可追溯性和可复现性实现高级 AI/ML 模型，轻松应对任务关键的负载；
• 数据网格的治理和审计场景：如何通过数据网格/数据产品捕捉数据的变化，这也许将革新数据的治理。

数据乱象：

陈旧、不一致的数据在企业中大量涌现

在企业数据版图中，随处可见各种新兴数据技术的残骸。企业通过"数据仓库"保存分析数据，但这并不能解决数据一致性的问题。很快，我们会发现在数仓都是一两天前的旧数据，造成分析数据陈旧问题变得很严重，数据仓库最终变为了数据丛林。

因此，人们又把数仓合并到"数据湖"中，但也发现很难在数据湖中进行数据检索或保持数据的一致性，因此很多用户，也包括公司高管在内，开始质疑数据的有用性。数据湖最终成为一片数据沼泽。

可以说，数据在企业中的移动方式（图1）已经成为企业面临的一大挑战。

• 数据陈旧：每天批量移动数据的方法，使系统内大多是 24 小时之前的数据；即使有一些在线处理能够更新数据，但这些方案的构建也存在定制程度高、成本高、开发周期长等问题，因此很难普及。
• 数据不一致：批处理还容易造成不一致的数据。在批处理造成的一天时延的基础上，下游的数据处理会再增加一到两天的延迟；基于上面相同的原因，定制解决方案也不可行。

简而言之，目前的做法，特别是企业内数据的移动做法，导致了当前的数据乱象。

数据网格是多个部件的组合

历史遗留的数据乱象不会很快消失，但从我的一手经验来看，"数据网格"能在很大程度上简化企业的数据版图，并为准确且一致的数据产出提供基础。根据数据网格概念的最初提出者 Zhamak Dehghani 的观点，数据网格应遵循几大原则^[3]：

• 按领域对数据的所有权和架构去中心化：数据网格的核心是去中心化的，并将权力下放，将其分配给最接近数据的人，从而能够支持持续的变更和扩张。
• 数据即产品：数据网格将提供包括可发现性、安全性、可探索性、可理解性、可信赖性等在内的一系列能力，并定义相关角色来为这些能力负责，这些角色就是各自数据域的所有者。
• 自助式数据基础设施即平台：数据网格支持数据所有者以简单和易于自主消费的方式提供数据。
• 联邦式计算治理：数据网格支持联邦式计算模型，围绕去中心化和域自主权，通过标准化保证互通性，同时具备动态拓扑结构，支持通过平台自动进行决策。

目前，还没有哪家供应商的单个产品能集中体现所有这些原则。相信随着时间的推移，供应商最终将能提供真正的数据网格，不过今天，我们还是只能通过不同的组件来组成数据网格，今天的数据网格更像是由多个乐高积木搭成的飞船（图2）。

那么，这些积木是什么，长什么样，怎么用它们组成数据网格呢？

数据网格/数据产品架构

数据网格架构由几个关键部分组成：数据产品，以及将这些数据产品组合在一起并使其能在企业内访问的数据网格。

让我们先从数据产品开始。基于前面提到的数据网格原则，企业内会有很多数据产品，但每个产品都应由相同的组件构成：

• 数据：不同数据库、数仓以及数据湖内的运营、分析和交互数据，按照产品所有者各自负责的域进行组织。
• 数据事件：定义和描述与数据产品相关的所有状态变化、命令或数据传输；这类事件可能由多种来源触发，包括数据产品 API（每个请求都可以是一个事件），数据变更捕获（数据中的每个变化都是一个事件），以及数据目录变更（元数据的变更事件只会向订阅者发布）。
• 数据产品 API：使数据产品内的数据可以按照统一、一致、符合行业标准规范的约定进行访问，比如 OpenAPI 或 GraphQL、MQQT、gRPC 等机制。
• 数据产品目录：描述位于数据产品中的数据，同时提供用户界面和 API 接口，方便用户和机器消费数据产品；数据产品目录整合在企业数据目录中，对所有数据产品提供统一的企业视图。
• 数据产品变更捕获^[4]：捕获数据产品中所有的数据变化，并将这些变化通知订阅用户，从而简化数据产品元素在组织内和更大范围间的传播，例如公司内需要保证分析和运营数据库的一致、例如，“账户”域就有可能触发对单个“客户”域内的数据变更。
• 数据产品变更/审计日志：跟踪和记录数据产品的所有变化，以支持联邦治理和审计要求。
• 事件流骨干网^[5]：简化事件在数据产品内以及整个企业中的传播。

数据网格/数据产品场景：

数据网格和 AI/ML

AI/ML 模型的质量取决于训练用的数据。因此要尽量确保模型训练数据是准确、一致的。那么如何在运营和分析（或交互）系统/数据库之间实现数据的及时同步呢？

上图展示了如何通过数据网格解决这个问题：

1. 运营系统变更了客户数据。
2. 数据变更捕获^[4]（CDC）读取运营数据库的交易日志，捕捉客户数据变更，创建事件并将其发布到由事件流骨干网（通常是 Kafka）管理的"Topic"中。
3. 订阅者 —— 本例中为客户分析系统，收到客户数据变更事件的通知。
4. 分析系统基于收到事件中的信息更新数据库。
5. AI/ML 算法使用最新的、一致的数据训练模型，产生最佳结果。

数据网格/数据产品架构

企业对模型的可复现性、可追溯性和可验证性的需求，迫使组织重新审视^[6]传统的 AI/ML 交付生命周期。这一点在金融服务业尤其重要，因为监管机构对模型的可复现性、可追溯性和可验证性有明确要求（参见欧盟^[7]、美国^[8]和加拿大^[9]具体规定）。目前在医疗保健、生物技术或政府安全等行业，也存在类似的要求；但即使其他一些监管相对宽松的行业，也已经认识到了这种做法能给企业的增益将远超其成本。

那如何解决可复现性、可追溯性和可验证性问题？企业一般采用两种方案。部分企业使用端到端的分析方案（如 SAS），将这些能力嵌入其生命周期中，但此时，企业只能选择特定供应商的产品，所以该方案不适用于希望充分利用强大的开源 AI/ML 组件的企业。

第二种方案是企业通过定制化组件建立数据血缘，从而满足可复现性、可追溯性和可验证性的要求。但这种方法的实现成本高，开发耗时长，因此只针对最关键的 AI/ML 模型建立，这也限制了AI/ML 模型的使用和它所能带来的价值。

数据网格企业架构

数据网格由企业数据产品目录提供支撑，并通过事件流骨干网进行连接。企业内会有许多数据产品，每个数据产品都围绕着企业相关业务线或团队而建立。通过数据变更捕获并将其作为事件发布在事件流骨干网上，订阅者（也就是应用或系统）能够得到他们所感兴趣的数据变化通知，从而实现数据产品之间的数据共享。

企业数据目录同样重要，它与数据产品目录同步（当然也是通过数据网格功能），以跟踪整个企业的数据要素（即驻留在每个数据产品中的数据）。企业数据目录凭借强大的搜索/查找功能，使我们能快捷方便地在整个企业中查找数据。

数据网格提供了便于数据产品连接的工具和机制：

• 数据网格简化了数据分享：数据在各域之间共享，并很可能支持不同域的复用。数据网格域可以帮助实现跨域的数据分享。对数据产品的访问和数据产品的变化都被认为是事件，这些事件既能在数据产品内部共享，也能通过事件流骨干网在数据产品之间共享。事件发布到一个"Topic"中，任何订阅者均能够收到通知。
• 数据网格实现近乎实时的数据共享：数据在域内通过"变更数据捕获"（CDC）^[4]机制以近乎实时的方式传输，从而使域内的经营、交互和分析数据保持同步；在不同域之间；也可以通过捕获域数据的 CDC 事件并使用 Kafka 事件流骨干网络（"Topic"）分发给相关订阅者，实现近实时的传输。
• 数据网格与企业数据目录的整合：每个数据产品都以近实时的方式与企业数据目录集成，所有用户（或机器）都可以访问任何企业数据产品的信息。这样的能见度、透明度和即时性也是联邦治理的基础。

企业数据网格设想场景：

实时数据同步

简而言之，数据网格将简化数据产品在企业内部的共享和同步。大多数企业都拥有许多数据产品，其中部分可能反映业务域，如"零售银行业务"、"支付业务"、"商业银行业务"，另一部分可能反映数据域，如"客户"、"账户"、"交易"。

从上图中可以看到数据如何在企业中移动和同步：

1. 业务系统更新数据；
2. 数据网格 CDC 捕获数据产品内的数据变更；
3. 订阅者——即企业内的应用/系统收到数据变更通知并更新自身数据库。

结论

数据网格能在正确的时间提供正确的数据，使企业能够自由、快速且敏捷地在当今市场进行创新。数据网格能够实现真正的联合式数据访问、交付和管理模式，不受繁琐流程的限制，企业团队可以在任意时间以自动化方式消费其项目、小组或业务线所需的数据。旧的数据管理模型已然过时，数据网格的前景将会更加广阔。