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

Author
Kyligence
2022年 4月 02日


数据网格(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. 订阅者——即企业内的应用/系统收到数据变更通知并更新自身数据库。

结论

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