许多企业正在投资他们的下一代数据湖，希望大规模普及数据以提供业务洞察力并最终做出自动化的智能决策。 基于数据湖架构的数据平台具有常见的故障模式，导致无法实现大规模的承诺。 为了解决这些故障模式，我们需要从湖的集中式范式或其前身数据仓库转变。 我们需要转向借鉴现代分布式架构的范式：将域视为首要关注点，应用平台思维创建自助式数据基础设施，并将数据视为产品。

内容

 

• 当前企业数据平台架构
• 架构失效模式
  • 集中式和单体式
  • 耦合流水线分解
  • 孤立和超专业的所有权
• 下一代企业数据平台架构
  • 数据和分布式域驱动架构融合
    • 面向领域的数据分解和所有权
    • 面向源的领域数据
    • 面向消费者和共享域数据
    • 分布式管道作为域内部实现
• 数据与产品思维的融合
  • 领域数据作为产品
    • 可发现的
    • 可寻址
    • 值得信赖和真实
    • 自描述语义和句法
    • 可互操作并受全球标准监管
    • 受全球访问控制的保护和管理
  • 领域数据跨职能团队
• 数据与自助平台设计融合
• 向数据网格的范式转变

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

我同意组织在转型为数据驱动方面面临着多方面的复杂性；从数十年的遗留系统迁移，遗留文化对依赖数据的抵制，以及不断竞争的业务优先事项。然而，我想与您分享的是支撑许多数据平台计划失败的架构观点。我展示了我们如何将过去十年在构建分布式架构方面的知识应用到数据领域；我将介绍一种新的企业数据架构，我称之为数据网格。

在继续阅读之前，我的要求是暂时搁置当前传统数据平台架构范式所建立的深层假设和偏见；对超越单一和集中式数据湖向有意分布式数据网格架构的可能性持开放态度；拥抱数据永远存在、无处不在和分布式的现实。

当前企业数据平台架构

它是集中的、单一的、与领域无关的，也就是数据湖。

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

• 第一代：专有的企业数据仓库和商业智能平台；具有高价格标签的解决方案给公司留下了同样大量的技术债务；数以千计的无法维护的 ETL 作业、表格和报告中的技术债务，只有一小部分专业人士才能理解，从而导致对业务的积极影响未被充分实现。
• 第二代：以数据湖为银弹的大数据生态系统；由超专业数据工程师组成的中央团队运营的复杂大数据生态系统和长期运行的批处理作业创造了数据湖怪物，充其量只能进行研发分析；过度承诺和实现不足。
• 第三代和当前的数据平台或多或少与上一代相似，具有现代化的转变：(a) 使用 Kappa 等架构实现实时数据可用性的流式传输，(b) 统一批处理和流式处理以进行数据转换使用 Apache Beam 等框架，以及 (c) 完全采用基于云的存储托管服务、数据管道执行引擎和机器学习平台。很明显，第三代数据平台正在解决前几代的一些差距，例如实时数据分析，以及降低管理大数据基础设施的成本。然而，它受到许多导致前几代人失败的潜在特征的影响。

架构失效模式

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

集中式和单体式

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

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

Figure 1: The 30,000 ft view of the monolithic data platform

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

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

Figure 2: Centralized data platform with no clear data domain boundaries and ownership of domain oriented data

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

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

• 无处不在的数据和源扩散：随着越来越多的数据变得无处不在，在一个平台的控制下在一个地方消费和协调它的能力正在减弱。想象一下，仅在“客户信息”领域，就有越来越多的资源在组织边界内外提供有关现有和潜在客户的信息。我们需要在一个地方摄取和存储数据以从不同来源获取价值的假设将限制我们对数据源激增做出响应的能力。我认识到数据科学家和分析师等数据用户需要以低开销处理各种数据集，并且需要将操作系统数据使用与用于分析目的的数据分开。但我认为现有的集中式解决方案对于拥有丰富领域和不断增加新资源的大型企业来说并不是最佳答案。
• 组织的创新议程和消费者激增：组织对快速实验的需求引入了大量使用平台数据的用例。这意味着对数据进行越来越多的转换——聚合、预测和切片，可以满足创新的测试和学习周期。满足数据消费者需求的较长响应时间在历史上一直是组织摩擦的一个点，并且在现代数据平台架构中仍然如此。
• 虽然我现在还不想透露我的解决方案，但我需要澄清一下，我并不是在提倡分散的、孤立的、面向领域的数据，这些数据通常隐藏在操作系统的内部。难以发现、理解和消费的孤立领域数据。我并不是在提倡多个分散的数据仓库，这些数据仓库是多年积累的技术债务的结果。这是行业领导者表达的担忧。但我认为，对这些意外的无法访问数据孤岛的反应不是创建一个集中的数据平台，并拥有一个拥有和管理来自所有域的数据的集中团队。正如我们在上面学习和展示的那样，它在组织上没有规模。

