1. 實時計算的概念

網際網路領域的實時計算一般都是針對海量資料進行的，除了像非實時計算的需求（如計算結果準確）以外，實時計算最重要的一個需求是能夠實時響應計算結果，一般要求為秒級。個人理解，網際網路行業的實時計算可以分為以下兩種應用場景：

1）  資料來源是實時的不間斷的，要求對使用者的響應時間也是實時的。

主要用於網際網路流式資料處理。所謂流式資料是指將資料看作是資料流的形式來處理。資料流則是在時間分佈和數量上無限的一系列資料記錄的集合體；資料記錄是資料流的最小組成單元。舉個例子，對於大型網站，活躍的流式資料非常常見，這些資料包括網站的訪問PV/UV、使用者訪問了什麼內容，搜尋了什麼內容等。實時的資料計算和分析可以動態實時地重新整理使用者訪問資料，展示網站實時流量的變化情況，分析每天各小時的流量和使用者分佈情況，這對於大型網站來說具有重要的實際意義。

2）  資料量大且無法或沒必要預算，但要求對使用者的響應時間是實時的。

主要用於特定場合下的資料分析處理。當資料量很大，同時發現無法窮舉所有可能條件的查詢組合或者大量窮舉出來的條件組合無用的時候，實時計算就可以發揮作用，將計算過程推遲到查詢階段進行，但需要為使用者提供實時響應[參考連結]。

2. 實時計算相關技術

網際網路上海量資料（一般為日誌流）的實時計算過程可以被劃分為以下三個階段：資料的產生與收集階段、傳輸與分析處理階段、儲存對對外提供服務階段。下面分別進行簡單的介紹：

2.1 資料實時採集

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

目前，網際網路企業的海量資料採集工具，有Facebook開源的Scribe、LinkedIn開源的Kafka、Cloudera開源的Flume，淘寶開源的TimeTunnel、Hadoop的Chukwa等，均可以滿足每秒數百MB的日誌資料採集和傳輸需求。

2.2 資料實時計算

傳統的資料操作，首先將資料採集並存儲在DBMS中，然後通過query和DBMS進行互動，得到使用者想要的答案。整個過程中，使用者是主動的，而DBMS系統是被動的。

但是，對於現在大量存在的實時資料，比如股票交易的資料，這類資料實時性強，資料量大，沒有止境，傳統的架構並不合適。流計算就是專門針對這種資料型別準備的。在流資料不斷變化的運動過程中實時地進行分析，捕捉到可能對使用者有用的資訊，並把結果傳送出去。整個過程中，資料分析處理系統是主動的，而使用者卻是處於被動接收的狀態。

需求：適應流式資料、不間斷查詢；系統穩定可靠、可擴充套件性好、可維護性好等。

實時流計算框架：Yahoo開源的S4、Twitter開源的Storm，還有Esper，Streambase，HStreaming等。

有關計算的一些注意點：分散式計算，平行計算（節點間的並行、節點內的並行），熱點資料的快取策略，服務端計算。

2.3 實時查詢服務

全記憶體：直接提供資料讀取服務，定期dump到磁碟或資料庫進行持久化。

半記憶體：使用Redis、Memcache、MongoDB、BerkeleyDB等記憶體資料庫提供資料實時查詢服務，由這些系統進行持久化操作。

全磁碟：使用HBase等以分散式檔案系統（HDFS）為基礎的NoSQL資料庫，對於key-value引擎，關鍵是設計好key的分佈。

3. 應用舉例

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

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

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

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

更詳細的內容，以後再進一步展開介紹。

4. 總結的話

1）並不是任何應用都做到實時計算才是最好的。

2）使用哪些技術和框架來搭建實時計算系統，需要根據實際業務需求進行選擇。

3）對於分散式系統來說，系統的可配置性、可維護性、可擴充套件性十分重要，系統調優永無止境。

5. 參考連結