（轉載）Hbase -- Hbase數據統計應用中使用心得

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進行數據統計應用中的一些經驗總結，其中對於提到問題的解決思路，有過一些嘗試，歡迎討論。