轉載自:http://www.cnblogs.com/panfeng412/archive/2011/11/19/2254921.html
1. 數據統計的需求
互聯網上對於數據的統計，一個重要的應用就是對網站站點數據的統計，例如CNZZ站長統計、百度統計、Google Analytics、量子恆道統計等等。
網站站點統計工具無外乎有以下一些功能：
1）網站流量統計：包括PV、UV、IP等指標，這些統計指標可以以趨勢圖的形式展示出來，如最近一周、最近一個月等。
2）IP來源信息統計：記錄各個來源IP下的訪問PV數。
3）訪問來源分析：記錄訪客是從哪些途徑到達本網站的。
4）搜索引擎及搜索關鍵詞分析：對於各個指定搜索引擎帶來訪問PV的變化及趨勢進行分析；對不同時段內訪客搜索關鍵詞的流量趨勢進行統計。
5）訪問地區分析：統計不同時間段內各地區的PV瀏覽量、UV訪客數的變化趨勢。
6）最近訪客流水：實時顯示網站當前的被訪問情況，包括訪問時間、IP地址、來源網址、訪問網址和來源地區等。
從統計的角度來看，這些業務功能的需求可以概括為：
1）各項統計指標的計算，如PV、UV、IP等，可以歸結為的對一條一條數據求SUM、AVG等操作。
2）統計需求越來越要求實時性，訪問來源隨時隨地發生，來源途徑多樣化。對於這類需求，不需要統計計算，而是要經過預處理后快速向用戶展示其關心的數據。
3）可以將數據統計分為兩部分來理解：一部分是對於實時數據的統計，動態展示站點的訪問數據更新情況；另一部分是對於歷史數據的統計，如用於各項報表分析。
2. HBase的實現思路
HBase是一個分布式的存儲系統，可以很容易在廉價PC上搭建其大規模存儲系統，用於存儲海量數據，這使得HBase適合於作為站點數據統計工具的存儲系統。
1）對於實時數據的統計，HBase能夠提供較低延遲的讀寫訪問，承受高並發的訪問請求；而對於歷史數據的統計，HBase則可以被視為一個巨大的Key-Value存儲系統，用於存儲各個網站上歷史的訪問信息，用於做離線的數據分析與報表生成。
2）對於像PV、UV、IP這樣需要求累加計算的操作（求SUM/AVG），由於要對HBase表中相關記錄進行掃描求和計算，所以如果被統計站點的數據量很大的話，使用HBase來做可能會保證不了很快的響應速度。也就是說，從前端發出一個查詢請求到最終結果的響應，時間會比較長（超過1秒或更長）。對於這個問題，將在第3節進行討論。
3）對於像站點訪客流水信息這樣的實時數據展示，則比較適合於使用HBase來做，只要我們設計了合理的key，那么在根據key取單條訪問記錄時響應速度會很快。
下面是一個使用HBase作為存儲系統的結構示意圖：
其中，HBase服務端就是指HBase集群，應用程序分別通過入庫端與查詢端對HBase進行寫操作與讀操作。
從HBase應用角度來看，可以分為兩個不同的方向：
1）第一種方向，將HBase視為一個可靠可用的容量巨大的Key-Value存儲系統，使用HBase的作用很簡單，就是將其作為一個黑匣子來使用，按照之前設計好的表結構來存儲具有稀疏結構的數據。基於這種思路，如果HBase無法完全滿足業務的需求，就在應用程序層次做一些設計或者優化工作，以最終滿足業務的需求。
2）第二種方向，由於HBase是開源的，所以可以對HBase本身機制進行完善與擴展，最終形成一個能夠滿足業務需要的穩定可用的HBase版本。
3. 問題的解決思路
針對第2節中提到的在使用HBase進行累加計算的操作（求SUM/AVG）時的問題，下面給出幾種解決問題的思路與方法。
基於第一種方向：
1）HBase服務端進行聚合計算，這樣應用程序的查詢端不必請求HBase響應大量數據進行傳輸，而只是在服務端計算后的結果，因此能夠滿足實時響應的需求。
基於第二種方向：
1）在HBase表設計時，加入一個空列專門用於統計所用，這樣可以減少從HBase服務端到查詢端的數據傳輸量。
2）應用程序端計算：
a) 入庫端：在HBase表設計時，加入一個專門用於存儲PV/UV這樣累加結果的表，每次新來一條數據時，首先查詢HBase表中上次記錄下來的PV/UV數，然后判斷是否加1后，再重新寫回HBase表中相應key下。通過這種方式，查詢端就可以直接通過HBase的一次get操作得到PV/UV。
b) 查詢端：在查詢端加入PV/UV的緩存，下一次查詢請求來的時候，在已緩存PV/UV值的基礎上，加上掃描HBase表中新增行的記錄數（緩存更新的時間周期足夠短的話，新增數會比較小，對HBase的查詢響應會很快）。