【觀察】常用的流式架構（二）-- Spark與Flink

Spark由加州大學伯克利分校于2009年開發，第二年開源，2014年成為Apache頂級項目。作為MapReduce的繼任者，Spark可以提供高水準API（如RDD--可恢複分布式資料集；Dstream--離散無序的RDD），其社群在2015年就有超過1000名貢獻者，知名的使用者包括亞馬遜、eBay、雅虎、IBM、百度等。
    2013年Spark Streaming成為Spark的核心，嚴格意義上說它是跑微批量（Micro-Batching）的架構，是以會有幾秒鐘的延時，但Spark Streaming支援豐富的狀态資料、無重複傳輸并且擴充性極佳。一般地，流式資料經過Spark Streaming被切分成微批量，再由Spark引擎處理。           

Spark的一個應用就是統計網頁通路量，可以用Python調取Spark Streming的接口，首先我們先讀取服務端的站點位址（pageViews）并定義讀取間隔，然後根據URL做Map算法将資料歸類（ones--即每一個通路事件被定義為一個最小元素），最後使用Reduce算法将不同URL的GET事件聚合統計出浏覽量。           

最後登場的是Flink，它于2010年由柏林工業大學、柏林洪堡大學和德國波茨坦普拉特拉學院聯合開發，起初名字叫Stratosphere，在2014年進入Apache孵化計劃并更名為Flink，2015年成為Apache頂級項目。Flink作為原生的流處理器，延時小于100毫秒；可以為應用提供流式或批量的虛拟API；支援資料表/SQL，CEP，機器學習，Gelly等多種特征庫；目前的使用者包括阿裡巴巴、愛立信、奧拓，ResearchGate，Zalando等。
    Flink的架構将批量應用與流式應用在資料層彙聚，這個資料層可以分布式地部署在搭在Hadoop Yarn、Apache Mesos和Kubernetes上甚至可以單獨作為叢集搭建，無高可用之虞。此外Flink還提供多種API和庫接口（有流式的及批量優化的）供第三方接入開發（Java/Scala/Python）           

Flink适合支援日事務處理量達幾萬億條的應用、需要維護TB級狀态資料的應用及有數千節點的應用，在處理大型狀态資料的時候，Flink會将狀态資料按時序分視窗按批次存儲，恢複的時候也會從分布式檔案系統種按批次恢複。           

當有任意Flink節點當機時，系統是如何實作高可用的呢？Flink會将資料流按順序切分成多個分區（Partition），然後為每個分區計算檢查點（CheckPoints），在恢複節點時，隻需重置檢查點狀态，然後将此檢查點後的資料由别的節點上重播入當機節點即可。           

介紹完了五種（Storm和Storm Trident算作兩種，盡管）架構，我們來比較下他們的優劣勢。           

對于資料的嚴密性，Storm和Samza都會檢查至少一次；延時性角度Storm遠小于100ms表現最優；但對于狀态資料Storm和Trident隻能處理小型資料，不及Samza、Spark Streaming和Flink；嚴格意義上說Trident和Spark Streaming是微批量的處理方式；由于Samza沒有資料緩沖區，是以就不存在反壓問題；除Storm外，另外四種架構都是能保證資料時序的；延展性方面，Strom、Trident和Spark Streaming表現更優，可以在運作時直接添加新的節點。
    根據在雅虎研究所的測試報告顯示：“Storm和Flink的處理延時最低，Spark支援高的資料吞吐量，但代價就是會有較大延時。”
    除了這五大體系之外，還有一些非主流的流式處理系統，比如的google的Dataflow，IBM的InfoSphere Streams等，這裡就不一一贅述了。