我工作过的许多公司，都把成为数据驱动型组织设定为它们的首要战略目标之一。我的客户深知 AI 赋能的益处：可以提供基于数据和超个性化（hyper-personalization）的最佳客户体验；同时通过数据驱动的优化减少运营成本和时间；还可以为员工提供更强大的趋势分析和 BI 能力。他们一直在大力投资数据和智能平台等赋能引擎。遗憾的是，尽管这些企业在构建此类赋能平台方面付出了更多的努力和投入，但结果往往不尽人意。我理解企业在转变成为数据驱动的组织的过程中面临着多方面的难题。因为他们从数十年的遗留系统迁移而来的同时，也会被反对依赖数据的遗留文化影响，同时，竞争激烈的业务优先级排序也阻碍了这种转变。但是，我想分享一种导致数据平台计划失败的架构视角。我将展示如何将过去十年在分布式架构中的学习成果应到数据领域中。我也会介绍一种新的企业数据架构，称为数据网格(即 Data Mesh)。

在阅读之前，我的建议是暂时先放下“基于当前数据平台体系构建范式”的假设和偏见；对从单体式和中心化数据湖转变到数据网格架构的可能性持开放态度；拥抱数据永远存在、无处不在、天然具有分布性特征的现实。

当前的企业数据平台架构

它是中心式，单体式和领域不可知的，又被称为数据湖。几乎每个与我合作的客户都在计划或正在构建他们的第三代数据和智能平台，同时也承认过去几代的失败：

第一代：专有的企业数据仓库和商业智能平台；这些高价的解决方案使公司承担了巨大的技术债务。这数千个无法维护的数据仓库技术作业、表格和报告中的技术债务，却只有一小部分专业人员能够理解，这使得其对业务产生的积极影响被低估。

第二代：以数据湖为”特效药“的大数据生态系统；在复杂的大数据生态系统中，超专业数据工程师团队经过长期运行，已经创建了“数据湖怪兽”，这些庞然大物充其量可以实现大量的“研究与开发”分析，但是存在“承诺有余、实现不足”的情况。

第三代和当前的数据平台或多或少与上一代相似，但在现代方向上转变如下:（a）通过 Kappa 等架构进行流传输以实现实时数据可用性，（b）使用 Apache Beam 等框架统一批处理和流处理以进行数据转换，（c）全面采用基于云的托管服务，用于存储，数据管道执行引擎和机器学习平台。

显然，第三代数据平台正在填补前几代的空白，并在降低管理大数据基础架构的成本，例如实时数据分析。但是，它同样具有许多导致上一代失败的潜在特征。架构故障模式为说明各代数据平台所面临的潜在限制，让我们先看一下它们的体系结构和特征。在本文中，我以互联网媒体流业务领域（例如 Spotify，SoundCloud，Apple iTunes 等）为例来阐明一些概念。中心式和单体式宏观来看，数据平台架构如下图 1 所示。中心式架构，其目标是：

从企业的各个角落提取数据，这些数据的范围包括企业的运营和交易系统以及经营业务的领域，还有扩展企业知识的外部数据提供商。例如，在流媒体业务中，数据平台负责摄取各种数据：“媒体播放器性能”，“用户与播放器的交互方式”，“被演奏的歌曲”，“被关注的艺术家”以及作为企业已加入的“标签和艺术家”，与艺术家的“经济往来”以及外部市场研究数据（例如“客户人口统计”信息）。

平台清理、丰富源数据并将其转换为可满足各种消费者需求的可信赖数据。在我们的示例中，其中一种转换是将用户交互的点击流变成了带有用户详细信息的数据。这试图在聚合中重构用户的行为。

平台将数据集提供给具有各种需求的消费者，达到分析消费，探索数据以寻找洞见的目的，同时也可以实现基于机器学习的决策制定，撰写总结业务绩效的商业智能报告等。在我们的流媒体示例中，该平台可以通过分布式日志界面（例如 Kafka）提供有关全球媒体播放器的实时信息，或提供正在播放的特定艺术家静态汇总视图，以帮助财务理清给艺术家和唱片公司的付款。

图 1：宏观视角下整体数据平台视图

