《Storm技術內幕與大資料實踐》一1.2其他流式處理框架

本節書摘來非同步社群《Storm技術內幕與大資料實踐》一書中的第1章，第1.2節，作者： 陳敏敏 , 黃奉線 , 王新春
責編： 楊海玲，更多章節內容可以訪問雲棲社群“非同步社群”公眾號檢視。

1.2 其他流式處理框架

1.2.1 Apache S4
Apache S4（http://incubator.apache.org/s4/）是由Yahoo開源的多用途、分散式的、可伸縮的、容錯的、可插入式的實時資料流計算平臺。

S4填補了複雜的專有系統和麵向批處理的開源計算平臺之間的差距。其目標是開發一個高效能運算平臺，對應用程式開發者隱藏並行處理系統固有的複雜性。S4已經在Yahoo!系統中大規模使用，目前最新版本是0.6.0。

S4相對於Storm在可靠性和容錯性上差一些，S4不保證完全不丟失資料。在使用者活躍度上S4也要差一些。

1.2.2 Spark Streaming
Spark是UC Berkeley AMP Lab開源的類Hadoop MapReduce的通用的平行計算框架。Spark基於MapReduce演算法實現的分散式計算擁有Hadoop MapReduce所具有的優點，但不同於MapReduce的是，作業中間輸出結果可以儲存在記憶體中，從而不再需要讀寫HDFS，因此Spark能更好地適用於資料探勘與機器學習等需要迭代的MapReduce的演算法。

Spark Streaming是建立在Spark上的實時計算框架，通過它提供的API和基於記憶體的高速執行引擎，使用者可以結合流式、批處理和互動式進行查詢和實時計算。Spark Streaming的基本的原理是將Stream資料分成小的時間片斷（幾秒鐘到幾分鐘），以類似batch批量處理的方式來處理這些小部分資料。Spark Streaming構建在Spark上，一方面是因為Spark的低延遲執行引擎可以用於實時計算，另一方面相比基於Record的其他處理框架（如Storm），彈性分散式資料集（Resilient Distributed Datasets，RDD）更容易實現高效的容錯處理。此外，小批量處理的方式使得它可以同時相容批量和實時資料處理的邏輯和演算法，方便了一些需要歷史資料和實時資料聯合分析的特定應用場合。

Spark Streaming和Storm兩個框架都提供了可擴充套件性和容錯性，它們根本的區別在於它們的處理模型。Storm處理的是每次傳入的一個事件，而Spark Streaming是處理某個時間段視窗內的事件流。因此，Storm處理一個事件可以達到極低的延遲，而Spark Streaming的延遲相對較高。

1.2.3 流計算和Storm的應用
大資料的價值在各行各業中得到了廣泛使用。針對離線處理，Hadoop已經成為事實上的標準；針對資料實時處理的需求，目前湧現出了許多平臺和解決方案。以下彙總了截至2014年流計算和Storm的使用情況。

1．新浪的實時分析平臺
新浪實時分析平臺的計算引擎是Storm，整個實時計算平臺包括視覺化的任務提交Portal介面、對實時計算任務的管理監控平臺以及核心處理實時計算平臺。

Storm作為核心處理，待處理資料來源為Kafka。對於實時性要求比較高的應用、資料會直接傳送到Kafka，然後由Storm中的應用進行實時分析處理；而對實時性要求不太高的應用，則由Scribe收集資料，然後轉發到Kafka中，再由Storm進行處理。

任務提交到Portal之前，作業的提交者需要確定資料來源、資料的每個處理邏輯，同時確定處理完成後資料的儲存、獲取和展示方式。在任務提交後，可以完成對任務的管理：編輯、停止、暫停和恢復等。

整個核心處理平臺提供了一些通用的模組，如資料的解析（不同的應用有不同的資料格式，可以是簡單的分隔符分隔和正規表示式）、對特定欄位的TopN計數以及資料的過濾和去重，資料處理過程中使用到了快取Redis，支援多種儲存方式（資料處理完成後可選擇的持久化方式有HBase、HDFS、本地檔案和MySQL等）。

在應用上，實時分析平臺的應用包括HTTP日誌分析、PV計算等。

在監控上，通過Storm的Nimbus節點，獲取叢集的執行資料，結合JMX收集到程式狀態資訊，將資料傳送到統一的監控工具中（如Ganglia）。

