實時處理方案架構-筆記.docx

1、數據接入層

該部分有多種數據收集方式，包括使用消息隊列（MetaQ），直接經過網絡

Socket傳輸數據，前端業務系統專有數據採集API，對Log問價定時監控。

2、爲何選擇消息隊列？

爲何不把數據直接問導入storm中？而是使用消息隊列（MetaQ）?

使用消息隊列做爲數據中間處理組件的緣由是:

在大批量數據處理時，前端業務數據產生速度可能會很快，而實時處理或者其餘處理速度跟不上，會影響整個系統處理性能，引入消息隊列以後，咱們能夠把數據臨時存儲在消息隊列中，後端處理速度就不會影響前端業務數據的產生，比較專業的術語叫作解除耦合，增長系統擴展性，系統各組件異步運行。

爲何使用MetaQ？

在消息隊列選擇上，kafka是一個比較通用的，開源時間較長的消息發佈訂閱系統，而MetaQ是基於kafka開發的，使用咱們比較熟悉的Java開發，而且在此基礎上做了必定的改進，如數據可靠及事務處理等。

另外一方面，這是國人開源的東西，各方面的文檔比較完整，而且有相關的實例接口。因此使用MetaQ做爲消息中間件，開發成本比較低，又有較好的性能。

Log文件監控

有時候咱們的數據源是已經保存下來的log文件，那Spout就必須監控

Log文件的變化，及時將變化部分的數據提取寫入Storm中，這很難作到徹底實時性。

3、爲什麼使用storm做爲實時處理的核心？

Storm做爲開源比較早的一款實時處理系統，其功能比較完善。其failover機制至關給力，不管是woker仍是supervisor，甚至是task，只要掛掉都能自動重啓；其性能通過測試仍是至關不錯的且目前網絡相關資料較多，這就意味着開發代價會小不少；其擴展性很是好，可以橫向擴展。

Storm目前的短處：

在於nimbus單點，若是nimbus掛掉，整個系統會掛掉，這是Storm須要改進的地方，不過nimbus的系統壓力不大，通常狀況下也不會出現宕機。

4、storm具體應用場景

1）、條件過濾

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

2）、中間計算

咱們須要改變數據中某一個字段（例如是數值），咱們須要利用一箇中間值通過計算（值比較、求和、求平均等等）後改變該值，而後將數據從新輸出。

3）、求TopN

相信你們對TopN類的業務需求也是比較熟悉的。

在規定時間窗口內，統計數據出現的TopN，該類處理在購物及電商業務需求中，比較常見。

4）、推薦系統

有時候在實時處理時會從mysql及hadoop中獲取數據庫中的信息，例如在電影推薦系統中，傳入數據爲用戶當前點播電影信息，從數據庫中獲取的是該用戶以前的一些點播電影信息統計，例如點播最多的電影類型、最近點播的電影類型，及其社交關係中點播信息，結合本次點擊及從數據庫中獲取的信息，生成一條推薦數據，推薦給該用戶。而且該次點擊記錄將會更新其數據庫中的參考信息，這

樣就是實現了簡單的智能推薦。

5）、分佈式RPC

Storm有對RPC進行專門的設計，分佈式RPC用於對Storm上大量的函數調用進行並行計算，最後將結果返回給客戶端。

6）、批處理

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

7）、熱度統計

熱度統計實現依賴於TimeCacheMap數據結構，該結構可以在內存中保存近期活躍的對象。咱們可使用它來實現例如論壇中的熱帖排行計算等。

5、數據落地層

1）、MetaQ

Storm與MetaQ是有一條虛線相連的，部分數據在通過實時處理以後須要寫入MetaQ之中，由於後端業務系統須要從MetaQ中獲取數據。

這嚴格來講不算是數據落地，由於數據沒有實實在在寫入磁盤中持久化。

2）、MySql

此處列出Mysql表明傳統數據庫與Storm的接口差很少都類似。通常狀況下，數據量不是很是大的狀況下可使用Mysql做爲數據落地的存儲對象。

Mysql對數據後續處理也是比較方便的，且網絡上對Mysql的操做也是比較多的，在開發上代價比較小，適合中小量數據存儲。

3）、HDFS

HDFS及基於Hadoop的分佈式文件系統。

許多日誌分析系統都是基於HDFS搭建出來的，因此開發Storm與HDFS的數據落地接口將頗有必要。

例如將大批量數據實時處理以後存入Hive中，提供給後端業務系統進行處理，例如日誌分析，數據挖掘等等。

4）、Lustre

在某些應用上比較適用。

例如：

Lustre做爲數據落地的應用場景是，數據量很大，且處理後目的是做爲歸檔處理。這種情形，Lustre可以爲數據提供一個比較大（至關大）的數據目錄，用於數據歸檔保存。Lustre的架構能夠採用Lustre+drbd+heartbeat的架構，這樣既能爲整個系統提供一個超大容量的歸檔統一命名目錄空間，又能保證數據的安全（雙機熱備）。

6、元數據管理器

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

1）、元數據設計

元數據設計可使用MySQL存儲元數據信息，結合緩存機制開源軟件設計而成。

7、關於Storm和Hadoop對比

Storm關注的是數據屢次處理一次寫入，而hadoop關注的是數據一次寫入，屢次處理使用（查詢）。

Storm系統運行起來後是持續不斷的，而hadoop每每只是在業務須要時調用數據。二者關注及應用的方向不同。

8、Storm的應用前景

就目前來講，愈來愈多的公司在用storm，像一些推薦系統啊，金融系統啊，在小一些的應用場景也有，例如預警系統，網站統計等等，其在數據處理方面有着自然的優點。

整體來看，在數據量愈來愈大，須要處理挖掘的數據需求愈來愈多的狀況下，Storm

仍是有着很好的前景的。