之前有幸在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），要把連續號打散

轉載于:https://www.cnblogs.com/weibaar/p/4767881.html

總結

以上是生活随笔為你收集整理的Hadoop-HBASE案例分析-Hadoop学习笔记二的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。