我們遇到了問題。數(shù)據(jù)集成領域以基于輪詢的 ETL 管道為主，這些管道按計劃運行并發(fā)起與源數(shù)據(jù)系統(tǒng)的通信。這種模式很普遍；各行業(yè)各種規(guī)模的公司都在使用它。

為什么這是個問題？其實有兩個：

1. 增加了源數(shù)據(jù)系統(tǒng)的負載：在許多情況下，源系統(tǒng)是應用程序數(shù)據(jù)庫，ETL 工具查詢該數(shù)據(jù)庫以獲取數(shù)據(jù)的更改。
   通常使用“增量”方法來僅選擇自上次輪詢以來已更改的數(shù)據(jù)，并且您可能會認為這種方法可以較大限度地減少這些查詢掃描的數(shù)據(jù)量。然而，在很多情況下，你都錯了。
   
   實際上，這些查詢通常會掃描整個表。這是因為源系統(tǒng)的索引通常與 ETL 工具用于過濾數(shù)據(jù)的鍵不匹配，因此查詢經(jīng)常對數(shù)據(jù)庫進行完整掃描以搜索新行，即使它只返回一小部分子集。
   因此，雖然由于查詢結(jié)果集較小，采用增量方法您的網(wǎng)絡和存儲負載可能會更小，但您的應用程序數(shù)據(jù)庫仍然支持全表掃描。您較終可能會給數(shù)據(jù)庫帶來巨大的負載，這較多只會降低其所支持的應用程序的體驗。更糟糕的是，您將看到天價的計算費用。
2. 您可能認為從數(shù)據(jù)庫中提取更改的增量方法會很有效，但在許多情況下，這些查詢?nèi)匀粫呙枵麄€表。

1. 變更數(shù)據(jù)并不新鮮。根據(jù)定義，基于輪詢的 ETL 按計劃運行，因此一旦作業(yè)完成就會立即過時。在較好的情況下，這些作業(yè)每小時運行一次。更常見的是，它們每 12 到 24 小時運行一次。
   您可以較大限度地縮短輪詢作業(yè)之間的時間以使事情變得更新鮮，但現(xiàn)在您遇到了問題#1，并且您不能冒險關閉應用程序來支持您可能擁有的任何下游數(shù)據(jù)需求。
   因此，您根本無法支持依賴于實時數(shù)據(jù)的用例，例如面向用戶的分析、基于使用情況的計費、實時個性化引擎、實時欺詐檢測等。對于基于輪詢的 ETL 來說這是不可能的。
2. 基于輪詢的批量 ETL 會給源數(shù)據(jù)系統(tǒng)帶來過度的壓力，并導致過時的數(shù)據(jù)被加載到下游系統(tǒng)中。在這篇博文中，我重點介紹了幾種事件驅(qū)動的架構模式，作為基于輪詢的工作流程的替代方案。

在Tinybird，我們相信數(shù)據(jù)應該在發(fā)生時立即處理。時期。我們認為，數(shù)據(jù)和工程團隊應該使用專門適合處理和處理這些數(shù)據(jù)的工具，而不會給其他系統(tǒng)和資源增加過度的壓力。

在這篇博文中，我將重點介紹可以跨不同源數(shù)據(jù)系統(tǒng)實現(xiàn)的幾種不同的事件驅(qū)動架構模式，并討論這些實現(xiàn)的優(yōu)缺點。

切換到事件驅(qū)動架構

事件流、消息隊列和無服務器功能正在興起，一些開明的人正在從輪詢思維轉(zhuǎn)向新的范式：事件驅(qū)動架構。

事件驅(qū)動架構的概念非常簡單。數(shù)據(jù)幾乎總是為了響應某種事件而生成：用戶單擊按鈕、處理事務、上傳文件。為什么不使用這些事件來觸發(fā)實時數(shù)據(jù)攝取過程？

事件驅(qū)動架構背后的想法很簡單：使用事件觸發(fā)數(shù)據(jù)攝取過程。

事件驅(qū)動架構解決了上述兩個問題，并且它已經(jīng)作為繞過（或者更確切地說，并行）源數(shù)據(jù)系統(tǒng)的數(shù)據(jù)捕獲和集成的方法而受到關注。

事件驅(qū)動架構的示例用例

考慮一個幾乎適用于所有 B2C 業(yè)務和大多數(shù) B2B 業(yè)務的場景：您有一個面向用戶的應用程序，該應用程序構建在與 Postgres 或 MySQL 等應用程序數(shù)據(jù)庫通信的后端 API 之上。

