《流式Data Mesh》第七章：构建流式Data Mesh-灵析社区

第七章：构建流式Data Mesh

在第3到第6章中，我们介绍了流式数据网格的支柱。现在我们将运用这些知识来设计一个流式数据网格。正如本书前面提到的，"数据网格"这个术语来自于微服务架构中的"服务网格"一词。我们借鉴这种相似性，使用与描述微服务架构部分相同的术语来描述流式数据网格的组成部分。我们将描述架构的每个部分，因此对微服务架构的了解不是先决条件。我们还将考虑多种流式数据网格解决方案，并列出它们的优点和权衡。最终得到的将是一个简单清晰的框架，可用于实现您自己的流式数据网格。

基础设施

正如在第1章中所述，我们将使用Kafka来实现流式数据网格。使用Kafka是可选的，可以替换为Apache Pulsar或Redpanda；无论您选择哪个，我们建议使用完全托管和无服务器的流式处理平台，以摆脱自我管理基础设施的任务。同样，我们将使用ksqlDB作为流处理引擎。它也可以作为完全托管或自我管理的服务提供。以下是一些完全托管的选项：

DeltaStream
Popsink
Decodable
Materialized
RisingWave
Timeplus

Kafka和ksqlDB都是使用SQL作为构建流式数据管道的主要方式的流处理引擎。可能还有其他选择，但在撰写本书时，这两个选项最为突出。我们在第6章讨论了支持域所需的自服务和相关工作流程。这些相同的自服务和工作流程无论您使用完全托管服务还是自我管理基础设施都可以使用。本章后面，我们将提供关于如何将这些自服务实现为工作流程的想法。

两个架构方案

在设计流式数据网格时，我们有两个选项：在域内使用专用的流式基础设施，或者使用共享的多租户基础设施，其中每个域都是一个租户（参见图7-1和7-2）。

这两个图表都包括了流式平台（Kafka、Pulsar、Redpanda）。不可见的是流处理平台（ksqlDB、SaaS流处理器）和Kafka Connect集群，因为它们的存在是隐含的。这两个图表的唯一区别是流式平台的位置。简要总结每个组件的目的，流式平台是用于流式传输数据（或事件）并将其存储在主题中的消息系统。流处理平台是在流式平台的主题之间对数据进行转换（丰富和清洗）的系统。最后，连接集群保存连接器，用于将系统（如数据库）与流式平台集成，以将其数据输入或输出到主题中。

在这两个选项中，流式数据产品的生产者和消费者（或客户端）在本地进行生产和消费。这意味着客户端可以访问靠近或最好是位于同一全球区域的基础设施。这是在流式数据网格中保持良好体验的一个规则。如果基础设施不接近，这些客户端将不得不通过长距离与其基础设施通信，从而在应用程序中产生延迟和其他不良影响。

如果需要处理较长的距离，可以使用复制机制将数据本地传递给客户端。复制是在流式平台（如Kafka）之间移动数据的过程。对于使用Kafka进行消费或生产的客户端来说，这个过程是隐藏的。因此，客户端不会暴露给长距离可能给它们带来的意外影响。现在让我们更详细地讨论这两个选项。

专用基础设施

此选项将基础设施（流式平台、流处理平台和Kafka Connect）部署到各个域中，以便只有该域本身可以使用它们；因此，它们是专用于域的基础设施。

这个选项具有一些优势：

安全性实施更容易，因为基础设施中没有其他需要分离的域（租户）。这减少了中央工程师需要开发的自服务数量，并使其更易于管理。这种复杂性的减少可能导致安全风险的降低。
基础设施在与域相同的区域进行配置。这使得所有数据派生都保持本地化，从而提高了基础设施组件的性能。它还减少了云中跨区域数据移动的成本。跨区域数据移动仅限于将流式数据产品复制到其他域。
使用情况指标更容易与域相关联。日志已经分隔开，可以与特定消费者关联，以便轻松计费。这包括审计日志，便于监控域中的安全访问。
可以将可扩展性专门应用于域，而不会影响其他域。扩展基础设施的上下文可能会造成中断。将中断限制在特定域内，将为所有未受影响的域提供更好的体验。
如果域向消费者保证了正常运行时间的服务级别协议（SLA），可以针对满足这些保证的域/数据产品实施灾难恢复计划。

唯一的缺点是将基础设施提供给所有域的成本。使用完全管理此基础设施的SaaS提供商可以降低这一成本。

