HBase學習筆記（一）——基礎入門

一、what：什麼是HBase

HBase的原型是Google的BigTable論文，受到了該論文思想的啓發，目前做爲Hadoop的子項目來開發維護，用於支持結構化的數據存儲。

HBase是一個高可靠性、高性能、面向列、可伸縮的分佈式存儲系統，利用HBASE技術可在廉價PC Server上搭建起大規模結構化存儲集羣。

HBase的目標是存儲並處理大型的數據，更具體來講是僅需使用普通的硬件配置，就可以處理由成千上萬的行和列所組成的大型數據。【非大勿用】

HBase是Google Bigtable的開源實現，可是也有不少不一樣之處。好比：Google Bigtable利用GFS做爲其文件存儲系統，HBase利用Hadoop HDFS做爲其文件存儲系統；Google運行MAPREDUCE來處理Bigtable中的海量數據，HBase一樣利用Hadoop MapReduce來處理HBase中的海量數據；Google Bigtable利用Chubby做爲協同服務，HBase利用Zookeeper做爲對應。

上面的話太官方，挨個看都認識，連起來不理解。簡單粗暴的總結：就是一款NoSQL數據庫，面向列存儲，用於存儲處理海量數據。

核心在於它是一個存數據的地方，但是在此以前學習過了HDFS和Mysql，那HBase爲何還會出現呢？後邊細說~

二、why：爲何會有HBase？

先說一下Mysql，咱們都知道Mysql是一個關係型數據庫，平時開發使用的很是頻繁。一個網站或者系統最核心的表就是用戶表，而當用戶表的數據達到幾千萬甚至幾億級別的時候，對單條數據的檢索將會耗費數秒甚至分鐘級別。實際的清空可能更加複雜不堪。

看下邊一張表：

有這麼一張用戶表，假如我要根據id=1查詢出來這條數據對應的用戶姓名，很簡單，會給咱們返回zhangsan。可是，當咱們查的時候，想一下，查名字的時候age和email會不會被查出來？答案是確定的，Mysql的數據存儲是以行爲單位的，面向行存儲。那問題就出現了，我只須要找出zhangsan的名字，卻須要查詢一整行的數據，若是列很是多，那麼查詢效率可想而知了。

查詢的操做速度會受到如下兩個因素的制約：

• 表被併發的插入、編輯以及刪除操做。
• 查詢語句一般不是簡單的對一個表進行操做，有多是多個表關聯後的複雜查詢，甚至有多是group by或者order by操做，此時，性能降低很明顯。

若是一張表的列過多，會影響查詢效率，咱們稱這樣表爲寬表。怎麼優化呢，拆開來，豎直拆分：

這樣的狀況下，咱們要查找username的時候只須要查找user_basic表，沒有多餘的字段，查詢效率就會很快。

若是一張表的行過多，會影響查詢效率，咱們將這樣的表稱之爲高表，能夠採用水平拆表的方式提升效率：

這種水平拆分應用比較多的 場景就是日誌表，日誌信息天天產生不少，能夠按月進行水平拆分，這樣就實現了高表變矮。

ok，這種拆分方式貌似能夠解決寬表和高表的問題，可是若是有一天公司的業務變了，好比原來沒有微信，如今有了微信，須要加入用戶的微信字段。這時候須要改變表的結構信息，該怎麼辦？最簡單的想法是多加一列，像這樣：

多考慮一下就知道這樣作很不妥帖，好比說有些早期用戶沒有微信，這一列是設置默認值仍是採起其餘的作法就得權衡一下。若是須要擴展不少的列出來，並且不是全部的用戶都有這些屬性，那麼拓展起來就更加複雜了。

這時候，想到了JSON格式的字符串，這是一種以字符串的形式表示的對象，並且屬性字段能夠動態拓展，因而有了下邊這種作法，兩種作法加以對比：

ok，這樣存儲數據它不挺好的嘛，HBase出來幹嗎？？Mysql有一點，數據達到必定的閾值，不管怎麼優化，它都沒法達到高性能的發揮。而大數據領域的數據，動輒PB級，這種存儲應用明顯是不能很好的知足需求的。針對上邊的問題，HBase都有很好的解決方案~~

三、How：HBase怎麼實現的？

先不說爲何用，接着上邊說到的幾個問題：高表寬表，數據列動態擴展，把提到的幾個解決辦法：水平垂直切分，列擴展方法，雜糅在一塊兒。

有這麼一張表，怕它又寬又高，又會動態擴展列，那麼在設計之初，就把這個表給他拆開，爲了列的動態拓展，直接存儲JSON格式：

這樣就解決了寬表問題，高表怎麼辦呢？

一個表的兩部分，各存一部分行：

解決了高表，寬表，動態擴展列的問題~~完美plus~

若是還要進一步提升性能怎麼辦？Mysql->Redis !!! 緩存啊！

查詢出來的數據放入到緩存中，下一次查詢直接從緩存中拿數據。插入數據怎麼辦呢？也能夠這樣理解，我把要插入的數據放進緩存中，不再用管了，直接由數據庫從緩存拿數據插入到數據庫。此時程序不須要等待數據插入成功，提升了並行工做的效率。

但是這樣作有了很大的風險，服務器宕機的話，緩存中的數據沒來得及插入到數據庫中，那不就丟數據了嘛。參考Redis的持久化策略，能夠給插入數據這個操做添加一個操做日誌，用於持久化插入操做，宕機重啓後從日誌恢復。

這樣設計架構就變成了這個樣子：

上邊這種解決方式，實際上就是HBase實現的大體思路，詳細的內容會在後邊慢慢說。

簡單粗暴總結：HBase就是一個面向列存儲的非關係型數據庫。二者的區別主要是：

HBase是的存儲時基於HDFS的，HDFS有着高容錯性的特色，被設計用來部署在低廉的硬件上，並且它提供高吞吐量以訪問應用程序的數據，時候那些有着超大數據集的應用程序。基於Hadoop意味着HBase與生俱來的超強的擴展性和吞吐量。

HBase採用的時key/value的存儲方式，這意味着，及時隨着數據量的增大，也幾乎不會致使查詢性能的降低。HBase又是一個面向列存儲的數據庫，當表的字段不少時，能夠把其中幾個字段獨立出來放在一部分機器上，而另外幾個字段放到另外一部分機器上，充分分散了負載的壓力。如此複雜的存儲結構和分佈式的存儲方式，帶來的代價就是：即使是存儲不多的數據，也不會很快。

HBase並非足夠快，而是數據量很大的時候它慢的不明顯。

何時使用HBase呢，主要是如下兩種狀況：

• 單表數據量超過千萬，並且併發量很大；
• 數據分析需求較弱，或者不須要那麼實時靈活。

參考資料：

[1] 李海波. 大數據技術之HBase

[2] 楊曦. HBase不睡覺書