《流式Data Mesh》第四章：流式数据产品-灵析社区

第四章：流式数据产品

在流式数据网格中，领域拥有自己的数据。这样创建了一个分散的数据平台，以解决数据湖和数据仓库中与敏捷性和可扩展性相关的问题。领域现在需要向其他领域提供其数据。因此，重要的是将其数据视为具有高质量和可信度的产品。

目前，数据工程师习惯于将所有数据存储在像数据湖或数据仓库这样的中央数据存储中。他们习惯于在处理数据时尝试“煮沸整个海洋”（在这种情况下是指数据湖）。流式数据网格使我们能够摆脱这种思维方式。在本章中，我们将概述流式数据产品的要求。

在我们作为数据工程师的职业生涯中，我们发现自己经常为Apache Spark编写许多包装器，Apache Spark是一款广泛用于大规模数据处理的分析引擎。只有在过去几年，我们才完全理解为什么公司要求我们这样做。

对于许多被指派解决大数据问题的工程师来说，像Apache Spark、Apache Flink和Apache Kafka Streams这样的大数据工具是无法接触的。回顾第1章，打破数据工程师的单一角色是数据网格的一个副作用。

这一点非常重要，因为第二个副作用是使复杂的数据工程工具（如Spark、Flink和Kafka Streams）对于通用工程师更加可访问，使他们能够解决大数据问题。这就是为什么这些公司要求我们封装大规模数据处理引擎的原因。表4-1列出了我们参与的一些项目，以帮助特定工程师查询存储在数据湖中的大数据。

经过这么多次的实践，验证了简化数据工具以使其更易于访问对于通用工程师和有时候专业工程师的必要性，并不是为了减轻数据工程师的工作负担。这使他们能够更快地应对异常问题并向客户提供即时结果。

在构建数据产品时，理解这一点非常重要。为领域提供访问数据工具的能力将使他们能够解决复杂的数据问题。这种能力以前是无法实现的。

在接下来的章节中，我们将介绍在流式数据网格中定义和构建数据产品的要求。我们将尽量将详细信息的范围限制在构建流式数据产品上，并在相应的章节中提及与流式数据产品相关的自助服务和数据治理的详细信息。

定义数据产品需求

本节是对表4-2中列出的数据产品要求的摘要。这些要求的目标是为消费者和领域消费者提供流畅和愉快的数据网格体验。数据网格的健康状况取决于领域消费者对数据产品的体验。这些要求将有助于设计和实施满足消费者需求的数据产品。

事后补充数据产品要求可能会带来高昂的技术债务。例如，血统（lineage）很可能是一个难以事后添加的要求，如果没有构建所需的可引用元数据，这就很重要了。因此，为了避免昂贵的技术债务，早期考虑这些复杂的要求非常重要。

当其他领域请求数据产品时，请确保它们符合这些要求。在确定您需要组成数据产品的数据源时，请记住这些要求。

识别数据产品的派生产品

数据产品是从领域内的数据源派生出来的。它们也可以从其他领域的数据产品中进行增强。请记住，数据产品归属于生产它们的领域专家。如果您构建的数据产品需要从其他领域的数据进行增强，则需要将该数据摄入到您自己的领域中，以增强您自己的数据产品。我们将数据派生物定义为领域内的数据和从其他领域获取的数据。识别这些派生物并了解它们的集成点将有助于定义解决方案，以便将它们摄入到流式平台中。

数据有两种类型：静态数据和动态数据。我们需要开始摄入数据派生物，这将涉及将静态数据转变为动态数据。我们还希望保持已经处于动态状态的数据保持运动。在摄入过程中，早期思考数据的优化非常重要，以便下游组件可以利用这种优化。可以从在流式平台中的源主题中对数据进行分区开始。拥有足够的分区将高效地为消费者提供数据产品，并在数据管道中创建平衡的处理。

来自其他领域的派生产品

作为数据产品从其他领域派生出来的派生物，需要具备可引用性，以便生成完整的血统图。这可能涉及在整个网格中递归遍历的多个领域。保留数据产品当前血统的快照将逐渐过时，因为数据产品的派生物可能在质量、可扩展性和结构（如模式）方面发生了变化。在后面的章节中，我们将讨论数据治理和模式演进作为数据网格中的集中化组件。关于保留血统的技术将在第6章中更详细地讨论。

消费其他领域的数据产品并丰富自己的数据产品是在数据网格中工作的真正本质。这一体验将涉及请求访问数据产品，然后订阅数据产品的实时流。完成这些操作后，流式平台中将出现一个主题，代表来自其他领域的实时流式数据产品。数据产品订阅的一部分不仅涉及数据本身，还包括元数据。正是这些元数据将使跨多个领域的血统成为可能。

使用Kafka Connect摄入数据产品派生物

在确定了我们的流式数据产品的数据派生物之后，我们需要将它们摄入到流式平台中。将数据传输到或从符合Kafka标准的流式平台中的最简单方法是利用Kafka连接器。（其他平台，如Spark或Flink，也有自己的连接器。）Kafka Connect是一个框架，可以实现从数据源读取数据并将其传输到流式平台。反过来，它还可以实现将数据从流式平台写入数据汇（sink）。请参见图4-1。

Kafka Connect还提供低代码体验，这意味着领域工程师无需编写代码。我们将使用Kafka Connect作为将源数据摄入流式平台的方式。还有其他将数据摄入流式平台的方法，但很少支持我们所需的变更数据捕获（CDC）连接器。我们将在“Debezium Connectors”中讨论CDC。

