ThoughtWorks最近一期的技术雷达，把Data Mesh从“评估”调升到了“试验”。ThoughtWorks眼中的“试验”意味着这项技术“值得追求。重要的是理解如何建立这种能力。企业应该在风险可控的项目中尝试此技术。”

文章内容大部分来自 Zhamak Dehghani 的《How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh》 讲了如何将单体的数据湖，变为分布式的数据网格（Data Mesh）。

那么，未来的企业数据中心，可能企业将告别建造单体的数据湖，转而成为分布式的数据水系么？

如何从单体数据湖演进到分布式数据网格

许多企业都在投资建设自己的下一代数据湖，希望通过数据洞察业务并做出智能决策。基于数据湖的数据平台架构，这样的单体架构存在共通的失败特征，不能达到建设时承诺过的服务标准。为了解决这些问题，我们需要转变这种集中式的数据湖或者数仓。我们需要一种现代的分布式架构：将“领域”作为首要考虑的因素，运用平台化的思维创建自助服务型的数据基础设施，并且将数据也视作一种产品。

建设数据驱动的组织，是当前许多公司的首要目标。他们深知数据智为企业带来的好处：基于数据与个性化技术，提升的客户体验；数据驱动的运营成本优化；通过趋势分析和BI工具为员工赋能。他们也一直在大力投资构建数据和智能平台。然而构建数据平台虽然投入不菲，但是最后结果却一般般。

我承认组织在转型数据驱动时，会面临诸多复杂问题：比如需要迁移十几年前的历史遗留系统，企业之前的内部文化并不欢迎数据加入，以及难以权衡的业务优先级。我所分享的架构理念，正是基于这诸多失败的数据平台建造过程，借鉴过去十年间在建造分布式架构，引入“数据领域”，这项新的企业数据架构，我称之为——数据网格（Data Mesh）。

在继续阅读之前，请各位读者放下对传统数据平台架构建设理念的固有思维，尽可能地以开放的心态拥抱分布式数据网格架构。你需要面对这样一个事实：数据是永远存在的、是无处不在的、而且是分布式存在的。

当前企业数据平台架构及其弊端

当前企业的数据平台是：中心化、整体化、领域无关的，亦称数据湖。

我接触过的所有客户，都正在构建或者计划构建他们的第三代数据智能平台，同时也认识到之前两代数据平台的不足：

• 第一代： 专有的企业数据仓库和BI平台；虽然这是一个价格不菲的解决方案，但同样留下了不小的技术债务；技术债务存在于数千个难以维护的ETL作业，诸多表格和报告中，这些东西仅有少数专业人员能够理解他们。

• 第二代： 大数据生态构建的数据湖，看起来似乎是银弹。复杂的大数据生态系统，长时间执行的批处理作业，必须由高度专业化的工程小组构建和维护，他们创造的是一个数据湖怪兽，但是充其量也只能完成一些研发分析；对比建设初期许下的承诺，显然有些差距。

第三代数据平台和当前的架构或多或少有些类似，面向流的实时数据处理架构，比如Kappa； 批流一体的数据转换框架，比如Apache Beam；以及完全基于云的托管服务来存储、处理数据的流水线和机器学习平台。显而易见，第三代数据平台正在解决之前遇到的问题，比如实时数据处理，以及降低基础设施的管理成本。但是，这种架构依然面临着和之前两代一样的潜在弊端。

架构弊端

为了解释这些数据平台面临的潜在问题，我们看一下这些架构的特征。在本文中，以互联网流媒体业务为例（像Spotify，SoundCloud，Apple iTunes等）来阐明一些概念。

集中式和单体式

从三万英尺的高度看数据平台架构，就像下面图1所示。集中式的目标是：

• 从企业的各个角落获取数据，包括运营系统、交易系统等等，也包括外部数据供应商。例如在流媒体业务中，数据平台会负责获取各种数据：“媒体播放器的性能”、“用户和播放器的交互”、“播放列表”、“关注的歌手”、“唱片公司和歌手”、和歌手之间的“金融结算”，以及外部市场调研数据（比如客户人口统计信息）等等。

• 清洗，扩表，转换源数据到高质量数据，以满足数据消费端的需求。在我们的示例中，用户交互行为的点击流信息，扩充上用户的详细信息，这种转换将重建用户的行为到一个聚合视图中。

