数据库和文件的事件驱动架构较佳实践

我们遇到了问题。数据集成领域以基于轮询的 ETL 管道为主，这些管道按计划运行并发起与源数据系统的通信。这种模式很普遍；各行业各种规模的公司都在使用它。

为什么这是个问题？其实有两个：

1. 增加了源数据系统的负载：在许多情况下，源系统是应用程序数据库，ETL 工具查询该数据库以获取数据的更改。
   通常使用“增量”方法来仅选择自上次轮询以来已更改的数据，并且您可能会认为这种方法可以较大限度地减少这些查询扫描的数据量。然而，在很多情况下，你都错了。
   
   实际上，这些查询通常会扫描整个表。这是因为源系统的索引通常与 ETL 工具用于过滤数据的键不匹配，因此查询经常对数据库进行完整扫描以搜索新行，即使它只返回一小部分子集。
   因此，虽然由于查询结果集较小，采用增量方法您的网络和存储负载可能会更小，但您的应用程序数据库仍然支持全表扫描。您较终可能会给数据库带来巨大的负载，这较多只会降低其所支持的应用程序的体验。更糟糕的是，您将看到天价的计算费用。
2. 您可能认为从数据库中提取更改的增量方法会很有效，但在许多情况下，这些查询仍然会扫描整个表。

1. 变更数据并不新鲜。根据定义，基于轮询的 ETL 按计划运行，因此一旦作业完成就会立即过时。在较好的情况下，这些作业每小时运行一次。更常见的是，它们每 12 到 24 小时运行一次。
   您可以较大限度地缩短轮询作业之间的时间以使事情变得更新鲜，但现在您遇到了问题#1，并且您不能冒险关闭应用程序来支持您可能拥有的任何下游数据需求。
   因此，您根本无法支持依赖于实时数据的用例，例如面向用户的分析、基于使用情况的计费、实时个性化引擎、实时欺诈检测等。对于基于轮询的 ETL 来说这是不可能的。
2. 基于轮询的批量 ETL 会给源数据系统带来过度的压力，并导致过时的数据被加载到下游系统中。在这篇博文中，我重点介绍了几种事件驱动的架构模式，作为基于轮询的工作流程的替代方案。

在Tinybird，我们相信数据应该在发生时立即处理。时期。我们认为，数据和工程团队应该使用专门适合处理和处理这些数据的工具，而不会给其他系统和资源增加过度的压力。

在这篇博文中，我将重点介绍可以跨不同源数据系统实现的几种不同的事件驱动架构模式，并讨论这些实现的优缺点。

切换到事件驱动架构

事件流、消息队列和无服务器功能正在兴起，一些开明的人正在从轮询思维转向新的范式：事件驱动架构。

事件驱动架构的概念非常简单。数据几乎总是为了响应某种事件而生成：用户单击按钮、处理事务、上传文件。为什么不使用这些事件来触发实时数据摄取过程？

事件驱动架构背后的想法很简单：使用事件触发数据摄取过程。

事件驱动架构解决了上述两个问题，并且它已经作为绕过（或者更确切地说，并行）源数据系统的数据捕获和集成的方法而受到关注。

事件驱动架构的示例用例

考虑一个几乎适用于所有 B2C 业务和大多数 B2B 业务的场景：您有一个面向用户的应用程序，该应用程序构建在与 Postgres 或 MySQL 等应用程序数据库通信的后端 API 之上。

当用户在应用程序中执行操作时，它会调用 API 并生成一些数据，然后将其推送到数据库。随着您的公司获得关注并且应用程序添加了更多用户和更多功能，您开始扩展数据库，拼命努力跟上来自 API 的单行插入频率的增加。

然后营销部门的一些笨蛋想要对这些数据进行分析。因此，您在晚上大多数用户都在睡觉并且应用程序数据库服务器有一些额外周期时运行批量导出，然后将新数据复制到数据仓库。这很常见。大多数公司都是这样做的。

这就是您遇到这两个问题的地方。批处理作业会给数据库带来额外的负载，并且较终会得到陈旧的数据。如果您尝试更频繁地运行该作业来进行补偿，则会增加负担。这是一个无法通过批量 ETL 解决的第 22 条军规。

