如何从单体数据湖迁移到分布式数据网格

背景

许多企业正在投资他们的下一代数据湖，希望大规模地应用数据，以提供业务洞察力和高效第做出自动化的智能决策。基于数据湖的大数据平台是常见的错误实现模式，因为这往往会导致大规模无法兑现的承诺。为了克服这样的错误模式，我们需要从中心化的数据湖或其前身数据仓库，转向借鉴现代分布式架构：将领域视为首要关注点、应用平台思维创建自助数据基础架构，并将数据视为产品。

我合作的许多公司的首要战略目标之一仍然是成为数据驱动的组织。
我的客户非常清楚获得智能授权的好处：提供基于数据和超个性化的最佳客户体验；通过数据驱动的优化降低运营成本和时间；并赋予员工趋势分析和商业智能的超能力。他们一直在大力投资建设数据和智能平台等支持平台。尽管在构建此类支持平台方面付出了越来越多的努力和投资，但这些组织发现结果并不理想。

我认为在转型为数据驱动组织的过程中，面临着多方面的复杂性；例如，迁移数十年前的遗留系统、公司历史文化对依赖数据模式的抵制，以及不断竞争的高优先级业务。然而，我想与您分享的是从架构角度导致很多失败的数据平台。我展示了我们如何适应和应用过去十年在大规模构建分布式架构到数据领域的经验；我将介绍一种新的企业数据架构，我称之为数据网格data mesh。

在继续阅读之前，先暂时搁置对当前传统数据平台架构已经建立的深层假设和偏见；对从单一和集中式数据湖转向智能分布式数据网格架构的可能性，持开放态度；接受数据是永远存在、无处不在和分布式的特性。

当前企业数据平台架构

集中式、单体式和非领域的，也就是数据湖。

几乎与我合作的每个客户都在规划或构建他们的第三代数据和智能平台，同时承认过去几代数据平台的失败：

第一代：专用的企业数据仓库和智能平台。价格高昂的解决方案给公司留下了同样大量的技术债务；数以千计无法维护的 ETL 作业、表格和报告，这些技术债务只有一小部分专业人士才能理解，从而导致不能充分发挥对业务的积极影响。
第二代：以数据湖作为银弹的大数据生态系统。复杂的大数据生态系统和由超专业数据工程师组成的独立团队运营的长时间运行的批处理作业，创造了数据湖怪物，充其量只是用于大量的研发分析；承诺过高而实现不足。

第三代即当前一代数据平台或多或少与上一代相似，不同点包括： (a) 使用 Kappa 等架构，实现了实时的流式数据的变得可用，(b)使用如Apache Beam等框架，统一批处理和流处理以进行数据转换，以及 © 完全采用基于云的托管服务，用于存储、数据管道执行引擎和机器学习平台。很明显，第三代数据平台正在解决前几代的遗留一些问题，例如实时数据分析，以及降低管理大数据基础设施的成本。然而，它仍然受到许多导致前几代失败的潜在特征的影响。

架构失败模式

为了解开各代数据平台所具有的底层限制，让我们来看看它们的架构和特性。在这篇文章中，我以Spotify、SoundCloud、Apple iTunes等互联网媒体流业务领域为例来阐明一些概念。

中心化和单体式

在 30,000 英尺处，数据平台架构如下图 1 所示；一个集中的架构，其目标是：

从企业的各个角落获取数据，包括运营和事务系统、运营业务的领域部门、或者增强企业知识的外部数据提供者。例如在流媒体业务中，数据平台负责采集大量数据：“媒体播放器性能”、“用户与播放器的互动方式”、“播放的歌曲”、“他们关注的艺术家”、作为企业已加入的“标签和艺术家”、与艺术家的“财务交易”以及外部市场研究数据，例如“客户人口统计”信息。
清理、丰富源数据，并将其转换为可满足不同消费者需求的值得信赖的数据。在我们的示例中，其中一项转换将用户交互的点击流转变为富含用户详细信息的有意义的会话。这试图将用户的旅程和行为重建为聚合视图。
将数据集提供给具有不同需求的各种消费者。这范围从探索数据以寻找洞察力的分析消费、基于机器学习的决策制定，到总结业务绩效的商业智能报告。在我们的媒体流示例中，该平台可以通过分布式日志接口（例如 Kafka）提供有关全球媒体播放器的近乎实时的错误和质量信息，或者提供正在播放的特定艺术家记录的静态聚合视图以驱动财务支付计算给艺术家和唱片公司。

