一． 實(shí)時計算的概念

實(shí)時計算一般都是針對海量數(shù)據(jù)進(jìn)行的，一般要求為秒級。實(shí)時計算主要分為兩塊:數(shù)據(jù)的實(shí)時入庫、數(shù)據(jù)的實(shí)時計算。

主要應(yīng)用的場景：

1) 數(shù)據(jù)源是實(shí)時的不間斷的，要求用戶的響應(yīng)時間也是實(shí)時的（比如對于大型網(wǎng)站的流式數(shù)據(jù)：網(wǎng)站的訪問PV/UV、用戶訪問了什么內(nèi)容、搜索了什么內(nèi)容等，實(shí)時的數(shù)據(jù)計算和分析可以動態(tài)實(shí)時地刷新用戶訪問數(shù)據(jù)，展示網(wǎng)站實(shí)時流量的變化情況，分析每天各小時的流量和用戶分布情況）

2) 數(shù)據(jù)量大且無法或沒必要預(yù)算，但要求對用戶的響應(yīng)時間是實(shí)時的。比如說：

昨天來自每個省份不同性別的訪問量分布，昨天來自每個省份不同性別不同年齡不同職業(yè)不同名族的訪問量分布。

二． 實(shí)時計算的相關(guān)技術(shù)

主要分為三個階段（大多是日志流）:

數(shù)據(jù)的產(chǎn)生與收集階段、傳輸與分析處理階段、存儲對對外提供服務(wù)階段

　　下面具體針對上面三個階段詳細(xì)介紹下

1）數(shù)據(jù)實(shí)時采集：

需求：功能上保證可以完整的收集到所有日志數(shù)據(jù)，為實(shí)時應(yīng)用提供實(shí)時數(shù)據(jù)；響應(yīng)時間上要保證實(shí)時性、低延遲在1秒左右；配置簡單，部署容易；系統(tǒng)穩(wěn)定可靠等。

目前的產(chǎn)品：Facebook的Scribe、LinkedIn的Kafka、Cloudera的Flume，淘寶開源的TimeTunnel、Hadoop的Chukwa等，均可以滿足每秒數(shù)百M(fèi)B的日志數(shù)據(jù)采集和傳輸需求。他們都是開源項目。

2）數(shù)據(jù)實(shí)時計算

在流數(shù)據(jù)不斷變化的運(yùn)動過程中實(shí)時地進(jìn)行分析，捕捉到可能對用戶有用的信息，并把結(jié)果發(fā)送出去。

　　實(shí)時計算目前的主流產(chǎn)品：

Yahoo的S4：S4是一個通用的、分布式的、可擴(kuò)展的、分區(qū)容錯的、可插拔的流式系統(tǒng)，Yahoo開發(fā)S4系統(tǒng)，主要是為了解決：搜索廣告的展現(xiàn)、處理用戶的點(diǎn)擊反饋。Twitter的Storm：是一個分布式的、容錯的實(shí)時計算系統(tǒng)。可用于處理消息和更新數(shù)據(jù)庫（流處理），在數(shù)據(jù)流上進(jìn)行持續(xù)查詢，并以流的形式返回結(jié)果到客戶端（持續(xù)計算），并行化一個類似實(shí)時查詢的熱點(diǎn)查詢（分布式的RPC）。Facebook 的Puma：Facebook使用puma和HBase相結(jié)合來處理實(shí)時數(shù)據(jù)，另外Facebook發(fā)表一篇利用HBase/Hadoop進(jìn)行實(shí)時數(shù)據(jù)處理的論文（ApacheHadoop Goes Realtime at Facebook），通過一些實(shí)時性改造，讓批處理計算平臺也具備實(shí)時計算的能力。

關(guān)于這三個產(chǎn)品的具體介紹架構(gòu)分析：http://www.kuqin.com/system-analysis/20120111/317322.html

　　下面是S4和Storm的詳細(xì)對比

　　其他的產(chǎn)品：

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

4. 淘寶的實(shí)時計算、流式處理