批处理作业会给数据库带来额外的负载，并且较终会得到陈旧的数据。如果您尝试更频繁地运行该作业来进行补偿，则会增加负担。这是一个无法通过批量 ETL 解决的第 22 条军规。

那么如何才能避免这两个问题并且仍然让营销人员满意呢？

关键是在数据到达应用程序数据库之前（或同时）将数据获取到仓库。在这种情况下，您已经有一个事件：API 调用。您可以利用这一点，将事件及其数据推送到消息队列，同时后端将其插入应用程序数据库。

通过这种事件驱动的方法，您完全稍后从应用程序数据库中提取此数据；它已经在消息队列中了。

事件驱动方法的关键是在数据到达应用程序数据库之前（或同时）将数据获取到仓库。

这是一种非常有效的模式，因为数据已经生成并存储在后端的内存中。您只需将其发送到另一个端点即可。

但是，与所有模式一样，有一个缺点：您必须对应用程序的后端进行代码更改。这项工作通常被推给负责后端的软件工程师，而不是管理数据（库）的团队。

这可能会给您的组织带来挑战，也可能不会。如果软件团队积压了问题，这可能不是优先考虑的事情。这完全取决于他们的移动速度以及您可以等待多长时间。

变更数据捕获怎么样？

变更数据捕获(CDC) 是事件驱动架构中经过验证的实现，您可以使用它来避免在不接触后端的情况下加载数据库，它有其优点和缺点。

使用 CDC，您可以订阅数据库中所做更改（例如插入、更新和删除）的日志，并将这些更改推送到其他地方。如果您不适合对 API 进行代码更改，那么 CDC 是在应用程序数据库之外构建事件驱动管道的好方法。

大多数应用程序数据库都会创建对数据库执行的操作的日志。对于某些数据库，此日志是数据库架构的核心部分，例如 Postgres 的预写日志（WAL）。对于其他人来说，这是一个需要启用的单独功能，就像 MySQL 的 bin 日志一样。

无论哪种情况，其想法都基本相同。日志是数据库更改（例如插入、更新、删除）及其数据的仅附加文件。每个操作都按时间顺序附加为新行，这意味着您只需从顶部开始并逐一重播每个事件，即可使用日志在准确的时刻重建数据库的状态。

CDC 工具会监视此日志文件中的新行，将每个更改操作捕获为一个事件，并将这些事件推送到其他地方。将这些事件推送到仅附加事件流系统（例如 Apache Kafka）的情况尤其常见。然后可以将更改操作推送到所需的下游系统，例如分析 (OLAP) 数据库。

如果您不能或不想更新现有的 API 代码，则更改数据捕获是一种有吸引力的策略。拥有数据库的团队通常拥有 CDC 实现，并且有像 Debezium 这样的开源框架，使得启动和运行相对简单。

由于此策略仅涉及监视日志文件，因此它比对数据库运行增量查询要轻得多。新行会立即附加到日志文件中，因此可以近乎实时地访问它们，从而将延迟保持在较低限度。

当您的后端工程团队无法或不想更新后端 API 以与数据库写入并行地将事件发送给下游消费者时，变更数据捕获系统是事件驱动架构的一个很好的替代方案。

然而，这并不全是阳光和雏菊。虽然读取日志文件是轻量级的，但它仍然需要服务器上的额外代理进程，这确实增加了负载。在扩展应用程序数据库时，它增加了另一层考虑因素，因为您必须考虑增加的流量将如何影响该代理所需的资源。

它还引入了您的团队可能不熟悉的全新技术。虽然这些工具被广泛采用且易于上手，但随着规模的扩大或偏离常规，它们可能会变得难以理解。

这两种策略都没有错，较终结果基本相同：来自应用程序堆栈的实时更改流。由您决定较佳方法。

事件驱动架构不仅仅适用于数据库

当然，并非每个数据摄取场景都涉及应用程序数据库。也许甚至不是大多数。在这种情况下，数据库中的行与生成的事件之间可能不具有 1:1 的关系。在许多情况下，您实际上可能会以文件形式接收数据，这些数据要么是从内部服务推送的，要么是从外部数据供应商收集的。事件驱动架构可以像数据库一样应用于文件系统。

