[轉]基於Storm的實時數據處理方案

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仍是有着很好的前景的。

 

轉載自：http://blog.csdn.net/endlu/article/details/51169383