實時計算，流數據處理系統簡介與簡單分析

轉自:http://www.csdn.net/article/2014-06-12/2820196-Storm

摘要：實時計算通常都是針對海量數據進行的，通常要求爲秒級。實時計算主要分爲兩塊:數據的實時入庫、數據的實時計算。今天這篇文章詳細介紹了實時計算，流數據處理系統簡介與簡單分析。

編者按：互聯網領域的實時計算通常都是針對海量數據進行的，除了像非實時計算的需求（如計算結果準確）之外，實時計算最重要的一個需求是可以實時響應計算結果，通常要求爲秒級。實時計算的今天，業界都沒有一個準確的定義，什麼叫實時計算？什麼不是？今天這篇文章詳細介紹了實時計算，流數據處理系統簡介與簡單分析。

---

如下爲做者原文：

一． 實時計算的概念

實時計算通常都是針對海量數據進行的，通常要求爲秒級。實時計算主要分爲兩塊:數據的實時入庫、數據的實時計算。

主要應用的場景：

1) 數據源是實時的不間斷的，要求用戶的響應時間也是實時的（好比對於大型網站的流式數據：網站的訪問PV/UV、用戶訪問了什麼內容、搜索了什麼內容等，實時的數據計算和分析能夠動態實時地刷新用戶訪問數據，展現網站實時流量的變化狀況，分析天天各小時的流量和用戶分佈狀況）

2) 數據量大且沒法或不必預算，但要求對用戶的響應時間是實時的。好比說：

昨天來自每一個省份不一樣性別的訪問量分佈，昨天來自每一個省份不一樣性別不一樣年齡不一樣職業不一樣名族的訪問量分佈。

二．  實時計算的相關技術

主要分爲三個階段（大可能是日誌流）:

數據的產生與收集階段、傳輸與分析處理階段、存儲對對外提供服務階段

下面具體針對上面三個階段詳細介紹下

1）數據實時採集：

需求：功能上保證能夠完整的收集到全部日誌數據，爲實時應用提供實時數據；響應時間上要保證明時性、低延遲在1秒左右；配置簡單，部署容易；系統穩定可靠等。

目前的產品：Facebook的Scribe、LinkedIn的Kafka、Cloudera的Flume，淘寶開源的TimeTunnel、Hadoop的Chukwa等，都可以知足每秒數百MB的日誌數據採集和傳輸需求。他們都是開源項目。

2）數據實時計算

在流數據不斷變化的運動過程當中實時地進行分析，捕捉到可能對用戶有用的信息，並把結果發送出去。

 

實時計算目前的主流產品：

 

1. Yahoo的S4：S4是一個通用的、分佈式的、可擴展的、分區容錯的、可插拔的流式系統，Yahoo開發S4系統，主要是爲了解決：搜索廣告的展示、處理用戶的點擊反饋。
2. Twitter的Storm：是一個分佈式的、容錯的實時計算系統。可用於處理消息和更新數據庫（流處理），在數據流上進行持續查詢，並以流的形式返回結果到客戶端（持續計算），並行化一個相似實時查詢的熱點查詢（分佈式的RPC）。
3. Facebook 的Puma：Facebook使用puma和HBase相結合來處理實時數據，另外Facebook發表一篇利用HBase/Hadoop進行實時數據處理的論文（ApacheHadoop Goes Realtime at Facebook），經過一些實時性改造，讓批處理計算平臺也具有實時計算的能力。

 

關於這三個產品的具體介紹架構分析：http://www.kuqin.com/system-analysis/20120111/317322.html

 

下面是S4和Storm的詳細對比

其餘的產品：

早期的：IBM的Stream Base、 Borealis、Hstreaming、Esper

4. 淘寶的實時計算、流式處理

1) 銀河流數據處理平臺：通用的流數據實時計算系統，以實時數據產出的低延遲、高吞吐和複用性爲初衷和目標，採用actor模型構建分佈式流數據計算框架（底層基於akka），功能易擴展、部分容錯、數據和狀態可監控。銀河具備處理實時流數據（如TimeTunnel收集的實時數據）和靜態數據（如本地文件、HDFS文件）的能力，可以提供靈活的實時數據輸出，並提供自定義的數據輸出接口以便擴展實時計算能力。銀河目前主要是爲魔方提供實時的交易、瀏覽和搜索日誌等數據的實時計算和分析。

2) 基於Storm的流式處理，統計計算、持續計算、實時消息處理。

