Kafka：消費者 API 與 Streams API

Question

我最近開始學習 Kafka 並最終解決了這些問題。

1. 消費者和流之間有什么區別？ 對我來說，如果任何工具/應用程序消費來自 Kafka 的消息，那么它就是 Kafka 世界中的消費者。

2. Stream 有什么不同，因為它也從 Kafka 消費或向 Kafka 生產消息？ 為什么需要它，因為我們可以使用消費者 API 編寫自己的消費者應用程序並根據需要處理它們或將它們從消費者應用程序發送到 Spark？

我在這方面做了谷歌，但沒有得到任何好的答案。 對不起，如果這個問題太微不足道了。

Answer 1

2021 年 1 月更新：我寫了一個關於 Kafka 基礎知識的四部分博客系列，我建議閱讀這些問題。 對於這個問題，請查看有關處理基礎知識的第 3 部分。

2018 年 4 月更新：現在您還可以使用ksqlDB （Kafka 的事件流數據庫）來處理 Kafka 中的數據。 ksqlDB 建立在 Kafka 的 Streams API 之上，它也提供一流的 Streams 和 Tables 支持。

消費者 API 和 Streams API 有什么區別？

Kafka 的 Streams 庫 ( https://kafka.apache.org/documentation/streams/ ) 建立在 Kafka 生產者和消費者客戶端之上。 與普通客戶端相比，Kafka Streams 明顯更強大，也更具表現力。

與普通消費者相比，使用 Kafka Streams 編寫從頭到尾的實際應用程序要簡單得多，速度也更快。

以下是 Kafka Streams API 的一些功能，其中大部分功能不受消費者客戶端支持（這需要您自己實現缺失的功能，基本上是重新實現 Kafka Streams）。

• 通過 Kafka 事務支持一次性處理語義（ EOS 是什么意思）
• 支持容錯有狀態（當然也包括無狀態）處理，包括流連接、 聚合和窗口。 換句話說，它支持開箱即用地管理應用程序的處理狀態。
• 支持事件時間處理以及基於處理時間和攝取時間的處理。 它還可以無縫處理亂序數據。
• 對流和表都有一流的支持，這是流處理與數據庫的結合； 在實踐中，大多數流處理應用程序都需要流和表來實現它們各自的用例，所以如果流處理技術缺少這兩個抽象中的任何一個（比如，不支持表），你要么被卡住，要么必須自己手動實現這個功能（祝你好運...）
• 支持交互式查詢（也稱為“可查詢狀態”）以通過請求-響應 API 向其他應用程序和服務公開最新的處理結果。 這對於只能執行請求-響應，而不能執行流式處理的傳統應用程序尤其有用。
• 更具表現力：它附帶 (1) 具有map 、 filter 、 reduce等操作的函數式編程風格DSL以及 (2) 用於執行復雜事件處理 (CEP) 的命令式處理器 API ，以及 (3) 您甚至可以結合 DSL 和 Processor API。
• 擁有自己的單元和集成測試測試套件。

請參閱http://docs.confluent.io/current/streams/introduction.html以獲取對 Kafka Streams API 的更詳細但仍然高級的介紹，這也應該有助於您了解與較低級別的 Kafka 消費者的區別客戶。

除了 Kafka Streams，您還可以使用流數據庫ksqlDB來處理 Kafka 中的數據。 ksqlDB 將其存儲層 (Kafka) 與其計算層（ksqlDB 本身；這里的大部分功能使用 Kafka Streams）分開。 它支持與 Kafka Streams 基本相同的功能，但您編寫流式 SQL 語句而不是 Java 或 Scala 代碼。 您可以通過 UI、CLI 和 REST API 與 ksqlDB 交互； 它還有一個本地 Java 客戶端，以防您不想使用 REST。 最后，如果您不想自行管理基礎設施， ksqlDB 可作為Confluent Cloud 中 的完全托管服務使用。

那么 Kafka Streams API 有什么不同，因為它也從 Kafka 消費或向 Kafka 生產消息？

是的，Kafka Streams API 既可以讀取數據，也可以向 Kafka 寫入數據。 它支持 Kafka 事務，因此您可以例如從一個或多個主題讀取一條或多條消息，如果需要，可選擇更新處理狀態，然后將一條或多條輸出消息寫入一個或多個主題——全部作為一個原子操作。

為什么需要它，因為我們可以使用消費者 API 編寫自己的消費者應用程序並根據需要處理它們或將它們從消費者應用程序發送到 Spark？

是的，您可以編寫自己的消費者應用程序——正如我提到的，Kafka Streams API 使用 Kafka 消費者客戶端（加上生產者客戶端）本身——但是您必須手動實現 Streams API 提供的所有獨特功能. 有關“免費”獲得的所有內容，請參閱上面的列表。 因此，用戶會選擇普通的消費者客戶端而不是更強大的 Kafka Streams 庫是一種罕見的情況。

Answer 2

為支持 ETL 類型的消息轉換而構建的 Kafka Stream 組件。 表示從主題輸入流，轉換並輸出到其他主題。 它支持實時處理，同時支持高級分析功能，如聚合、加窗、連接等。

“Kafka Streams 通過構建 Kafka 生產者和消費者庫並利用 Kafka 的本機功能來提供數據並行性、分布式協調、容錯和操作簡單性，從而簡化了應用程序開發。”

以下是 Kafka Stream 的關鍵架構特性。 請參考 這里

1. 流分區和任務：Kafka Streams 使用分區和任務的概念作為其基於 Kafka 主題分區的並行模型的邏輯單元。
2. 線程模型： Kafka Streams 允許用戶配置庫可用於在應用程序實例中並行處理的線程數。
3. 本地狀態存儲：Kafka Streams 提供了所謂的狀態存儲，可以被流處理應用程序用來存儲和查詢數據，這是實現有狀態操作時的重要能力
4. 容錯： Kafka Streams 建立在 Kafka 原生集成的容錯功能之上。 Kafka 分區具有高可用性和可復制性，因此當流數據持久化到 Kafka 時，即使應用程序失敗並需要重新處理它，它也是可用的。

根據我的理解，以下是關鍵差異，如果遺漏或誤導任何一點，我願意更新

在哪里使用消費者 - 生產者：

1. 如果有單個消費者，則消費消息進程但不溢出到其他主題。
2. 作為第 1 點，如果只有生產者生產消息，我們不需要 Kafka Stream。
3. 如果消費者消息來自一個 Kafka 集群，但發布到不同的 Kafka 集群主題。 在這種情況下，即使您可以使用 Kafka Stream，但您必須使用單獨的 Producer 將消息發布到不同的集群。 或者干脆使用 Kafka Consumer - Producer 機制。
4. 批處理 - 如果需要收集消息或進行批處理，則可以使用正常的傳統方式。

在哪里使用 Kafka Stream：

1. 如果您使用來自一個主題的消息，那么 Kafka Stream 最適合轉換並發布到其他主題。
2. 實時處理、實時分析和機器學習。
3. 聚合、連接窗口等狀態轉換。
4. 計划使用本地狀態存儲或已安裝的狀態存儲，例如 Portworx 等。
5. 實現完全一種處理語義和自動定義的容錯。

Answer 3

Streams 建立在 Consumer 和 Producer API 之上，因此可以在更高的層次上工作，這意味着

• Streams 更容易用於從主題讀取/處理/寫入到主題風格的任務
• Producer/Consumer 允許更多控制，並且可以在 Streams 無法處理的某些情況下使用

例如，Streams 自動處理事務提交，這意味着您無法控制提交的確切時間點（無論您使用 Streams DSL 還是 Processer API）。 相比之下，消費者/生產者 API 為您提供了這種控制。