耦合流水线分解

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

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

Figure 3: Architectural decomposition of data platform

尽管此模型提供了一定程度的规模，但通过将团队分配到管道的不同阶段，它有一个固有的限制，会减慢功能的交付。它在管道的各个阶段之间具有高度耦合，以提供独立的功能或价值。它与变化轴正交分解。

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

Figure 4: Architecture decomposition is orthogonal to the axis of change when introducing or enhancing features, leading to coupling and slower delivery

孤立和超专业的所有权

当今数据平台的第三种失效模式与我们如何构建构建和拥有平台的团队有关。 当我们放大到足够近来观察构建和运营数据平台的人们的生活时，我们会发现一群超专业的数据工程师与组织的运营部门隔离开来； 数据的来源或使用地点以及用于行动和决策的地点。 数据平台工程师不仅在组织上是孤立的，而且根据他们在大数据工具方面的技术专长，往往缺乏业务和领域知识。

Figure 5: Siloed hyper-specialized data platform team

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

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

实际上，我们发现源团队脱节、沮丧的消费者在数据平台团队积压工作中争夺一席之地，以及数据平台团队过度紧张。

我们创建的架构和组织结构无法扩展，也无法实现创建数据驱动组织的承诺价值。

下一代企业数据平台架构

它通过分布式数据网格包含无处不在的数据。

那么我们上面讨论的故障模式和特征的答案是什么？在我看来，范式转变是必要的。有助于大规模构建现代分布式架构的技术交汇处的范式转变；整个科技行业已加速采用并创造了成功成果的技术。

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

Figure 6: Convergence: the paradigm shift for building the next data platforms

尽管这听起来像是一句话中的很多流行语，但这些技术中的每一种都对操作系统技术基础的现代化产生了特定且令人难以置信的积极影响。让我们深入探讨如何将这些学科中的每一个应用于数据世界，以摆脱从多年遗留数据仓库架构中继承下来的当前范式。

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

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

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

尽管我们在实现运营能力时采用了面向领域的分解和所有权，但奇怪的是，我们在数据方面忽略了业务领域的概念。 DDD 在数据平台架构中最接近的应用是让源操作系统发出其业务领域事件，并让单体数据平台摄取它们。然而，在摄取点之外，域的概念和不同团队对域数据的所有权丢失了。

Domain Bounded Context 是一个非常强大的工具来设计数据集的所有权。 Ben Stopford 的 Data Dichotomy 文章揭示了通过流共享域数据集的概念。

为了分散单体数据平台，我们需要扭转我们对数据的看法，即数据的位置和所有权。域需要以易于使用的方式托管和服务其域数据集，而不是将域中的数据流入中央拥有的数据湖或平台。

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

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

这需要将我们的思维从传统上通过 ETL 以及最近通过事件流的推送和摄取转变为跨所有领域的服务和拉取模型。

面向领域的数据平台中的架构量子是一个领域，而不是管道阶段。

Figure 7: Decomposing the architecture and teams owning the data based on domains - source, consumer, and newly created shared domains

面向源的领域数据

一些域自然地与数据来源一致。源域数据集代表业务的事实和现实。源域数据集捕获的数据与其起源的操作系统、现实系统生成的内容非常接近。在我们的示例中，诸如“用户如何与服务交互”或“入职标签的过程”等业务事实导致创建域数据集，例如“用户点击流”、“音频播放质量流”和“板载标签”。这些事实最为人所知，并由位于起源点的操作系统生成。例如，媒体播放器系统最了解“用户点击流”。

