iT邦幫忙

DAY 15
0

分散式資料處理,以Stream Computing為例系列 第 15

Day 15: Apache Kafka (3)

以下是Kafka的設計所帶來的限制:

  1. Consumer Group裡的consumer數量 不能小於 partition 數量。不然就會有partition裡的資料對不到consumer。
  2. 若各個consumer消耗資料速度不均,Partition的消耗速度會失衡。也就是有的partition已經消耗到最近的資料,但有的partition還在消耗之前的資料。
  3. 搭配上之前所說:「Producer必須要自己決定要將資料送到哪個partition」,所以失衡的狀況無法透過Producer改善,又:「每一個Consumer只會同時bind一個partition」,所以,失衡的狀況無法藉由produer/consumer的round-robin來解決(*)。
  4. 基於以上,每個partition實際上可以看成一個獨立的Queue。也就是說,雖然有partition,但沒有所謂跨partition的total order,也就是只能保證各個partition自己的local order。
  5. 也就是說,若有一個AP會處理跨partition的資料,AP不能假設會依producer產生的時序取得資料,而只能假設從每個partition裡取得的資料是有按時序的 (Kafka有保證,若Producer先送到Partition的資料,在Partition裡也會排前面)。這就是在Day 3所講到,partition帶來的tradeoff。因此,若有total order需求的AP並不適合用Kafka。

簡單來說,Kafka假設,AP是不需要total order的;抑或是AP只需要by-partition的local order,只要適當的做好partition,那麼就可以維持好時序的資料消耗。

Kafka實際上也倚賴Zookeeper來儲存Partition的metadata,如同Day 5我們提到的常見作法。

以上,這是從partition的角度來看Kafka。明天就再從Replication觀點來看Kafka吧。

(*) (Update 10/16): Kafka有rebalance功能,若在Consumer group中新增Consumer,會觸動rebalance, 重新分配partition與consumer之間的對應關係。這樣有機會可以解決資料量失衡的問題。


上一篇
Day 14: Apache Kafka (2)
下一篇
Day 16: Apache Kafka (4)
系列文
分散式資料處理,以Stream Computing為例30

尚未有邦友留言

立即登入留言