Hadoop-HBASE案例分析-Hadoop學習筆記<二>

標籤：

之前有幸在MOOC學院抽中小象學院hadoop體驗課。 
這是小象學院hadoop2.X概述第八章的筆記 
主要介紹HBase，一個分散式資料庫的應用案例。

案例概況：

1）時間序列資料庫(OpenTSDB) 
用HBase儲存時間序列資料，每時每刻都在解決，資料庫為開源 
2）HBase爬蟲調度庫 
垂直搜尋爬蟲 
大規模爬蟲（全網爬蟲） 
這裡界定URL爬蟲調度 
3）HBase文件庫 
儲存文檔資料庫，偏重於儲存 
4）銀行人民幣查詢系統

不在部落格園上閱讀時才會看到的，這篇博文歸http://www.cnblogs.com/weibaar 所有

僅保證在部落格園部落格上的排版乾淨利索還有代碼塊與圖片正確顯示，他站請保留作者資訊尊重著作權啊

HBase在實際問題中的應用：

當資料需要隨機讀寫應用，或者高並行作業（大資料多次操作），或者當資料結構簡單，但是量大（非關係型需要大量應用join操作） 
HBase對關係型查詢，如join等比較難操作 
關鍵要設計Rowkey，可加快查詢 
常用語言有Java, thrift引用其他語言操作

在rowkey設計裡要避免rowkey熱點，要充分利用rowkey有序特點，並可以把需求欄位組合成rowkey

時間序列資料庫

OpenTSDB屬於分布式、可伸縮的時間序列資料庫 
可以在秒級資料進行採集，並支援永久儲存與容量規劃，另外可以從不同的metrics進行儲存、索引 
普通mysql容量不夠，維度支援不夠 
該資料庫的經驗（應該會有遺漏。。） 
1）更多的列，更多的資料，掃描更快（在列上掃描比行上掃描快） 
2）要讓每一行的資料相對獨立。把行按照一定的規律進行切分（譬如認為10秒是一行資料，時間戳記） 
3）要在每一個KeyValue裡儲存更多的資料 
4）不要把同步的儲存到server裡面（如HTable/HTablePool等），多用asynchbase的護理高並發資料庫 
5）key盡量等長 
6）不要在一個Region裡儲存過多？

儲存時間序列的方法

每一行儲存一個metric & time 以及值，這樣可以按不同維度儲存 
把metric id放在時間前面做組合的key，能夠更快掃描相應的維度,而且可以節省儲存空間（把metrics編號，而不是直接用其名字做metrics） 

還可以把行變寬，使行儲存更多資料(+0,+1,+2)，但是這個不會節省任何空間，只是展示上有所變化而已 
但是行不能無限度變寬。 
另外，為了防止網路中斷錯行，建議按照時間戳記分行，而不是時間+1、+2、+3這樣按列數斷行 
有相應的PDF，網上搜就可以了。。

總結

加寬行可以增加掃描速度，組合使用rowkey，但這些並不能節省空間的 
只有合并列、縮短column family名字才能一定程度上縮短空間

垂度爬蟲調度庫

多個組（片組新聞群組等）同時進行爬蟲處理，並儲存到調度庫裡，HBase定期讀取即可

特點

爬蟲軟體需要根據即時性、優先順序等儲存調度需要爬取的url 
且爬蟲需要為不同組維護url列表 
基本上是隊列特徵，先插入的URL要優先爬取。但是也要有可以自訂優先順序的功能。而且由於資料量差異大（圖片很大），也要合理分配資源。 
如垂直業務同時調度、網站抓取速度限速處理、還有時間戳記調度處理。

調度庫

為不同頻道儲存host特點及host url列表。 
在url裡按照hostid與優先順序排序 
這裡符合之前OpenTSDB的特性，不要直接用名字做rowkey，而是用ID（來自host name表）排序 
這樣就可以有間隔的掃描線程來執行URL

總結：

要充分運用rowkey進行有序排序 
要把rowkey融入有用的欄位hostid+PID+URLID 
不要直接用字串作為rowkey，而是編碼以後（整數）進行掃描，節省空間的（因為每個列都要儲存rowkey 
而且整數化以後就規整化了

文件庫

文件庫與調度庫原理比較相似 
文件庫，可以儲存網頁分析以後更加精細化的資料

特點：

資料格式不一樣，需要即時讀取和寫入（還有更新），資料之間儲存會有關聯（如BLOG的評論和本文之間是有關聯的）

不在部落格園上閱讀時才會看到的，這篇博文歸http://www.cnblogs.com/weibaar 所有

僅保證在部落格園部落格上的排版乾淨利索還有代碼塊與圖片正確顯示，他站請保留作者資訊尊重著作權啊

技術特點

拆分基礎資料和動態資料（兩個column family） 
基礎的基本不會變（網頁標題啊內容啊建立時間啊） 
動態資料可以即時變化（瀏覽量啊等等） 
這裡不再是一個server應對不同組，而是多個server應對多個組，以應對不同組的不同資料精細化要求 
關聯

不在部落格園上閱讀時才會看到的，這篇博文歸http://www.cnblogs.com/weibaar 所有

僅保證在部落格園部落格上的排版乾淨利索還有代碼塊與圖片正確顯示，他站請保留作者資訊尊重著作權啊

銀行人民幣查詢系統特點：

規模極大，且裝置分散（如ATM啊點鈔機啊等等），採集系統要求要及時且不能有遺漏 
可按照人民幣冠字型大小來看，做HASH值或逆轉（因為冠字型大小可能是連續的，有些連號鈔票會儲存在一起，無法有效切分資料儲存，有時候會造成訪問熱點，因此需要更改冠字型大小來做rowkey） 
要求 
及時可靠，能夠快速檢索及儲存，且擴充性要好 

因為涉及到多裝置採集輸入，所以可以用Flume+HBase解決問題 
選擇HBase的原因是應用非常簡單，只是簡單查詢而已，用HBase就夠了 
可以參考Cloudera開源的日誌收集系統

總結

HBase常常需要與其他系統結合使用 
要盡量避免產生訪問熱點（尤其要避免直接採用時間作為rowkey），要把連續號打散

Hadoop-HBASE案例分析-Hadoop學習筆記<二>