• 向不同的数据需求方提供数据，需要提供不同种类的数据。从数据中分析消费，通过机器学习制定决策，通过BI报表展示业务表现，这些需求所需要的数据各不相同。在我们的流媒体示例中，平台可以近实时的从Kafka等分布式日志系统接口中取得全球范围内播放器的错误和播放质量信息，或者提供某个歌手的播放记录的聚合视图，以推动财务结算应付账款给歌手和唱片公司。

图1：三万英尺俯瞰单体数据平台

单体架构平台上的集中托管的数据，在逻辑上其实并不属于相同的领域，比如：“播放事件”、“销售的KPI”、“歌手”、“唱片”、“唱片公司”、“音频”、“播客”、“音乐活动”等等；这些数据来自大量不同领域。

过去十年间，尽管我们成功地将领域驱动设计（Domain Driven Design,DDD）和边界上下文（Bounded Context）应用于各类系统，但是我们在数据平台中却忽略了领域的概念。我们已经不知不觉地从“面向领域的数据所有权”转向了“集中式领域不明确的数据所有权”。我们以创造最大的单体大数据平台而骄傲。

图2： 集中数据平台，没有明确的数据领域边界和面向领域数据的所有权。

集中式的模型适用于较为简单的领域，数据消费端数量较少的情况；对于领域丰富，数据生产来源众多，数据消费者多样的企业并不适用。

集中式的数据平台架构通常有两个压力点，经常导致数据平台是建设失败：

• 分散的数据和源的不断增加：随着数据变得分散，单一平台的控制协调能力将会下降。想象一下，“客户信息”，在组织内外有各种各样的数据来源，提供现存和潜在客户的信息。随着数据源的不断增加，我们需要从各个数据源接入并存储到一个单一的位置。对于数据用途，数据科学家和分析师希望低成本的处理各个数据集，以运营为目的使用数据，和以分析目的使用数据的方式也并不相同。我的看法是，现有的集中式的解决方案，不是应对多领域，数据源持续新增的大企业的最佳解决方案。

• 业务创新需求和数据消费多元化：业务方通常需要通过数据快速验证一些想法，这样的需求引入了大量的数据使用的案例。这意味着不同的数据处理任务数量也不断增长：聚合、投影、切片，以满足创新的测试和学习。长期以来，如何快速满足数据使用者的需求，一直是企业面临的问题，并且在现代数据平台架构中依然如此。

但是需要澄清的是，我并不是要鼓吹之前那种隐藏在各个系统中的、分散、孤立、烟筒似的领域数据，这样的数据是难以被发现、理解和使用的。也不是鼓吹那些由于多年攒下的技术债务导致的分散成的多个数据孤岛。我的观点是，为了解决这些无法访问的数据孤岛问题，不应该是建立一个集中的数据平台，再搭上一个中心化的团队。这样就会面临我们前面提到的那些扩展性的问题。

耦合数据流水线的拆分方式

传统数据平台架构的第二弊端是我们如何拆分体系结构。在一万英尺看集中式大数据平台的时候，我们会发现数据架构依据获取、清洗、聚合、服务等功能进行拆分。架构师会根据平台的增长进一步分解体系架构。架构师需要找到一个扩展系统，将其分解到架构单元（architectural quantum）。在《演进式构建》的描述中，一个“架构单元”是一个具备完整功能、高内聚、可独立部署的组件。将系统分解为单一结构单元的初衷，是方便划分独立的团队，每个人都可以构建和维护这个结构单元。团队之间并行工作以便增加系统的可扩展性和建设速度。

考虑到前几代数据平台架构的影响，架构师通常将数据平台划分为一系列的数据处理阶段。围绕数据处理的技术实现，通过一条流水线实现一组功能。包括了数据获取、预处理、聚合、服务等功能。

图3：数据平台的架构拆分方式

尽管此模型可以提供一定程度的扩展，但是将团队分配到数据流水线上的不同阶段，具有一个固有的局限性，将功能交付速度拖慢。整条数据流水线在各个阶段都具有很高的耦合性，而这种拆分方式，流水线的拆分方向和流水线本身的变化方向，刚好是正交的。