单体数据平台托管和拥有逻辑上属于不同领域的数据是一个公认的约定，例如“播放事件”、“销售 KPI”、“艺术家”、“专辑”、“标签”、“音频”、“播客”、“音乐事件”等；来自大量不同领域的数据。

虽然在过去十年中，我们已经成功地将领域驱动设计和确定边界的上下文应用于运营系统，但我们在很大程度上忽视了数据平台中的领域概念。我们已经将数据所有权从面向领域转移到与领域无关的集中的数据中心。我们以创建其中最大的单体–大数据平台，而自豪。

虽然这种集中式模型适用于拥有较简单的域和较少的多样化消费者的组织，但它不适用于拥有丰富域、大量来源和多样化消费者的企业。

中心化数据平台的架构和组织架构有两个压力点，往往会导致其失败：

无处不在的数据和分散的数据源：随着越来越多的数据变得无处不在，在一个平台的控制下将所有数据统一汇总到一个地方消费的能力会减弱。想象一下，在“客户信息”领域，组织内部和外部有越来越多的来源提供有关现有和潜在客户的信息。我们需要在一个地方采集和存储数据以从不同来源获取价值的假设，将限制我们应对数据来源激增的能力。我认识到数据科学家和分析师等数据用户需要以低开销处理一组多样化的数据集，以及将运营系统数据使用与用于分析目的的数据分开的需要。但我认为现有的集中式解决方案对于拥有丰富域和不断添加新源的大型企业来说并不是最佳答案。
组织的创新议程和消费者激增：组织对快速实验的需求引入了大量使用平台数据的用例。这意味着对数据进行越来越多的转换、聚合、预测和切片，可以满足创新的测试和学习周期。满足数据消费者需求的长响应时间，在历史上一直是组织机构的一个痛点，在现代数据平台架构中仍然如此。

虽然我现在还不想透露我的解决方案，但我需要澄清的是，我并不是提倡通常隐藏在运营系统内部的碎片化、孤立的面向领域的数据；和难以发现、理解和消费的孤立域数据。我不提倡多年积累的技术债务导致的多个碎片化数据仓库，虽然这是行业领导者表达的担忧。但我认为，应对这些意外的无法访问数据孤岛的应对措施并不是创建一个集中的数据平台、一个集中的团队拥有和管理来自所有领域的数据。它不能像我们在上面学到和展示的那样，在组织规模上扩展。

高度耦合的pipe

传统数据平台架构的第二种失效模式与如何分解架构有关。在 10,000 英尺处放大集中式数据平台，架构可以分解为采集、清理、聚合、服务等模块。组织中的架构师和技术领导者分解架构以响应平台的增长。如上一节所述，因为需要引入新资源或响应新消费者，所以平台需要发展壮大。架构师需要找到一种通过将系统分解为原子模块，来扩展系统的方法。如构建进化架构中所述，原子模块是一个具有高度功能内聚性的、可独立部署的组件，其中包括系统正常运行所需的所有结构元素。将系统分解为其原子模块背后的动机是创建独立的团队，每个团队都可以构建和操作原子模块。这些团队之间的并行工作，以实现更高的运营可扩展性和速度。

鉴于前几代数据平台架构的影响，架构师将数据平台分解为数据处理阶段的管道。一个在非常高的层次上围绕处理数据的技术实现实现功能内聚的管道，实现采集、准备、聚合、服务等的能力。

尽管此模型通过将团队分配到管道的不同阶段，提供了一定程度的扩展能力。它有一个固有的限制，会减慢功能的交付速度。它在管道的各个阶段之间具有高度耦合，对于提交一个独立的功能或价值，需要实现管道高度耦合的各个阶段。这些分解和变化轴成正交关系。