在淘寶，Storm被普遍用來進行實時日誌處理，出如今實時統計、實時風控、實時推薦等場景中。通常來講，咱們從類kafka的metaQ或者基於HBase的timetunnel中讀取實時日誌消息，通過一系列處理，最終將處理結果寫入到一個分佈式存儲中，提供給應用程序訪問。咱們天天的實時消息量從幾百萬到幾十億不等，數據總量達到TB級。對於咱們來講，Storm每每會配合分佈式存儲服務一塊兒使用。在咱們正在進行的個性化搜索實時分析項目中，就使用了timetunnel +HBase + Storm + UPS的架構，天天處理幾十億的用戶日誌信息，從用戶行爲發生到完成分析延遲在秒級。

3) 利用Habase實現的Online應用

4）實時查詢服務

 

•  半內存：使用Redis、Memcache、MongoDB、BerkeleyDB等內存數據庫提供數據實時查詢服務，由這些系統進行持久化操做。
•  全磁盤：使用HBase等以分佈式文件系統（HDFS）爲基礎的NoSQL數據庫，對於key-value引擎，關鍵是設計好key的分佈。
•  全內存：直接提供數據讀取服務，按期dump到磁盤或數據庫進行持久化。

 

關於實時計算流數據分析應用舉例：

對於電子商務網站上的店鋪：

1） 實時展現一個店鋪的到訪顧客流水信息，包括訪問時間、訪客姓名、訪客地理位置、訪客IP、訪客正在訪問的頁面等信息；

2） 顯示某個到訪顧客的全部歷史來訪記錄，同時實時跟蹤顯示某個訪客在一個店鋪正在訪問的頁面等信息；

3） 支持根據訪客地理位置、訪問頁面、訪問時間等多種維度下的實時查詢與分析。

下面對Storm詳細介紹下：

總體架構圖

整個數據處理流程包括四部分：

第一部分是數據接入該部分從前端業務系統獲取數據。

第二部分是最重要的Storm 實時處理部分，數據從接入層接入，通過實時處理後傳入數據落地層；

第三部分爲數據落地層，該部分指定了數據的落地方式；

第四部分元數據管理器。

數據接入層

該部分有多種數據收集方式，包括使用消息隊列（MetaQ），直接經過網絡Socket傳輸數據，前端業務系統專有數據採集API，對Log問價定時監控。(注：有時候咱們的數據源是已經保存下來的log文件，那Spout就必須監控Log文件的變化，及時將變化部分的數據提取寫入Storm中，這很難作到徹底實時性。)

Storm實時處理層

首先咱們經過一個 Storm 和Hadoop的對比來了解Storm中的基本概念。

(Storm關注的是數據屢次處理一次寫入，而Hadoop關注的是數據一次寫入，屢次處理使用（查詢）。Storm系統運行起來後是持續不斷的，而Hadoop每每只是在業務須要時調用數據。二者關注及應用的方向不同。)

1.     Nimbus：負責資源分配和任務調度。

2.     Supervisor：負責接受nimbus分配的任務，啓動和中止屬於本身管理的worker進程。

3.     Worker：運行具體處理組件邏輯的進程。

4.     Task：worker中每個spout/bolt的線程稱爲一個task. 在Storm0.8以後，task再也不與物理線程對應，同一個spout/bolt的task可能會共享一個物理線程，該線程稱爲executor。

具體業務需求：條件過濾、中間值計算、求topN、推薦系統、分佈式RPC、熱度統計

數據落地層：

MetaQ

如圖架構所示，Storm與MetaQ是有一條虛線相連的，部分數據在通過實時處理以後須要寫入MetaQ之中，由於後端業務系統須要從MetaQ中獲取數據。這嚴格來講不算是數據落地，由於數據沒有實實在在寫入磁盤中持久化。

Mysql

數據量不是很是大的狀況下可使用Mysql做爲數據落地的存儲對象。Mysql對數據後續處理也是比較方便的，且網絡上對Mysql的操做也是比較多的，在開發上代價比較小，適合中小量數據存儲。

HDFS

HDFS及基於Hadoop的分佈式文件系統。許多日誌分析系統都是基於HDFS搭建出來的，因此開發Storm與HDFS的數據落地接口將頗有必要。例如將大批量數據實時處理以後存入Hive中，提供給後端業務系統進行處理，例如日誌分析，數據挖掘等等。

Lustre

Lustre做爲數據落地的應用場景是，數據量很大，且處理後目的是做爲歸檔處理。這種情形，Lustre可以爲數據提供一個比較大（至關大）的數據目錄，用於數據歸檔保存。

元數據管理器

元數據管理器的設計目的是，整個系統須要一個統一協調的組件，指導前端業務系統的數據寫入，通知實時處理部分數據類型及其餘數據描述，及指導數據如何落地。元數據管理器貫通整個系統，是比較重要的組成部分。元數據設計可使用mysql存儲元數據信息，結合緩存機制開源軟件設計而成。