让我们看一下流媒体实例。互联网流媒体平台围绕他们的媒体类型，具有强大的面向领域建造能力。这些服务通常以“歌曲”和“专辑”开始，然后再扩展到“音乐活动”、“播客”、“电台SHOW”、“电影”等等。每一个数据统计的新需求，例如“播客播放率”，需要修改整个数据流水线上的所有部分。团队必须引入新的获取数据的代码、新的清理数据和预处理数据的代码、新的聚合数据的代码，直到最后才是展示“播客播放率”的视图。这要求在不同的组件之间要同步实现功能，并在团队之间管理发布节奏。许多数据平台现在已经提供了通用的和基于配置的数据获取服务，以应对扩展的需求，降低实现新功能的成本。但是这并没有从根本上消除新数据集需要端到端的依赖性管理。流水线架构从表面上看，各个处理阶段已经是一个独立的架构单元，但是从整个单体平台角度看，这整条数据流水线才是最小的架构单元，新的数据集从获取到展示，必须要改变整条流水线。这就限制了我们快速应对新的数据源或者新的数据使用需求。

图4：新增或改进功能时，架构的分解和对应的变化是正交的，从而导致耦合并且拖慢了交付。

专业且独立的技术团队

当前数据平台的第三个弊端，与我们如何建立平台团队有关系。当我们更近距离观察这些构建和维护数据平台的工程师们，会发现他们是一群超专业的工程师，和那些生产数据或者使用数据的部门是隔离开的。数据平台工程师通常不仅组织结构上的独立，而且通常他们具备大数据工具的专业经验，且缺乏业务相关领域的知识，因而被组成一个独立的团队。

图5：专业且独立的数据平台团队

我个人并不羡慕平台工程师的工作。一方面，他们需要从其他团队消费数据，但是其他团队并没有动力提供那么真实、准确、有意义的数据。而另一方面，他们对生产数据的领域又知之甚少，缺乏专业知识。他们需要为各需求方提供数据，却不了解数据需求方的领域知识。

在流媒体平台这个例子中，在数据源一侧，我们有跨职能的“播放器”团队，可以提供用户如何使用播放器功能的有效信息，比如“播放乐曲事件”、“购买事件”、“播放的音频质量”等等；在数据的另一端，是跨职能的数据消费团队，例如“歌曲推荐团队”推荐歌曲，“销售团队”报告销售KPI，“结算团队”通过计算播放事件数量支付给歌手费用等等。不幸的是，加载中间的数据平台团队，需要付诸全力才能为生产端和消费端提供合适的数据。

但实际上，我们发现数据平台团队，很难获得数据生产端的支持，又很容易被数据消费端争抢任务排期，这导致数据平台团队一直被撕扯。

我们当前创建的技术架构和组织结构都无法进行扩展，自然不能实现在创建数据驱动型组织时设立的目标。

下一代企业数据平台架构

使用分布式数据网格（Data Mesh）拥抱无处不在的数据。

针对上面讨论的集中式架构的弊端，我们的应对是什么？我认为是进行必要的范式转换（paradigm shift）。在构建大规模分布式体系架构中已经有所应用，并且在业界已经取得了不错的成果。

我建议下一代企业数据平台架构，包括：分布式领域驱动架构（Distributed Domain Driven Architecture），自助服务平台设计（Self-serve Platform Design），以及数据产品思想（Product Thinking with Data）

图6：转变范式，构建下一代数据平台

尽管听起来有很多时髦的词，但这些技术在特定领域已经产生了重大的积极影响。让我们深入研究如何将这些技术应用于数据领域，以摆脱多年来陈旧的数仓体系结构。

数据 与 分布式领域驱动架构相结合

面向领域的数据的拆分

埃里克·埃文斯（Eric Evans）的著作《域驱动设计》（Domain-Driven Design）深刻地影响了现代体系架构思想，也影响了组织架构模型。它通过将系统分解为：围绕业务域构建分布式服务的微服务体系结构。从根本上改变了团队的组成方式，从而使团队可以独立自主地拥有特定领域的能力。

尽管在许多时候，我们都采用了面向领域的拆分方式，但奇怪的是，在涉及数据时，我们却忽略了业务领域的概念。在数据平台体系结构中最接近DDD概念的地方，是数据源端的系统生产的业务领域的事件，然后由数据平台来接收它们。但是，在此之后，数据就失去了领域的概念，该领域团队也失去了对数据的掌控。

领域边界上下文是划分数据集归属的有力工具。Ben Stopford的《Data Dichotomy》一文介绍了通过流共享领域数据集的概念。