當用戶在應用程序中執(zhí)行操作時，它會調(diào)用 API 并生成一些數(shù)據(jù)，然后將其推送到數(shù)據(jù)庫。隨著您的公司獲得關注并且應用程序添加了更多用戶和更多功能，您開始擴展數(shù)據(jù)庫，拼命努力跟上來自 API 的單行插入頻率的增加。

然后營銷部門的一些笨蛋想要對這些數(shù)據(jù)進行分析。因此，您在晚上大多數(shù)用戶都在睡覺并且應用程序數(shù)據(jù)庫服務器有一些額外周期時運行批量導出，然后將新數(shù)據(jù)復制到數(shù)據(jù)倉庫。這很常見。大多數(shù)公司都是這樣做的。

這就是您遇到這兩個問題的地方。批處理作業(yè)會給數(shù)據(jù)庫帶來額外的負載，并且較終會得到陳舊的數(shù)據(jù)。如果您嘗試更頻繁地運行該作業(yè)來進行補償，則會增加負擔。這是一個無法通過批量 ETL 解決的第 22 條軍規(guī)。

批處理作業(yè)會給數(shù)據(jù)庫帶來額外的負載，并且較終會得到陳舊的數(shù)據(jù)。如果您嘗試更頻繁地運行該作業(yè)來進行補償，則會增加負擔。這是一個無法通過批量 ETL 解決的第 22 條軍規(guī)。

那么如何才能避免這兩個問題并且仍然讓營銷人員滿意呢？

關鍵是在數(shù)據(jù)到達應用程序數(shù)據(jù)庫之前（或同時）將數(shù)據(jù)獲取到倉庫。在這種情況下，您已經(jīng)有一個事件：API 調(diào)用。您可以利用這一點，將事件及其數(shù)據(jù)推送到消息隊列，同時后端將其插入應用程序數(shù)據(jù)庫。

通過這種事件驅(qū)動的方法，您完全稍后從應用程序數(shù)據(jù)庫中提取此數(shù)據(jù)；它已經(jīng)在消息隊列中了。

事件驅(qū)動方法的關鍵是在數(shù)據(jù)到達應用程序數(shù)據(jù)庫之前（或同時）將數(shù)據(jù)獲取到倉庫。

這是一種非常有效的模式，因為數(shù)據(jù)已經(jīng)生成并存儲在后端的內(nèi)存中。您只需將其發(fā)送到另一個端點即可。

但是，與所有模式一樣，有一個缺點：您必須對應用程序的后端進行代碼更改。這項工作通常被推給負責后端的軟件工程師，而不是管理數(shù)據(jù)（庫）的團隊。

這可能會給您的組織帶來挑戰(zhàn)，也可能不會。如果軟件團隊積壓了問題，這可能不是優(yōu)先考慮的事情。這完全取決于他們的移動速度以及您可以等待多長時間。

變更數(shù)據(jù)捕獲怎么樣？

變更數(shù)據(jù)捕獲(CDC) 是事件驅(qū)動架構中經(jīng)過驗證的實現(xiàn)，您可以使用它來避免在不接觸后端的情況下加載數(shù)據(jù)庫，它有其優(yōu)點和缺點。

使用 CDC，您可以訂閱數(shù)據(jù)庫中所做更改（例如插入、更新和刪除）的日志，并將這些更改推送到其他地方。如果您不適合對 API 進行代碼更改，那么 CDC 是在應用程序數(shù)據(jù)庫之外構建事件驅(qū)動管道的好方法。

大多數(shù)應用程序數(shù)據(jù)庫都會創(chuàng)建對數(shù)據(jù)庫執(zhí)行的操作的日志。對于某些數(shù)據(jù)庫，此日志是數(shù)據(jù)庫架構的核心部分，例如 Postgres 的預寫日志（WAL）。對于其他人來說，這是一個需要啟用的單獨功能，就像 MySQL 的 bin 日志一樣。

無論哪種情況，其想法都基本相同。日志是數(shù)據(jù)庫更改（例如插入、更新、刪除）及其數(shù)據(jù)的僅附加文件。每個操作都按時間順序附加為新行，這意味著您只需從頂部開始并逐一重播每個事件，即可使用日志在準確的時刻重建數(shù)據(jù)庫的狀態(tài)。