有两种类型的域：生产流式数据产品的域和消费流式数据产品的域。一个域也可以是两者兼而有之。由于基础设施专用于域，我们将描述如何在这些域中部署基础设施。

生产域架构

生产域是指仅生成数据产品而不消费其他域的数据产品的域。在图7-3中，配置了一个Kafka集群、一个Connect集群和一个ksqlDB集群。

对于专用基础设施，这是域所需的最低配置。Connect集群从操作（源）数据库中读取数据并将其提供给Kafka。在将其发布为流式数据产品之前，数据派生物经过ksqlDB中的清洗、转换和混淆处理，并发送到最终的Kafka主题中。

如果您的数据源仅来自微服务，就没有必要使用Connect集群。同样，如果您的数据不需要任何转换或清洗，可以省略ksqlDB集群。大多数情况下，一个域将需要同时使用Connect集群和流处理集群来构建流式数据产品。

高吞吐量生产域

对于提供高吞吐量流式数据产品的域，我们建议将Kafka集群拆分为写入和读取集群（参见图7-4）。这样可以让每个集群独立扩展。写入集群针对高吞吐量写入进行了优化。读取集群专注于向其消费者提供具有特定SLA保证的流式数据产品。写入集群和读取集群之间的复制可以由Kafka连接器或集群链接处理，集群链接是Confluent提供的一种专有技术，使数据复制变得简单。它减轻了中央团队管理更多组件的负担。

同样，如果读取集群旨在为多个消费者提供服务，从而增加了读取吞吐量，这种模式也适用。在这种情况下，写入集群的规模可以比读取集群低。

拥有两个Kafka集群可以在灾难情况下提供故障转移的方式。这也增加了可靠性。每个集群都可以故障转移到另一个集群。这需要两个集群具有相同的容量。故障转移的协调是中央团队需要自动处理的事项。故障转移不是域需要了解的技能。灾难恢复的详细信息超出了本书的范围。

消费域架构

图7-5说明了生产领域的数据如何复制到消费领域中的Kafka集群。需要明确的是，生产领域和消费领域都有一个Kafka集群。流式数据从生产领域的Kafka复制到消费领域的Kafka。如何进行这种复制将在“数据平面”中讨论。重要的是要知道，在消费领域中执行复制的应用程序存在。如果生产领域实施了按使用量计费的方法，那么消费工作负载将不会成为成本的一部分，因为它位于消费领域的基础架构中。

如果您希望在消费领域内保持Kappa架构，请使用此架构。数据保持为流式，并且允许使用ksqlDB进行进一步处理，而无需首先落入数据库中。

该架构还使消费领域能够生成流式数据产品。它具有与生产领域相同的基础架构。在第2章中，我们提到流式数据网格的一个优点是对实时用例和批处理都提供了流式支持。我们还警告说，如果一个仅限批处理的领域突然需要实时用例而没有支持的基础设施，将会产生昂贵的技术债务。在消费领域中拥有一个Kafka集群可以避免这种债务。

该架构还提供与实时在线分析处理（实时OLAP或RTOLAP）数据库的集成。RTOLAP数据库可以快速检索、聚合和分析数据，而无需运行繁重的批处理。图7-6展示了与RTOLAP数据库的本机集成，并省略了图7-5中显示的Connect集群。图7-6展示了市场上今天可用的一些RTOLAP数据库示例：Rockset、Apache Pinot、Apache Druid、Materialized、Tinybird和ClickHouse。

这些RTOLAP数据库可以以大规模为实时仪表板和应用程序提供数据。通过流数据网格，您可以从产生领域中的源头保持Kappa架构，到消费领域中的实时应用程序。

没有流平台的消费领域

为了降低成本，只在消费领域部署一个Connect集群是可选的（参见图7-7）。此选项从产生领域的Kafka集群中消费数据，并将其持久化存储在消费领域的数据库中。

这个选项阻止了该领域自身提供流数据产品的能力。它还强制该领域运行批处理过程，以将数据转换到目标数据库中。这个转换将被嵌入到数据流水线中，但不会由中央团队支持。这是因为目标数据库在中央团队提供的基础设施范围之外。在数据流水线中嵌入的任何批处理过程将使该领域失去实时能力。要更改这一点，需要提供一个Kafka集群和一个ksqlDB集群。需要付出很大的努力来重新配置所有的基础设施，使其像图7-5一样工作。这是我们在第2章中提到的技术债务。