为了数据平台的去中心化，我们需要反思我们的数据，反思数据所处的位置和责任归属。不应将数据从特定领域全部归集到数据湖或平台，而是应该由数据所归属的“领域”以方便消费的方式保存他们的数据并提供数据服务。

在我们的例子中，与其让数据里从媒体播放器流入中心数据平台，不如思考让“播放器域”自己掌握所有数据并提供服务，其他下游团队进行访问。数据集存储在哪里，如何流动，这是“播放器域”自己的技术实现。物理存储可以是Amazon S3这样的基础架构，但是数据的内容和归属依然属于生产它的团队。类似的，“推荐域”通过创建适合他们自己业务的数据格式，比如通过消费“播放器域”的数据，经过处理和计算，保存到图数据库存储。如果其他领域，例如“发现新歌手域”发现“推荐域”中图数据有意义，他们就可以选择拉取这些数据。

这意味着，我们可能需要复制数据，然后做一些计算变成新的领域数据。例如，将时间序列的播放事件，转换为歌手相关的图。

我们需要转变思维方式，从推送和获取（传统的通过ETL和事件流处理数据的方式），转换到跨领域的服务和拉取模型。

在面向领域数据平台中基本的架构单元是“领域”，而不是数据流水线上的不同处理阶段。

图7：根据领域划分数据架构和团队。

面向源的域数据

一些领域和源数据的组成是天然一致的。源领域数据集，展示的是业务上的事实。源领域的数据集对应的是原始业务系统中的数据，代表着真实系统产生的数据。在我们的流媒体例子中，“用户如何使用服务”，这样的业务创建的数据，例如“用户点击流”、“音频播放质量流”。这些是数据就是由原始业务系统生成的。“播放器域”最了解“用户点击流”数据。

在理想情况下，一个业务系统的团队，除了负责提供业务功能，也应该负责提供他们所处领域的源数据集。在企业中，没有一对一的领域和系统的对应关系。通常是许多系统，各自提供一部分数据，同时属于一个领域，有些是旧系统，有些易变动。因此这里有许多源数据集需要对齐（事实数据集），最终需要汇聚成为一个内聚的领域对齐的数据集。

业务事实，最佳表现形式是”业务领域事件“，以“带时间戳的事件的分布式日志”的形式存储并提供服务，获得授权的消费者可访问这些数据。

除了时序事件外，源数据域还应该提供便于消费的历史数据快照，这些快照以特定间隔汇总数据，以反映域数据的变化。例如，在“唱片公司”源域中，应该同时提供每月汇总唱片公司上架音乐的数据。

需要注意的是，对齐后的源域数据集必须与内部原始系统的数据集分开存放。领域数据集的性质与原始系统用来提供服务的系统内部数据完全不同。与原始系统数据相比，领域数据集具有更大的体积，代表不变历史事实，并且更改频率较低。因此，领域数据的存储必须适合大数据，并且必须与现有的业务数据库分开。在后续的数据和自助服务平台的设计部分，会介绍如何创建大数据存储和服务基础设施。

源域数据集是最基础的数据集，更改频率较低，因为业务事实并不经常变更。预计这些源域数据集将被永久保存，随着组织数据驱动的演进，他们可以始终追溯到业务事实，并创建新的汇总或者预测。

注意，源域数据集在创建时几乎代表原始数据，并且不针对特定数据使用者进行数据拟合或建模。

面向消费的共享域数据

另一些领域数据与他们的使用者密切相关。在数据消费端的领域数据集，是为了满足特定的数据使用场景。例如，“社交推荐域”侧重于根据用户之间的关系，提供推荐服务，因此需要创建适合此特定需求的域数据集；也许是“用户社交网络图”的形式。显然此图数据集对于推荐场景很适用，除此之外，对于“听众通知域”也可能有意义，推送给听众的通知，包括其社交网络中的“朋友正在听”的消息。因此，“用户社交网络”有可能成为共享的新领域数据集，供多个数据消费者使用。 “用户社交网络”域的团队有责任提供“用户社交网络域”的精确数据视图并及时更新。

消费者对齐的域数据集与源域数据集相比具有不同的性质。数据结构上发生了更多的变更，并且源域事件被转换聚合为适合特定访问模型的视图和结构，例如我们上面看到的图数据的示例。面向领域的数据平台应该能够轻松地从源域数据集重新生成这些消费域数据集。

将分布式数据流水线作为领域内部实现