CDC 工具會監(jiān)視此日志文件中的新行，將每個更改操作捕獲為一個事件，并將這些事件推送到其他地方。將這些事件推送到僅附加事件流系統(tǒng)（例如 Apache Kafka）的情況尤其常見。然后可以將更改操作推送到所需的下游系統(tǒng)，例如分析 (OLAP) 數(shù)據(jù)庫。

如果您不能或不想更新現(xiàn)有的 API 代碼，則更改數(shù)據(jù)捕獲是一種有吸引力的策略。擁有數(shù)據(jù)庫的團隊通常擁有 CDC 實現(xiàn)，并且有像 Debezium 這樣的開源框架，使得啟動和運行相對簡單。

由于此策略僅涉及監(jiān)視日志文件，因此它比對數(shù)據(jù)庫運行增量查詢要輕得多。新行會立即附加到日志文件中，因此可以近乎實時地訪問它們，從而將延遲保持在較低限度。

當您的后端工程團隊無法或不想更新后端 API 以與數(shù)據(jù)庫寫入并行地將事件發(fā)送給下游消費者時，變更數(shù)據(jù)捕獲系統(tǒng)是事件驅(qū)動架構的一個很好的替代方案。

然而，這并不全是陽光和雛菊。雖然讀取日志文件是輕量級的，但它仍然需要服務器上的額外代理進程，這確實增加了負載。在擴展應用程序數(shù)據(jù)庫時，它增加了另一層考慮因素，因為您必須考慮增加的流量將如何影響該代理所需的資源。

它還引入了您的團隊可能不熟悉的全新技術。雖然這些工具被廣泛采用且易于上手，但隨著規(guī)模的擴大或偏離常規(guī)，它們可能會變得難以理解。

這兩種策略都沒有錯，較終結(jié)果基本相同：來自應用程序堆棧的實時更改流。由您決定較佳方法。

事件驅(qū)動架構不僅僅適用于數(shù)據(jù)庫

當然，并非每個數(shù)據(jù)攝取場景都涉及應用程序數(shù)據(jù)庫。也許甚至不是大多數(shù)。在這種情況下，數(shù)據(jù)庫中的行與生成的事件之間可能不具有 1:1 的關系。在許多情況下，您實際上可能會以文件形式接收數(shù)據(jù)，這些數(shù)據(jù)要么是從內(nèi)部服務推送的，要么是從外部數(shù)據(jù)供應商收集的。事件驅(qū)動架構可以像數(shù)據(jù)庫一樣應用于文件系統(tǒng)。

在過去（實際上，今天仍然很常見），數(shù)據(jù)生產(chǎn)者或經(jīng)紀人會建立一個大型文件傳輸協(xié)議（FTP）服務器并將文件轉(zhuǎn)儲到一個大型存儲服務器上。他們向客戶提供 FTP 憑據(jù)，客戶端將在每天運行的 bash 腳本中使用該憑據(jù)來查找新文件并將其復制到內(nèi)部共享存儲中。這是一個奇特的小工作流程，多年來一直發(fā)揮其作用。

但是，除了過時之外，它還存在一些問題：

1. 必須有人維護龐大的存儲服務。任何數(shù)據(jù)生產(chǎn)者或經(jīng)紀人都需要構建和維護自己的內(nèi)部文件存儲系統(tǒng)。這是昂貴且痛苦的。
2. FTP 不靈活或可擴展。FTP 不是一個特別靈活的協(xié)議，尤其是當您下載大文件時，網(wǎng)絡故障可能會導致傳輸中斷，您必須從頭開始。它也很難擴展，因此通常很慢。由于許多客戶端同時連接并嘗試下載文件，速度很快就會變得緩慢。
3. FTP 已經(jīng)過時且不靈活，但至今仍被廣泛使用。

事件驅(qū)動數(shù)據(jù)管道的好處在于它們非常靈活，可以適應許多用例、許多源數(shù)據(jù)系統(tǒng)以及下游數(shù)據(jù)消費者的許多不同需求。它們可以像數(shù)據(jù)庫一樣用于文件，盡管使用的是不同的工具集。

現(xiàn)代云供應商使事件驅(qū)動的文件攝取變得簡單

時代變了，現(xiàn)在我們擁有容錯、可擴展且經(jīng)濟的文件存儲服務，例如 Amazon S3 和 Google Cloud Storage。

