【觀察】常用的流式架構（一）-- Storm與Samza

相較資料處理的兩大陣營，批量處理（Batch）和流式處理（Stream）：批量處理比較經濟，且隻對全量資料進行處理；但資料延時較大，因為隻有跑批之後資料才提供給應用系統。           

流式處理延時小，但由于24小時運作，是以不許有當機時間，并且由于隻處理增量資料，是以難免會遺漏部分資料的處理。           

在兩相權宜之下，演化出了以下兩種混合架構：           

1. Lambda架構：有流式處理以提供低延時的資料通路，同時定期跑批以覆寫流式進行中可能帶來的不完整的資料。但這會造成企業中有兩套代碼庫。

   

2. Kappa架構：在原有流式處理的管道中加入資料保留（Retention）以減小資料未處理的風險，但這就限制了使用者隻能在進行中加入增量算法，不然無法識别新舊資料。

   

   流式處理可以內建一些簡單的算法，他們體量很小在完成算法的同時又不會影響到資料的實時性，例如：           

3. 資料的過濾與轉換；
4. 資料的分類；
5. 簡單的數學計算（求和、計數、求平均等）及邏輯運算
6. 滑動視窗大小設定（比如隻對過去5分鐘的資料做運算等）

   

   Twitter有業界知名的流式處理架構（從Yahoo學來的），它需要定期彙報給客戶廣告投放的效果，怎麼做呢？首先從Kafka中提取廣告跟蹤的資料，然後做初步篩選，然後提取相關字段（比如實際播放時長、浏覽量等），然後按照廣告的投放活動進行分組，最後定義視窗時長進行浏覽量的統計。           

   

   下面我們來看下流式進行中的各代表架構。           

   

   Storm是第一個被廣泛采納的流式架構，它在2010年由BackType公司開發（目前這家公司已被Twitter收購），2011年開源，2014年成為Apache頂級項目。在Storm中提出了“spouts”和“bolts”的想法，前者接收流資料（比如Kafka）後稍作處理生成全新的流，而後者以流作為輸入，并生成流作為輸出。Bolts隻需訂閱它們需要處理的流，并指明作為輸入的流應該如何劃分。它是一個由spouts和bolts組成的網絡。           

   

   它的部署也非常簡單，設計好架構之後，送出給Nimbus伺服器，再由Zookeeper将架構部署到組織内的節點，每一個Storm節點中有多個Worker程序（Worker程序中運作了spouts和bolts的任務）及一個監管程序（Supervisor）。當有Storm節點當機時，Nimbus還會重新部署workers和工作流。           

   

   對于組織中一些狀态資料（例如登陸賬号），Storm将其存放在記憶體中或放到Redis資料庫裡，同時會在關鍵路徑上同步這些狀态資料。當然如果這些狀态資料過大，會影響到流式架構的傳輸實時性。           

   

   當然如果真的有太多Tuples（storm中使用的最基本單元、資料模型和元組）要處理導緻實時資料流擁堵，Storm也會有相應的反壓機制，它對bolt的入站緩存做監控，當超過“高水位”時做限流；低于“低水位”時做加速。
       在2012年，Storm推出了新的擴充元件Trident，用來提供進階API以滿足更多資料的接入，并将流式架構減速為微批量（Micro-batch），提高了資料流的時序性和吞吐量。           

   

   從上圖中我們可以看到，Trident将Spout到最終服務間的資料流切成了三個微批量（Trident在英語中就是三叉戟的意思）。
   
       領英公司（Linkedin）在開發Kafka的時候同時開發了Samza，Samza是在Kafka上層的實時資料流，是上文提到的Kappa架構（Kafka能保留一定量的曆史資料，是以絕大多數的Kappa會基于Kafka）。2013年開源，2015年成為Apache頂級項目。他的特點是單線程作業（避免資料的時序錯亂和資料對點），隻保留本地狀态（便于分布式拓撲與災難恢複），隻使用本地流處理器（更低的延時）。除領英外，我們熟悉的Uber、Netflix也是Samza的使用者。
       在架構設計上，它的作業（Job）類似于Storm中的bolt，但是因為有Kafka幫忙緩存資料，在Kafka的Partition内部完成資料排列，是以Samza完全不用擔心反壓問題和時序問題。分布式的作業還能保證資料流的高可用。           

   

   在處理狀态資料時有兩種辦法，第一種是異地存放，作業會将狀态資料（例如移動視窗）存放在一個KV存儲中（例如Redis），但這樣一個共享的KV存儲的讀寫會非常頻繁；另一種本地存放，即将狀态變化的日志作為資料流的一部分寫到Kafka，然後根據日志資料更新狀态變化。我們一般傾向于第二種，因為沒有反壓，查詢便捷并且恢複簡單。           

   

   既然說到恢複，對于Samza任務的恢複，隻需要重播Kafka中的變更日志再比較其餘任務節點就能将故障節點狀态恢複到最後運作正常的時刻。           

   

   希望今天的講述不太枯燥，下一堂課我們介紹流式架構的另外半壁江山：Spark和Flink。