这个架构还给中央工程团队增加了工作量。他们必须支持两种消费流数据产品的方法：Kafka集群之间的复制（图7-5）和基于连接器的消费（图7-7）。每种方法都有自己的工作流程和自助服务来构建基础设施。这个选项开始变得更像是一种违反流数据网格精神的反模式。

多租户基础设施

在多租户基础设施中，Kafka被多个领域共享。访问控制被设置为将敏感数据与其他领域分离和保护。这可以降低成本，但会增加流数据网格的复杂性。

在图7-10中，Connect集群仍然在领域内部进行配置。ksqlDB仅部署在产生领域，这一点我们稍后会在本节中讨论。每个领域还通过访问控制被分配了多租户Kafka集群的一部分。

由于两个Kafka集群将为多个产生和消费领域提供服务，我们再次建议将写入集群与读取集群分离，以便能够分别进行扩展和简化管理。这将仅将流数据产品的转换工作负载隔离到写入集群中。在表7-1中，您可以看到实施此分离的一些优势列表。

生产域架构

在图7-10中，产生领域看起来类似于本章前面讨论的专用基础设施，只是Kafka是一个多租户集群并位于中央空间。写入集群将用于流数据产品的开发。领域中的Connect集群将将源数据衍生发送到写入集群中的主题。ksqlDB将访问这些主题，将衍生转换为构建流数据产品。最终的流数据产品从写入Kafka集群复制到读取Kafka集群。

作为发布的一部分，流数据产品会复制到读取集群中。独立的读取和写入集群有助于将资源用于流数据产品的开发，与为其提供服务的资源分离。再次强调，读取和写入流平台的分离使得扩展变得容易，而不会中断任何一方。

消费域架构

在图7-10中，消费领域没有ksqlDB，这意味着无法进行实时数据转换。如果消费领域需要进一步转换数据，有以下几种替代方案：

消费领域可以使用完全不同于流数据网格的基础设施，但这需要自行管理。消费领域的Connect集群很可能会将数据写入数据存储，这会立即强制执行批处理语义。将流数据产品持久化到数据存储中会将其转换为批处理数据产品。
使用Apache Spark或Apache Flink直接从流平台读取流数据产品。这将保持流式处理，但需要在这些技术上具备深入的技能。此外，基础设施将超出中央团队的责任范围。这将使消费领域回到单体式数据仓库或数据湖的方式。
让原始产生领域创建满足消费领域需求的新的流数据产品。这将不需要消费领域进行进一步的转换。

尽管其中一些替代方案遵循批处理语义，但数据产品仍然以流式方式进入消费领域，这仍然使得该解决方案符合流数据网格的要求。流数据网格确保数据产品从其来源流式传输到其消费者。消费者在消费数据产品后如何最终使用这些流数据产品（批处理还是流式处理）不在流数据网格的要求范围内。

需要注意的是，如果没有像ksqlDB或SaaS流处理器这样的流处理平台，领域将无法进行实时数据转换。数据产品的转换将需要在数据库或源系统本身中进行。这开始倾向于批处理语义。即使Kafka Connect在数据产品转换后读取数据库，生成的流数据产品也不会真正实时，而是数据产品的快照。消费者需要了解这一点，以便在实施其用例时考虑到这种行为。

区域

多半情况下，您的业务将跨越多个全球区域。如果是这样的话，将数据保持在接收方所在的区域是非常重要的。正如我们之前提到的，要求客户端跨区域进行数据的生成或消费将会对应用程序产生负面影响。

解决方案是在每个区域内复制读写流平台的模型，并在区域之间异步复制数据。图7-11展示了多个全球区域：美洲、欧洲、亚太地区。虚线表示区域之间的数据异步复制，实线表示客户端在各自区域内本地生成和消费数据。复制过程是一个流式处理过程，因此不会丢失实时性。

在这个模型中，为了避免在流平台内出现名称冲突，为所有资源提供前缀（或命名空间）非常重要。这包括主题名称和模式名称。

在图7-12中，假设通过流数据网格流动的流数据产品包含来自不同全球区域的员工信息。这些领域之间的分离是因为它们都有不同的工资和福利系统，并遵循不同的区域法规。遵循流数据网格中的数据治理规则，应达成共识，所有这些区域都将遵守一个单一的员工模式。这将防止每个区域中发生多次冗余的转换操作。