一般来说，整体数据平台会托管逻辑上属于不同领域的数据。例如“播放事件”，“销售 KPI”，“艺术家”，“专辑”，“标签”，“音频”，“播客”，“音乐事件”等；来自大量不同领域的数据。在过去的十年中，尽管我们已成功将领域驱动的设计和有限的上下文应用于我们的操作系统，但我们在很大程度上忽略了数据平台中的领域概念。我们已经从面向领域的数据所有权转移到中心式的不可知数据所有权的域。我们以创建最大的整体（即大数据平台）而自豪。

图 2：领域数据界限和所有权不清的数据平台

尽管此中心式模型可用于领域更简单、消费案例数量较少的企业，但对于领域丰富，来源众多且消费者多样化的企业却不适用。中心式数据平台的体系结构和组织结构上存在两个压力点，这些压力点通常会导致失败：

无处不在的数据和源扩散：随着越来越多的数据变得无处不在，在一个平台的控制下，在一个地方使用所有数据并进行协调的能力将减弱。想象一下，仅在“客户信息”领域，在企业内外都有越来越多的提供有关现有和潜在客户的信息来源。如果假设我们需要在一个地方摄取和存储数据以从各种来源中获取价值，我们对数据来源扩散的响应能力将被限制。我认为需要数据用户（例如数据科学家和分析师）以低成本来处理各种数据集，并且需要将操作系统数据使用的数据与用于分析目的的数据区分开来。但是我认为，如果企业是具有丰富领域和不断添加新资源的大型组织，现有的中心式解决方案不是最佳解决方案。

组织的创新计划和消费者激增：组织对快速试验的需求引入了大量用例来消费平台中的数据。这意味着数据转换（可以满足创新的测试和学习周期的聚合，投影和切片）的数量正在不断增长。满足数据消费者需求的响应时间过长一直是企业面临的一个问题，而在现代数据平台体系结构中仍然如此。

尽管我现在还不想放弃我的解决方案，但我需要澄清的是，我倡导的领域数据不是隐藏在操作系统中的，分散的，孤立的，也不是难以发现，理解和使用的。我不支持技术债务中形成的分散数据仓库。这是行业领导者的关注点。但是我认为，解决这些问题的方法并不是建立一个中心式的数据平台，而是由一个中心团队组成来管理。正如我们在上面论证的那样，它没有组织化的规模。耦合流水线分解传统数据平台体系结构的第二种故障模式与我们如何分解体系结构有关。放大中心式数据平台后，我们发现一个围绕摄取，清理，聚合，服务等机械功能的架构分解。企业中的架构师和技术领导者会根据平台的增长来分解架构。如上一节所述，引入新资源或应对新消费者的需求要求平台不断发展。架构师需要找到一种方法，通过将其分解为体系结构量子来扩展系统。如《设计可进化架构》中所述，架构量子是具有高功能凝聚力的、可独立部署的组件，其中包括系统正常运行所需的所有结构要素。将系统分解成架构量子是为了创建独立的团队，团队里每个人都可以构建和操作架构量子。这些团队之间的并行工作可提高的运营可扩展性和速度。鉴于前几代数据平台体系结构的影响，架构师将数据平台分解为一系列数据处理阶段。这邪恶管道在高水平处理数据并实现摄取，准备，汇总，服务等功能的凝聚。

图 3：数据平台的体系结构分解

尽管此模型通过将团队分配到流水线的不同阶段扩大了规模，但它具有一个固有的局限性，那就是使功能交付速度变慢。它在流水线的各个阶段之间具有很高的耦合度，以提供独立的功能或价值。它与变化轴正交分解。让我们看一下我们的流媒体示例。网络流媒体平台有一个强大的媒体类型领域构造。他们通常从“歌曲”和“专辑”等服务开始，然后扩展到“音乐事件”，“播客”，“广播节目”，“电影”等。启用单个新功能，例如“播客播放率”的可见性，则需要更改管道中的所有组件。团队必须引入新的摄取服务，新的清理和准备工作以及用于查看播客播放率的合集。这需要在组件之间进行同步，并在团队之间进行发布管理。许多数据平台提供的提取服务可以应资源添加扩展问题，以最大程度地减少开销。但是，这并没有从消费者角度解决端到端依赖性问题。我们看似已经达到了流水线阶段的架构，但实际上整个流水线（即单体式平台）是必须改成适应新功能的最小单元：解锁新数据集并将其用于新的或现有的消费。这限制了我们响应新的使用者或数据源以实现更高速度和更大规模的能力。