在过去（实际上，今天仍然很常见），数据生产者或经纪人会建立一个大型文件传输协议（FTP）服务器并将文件转储到一个大型存储服务器上。他们向客户提供 FTP 凭据，客户端将在每天运行的 bash 脚本中使用该凭据来查找新文件并将其复制到内部共享存储中。这是一个奇特的小工作流程，多年来一直发挥其作用。

但是，除了过时之外，它还存在一些问题：

1. 必须有人维护庞大的存储服务。任何数据生产者或经纪人都需要构建和维护自己的内部文件存储系统。这是昂贵且痛苦的。
2. FTP 不灵活或可扩展。FTP 不是一个特别灵活的协议，尤其是当您下载大文件时，网络故障可能会导致传输中断，您必须从头开始。它也很难扩展，因此通常很慢。由于许多客户端同时连接并尝试下载文件，速度很快就会变得缓慢。
3. FTP 已经过时且不灵活，但至今仍被广泛使用。

事件驱动数据管道的好处在于它们非常灵活，可以适应许多用例、许多源数据系统以及下游数据消费者的许多不同需求。它们可以像数据库一样用于文件，尽管使用的是不同的工具集。

现代云供应商使事件驱动的文件摄取变得简单

时代变了，现在我们拥有容错、可扩展且经济的文件存储服务，例如 Amazon S3 和 Google Cloud Storage。

这些服务不仅使用起来比 FTP 更有趣，而且还使得使用事件驱动的架构来分发和使用文件成为可能。而不是不断地轮询存储服务来询问“新文件是否到达？” 或者等待一整天然后说“给我昨天到达的所有文件”，存储服务本身可以创建有关新文件的通知并将它们推送到消息队列，就像在数据库的事件驱动架构中一样。

然后，下游消费者可以简单地订阅消息队列，并在收到通知时去获取文件。

托管在云供应商的对象存储中的文件可以利用云原生通知服务来通知下游消费者有新的或修改的文件。

这种模式非常有用，有以下几个原因：

1. 它比 FTP 更强大。您不必担心维护 FTP 服务器或您自己的文件存储系统。您不必担心网络故障或客户端连接速度慢。您不必担心如何处理迟到的文件或已重新上传的文件以修复数据中的错误。存储服务和消息队列让这些痛苦大部分神奇地消失了。
2. 它增加了数据的新鲜度。当然，如果您正在处理文件，您永远不会拥有较新的数据，因为它们已经全部批处理到文件中......但您至少可以在文件准备好后立即获取文件，而不是几个小时或几天后。

您可以看到这如何反映应用程序数据库的场景。源数据系统不同，但实现和好处非常相似。

由于这些现代云存储服务内置了事件通知，只需单击一下即可启用，因此设置事件驱动的文件摄取非常容易。数据创建者几乎不需要做额外的工作，数据消费者可以利用无服务器服务，从而轻松采用这种新模式。

例如，Amazon 有 SQS 和 SNS，可用于对这些事件进行排队，然后您可以附加任意数量的工具来响应事件并处理文件。例如，您可以使用 Apache NiFi 处理在 SQS 中排队的 S3 事件通知。

消息队列：灵活、耐用、

因此，无论您使用数据库还是文件作为源数据系统，您都可以采用这些新模式来实现事件驱动架构。您可以发出事件，而不是轮询数据库或文件存储以获取更改。

但你应该如何处理这些事件呢？

实际上，你有两个选择：

1. 将事件放在消息队列或事件流平台上，或者
2. 让事件直接触发流程

在上述事件驱动模式中，我特别提到了选项 #1。这是模式，也是大多数人选择的模式。

为什么？消息队列是一种持久、灵活且的数据到达方式。消息队列的优点有两个：

首先，您通过以下方式解决我们开始的两个问题：

1. 将下游用例与源数据系统解耦，以及
2. 数据生成后立即交付给消费者。