让我们看看我们的媒体流示例。互联网媒体流平台具有强烈领域结构特性，这些结构围绕着他们提供的媒体类型。通常以“歌曲”和“专辑”开始他们的服务，然后扩展到“音乐活动”、“播客”、“广播节目”、“电影”等。启用单个新功能，例如对“播客播放率”，需要更改管道的所有组件。团队必须引入新的采集服务、新的清理和准备以及用于查看播客播放率的聚合操作。这需要跨越不同组件和团队共同工作。许多数据平台提供通用和基于配置的采集服务，可以应对扩展，例如轻松添加新源或修改现有源，达到最小化引入新源的开销。然而，从消费者的角度来看，这并没有消除引入新数据集的端到端依赖管理。尽管在纸面上，管道架构可能看起来好像我们已经实现了管道阶段的原子模块，但实际上整个管道，就是一个单体平台，是必须更改以适应新功能的最小单元：解锁新数据集并使其可用于新的或现有的消费者。这限制了更快的速度和更大规模的响应新消费者或新数据源的能力。

孤立且高度专业化的所有权

当今数据平台的第三种失败模式，与我们如何组织构建和拥有平台的团队有关。当我们放大到足够近，以观察构建和运营数据平台的人的生活时，我们发现一群超专业的数据工程师，他们与数据的来源、数据使用场景或做出决策的组织运营部门完全隔离。数据平台工程师不仅在组织上是孤立的，而且根据他们在大数据工具方面的技术专长，通常缺乏业务和领域知识，他们被分离并分组到一个团队中。

我个人并不羡慕数据平台工程师的生活。他们需要使用来自没有动力提供有意义、真实和正确数据的团队的数据。他们对生成数据的源领域知之甚少，并且缺乏团队中的领域专业知识。他们需要为各种不同的需求（运营或分析）提供数据，但对数据的应用没有清晰的了解，也不是数据消费领域的专家。

例如，在媒体流领域，在源端，我们有跨职能的“媒体播放器”团队，提供有关用户如何与他们提供的特定功能交互的信息，例如“播放歌曲事件”、“购买事件”、“播放音频质量”等；另一端是消费数据的跨职能团队，如“歌曲推荐”团队、报告销售 KPI的“销售团队”、根据播放事件计算和支付艺术家报酬的“艺术家支付团队”等等。可悲的是中间的数据平台团队，他们通过努力为所有来源和消费端提供合适的数据。

实际上，我们看到的是一个脱节的数据源团队、在数据平台团队积压工作中争夺一席之地的沮丧的数据消费团队和一个过度紧张的数据平台团队。

我们创建的架构和组织结构不能扩展，也不能履行创建数据驱动组织的承诺。

下一个企业数据平台架构

它通过分布式数据网格Data Mesh拥抱无处不在的数据。

那么我们上面讨论那些导致数据平台失败的模式和特征，如何解决？在我看来，范式转变是必要的。这种转变是有助于构建大规模现代分布式架构的关键技术节点，是整个科技行业都在加速采用并创造了成果的技术。

我建议下一个企业数据平台架构采用：分布式领域驱动架构、自助平台设计和与融合数据的产品思维。

虽然这听起来像是一句由很多流行语拼凑的话，但这些技术中的每一种细节，都对运营系统技术基础的现代化产生了特定且令人难以置信的积极影响。让我们深入探讨如何将这些理论中的每一种技术应用于数据领域，从多年遗留的数据仓库架构中摆脱出来。

数据和分布式领域驱动融合架构

面向领域的数据分解和所有权

Eric Evans 的著作《领域驱动设计》深刻影响了现代架构思维，进而影响了组织结构。它通过将系统分解为围绕业务领域功能构建的分布式服务，来影响微服务架构。它从根本上改变了团队的组织方式，使团队可以独立自主地拥有领域能力。

虽然我们在实现运营能力时，采用了面向领域的分解和面向领域的所有权。但奇怪的是，我们在涉及数据时却忽略了业务领域的概念。
在数据平台架构中最接近DDD理念的应用是产生业务驱动事件的源运营系统，以及采集这些事件的单体平台。然而，领域的概念，以及对这些领域数据分属不同团队的所有权，在采集点之外就完全消失了。

Domain Bounded Context 是一个用于设计数据集所有权的非常强大的工具。 Ben Stopford 的《数据二分法》揭示了通过数据流共享域数据集的概念。

为了分解单体的数据平台，需要改变对数据的看法，包括数据的位置和所有权。采用易于使用的方式，托管和管理领域数据集，而不是将数据放入一个集中的数据湖或数据平台。