图 4：引入或增强功能时，架构分解与更改轴正交，从而导致耦合和交付速度降低

当今数据平台的第三种失败模式与我们如何组织构建平台的团队有关。当我们实地观察数据平台的人员的生活时，我们发现他们是一群与组织运营部门隔离的超专业数据工程师；对于数据源自何处或在何处使用并付诸行动和决策制定并不知情。数据平台工程师不仅在组织上处于孤立状态，而且根据他们在大数据工具方面的技术专长（通常缺乏业务和领域知识）分类使得他们通常缺乏业务和领域知识。

图 5：孤立的超专业数据平台团队

我并不羡慕数据平台工程师的生活。他们需要消费来自团队的数据，这个团队通常不能提供有意义的、真实的和正确的数据。他们对生成数据的源域了解甚少，并且团队中缺乏领域专业知识。他们需要针对各种操作或分析的需求提供数据，但却不了解数据的应用，也无需与使用领域专家联系。

在媒体流领域，比如在源端，我们有跨职能的“媒体播放器”团队，可提供有关用户如何与他们提供的特定功能进行交互的信号，例如“播放歌曲事件”，“购买事件”，“播放音频质量”等；另一端是消费者跨职能团队，例如“歌曲推荐”团队，报告销售 KPI 的“销售团队”，根据演出计算和付款给艺人的“艺人支付团队”等。不幸的是，位于中间的数据平台团队则拼命为所有来源和消费提供合适的数据。实际上，我们还发现有的源团队彼此没有联系，有的互相争夺，导致过度拉伸。我们创建的架构和组织结构无法扩展，并且无法实现创建数据驱动型组织所承诺的价值。

下一代企业数据平台架构

它通过分布式数据网格包含了无处不在的数据。那么，我们上面讨论的故障模式和特征的答案是什么？我认为有必要进行范式转换，以期在大规模构建现代分布式体系结构中发挥作用。整个技术行业都采用了这些技术，并取得了成功。我建议下一代企业数据平台架构是分布式领域驱动架构、自助式平台设计以及产品思维与数据的融合。

图 6：融合：构建下一个数据平台的模式转变

尽管这听起来像是一句空话，但是这些技术确实在现代化操作系统的技术基础方面产生了具体的、令人难以置信的积极影响。让我们来深入研究一下如何将这些方法应用于数据世界，以摆脱当前的旧范式。数据和分布式领域驱动的架构融合面向领域的数据分解和所有权埃里克·埃文斯（Eric Evans）的著作《领域驱动设计》（Domain-Driven Design）对现代架构思想以及组织建模产生了深远的影响。它通过将系统分解为围绕业务领域功能构建的分布式服务来影响微服务体系结构。它从根本上改变了团队的组成方式，从而使团队可以独立自主地拥有领域能力。尽管在实现运营功能时我们采用了定向领域分解和所有权，但奇怪的是，在涉及数据时，我们却忽略了业务领域的概念。

DDD 在数据平台体系结构中最接近的应用是用于源操作系统发出其业务领域事件，并用于整体数据平台来接收它们。但是，超出摄取点的范围，就失去了领域的概念以及不同团队对领域数据的所有权。领域绑定上下文是一种功能强大的工具，可用于设计数据集的所有权。Ben Stopford 的 Data Dichotomy 文章介绍了通过流共享领域数据集的概念。为了使单体式数据平台分散化，我们需要颠覆我们对数据本地性和所有权的看法。与其将数据从领域中流到中央拥有的数据湖或平台中，不如说领域需要以易于使用的方式托管和服务于其领域数据集。在我们的示例中，与其想象来自媒体播放器的数据流到某个集中位置以供一个集中的团队接收，不如想象我们有一个拥有并服务其数据集的播放器领域以满足团队下游使用的任何目的。数据集实际驻留的物理位置及其流动方式是“播放器领域”的技术实现。物理存储肯定可以是诸如 Amazon S3 存储桶之类的中心式架构，但播放器数据集的内容和所有权仍保留在生成它们的领中。类似地，在我们的示例中，“推荐”领域以适合其应用的格式创建数据集，例如图形数据库，同时消化了播放器数据集。

