Apache Kafka 是什麼？核心元件、優勢、常見使用案例一次看！
內容目錄
Kafka 是什麼？
Apache Kafka 是專為處理大數據而生的分布式資料串流平台，能輕鬆處理每秒數萬次的請求（Request）。相較其他消息佇列系統（Message Queue），Kafka 擁有更好的吞吐量，內建的分區（Partition）機制，和卓越的容錯能力，這使其被應用於各種大數據使用情境，例如即時資料分析、日誌聚合、消息傳遞和支援微服務架構。
本文將深入探討 Kafka 的基本概念、功能、架構和主流使用情境。
Kafka 解決了什麼問題？
在深入介紹 Kafka 之前，我們應先了解 Kafka 被用來解決什麼問題。許多發佈/訂閱系統經常在初期作為簡易消息佇列架構。以下圖為例，開發者只需架設 Web 伺服器、配合前端網頁、後端程式與資料庫串接，即可滿足大部分使用需求。
隨著 Web 系統使用規模增加，API 呼叫（Request）與資料庫存取頻率也會跟著提高，萬一系統缺乏有效的緩衝機制，資料庫很快就會承受過大的工作負載。
不止如此，當企業進入擴張期，必然產生用戶行為、業務狀態等資訊分析需求，這時系統就必須追加監控功能等額外應用程式。如果未能妥善規範資料流架構，系統結構將變得複雜、難以追蹤與管理。
為了解決上述困難，開發者可以將前端資料發佈到 Kafka、形成資料暫存區，再藉由後端程式從中訂閱資料。這麼一來，既能減緩資料庫負載，也能達到如下圖一樣較不複雜的系統架構。
Kafka 的資料管道（Data Pipeline）工作流程
綜觀整個資料處理架構，自資料來源導入系統的應用程式可稱作「輸入端」、取用資料的應用程式則稱為「輸出端」；Kafka 位於「輸入端」與「輸出端」之間，
一邊從「輸入端」接收資料，一邊分配資料到「輸出端」，完成後續的資料加工與傳遞作業。
Kafka 作為資料流的「管道」（Pipeline），可以讓資料流通於各類基礎架構、降低元件之間的耦合程度；這種架構有利於日後系統維運，即降低「輸出端」應用程式原始碼修改後，連帶影響其它元件設定值的修改成本。
Kafka 4 大核心元件
一、Events（事件）＆ 消息（Message）
在 Kafka 中，事件是帶有資料的消息。消息是 Kafka 中的最小資料單元，此概念類似於資料庫的 Row 和 Record。通常一個事件會回傳以下消息： Key、 Value、 Timestamp 以及 Meta Data Header。
以下為一個事件範例：當一位新訪客在網銀上匯款時，此匯款行為就會被視為一個事件，並回傳以下消息（Message）：匯款者姓名、值、時間戳。
- Event key: “Ethan”
- Event value: “向 Claire 支付 200 元”
- Event timestamp: “2023/05/06 3.30pm”
二、Topics（主題） & Partition（分區）
Kafka 會將每一條資料歸納在事先指定的 Topic 中，即每個 Topic 處理同一類型的資料；當生產者 (Producer) 指定目標 Topic 時，就代表提供了明確的資料分類標示。
Topic（主題）可以被理解為資料庫的資料表或檔案系統的資料夾，每條資料都具有值（Value）、鍵（Key）和標頭（Header）。Topic 作為資料訂閱、發佈的基本單位，不僅可以單純接收生產者發佈的資料，也可以接收一或多個消費者訂閱消息。
一個 Topic 可以區分為多個 Partition，從提交日誌紀錄（Log）的角度理解，每個 Partition 代表了各自紀錄的集合，一但資料發佈到 Kafka Topic，資料就會預設以「僅限追加」（Append-only）的方式加入 Partition 佇列末端，並加上 Offset（偏移值）來標記先後順序與資料傳輸進度。
Kafka 或 Zookeeper 會記錄每個 Partition 最後被訂閱的資料 Offset，因此即使消費端中斷與 Kafka 的連接並再次重新訂閱也不會遺失任何資料。
受到 Partition 結構影響，直接觀察 Kafka Topic 無法確認資料傳輸的具體順序，但如果觀察個別 Partition 就能發現資料按照寫入順序排列。
下圖是一個由 3 個 Partition 組成的 Topic，資料會進入每個 Partition 末端並被賦予 Offset。相同 Topic 所屬的 Partition 可以分布於不同主機，也就是說，Topic 可以跟隨需求、在多個伺服器進行水平擴展。
三、Producers（生產者）和 Consumer（消費者）
Kafka 的客戶端系統應用程式主要分為生產者和消費者。
Producer （生產者）
負責產生消息。在發布/訂閱系統中，它們被稱為發佈者或寫入端。生產者會在產生消息後將其寫入特定 Kafka Topic 中。通常生產者並不特別指定消息應寫入哪個 Partition，而是將其平均分佈到 Topic 中所有的 Partition 上。生產者的形式多樣，它可以是運行於網頁伺服器的應用程式、IoT 設備或監控程式等等。
當使用者登入購物網站時，他們的登入資訊、購物喜好以及瀏覽資訊都會作為消息發送到 Kafka Cluster 中。從這個例子可以看出，任何生成消息的實體都可以作為生產者。
Consumer（消費者）
負責讀取消息。它們在發佈/訂閱系統中可能被稱為訂閱者或讀取者。消費者能訂閱一到多個 Topic 並依照資料生產的順序進行讀取，此外，他們能藉由消息的 Offset 持續追蹤哪些消息已被讀取完畢。
根據系統架構，一個應用程式可以同時是生產者和消費者。例如：一個資料倉儲能從 Kafka 消費資料，將其整理後的結果再透過 Kafka 提供給 ML 或 AI 應用程式的消費者訂閱。一般來說，資料庫、資料湖泊和資料分析應用程式在 Kafka 中扮演消費者的角色，因為它們需要儲存並分析從 Kafka 接收到的資料。
另外，Kafka 還提供進階的客戶端 API，例如用於資料整合的 Kafka Connect API 以及整理串流的 Kafka Stream，這類進階客戶端會將生產者與消費者做為基石，並打造更高階的應用功能。
四、Broker（代理器） & Cluster（叢集）：
在 Kafka 中， Broker 可以被理解為組成叢集的單元。Broker 的主要職責是從生產者接收消息，為消息分配 Offset，並將消息儲存於硬碟系統。此外，Broker 也為消費者提供服務，負責處理 Partition 的串流讀取請求，並從硬碟中檢索並返回相應的消息。根據不同的硬體配置，單個 Broker 每秒能處理數以萬計的讀寫請求。
一個 Kafka Cluster 通常由多個 Broker 組成，開發者能透過每個 Broker 的 ID（Integer）進行識別，從而幫助 Kafka Cluster 實現負載平衡、資料備份和故障轉移等功能。
此外，Kafka 採用 ZooKeeper 來管理 Broker。Zookeeper 是 Kafka Broker 和消費者間的協調接口。ZooKeeper 會在叢集中選出一個 Broker 作為叢集控制者（Controller）。控制者負責執行管理所有叢集和元數據（Meta Data）的訊息，控制者的職責包含：
- 管理 Broker 的運行狀態，包括管理 Broker 的自然下線、當機或網路通訊所造成的叢集變動。控制者需要即時更新叢集資訊，並將所發生的變動吿知所有 Broker。
- 在創建 Topic 或對其進行擴展時，控制者會重新分配 Topic 中 Partition 資料的備份副本（Replica），並且為每個 Partition 選出領頭 Broker；每個 Partition 的領頭 Broker 將主導各自 Partition 的資料讀寫動作。
- 管理叢集中所有 Replica 和 Partition 的運行狀態，透過監聽運行狀態事件，來做出相應的處置。
Kafka 的三個優勢
一、可擴展性（Scalability）
Kafka 的可擴展性讓開發者輕鬆管理巨量資料。在 Kafka 中，單一叢集可以橫跨多個資料中心和雲服務基礎架構。
一個 Topic 也能夠將不同 Partition 部署於不同 Broker 上。這種特殊架構讓 Kafka 更容易實現水平擴展，使用者只需在現有的基礎架構中加入新伺服器或資料中心就能處理更多資料。
實務上，開發者能部署單一 Broker 進行概念性驗證，再將其擴展成 3 至 5 台的小型叢集，並隨著服務規模的提升，最後轉移至由數百台 Broker 組成的大型 Kafka 叢集上。
Cluster 在進入正式環境後能在不影響系統可用性的清況下進行擴展，確保即使在某些 Broker 失效的情況下，由多個 Broker 構成的 Cluster 也能持續運行。
二、管理數個生產者和消費者
Kafka 的分散式架構確保無論生產者向相同或不同 Topic 發送資料，所有消息都能按順序儲存。該特性讓 Kafka 能有效聚合前端系統並長時間儲存消息，從而確保資料結構一致。
舉例來說，一個由數個微服務構成的網站，允許每個微服務將 Page View 事件以一致的格式寫入相同的 Kafka Topic。消費端即可從單一串流取得所有應用程式的 Page View 狀態，而不需要為每個應用建立個別 Topic。
除了能夠管理複數生產者，單一 Kafka 串流也能被多個消費者同時讀取，數個消費者也能組成消費者群組（Consumer Group） 並行從不同 Partition 讀取消息，共享串流並提高吞吐量。
三、基於磁碟保存資料
Kafka 不僅能管理多個消費者，還能將消息長時間保存。這代表消費者不必即時處理串流資料。因為消息能留存於磁碟。
Kafka 允許消費者根據不同業務需求為資料保存期限配置合適的策略。透過長時間保留消息，即使是處理速度較慢或由消息吞吐量激增而導致進度落後的消費者，也能保證保不丟失任何數據。
此外，這一機制允許消費者在進行必要的維護時短暫下線，不需擔心遺漏生產者產出的消息。因為在消費者終止運行後，消息仍會保存於 Kafka，只需重啟就能繼續接收串流中的數據。
Kafka 的四個使用案例
一、行為追蹤
Kafka 的設計初衷是為了追蹤使用者行為。使用者於前端系統完成的任何行為，都會產生大量資料，包含被動資料（例如：Page View、 Search Result、Click 事件等等），或其他更複雜的行為（例如：帳號註冊事件）。
這些事件會被發佈到專門的 Kafka Topic 上，隨後被後端應用程式消費，並應用於監控、分析、報表製作、個人化推薦系統等領域。
行為追蹤應用場景
電商平台即時追蹤訪客活動。每個訪客觸發的事件，例如：Page View、Add to Cart、Purchase、Search Result 等，都可以作為事件並發佈到特定的 Kafka Topic。這些事件隨後被消費者訂閱，並能夠用於推薦、個人化折扣、報告和詐欺檢測。
二、消息傳遞
Kafka 允許應用程式向使用者傳遞消息（如：電子郵件）時，無需擔心資料格式或消息是否已確實送出。
開發者只需透過 Kafka 就能夠讀取所有送出的消息，並統一管理，例如：將消息整理成常見格式、將收集的大量消息於一次通知時同時傳送或利用開發者偏好的方式傳送。
消息傳遞應用場景
使用微服務架構的叫車系統透過 Kafka 在不同程式間傳送消息，例如：當客戶預訂叫車行程時，行程預訂程式可透過 Kafka 向司機匹配程式發送一條消息，然後司機匹配程式再匹配到附近司機後迅速回傳消息，而這些消息傳遞都是即時進行的。
三、量測值與日誌
Kafka 也能追蹤系統量測值與監控系統日誌，當生產者將消息發佈到 Kafka Topic 後，這些消息會在 Kafka Cluster 上被聚合，集中存放於文件伺服器或 HDFS，方便後續存取。
這些消息能被監控或告警系統消費，也同時適用於離線系統（如 Hadoop）執行長期趨勢分析的任務，例如：成長率預估。此外，Kafka 也允許將日誌檔案寫入 Elasticsearch 這類日誌搜尋系統或資安分析應用程式。
量測值與日誌應用場景
雲端供應商利用 Kafka 聚合和監控來自各服務的運營指標。例如：由數百台伺服器回傳的 CPU 使用率、記憶體使用率、請求次數、錯誤率等指標可以發佈到 Kafka 上，再將其應用於即時視覺化、偵測告警事件以及檢測異常情況。
四、即時資料處理
許多系統需要在接收消息後立即處理，Kafka 能以極低的延遲時間（ 5 毫秒內）將消息從生產者傳送到消費者，這對以下領域至關重要：
- 金融機構：使用 Kafka 即時收集和處理支付及金融交易，一但檢測詐欺交易就立即終止，或即時更新報價單。
- 物聯網（IOT）：通過預測性維護（Predictive Maintenance）模型持續分析設備回傳資料；當模型檢測到帶有故障風險的異常資訊時，即可觸發系統警告。
- 物流業：利用監控程式追蹤貨船航行位置以提供即時的到貨進度。
即時資料處理應用場景
金融業透過 Kafka 實現即時交易處理。每筆客戶交易資料都會作為事件發佈到 Kafka Topic 上供消費端應用程式讀取，這些資料會被用於分析、追蹤並偵測金融市場活動。
歐立威科技致力成為全方位開源軟體解決方案與資料分析專業建置商，我們提供 Kafka 平台的規劃部署、架構整合、教育訓練與技術服務，幫助客戶利用 Kafka 打造良好的資料流架構，讓他們專注於發展核心業務。如果想要獲得更多資訊，歡迎與我們聯繫。