Kafka Connect开源框架以可扩展的方式实现了数据的简单进入和退出。这也是我们选择讨论这个解决方案的原因之一。连接器能够连接到特定的数据源以及符合Kafka标准的流式平台（如Redpanda）来流式传输数据。其他产品，如Apache Pulsar，允许Kafka客户端将消息从Kafka生产和消费到它们的平台。

Kafka连接器不能单独运行，它们运行在Kafka Connect集群中，使其能够分布式和高可用。连接集群中的每个节点称为连接工作节点（connect worker）。每个连接器包含一个名为tasks.max的配置属性。任务是连接器中流式传输数据的主要进程。当配置多个任务时，连接集群能够将它们分布到工作节点上并行运行，实现可扩展性。如果集群中的一个连接工作节点发生故障，数据将重新分配到其余的工作节点上（参见图4-2）。tasks.max属性定义了在连接集群中为该连接器应创建的最大任务数。如果连接器无法实现此级别的并行处理，则可能创建较少的任务。

使用Kafka Connect和众多预构建的连接器可以加快构建流式数据网格的速度，并将开发和支持工作交给第三方供应商。已经构建了许多流行数据库和云数据存储的连接器。其中许多是由供应商自己开发并附带支持计划的。如果没有可用的连接器，集中的数据网格团队应该具备构建连接器并提供给数据网格中的领域使用的技能。

Kafka Connect是一个很好的解决方案的另一个原因是它标准化了数据摄入，简化了连接器的部署和管理。Kafka Connect集群提供了一个RESTful接口，可以与Jenkins、Kubernetes、Ansible或Terraform等CI/CD流水线轻松集成。

Kafka Connect具有一些称为单条消息转换（SMT）的转换能力，但这些能力局限于简单的转换。这意味着不能进行连接或聚合操作。数据转换最好在流式处理中进行整合，可以同时支持简单和复杂的转换。转换将在“将数据衍生物转换为数据产品”中进行介绍。

在摄入数据产品衍生物时，我们需要提前考虑最终的流式数据产品以及如何确保其易于消费。还要记住，数据是异步还是同步摄入将影响领域如何使用和消费您的流式数据产品。

可消费性（Consumability）

可消费性是一个非常重要的要求，因为它将直接影响领域消费者在流式数据网格中的体验。

如果其他领域不能轻松地消费流式数据产品，那么它们可能会选择退出流式数据网格，并决定通过手动构建自己的集成来绕过数据网格遇到的任何问题。在摄入数据衍生物时，会影响其他领域可消费性的一些因素包括：

缺乏可扩展性
缺乏互操作性

可扩展性（Scalability）

在考虑将数据派生物注入到流式平台时，了解需要注入数据的规模非常重要。在流式平台中，您需要确保分区的数量能够支持数据的预期流量（或速率）。在Kafka主题中，分区越多，数据的流动速度就越快。分区是Kafka实现并行处理的方式。在其他流式平台中，您需要类似地配置它们的主题等效项。

根据Apache Kafka的原始开发者之一Jun Rao提出的一个简单公式来确定分区数量，该公式基于吞吐量。该公式通过以下两个值中的较大值来确定分区数量：

所需吞吐量（t）除以您可以实现的将数据发送到分区的生产吞吐量（p）
所需吞吐量（t）除以您可以实现的从分区消费数据的消费吞吐量（c）

公式如下：

m a x ( t / p , t / c ) max(t/p, t/c) max(t/p,t/c)

以下示例展示了所需吞吐量为3 MBps（兆字节每秒）。生产者可以实现1 MBps的吞吐量。假设有3个消费者想要订阅这些数据，这意味着每个消费者需要1 MBps的吞吐量，总共为3 MBps。计算结果为3个分区。在这个示例中，对于大多数Kafka使用情况来说，分区数量实际上较低。您可以通过将该数量增加到5或6来为将来的吞吐量增加做准备：

m a x ( 3 M B p s / 1 M B p s , 3 M B p s / 3 M B p s ) = m a x ( 3 , 1 ) = 3 个分区 max(3 MBps/1 MBps, 3 MBps/3 MBps) = max(3, 1) = 3个分区 max(3MBps/1MBps,3MBps/3MBps)=max(3,1)=3个分区

其他因素可以帮助实现所需的吞吐量，但超出了本书的范围。

确定分区数量后，了解如何在所有分区之间均匀分布数据是实现平衡并行处理的重要因素。在Apache Kafka中，数据以键值对的形式发送。将键进行哈希运算，以确定将其分配到哪个分区。以下公式说明了这个过程：

key % p = 分区分配

当键在发送到Kafka主题的所有记录中均匀分布时，这个哈希算法能够很好地工作。换句话说，键应具有高基数并在整个数据集中分布均匀。高基数和均匀分布能够在所有主题分区之间实现良好的数据平衡。低基数或不均匀分布会导致不平衡的并行处理。在数据流入过程中的不平衡会影响数据管道中的所有下游组件。在Kafka主题中，这会表现为热点问题，即只有一个或几个分区承担大部分工作，从而导致整个数据管道运行缓慢。

因此，对数据进行分析，了解数据键的基数和分布情况是很有益的。在分布式处理中，定义具有高基数和均匀分布的键是一个重要的步骤，因为大多数分布式系统通过键将工作负载分配给其工作节点。

另一种提高可扩展性的方法是使用适当的数据序列化格式，下面将讨论这个问题。