在图7-12中，浅色阴影的管道代表包含流数据产品的可写主题，该产品是本地写入的。其他管道表示只读主题，其中包含源自远程可写主题的复制数据。这为每个区域提供了一个本地主题，用于读取流数据产品，以及一个只有本地区域可以写入的本地可写主题。

为了创建业务中所有员工的单一全局视图，您可以同时消费这三个主题（参见示例7-1）。每个区域都可以创建一个包含所有员工合并为单个流的全局视图。

consumer.subscribe(["*.employees.dp"])

这种模式对于专用基础设施解决方案也是适用的。专用基础设施和多租户基础设施并不是相互排斥的。我们可以两者混合使用。这需要中央团队更多地管理和组织基础设施和元数据。例如，可以为美洲地区的域提供专用基础设施，而将亚太地区和欧洲地区限制为多租户基础设施。在云环境中，这些地区的基础设施配置往往更昂贵，而在这些地区实施多租户解决方案可能是一种更具成本效益的选择。

我们提出的这两种架构解决方案都是针对域和它们之间的数据共享。它们使域能够生成和消费流数据产品。流数据网格还有一个中央组件，用于协调和管理它及其域，中央团队是其中的一部分。它还具有作为流数据网格核心的架构。

流数据网格中央架构

流数据网格的中央架构是指域之外的一切。它由中央团队操作，并管理通过我们在第6章中介绍的命令行界面触发的所有自服务。它还管理OpenLineage、模式注册表、流数据目录等。在本节中，我们将列出中央架构中的所有系统，并查看域和流数据网格之间的相互通信。

微服务具有数据平面、控制平面和边车组件。将这些组件组合在一起形成了服务网格，从中派生出了“网格”一词。数据网格的概念就是从这种架构中引申出来的。我们可以将这些组件与流数据网格中的组件进行映射：

边车组件是部署在域内的代理，与控制平面进行通信。
域之间的数据复制是数据平面。
中央流数据网格是控制平面（除了域之外的一切）。

在本节中，我们将详细介绍这些映射关系。术语“数据平面”将代表流数据产品在域之间的复制，并由域代理控制。我们还将开始称呼中央流数据网格为“控制平面”。

域代理（aka Sidecar)

在微服务中，边车是与微服务一起部署的组件，它与控制平面进行通信。控制平面与边车进行通信，以控制微服务的行为、配置其安全性、捕获使用度量和配置数据的传输。在流数据网格中，也可以使用相同的概念。

该代理的唯一目的是将域与流数据网格之间的所有交互聚合到一个组件中，以便在配置域时可以轻松部署。我们在第6章中提到的面向域的CLI与控制平面进行通信。然后，控制平面代表CLI向域代理发送命令作为命令工作流的一部分。以下是一些命令示例（非详尽列表）：

下载并安装连接器和UDF（用户自定义函数）到相应的系统。控制平面中的自助服务将编排一系列任务，包括（1）在中央仓库中搜索连接器或UDF（即构件），（2）命令域代理将构件下载到域本地，然后（3）指示域在相应的系统中安装或升级现有构件。
配置生产和消费域之间的复制。此命令将要求从生产和消费域中的多个域代理进行编排，包括（1）向消费域授予对流数据产品的访问权限，（2）检查每个域中两个流平台的容量，并且（3）在消费域中从生产域进行复制。
发布流数据产品，包括（1）构建AsyncAPI YAML文档，（2）在模式注册表中注册其模式，（3）将其部署添加到OpenLineage图中，然后（4）在流数据目录中部署AsyncAPI。

这些工作流本身也不是详尽无遗的。我们将在本章后面提供更详细的示例，说明这些工作流的实现方式。

在图7-13中，我们将域代理的位置表示为每个域中的代理/边车。该代理使数据可以在流数据网格中的其他域之间移动，这被称为流数据网格中的数据平面。控制平面控制代理并代表管理平面编排工作流。

数据平面

在图7-13中，如前所述，数据平面表示域之间复制流数据产品，并由域代理提供支持。域代理根据控制平面的指示来配置数据的复制。

域代理配置数据复制机制。在本章中，我们将使用的机制是集群链接（cluster linking），这是一项由Confluent提供的功能，使Kafka代理能够相互复制数据。配置必须包括安全性和监控。域将不知道流数据产品复制到消费域的具体机制或该机制如何获得安全性。

