HBase詳細說明

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接口，就不用自己管理兩者。