尽管数据集的归属从中心平台委派给各个域，但数据仍然需要经过清理、预处理、聚合和服务几个阶段。在新体系结构中，数据流水线只是数据域内部的实现，并在该域内部执行。这样，我们将看到数据流水线的阶段分散到每个域中。

例如，源域需要包括对其域事件的清理，去重，扩展，以便其他域可以使用它们。而无需使用者再次重复这些工作。因此每个域数据集的提供者都必须为其所提供的数据设定“服务质量目标”（Service Level Objectives）：数据实效性，数据错误率等。例如，提供音频“播放点击流”的“播放器域”应当在其域数据流水线中清理和标准化数据，从而提供去重后近实时的“音频单击播放事件”，并且符合企业设定的编码标准。

类似的，集中式流水线的聚合阶段功能，成为了消费域内部的实现细节。

图8：将数据流水线放到各个域中，作为领域的内部实现。

有人会对此提出异议：该模型会导致每个领域需要各自实现自己的数据处理流水线，在技术栈和工具方面带来重复的工作量。对于这个问题，我将在后续介绍自助服务共享数据基础架构平台时，回答这个问题 。

数据和产品思维融合

采用分布式数据集，将数据和流水线的实现放到各个业务领域之内，就需要关注数据集的可访问性、可用性、协调性。在这里需要借鉴产品化和数据资产所有权的思想。

域数据作为产品

在过去的十年中，业务领域已将产品化思维融入到他们提供的业务功能中了。业务领域团队将这些功能作为API提供给其他开发人员，用于构建上层的功能。这些团队致力于为他们的API创建最佳的开发人员体验；包括可发现且易理解的API文档，API测试沙箱，以及和质量密切相关的KPI指标。

为了使分布式数据平台取得同样的成功，领域数据团队必须以严谨的产品化思维，审视他们提供的数据集。将数据资产视为产品，将使用数据的数据科学家、机器学习工程师、数据工程师等视为自己的客户。

图9：产品化领域数据的特征

在互联网媒体流业务这个例子中，它的关键领域之一是“播放事件”，即：谁，在何时，在何地，播放了哪些歌曲。这个关键领域在组织中有不同的使用者。例如，对用户体验以及服务质量感兴趣的支持团队，需要近实时的播放事件数据，以便在客户体验下降或接到投诉电话的情况下可以快速响应。也有一些数据使用者更需要按日或按月汇总的歌曲播放事件的历史快照。

在这种情况下，我们的“播放的歌曲域”需要为其他数据用户提供了两个不同的数据集作为产品。在流式存储上的实时播放事件，以及在对象存储中的聚合播放事件的统计。

任何技术产品（在这种情况下是领域数据集产品）的一项衡量标准，就是使它们的顾客满意度。数据产品的顾客包括：数据工程师、机器学习工程师、数据科学家。为了向顾客提供最佳的用户体验，领域数据产品需要具有以下基本素质：

可发现

数据产品必须易于发现。常见的实现方式是对所有可用数据产品及其元信息（例如其所有者，来源来源，血统，样本数据集等）进行注册，编制数据目录。集中式可发现性服务，允许数据消费者，工程师和科学家组织，能够轻松找到他们感兴趣的数据集。每个域数据产品都必须在此集中式数据目录中注册以方便他人发现。

请注意，这里的观点转变：从单个平台提取并拥有全部数据，到各个数据域以可发现的方式提供产品。

可寻址

数据产品一旦发现，应遵循全局约定，允许用户以编程方式访问数据的唯一地址。根据数据的基础存储和格式，可以为数据设计不同的命名约定。考虑到易用性，在一个分布式体系结构中，有必要制定通用的约定。不同的域可以使用不同形式的存储和提供数据，事件可能提供诸如Kafka之类的流式存储和访问，列式数据可能使用CSV文件或Parquet文件存储在AWS S3上。标准的数据集寻址方式，有助于消除了查找和访问时的信息壁垒。

诚实守信

没有人会使用他们不信任的产品。在传统的数据平台中，ETL 可能有错误，不能反映业务真相，数据根本不可信。因此，这也是集中式数据流水线的大部分工作，在获取数据后，进行数据清洗。

根本性的转变，是要求数据产品的提供者，围绕数据的真实性设定可接受的服务水平目标（Service Level Objective）。因此，在创建数据产品时，需要数据清理，并且执行自动数据完整性测试，来保证数据产品的质量水平。提供数据来源和数据血缘，帮助消费者增强对数据产品的信任，以及确定数据适合相应的需求。