這些服務不僅使用起來比 FTP 更有趣，而且還使得使用事件驅(qū)動的架構來分發(fā)和使用文件成為可能。而不是不斷地輪詢存儲服務來詢問“新文件是否到達？” 或者等待一整天然后說“給我昨天到達的所有文件”，存儲服務本身可以創(chuàng)建有關新文件的通知并將它們推送到消息隊列，就像在數(shù)據(jù)庫的事件驅(qū)動架構中一樣。

然后，下游消費者可以簡單地訂閱消息隊列，并在收到通知時去獲取文件。

托管在云供應商的對象存儲中的文件可以利用云原生通知服務來通知下游消費者有新的或修改的文件。

這種模式非常有用，有以下幾個原因：

1. 它比 FTP 更強大。您不必擔心維護 FTP 服務器或您自己的文件存儲系統(tǒng)。您不必擔心網(wǎng)絡故障或客戶端連接速度慢。您不必擔心如何處理遲到的文件或已重新上傳的文件以修復數(shù)據(jù)中的錯誤。存儲服務和消息隊列讓這些痛苦大部分神奇地消失了。
2. 它增加了數(shù)據(jù)的新鮮度。當然，如果您正在處理文件，您永遠不會擁有較新的數(shù)據(jù)，因為它們已經(jīng)全部批處理到文件中......但您至少可以在文件準備好后立即獲取文件，而不是幾個小時或幾天后。

您可以看到這如何反映應用程序數(shù)據(jù)庫的場景。源數(shù)據(jù)系統(tǒng)不同，但實現(xiàn)和好處非常相似。

由于這些現(xiàn)代云存儲服務內(nèi)置了事件通知，只需單擊一下即可啟用，因此設置事件驅(qū)動的文件攝取非常容易。數(shù)據(jù)創(chuàng)建者幾乎不需要做額外的工作，數(shù)據(jù)消費者可以利用無服務器服務，從而輕松采用這種新模式。

例如，Amazon 有 SQS 和 SNS，可用于對這些事件進行排隊，然后您可以附加任意數(shù)量的工具來響應事件并處理文件。例如，您可以使用 Apache NiFi 處理在 SQS 中排隊的 S3 事件通知。

消息隊列：靈活、耐用、

因此，無論您使用數(shù)據(jù)庫還是文件作為源數(shù)據(jù)系統(tǒng)，您都可以采用這些新模式來實現(xiàn)事件驅(qū)動架構。您可以發(fā)出事件，而不是輪詢數(shù)據(jù)庫或文件存儲以獲取更改。

但你應該如何處理這些事件呢？

實際上，你有兩個選擇：

1. 將事件放在消息隊列或事件流平臺上，或者
2. 讓事件直接觸發(fā)流程

在上述事件驅(qū)動模式中，我特別提到了選項 #1。這是模式，也是大多數(shù)人選擇的模式。

為什么？消息隊列是一種持久、靈活且的數(shù)據(jù)到達方式。消息隊列的優(yōu)點有兩個：

首先，您通過以下方式解決我們開始的兩個問題：

1. 將下游用例與源數(shù)據(jù)系統(tǒng)解耦，以及
2. 數(shù)據(jù)生成后立即交付給消費者。

其次，大多數(shù)消息隊列允許任意數(shù)量的下游消費者連接并訂閱新消息。因此，如果 4 個不同的團隊構建 8 個不同的東西，想要以 16 種不同的方式訪問數(shù)據(jù)，他們就可以各自完成自己的事情，而不會互相干擾。

消息隊列并不是處理事件驅(qū)動的實時數(shù)據(jù)攝取的方法，但它們是迄今為止較受歡迎的方法，因為它們將源數(shù)據(jù)與消費者解耦，并且足夠靈活，可以同時處理許多不同的消費者。

如果團隊只想每天獲取更改，他們可以批量使用昨天的消息。但是，如果另一個團隊想要實時使用消息，他們可以監(jiān)視新消息并在數(shù)據(jù)到達時自動觸發(fā)其流程。

該模型非常適合數(shù)據(jù)庫和文件，但它確實需要額外的中介服務。隨著事件驅(qū)動架構和實現(xiàn)的增長，您可能會投入大量資源來維護和擴展消息隊列或事件流平臺?？紤]到事件驅(qū)動架構所實現(xiàn)的所有實時用例，這可能是一個值得的權衡。

那么，您可以跳過隊列嗎？

