這是最後一篇文章囉，我要來介紹一下 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) 看到。然後開始介紹分散式資料系統，以Zookeeper和Kafka作為範例。而之所以會選這兩個，是因為它們常是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天的分享內容，希望能對大家能有些幫助。