一． 實時計算的概念
實時計算一般都是針對海量資料進行的，一般要求為秒級。實時計算主要分為兩塊:資料的實時入庫、資料的實時計算。
主要應用的場景：
1) 資料源是實時的不間斷的，要求使用者的響應時間也是實時的（比如對于大型網站的流式資料：網站的通路pv/uv、使用者通路了什麼内容、搜尋了什麼内容等，實時的資料計算和分析可以動态實時地重新整理使用者通路資料，展示網站實時流量的變化情況，分析每天各小時的流量和使用者分布情況）
2) 資料量大且無法或沒必要預算，但要求對使用者的響應時間是實時的。比如說：
昨天來自每個省份不同性别的通路量分布，昨天來自每個省份不同性别不同年齡不同職業不同名族的通路量分布。
二． 實時計算的相關技術
主要分為三個階段（大多是日志流）:
資料的産生與收集階段、傳輸與分析處理階段、存儲對對外提供服務階段
下面具體針對上面三個階段詳細介紹下
1）資料實時采集：
需求：功能上保證可以完整的收集到所有日志資料，為實時應用提供實時資料；響應時間上要保證明時性、低延遲在1秒左右；配置簡單，部署容易；系統穩定可靠等。
目前的産品：facebook的scribe、linkedin的kafka、cloudera的flume，淘寶開源的timetunnel、hadoop的chukwa等，均可以滿足每秒數百mb的日志資料采集和傳輸需求。他們都是開源項目。
2）資料實時計算
在流資料不斷變化的運動過程中實時地進行分析，捕捉到可能對使用者有用的資訊，并把結果發送出去。
實時計算目前的主流産品：
yahoo的s4：s4是一個通用的、分布式的、可擴充的、分區容錯的、可插拔的流式系統，yahoo開發s4系統，主要是為了解決：搜尋廣告的展現、處理使用者的點選回報。
twitter的storm：是一個分布式的、容錯的實時計算系統。可用于處理消息和更新資料庫（流處理），在資料流上進行持續查詢，并以流的形式傳回結果到用戶端（持續計算），并行化一個類似實時查詢的熱點查詢（分布式的rpc）。
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存儲中繼資料資訊，結合緩存機制開源軟體設計而成。
原文釋出時間為：2014年06月13日
本文作者：va_key
本文來自雲栖社群合作夥伴至頂網，了解相關資訊可以關注至頂網。