HBase是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統。

? 適合于存儲大表數據（表的規模可以達到數十億行以及數百萬列），并且對大表數據的讀、寫訪問可以達到實時級別；
? 利用Hadoop HDFS（Hadoop Distributed File System）作為其文件存儲系統，提供高可靠性、高性能、列存儲、可伸縮、實時讀寫的數據庫系統；
? 利用ZooKeeper作為協同服務。

與RMDB比較：

HBase
分布式存儲，面向列。
動態擴展列。
普通商用硬件支持，擴容成本低。
RMDB
數據結構固定。
需要預先定義好數據結構。
需要大量IO，擴展成本大。

HBase適合具有如下需求的應用：

?海量數據（TB、PB）
?高吞吐量
?需要在海量數據中實現高效的隨機讀取
?需要很好的性能伸縮能力
?能夠同時處理結構化和非結構化的數據
?不需要完全擁有傳統關系型數據庫所具備的ACID特性

數據結構介紹：

結構化數據

? 具有固定的結構，屬性劃分，以及類型等信息。我們通常所理解的關系型數據庫中所存儲的數據信息，大多是結構化數據， 如職工信息表，擁有ID、Name、Phone、Address等屬性信息。
? 通常直接存放在數據庫表中。數據記錄的每一個屬性對應數據表的一個字段。

非結構化數據

? 無法用統一的結構來表示，如文本文件、圖像、視頻、聲音、網頁等信息。
? 數據記錄較小時(如KB級別)，可考慮直接存放到數據庫表中（整條記錄映射到某一個列中），這樣也有利于整條記錄的快速檢索。
? 數據較大時，通常考慮直接存放在文件系統中。數據庫可用來存放相關數據的索引信息。

半結構化數據

? 具有一定的結構，但又有一定的靈活可變性。典型如XML、HTML等數據。其實也是非結構化數據的一種。
? 可以考慮直接轉換成結構化數據進行存儲。
? 根據數據記錄的大小和特點，選擇合適的存儲方式。這一點與非結構化數據的存儲類似。

行列存儲：按行存儲：

數據按行存儲在底層文件系統中。通常，每一行會被分配固定的空間。
? 優點：有利于增加/修改整行記錄等操作；有利于整行數據的讀取操作；
? 缺點：單列查詢時，會讀取一些不必要的數據。

按列存儲：

數據以列為單位，存儲在底層文件系統中。
? 優點：有利于面向單列數據的讀取/統計等操作。
? 缺點：整行讀取時，可能需要多次I/O操作。

主鍵設置規則：

Secondary Index

? HBase是一個Key-Value類型的分布式存儲數據庫。每張表的數據，是按照RowKey的字典順序排序的，因此，如果按照某個指定的RowKey去查詢數據，或者指定某一個RowKey范圍去掃描數據時，HBase可以快速定位到需要讀取的數據位置，從而可以高效地獲取到所需要的數據。
? 在實際應用中，很多場景是查詢某一個列值為XXX的數據。HBase提供了Filter特性去支持這樣的查詢，它的原理是：按照RowKey的順序，去遍歷所有可能的數據，再依次去匹配那一列的值，直到獲取到所需要的數據。可以看出，可能僅僅為了獲取一行數據，它卻掃描了很多不必要的數據。因此，如果對于這樣的查詢請求非常頻繁并且對查詢性能要求較高，使用Filter無法滿足這個需求。
這就是HBase二級索引產生的背景。二級索引為HBase提供了按照某些列的值進行索引的能力。