如果还有其他领域（例如“新艺术家发现领域”）对“推荐领域”图数据集有用，则可以选择提取和访问该领域。这意味着当我们将数据转换为适合该特定领域的形状时，我们可能会在不同领域中复制数据。例如，与艺术家相关的时间序列播放事件的图表。这就要求我们将思维方式从传统上通过 ETL、当前通过事件流的推入和获取模型转移到跨所有域的服务和提取模型。面向领域的数据平台中的体系结构范围是一个领域，而不是流水线阶段。

图 7：根据域（源域，使用者域和新创建的共享域）分解拥有数据的架构和团队

面向源的领域数据

一些领域自然地与数据起源的源一致。源域数据集代表业务的现实情况。源域数据集捕获与其操作系统的来源和现实关联非常紧密的数据。在我们的示例中，诸如“用户如何与服务进行交互”或“入职标签流程”之类的业务事实导致领域数据集的创建，例如“用户点击流”，“音频播放质量流”和“内置标签”。这些事实是众所周知的，并且是由起源处的操作系统生成的。例如，媒体播放器系统最了解“用户点击流”。在理想的情况下，操作系统及其团队或组织单位不仅负责提供业务功能，而且还负责提供其业务领域的真实情况作为源域数据集。在企业规模上，领域概念和源系统之间从来没有一对一的映射。通常，有许多系统可以服务属于某个领域的部分数据，其中一些是旧式的，而某些则易于更改。因此，可能会有许多源对齐的数据集（也称为现实数据集），最终需要将它们汇总到一个内聚的领域对齐的数据集中。

商业事实最好以商业领域事件的形式呈现，可以将其存储并作为带有时间标记的事件的分布式日志，以供任何授权消费者访问。除了定时事件外，源数据域还应提供易于使用的源域数据集的历史快照，这些密切反映其领域的更改间隔的记录在一定时间范围内汇总。例如，在向流媒体业务提供音乐的艺术家的“内嵌标签”源域中，每月汇总通过入职标签生成的事件的内嵌标签是一种合理的视图。请注意，源对齐领域数据集必须与内部源系统的数据集分开。领域数据集的性质与操作系统用来完成其工作的内部数据有很大不同。与它们的系统相比，它们具有更大的体积，代表着不变的定时事实，并且变化的频率更低。

因此，实际的基础存储必须适合大数据，并且必须与现有的操作数据库分开。数据和自助平台设计融合部分将介绍如何创建大数据存储和服务基础架构。源域数据集是最基础的数据集，由于业务事实并不经常更改，所以更改频率较低。预计这些领域数据集将被永久储存使用，以便随着企业发展其数据驱动和情报服务，他们始终可以返回到业务事实，并创建新的汇总或预测。请注意，源域数据集在创建时几乎代表原始数据，并且未针对特定使用者进行拟合或建模。

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

一些领域与消费密切相关。消费者领域数据集和拥有它们的团队的目的是满足一组密切相关的用例。例如，“社交推荐领域”侧重于根据用户彼此之间的社交联系提供推荐，创建适合此特定需求的领域数据集；也可以通过“用户社交网络的图形”表示。此数据集对于推荐用例很有用，也许对于“听众通知”领域也有用，该领域提供给不同听众发送通知的数据，比如其社交网络中的人正在听的内容。因此，“用户社交网络”有可能成为共享的和新定义的领域数据集，供多个消费者使用。“用户社交网络”领域团队专注于提供“用户社交网络”的最新视图。

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

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

尽管将数据集所有权从中央平台委托给领域，但是仍然需要清理，准备，聚合和提供数据，数据管道的使用也是如此。在这种体系结构中，数据管道只是内部复杂性和数据域的实现，并在域内部进行处理。结果，我们将看到数据管道阶段分布到每个领域中。例如，源域需要包括对其领域事件的清除，重复数据删除，扩展它们的领域以便其他领域可以使用它们，而无需复制清除。每个领域数据集都必须为其提供的数据质量、及时性，错误率等建立服务水平目标：。例如，我们提供音频“播放点击流”的媒体播放器领域可以包括清理和标准化其领域中的数据管道，这样就可以提供“播放音频点击事件”的实时数据流。同样，我们将看到从中心式管道的聚合阶段进入了消费领域的细节的实现。

