在「資料行銷」逐漸成為主流的現今，數據是行銷活動的核心基礎。而談及大數據技術， SMACK (Spark、Mesos、Akka、Cassandra、Kafka) 架構從 2016 年於矽谷崛起，至今仍保有其難以撼動的地位。
愛酷智能科技應用 SMACK 資料技術組合中的 Kafka 事件串流平台，處理大量數據搜集與應用的流程，以下將介紹 Kafka 的特性及其內容單元：
Kafka 最早是由 LinkedIn 公司開發，使用 Scala 和 Java 語言編寫，是一個統一、高吞吐、低延遲的分散式資料流處理平台 (Distributed Streaming Platform)。
Kafka Cluster (Kafka 的主要架構)
Why Kafka?
- High Availability
- 系統架構使用去中心化 (Decentralization) 作為主要結構，在 Kafka Cluster 內 (如上圖)，由許多Broker 所構成，內部使用 Topic 做為訊息佇列識別名稱，且每個 Topic 內部分割許多存放訊息之Partition。
- 在 Producer 將所需要之訊息發送至 Kafka Cluser 內後，每一個 Broker 都可以處理並將訊息寫入正確之 Topic 及 Partition，並且依需求進行覆寫，確保訊息為多複本狀態。
- High Performance
- 訊息使用磁碟存放，並且採用日誌模式進行循序寫入，確保訊息可用性及高 IOPS，因此在效能性價比上，遠高於其他同類產品。
- High Scalability
- 因使用中心化設計，原則上系統可隨時進行 Scale up & Scale out，並且可以支援多叢集複寫，在佈署上相對靈活且容易。
綜合上述三點，我們可以將 Kakfa 視為成熟且可信賴之訊息佇列中介系統，為企業提供了成熟的解耦合元件。
接著我們將針對 Kafka 內部運作的原理做更深入的介紹：
Deep Dive Into Kafka
Kafka主要分為六大部份，以下針對每一個系統單元說明：
- Broker
- Producer
- Consumer
- Message
- Zookeeper
- Topic
- Broker
一個獨立的 Kafka 伺服器被稱為 Broker，是組成 Kafka Cluster 的最小單元，Broker 可由一個或多個 Broker 組成。Broker 接收來自 Producer的 Message，為 Message 設定偏移量 (Offset)，並存放到磁碟保存。每個 Kafka Cluster 都有至少有一個 Broker 同時為叢集控制器的角色 (自動從叢集的存活節點中選舉出來)。 - Producer
向 Topic 發佈 Message 的應用程式稱為 Producer，Producer 用於持續不斷地向某個 Topic 發送所需的訊息。在許多實際的應用上，Producer 所對應的項目為 Kafka REST API。 - Consumer
Topic 中的 Message 的訂閱者，一個或多個 Consumer 可以訂閱來自不同分區的 Topic，稱為 Consumer Group。同一個 Consumer Group 的兩個 Consumer 不能訂閱來自同一個分區的 Message。 每個 Consumer 維護訂閱分區的偏移量。Consumer 可以通過定位 Topic 分區的已讀偏移量來重新獲取 Message 的訂閱。 - Message
每一個 Topic 內存放著由 Producer 產生的 Message，這些 Message 依照設定可平均分佈在不同的 Broker 內，並且可由系統所產生之一 Key 值進行有序排列，確保 Message 的順序性。 - Zookeeper
Zookeeper 是 Kafka 的分散式管理系統，負責在節點間協調內容，例如：彼此節點的 ID，位置與當前狀態，或是跨節點 Topic 的設定與狀態。在 Kafka 2.8 版本後，已不再依賴此元件。 - Topic
所有 Message 都有自己的所屬分類，這個分類就叫做 Topic。一個 Topic 下的 Message 可以保存在多個Broker上 (對於 Producer 和 Consumer 是無感知的)。
以上為本次對 Kafka 的講述，在下篇文章中，會更深入分享其原理與應用。
推薦閱讀： AccuCDP 「數據儀表板」五大功能解析，全面掌握顧客行為
前瞻性 MarTech 解決方案請參考愛酷官網：https://accu-url.me/3rbycl
作者：愛酷智能科技 雲端架構師 王唯綱
【參考資料】