在我们的示例中，与其想象数据从媒体播放器流入某种集中式的地方以供集中式团队接收，不如想象为一个播放器领域拥有并提供其数据集，供下游任何团队出于任何目的访问。数据集实际所在的物理位置及其流转方式是“玩家域”内部的技术实现。物理存储当然可以使用集中式基础设施，例如 Amazon S3 存储桶，但玩家数据集的内容和所有权仍属于生成它们的领域模块。同样，在我们的示例中，“推荐”领域模块消费“玩家”领域的数据集，生成适合自身应用格式的数据集，例如图数据库。如果有其他域（例如“新艺术家发现域”）发现“推荐域”图数据集有用，则他们可以选择拉取并访问该图数据集。

这意味着我们可能会在不同域中复制数据，因为我们将它们转换为适合该特定域的格式，例如相关艺术家关系图的时间序列播放事件。

这需要将我们的思维从传统上通过 ETL 或事件流（当前更流行的方式）的推送和采集，转变为跨所有域的服务和拉取模型。

面向领域的数据平台中的原子模块是一个领域，而不是管道的阶段。

面向源的领域数据

一些域自然地与数据的来源对齐。源域数据集代表了业务的事实和现实。源域数据集捕获的数据与其源头的业务系统、现实系统生成的内容非常接近。在我们的示例中，诸如“用户如何与服务交互”或“载入标签的过程”等业务事实直接创建域数据集，例如“用户点击流”、“音频播放质量流”和“载入标签”。位于源端的运营系统最了解这些事实，因为这些信息是由它们产生的。例如，媒体播放器系统最了解“用户点击流”。

在成熟和理想的情况下，运营系统及其团队或组织单元不仅负责提供业务能力，还负责提供其业务领域的记录作为源领域数据集。在企业层次上，领域概念和数据源系统之间从来不是一对一的映射。通常有许多系统，能够为部分领域数据提供服务，其中一些是历史遗留的，另一些是易于更改的。因此，可能有许多与数据源对齐的数据集，即现实数据集，最终需要聚合到一个内聚的领域对齐数据集。

业务事实最好以业务领域事件的形式呈现和存储，并可以作为带时间戳事件的分布式日志提供给任何已授权的消费者访问。

除了实时的事件之外，源数据域还应该提供易于使用的历史快照，以及在一个时间间隔内的聚合，该时间间隔能够密切反应该领域的变化。例如，在“注册标签”数据源领域中，它显示了为流媒体业务提供音乐的艺术家的标签。按月汇总注册标签是一个合理的视图，该视图是通过处理“注册标签”生成的额外事件。

请注意，与数据源对齐的领域据集必须与源系统的内部的数据集分开。领域数据集的性质与运营系统用于完成其工作的内部数据有很大不同。它们具有更大的体积，表示不可变的基于时间的记录，并且比它们的系统更低的更改频率。为此，实际的底层存储必须适合大数据，并与现有的运营数据库分开。数据和自助服务平台设计融合章节描述了如何创建大数据存储和服务基础设施。

源域数据集是最基础的数据集，更改频率较低，因为业务事实不会频繁更改。预计这些领域数据集将被一直捕获并且可供使用，以便随着组织更新其数据驱动和智能服务，它们始终可以回到业务事实，并创建新的聚合或预测。

请注意，源域数据集与创建时的原始数据密切相关，并未针对特定消费者进行拟合或建模。

面向消费者共享的领域数据

一些领域与消费密切相关。消费者领域的数据集和拥有它们的团队，旨在满足一组与之密切相关的用例。例如，“社交推荐域”专注于根据用户彼此之间的社交联系提供推荐，该领域的数据集是为了满足这一特殊需求而创建的。也许通过“用户社交网络图表示”。虽然此图数据集对于推荐用例很有用，但它对于“听众通知”领域也可能有用，该领域提供有关发送给听众的不同类型通知的数据，包括他们社交网络中的人们正在收听的内容。因此，“用户社交网络”有可能成为供多个消费者共享使用，新物化的领域数据集。 “用户社交网络”团队专注于提供一个“用户社交网络”最新的视图。

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

领域内部实现的分布式管道