在成熟和理想的情况下，一个操作系统及其团队或组织单元不仅负责提供业务能力，还负责提供其业务领域的真相作为源域数据集。在企业规模上，域概念和源系统之间从来没有一对一的映射。通常有许多系统可以为属于某个域的部分数据提供服务，有些是遗留的，有些是易于更改的。因此，可能有许多源对齐数据集，即现实数据集，最终需要聚合到一个有凝聚力的域对齐数据集。

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

除了定时事件，源数据域还应该提供源域数据集的易于使用的历史快照，这些快照在一个时间间隔内聚合，密切反映其域的变化间隔。例如，在“加入标签”源域中，它显示为流媒体业务提供音乐的艺术家的标签，除了通过流程生成的事件之外，每月汇总加入标签是一个合理的视图。入职标签。

请注意，源对齐的域数据集必须与内部源系统的数据集分开。域数据集的性质与操作系统用于完成其工作的内部数据非常不同。它们的体积要大得多，代表不可变的定时事实，并且比它们的系统更改的频率低。出于这个原因，实际的底层存储必须适合大数据，并与现有的操作数据库分开。数据和自助平台设计融合部分描述了如何创建大数据存储和服务基础设施。

源域数据集是最基本的数据集，并且变化较少，因为业务事实不会经常变化。这些域数据集预计将被永久捕获并提供，以便随着组织发展其数据驱动和智能服务，它们始终可以回到业务事实，并创建新的聚合或预测。

请注意，源域数据集非常接近创建时的原始数据，并且没有为特定消费者拟合或建模。

面向消费者和共享域数据

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

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

分布式管道作为域内部实现

虽然数据集所有权从中央平台委托给域，但仍然需要清理、准备、聚合和提供数据，数据管道的使用也是如此。在此架构中，数据管道只是数据域的内部复杂性和实现，并在域内部进行处理。结果，我们将看到数据管道阶段在每个域中的分布。

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

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

Figure 8: Distribute the pipelines into the domains as a second class concern and the domain's internal implementation detail

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

数据与产品思维的融合

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

领域数据作为产品

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

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

Figure 9: Characteristics of domain datasets as product

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

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

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

可发现的

数据产品必须易于发现。一个常见的实现是为所有可用的数据产品建立一个注册表、一个数据目录，以及它们的元信息，例如它们的所有者、来源、血统、样本数据集等。这种集中的可发现性服务允许数据消费者、工程师和科学家在一个组织，轻松找到他们感兴趣的数据集。每个域数据产品都必须在这个集中的数据目录中注册，以便于发现。

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

可寻址

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

值得信赖和真实

没有人会使用他们无法信任的产品。在传统的数据平台中，提取和载入有错误、不能反映业务真实性且根本不可信的数据是可以接受的。这是集中数据管道的大部分工作集中的地方，在摄取后清理数据。

根本性转变要求数据产品的所有者围绕数据的真实性提供可接受的服务水平目标，以及它在多大程度上反映了已发生事件的真实性或已获得洞察力的真实性的高概率。生成。在创建数据产品时应用数据清理和自动化数据完整性测试是用于提供可接受的质量水平的一些技术。提供数据出处和数据沿袭作为与每个数据产品相关的元数据有助于消费者对数据产品及其对他们特定需求的适用性获得进一步的信心。

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

自描述语义和句法

优质产品无需消费者手持：它们可以被独立发现、理解和消费。将数据集构建为数据工程师和数据科学家使用的摩擦最小的产品，需要对数据的语义和语法进行良好描述，最好以样本数据集作为示例。数据模式是提供自助数据资产的起点。

可互操作并受全球标准监管

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

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

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

受全球访问控制的保护和管理

无论架构是否集中，都必须安全地访问产品数据集。在分散的面向领域的数据产品的世界中，访问控制以更精细的粒度应用于每个领域数据产品。与操作域类似，访问控制策略可以集中定义，但在访问每个单独的数据集产品时应用。使用企业身份管理系统 (SSO) 和基于角色的访问控制策略定义是实施产品数据集访问控制的便捷方式。

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

