個人博客總是訪問不了，原文：實時計算應用場景
實時計算的概念很難定義，每個人對這四個字的理解可能都不同。個人觀點主要分爲兩塊：數據的實時入庫和數據的實時計算。
數據實時入庫的時候，一般都需要對原始數據做一定的處理再入庫。能在這個步驟計算儘量在這裏完成。 這個類似數據的預算後入庫，然後提供直接讀取服務。對用戶的延時性上最好。
然而有一些對數據的計算並不能通過預算解決全部問題，比如搜索。這篇主要講實時計算的應用場景，技術架構、實現細節以後寫。
實時計算比較常在數據分析類應用中出現，由於數據分析時刷選條件多樣性與多變性，使數據無法預算，所以只能通過後期的實時計算。
Facebook的實時系統中大量應用到了hadoop、hbase。
他們的項目需求主要有：
1. Elasticity（伸縮性）
2. High write throughput（高寫吞吐量）
3. Efficient and low-latency strong consistency semantics within a data center（單個data center內高性能、低延遲的強一致性）
4. Efficient random reads from disk（disk的高性能隨機讀）
5. High Availability and Disaster Recovery（高可靠性、災後恢復能力）
6. Fault Isolation（錯誤隔離）
7. Atomic read-modify-write primitives（read-modify-write原子操作）
8. Range Scans（範圍掃描）
Facebook對HBase、HDFS做了大量優化，但畢竟是基於MapReduce(IO是硬傷)，再優化也無法達到互聯網應用級別的響應延時。用戶搜索“2011手機” 又選擇了屬性：智能機、直板，想看這個月滿足這些條件的交易在不同省份的分佈。如果過個10s以上才返回數據分析結果，我都不好意思說自己是做互聯網的。
上面的是Facebook實時分析系統的需求，我們的實時計算系統的主要需求如下：
1、海量數據
2、提供各類計算
3、支持任何條件的搭配
4、實時響應(秒級)
5、結果精確
所以我們需要放棄MapReduce的思想，自己設計新的計算架構。 乍一看需求，和搜索很類似。的確，實時計算中大量用到了搜索技術。
與搜索的主要區別：
目的不同：搜索的目的是排序、實時計算的目的是彙總計算
結果不同：搜索返回的是list、實時計算返回的是計算的精確結果
讀取數據不同：搜索可以根據權重取topN的數據做排序、實時計算需要獲取所有滿足條件的數據做計算。
想象一個應用場景(假設我需要的屬性都能獲得)：
1、我想知道昨天訪問我博客的訪問量 —> 這個很簡單，根本不需要實時計算
2、我想知道昨天來自每個省份對我博客的訪問量 —> 這個也簡單，我提前把每個省的訪問量都預算好就行了
3、我想知道昨天來自每個省份不同性別的訪問量分佈 —> 這個也不難，也就36*2 = 72條記錄，我也提前預算好了。
4、我想知道昨天來自每個省份不同性別不同年齡的訪問量分佈 —-> 有點夠嗆，不過也不難 ，繼續預算
5、我想知道昨天來自每個省份不同性別不同年齡不同職業的訪問量分佈 —> 數據量開始膨脹，預算時間也開始變久，數據已經快上億級別了。而且你會發現，很多組合的預算都是沒有意義的，比如 “上海+女+99歲+狙擊手”、“西藏 + 女 + 屠夫” 這樣的查詢組合根本不可能有數據。
6、我想知道昨天來自每個省份不同性別不同年齡不同職業不同名族的訪問量分佈 —> 不考慮預算了，數據量早就上億了，而且很多計算都是沒有意義的。So 實時計算的作用發揮了。
總結下：
當數據量很大，同時發現無法窮舉所有可能條件的查詢組合 或者 大量窮舉出來的條件組合無用的時候是實時計算最佳的應用場景。