虽然数据集的所有权从集中的平台委托给了领域，但仍然需要清理、准备、聚合和提供数据，数据管道的使用也是如此。在这种架构中，数据管道的复杂性和功能实现仅在数据域的内部。因此，我们将在每个域中看到数据管道的各个阶段。

例如，数据源领域需要包括对其域事件的清理、去重、丰富，以便其他域可以使用时无需重复清理。每个域数据集都必须为其提供的数据质量建立服务级别目标：及时性、错误率等。例如，我们提供音频“播放点击流”的媒体播放器域，可以在域中包括清理和标准化的管道，从而提供去重的近实时“播放音频点击事件”流，这些数据也符合组织的事件编码标准。

同样，我们将看到集中式管道的聚合阶段进入消费域的实现细节。

有人可能会争辩说，这种模型可能会导致每个领域的重复工作，包括创建自己的数据处理管道实现、技术堆栈和工具。后面在讨论数据和平台思维与自助共享数据基础设施作为平台的融合时，我将很快解决这个问题。

数据与产品思维融合

将数据所有权和数据管道实施分配到业务领域的手中，产生了对分布式数据集的可访问性、可用性和协调性的重要关注。这就是学习应用产品思维和数据资产所有权的地方。

领域数据即产品

在过去十年中，运营领域已经将产品思维融入了它们提供给组织其他部门的能力中。领域团队将这些功能作为 API 提供给组织中的其他开发人员，作为创建更高阶价值和功能的构建块。团队努力为其域 API 创造最佳的开发人员体验；包括可发现和可理解的 API 文档、API 测试沙箱以及密切跟踪的质量和采用 KPI。

要使分布式数据平台取得成功，领域数据团队必须以类似的严谨性将产品思维应用于他们提供的数据集；将他们的数据资产视为他们的产品，将组织的其他数据科学家、ML 和数据工程师视为他们的客户。

考虑我们的示例，互联网媒体流业务。它的关键领域之一是“播放事件”，即谁在何时何地播放了哪些歌曲。这个关键域在组织中有不同的消费者；例如，对用户体验和可能的错误感兴趣的近实时消费者，以便在客户体验下降或客户支持来电的情况下可以快速响应以恢复错误。还有一些消费者更喜欢每日或每月歌曲播放事件聚合的历史快照。

在这种情况下，我们的“播放歌曲”域向组织的其他部分提供了作为产品的两个不同数据集；公开在事件流上的实时播放事件，以及公开在对象存储上，以序列化文件形式的聚合之后的播放事件。

任何技术产品（在这种情况下是域数据产品）的一个重要品质是取悦消费者，这里的消费者是指数据工程师、机器学习工程师或数据科学家。为了给消费者提供最好的用户体验，领域数据产品需要具备以下基本素质：

可发现

数据产品必须易于发现。常见的实现是使用全局的注册表和数据目录，所有数据产品在其注册它们的元信息，这些元信息包括所有者、来源、血统、样本数据集等。这种集中的可发现性模块，服务于组织中的数据消费者、工程师和科学家，以便轻松找到他们感兴趣的数据集。每个域数据产品都必须在这个集中的数据目录中注册自己，以便于被发现。

请注意，这里的视角转变是从单一平台提取和拥有使用的数据，到每个域以可发现的方式将其数据作为产品提供给使用者。

可寻址

数据产品一旦被发现，就应该有一个遵循全局惯例的唯一地址，以帮助其用户可以编程方式访问它。组织可能对其数据采用不同的命名约定，具体取决于数据的底层存储和格式。考虑到易用性为目标，在去中心化架构中，需要制定通用约定。不同的域可能以不同的格式存储和提供其数据集，事件可能通过流（例如 Kafka 主题）进行存储和访问，结构化数据集可能使用 CSV 文件，或序列化 Parquet 文件的 AWS S3 存储桶。多语言环境中数据集可寻址性的标准，消除了查找和访问信息时的阻力。

真实可靠

没有人会使用不值得信任的产品。在传统的数据平台中，提取和加载有错误、不反映业务真实性或根本不可信的数据是可以接受的。这也是集中式管道最大的价值所在，采集后清理数据。

