iT邦幫忙

DAY 30
0

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

Day 30: Stream States & Finale

這是最後一篇文章囉,我要來介紹一下 stream computing 裡 狀態 的管理。

所謂狀態是指處理過程中的副作用,比方說,要更新 counter。如果沒有 exactly-once semantics,一筆資料可能被處理多次,那麼更新多次counter就會產出錯誤的結果。

在Storm裡是在micro-batch裡用一個transaction id表示batch的順序,並且保證state的更新會依id順序處理。在儲存state時除了存最新狀態值之外,還會存上一版的狀態值。因此,如果遇到同一個micro-batch被重新處理,只要把上一版狀態取出後重新更新即可。這樣就保證了每一個micro-batch只會更新到一次狀態。

好了,exactly-once semantics問題解決了,但狀態帶來的另外一個問題是效率問題。雖然Stream Computing有效的分散運算,可是所有狀態更新都集中在同一個地方,還是會變成處理瓶頸。這就是我在前半部談到的分散式資料系統要解決的問題。不過,若運算系統和資料系統是獨立運作的,更新時的network latency會對某些要求低延遲的應用造成傷害。在這方面,Samza有個聰明的解決方法。大家可以去看看。

好了,來總結一下吧。前半部分,我先提出一些分散式系統的設計決策,這些設計決策也可以在各種分散式系統中 (e.g., Hadoop) 看到。然後開始介紹分散式資料系統,以ZookeeperKafka作為範例。而之所以會選這兩個,是因為它們常是Stream Computing框架中的元件。後半部介紹分散式運算系統,主要是以Stream Computing為主。Stream Computing因為要求低延時,所以除了一般分散式系統的問題之外,還要面對 細處理顆粒 所帶來的問題。各種不同的框架 (Storm, Samza, Spark Streaming)各有其優缺點。純 Stream computing 因為不保證 exactly-once ,所以無法保證數值會絕對正確。替代方案是改用Micro batch,但這會增加一些latency。不過,為了增加 Stream Computing 的應用範圍,許多框架都支援(或是原生) micro batch。

未來的資料運算系統,都要結合分散式資料系統和分散式運算系統 (如: HDFS & MapReduce)。不像Hadoop已經有完整解決方案,Stream Computing仍然在尋求資料運算系統的最佳組合。

以上就是30天的分享內容,希望能對大家能有些幫助。


上一篇
Day 29: 從Stream到Micro batch
系列文
分散式資料處理,以Stream Computing為例30

1 則留言

0
lulubear
iT邦新手 5 級 ‧ 2014-10-28 10:22:59

恭喜完賽!

我要留言

立即登入留言