概覽
Kafka Connect 是一種用於在 Apache Kafka 和其他系統之間可擴展且可靠地流式傳輸數據的工具。 它使快速定義將大量數據移入和移出 Kafka 的連接器變得簡單。 Kafka Connect 可以攝取整個數據庫或從所有應用程序服務器收集指標到 Kafka 主題中，使數據可用於低延遲的流處理。 導出作業可以將數據從 Kafka 主題傳送到二級存儲和查詢系統或批處理系統進行離線分析。
Kafka Connect有什麼優勢：
- 數據中心管道 - 連接使用有意義的數據抽象來拉或推數據到Kafka。
- 靈活性和可伸縮性 - Connect可以在單個節點(獨立)上與面向流和批處理的系統一起運行，也可以擴展到整個集羣的服務(分佈式)。
- 可重用性和可擴展性 - Connect利用現有的連接器或對其進行擴展，以適應您的需要，並縮短生產時間。
Kafka Connect專注於Kafka之間的數據流，讓你可以更簡單地編寫高質量、可靠和高性能的連接器插件。Kafka Connect還使框架能夠保證使用其他框架很難做到的事情。當與Kafka和流處理框架結合時，Kafka Connect是ETL管道的一個不可或缺的組件。
爲了更有效地討論Kafka Connect的內部工作原理，我們需要建立幾個主要的概念。
- Connector：通過管理任務來協調數據流的高級抽象
- Tasks：描述如何從Kafka複製數據
- Workers：執行連接器和任務的運行進程
- Converters：用於在 Connect 和發送或接收數據的系統之間轉換數據的代碼
- Transforms：改變由連接器產生或發送到連接器的每條消息的簡單邏輯
- Dead Letter Queue：Connect 如何處理連接器錯誤
Connector
Kafka Connect 中的連接器定義了數據應該複製到哪裏和從哪裏複製。 連接器實例是一個邏輯作業，負責管理 Kafka 和另一個系統之間的數據複製。 連接器實現或使用的所有類都在連接器插件中定義。 連接器實例和連接器插件都可以稱爲“連接器”。
Kafka Connect可以很容易地將數據從多個數據源流到Kafka，並將數據從Kafka流到多個目標。Kafka Connect有上百種不同的連接器。其中最流行的有:
- RDBMS (Oracle, SQL Server, DB2, Postgres, MySQL)
- Cloud Object stores (Amazon S3, Azure Blob Storage, Google Cloud Storage)
- Message queues (ActiveMQ, IBM MQ, RabbitMQ)
- NoSQL and document stores (Elasticsearch, MongoDB, Cassandra)
- Cloud data warehouses (Snowflake, Google BigQuery, Amazon Redshift)
Tasks
任務是 Connect 數據模型中的主要參與者。 每個連接器實例協調一組實際複製數據的任務。 通過允許連接器將單個作業分解爲多個任務，Kafka Connect 以很少的配置提供了對並行性和可擴展數據複製的內置支持。 這些任務中沒有存儲狀態。 任務狀態存儲在 Kafka 中的特殊主題 config.storage.topic 和 status.storage.topic 中，並由關聯的連接器管理。 因此，可以隨時啓動、停止或重新啓動任務，以提供彈性、可擴展的數據管道。
任務再平衡
當連接器首次提交到集羣時，workers會重新平衡集羣中的全套連接器及其任務，以便每個workers擁有大致相同的工作量。 當連接器增加或減少它們需要的任務數量時，或者當連接器的配置發生更改時，也會使用相同的重新平衡過程。 當workers失敗時，任務會在活動工作人員之間重新平衡。 當任務失敗時，不會觸發重新平衡，因爲任務失敗被視爲例外情況。 因此，失敗的任務不會由框架自動重新啓動，而應通過 REST API 重新啓動。
Workers
連接器和任務是工作的邏輯單元，必須安排在流程中執行。 Kafka Connect 將這些進程稱爲Worker，並且有兩種類型的worker：獨立的和分佈式的。
獨立的workers
獨立模式是最簡單的模式，其中一個進程負責執行所有連接器和任務。
由於它是單個進程，因此需要最少的配置。 獨立模式便於入門、開發期間以及某些只有一個進程有意義的情況，例如從主機收集日誌。 但是，因爲只有一個進程，所以它的功能也更有限：可擴展性僅限於單個進程，除了您添加到單個進程的任何監控之外，沒有容錯能力。
分佈式workers
分佈式模式爲 Kafka Connect 提供了可擴展性和自動容錯能力。 在分佈式模式下，您使用相同的 group.id 啓動許多工作進程，它們會自動協調以安排所有可用workers之間的連接器和任務的執行。 如果您添加workers、關閉workers或workers意外失敗，其餘workers會檢測到這一點並自動協調以在更新的可用workers之間重新分配連接器和任務。 請注意與消費者組重新平衡的相似性。 在後臺，連接workers正在使用消費者羣體進行協調和重新平衡。
具有相同 group.id 的所有工作人員將在同一個連接集羣中。 例如，如果worker-a 的group.id=connect-cluster-a 和worker-b 的group.id 相同，則worker-a 和worker-b 將組成一個名爲connect-cluster-a 的集羣。
Converters
在向 Kafka 寫入或從 Kafka 讀取數據時，轉換器是必要的，以使 Kafka Connect 部署支持特定的數據格式。 任務使用轉換器將數據格式從字節更改爲 Connect 內部數據格式，反之亦然。
轉換器與連接器本身分離，以允許自然地在連接器之間重用轉換器。 例如，使用相同的 Avro 轉換器，JDBC Source Connector 可以將 Avro 數據寫入 Kafka，而 HDFS Sink Connector 可以從 Kafka 讀取 Avro 數據。 這意味着可以使用相同的轉換器，例如，JDBC 源返回一個最終作爲 parquet 文件寫入 HDFS 的 ResultSet。
下圖顯示了在使用 JDBC 源連接器從數據庫讀取、寫入 Kafka 以及最後使用 HDFS 接收器連接器寫入 HDFS 時如何使用轉換器。
Transforms
連接器可以配置轉換以對單個消息進行簡單和輕量級的修改。這對於細微的數據調整和事件路由很方便，並且可以在連接器配置中將多個轉換鏈接在一起。
轉換是一個簡單的函數，它接受一個記錄作爲輸入並輸出一個修改過的記錄。 Kafka Connect 提供的所有轉換都執行簡單但通常有用的修改。請注意，您可以使用自己的自定義邏輯實現 Transformation 接口，將它們打包爲 Kafka Connect 插件，並將它們與任何連接器一起使用。
當轉換與源連接器一起使用時，Kafka Connect 將連接器生成的每個源記錄傳遞給第一個轉換，它進行修改並輸出新的源記錄。這個更新的源記錄然後被傳遞到鏈中的下一個轉換，它生成一個新的修改源記錄。這對於剩餘的變換繼續。最終更新的源記錄轉換爲二進制形式寫入Kafka。
轉換也可以與接收器連接器一起使用。 Kafka Connect 從 Kafka 讀取消息並將二進制表示轉換爲接收器記錄。如果有轉換，Kafka Connect 將通過第一個轉換傳遞記錄，該轉換進行修改並輸出一個新的、更新的接收器記錄。更新後的接收器記錄然後通過鏈中的下一個轉換，生成新的接收器記錄。對於剩餘的轉換，這將繼續，然後將最終更新的接收器記錄傳遞給接收器連接器進行處理。
Dead Letter Queue
由於多種原因，可能會出現無效記錄。 一個例子是當一條記錄到達以 JSON 格式序列化的接收器連接器時，但接收器連接器配置需要 Avro 格式。 當接收器連接器無法處理無效記錄時，將根據連接器配置屬性 errors.tolerance 處理錯誤。
死信隊列僅適用於接收器連接器。
此配置屬性有兩個有效值：none（默認）或 all。
當errors.tolerance 設置爲none 時，錯誤或無效記錄會導致連接器任務立即失敗並且連接器進入失敗狀態。 要解決此問題，您需要查看 Kafka Connect Worker 日誌以找出導致故障的原因、糾正它並重新啓動連接器。
當errors.tolerance 設置爲all 時，所有錯誤或無效記錄都將被忽略並繼續處理。 沒有錯誤寫入 Connect Worker 日誌。 要確定記錄是否失敗，您必須使用內部指標或計算源處的記錄數並將其與處理的記錄數進行比較。
Kafka Connect是如何工作的？
您可以將 Kafka Connect 部署爲在單臺機器上運行作業的獨立進程（例如日誌收集），也可以部署爲支持整個組織的分佈式、可擴展、容錯服務。 Kafka Connect 提供了低門檻和低運營開銷。 您可以從小規模的獨立環境開始進行開發和測試，然後擴展到完整的生產環境以支持大型組織的數據管道。
Kafka Connect包括兩個部分：
- Source連接器 – 攝取整個數據庫並將表更新流式傳輸到 Kafka 主題。 源連接器還可以從所有應用程序服務器收集指標並將這些指標存儲在 Kafka 主題中，從而使數據可用於低延遲的流處理。
- Sink 連接器——將數據從 Kafka 主題傳送到二級索引（例如 Elasticsearch）或批處理系統（例如 Hadoop）以進行離線分析。
Kafka Connect使用場景
任何時候，當你想把數據從另一個系統流到Kafka，或者把數據從Kafka流到其他地方，Kafka Connect應該是你的第一個調用端口。下面是一些使用Kafka Connect的常見方式:
流數據管道
Kafka Connect 可用於從事務數據庫等源中攝取實時事件流，並將其流式傳輸到目標系統進行分析。 由於 Kafka 將數據存儲到每個數據實體（主題）的可配置時間間隔內，因此可以將相同的原始數據向下傳輸到多個目標。 這可能是針對不同的業務需求使用不同的技術，或者將相同的數據提供給擁有自己的系統來保存數據的業務中的不同領域。
從應用程序寫入數據存儲
在您的應用程序中，您可以創建要寫入目標系統的數據。 這可能是一系列要寫入文檔存儲的日誌事件，也可能是要持久保存到關係數據庫的數據。 通過將數據寫入 Kafka 並使用 Kafka Connect 負責將數據寫入目標，您可以簡化佔用空間。
將舊系統遷往新系統
在 NoSQL 存儲、事件流平臺和微服務等較新的技術出現之前，關係數據庫 (RDBMS) 是應用程序中所有數據的實際寫入位置。 RDBMS 在我們構建的系統中仍然扮演着非常重要的角色——但並非總是如此。 有時我們會希望使用 Kafka 作爲獨立服務之間的消息代理以及永久的記錄系統。 這兩種方法非常不同，但與過去的技術變革不同，它們之間存在一條無縫的路線。
通過利用變更數據捕獲 (CDC)，可以近乎實時地將數據庫中的每個 INSERT、UPDATE 甚至 DELETE 提取到 Kafka 中的事件流中。 CDC 對源數據庫的影響非常小，這意味着現有應用程序可以繼續運行（並且不需要對其進行任何更改），同時可以構建新應用程序，由從數據庫捕獲的事件流驅動。 當原始應用程序在數據庫中記錄某些內容時（例如，訂單被接受），任何訂閱 Kafka 事件流的應用程序都將能夠根據事件採取行動，例如新的訂單履行服務。
使您的系統實現實時性
許多組織的數據庫中都有靜態數據，例如 Postgres、MySQL 或 Oracle，並且可以使用 Kafka Connect 從現有數據中獲取價值，將其轉換爲事件流。 您可以在流管道示例中看到這一點，使用現有數據推動分析。
爲什麼要使用Kafka Connect而不是自己寫一個連接器呢？
Apache Kafka 擁有自己非常強大的生產者和消費者 API 以及支持多種語言的客戶端庫，包括 C/C++、Java、Python 和 Go。 因此，您想知道爲什麼不直接編寫自己的代碼從系統中獲取數據並將其寫入 Kafka 是非常正確的——編寫一小段消費者代碼以從系統讀取數據是否有意義？ 主題並將其推送到目標系統？
問題是，如果您要正確地執行此操作，那麼您將意識到您需要滿足故障、重新啓動、日誌記錄、彈性擴展和再次縮減以及跨多個節點運行的需求。 那是在我們考慮序列化和數據格式之前。 一旦你完成了所有這些事情，你就編寫了一些可能更像 Kafka Connect 的東西，但沒有多年的開發、測試、生產驗證和社區。
與 Kafka 的流式集成是一個已解決的問題。 可能存在一些適合定製解決方案的邊緣情況，但總的來說，您會發現 Kafka Connect 應該是您與 Kafka 集成的第一個有效工具。