根本性转变是要求拥有者提供数据产品围绕真实性的可接受服务水平目标，该指标描述数据产品反映已发生事件的可靠程度或得到正确洞察的概率。在创建数据产品时应用数据清理和自动数据完整性测试是一些用于提供可接受的质量水平的技术。提供数据来源和数据血缘，作为与每个数据产品相关联的元数据，可以帮助消费者进一步信任数据产品及其对满足其特定的需求。

数据完整性（质量）指标的目标值或范围因领域数据产品而异。例如，“播放事件”域可以提供两种不同的数据产品，一种具有较低准确度的近实时数据产品，包括丢失或重复的事件，另一种具有较长的延迟和较高的事件准确度。每个数据产品将其完整性和真实性的目标级别定义并确保为一组 SLO。

自描述语义和语法

优质产品在使用时不需要消费者人工干预：它们可以被独立发现、理解和消费。为l了数据工程师和数据科学家，将数据集构建为方便使用的产品，需要对数据进行良好描述的语义和语法，最好附上样本数据集作为范例。数据模式是提供自助数据资产的起点。

遵循通用标准和可互操作

分布式领域数据架构的主要关注点之一是跨域关联数据，并以出色、有洞察力的方式将它们拼接在一起的能力，例如关联、过滤和聚合等。跨领域有效关联数据的关键是遵循某些标准和协调规则，这种标准化应该属于全局范围，以实现多语言领域数据集之间的互操作性。此类标准化工作的共同关注点是字段类型格式、跨不同领域识别多义词、数据集地址约定、通用元数据字段、事件格式（如 CloudEvents）等。

例如，在流媒体业务中，“艺术家”可能出现在不同的域中，并且在每个域中具有不同的属性和标识符。 “播放事件流”域对艺术家的识别可能与处理发票和付款的“艺术家付款”域不同。然而，为了能够将艺术家的数据与不同领域的数据产品相关联，我们需要就如何将艺术家识别为多义词达成一致。一种方法是考虑具有联合实体的“艺术家”和全局唯一标识符，类似于联合身份的管理方式。

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

安全和全局范围内的访问控制

无论架构是否集中式的，对产品数据集的访问必须是安全的。在去中心化的、面向领域的数据产品世界中，访问控制有着更精细的粒度，即每个领域的数据产品单独设置访问控制。与操作领域类似，访问控制策略可以集中定义，然后应用于每个单独的数据集产品。使用企业身份管理系统 (SSO) 和基于角色的访问控制策略定义是实现产品数据集访问控制的便捷方式。

在数据和自助服务平台设计融合章节描述的共享基础架构，可以轻松自动地为每个数据产品启用上述功能。

领域数据的跨职能团队

在数据即产品的领域，需要工程师具有两种身份：数据产品所有者和数据工程师。

数据产品所有者围绕愿景和规划路线图做出决策，关注消费者的满意度，并不断衡量和改进数据的质量和丰富度。负责管理领域数据集的全部生命周期，何时更改、修订和停用数据和模式。在数据消费者的竞争需求之间取得了平衡。

数据产品所有者必须为其数据产品定义成功标准和与业务一致的关键绩效指标 (KPI)。例如，数据产品的消费者成功发现和使用数据产品的前置时间。

为了构建和运营领域的内部数据管道，团队必须包括数据工程师。这种跨职能团队的一个美妙的副作用是不同技能的融合。我目前的行业观察是，一些数据工程师虽然能胜任使用他们的行业工具，但在构建数据资产时缺乏软件工程标准实践，例如持续交付和自动化测试。同样，构建运营系统的软件工程师通常没有使用数据工程工具集的经验。消除技能集孤岛将给组织带来更大、更深入的数据统计技能集。与类似的 DevOps 风潮中出现了跨技能融合中，出现了新型的工程师，例如SREs。

数据必须被视为任何软件生态系统的基础，因此软件工程师和相关人员必须将开发数据产品的经验和知识添加到他们的工具箱中。同样，基础设施工程师需要增加管理数据基础设施的知识和经验。组织必须提供从通才到数据工程师的职业发展途径。缺乏数据工程技能导致形成只关注局部优化的集中式数据工程团队，正如在孤立和超专业的所有权章节所述。

数据与自助平台设计融合

将数据所有权分配给领域的主要问题之一，是在每个领域中都要使用数据管道和基础设施技术，这将导致工作和技能的重复。幸运的是，将通用基础设施构建为平台，是一个理解和解决的这个问题很好的方式；尽管不可否认，当前数据生态系统中的工具和技术并不成熟。

