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

集中式和单体式

从30,000英尺的高度来看，数据平台架构看起来像下面的图1；一个集中式的架构，其目标是

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

图1：单体数据平台的30,000英尺视图

这是一个公认的惯例，即单体数据平台托管并拥有逻辑上属于不同领域的數據，例如'播放事件'、'销售KPI'、'艺术家'、'专辑'、'标签'、'音频'、'播客'、'音乐活动'等；来自大量不同领域的數據。

虽然在过去十年中，我们已成功地将领域驱动设计和限界上下文应用于我们的运营系统，但我们在很大程度上忽略了数据平台中的领域概念。我们已经从面向领域的數據所有权转向集中式的领域无关的數據所有权。我们为创建所有单体中最大的一个，即大数据平台而感到自豪。

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

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

集中式数据平台的架构和组织结构存在两个压力点，往往会导致其失败。

• 无处不在的数据和源的激增：随着更多数据变得无处不在，在同一个地方、在一个平台的控制下消费所有数据并将其协调起来的能力正在下降。想象一下，仅在'客户信息'领域，组织边界内外就有越来越多的来源提供有关现有和潜在客户的信息。我们必须在一个地方摄取和存储数据才能从各种来源获得价值的假设，将限制我们响应数据源激增的能力。我认识到数据科学家和分析师需要以低开销处理各种数据集，以及需要将运营系统数据使用与用于分析目的的数据分开。但我建议，现有的集中式解决方案并非拥有丰富领域和不断添加新来源的大型企业的最佳答案。
• 组织的创新议程和消费者激增：组织对快速实验的需求引入了更多用例，用于从平台消费数据。这意味着对数据进行越来越多的转换——聚合、投影和切片，以满足创新假设驱动开发的测试和学习周期。满足数据消费者需求的长时间响应时间历来是组织摩擦的一个点，并且在现代数据平台架构中仍然如此。

虽然我不想现在就给出我的解决方案，但我需要澄清一下，我并不是主张将孤立的、分散的、面向领域的數據隐藏在运营系统的深处；孤立的、难以发现、理解和消费的领域数据。我并不是主张创建多个分散的数据仓库，这些数据仓库是多年积累的技术债务的结果。这是行业领导者已经表达过的担忧。但我认为，对这些无法访问的意外数据孤岛的回应，不是创建集中式数据平台，由一个集中式团队拥有和管理来自所有领域的數據。正如我们上面所学和证明的那样，它在组织上无法扩展。

耦合管道分解

传统数据平台架构的第二个失败模式与我们如何分解架构有关。从10,000英尺的高度俯瞰集中式数据平台，我们发现其架构分解围绕着**数据摄取**、**数据清洗**、**数据聚合**、**数据服务**等机械功能。组织中的架构师和技术领导者会根据平台的增长来分解架构。正如上一节所述，平台需要不断发展以应对新的数据源接入或新的数据消费者需求。架构师需要找到一种方法，通过将系统分解成**架构量子**来扩展系统。正如《构建演进式架构》中所述，架构量子是一个独立部署的组件，具有高度的功能内聚性，包含系统正常运行所需的所有结构元素。将系统分解成架构量子的动机是创建独立的团队，每个团队都可以构建和运营一个架构量子。在这些团队之间并行工作，以实现更高的运营可扩展性和速度。

受前几代数据平台架构的影响，架构师将数据平台分解成**数据处理阶段的管道**。从非常高的层次来看，管道围绕着数据处理的技术实现实现了功能内聚；例如，**数据摄取**、**数据准备**、**数据聚合**、**数据服务**等功能。

图3：数据平台的架构分解

虽然这种模型通过将团队分配到管道的不同阶段提供了一定程度的可扩展性，但它也存在一个固有的限制，会减缓功能的交付速度。管道各个阶段之间存在高度耦合，难以交付独立的功能或价值。它**与变化轴正交分解**。

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

图4：在引入或增强功能时，架构分解**与变化轴正交**，导致耦合和更慢的交付速度

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

当今数据平台的第三个失败模式与我们如何构建和拥有平台的团队有关。当我们足够近地观察构建和运营数据平台的人员的生活时，我们发现了一群高度专业化的数据工程师，他们与组织的运营部门隔离开来；数据从哪里产生，或者数据在哪里被使用并转化为行动和决策。数据平台工程师不仅在组织上是孤立的，而且根据他们在大型数据工具方面的技术专长被分组到一个团队中，通常缺乏业务和领域知识。

图5：孤立的高度专业化的数据平台团队