图 8：将管道分配到领域中

作为第二类关注点，以及领域的内部实现细节有人可能会争辩说，该模型可能会导致每个领域在创建自己的数据处理管道实现，技术堆栈和工具方面做出重复的努力。我将在谈论数据和以自助共享数据基础架构为平台的思维融合时，很快解决这个问题。数据和产品思维融合将数据所有权和数据管道实施分配到业务领域中这件事引起了人们对分布式数据集的关注可行性，可用性和协调性。在这里，学习应用产品思维和数据资产所有权非常方便。

领域数据作为产品在过去的十年中，运营领域已经将产品思想融入了他们为组织其他部门提供的能力中。领域团队将这些能力作为 API（应用程序接口）提供给组织中其他开发人员以作为创建更高价值和功能的基础。这些团队致力于为他们的领域 API（应用程序接口）创建最佳的开发人员体验；包括可发现且易于理解的 API 文档，API 测试箱，同时密切跟踪质量和应用的关键绩效指标。为了使分布式数据平台获得成功，领域数据团队必须以相似的严格度将产品思维应用于他们提供的数据集。将其数据资产视为产品，并将组织里的其余数据科学家，机器学习和数据工程师视为客户。

图 9：领域数据集

作为产品的特征回顾我们的示例，互联网媒体流业务。它的关键领域之一是“播放事件”，即谁，何时，何地播放了哪些歌曲。这个关键的领域在组织中拥有不同的使用者；例如，近实时消费者会对用户体验以及可能的错误感兴趣，因此在客户体验下降或客户支持电话打入的情况下可以快速响应以恢复错误。还有一些消费者更喜欢每日或每月歌曲播放事件聚合的历史记录。在这种情况下，我们的“播放的歌曲”领域为组织的其他部分提供了两个不同的数据集作为产品。在事件流上公开的实时播放事件，以及在对象存储中作为序列化文件公开的聚合播放事件。任何技术产品（这里说的是领域数据产品）的一项重要素质就是使它们的消费者满意。（这里指的是数据工程师，机器学习工程师或数据科学家。）为了向消费者提供最佳的用户体验，领域数据产品需要具有以下基本素质：

可发现的

数据产品必须易于发现。常见的实现方式是对所有可用的数据产品及其元信息（例如其所有者，来源，样本数据集等）编写目录。此中心式可发现性服务使组织里的数据消费者，工程师和科学家能够轻松找到他们需要的数据集。每个领域数据产品都必须在此中心式数据目录中注册以方便查询。请注意，这里的观点转变是从单一平台提取数据，到以可发现的方式将其数据作为产品提供到每个领域。

可寻址的

数据产品一经发现，便应该遵循国际惯例，有一个唯一地址，以帮助其用户以编程方式访问它。根据数据的基础存储和格式，组织可以为数据采用不同的命名约定。考虑到易用性，在分散式体系结构中，有必要制定通用的约定。不同的领域存储和提供数据集的格式不同，事件可能通过诸如 Kafka 主题之类的流进行存储和访问，而柱状数据集可能使用 CSV 文件或序列化 Parquet 文件的 AWSS3 存储桶。多种语言环境中的数据集可寻址性标准消除了查找和访问信息时的摩擦。

可信赖且真实的

没有人会使用他们不信任的产品。在传统的数据平台中，存在数据有误、不能反映业务真相或者根本无法信任的情况。在这里，中心式数据管道的大部分工作都集中在此，在提取数据后清理数据。如果要达到根本性的转变，数据产品的所有者要围绕数据的真实性提供可接受的服务，以及提供它与事件发生的真实性的接近程度。在创建数据产品时应该应用数据清理和自动数据完整性测试。提供数据源和数据沿袭作为与每个数据产品相关联的元数据有助于增加消费者对产品及其适用性方面的信任。数据完整性（质量）指标的目标值或范围在领域数据产品之间有所不同。例如，“播放事件”领域可以提供两种不同的数据产品，一种接近实时，准确性较低，包括丢失或重复的事件，而另一种则具有较长的延迟和较高的事件准确性。每个数据产品定义并保证其作为一组 SLO 的完整性和真实性。

自描述的语义和语法