2．騰訊的實時計算平臺
騰訊的實時計算平臺Tencent Real-time Computing主要由兩部分組成：分散式K/V儲存引擎TDEngine和支援資料流計算的TDProcess。TDProcess是基於Storm的計算引擎，提供了通用的計算模型，如Sum、Count、PV/UV計算和TopK統計等。整個平臺修復了執行中發現的Storm的問題，同時引入YARN進行資源管理。

據稱，整個計算平臺每天承載了超過1000億資料量的計算，支援廣點通、微信、視訊、易迅、秒級監控、電商和互娛等業務上百個實時統計的需求。

3．奇虎360實時平臺
奇虎360從2012年開始引入Storm，Storm主要應用場景包括雲盤縮圖、日誌實時分析、搜尋熱詞推薦、線上驗證碼識別、實時網路入侵檢測等包括網頁、圖片、安全等應用。在部署中，使用了CGroup進行資源隔離，並向Storm提交了很多補丁，如log UI（https://github.com/nathanmarz/storm/pull/598）等。在部署上，Storm叢集複用了其他機器的空閒資源（Storm部署在其他服務的伺服器上，每臺機器貢獻1～2核處理器、1～2 GB記憶體），整個規模達到60多個叢集，15 000多臺物理機，服務於170多個業務。每天處理資料量約幾百TB、幾百億條記錄。

4．京東的實時平臺
京東的實時平臺基於LinkedIn開源的Samza，整個Samza包括流處理層Kafka，執行層YARN和處理層Samza API。一個流式處理由一個或多個作業組成，作業之間的資訊互動藉助Kafka實現，一個作業在執行狀態表現為一個或者多個Task，整個處理過程實際上是在Task中完成的。在Samza中，Kafka主要的角色是訊息的緩衝、作業互動資訊的儲存，同一個業務流程中使用YARN進行任務排程。在其整個架構中，引入了Redis作為資料處理結果的儲存，並通過Comet技術將實時分析的資料推送到前臺展示，整個業務主要應用於京東大家電的訂單處理，實時分析統計出待定區域中各個狀態的訂單量（包括待定位、待派工、待揀貨、待發貨、待配送、待妥投等）。

5．百度的實時系統
相對而言，百度在實時系統上開展的比較早，在其流計算平臺DStream開發時業界尚未有類似的開源系統。截至2014年，從公開的資料可以發現，DStream平臺的叢集規模已超千臺，單叢集最大處理資料量超過50 TB/天，叢集峰值QPS 193W/S，系統穩定性、計算能力已完全滿足海量資料時效性處理需求。另一個平臺TM則保證資料不重不丟，主要用於報表生成系統、計費流計算等。

6．阿里巴巴團隊的JStorm
JStorm（https://github.com/alibaba/jstorm）是阿里巴巴團隊基於Storm二次開發的，Spout/Bolt等介面的使用方式和Storm保持完全一致，在Storm上開發和執行的程式碼可以一行不修改就執行在JStorm上。Storm的核心是Clojure編寫，JStorm完全用Java重寫。JStorm還提供了一些Storm沒有的特性。

• Nimbus實現HA：當一臺Nimbus當機，自動熱切到備份Nimbus。
• 任務之間影響小：新上線的任務不會衝擊老的任務。採用CGroups對資源進行硬隔離，保證程式之間CPU不發生搶佔。
• 解決Disruptor急劇消耗CPU問題：當原生Disruptor佇列慢時，生產方會不斷輪詢檢查Disruptor佇列是否有空的Slot，極大消耗佇列。
• 排程更強大，徹底解決了Storm任務分配不均衡問題。從CPU、記憶體、磁碟、網路4個維度進行任務分配。
• Classloader隔離：解決應用的類和JStorm的類發生衝突的問題。將應用的類放置在自己的類空間中。
• 監控更強大：Web UI上展示更多的監控。Task級別，每一個模組消耗時間和佇列長度；Worker級別，每一個模組消耗時間、佇列長度、CPU/Memory使用以及網路時延；還包括使用者自定義監控資料。
• 在JStorm的介紹中，JStorm上的應用能夠在一行程式碼都不需要改動的情況下執行在Storm平臺上，結合JStorm的其他特性，這將給JStorm帶來更廣闊的使用選擇。

JStrom的開發和更新速度非常快，使用者活躍度也很高。更多詳細資訊可以參考GitHub的介紹。