如何设计事件流，第 5 部分

让我们依次看看每个解决方案。

选项 1：使用专门构建的连接器服务进行非规范化

在此示例中，左侧的流镜像它们来自数据库中的表。

我们使用基于外键关系的专用应用程序(或流式 SQL 查询)加入事件，并发出单个丰富的项目流。

从逻辑上讲，我们正在解决关系并将数据压缩到单个非规范化行中。

将BrandName 解析到Item表中。

将 StateTax 和 CountryTax 解析为 Item 表

专门构建的连接器依靠 Apache Kafka Streams 和 Apache Flink 等流处理框架来解决主键连接和外键连接。它们将流数据具体化为持久的内部表格式，使连接器应用程序能够连接任何时期的事件 - 而不仅仅是那些受时间限制的窗口约束的事件。

使用 Flink 或 Kafka Streams 的连接器还具有显着的可扩展性——它们可以根据负载进行扩展和缩减，并处理大量流量。

提示：不要将任何业务逻辑放入连接器中。为了在这种模式中取得成功，连接的数据必须准确地表示源，简单地作为非规范化的结果。让下游消费者应用自己的业务逻辑，使用非规范化数据作为单一事实来源。

如果您不想使用下游连接器，还有其他选择。接下来让我们看一下事务发件箱模式。

选项 2：事务性发件箱模式

首先，创建一个专用的发件箱表，用于将事件写入流。

其次，将所有必要的内部表更新包装在事务内。事务保证对内部表所做的任何更新也将写入发件箱表。

发件箱允许您隔离内部数据模型，因为您可以在将数据写入发件箱之前连接和转换数据。发件箱充当内部数据和外部数据之间的抽象层，充当消费者的数据契约。

最后，您可以使用连接器将数据从发件箱取出并放入 Kafka。

您必须确保发件箱不会无限期增长 - 要么在 CDC 捕获数据后删除数据，要么通过计划作业定期删除数据。

示例：非规范化用户行为跟踪事件

跟踪网页和应用程序上的用户行为是标准化事件的常见来源 - 想想 Google Analytics 或第一方内部选项。但我们并没有包含事件中的所有信息;相反，我们将其限制为标识符(更快、更小、更便宜)，在创建事实后进行非规范化。

考虑一个项目点击事件流，详细说明用户在浏览电子商务项目时何时单击项目。请注意，此商品点击事件不包含名称、价格、描述等更丰富的商品信息，仅包含基本信息ids。

许多点击流消费者所做的第一件事是将其与项目事实流结合起来。由于您正在处理许多点击事件，您会发现它最终会使用大量的计算资源。专门构建的 Flink 应用程序可以将项目点击与详细的项目数据结合起来，并将它们发送到丰富的项目点击流。

拥有多个部门(和系统)的大型公司可能会看到他们的数据来自不同的来源，并且在事后使用流连接器加入是最可能的结果。

关于缓慢变化维度的考虑

我们已经讨论了写入包含大型数据集(例如大型文本 blob)和频繁更改的数据域(例如项目库存)的事件的性能注意事项。现在，我们将研究缓慢变化的维度(SCD)，通常通过外键关系表示，因为它们可能是重要数据量的另一个来源。

让我们再次回到我们的项目示例。假设您有一个更新项目表的操作。我们将把该物品从 Anvil 重命名为 Iron Anvil。

更新数据库中的数据后，我们还会发出更新的项目(例如通过发件箱模式)，以及非规范化的税收状态和品牌表。

然而，我们还需要考虑当我们更改品牌或税表中的值时会发生什么。更新这些缓慢变化的维度之一可能会导致所有受影响的项目发生大量更新。

例如，ACME 公司进行了品牌重塑并提出了新的品牌名称，从 ACME 更改为 Rotunda。我们为 举办另一个活动ItemId=123。

然而，Rotunda(以前称为 ACME)可能有数百(或数千)个项目也因此更改而更新，从而导致相应数量的更新丰富项目事件。

当对 SCD 和外键关系进行非规范化时，请记住 SCD 中的更改可能对整个事件流产生的影响。如果更改 SCD 会导致数百万或数十亿个更新事件，您可能会决定放弃非规范化并将其留给消费者。

概括

非规范化使消费者更容易使用数据，但代价是更多的上游处理和仔细选择要包含的数据。消费者可以更轻松地构建应用程序，并且可以从更广泛的技术中进行选择，包括那些本身不支持流连接的技术。

当数据较小且不经常更新时，标准化上游数据效果很好。较大的事件规模、频繁的更新和 SCD 都是在确定哪些内容要对上游进行非规范化以及哪些内容要留给消费者自行处理时需要注意的因素。

最终，选择在事件中包含哪些数据以及排除哪些数据是消费者需求、生产者能力和独特数据模型关系之间的平衡行为。但最好的起点是了解消费者的需求并隔离源系统的内部数据模型。