翻译ThoughtWorks一篇关于数据平台的文章《How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh》，作者Zhamak Dehghani是ThoughtWorks的首席技术顾问。
许多企业正在投资下一代数据湖，希望大规模地实现数据民主化，以提供商业洞察力，并最终做出自动化的智能决策。基于数据湖架构的数据平台存在着常见的失败模式，这些失败模式会导致无法规模化实现预期。为了解决这些失败模式，我们需要从数据湖以及其前身数据仓库这样的集中化范式转移。我们需要转换到从现代分布式架构中提取的范式:将领域视为第一关注点，应用平台思维来创建自助式数据基础设施，并将数据视为产品。
内容目录
- 当前的企业数据平台架构
- 架构失败模式
- 集中式和单体式
- 耦合流水线分解
- 孤立和高度专业化的所有权
- 架构失败模式
- 下一个企业数据平台架构
- 数据和分布式领域驱动的架构融合
- 面向领域的数据分解和所有权
- 面向源的域数据
- 面向消费者的共享域数据
- 分布式流水线作为域内部实现
- 数据和产品思维融合
- 领域数据作为产品
- 可发现的
- 可寻址的
- 可信赖的、真实的
- 自描述语义和语法
- 可互操作并受全局标准约束
- 安全并受全局访问控制
- 领域数据跨职能团队
- 领域数据作为产品
- 数据和自助平台设计融合
- 数据和分布式领域驱动的架构融合
- 向数据网格的范式转换
成为一个数据驱动型组织一直是我工作过的许多公司的首要战略目标之一。我的客户深知获得智慧赋能的好处：基于数据和超个性化提供最佳的客户体验;通过数据驱动优化降低运营成本和时间;给员工提供趋势分析和商业智能的超能力。他们一直在大力投资建设数据和智能平台等促成因素。尽管 在构建此类支持平台方面付出了更多的努力和投入，但最后发现结果并不理想。
我同意组织在转变为数据驱动的过程中面临多方面的复杂性;从几十年的遗留系统中迁移，对遗留文化依赖数据的抵制，以及不断竞争的业务优先级。然而，我想与您分享的是支撑许多数据平台计划失败的架构视角。我将展示我们如何适应和应用过去十年的经验教训，在数据领域大规模地构建分布式架构;我将介绍一种新的企业数据架构，我称之为数据网格（Data Mesh）。
在继续阅读之前，我希望暂时搁置传统数据平台架构的范式已经建立的深层次假设和偏见;对超越单一和集中的数据湖到有意分布式化数据网格架构的可能性持开放态度;拥抱数据永远存在、无处不在和分布式的现实。
当前的企业数据平台架构
它是集中的、单体的、领域不可知的，又称数据湖。
几乎所有与我合作过的客户都在计划或建设他们的第三代数据和智能平台，同时也承认了过去几代人的失败：
- 第一代：专有的企业数据仓库和商业智能平台;价格高昂的解决方案给公司留下了同样大量的技术债务;数以千计的不可主的ETL作业、表和报告中的技术债务，只有少数专业人员了解这些工作、表和报告，导致对业务的积极影响没有得到充分认识。
- 第二代：以数据湖为银弹的大数据生态系统;复杂的大数据生态系统和由高度专业化数据工程师组成的集中团队操作的长时间运行的批处理任务，创造出了数据湖怪物，最多只能使大量的研发分析成为可能;承诺过多，实现不足。
第三代和当前一代数据平台都或多或少类似于上一代,虽然有些现代的转变：(a)实时数据流可用性架构如 Kappa,(b)统一的批处理和流处理数据转换框架 如Apache Beam,(c)完全采用 基于云的存储管理服务,数据流水线执行引擎和机器学习平台。很明显，第三代数据平台正在解决一些前几代的一些空白，如实时数据分析，以及降低管理大数据基础设施的成本。然而，它仍然具有许多导致上一代失败的潜在特征。
架构失败模式
为了解决各代数据平台带来的潜在限制，让我们看看它们的架构和特征。在这篇文章中，我使用了互联网媒体流媒体业务领域，如Spotify、SoundCloud、 Apple iTunes等作为例子来阐明一些概念。
集中式和整体式
在30,000英尺高度，数据平台架构如下图1所示。集中式架构，其目标是：
- 从企业的各个角落提取数据，从运营、交易系统到经营业务的领域，或者扩展企业知识的外部数据提供商。例如，在流媒体业务中，数据平台负责提取各种数据：“媒体播放器性能”，“用户与播放器的交互方式”，“他们演奏的歌曲”，“他们关注的艺术家”以及以及“标签和艺术家”，与艺术家的“金融交易”以及外部市场研究数据（例如“客户统计”信息）。
- 清理，丰富源数据并将其转换为可满足各种使用者需求的可信赖数据。在我们的示例中，其中一种转换将用户交互的点击流变成了包含丰富用户细节的有意义的会话。这试图将用户的旅程和行为重构为聚合视图。
- 为具有不同需求的各种消费者提供数据集。这包括从分析类消费到数据挖掘以寻找洞察力，从基于机器学习的决策制定，到业绩总结的商业智能报告。在流媒体的案例中,该平台可以通过分布式日志如kafka提供有关全球媒体播放器准实时的错误和质量信息，或提供正在播放的特定艺术家唱片的静态汇总视图，以推动金融支付计算给艺术家和唱片公司。
一个公认的惯例是，整体数据平台托管并拥有逻辑上属于不同领域的数据，例如“播放事件”，“销售KPI”，“艺术家”，“专辑”，“标签”，“音频”，“播客” '，'音乐事件'等；来自大量不同领域域的数据。
在过去的十年中，我们已经成功地将领域驱动的设计和受限制的上下文应用于我们的业务交易系统(Operational system)，而我们在很大程度上忽略了数据平台中的领域概念。我们已经从面向领域的数据所有权转移到集中式的领域不可知数据所有权。我们以创建最大的单体（大数据平台）而感到自豪。
Operational system 指的就是联机交易的业务系统
这种集中式模型可以用于领域简单、消费案例种类较少的组织，但并不适用于领域丰富、来源众多和消费者多样化的企业。
集中式数据平台的架构和组织结构上存在两个压力点，经常导致其失败：
无处不在的数据和源扩散：随着越来越多的数据变得无处不在，在一个平台的控制下，在一处使用所有数据并进行协调的能力将减弱。想象一下，仅在“客户信息”领域，在组织边界内外都有越来越多的来源提供有关现有和潜在客户的信息。我们需要在一个地方提取和存储数据进而从各种来源中获取价值，这种假设将限制我们应对数据来源激增的能力。我认识到，数据科学家和分析师等数据用户需要以低开销处理各种数据集，以及将业务交易类数据使用情况与出于分析目的而消费的数据分开的需求。但是我建议，现有的集中式解决方案不是具有丰富域和不断添加新数据源的大型企业的最佳选择。
组织的创新规划和消费者激增：组织对快速试错的需求引入了大量从平台消费数据的案例。这意味着为了满足 测试和创新学习周期，聚合、投影和切片的转换数量将不断增加。长期以来，满足数据消费者需求的响应时间太长一直是组织摩擦的一个问题，而在现代数据平台架构中仍然如此。
尽管我现在还不想给出我的解决方案，但我需要澄清的是，我并不是在提倡经常隐藏在业务系统内部的、分散的、孤立的、面向领域的数据；难以发现、理解和使用的孤立领域数据。我不是在提倡建立多个分散的数据仓库，这是多年积累的技术债务的结果。这是行业领导者表达的关注点。但是我认为，对这些意外的无法访问的数据孤岛的回应并不是建立一个集中式的数据平台，然后由一个集中化的团队来拥有和管理来自所有领域的数据。正如我们在上面已学到和证明的那样，它在组织上并不具备伸缩能力。
耦合的数据流水线分解
传统数据平台架构的第二种失败模式与我们如何分解架构有关。在10,000英尺处放大集中式数据平台后，我们发现架构分解是围绕提取，清理，聚合，服务等机械化功能的。组织的架构师和技术领导者会根据平台的增长来分解架构。如如上一节所述，添加新的数据源或响应新的消费者要求平台不断发展。架构师需要找到一种方法，通过将其分解来进行扩展架构量子（architectural quanta）。如《构建可进化的架构》中所述，架构量子是具有高功能内聚的可独立部署的组件，其中包括系统正常运行所需的所有结构要素。将系统分解为架构量子的动机是创建独立的团队，每个人都可以构建和操作架构量子。这些团队之间的并行工作可达到更高的操作扩展性和速度。
考虑到前几代数据平台架构的影响，架构师将数据平台分解为一系列数据处理阶段。一个数据流水线在非常高抽象层定义了一个功能聚合，它围绕数据处理的技即提取， 准备，汇总，服务等功能。
尽管此模型提供了一定程度的扩展能力，但通过将团队分配到流水线的不同阶段，它具有一个固有的局限性：使功能交付速度变慢。它在流水线的各个阶段之间具有很高的耦合度，以提供独立的功能或价值。这种分解与变化轴是正交的。
让我们看一下我们的媒体流示例。互联网流媒体平台围绕它们提供的媒体类型具有强大的领域结构。他们通常以“歌曲”和“专辑”开始服务，然后扩展到“音乐事件”，“播客”，“广播节目”，“电影”等。启用单个新功能，例如“播客播放率”，要求更改流水线的所有组件。团队必须引入新的提取服务，新的清理和准备工作以及用于查看播客播放率的汇总。这要求在不同组件之间进行同步，以及跨团队的发布管理。许多数据平台提供了通用的和基于配置的提取服务，这些服务可以应对扩展，例如轻松添加新资源或修改现有资源，以最大程度地减少引入新资源的开销。但是从消费者角度，这并没有消除引入新数据集的端到端依赖性管理。尽管从表面上看，流水线架构看起来好像我们已经达到了流水线阶段的架构量子（architectural quantum），但实际上整个流水线（即单体式平台）是适应新功能的必须更改的最小单元：解锁新数据集并将其用于新的或者现有的消费。这限制了我们在响应新的用户或数据源时获得更快速度和规模的能力。
孤立和高度专业化的所有权
当今数据平台的第三种失败模式与我们如何组织构建和拥有该平台的团队有关。当我们足够近地观察构建和操作数据平台的人员的生活时，我们发现的是一群与组织运营部门隔离的高度专业的数据工程师；他们并不清楚数据源来自何处或在何处使用并付诸行动和决策。数据平台工程师不仅在组织上处于孤立状态，而且根据他们在大数据工具方面的技术专长将他们分开并就划分为一个团队,他们通常缺乏业务和领域知识。
我个人并不羡慕数据平台工程师的生活。他们需要消费来自数据源团队的数据，而这些团队没有动力提供有意义、真实和正确的数据。平台工程师对生成数据的源域了解甚少，并且缺乏专业的领域知识。他们需要针对各种需求（操作性或分析性）提供数据，但不清楚数据的应用和使用方专家的具体访问情况。
例如，在流媒体领域中，在数据源端，我们有跨职能的“媒体播放器”团队，提供有关用户如何与他们提供的特定功能进行交互的信号，例如“播放歌曲事件”，“购买事件”，“音频播放质量”等；另一端是消费者跨职能团队，例如“歌曲推荐”团队，“销售团队”报告销售KPI，“艺术家支付团队”，后者根据播放事件计算和已支付的艺术家，等等。可悲的是，位于中间的数据平台团队通过全力为所有来源和消费者提供合适的数据。
实际上，我们发现源团队之间没有联系，沮丧的消费者争夺数据平台团队积压的工作优先级以及超负荷的数据平台团队。
我们创建了一个架构和组织结构，但它无法扩展，也无法实现创建数据驱动型组织所承诺的价值。
下一个企业数据平台架构
它通过分布式数据网格（Data Mesh）包含了无处不在的数据。
那么，我们上面讨论的失败模式和特征的答案是什么？我认为有必要进行范式转换。这个转变是在技术交叉上的范式转变，这些技术在大规模地构建现代分布式体系结构中起着重要作用；整个技术行业都普遍加速采用的技术，并取得了成功的成果。
我建议，今后企业数据平台架构是分布式领域驱动的架构、自助服务平台设计以及数据产品思维的融合。
尽管这听起来像是一句话中的许多流行语，但是这些技术中的每一种在现代化业务系统的技术基础方面都产生了特定而令人难以置信的积极影响。让我们深入研究如何将这些学科中的每一个应用于数据世界，以摆脱多年旧数据仓库架构所采用的范式。
数据和分布式领域驱动架构融合
面向领域的数据分解和所有权
埃里克·埃文斯（Eric Evans）的著作《领域驱动设计》深刻地影响了现代架构思想，从而影响了组织建模。通过将系统分解为围绕业务域功能构建的分布式服务，它给微服务架构带来很大影响。它从根本上改变了团队的组成方式，从而使团队可以独立自主地拥有领域能力。
尽管在实现业务功能时我们采用了面向领域的分解和所有权，但奇怪的是，在涉及数据时，我们却忽略了业务领域的概念。DDD在数据平台架构中最接近的应用是，数据源业务系统发出对应业务领域事件，然后单体数据平台来接收它们。但是，超出提取点范围，却丢失了领域概念以及不同团队对领域域数据的所有权。
领域边界上下文是设计数据集所有权的强大工具。Ben Stopford的Data Dichotomy 文章介绍了通过流共享领域数据集的概念。
为了实现单体数据平台去中心化，我们需要改变我们对数据的看法，即本地性和所有权。与数据从领域流向集中拥有的数据湖或平台不同，领域需要以一种易于使用的方式托管和服务它们的领域数据集。。
在我们的例子中，与其想象数据从媒体播放器流到某个集中的地方供集中的团队接收，不如想象一个播放器领域拥有并将其数据集服务于下游的任何团队以任何目的访问。数据集实际驻留的物理位置以及它们是如何流动的，是“玩家域”的技术实现部分。物理存储当然可以是一个集中式的基础设施，比如Amazon S3 bucket，但是播放器数据集的内容和所有权仍然由生成它们的领域来决定。类似的，在我们的例子中，“推荐”领域可以选择适合它的应用程序的数据集的创建格式，如图数据库，同时消费播放器数据集。如果有其它领域，如“新艺术家发现领域”，发现“推荐领域”图数据有用，他们可以选择拉取和访问它。
这意味着当我们将数据转换成适合该特定域的形态时，我们可能会在不同域中复制数据，例如，时间序列播放事件到相关艺术家关系图。
这就需要将我们的思维方式从推入式（通常是通过ETL，近些年通过事件流）转移到跨所有领域的服务和提取模型。
面向领域的数据平台中的架构量子是一个领域，而不是流水线阶段。
面向数据源的领域数据
一些领域自然地与数据起源一致。源领域数据集代表了业务的事实和现实。源域数据集捕获的数据集与它们的原始业务系统生成的现实数据映射非常紧密。在我们的例子中，业务事实如“用户如何与服务进行交互”或“入驻标签流程”导致了域数据集的创建，例如“用户点击流”，“音频播放质量流”和“入驻的唱片公司”。这些事实是众所周知的，并且由数据起源处的业务系统生成。例如，媒体播放器系统最了解“用户点击流”。
在成熟且理想的情况下，业务系统及其团队或组织单位不仅负责提供业务功能，而且还负责将其业务域的真实情况作为源域数据集提供出来。在企业规模上，领域概念和源系统之间从来没有一对一的映射。通常有许多系统可以为属于某个领域的数据提供服务，其中一些是遗留数据，另一些是容易更改的数据。因此，可能会有许多源对齐数据集，也就是现实数据集，最终需要被聚合成一个内聚的域对齐数据集。
业务事实最好以商业领域事件的形式呈现，可以作为带有时间戳的事件的分布式日志进行存储，以供任何授权消费者访问。
除了定时事件之外，源数据域还应该提供容易使用的源域数据集的历史快照，这些快照在一个时间间隔内聚合，紧密反映了它们域的变化间隔。例如，在一个 “入驻标签”源域中，它显示向流媒体业务提供音乐的艺人的标签，除了通过入驻标签过程生成的事件外，每月聚合入驻标签是一个合理的视图。
注意，源对齐的域数据集必须与内部源系统的数据集分开。领域数据集的性质与业务系统用于完成其工作的内部数据非常不同。它们有更大的容量，表示不可变的时间事实，并且比它们的系统变化得更少。因此，实际的底层存储必须适合大数据，并与现有的业务数据库分离。“数据和自助服务平台的设计融合”章节介绍如何创建大数据存储和服务的基础设施。
源域数据集是最基础的数据集，并且更改频率较低，因为业务事实并不经常更改。预计这些域数据集将被永久捕获并变得可用，以便随着组织发展其数据驱动和情报服务，他们始终可以回到业务事实，并创建新的汇总或预测。
请注意，源域数据集 在创建时紧密代表原始数据，并且未针对特定使用者进行拟合或建模。
源域数据集是最基础的数据集，并且很少更改，因为业务事实不会经常更改。这些领域数据集应当被长期地捕获和提供，以便随着组织发展其数据驱动和智能服务，它们总是可以回到业务事实，并创建新的聚合或投影。
请注意，源域数据集在创建时紧密地表示原始数据，它不适合也不是为特定的消费者而建模。
面向消费者的共享域数据
一些领域与消费密切相关。消费者领域数据集和拥有它们的团队旨在满足一组密切相关的用例。例如，“社交推荐域”侧重于根据用户之间的社交联系提供推荐，创建适合此特定需求的域数据集；也许通过“用户社交网络的图表示”。尽管此图数据集对于推荐用例很有用，但对于“听众通知”域也可能有用，该域提供有关根据听众的类型发送不同的通知数据，包括其社交网络中的人正在听的内容。因此，“用户社交网络”有可能成为共享的和新定义的域数据集，供多个消费者使用。“用户社交网络”域团队致力于提供一个“用户社交网络”的始终精心设计的最新视图。
消费者对齐的领域数据集与源域数据集相比具有不同的性质。它们在结构上经历了更多更改，并且将源域事件转换为适合特定访问模型的聚合视图和结构，例如我们上面看到的图的例子。面向领域的数据平台应该能够轻松地从源头重新生成这些消费者数据集。
分布式流水线作为领域内部实现
尽管将数据集所有权从集中式平台委托给领域，但是仍然需要清理、准备、聚合和提供数据，数据流水线的使用也是如此。在这种架构中，数据流水线只是领域内部复杂性和数据域的实现，并在领域内部进行处理。结果，我们将看到数据流水线阶段分布到每个领域中。
例如，源域需要包括对其域事件的清理、去重、丰富它们的领域事件以便其它领域可以使用它们，其它领域无需重复清理工作。每个领域数据集都必须为其提供的数据质量建立服务水平目标（SLO）：及时性、错误率等。例如，我们媒体播放器领域提供音频“播放点击流”可以包括清理和标准化其域中的数据流水线，从而提供去重后的的近实时“播放音频单击事件”，这些事件符合组织的编码事件标准。
同样，我们将看到集中式流水线的聚合阶段迁移到了使用域的实现细节。
有人可能会说，这个模型可能会导致在每个领域中创建自己的数据处理流水线、技术堆栈和工具的这些重复工作。我将会在说稍后讲到的章节“数据与平台思维融合，自助共享数据基础架构作为平台”中解决这个问题。
数据和产品思维融合
将数据所有权和数据流水线实现分散到业务领域，这引起了对分布式数据集的可访问性、可用性和协调的重要关注。这是应用产品思维和数据资产所有权知识能够派上用处之地。
领域数据作为产品
在过去的十年中，业务系统领域已将产品思想融入到他们为组织其它部门提供的功能中。领域团队将这些功能作为API提供给组织中其他开发人员，作为创建更高价值和功能的构建块。这些团队致力于为他们的领域API创建最佳的开发人员体验。包括可发现且易于理解的API文档，API测试沙箱以及密切跟踪的质量和采用KPI。
为了使分布式数据平台成功，领域数据团队必须对他们提供的数据集应用具有类似的严谨的产品思维。将数据资产视为产品，并将组织的其余数据科学家、机器学习和数据工程师视为客户。
考虑我们的示例，互联网流媒体业务。它的关键领域之一是“播放事件”，即谁在何时在何地播放了哪些歌曲。这个关键领域在组织中有不同的使用者；例如，对用户体验以及可能的错误感兴趣的近实时用户，以便在客户体验下降或客户支持电话打入的情况下可以快速响应以恢复错误。也有一些用户更喜欢每日或每月歌曲播放事件汇总的历史快照。
在这种情况下，我们的“播放的歌曲”领域为组织的其它部分提供了两个不同的数据集作为产品。在事件流上公开的实时播放事件，以及在对象存储中作为序列化文件公开的聚合播放事件。
任何技术产品（在本示例中是领域数据产品）的一项重要质量就是使他们的消费者满意；在这个例子中是数据工程师、机器学习工程师或数据科学家。为了向用户提供最佳的用户体验，领域数据产品需要具有以下基本特质：
可发现的
一款数据产品必须易于发现。常见的实现方式是为所有可用的数据产品提供一个注册表，它包括一个数据目录，以及它们的元信息（比如其所有者、来源、数据血缘、样本数据集等）。这种集中式可发现性服务允许组织中的数据消费者、工程师和科学家轻松找到他们感兴趣的数据集。为了便于发现，每个领域数据产品都必须在此集中式数据目录中注册。
注意，这里的视角从单个平台提取并拥有数据转变为每个领域以可发现的方式将其数据作为产品提供。
可寻址的
数据产品一旦被发现，就应该有一个惟一的地址，该地址遵循一个全局约定，以帮助其用户以编程方式访问它。根据数据的底层存储和格式，组织可能对其数据采用不同的命名约定。考虑到易用性作为一个目标，在一个去中心化的架构中，有必要制定通用的约定规范。不同的领域可能以不同的格式存储和提供其数据集，事件可能通过诸如Kafka主题之类的流进行存储和访问，列式数据集可能使用CSV文件或AWS S3存储序列化Parquet文件。多种语言环境中的数据集可寻址性标准消除了查找和访问信息时的摩擦。
可信赖的、真实的
没有人会使用他们不信任的产品。在传统的数据平台中，可以接受提取并装载有错误、不能反映业务真相并且无法信任的数据。集中式数据流水线的大部分工作都集中在此，在提取数据后清理数据。
根本性的转变要求数据产品的所有者围绕数据的真实性、以及它在多大程度上反映了已经发生的事件的真实性，或者产生的洞察的真实度，提供一个可接受的服务水平目标。在创建数据产品时，应用数据清理和自动化数据完整性测试是提供可接受质量水平的一些技术。将数据来源和数据血缘作为每个数据产品关联的元数据提供，有助于消费者进一步信任数据产品以及适配其特定需求。
数据完整性（质量）指标的目标值或范围在领域数据产品之间有所不同。例如，“播放事件”领域可以提供两种不同的数据产品，一种接近实时、准确性较低，包括丢失或重复的事件，而另一种则具有较长的延迟和较高的事件准确性。每个数据产品定义并确保其完整性和真实性的目标级别（作为一组SLO）。
自描述的语义和语法
优质的产品不需要消费者手持即可使用：它们可以独立地发现，理解和消费。将数据集构建为数据工程师和数据科学家使用起来摩擦最小的产品，需要对数据的语义和语法进行良好的描述，理想情况下还需要样本数据集作为范例。数据模式是提供自助数据资产的起点。
可互操作并由全局标准管理
分布式领域数据架构中的主要关注点之一，是跨领域关联数据并将其以精妙的、深刻的方式组合在一起的能力，连接、过滤、聚合等。跨领域有效关联数据的关键是遵循某些标准和统一规则。此类标准化应属于全局治理，以实现多语言域数据集之间的互操作性。这种标准化工作的共同关注点是字段类型格式化、跨不同域识别多义词、数据集地址约定、通用元数据字段，事件格式（例如CloudEvents等）。
例如，在流媒体业务中，“艺术家”可能出现在不同的领域中，并且在每个域中具有不同的属性和标识符。“播放事件流”域对艺术家的识别可能与负责发票和付款的“艺术家支付”域的识别不同。但是，为了能够在不同领域数据产品之间关联艺术家的数据，我们需要就如何将艺术家识别为一个多义词达成共识。一种方法是考虑具有联合实体的“艺术家”和“艺术家”的唯一全局联合实体标识符，类似于联合身份的的管理方式。
全局管理的通信互操作性和标准化是构建分布式系统的基础支柱之一。
安全并受全局访问控制
无论架构是否集中化，必须安全地访问产品数据集。在去中心化的面向领域的数据产品的世界中，对每个域数据产品都以更精细的粒度应用访问控制。与业务交易领域类似，可以集中定义访问控制策略，但在访问每个单独的数据集产品时应用访问控制策略。使用企业身份管理系统（SSO） 和基于角色的访问控制策略定义是实现产品数据集访问控制的便捷方法。
“数据和自助服务平台的设计融合”章节描述了共享的基础架构，可以轻松自动的赋予每个数据产品上述能力。
领域数据跨职能团队
将数据作为产品提供的领域需要增加新的技能：（a）数据产品所有者和（b）数据工程师。
数据产品所有者围绕数据产品的愿景和路线图做出决策，关注消费者的满意度，并持续度量和改进其领域所拥有和产生的数据的质量和丰富程度。他负责领域数据集的生命周期，即何时更改、修改和退出数据和模式。他要在领域数据消费者的竞争需求之间寻求平衡。
数据产品所有者必须为其数据产品定义成功标准和与业务相关的关键绩效指标（KPI）。例如，数据产品的消费者成功发现和使用数据产品的提前期是可衡量的成功标准。
为了构建和运行领域的内部数据流水线，团队必须包括数据工程师。这种跨职能团队的一个奇妙的副作用是不同技能的交叉传授。我目前的行业观察是，一些数据工程师虽然能够使用其交易工具，但在构建数据资产时缺乏软件工程标准实践，例如持续交付和自动化测试。同样，正在构建业务系统的软件工程师通常没有使用数据工程工具集的经验。消除技能集竖井将创建可供组织更大更深的数据工程技能库。我们观察到DevOps运动中同样的交叉技能传授，以及诸如SREs之类的新型工程师的诞生SRE。
数据必须被视为任何软件生态系统的基础部分，因此软件工程师和软件通才（software generalists）必须将数据产品开发的经验和知识添加到他们的工具带中。类似地，基础设施工程师需要增加管理数据基础设施的知识和经验。组织必须提供从通才到数据工程师的职业发展路径。数据工程技能的缺乏导致局部优化，正如“ 孤立的和超专业的所有权”一节所述，组建了集中式的数据工程团队。
数据和自助平台设计融合
将数据所有权分配给领域的主要问题之一是在每个领域中操作数据流水线技术栈和基础设施带来的重复工作和技能。幸运的是，将通用基础设施构建为平台是一个众所周知的问题，并且已经得到解决。尽管不可否认的是，工具和技术在数据生态系统中还不成熟。
将领域无关的基础设施功能收集和提取到数据基础设施平台中，避免了重复设置数据流水线引擎、存储和流基础设施的工作。数据基础设施团队可以拥有并提供域捕获、处理、存储和服务其数据产品所需的必要技术。
将数据基础设施构建为平台的关键是（a）不包含任何特定领域的概念或业务逻辑，使其与领域无关，（b）确保平台隐藏了所有底层的复杂性，并以自助服务的方式提供数据基础设施组件。自助数据基础架构作为平台向用户（领域的数据工程师）提供的功能有一长串，以下是其中一些：
- 可扩展的多语言大数据存储
- 静态和动态数据加密
- 数据产品版本控制
- 数据产品模式
- 数据产品去标识
- 统一的数据访问控制和日志
- 数据流水线实施和编排
- 数据产品发现，目录注册和发布
- 数据治理与标准化
- 数据产品血缘
- 数据产品监控/报警/日志
- 数据产品质量指标（收集和共享）
- 内存数据缓存
- 联合身份管理
- 计算和数据局部性
自助数据基础设施的成功标准是减少基础设施上的“创建新数据产品的准备时间”。 这导致了自动化，这是实现“数据产品”功能所必需的，正如“将域数据作为产品”章节中介绍。例如，通过配置和脚本自动化数据提取、数据产品创建脚本来放置脚手架、在目录中自动注册数据产品等等。
使用云基础设施作为基础可以降低按需访问数据基础架构所需的运营成本和工作量，但是并不能完全消除需要在业务上下文中用到的高级抽象。无论云提供商是谁，都有大量且不断增长的数据基础架构服务可用于数据基础架构团队。
范式向数据网格转移
已经读了很长时间，让我们串起来看看。我们研究了当前数据平台的一些基本特征：集中式、整体式、高度耦合的流水线架构，被高度专业化的数据工程师竖井式的操作。我们介绍了一个无处不在的数据网格作为平台构建模块；面向领域的分布式数据产品，由独立的跨职能团队拥有，这些团队具有嵌入式数据工程师和数据产品所有者，使用通用数据基础设施作为平台来托管，准备和服务其数据资产。
数据网格平台是经过精心设计的分布式数据架构，在集中管理和标准化下实现互操作性，并通过共享和统一的自助式数据基础设施实现。我希望已经阐述清楚的是，这绝不是一个由无法访问数据所组成的支离破碎的孤岛。
您可能会问，数据湖或数据仓库在此架构中适合什么位置？它们只是网格上的节点。我们很有可能不需要数据湖，因为保存原始数据的分布式日志和存储可用于从作为产品的、不同可寻址的、不可变的数据集中进行探索。但是，如果我们确实需要更改数据的原始格式以进行进一步的探索（例如标记），有此需求的领域可能会创建自己的数据湖或数据中心。
因此，数据湖不再是整个架构的核心。我们将继续对面向源的领域数据产品应用数据湖的一些原则，例如使不可变数据可用于探索和分析使用。我们将继续使用数据湖工具，但是，要么用于数据产品的内部实现，要么作为共享数据基础设施的一部分。
实际上，这使我们回到了一切的起点： 2010年，詹姆斯·迪克森（James Dixon）打算将一个数据湖用于单个领域，而多个数据领域将形成一个“水花园”。
主要转变是将领域数据产品视为第一类关注点，而将数据湖工具和流水线视为第二类关注点-实现细节。这将当前的思维模型从集中的数据湖转变为可以很好地协同工作的数据产品生态系统，即数据网格。
相同的原则适用于用于业务报告和可视化的数据仓库。它只是网格上的一个节点，并且可能位于面向消费者的网格边缘。
我承认，尽管我看到数据网格实践已在我的客户的口袋中应用，但到企业规模化的采用仍然有很长的路要走。我不认为技术是这里的限制，我们今天使用的所有工具都可以容纳多个团队的分配和所有权。特别是向批处理和流式处理工具统一的转变，例如Apache Beam或 Google Cloud Dataflow，可以轻松地处理可寻址的多语言数据集。
诸如Google Cloud Data Catalog之类的数据目录平台，提供了分布式领域数据集集中的可发现性、访问控制和治理。各种各样云数据存储选项使领域数据产品可以选择适合自身的多语言存储。
需求是真实的，工具已经准备好。组织的工程师和领导者应当认识到，仅使用新的基于云的工具，现有的大数据范式和一个真正的大数据平台或数据湖只会重复过去的失败。
这种范式转变需要一套新的管理原则以及一种新的语言：
- 服务而不是提取
- 发现和使用而不是提取和加载
- 发布事件流而不是通过集中式流水线集中进行数据流动
- 数据产品生态系统而不是集中式的数据平台
让我们将大数据整体分解成为一个协调的、协作的、分布式的数据网格生态系统。