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的查詢響應會很快）。

4. 總結的話

這裡是在使用HBase進行資料統計應用中的一些經驗總結，其中對於提到問題的解決思路，有過一些嘗試，歡迎討論。