领域数据跨职能团队

将数据作为产品提供的域；需要增加新的技能：(a) 数据产品所有者和 (b) 数据工程师。

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

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

为了构建和操作域的内部数据管道，团队必须包括数据工程师。这种跨职能团队的一个奇妙的副作用是不同技能的异花授粉。我目前的行业观察是，一些数据工程师虽然擅长使用他们的行业工具，但在构建数据资产时缺乏软件工程标准实践，例如持续交付和自动化测试。同样，构建操作系统的软件工程师通常没有使用数据工程工具集的经验。消除技能集孤岛将导致创建组织可用的更大更深的数据工程技能集。我们已经观察到 DevOps 运动的交叉技能授粉，以及 SRE 等新型工程师的诞生。

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

Figure 10: Cross functional domain data teams with explicit data product ownership

数据与自助平台设计融合

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

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

Figure 11: Extracting and harvesting domain agnostic data pipeline infrastructure and tooling into a separate data infrastructure as a platform

将数据基础架构构建为平台的关键是 (a) 不包含任何特定领域的概念或业务逻辑，使其与领域无关，以及 (b) 确保平台隐藏所有底层复杂性并提供数据基础架构组件一种自助方式。自助式数据基础设施作为平台提供给其用户（域的数据工程师）的功能有很长的列表。这里有几个：

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

自助数据基础架构的成功标准是降低基础架构上的“创建新数据产品的准备时间”。这导致了自动化，这是实现“数据产品”功能所必需的，如“域数据作为产品”部分所述。例如，通过配置和脚本自动获取数据、创建数据产品脚本以放置脚手架、在目录中自动注册数据产品等。

使用云基础设施作为基础降低了提供对数据基础设施的按需访问所需的运营成本和工作量，但它并没有完全消除需要在业务环境中实施的更高抽象层。无论是哪家云提供商，数据基础设施团队都可以使用丰富且不断增长的数据基础设施服务。

向数据网格的范式转变

读了很久。让我们把它放在一起。我们研究了当前数据平台的一些基本特征：集中式、单体式、具有高度耦合的管道架构，由超专业数据工程师的孤岛操作。我们介绍了作为平台的无处不在的数据网格的构建块；面向领域的分布式数据产品，由独立的跨职能团队拥有，这些团队拥有嵌入式数据工程师和数据产品所有者，使用通用数据基础设施作为平台来托管、准备和服务他们的数据资产。

数据网格平台是一种有意设计的分布式数据架构，在集中治理和互操作性标准化下，由共享和协调的自助数据基础设施支持。我希望很清楚，它远离无法访问数据的碎片孤岛。

Figure 12: Data mesh architecture from 30,000 foot view

您可能会问，数据湖或数据仓库在这个架构中的位置是什么？它们只是网格上的节点。我们很可能不需要数据湖，因为保存原始数据的分布式日志和存储可用于从不同的可寻址不可变数据集作为产品进行探索。但是，如果我们确实需要对数据的原始格式进行更改以进行进一步探索，例如标记，具有这种需求的域可能会创建自己的湖或数据中心。

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

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

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

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

我承认，尽管我看到数据网格实践被应用在我的客户的口袋里，但企业规模的采用仍有很长的路要走。我不认为技术是这里的限制，我们今天使用的所有工具都可以适应多个团队的分发和所有权。特别是向批处理和流的统一以及 Apache Beam 或 Google Cloud Dataflow 等工具的转变，可以轻松地处理可寻址的多语言数据集。

谷歌云数据目录等数据目录平台提供分布式域数据集的集中发现、访问控制和治理。多种云数据存储选项使域数据产品能够选择适合用途的多语言存储。

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

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

• 服务超过摄取
• 发现和使用过度提取和加载
• 通过集中式管道将事件发布为流过流动数据的流
• 中心化数据平台上的数据产品生态系统

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

原文：https://martinfowler.com/articles/data-monolith-to-mesh.html

本文：https://jiagoushi.pro/node/2131