优质的产品不需要消费者手持即可使用：它们可以被查询，理解和消费。将数据集构建为具有最小单元的产品，以供数据工程师和数据科学家使用，这需要对语义和语法对数据进行充分描述，理想情况下将样本数据集作为示例。数据模式是提供自助数据资产的起点。

可互操作并受全球标准约束

分布式领域数据体系结构中的主要问题之一是关联跨领域数据并将其有机缝合、连接，过滤，聚合的能力。跨领域有效关联数据的关键是遵循某些标准和统一规则。这样的标准化应该用于全球治理，以实现多语言领域数据集之间的互操作性。这种标准化工作的共同关注点是字段类型格式化，跨不同领域识别多义词，数据集地址约定，通用元数据字段，事件格式（例如 CloudEvents）等。例如，在媒体流业务中，“艺术家”可能出现在不同的领域中，并且在每个领域中具有不同的属性和标识符。“播放事件流”域对艺术家的识别可能与负责开发票和付款的“艺术家支付”领域的识别不同。但是，为了能够在不同领域的数据产品之间关联艺术家的数据，我们需要就如何将艺术家识别为多义词达成共识。一种方法是考虑具有联合实体的“艺术家”和“艺术家”的唯一全局联合实体标识符，这与管理联合身份的方式类似。受全球管辖的通信的互操作性和标准化是构建分布式系统的基础支柱之一。

安全并受全局访问控制

无论架构是否中心化，都必须安全地访问产品数据集。在分散的面向领域的数据产品的世界中，对每个领域数据产品都被以更小的单元应用访问控制。与操作领域类似，访问控制策略可以被集中定义，但是也可以应用到每个单独的数据集产品上。使用企业身份管理系统（SSO）和基于角色的访问控制策略定义是实现产品数据集访问控制的便捷方法。数据和自助服务平台设计的融合部分描述了这一共享的基础结构，该基础结构可轻松、自动地为每个数据产品启用上述功能。

领域数据跨职能团队

将数据作为产品提供的领域；需要增加新的技能：（a）数据产品所有者和（b）数据工程师。数据产品所有者根据数据产品的愿景和路线图做出决策，更多关注消费者的满意度，并不断衡量和提高其领域拥有和生产的数据的质量和丰富性。她负责领域数据集的生命周期，以及何时更改，修订和淘汰数据和架构。她在领域数据使用者的竞争需求之间取得了平衡。数据产品所有者必须定义成功标准和与业务相关的关键绩效指标（KPI）。例如，数据产品的消费者成功发现和使用数据产品的交付时间是可衡量的成功标准。为了构建和运行领域的内部数据管道，团队必须拥有数据工程师。这种跨职能团队的一个奇妙的副作用是跨团队技能互补。我目前的行业观察是，一些数据工程师虽然能够使用其交易工具，但在构建数据资产时缺乏软件工程标准实践，例如在连续交付和自动化测试方面。同样，构建操作系统的软件工程师通常也没有使用数据工程工具集的经验。消除技能孤岛有助于创建更大的数据工程技能库。

我们已经观察到与 DevOps 运动相同的跨团队技能互补，以及诸如 SRE 之类的新型工程师的诞生。必须将数据视为任何软件生态系统的基础，因此软件工程师和软件通才必须将数据产品开发的经验和知识添加到他们的工具带中。同样，基础架构工程师需要增加管理数据基础架构的知识和经验。企业必须提供从通才到数据工程师的职业发展途径。由于缺少数据工程的技术从而导致了之前「孤立和超专业的所有权」那节中的中心化的数据工程团的过度局部优化的问题。

图 10：具有明确数据产品所有权的跨功能领域数据团队

数据和自助平台设计融合将数据所有权分配给领域的主要问题之一是可能存在重复工作。幸运的是，将通用基础架构构建为平台已经是众所周知的问题，并且已经得到解决。将领域不可知的基础架构功能收集和提取到数据基础架构平台中，解决了重复设置数据管道引擎，存储和流基础架构的工作的问题。数据基础架构团队可以拥有并提供域发现，处理，存储和服务其数据产品所需的必要技术。

图 11：提取和收集与领域无关的数据管道基础架构，并将工具构建到作为平台的独立数据基础架构中