1) 銀河流數(shù)據(jù)處理平臺：通用的流數(shù)據(jù)實(shí)時計算系統(tǒng)，以實(shí)時數(shù)據(jù)產(chǎn)出的低延遲、高吞吐和復(fù)用性為初衷和目標(biāo)，采用actor模型構(gòu)建分布式流數(shù)據(jù)計算框架（底層基于akka），功能易擴(kuò)展、部分容錯、數(shù)據(jù)和狀態(tài)可監(jiān)控。銀河具有處理實(shí)時流數(shù)據(jù)（如TimeTunnel收集的實(shí)時數(shù)據(jù)）和靜態(tài)數(shù)據(jù)（如本地文件、HDFS文件）的能力，能夠提供靈活的實(shí)時數(shù)據(jù)輸出，并提供自定義的數(shù)據(jù)輸出接口以便擴(kuò)展實(shí)時計算能力。銀河目前主要是為魔方提供實(shí)時的交易、瀏覽和搜索日志等數(shù)據(jù)的實(shí)時計算和分析。

2) 基于Storm的流式處理，統(tǒng)計計算、持續(xù)計算、實(shí)時消息處理。

在淘寶，Storm被廣泛用來進(jìn)行實(shí)時日志處理，出現(xiàn)在實(shí)時統(tǒng)計、實(shí)時風(fēng)控、實(shí)時推薦等場景中。一般來說，我們從類kafka的metaQ或者基于HBase的timetunnel中讀取實(shí)時日志消息，經(jīng)過一系列處理，最終將處理結(jié)果寫入到一個分布式存儲中，提供給應(yīng)用程序訪問。我們每天的實(shí)時消息量從幾百萬到幾十億不等，數(shù)據(jù)總量達(dá)到TB級。對于我們來說，Storm往往會配合分布式存儲服務(wù)一起使用。在我們正在進(jìn)行的個性化搜索實(shí)時分析項目中，就使用了timetunnel +HBase + Storm + UPS的架構(gòu)，每天處理幾十億的用戶日志信息，從用戶行為發(fā)生到完成分析延遲在秒級。

3) 利用Habase實(shí)現(xiàn)的Online應(yīng)用

4）實(shí)時查詢服務(wù)

半內(nèi)存：使用Redis、Memcache、MongoDB、BerkeleyDB等內(nèi)存數(shù)據(jù)庫提供數(shù)據(jù)實(shí)時查詢服務(wù)，由這些系統(tǒng)進(jìn)行持久化操作。 全磁盤：使用HBase等以分布式文件系統(tǒng)（HDFS）為基礎(chǔ)的NoSQL數(shù)據(jù)庫，對于key-value引擎，關(guān)鍵是設(shè)計好key的分布。 全內(nèi)存：直接提供數(shù)據(jù)讀取服務(wù)，定期dump到磁盤或數(shù)據(jù)庫進(jìn)行持久化。

關(guān)于實(shí)時計算流數(shù)據(jù)分析應(yīng)用舉例：

對于電子商務(wù)網(wǎng)站上的店鋪：

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

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

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

　　下面對Storm詳細(xì)介紹下：

整體架構(gòu)圖

整個數(shù)據(jù)處理流程包括四部分：

第一部分是數(shù)據(jù)接入該部分從前端業(yè)務(wù)系統(tǒng)獲取數(shù)據(jù)。

第二部分是最重要的Storm 實(shí)時處理部分，數(shù)據(jù)從接入層接入，經(jīng)過實(shí)時處理后傳入數(shù)據(jù)落地層；

第三部分為數(shù)據(jù)落地層，該部分指定了數(shù)據(jù)的落地方式；

第四部分元數(shù)據(jù)管理器。

數(shù)據(jù)接入層