是的，您可以跳過隊列

在某些情況下，您可以讓事件直接觸發(fā)流程。例如，您可以將 Amazon S3 配置為直接觸發(fā) AWS Lambda 函數(shù)，從而允許您立即處理單個事件。您可以使用其他處理框架（例如 Apache NiFi 或 Apache Flink）復制此模型。

現(xiàn)在，這種方法有利有弊。較大的優(yōu)點是您可以省去另一個中間服務，因此它既便宜又簡單。當您立即調(diào)用處理函數(shù)時，您還可以較大限度地減少延遲并保持數(shù)據(jù)新鮮度。

更簡單的用例，您可以跳過消息隊列并使用無服務器函數(shù)根據(jù)源文件系統(tǒng)中的更新立即觸發(fā)進程。

然而，也有缺點。消息隊列提供了您在處理框架中可能無法獲得的持久性級別，這可能會使處理故障變得更加困難。

你也會失去一些靈活性。由于您避開了“發(fā)布/訂閱”模型，因此您可能會直接將事件發(fā)送到單個處理器，而不是將它們發(fā)布到多個處理器可以根據(jù)需要進行訂閱的隊列。

例如，如果您將事件發(fā)送到 SQS，您可以連接一堆不同的工具（例如 Apache NiFi、Apache Flink、Striim、StreamSets）或位于小型、廉價的 EC2 服務器上的您自己的代碼來處理事件。如果您直接將事件發(fā)送到 Lambda，則沒有這種靈活性。

將此模式應用于數(shù)據(jù)庫也更困難。對于文件，事件往往較少，因為每個事件代表一大塊數(shù)據(jù)（文件），并且很容易定義一個流程“當我獲取文件時，執(zhí)行此操作，然后結(jié)束”。

當您有來自應用程序數(shù)據(jù)庫的更改流時，這會更加困難。啟動和停止進程會產(chǎn)生開銷，如果您不斷收到變化流，您不希望為每個事件啟動的進程。您通常需要一個長期運行的進程來消耗事件并將它們作為連續(xù)流進行處理。

較終，這兩種方法都可以用于事件驅(qū)動的文件攝取，但較好使用隊列進行數(shù)據(jù)庫更改。

結(jié)論

我在這里介紹了一些不同的模式，用于從數(shù)據(jù)庫和文件捕獲和集成事件驅(qū)動的數(shù)據(jù)。對于數(shù)據(jù)庫，您可以修改后端代碼以在數(shù)據(jù)庫之前通過 API 調(diào)用發(fā)出事件，或者選擇更改數(shù)據(jù)捕獲工具來監(jiān)視數(shù)據(jù)庫日志文件并在數(shù)據(jù)庫之后發(fā)出有關更改的事件。對于文件，您可以使用云原生消息服務將事件發(fā)送到消息隊列或直接使用無服務器函數(shù)觸發(fā)進程。

較終，這些方法中的任何一種都將幫助您較大限度地減少源數(shù)據(jù)系統(tǒng)的負載，并在數(shù)據(jù)到達數(shù)據(jù)消耗流程時提高數(shù)據(jù)的新鮮度。

當然，并非每個用例都需要新鮮數(shù)據(jù)。例如，商業(yè)智能 (BI) 報告通?？梢悦刻??批量生成。但實時運營分析、產(chǎn)品內(nèi)分析、實時個性化和異常檢測、智能庫存管理和游戲等運營和面向用戶的功能確實需要新鮮數(shù)據(jù)。如果您使用基于輪詢的方法從源系統(tǒng)捕獲數(shù)據(jù)，則您根本無法訪問新數(shù)據(jù)，并且無法執(zhí)行這些用例。他們簡直是不可能的。

如果您正在嘗試構建任何這些實時用例，或者正在評估可幫助您轉(zhuǎn)向事件驅(qū)動架構和實時數(shù)據(jù)處理的工具，您還應該考慮嘗試一下Tinybird。Tinybird 可讓您統(tǒng)式和批處理數(shù)據(jù)源，使用 SQL 連接和轉(zhuǎn)換它們，并以高并發(fā)、低延遲的 API 形式與內(nèi)部利益相關者快速共享您的實時數(shù)據(jù)產(chǎn)品。Tinybird構建計劃是的，沒有時間限制，甚至還有模擬數(shù)據(jù)流工作流程，以防您只是為了學習該工具而不想自帶數(shù)據(jù)。