数据完整性（质量）指标的目标值，在不同的领域数据产品之间可以有所不同。例如，“播放事件”域可以提供两种不同的数据产品，一种近实时，准确性较低，可能包括丢失或重复的事件；而另一种则具有较长的延迟，但事件准确性较高。每个数据产品定义一组完整性和可靠性等指标，作为服务水平目标（SLOs）。

自描述的语义和语法

优质的产品不需要消费者深究即可使用：可以独立地发现、理解和消费它们。将数据集构建为便于使用的产品，以供数据工程师和数据科学家使用，这需要对数据的语义和语法进行充分描述，理想情况下还应提供数据集的示例。数据的模式（schema），是提供自助数据资产的起点。

可互操作且符合全局标准

分布式域数据体系结构的主要关注问题是跨域关联数据的能力：连接，过滤，聚合等。跨域关联数据的关键是：遵循标准和统一规则。此类标准化应属于全局治理范畴的，以实现多域数据集之间的互操作性。此类标准化关注：字段类型格式化，跨域识别多义词，约定数据集地址，元数据公共字段，事件格式（例如CloudEvents等）。

例如，在媒体流业务中，“歌手”可能出现在不同的数据域中，并且在每个域中具有不同的属性和标识符。 “播放事件流”域对歌手的标识，可能与负责发票和付款的“歌手结算域”的不同。但是，为了能够在不同域数据产品之间关联歌手数据，我们需要就如何标识歌手达成一致。一种方法是考虑“歌手”的唯一全局实体标识符，这与管理个人身份的方式类似。

全局的通信的互操作和标准化，是构建分布式系统的基础支柱之一。

安全并受全局访问控制

无论体系结构是否集中化，都必须能够安全地访问数据集。在分散的面向域的数据产品的世界中，对每个域数据产品，都以更精细的粒度进行访问控制。与业务领域类似，访问控制策略可以集中定义，但在访问每个单独的数据集产品时应用。使用企业身份管理系统（SSO） 和基于角色的访问控制策略定义是实现产品数据集访问控制的较为便捷方法。

数据和自助服务平台的设计部分，描述了一个各数据产品可以轻松拥有这些能力的，共享基础架构。

域数据跨职能团队

将领域数据集作为产品，需要增加新的：（a）数据产品负责人（b）数据工程师。

数据产品负责人围绕数据产品的愿景和路线图做出决策，关注数据消费者的满意度，并不断量化和提高其拥有和生产的数据的质量和丰富性。负责领域数据集的生命周期管理，以及何时更改，修订和淘汰数据和模式。还需要权衡数据使用者的需求之间的优先级。

数据产品负责人必须为其数据产品定义成功标准和与业务相关的KPI指标。例如，数据产品的消费者从发现数据和使用数据的时间周期，是可衡量的指标。

为了构建和运行领域内部数据流水线，团队中必须包括数据工程师。这种跨职能团队的一个奇妙副作用是不同技能的交叉互补。我目前的行业观察是，一些数据工程师虽然能够使用数据工具，但在构建数据资产时缺乏软件工程标准实践，例如缺少连续交付和自动化测试。同样，构建业务系统的软件工程师通常也没有使用数据工具的经验。如果能消除这种技能孤岛，将创建出更强大精深的数据工程技能库。我们已经观察到与DevOps相类似的跨技能交叉，并诞生了新型工程师的岗位，例如 SRE。

数据必须被视为任何软件生态系统的基础，因此软件工程师必须将数据产品开发的经验和知识添加到他们的工具箱中。同样，基础设施工程师也需要增加管理数据基础设施的知识和经验。组织必须提供职业发展途径。

图10：具有明确数据产品责任的跨职能的领域域数据团队

数据和自助平台设计融合 Data and self-serve platform design convergence

将数据的责任划分给各个域的主要问题之一，是在每个域中重复建设数据流水线的技术栈和基础架构。幸运的是，将通用基础结构构建为平台，是一个众所周知并且已经有解决方案的问题。尽管工具和技术在数据生态系统中还不成熟。

将领域无关的基础架构功能放到基础架构平台中，解决了重复设置数据管道引擎，存储和流基础架构的工作。数据基础架构团队掌握并提供技术，各个领域获取、处理、存储和服务其数据产品。