我个人不羡慕数据平台工程师的生活。他们需要从那些没有动力提供有意义、真实和正确数据的团队那里获取数据。他们对生成数据的源领域了解甚少，并且缺乏团队中的领域专业知识。他们需要为各种需求提供数据，无论是运营的还是分析的，而对数据的应用和访问消费领域专家的途径并不清楚。

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

实际上，我们发现的是断开的源团队，沮丧的消费者争夺数据平台团队积压工作中的位置，以及一个过度紧张的数据平台团队。

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

面向领域的數據分解和所有权

埃里克·埃文斯的著作《领域驱动设计》深刻地影响了现代架构思维，以及随之而来的组织建模。它影响了微服务架构，将系统分解成围绕业务领域能力构建的分布式服务。它从根本上改变了团队的形成方式，以便一个团队可以独立自主地拥有一个领域能力。

虽然我们在实现运营能力时采用了面向领域的分解和所有权，但奇怪的是，我们在处理数据时忽略了业务领域的理念。DDD 在数据平台架构中最接近的应用是，源运营系统发出其业务**领域事件**，而单体数据平台则摄取这些事件。然而，在摄取之后，领域的概念以及不同团队对领域数据的拥有权就消失了。

**限界上下文**是一个非常强大的工具，用于设计数据集的所有权。本·斯托普福德的《数据二分法》文章阐述了通过流共享领域数据集的概念。

为了分散单体数据平台，我们需要颠覆我们对数据、数据位置和所有权的思考方式。与其将数据从领域**流入**一个集中式数据湖或平台，不如让领域**托管和服务**其领域数据集，使其易于被任何团队以任何目的进行消费。

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

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

这要求我们从传统的**推送和摄取**模式（通常通过 ETL 和最近的事件流）转变为跨所有领域的**服务和拉取**模型。

面向领域的 data platform 中的**架构量子**是**领域**，而不是管道阶段。

图7：根据领域分解架构和团队拥有数据 - 源、消费者和新创建的共享领域

面向源的领域数据

一些领域自然地与数据来源对齐，即数据从哪里产生。**源领域数据集**代表**业务的事实和现实**。**源领域数据集**捕获的数据与它们起源的运营系统（**现实系统**）生成的数据非常接近。在我们的示例中，业务事实，例如“用户如何与服务交互”或“标签入职流程”，导致创建了领域数据集，例如“用户点击流”，“音频播放质量流”和“入职标签”。这些事实最适合由位于起源点的运营系统所知和生成。例如，媒体播放器系统最了解“用户点击流”。

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

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

除了定时事件之外，源数据领域还应提供易于消费的源领域数据集的历史快照，这些快照在时间间隔内聚合，该时间间隔与它们领域的更改间隔密切相关。例如，在“入职标签”源领域中，该领域显示为流媒体业务提供音乐的艺术家的标签，在每月聚合入职标签是一个合理的视图，除了通过入职标签过程生成的事件之外。

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

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

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

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

一些域与消费密切相关。消费者域数据集及其所有者团队旨在满足一组密切相关的用例。例如，专注于根据用户之间社交连接提供推荐的“社交推荐域”会创建适合此特定需求的域数据集；也许通过“用户社交网络的图形表示”。虽然此图形数据集对推荐用例很有用，但它也可能对“监听器通知”域有用，该域提供有关发送给监听器的不同类型通知的数据，包括其社交网络中的人正在收听的内容。因此，“用户社交网络”有可能成为多个消费者使用的共享和新重新定义的域数据集。“用户社交网络”域团队专注于提供始终保持最新和最新的“用户社交网络”视图。

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

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

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

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

同样，我们也会看到集中式管道中的聚合阶段转移到消费域的实现细节中。

图 8：将管道作为二级关注点和域的内部实现细节分布到域中

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

领域数据作为产品

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

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

图 9：域数据集作为产品的特征

以我们的互联网媒体流业务为例。其关键域之一是“播放事件”，哪些歌曲由谁、何时何地播放。该关键域在组织中拥有不同的消费者；例如，对用户体验和可能的错误感兴趣的近实时消费者，以便在出现客户体验下降或传入客户支持电话时能够快速响应以恢复错误。还有一些消费者更喜欢每日或每月歌曲播放事件聚合的历史快照。

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

任何技术产品的关键质量，在这种情况下是域数据产品，是让其消费者满意；在这种情况下是数据工程师、ML 工程师或数据科学家。为了为消费者提供最佳的用户体验，域数据产品需要具备以下基本品质

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

跨职能的领域数据团队

提供数据作为产品的域需要增强新的技能集：（a）数据产品所有者和（b）数据工程师。

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

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

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

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

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