1 文件說明

該文件描述的是以storm為主體的實時處理架構，該架構包括了資料收集部分，實時處理部分，及資料落地部分。

關於不同部分的技術選型與業務需求及個人對相關技術的熟悉度有關，會一一進行分析。

該架構是本人所掌握的一種架構，可能會與其他架構有相似的部分，個人會一一解釋對其的理解。

這個文章寫的很詳細，相信對大家在實時處理整體理解上會有幫助的。

2 實時處理架構

2.1 整體架構圖

架構說明：

整個資料處理流程包括四部分，一部分是資料接入層，該部分從前端業務系統獲取資料；中間部分是最重要的storm實時處理部分，資料從接入層接入，經過實時處理後傳入資料落地層；第三部分為資料落地層，該部分指定了資料的落地方式；第四部分元資料管理器。

2.2 資料接入層

該部分有多種資料收集方式，包括使用訊息佇列（MetaQ），直接通過網路Socket傳輸資料，前端業務系統專有資料採集API，對Log問價定時監控。

2.2.1 MetaQ

為什麼選擇訊息佇列?

這或許是大家比較疑惑的地方，會疑惑為什麼不把資料直接匯入storm中。使用訊息佇列作為資料中間處理元件的原因是，在大批量資料處理時，前端業務資料產生速度可能會很快，而實時處理或者其他處理速度跟不上，會影響整個系統處理效能，引入訊息佇列之後，我們可以把資料臨時儲存在訊息佇列中，後端處理速度就不會影響前端業務資料的產生，比較專業的術語叫做解除耦合，增加系統擴充套件性，系統各元件非同步執行。

為什麼使用MetaQ？

在訊息佇列選擇上，kafka是一個比較通用的，開源時間較長的訊息釋出訂閱系統，而MetaQ是基於kafka開發的，使用我們比較熟悉的Java開發，並且在此基礎上作了一定的改進，如資料可靠及事務處理等。另一方面，這是國人開源的東西，各方面的文件比較完整，並且有相關的例項介面。所以使用MetaQ作為訊息中介軟體，開發成本比較低，又有較好的效能。

2.2.2 Socket

部分人使用網路Socket程式設計實現Storm的資料接入。這是一種比較直接的資料採集方式，並且確實有些Storm相關的專案使用這種資料接入方式。

這種資料接入方式比較簡單，維護成本較低，但資料量相對於使用訊息中介軟體來說較小。

難點：

使用Socket採集資料比較麻煩的是，由於Storm的Spout的地址是不定的，無法確定其地址，則前端業務系統就無法將資料準確的傳送的某個具體IP地址上的埠中。解決方法如下：

(1) 我們可以使用zookeeper作為傳輸站，Spout執行後，將本地有效的IP地址及可用正在監控的埠等資訊寫入zookeeper中，前端業務系統從zookeeper目錄中獲取該資訊。

(2) 使用元資料指導前端業務系統資料傳送，Spout將本地IP及埠資訊存入元資料管理器中，前端業務系統從元資料管理器中獲取該引數資訊。

2.2.3 前端業務系統資料採集API

這種資料採集方式就不多說了，前端業務系統為Spout專門設計的資料採集API，Spout只需呼叫該API就能獲取資料。

2.2.4 Log檔案監控

有時候我們的資料來源是已經儲存下來的log檔案，那Spout就必須監控Log檔案的變化，及時將變化部分的資料提取寫入Storm中，這很難做到完全實時性。

2.3 Storm實時處理系統

2.3.1 說明

前面部分資料接入層其實已經包含部分storm相關的內容，例如一些資料採集介面就是屬於Storm的Spout部分，我把該部分單獨拿出來的意思是把實時處理核心部分作為一個大章節，即實時處理部分（除資料接入及資料落地的介面）。

2.3.2 使用Storm原因

為何選擇Storm作為實時處理的核心呢？Storm作為開源比較早的一款實時處理系統，其功能比較完善，其failover機制相當給力，無論是woker還是supervisor，甚至是task，只要掛掉都能自動重啟；其效能經過測試還是相當不錯的且目前網路相關資料較多，這就意味著開發代價會小很多；其擴充套件性非常好，能夠橫向擴充套件。Storm目前的短處在與nimbus單點，如果nimbus掛掉，整個系統會掛掉，這是Storm需要改進的地方，不過nimbus的系統壓力不大，一般情況下也不會出現宕機。

2.3.3 實時處理業務介面

該部分需要提供一個實時業務處理的介面，即將使用者的業務層需求轉換為實時處理的具體模式。例如模仿Hive提供一個類Sql的業務介面，我們將一類資料在元資料管理器中描述是一個表，不同欄位是表中不同欄位

select ---------------------------固定資料查詢（異常或者髒資料處理），

max/min/avg-------------------最大最小值

count/sum----------------------求和或次數統計（比如pv等）

count(distinct)------------------去重計數（典型的如UV）