将与领域无关的基础设施功能收集和提取到数据基础设施平台中，解决了重复建设数据管道引擎、存储和流处理基础设施工作的需要。数据基础架构团队拥有并提供领域捕获、处理、存储和服务其数据产品所需的必要技术。

将数据基础设施构建为平台有两个关键点：(a) 不包含任何特定领域的概念或业务逻辑，使其与领域无关；(b) 确保平台能够隐藏技术的复杂性，提供能够自助式服务方式的数据基础设施组件。为领域工程师提供的自助式数据基础架构，具有非常多的功能特性。这里列举其中几个，如下：

支持多种语言的可扩展大数据存储
静态和动态数据加密
数据产品版本控制
数据产品元数据管理
数据产品去标识化
统一的数据访问控制和日志记录
数据管道的实现和编排
数据产品的发现、注册和发布
数据治理和标准化
数据产品的血缘
数据产品监控、告警和日志
数据产品质量指标（收集和共享）
在内存中缓存数据
联合身份管理
计算和数据本地化

自助数据基础设施的成功标准是降低“创建新数据产品的交付时间”，正如在领域数据即产品章节所述的那样，实现数字产品需要自动化能力。例如，通过在系统中增加数字产品的配置或脚本，自动实现数据的采集、注册等。

使用云基础设施降低了运营成本和工作量，然而这不能完全消除业务上下文中使用更高抽象。无论云提供商如何优秀，数据基础设施团队都要提供丰富且不断增长的数据基础设施服务集。

向数据网格的范式转变

上面已经说了很多，让我们做个总结。当前数据平台的一些基本特征：集中式、单体式、高度耦合的管道架构，由超专业数据工程师的独立操作。而我们引入了无处不在的数据网格平，它是面向领域的分布式数据产品，由独立的跨职能团队拥有，这些团队由数据工程师和数据所有者组成，使用通用的数据基础设施作为平台来托管、准备和服务他们的数据资产。

数据网格平台是一种有意设计的分布式数据架构，遵循集中治理和互操作性标准化原则，由共享和协作的自助数据基础设施实现。我希望它能很清晰地解决无法访问数据的碎片化孤岛问题。

可能会问数据湖或数据仓库在此架构中的位置如何？答案是它们只是网格上的节点。我们很可能不需要数据湖，因为所有原始数据都可以从分布式的日志和存储中获取，这些数据以可寻址的产品形式供用户探索使用。但是，有些情况确实需要更改数据的原始格式，目的是进行进一步探索，例如给数据打上标签。具有此类需求的领域可能会创建自己的数据湖或数据中心。

因此，数据湖不再是整个架构的核心。我们将继续将数据湖的一些原则应用到面向数据源的领域数据产品中，例如使不可变数据可用于探索和分析使用。我们将继续使用数据湖工具，无论是用于数据产品的内部实现还是作为共享数据基础设施的一部分。

事实上，这让我们回到了一切开始的地方：James Dixon 在 2010 年打算将数据湖用于单个域，多个数据域将形成一个“水花园”。

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

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

我承认，虽然数据网格实践在我的客户身上得到应用，但企业规模的采用还有很长的路要走。我认为这不是因为技术的限制，今天我们使用的所有工具都可以适应多个团队之间共享。特别是朝着统一批处理和流处理的工具的转变，例如 Apache Beam 或 Google Cloud Dataflow 等，可以轻松处理可寻址的多语言数据集。

数据目录平台（例如 Google Cloud Data Catalog）提供分布式域数据集的集中可发现性、访问控制和治理。多种云数据存储选项使域数据产品能够选择适合多语言存储的目的。

需求是真实的，工具已准备就绪。组织中的工程师和领导者应该意识到，现有的大数据范式和一个大数据平台或数据湖只会重复过去的失败，不过是使用基于云的新工具而已。

这种范式转变需要一套新的管理原则以及一种新的语言：

提供服务高于数据采集；
‘发现和使用’高于’提取和加载’；
以数据流的形式发布事件，高于通过集中式管道采集数据；
数据产品生态系统，高于集中式的数据平台

让我们将大数据单体分解为一个协调、协作和分布式的数据网格生态系统。