域中所有系统的安全日志（如审计日志）和使用度量日志也属于数据平面的一部分。度量日志将被发送到可观测性服务（如Datadog、AppDynamics或Prometheus和Grafana）。安全日志将被发送到安全信息和事件管理（SIEM）服务（如Splunk、Sumo Logic或SolarWinds）。许多这些日志服务可以用于度量日志和安全日志。域代理会自动配置这些日志系统，并且在域中大部分是隐藏的。

控制平面

控制平面与域代理进行通信，以执行许多与域相关的任务。这些任务是由CLI或中央团队从管理平面发起的。在本书的大部分内容中，我们一直将流数据网格的这一部分称为“流数据网格”甚至是“中央域”。它包括中央团队、自助服务的实现以及支持域的系统，如OpenLineage和Schema Registry。正如前面所述，在本书的剩余部分中，我们将称之为控制平面。在图7-14中，控制平面包含三个子平面：

元数据和注册平面

包含控制平面需要使用的许多开源工具。它们包括OpenLineage、Apicurio、Schema Registry和JFrog（一个构件库）。这些工具中包含了消费者在流数据网格中发布的流数据产品中所需的大部分元数据，使消费者能够信任这些产品。

管理平面

为用户提供监控流数据网格和发起命令的访问权限。

自助服务平面

自助服务平面包含面向域的服务。

管理平面和元数据注册平面

管理平面（Management plane）在图7-14中提供了与域角色进行交互所需的接口，通过控制平面与其自身的域进行交互。管理平面还被中央团队用于管理控制平面和域。它包含了可视化工具，允许团队监控使用度量和安全日志。他们能够从日志和度量中接收警报，以帮助诊断问题。中央团队能够禁用系统、断开连接、隔离域，并应用速率限制规则，如限制数据吞吐量和存储。

元数据和注册平面，实际上可以是管理平面的一部分，允许用户管理模式、监视数据产品部署、可视化谱系图，并在JFrog Artifactory中更新连接器/UDF。我们在图中将这些平面分开，再次帮助组织系统。一个单一的可视化工具将有助于提供一个“全景式”的视图，聚合所有所需的元数据和用户界面，以帮助管理整个流数据网格。您应该能够在管理和元数据/注册平面中更换不同的产品，仍然能够获得对流数据网格的相同视角。

自助服务平面

自助服务平面没有可视化工具。它是实施自助服务的微服务面向域的部分。它也是由中央团队控制流数据网格的微服务。这些服务直接与域代理进行通信，并调用工作流。基本上，自助服务平面由中央团队开发的代码组成，用于整合流数据网格中的所有域和系统。

工作流编排

在自助服务平面编写的大部分代码都被实现为工作流编排的有向无环图（DAG）。这些DAG提供了工作流的可视化，可以提供给合规审计员和中央团队的管理员。这些可视化是证明数据治理和法规遵守的证据。例如，在构建生产域和消费域之间的复制过程时，应包含逻辑以显示未违反GDPR。可以是一个采样敏感信息并拒绝复制的机器学习算法，也可以是一个手动任务，使安全团队成员执行相同操作。无论哪种方式，看到任务是工作流的一部分将有助于让参与流数据网格的所有人放心。在图7-14中，工作流编排的实现是Apache Airflow。市场上还有其他工作流编排器，如Dagster和Luigi，可以完成相同的工作。在这个例子中，我们将使用Airflow。

实施链接的DAG

图7-15是一个DAG，展示了将生产域与消费域链接以复制流数据产品的工作流程。在这个例子中，DAG中的一个节点检查GDPR违规情况。图7-15显示，GDPR法规检查结果没有违规，但对于一些节点，未能授予对主题的访问权限。

我们可以在DAG中添加更多逻辑，以检查可能影响域之间创建集群链接的更多信息。在图7-16中，我们在实际授予对主题的访问权限之前添加了两个节点。首先，我们添加了一个检查，以查看目标Kafka集群是否具有足够的容量来容纳流数据产品。其次，我们检查源Kafka集群的容量，以确定是否具有资源来添加另一个消费者到其流数据产品中。

更准确地表示工作流程将帮助审计员知道我们正在采取措施防止违规行为。准确性还可以在命令不起作用时更容易进行调试。中央团队可以直接查看工作流程后面的具体任务，以调查和解决问题。在Airflow中，DAG使用Python编写。示例7-2是一段Python代码片段，显示了如何组装DAG，但缺少与任务的实现。每个方法都是一个任务，并向下一个任务提供输入。这为Airflow提供了代码内省的信息，以生成用户的图形视图。