其次，大多数消息队列允许任意数量的下游消费者连接并订阅新消息。因此，如果 4 个不同的团队构建 8 个不同的东西，想要以 16 种不同的方式访问数据，他们就可以各自完成自己的事情，而不会互相干扰。

消息队列并不是处理事件驱动的实时数据摄取的方法，但它们是迄今为止较受欢迎的方法，因为它们将源数据与消费者解耦，并且足够灵活，可以同时处理许多不同的消费者。

如果团队只想每天获取更改，他们可以批量使用昨天的消息。但是，如果另一个团队想要实时使用消息，他们可以监视新消息并在数据到达时自动触发其流程。

该模型非常适合数据库和文件，但它确实需要额外的中介服务。随着事件驱动架构和实现的增长，您可能会投入大量资源来维护和扩展消息队列或事件流平台。考虑到事件驱动架构所实现的所有实时用例，这可能是一个值得的权衡。

那么，您可以跳过队列吗？

是的，您可以跳过队列

在某些情况下，您可以让事件直接触发流程。例如，您可以将 Amazon S3 配置为直接触发 AWS Lambda 函数，从而允许您立即处理单个事件。您可以使用其他处理框架（例如 Apache NiFi 或 Apache Flink）复制此模型。

现在，这种方法有利有弊。较大的优点是您可以省去另一个中间服务，因此它既便宜又简单。当您立即调用处理函数时，您还可以较大限度地减少延迟并保持数据新鲜度。

更简单的用例，您可以跳过消息队列并使用无服务器函数根据源文件系统中的更新立即触发进程。

然而，也有缺点。消息队列提供了您在处理框架中可能无法获得的持久性级别，这可能会使处理故障变得更加困难。

你也会失去一些灵活性。由于您避开了“发布/订阅”模型，因此您可能会直接将事件发送到单个处理器，而不是将它们发布到多个处理器可以根据需要进行订阅的队列。

例如，如果您将事件发送到 SQS，您可以连接一堆不同的工具（例如 Apache NiFi、Apache Flink、Striim、StreamSets）或位于小型、廉价的 EC2 服务器上的您自己的代码来处理事件。如果您直接将事件发送到 Lambda，则没有这种灵活性。

将此模式应用于数据库也更困难。对于文件，事件往往较少，因为每个事件代表一大块数据（文件），并且很容易定义一个流程“当我获取文件时，执行此操作，然后结束”。

当您有来自应用程序数据库的更改流时，这会更加困难。启动和停止进程会产生开销，如果您不断收到变化流，您不希望为每个事件启动的进程。您通常需要一个长期运行的进程来消耗事件并将它们作为连续流进行处理。

较终，这两种方法都可以用于事件驱动的文件摄取，但较好使用队列进行数据库更改。

结论

我在这里介绍了一些不同的模式，用于从数据库和文件捕获和集成事件驱动的数据。对于数据库，您可以修改后端代码以在数据库之前通过 API 调用发出事件，或者选择更改数据捕获工具来监视数据库日志文件并在数据库之后发出有关更改的事件。对于文件，您可以使用云原生消息服务将事件发送到消息队列或直接使用无服务器函数触发进程。

较终，这些方法中的任何一种都将帮助您较大限度地减少源数据系统的负载，并在数据到达数据消耗流程时提高数据的新鲜度。

当然，并非每个用例都需要新鲜数据。例如，商业智能 (BI) 报告通常可以每天​​批量生成。但实时运营分析、产品内分析、实时个性化和异常检测、智能库存管理和游戏等运营和面向用户的功能确实需要新鲜数据。如果您使用基于轮询的方法从源系统捕获数据，则您根本无法访问新数据，并且无法执行这些用例。他们简直是不可能的。

如果您正在尝试构建任何这些实时用例，或者正在评估可帮助您转向事件驱动架构和实时数据处理的工具，您还应该考虑尝试一下Tinybird。Tinybird 可让您统式和批处理数据源，使用 SQL 连接和转换它们，并以高并发、低延迟的 API 形式与内部利益相关者快速共享您的实时数据产品。Tinybird构建计划是的，没有时间限制，甚至还有模拟数据流工作流程，以防您只是为了学习该工具而不想自带数据。