iT邦幫忙

DAY 5
0

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

Day 5: 資料切割的metadata管理

啊啊 今天要談什麼呢? 來談談資料切割的metadata好了。

現在有好幾台機器,都必須要follow同一套的資料切割方式,這個切割方式存在metadata中。這個metadata如果不見,那之後的資料就不知道該寫入哪一台,且每次查詢時都必須要廣播找資料,這是很不方便的。所以要想辦法保存好這些metadata。

有些切割方式,像是Hashing的metadata量非常少,這是相對容易管的。但有些切割方式有很多metadata,且有些方式在每次insert都要更新metadata (bad practice~),那這就麻煩了。

一個最簡單的方式就是有一台機器專門管這些metadata (meta server, config server...),若需要metadata就來這邊問。但明顯的這會有單點問題。

現在常見的解法是用Apache Zookeeper (ZK),這是一個維持cluster中共同狀態的分散式系統,透過ZK來維護這些metadata是許多分散式系統的普遍作法。ZK有自己的HA和consistency機制可以保障資料,而且在production環境中一次要用2n+1 (n>0)個節點 (minumum = 3),只要不要大於n個節點掛掉都可以正常服務。因為ZK裡的資料

很重要!

很重要!

很重要!

因為很重要所以至少要保存三份!

ZK為了保障資料的一致性,存取資料的手續有點麻煩。所以請不要因為ZK好用就讓ZK太過操勞。

當然,如果metadata真的很少,又不大會更新的時候,連ZK都可以省掉。這就是完全P2P的系統了,像Cassandra就是這種。


上一篇
Day 4: 為什麼有有些時候不要把query灑到所有機器上平行處理?
下一篇
Day 6: Replication
系列文
分散式資料處理,以Stream Computing為例30

尚未有邦友留言

立即登入留言