1 @dag(
2 	tags=['link'],
3 	description='link data product to consuming domain'
4 )
5 def link():
6 
7 	@task
8 	def grant_access_to_topic(data_product, source, destination):
9 		return {}
10 
11 	@task
12 	def check_capacity_source(destination):
13 		return {}
14 
15 	@task
16 	def check_capacity_destination(destination):
17 		return {}
18 
19 	@task
20 	def check_for_gdpr_violation(dataproduct):
21 		return { "ok": True }
22 
23 	@task
24 	def create_link(data_product, destination):
25 		return {}
26 
27 	@task
28 	def test_link(context):
29 		return {}
30 
31 	@task
32 	def notify(results):
33 		return {}
34 
35 	data_product = "foo"
36 	destination_domain = "bar"
37 
38 	result = check_for_gdpr_violation(data_product)
39 	link = create_link(
40 		grant_access_to_topic(
41 			result,
42 			check_capacity_source(destination_domain),
43 			check_capacity_destination(destination_domain)
44 		),
45 		destination_domain
46 	)
47 	notify(test_link(link))
48 
49 
50 link = link()

这个DAG应根据业务的数据治理需求进行定制。业务可能需要在工作流程中添加额外的任务，比如捕获要发送到Prometheus的度量日志，或在可以自动完成的情况下添加更多的容量。更重要的是，需要进行OpenLineage调用，将消费域追加到谱系图的末尾。在Airflow中，DAG也可以通过事件（称为Sensors）触发启动，或者从微服务中调用，传递DAG所需的所有参数。尽管流式数据网格专注于实时用例，但DAG本身不需要实时运行，可以具有批处理语义，特别是如果工作流需要人工干预，如通知和审批。这些人工干预很可能会在第二天进行。

实施用于发布数据产品的DAG

另一个重要的可视化DAG是用于发布流式数据产品的DAG。这个示例再次帮助可视化正确执行此操作所需的步骤。在图7-17中，这个工作流逻辑可能变得更加复杂。考虑将其拆分为多个DAG以简化可视化。

在这个DAG中，重要的任务是设置日志记录和构建AsyncAPI YAML文档。它足够详细，可以帮助轻松查找任何任务中的问题。

基础设施即代码（IaC）

另外，您可以在我们的DAG中加入调用Terraform或Ansible等工具的代码，这些工具可以构建基础设施。这些工具用于简化供应和弹性扩展（向上或向下扩展）的工作。同样，像Kubernetes这样的框架可以帮助简化与控制平面相关的一些任务。

一些示例包括部署流式平台、流处理平台和Kafka Connect。它们可以添加额外的代理来增加流式平台的容量，或者向Kafka Connect集群添加更多的Connect工作者来处理更大的负载。构建这些工具的混合体可能有助于供应基础设施。

总结

本章重点介绍了如何构建数据平面、控制平面（包括其他子平面）、自助服务平面和管理平面。我们还提供了一些应用程序和工具，以便轻松实现这一目标。我们并没有固守解决方案中的任何产品，它们只是用来识别构建良好控制平面的组成部分的方式。您最终使用的工具希望能够满足您所替代的功能。

本章在很大程度上依赖于在Kafka集群（或您选择的流式平台）之间复制数据的能力。本章中的图表暗示了使用Confluent提供的集群链接来在集群之间复制/镜像Kafka主题。您也可以使用MirrorMaker 2（MM2）来实现这一点，它是一个在Kafka集群之间进行数据复制的开源工具。其他流式平台可能会有自己的解决方案来复制流式数据，这可能包括分离存储层或使用分层存储。这些细节超出了本书的范围。

中央团队需要在编码和基础设施方面具备更深入的技能。之前在单体数据湖或数据仓库中工作的数据工程师非常适合转向中央团队。他们应该具备Python、Java/Scala、Kubernetes、Terraform和构建微服务等技能。在第8章中，我们将提供建立一个数据团队的指导，以帮助您创建一个良好的流数据网格。

《流式Data Mesh》第七章：构建流式Data Mesh-灵析社区

第七章：构建流式Data Mesh

基础设施

两个架构方案

专用基础设施

生产域架构

高吞吐量生产域

消费域架构

推荐的架构方案

多租户基础设施

生产域架构

消费域架构

区域

流数据网格中央架构

域代理（aka Sidecar)

数据平面

控制平面

管理平面和元数据注册平面

自助服务平面

总结