該部分有多種數(shù)據(jù)收集方式，包括使用消息隊列（MetaQ），直接通過網(wǎng)絡(luò)Socket傳輸數(shù)據(jù)，前端業(yè)務(wù)系統(tǒng)專有數(shù)據(jù)采集API，對Log問價定時監(jiān)控。(注：有時候我們的數(shù)據(jù)源是已經(jīng)保存下來的log文件，那Spout就必須監(jiān)控Log文件的變化，及時將變化部分的數(shù)據(jù)提取寫入Storm中，這很難做到完全實(shí)時性。)

Storm實(shí)時處理層

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

(Storm關(guān)注的是數(shù)據(jù)多次處理一次寫入，而Hadoop關(guān)注的是數(shù)據(jù)一次寫入，多次處理使用（查詢）。Storm系統(tǒng)運(yùn)行起來后是持續(xù)不斷的，而Hadoop往往只是在業(yè)務(wù)需要時調(diào)用數(shù)據(jù)。兩者關(guān)注及應(yīng)用的方向不一樣。)

1. Nimbus：負(fù)責(zé)資源分配和任務(wù)調(diào)度。

2. Supervisor：負(fù)責(zé)接受nimbus分配的任務(wù)，啟動和停止屬于自己管理的worker進(jìn)程。

3. Worker：運(yùn)行具體處理組件邏輯的進(jìn)程。

4. Task：worker中每一個spout/bolt的線程稱為一個task. 在Storm0.8之后，task不再與物理線程對應(yīng)，同一個spout/bolt的task可能會共享一個物理線程，該線程稱為executor。

具體業(yè)務(wù)需求：條件過濾、中間值計算、求topN、推薦系統(tǒng)、分布式RPC、熱度統(tǒng)計

數(shù)據(jù)落地層：

MetaQ

如圖架構(gòu)所示，Storm與MetaQ是有一條虛線相連的，部分?jǐn)?shù)據(jù)在經(jīng)過實(shí)時處理之后需要寫入MetaQ之中，因?yàn)楹蠖藰I(yè)務(wù)系統(tǒng)需要從MetaQ中獲取數(shù)據(jù)。這嚴(yán)格來說不算是數(shù)據(jù)落地，因?yàn)閿?shù)據(jù)沒有實(shí)實(shí)在在寫入磁盤中持久化。

Mysql

數(shù)據(jù)量不是非常大的情況下可以使用Mysql作為數(shù)據(jù)落地的存儲對象。Mysql對數(shù)據(jù)后續(xù)處理也是比較方便的，且網(wǎng)絡(luò)上對Mysql的操作也是比較多的，在開發(fā)上代價比較小，適合中小量數(shù)據(jù)存儲。

HDFS

HDFS及基于Hadoop的分布式文件系統(tǒng)。許多日志分析系統(tǒng)都是基于HDFS搭建出來的，所以開發(fā)Storm與HDFS的數(shù)據(jù)落地接口將很有必要。例如將大批量數(shù)據(jù)實(shí)時處理之后存入Hive中，提供給后端業(yè)務(wù)系統(tǒng)進(jìn)行處理，例如日志分析，數(shù)據(jù)挖掘等等。

Lustre

Lustre作為數(shù)據(jù)落地的應(yīng)用場景是，數(shù)據(jù)量很大，且處理后目的是作為歸檔處理。這種情形，Lustre能夠?yàn)閿?shù)據(jù)提供一個比較大（相當(dāng)大）的數(shù)據(jù)目錄，用于數(shù)據(jù)歸檔保存。

元數(shù)據(jù)管理器

元數(shù)據(jù)管理器的設(shè)計目的是，整個系統(tǒng)需要一個統(tǒng)一協(xié)調(diào)的組件，指導(dǎo)前端業(yè)務(wù)系統(tǒng)的數(shù)據(jù)寫入，通知實(shí)時處理部分?jǐn)?shù)據(jù)類型及其他數(shù)據(jù)描述，及指導(dǎo)數(shù)據(jù)如何落地。元數(shù)據(jù)管理器貫通整個系統(tǒng)，是比較重要的組成部分。元數(shù)據(jù)設(shè)計可以使用mysql存儲元數(shù)據(jù)信息，結(jié)合緩存機(jī)制開源軟件設(shè)計而成。