一般HBase的查詢都是通過RowKey(要把多條件組合查詢的字段都拼接在RowKey中顯然不太可能)，或者全表掃描再結合過濾器篩選出目標數據(太低效)，所以通過設計HBase的二級索引來解決這個問題。
對于HBase而言，如果想精確地定位到某行記錄，唯一的辦法是通過rowkey來查詢。如果不通過rowkey來查找數據，就必須逐行地比較每一列的值，即全表掃瞄。對于較大的表，全表掃瞄的代價是不可接受的。
但是，很多情況下，需要從多個角度查詢數據。例如，在定位某個人的時候，可以通過姓名、身份證號、學籍號等不同的角度來查詢，要想把這么多角度的數據都放到rowkey中幾乎不可能（業務的靈活性不允許，對rowkey長度的要求也不允許）。
所以，需要secondary index來完成這件事。secondary index的原理很簡單，但是如果自己維護的話則會麻煩一些。現在，Phoenix已經提供了對HBase secondary index的支持，下面將說明這樣用Phoenix來在HBase中創建二級索引。
create index my_index on example (m.c0);

HBase FileStream

HBase文件存儲模塊（HBase FileStream，簡稱HFS）是HBase的獨立模塊，它作為對HBase與HDFS接口的封裝，應用在FusionInsight HD的上層應用，為上層應用提供文件的存儲、讀取、刪除等功能。
在Hadoop生態系統中，無論是HDFS，還是HBase，均在面對海量文件的存儲的時候，在某些場景下，都會存在一些很難解決的問題：
? 如果把海量小文件直接保存在HDFS中，會給NameNode帶來極大的壓力。
? 由于HBase接口以及內部機制的原因，一些較大的文件也不適合直接保存到HBase中。
HFS的出現，就是為了解決需要在Hadoop中存儲海量小文件，同時也要存儲一些大文件的混合的
場景。簡單來說，就是在HBase表中，需要存放大量的小文件（10MB以下），同時又需要存放一
些比較大的文件（10MB以上）。
HFS為以上場景提供了統一的操作接口，這些操作接口與HBase的函數接口類似。
注意事項
? 如果只有小文件，確定不會有大文件的場景下，建議使用HBase的原始接口進行操作。
? HFS接口需要同時對HBase和HDFS進行操作，所以客戶端用戶需要同時擁有這兩個組件的操作權限。
? 直接存放在HDFS中的大文件，HFS在存儲時會加入一些元數據信息，所以存儲的文件不是直接等于原文件的。不能直接從HDFS中移動出來使用，而需要用HFS的接口進行讀取。
? 使用HFS接口存儲在HDFS中的數據，暫不支持備份與容災。

HBASE+Solr全文檢索

背景
某電信項目中采用HBase來存儲用戶終端明細數據，供前臺頁面即時查詢。HBase無可置疑擁有其優勢，但其本身只對rowkey支持毫秒級的快速檢索，對于多字段的組合查詢卻無能為力。針對HBase的多條件查詢也有多種方案，但是這些方案要么太復雜，要么效率太低，本文只對基于Solr的HBase多條件查詢方案進行測試和驗證。
原理
基于Solr的HBase多條件查詢原理很簡單，將HBase表中涉及條件過濾的字段和rowkey在Solr中建立索引，通過Solr的多條件查詢快速獲得符合過濾條件的rowkey值，拿到這些rowkey之后在HBASE中通過指定rowkey進行查詢。

HBase與Solr系統架構設計
使用HBase搭建結構數據存儲云，用來存儲海量數據；使用SolrCloud集群用來搭建搜索引擎，將要查找的結構化數據的ID查找出來，只配置它存儲ID。

wd代表用戶write data寫數據，從用戶提交寫數據請求wd1開始，經歷wd2，寫入MySQL數據庫，或寫入結構數據存儲云中，wd3，提交到Solr集群中，從而依據業務需求創建索引。
rd代表用戶read data讀數據，從用戶提交讀數據請求rd1開始，經歷rd2，直接讀取MySQL中數據，或向Solr集群請求搜索服務，rd3，向Solr集群請求得到的搜索結果為ID，再向結構數據存儲云中通過ID取出數據，最后返回給用戶結果。

實現方法有兩種
手工編碼，直接用HBASE的API，可以參考下文
http://www.cnblogs.com/chenz/articles/3229997.html
可以使用HBASE/Solr的LUNA接口，就不用自己管理兩者。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的HBase详细说明的全部內容，希望文章能夠幫你解決所遇到的問題。

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