order by------------------------排序（取近訪問的使用者）

group by + 聚類函式 + order by-----聚類後排序（如訪問次數最多的topN商品）

這只是簡單類比，我們可以將實時處理的業務需求轉化為Sql相關語句，上層執行類Sql語句，底層將其翻譯成具體Topology組成及節點引數等。

2.3.4 具體業務需求

(1) 條件過濾

這是Storm最基本的處理方式，對符合條件的資料進行實時過濾，將符合條件的資料儲存下來，這種實時查詢的業務需求在實際應用中是很常見的。

(2) 中間計算

我們需要改變資料中某一個欄位（例如是數值），我們需要利用一箇中間值經過計算（值比較、求和、求平均等等）後改變該值，然後將資料重新輸出。

(3) 求TopN

相信大家對TopN類的業務需求也是比較熟悉的，在規定時間視窗內，統計資料出現的TopN，該類處理在購物及電商業務需求中，比較常見。

(4) 推薦系統

正如我架構圖中畫的那樣，有時候在實時處理時會從mysql及hadoop中獲取資料庫中的資訊，例如在電影推薦系統中，傳入資料為使用者當前點播電影資訊，從資料庫中獲取的是該使用者之前的一些點播電影資訊統計，例如點播最多的電影型別、最近點播的電影型別，及其社交關係中點播資訊，結合本次點選及從資料庫中獲取的資訊，生成一條推薦資料，推薦給該使用者。並且該次點選記錄將會更新其資料庫中的參考資訊，這樣就是實現了簡單的智慧推薦。

(5) 分散式RPC

Storm有對RPC進行專門的設計，分散式RPC用於對Storm上大量的函式呼叫進行平行計算，最後將結果返回給客戶端。（這部分我也不是很懂）

(6) 批處理

所謂批處理就是資料攢積到一定觸發條件，就批量輸出，所謂的觸發條件類似時間視窗到了，統計數量夠了及檢測到某種資料傳入等等。

(7) 熱度統計

熱度統計實現依賴於TimeCacheMap資料結構，該結構能夠在記憶體中儲存近期活躍的物件。我們可以使用它來實現例如論壇中的熱帖排行計算等。

2.4 資料落地層

2.4.1 MetaQ

如圖架構所示，Storm與MetaQ是有一條虛線相連的，部分資料在經過實時處理之後需要寫入MetaQ之中，因為後端業務系統需要從MetaQ中獲取資料。這嚴格來說不算是資料落地，因為資料沒有實實在在寫入磁碟中持久化。

2.4.2 Mysql

此處列出Mysql代表傳統資料庫與Storm的介面差不多都相似。一般情況下，資料量不是非常大的情況下可以使用Mysql作為資料落地的儲存物件。Mysql對資料後續處理也是比較方便的，且網路上對Mysql的操作也是比較多的，在開發上代價比較小，適合中小量資料儲存。

2.4.3 HDFS

HDFS及基於Hadoop的分散式檔案系統。許多日誌分析系統都是基於HDFS搭建出來的，所以開發Storm與HDFS的資料落地介面將很有必要。例如將大批量資料實時處理之後存入Hive中，提供給後端業務系統進行處理，例如日誌分析，資料探勘等等。

2.4.4 Lustre

寫這個資料落地方式，一方面是因為最近在研究Lustre，對其比較熟悉；另一方面也卻是在某些應用上比較適用，例如Lustre作為資料落地的應用場景是，資料量很大，且處理後目的是作為歸檔處理。這種情形，Lustre能夠為資料提供一個比較大（相當大）的資料目錄，用於資料歸檔儲存。

Lustre的架構可以採用Lustre+drbd+heartbeat的架構，這樣既能為整個系統提供一個超大容量的歸檔統一命名目錄空間，又能保證資料的安全（雙機熱備）。

2.5 元資料管理器

2.5.1 設計目的

元資料管理器的設計目的是，整個系統需要一個統一協調的元件，指導前端業務系統的資料寫入，通知實時處理部分資料型別及其他資料描述，及指導資料如何落地。元資料管理器貫通整個系統，是比較重要的組成部分。

2.5.2 元資料設計

元資料設計可以使用mysql儲存元資料資訊，結合快取機制開源軟體設計而成。

3 相關說明

3.1 關於Storm和Hadoop對比

Storm關注的是資料多次處理一次寫入，而hadoop關注的是資料一次寫入，多次處理使用（查詢）。Storm系統執行起來後是持續不斷的，而hadoop往往只是在業務需要時呼叫資料。

兩者關注及應用的方向不一樣。

3.2 Storm的應用前景

就目前來說，越來越多的公司在用storm，像一些推薦系統啊，金融系統啊，在小一些的應用場景也有，例如預警系統，網站統計等等，其在資料處理方面有著天然的優勢。

總體來看，在資料量越來越大，需要處理挖掘的資料需求越來越多的情況下，Storm還是有著很好的前景的。