之前有幸在MOOC學(xué)院抽中小象學(xué)院hadoop體驗(yàn)課。?
這是小象學(xué)院hadoop2.X概述第八章的筆記?
主要介紹HBase，一個分布式數(shù)據(jù)庫的應(yīng)用案例。

案例概況：

1）時間序列數(shù)據(jù)庫(OpenTSDB)?
用HBase儲存時間序列數(shù)據(jù)，每時每刻都在解決，數(shù)據(jù)庫為開源?
2）HBase爬蟲調(diào)度庫?
垂直搜索爬蟲?
大規(guī)模爬蟲（全網(wǎng)爬蟲）?
這里界定URL爬蟲調(diào)度?
3）HBase文檔庫?
儲存文檔數(shù)據(jù)庫，偏重于儲存?
4）銀行人民幣查詢系統(tǒng)

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

僅保證在博客園博客上的排版干凈利索還有代碼塊與圖片正確顯示，他站請保留作者信息尊重版權(quán)啊

HBase在實(shí)際問題中的應(yīng)用：

當(dāng)數(shù)據(jù)需要隨機(jī)讀寫應(yīng)用，或者高并發(fā)操作（大數(shù)據(jù)多次操作），或者當(dāng)數(shù)據(jù)結(jié)構(gòu)簡單，但是量大（非關(guān)系型需要大量應(yīng)用join操作）?
HBase對關(guān)系型查詢，如join等比較難操作?
關(guān)鍵要設(shè)計Rowkey，可加快查詢?
常用語言有Java, thrift引用其他語言操作

在rowkey設(shè)計里要避免rowkey熱點(diǎn)，要充分利用rowkey有序特點(diǎn)，并可以把需求字段組合成rowkey

時間序列數(shù)據(jù)庫

OpenTSDB屬于分布式、可伸縮的時間序列數(shù)據(jù)庫?
可以在秒級數(shù)據(jù)進(jìn)行采集，并支持永久存儲與容量規(guī)劃，另外可以從不同的metrics進(jìn)行存儲、索引?
普通mysql容量不夠，維度支持不夠?
該數(shù)據(jù)庫的經(jīng)驗(yàn)（應(yīng)該會有遺漏。。）?
1）更多的列，更多的數(shù)據(jù)，掃描更快（在列上掃描比行上掃描快）?
2）要讓每一行的數(shù)據(jù)相對獨(dú)立。把行按照一定的規(guī)律進(jìn)行切分（譬如認(rèn)為10秒是一行數(shù)據(jù)，時間戳）?
3）要在每一個KeyValue里儲存更多的數(shù)據(jù)?
4）不要把同步的儲存到server里面（如HTable/HTablePool等），多用asynchbase的護(hù)理高并發(fā)數(shù)據(jù)庫?
5）key盡量等長?
6）不要在一個Region里儲存過多？

儲存時間序列的方法

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

還可以把行變寬，使行儲存更多數(shù)據(jù)(+0,+1,+2)，但是這個不會節(jié)省任何空間，只是展示上有所變化而已?
但是行不能無限度變寬。?
另外，為了防止網(wǎng)絡(luò)中斷錯行，建議按照時間戳分行，而不是時間+1、+2、+3這樣按列數(shù)斷行?
有相應(yīng)的PDF，網(wǎng)上搜就可以了。。

總結(jié)

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

---

垂度爬蟲調(diào)度庫

多個組（如圖片組新聞組等）同時進(jìn)行爬蟲處理，并儲存到調(diào)度庫里，HBase定期讀取即可

特點(diǎn)

爬蟲軟件需要根據(jù)實(shí)時性、優(yōu)先級等存儲調(diào)度需要爬取的url?
且爬蟲需要為不同組維護(hù)url列表?
基本上是隊(duì)列特征，先插入的URL要優(yōu)先爬取。但是也要有可以自定義優(yōu)先級的功能。而且由于數(shù)據(jù)量差異大（圖片很大），也要合理分配資源。?
如垂直業(yè)務(wù)同時調(diào)度、站點(diǎn)抓取速度限速處理、還有時間戳調(diào)度處理。

調(diào)度庫

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

總結(jié)：

要充分運(yùn)用rowkey進(jìn)行有序排序?
要把rowkey融入有用的字段hostid+PID+URLID?
不要直接用字符串作為rowkey，而是編碼以后（整數(shù)）進(jìn)行掃描，節(jié)省空間（因?yàn)槊總€列都要儲存rowkey?
而且整數(shù)化以后就規(guī)整化了

---

文檔庫

文檔庫與調(diào)度庫原理比較相似?
文檔庫，可以存儲網(wǎng)頁分析以后更加精細(xì)化的數(shù)據(jù)

特點(diǎn)：

數(shù)據(jù)格式不一樣，需要實(shí)時讀取和寫入（還有更新），數(shù)據(jù)之間存儲會有關(guān)聯(lián)（如BLOG的評論和正文之間是有關(guān)聯(lián)的）

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

僅保證在博客園博客上的排版干凈利索還有代碼塊與圖片正確顯示，他站請保留作者信息尊重版權(quán)啊

技術(shù)特點(diǎn)

拆分基礎(chǔ)數(shù)據(jù)和動態(tài)數(shù)據(jù)（兩個column family）?
基礎(chǔ)的基本不會變（網(wǎng)頁標(biāo)題啊內(nèi)容啊創(chuàng)建時間啊）?
動態(tài)數(shù)據(jù)可以實(shí)時變化（瀏覽量啊等等）?
這里不再是一個server應(yīng)對不同組，而是多個server應(yīng)對多個組，以應(yīng)對不同組的不同數(shù)據(jù)精細(xì)化要求?
關(guān)聯(lián)

---

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

僅保證在博客園博客上的排版干凈利索還有代碼塊與圖片正確顯示，他站請保留作者信息尊重版權(quán)啊

銀行人民幣查詢系統(tǒng)

特點(diǎn)：

規(guī)模極大，且設(shè)備分散（如ATM啊點(diǎn)鈔機(jī)啊等等），采集系統(tǒng)要求要及時且不能有遺漏?
可按照人民幣冠字號來看，做HASH值或逆轉(zhuǎn)（因?yàn)楣谧痔柨赡苁沁B續(xù)的，有些連號鈔票會儲存在一起，無法有效切分?jǐn)?shù)據(jù)儲存，有時候會造成訪問熱點(diǎn)，因此需要更改冠字號來做rowkey）?
要求?
及時可靠，能夠快速檢索及存儲，且擴(kuò)展性要好?

因?yàn)樯婕暗蕉嘣O(shè)備采集輸入，所以可以用Flume+HBase解決問題?
選擇HBase的原因是應(yīng)用非常簡單，只是簡單查詢而已，用HBase就夠了?
可以參考Cloudera開源的日志收集系統(tǒng)

總結(jié)

HBase常常需要與其他系統(tǒng)結(jié)合使用?
要盡量避免產(chǎn)生訪問熱點(diǎn)（尤其要避免直接采用時間作為rowkey），要把連續(xù)號打散

轉(zhuǎn)載于:https://www.cnblogs.com/weibaar/p/4767881.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。