图11：抽取域无关的数据流水线基础架构，并将工具构建到独立的数据基础平台架构中

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

• 可扩展的多语言大数据存储
• 静态和动态数据加密
• 数据产品版本控制
• 数据产品schema
• 数据产品逆向标识
• 统一的数据访问控制和记录
• 数据管道实现和编排
• 数据产品发现，catalog注册和发布
• 数据治理与标准化
• 数据产品血缘
• 数据产品监控/报警/日志
• 数据产品质量指标（收集和共享）
• 内存数据缓存
• 统一身份标识管理
• 计算和数据本地化

衡量自助数据基础架构的成功与否的标准，是能否减少“创建新数据产品的时间”。这需要实现“数据产品”所需的自动化能力。例如，通过配置和脚本自动执行数据提取，创建数据产品的脚手架工具，在catalog中自动注册数据产品等。

使用云作为基础设施，可以减少提供按需访问的运营成本和工作量，但是并不能完全消除需要在业务环境中进行部署的工作。无论云服务商如何，数据基础架构团队都应该有一组丰富且不断增长的数据基础架构服务。

范式向数据网格转移

现在，让我们一起来回顾本文。我们研究了当前数据平台的一些基本特征： 集中式，单体式，高度耦合的管道架构，由独立且专业化的数据工程师进行维护。我们还介绍了数据网格作为数据平台的构建 ； 面向领域的分布式数据产品，由独立的跨职能团队负责，这些团队具有数据工程师和数据产品负责人，使用通用数据基础结构作为平台来托管、准备数据资产，并对其他客户提供服务。

数据网格平台是经过精心设计的分布式数据体系结构，通过集中治理和标准化实现领域之间互操作性，并通过共享和统一的自助式数据基础架构实现。很明显，这与之前无法访问的数据孤岛的情况相去甚远。

图12：30,000英尺视角的数据网格架构

您可能会问，数据湖或数据仓库在此体系结构中位于什么位置？它们只是网格上的节点。我们很有可能不需要数据湖，因为保存原始数据的分布式日志和存储，是一个产品化的数据产品，是可以寻址的。但是，如果确实需要更改数据的原始格式以进行进一步的数据发掘（例如打标记），则对此有需求的域，也可能会创建自己的数据湖或数据中心。

因此，数据湖不再是整个体系结构的核心。我们将继续利用数据湖的某些原理，例如使不可变数据可用于发掘和分析用途 。我们也将继续使用数据湖工具，但是会将其用于数据产品的内部实现或作为共享数据基础架构的一部分。

实际上，这使我们回到了一切的起点： 2010年，詹姆斯·迪克森（James Dixon）打算将一个数据湖用于单个域，而多个数据域将形成一个“水系”。

主要转变是将领域数据产品视为主要关注点，而将数据湖工具和管道视为次要的关注点——实现细节。这将当前的思维模型从集中式数据湖转变为可以很好地协同工作的数据产品生态系统，即数据网格。

相同的原则适用于用于业务报表和可视化的数据仓库。它们也只是网格上的一个节点，可能位于面向数据消费者的网格边缘上。

必须承认，尽管看到数据网格实践已在有些应用，但是企业如果大规模的采用仍然有很长的路要走。但我不认为这是技术限制，我们今天使用的所有工具都可以容纳多个团队。特别是批流一体化工具，诸如Apache Beam或 Google Cloud Dataflow之类，可以轻松地处理可寻址的各类数据集。

诸如Google Cloud Data Catalog之类的数据目录平台 提供了集中的可发现性，访问控制和分布式域数据集的治理。云端数据存储也有多种选择。

需求是真实的，工具也已经准备就绪。由组织的工程师和领导者需要认识到，如果仅使用新的基于云的工具，但以原有的方式建设大数据平台或数据湖，只会重蹈覆辙。

这种范式转换需要一套新的治理理念：

• 数据服务，胜过数据获取；
• 数据的发现和使用，胜过提取和加载；
• 发布流式事件，胜过流水线数据流动；
• 数据产品生态，胜过集中数据平台。

将单体大数据体系，分解为协同、协作、分布式生态系统——数据网格。

---

参考资料

1. https://www.thoughtworks.com/cn/radar/techniques/data-mesh
2. https://martinfowler.com/articles/data-monolith-to-mesh.html
3. http://www.tuzei8.com/distributed-data-mesh/