将数据基础架构构建为平台的关键是（a）不包含任何特定于领域的概念或业务逻辑，使其保持领域不可知性；以及（b）确保平台隐藏了所有潜在的复杂性和提供了数据基础架构组件自助服务的方式。自助数据基础架构作为平台向用户（领域的数据工程师）提供的功能种类繁多。这里有几个：

可扩展的多语言大数据存储

加密静态和动态数据

数据产品版本控制

数据产品架构

数据产品去识别

统一的数据访问控制和记录

数据管道的实现和编排

数据产品发现，目录注册和发布

数据治理与标准化

数据产品沿袭

数据产品监控/报警/日志

数据产品质量指标（收集和共享）

内存中数据缓存

联合身份管理

计算和数据局部性

自助数据基础架构的成功标准是减少“创建新数据产品的时间”。这将引导“数据产品”功能所需的自动化，这在“将领域数据作为产品”部分中进行了介绍。例如，通过配置和脚本自动执行数据提取，将脚手架放置在适当位置的数据产品创建脚本，在目录中自动注册数据产品等。使用云基础架构作为基础可以减少运营成本和工作量，但是，它并没有完全消除需要在业务环境中放置的更高的抽象。无论云提供商如何，数据基础架构团队都可以使用一组丰富且不断增长的数据基础结构服务。

向数据网格转移的范式

读了这么久了，让我们总结一下。我们研究了当前数据平台的一些基本特征：中心式，单体式，高度耦合的管道架构，由超专业数据工程师的独立操作。我们介绍了作为平台的无处不在的数据网格的构建模块；面向领域的分布式数据产品，由独立的跨职能团队拥有，这些团队具有嵌入式数据工程师和数据产品所有者，使用通用数据基础结构作为承载，准备和服务其数据资产的平台。数据网格平台是经过精心设计的分布式数据体系结构，在集中管理和标准化下实现了互操作性，并通过共享和统一的自助式数据基础结构实现了此功能。我希望，它与无法访问的数据零散孤岛的景象不同。

图 12：俯视数据网格架构

那么，数据湖或数据仓库在此体系结构中适合什么位置？它们只是网格上的节点。我们很有可能不需要数据湖，因为保存原始数据的分布式日志和存储是可用与从作为产品的不同的、可寻址的、不可变的数据集中作为产品中进行探索。但是，如果我们确实需要更改数据的原始格式以进行进一步的探索（例如标记），则有此需求的领域可能会创建自己的湖泊或数据中心。因此，数据湖不再是整个体系结构的核心。我们将继续应用一些数据湖的原理，例如使不变的数据可用于勘探和分析用途。我们将继续使用数据湖工具，但是将其用于数据产品的内部实施或作为共享数据基础结构的一部分。实际上，这使我们回到了一切的起点：2010 年，James Dixon 打算将一个数据湖用于单个领域，而多个数据域将形成一个“水上花园”。

主要转变是将领域数据产品视为第一类关注点，而将数据湖工具和管道视为第二类关注点-即实现细节。这将当前的思维模型从中心化式数据湖转变为可以很好地协同工作的数据产品生态系统，即数据网格相同的原则适用于用于业务报告和可视化的数据仓库。它只是网格上的一个节点，并且可能位于网格的面向消费者的边缘上。我承认，尽管我看到数据网格实践已在我的客户中应用，但企业规模的采用仍然有很长的路要走。我不认为技术是这里的局限性，我们今天使用的所有工具都可以容纳多个团队的分配和所有权。尤其是向批处理和流传输以及诸如 Apache Beam 或 Google Cloud Dataflow 之类的工具统一的转变，可以处理多种类型的数据集。

诸如 Google Cloud Data Catalog 之类的数据目录平台提供了中心化的可发现性，访问控制和分布式领域数据集的治理。多种云数据存储选项使领域数据产品可以选择适合用途的多语言存储。需求是真实的，工具已经准备就绪。这需要组织的工程师和领导者来认识到，仅使用新的基于云的工具，现有的大数据范例和一个真正的大数据平台或数据湖就只会重复过去的失败。这种范式转换需要一套新的管理原则以及一种新的语言：

服务而不是提取

发现和使用而不是提取和载入

发布事件流而不是利用中心化的管道来管理数据

数据产品生态而不是中心化数据平台

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