Topic
- 在Kafka中,每筆資料都是事件(Event),而 Topic 就是這些事件的儲存空間。
- 你可以大致將Topic理解為資料庫中的Table,而Event則類似於資料表中的Record 或 Row。
- 需要特別注意的是,Topic是一種Log的檔案結構,而不是資料結構中的Queue。也就是說,當資料被讀取(消費)後,並不會像Queue一樣自動刪除。Kafka 允許你設定 Retention Policy,透過設置時間或大小限制,來控制資料的保留期限。
Topic的Log 結構
- Topic是一種"Append-Only"的Log,所有事件都只能新增在Topic結構的最尾部,無法在中間插入任何資料。
- 當 Producer 傳送 Event 到某個 Topic 時,該事件會從前一筆事件的後面繼續寫入下一個事件。
Topic可分割為多個 Partition
Event只能透過Offset讀取
- 在Kafka中,每個 Partition 中的 Event 都有一個唯一的 Offset,也就是從第0位開始的偏移量
- 要讀取Event,必須先指定Offset,而不是指定索引值(index)來取值(Can only be seek by offset, not indexed)。
- 例如: 假設Consumer上一次消費了某個Partition中,Offset 2的Event,下次消費時將會從Offset 3開始。
Producer
- Producer是負責將Event傳送到Topic的角色。而前面我們提到,Topic會有多個Partition。那麼,如何決定要把Event寫入哪個 Partition 呢? 會根據有無指定Event Key來決定:
無指定 Event Key 的情況
- 如果Producer沒有指定Event的Key,Kafka會採用輪詢機制(Round Robin),將事件依次寫入不同的 Partition。
- 例如,第一次寫入Partition 0,下一次寫入Partition 1,依此類推。
- 這種方式適合不需要關注事件順序的場景。
有指定 Event Key 的情況
- 當Producer有指定Event Key時,Kafka會保證擁有相同Key的事件都被寫入同一個Partition,並依序寫入,也就是在同一個Partition一直Append event上去。
- Kafka預設會用雜湊函數算出Event key的雜湊值,再用這個值去Mod Partition的數目。這個結果就是要寫入的Partition Id
- 這個機制確保了事件的順序性,適合需要維護讀取順序的場景,例如:當希望某個客戶的Event都寫入同一個 Partition時,可以用這個客戶的Customer Id當Event Key,確保資料的順序性。
Event Key 的潛在問題
使用Event Key雖然保證了順序性,但如果某個 Event Key非常活躍(如一個頻繁產生資料的客戶),可能會導致某一個Partition特別大,造成資料不平均分佈在不同的Partition上。
結論
- Kafka的Topic以Log結構儲存事件,並透過Partition分散數據,這使得它在處理資料量大的數據流時,具有著較高的效能與彈性。而 Producer在寫入事件時,可以選擇是否指定Event Key,根據不同場景的需求來決定事件的分佈和順序。
下一章將繼續介紹Consumer在消費Event時的詳細機制。