1.為什么要按列存儲
列式存儲(Columnar or column-based)是相對於傳統關系型數據庫的行式存儲(Row-basedstorage)來說的。簡單來說兩者的區別就是如何組織表：
Ø Row-based storage stores atable in a sequence of rows.
Ø Column-based storage storesa table in a sequence of columns.
行式存儲下一張表的數據都是放在一起的，但列式存儲下都被分開保存了
|
|
行式存儲 |
列式存儲 |
| 優點 |
Ø 數據被保存在一起 Ø INSERT/UPDATE容易 |
Ø 查詢時只有涉及到的列會被讀取 Ø 投影(projection)很高效 Ø 任何列都能作為索引 |
| 缺點 |
Ø 選擇(Selection)時即使只涉及某幾列，所有數據也都會被讀取 |
Ø 選擇完成時，被選擇的列要重新組裝 Ø INSERT/UPDATE比較麻煩 |
注：關系型數據庫理論回顧 - 選擇(Selection)和投影(Projection)
數據壓縮：通過字典表壓縮數據
下面才是那張表本來的樣子。經過字典表進行數據壓縮后，表中的字符串才都變成數字了。正因為每個字符串在字典表里只出現一次了，所以達到了壓縮的目的(有點像規范化和非規范化Normalize和Denomalize)
查詢執行性能
通過一條查詢的執行過程說明列式存儲(以及數據壓縮)的優點：
關鍵步驟如下：
1. 去字典表里找到字符串對應數字(只進行一次字符串比較)。
2. 用數字去列表里匹配，匹配上的位置設為1。
3. 把不同列的匹配結果進行位運算得到符合所有條件的記錄下標。
4. 使用這個下標組裝出最終的結果集。
Hbase簡介
HBase是一個開源的非關系型分布式數據庫（NoSQL），它參考了谷歌的BigTable建模，實現的編程語言為 Java。
它是Apache軟件基金會的Hadoop項目的一部分，運行於HDFS文件系統之上，為 Hadoop 提供類似於BigTable 規模的服務。
因此，它可以容錯地存儲海量稀疏的數據。
HBase在列上實現了BigTable論文提到的壓縮算法、內存操作和布隆過濾器。
HBase的表能夠作為MapReduce任務的輸入和輸出，可以通過Java API來存取數據，也可以通過REST、Avro或者Thrift的API來訪問。
Hbase是bigtable的開源版本，是建立的hdfs之上，提供高可靠性、高性能、列存儲、可伸縮、實時讀寫的數據庫系統。
它介於nosql和RDBMS之間，僅能通過主鍵(row key)和主鍵的range來檢索數據，僅支持單行事務(可通過hive支持來實現多表join等復雜操作)，主要用來存儲非結構化和半結構化的松散數據。
與hadoop一樣，Hbase目標主要依靠橫向擴展，通過不斷增加廉價的商用服務器，來增加計算和存儲能力。
Hbase中的表一般有這樣的特點：
- 大：一個表可以有上億行，上百萬列
- 面向列:面向列(族)的存儲和權限控制，列(族)獨立檢索。
- 稀疏:對於為空(null)的列，並不占用存儲空間，因此，表可以設計的非常稀疏。
Hbase在Hadoop Ecosystem中的位置
邏輯視圖
Hbase以表的形式存儲數據。表有行和列組成。列划分為若干個列族(row family)
Row Key:
與nosql數據庫們一樣,row key是用來檢索記錄的主鍵。
訪問Hbase table中的行，只有三種方式：
- 通過單個row key訪問
- 通過row key的range
- 全表掃描
Row key行鍵 (Row key)可以是任意字符串(最大長度是 64KB，實際應用中長度一般為 10-100bytes)，在Hbase內部，row key保存為字節數組。
存儲時，數據按照Row key的字典序(byte order)排序存儲。
設計key時，要充分排序存儲這個特性，將經常一起讀取的行存儲放到一起。(位置相關性)
字典序對int排序的結果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。
要保持整形的自然序，行鍵必須用0作左填充。
行的一次讀寫是原子操作 (不論一次讀寫多少列)。這個設計決策能夠使用戶很容易的理解程序在對同一個行進行並發更新操作時的行為。
列族:
Hbase表中的每個列，都歸屬與某個列族。
列族是表的chema的一部分(而列不是)，必須在使用表之前定義。
列名都以列族作為前綴。例如courses:history，courses:math 都屬於courses 這個列族。
訪問控制、磁盤和內存的使用統計都是在列族層面進行的。
實際應用中，列族上的控制權限能幫助我們管理不同類型的應用：我們允許一些應用可以添加新的基本數據、一些應用可以讀取基本數據並創建繼承的列族、一些應用則只允許瀏覽數據(甚至可能因為隱私的原因不能瀏覽所有數據)。
時間戳:
Hbase中通過row和columns確定的為一個存貯單元稱為cell。每個 cell都保存着同一份數據的多個版本。版本通過時間戳來索引。
時間戳的類型是 64位整型。
時間戳可以由Hbase(在數據寫入時自動 )賦值，此時時間戳是精確到毫秒的當前系統時間。
時間戳也可以由客戶顯式賦值。如果應用程序要避免數據版本沖突，就必須自己生成具有唯一性的時間戳。
每個 cell中，不同版本的數據按照時間倒序排序，即最新的數據排在最前面。
為了避免數據存在過多版本造成的的管理 (包括存貯和索引)負擔，Hbase提供了兩種數據版本回收方式。
一是保存數據的最后n個版本，
二是保存最近一段時間內的版本(比如最近七天)。
用戶可以針對每個列族進行設置。
Cell:
由{row key, column(= + ), version} 唯一確定的單元。
cell中的數據是沒有類型的，全部是字節碼形式存貯
物理存儲
1 、Table中的所有行都按照row key的字典序排列。
2 、Table 在行的方向上分割為多個Hregion。
3、region按大小分割的，
每個表一開始只有一個region，隨着數據不斷插入表，region不斷增大，
當增大到一個閥值的時候，Hregion就會等分會兩個新的Hregion。
當table中的行不斷增多，就會有越來越多的Hregion。
4、HRegion是Hbase中分布式存儲和負載均衡的最小單元。
最小單元就表示不同的Hregion可以分布在不同的HRegion server上。但一個Hregion是不會拆分到多個server上的。
5、HRegion雖然是分布式存儲的最小單元，但並不是存儲的最小單元。
事實上，HRegion由一個或者多個Store組成，每個store保存一個columns family。
每個Strore又由一個memStore和0至多個StoreFile組成。如圖：StoreFile以HFile格式保存在HDFS上。
Hfile的格式如下圖所示：
HFile分為六個部分：
- Data Block 段–保存表中的數據，這部分可以被壓縮。
- Meta Block 段 (可選的)–保存用戶自定義的kv對，可以被壓縮。
- File Info 段–Hfile的元信息，不被壓縮，用戶也可以在這一部分添加自己的元信息。
- Data Block Index 段–Data Block的索引。每條索引的key是被索引的block的第一條記錄的key。
- Meta Block Index段 (可選的)–Meta Block的索引。
- Trailer– 這一段是定長的。保存了每一段的偏移量，讀取一個HFile時，會首先讀取Trailer，Trailer保存了每個段的起始位置(段的Magic Number用來做安全check)，然后，DataBlock Index會被讀取到內存中，這樣，當檢索某個key時，不需要掃描整個HFile，而只需從內存中找到key所在的block，通過一次磁盤io將整個block讀取到內存中，再找到需要的key。DataBlock Index采用LRU機制淘汰(LRU是Least Recently Used的縮寫，即最近最久未使用，常用於頁面置換算法，是為虛擬頁式存儲管理服務)。
HFile的Data Block，Meta Block通常采用壓縮方式存儲，壓縮之后可以大大減少網絡IO和磁盤IO，隨之而來的開銷當然是需要花費cpu進行壓縮和解壓縮。
目前Hfile的壓縮支持兩種方式：Gzip，Lzo。
首先HFile文件是不定長的，長度固定的只有其中的兩塊：Trailer和FileInfo。
正如圖中所示的，Trailer中有指針指向其他數據塊的起始點。
File Info中記錄了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等。
Data Index和Meta Index塊記錄了每個Data塊和Meta塊的起始點。
Data Block是HBase I/O的基本單元，為了提高效率，HRegionServer中有基於LRU的Block Cache機制。
每個Data塊的大小可以在創建一個Table的時候通過參數指定，大號的Block有利於順序Scan，小號Block利於隨機查詢。
每個Data塊除了開頭的Magic以外就是一個個KeyValue對拼接而成,
Magic內容就是一些隨機數字，目的是防止數據損壞。
HFile里面的每個KeyValue對就是一個簡單的byte數組。
但是這個byte數組里面包含了很多項，並且有固定的結構。我們來看看里面的具體結構：
開始是兩個固定長度的數值，分別表示Key的長度和Value的長度。
緊接着是Key
-
- 開始是固定長度的數值，表示RowKey的長度，
- 緊接着是RowKey，
- 然后是固定長度的數值，表示Family的長度，
- 然后是Family，
- 接着是Qualifier，
- 然后是兩個固定長度的數值，表示Time Stamp和Key Type（Put/Delete）。
Value部分沒有這么復雜的結構，就是純粹的二進制數據了。
HLog(WAL log)：
WAL 意為Write ahead log(http://en.wikipedia.org/wiki/Write-ahead_logging)，類似mysql中的binlog,用來做災難恢復只用，
Hlog記錄數據的所有變更,一旦數據修改，就可以從log中進行恢復。
每個Region Server維護一個Hlog,而不是每個Region一個。
優點：這樣不同region(來自不同table)的日志會混在一起，這樣做的目的是不斷追加單個文件相對於同時寫多個文件而言，可以減少磁盤尋址次數，因此可以提高對table的寫性能。
缺點：帶來的麻煩是，如果一台region server下線，為了恢復其上的region，需要將region server上的log進行拆分，然后分發到其它region server上進行恢復。
HLog文件就是一個普通的Hadoop Sequence File，
Sequence File 的Key是HLogKey對象，
-
- HLogKey中記錄了寫入數據的歸屬信息，
- 除了table和region名字外，
- 同時還包括 sequence number和timestamp，timestamp是”寫入時間”，sequence number的起始值為0，或者是最近一次存入文件系統中sequence number。
HLog Sequece File的Value是Hbase的KeyValue對象，即對應HFile中的KeyValue。
系統架構
Client：
包含訪問Hbase的接口，
client維護着一些cache來加快對Hbase的訪問，比如regione的位置信息。
Zookeeper：
- 保證任何時候，集群中只有一個master
- 存貯所有Region的尋址入口。
- 實時監控Region Server的狀態，將Region server的上線和下線信息實時通知給Master
- 存儲Hbase的schema,包括有哪些table，每個table有哪些column family
HMaster:
- 為Region server分配region，負責region server的負載均衡
- 管理用戶對Table的增、刪、改、查操作
- 發現失效的region server並重新分配其上的region
- GFS上的垃圾文件回收
- 在HRegionServer停機后，負責失效HRegionServer 上的Regions遷移
可以看到，client訪問Hbase上數據的過程並不需要master參與(尋址訪問zookeeper和region server，數據讀寫訪問regione server)，master僅僅維護者table和region的元數據信息，負載很低。
HRegionServer
- Region server維護Master分配給它的region，處理對這些region的IO請求
- Region server負責切分在運行過程中變得過大的region
HRegionServer主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據，是HBase中最核心的模塊。
HRegionServer內部管理了一系列HRegion對象，
每個HRegion對應了Table中的一個Region，
HRegion中由多個HStore組成。
每個HStore對應了Table中的一個Column Family的存儲，可以看出每個Column Family其實就是一個集中的存儲單元，因此最好將具備共同IO特性的column放在一個Column Family中，這樣最高效。
HStore存儲是HBase存儲的核心了，其中由兩部分組成，一部分是MemStore，一部分是StoreFiles。
MemStore是Sorted Memory Buffer，
用戶寫入的數據首先會放入MemStore，
當MemStore滿了以后會Flush成一個StoreFile（底層實現是HFile），
當StoreFile文件數量增長到一定閾值，會觸發Compact合並操作，將多個StoreFiles合並成一個StoreFile，合並過程中會進行版本合並和數據刪除，
因此可以看出HBase其實只有增加數據，所有的更新和刪除操作都是在后續的compact過程中進行的，這使得用戶的寫操作只要進入內存中就可以立即返回，保證了HBase I/O的高性能。
當StoreFiles Compact后，會逐步形成越來越大的StoreFile，
當單個StoreFile大小超過一定閾值后，會觸發Split操作，
同時把當前Region Split成2個Region，父Region會下線，
新Split出的2個孩子Region會被HMaster分配到相應的HRegionServer上，使得原先1個Region的壓力得以分流到2個Region上。
下圖描述了Compaction和Split的過程：
在理解了上述HStore的基本原理后，還必須了解一下HLog的功能，因為上述的HStore在系統正常工作的前提下是沒有問題的，但是在分布式系統環境中，無法避免系統出錯或者宕機，因此一旦HRegionServer意外退出，MemStore中的內存數據將會丟失，這就需要引入HLog了。
每個HRegionServer中都有一個HLog對象，
HLog是一個實現Write Ahead Log的類，
在每次用戶操作寫入MemStore的同時，也會寫一份數據到HLog文件中（HLog文件格式見后續），
HLog文件定期會滾動出新的，並刪除舊的文件（已持久化到StoreFile中的數據）。
當HRegionServer意外終止后，HMaster會通過Zookeeper感知到，
HMaster首先會處理遺留的 HLog文件，
將其中不同Region的Log數據進行拆分，分別放到相應region的目錄下，
然后再將失效的region重新分配，
領取到這些region的HRegionServer在Load Region的過程中，會發現有歷史HLog需要處理，因此會Replay HLog中的數據到MemStore中，然后flush到StoreFiles，完成數據恢復。
MapReduce on HBase
在HBase系統上運行批處理運算，最方便和實用的模型依然是MapReduce，如下圖：
關鍵算法/流程
region定位
系統如何找到某個row key (或者某個 row key range)所在的region ？bigtable 使用三層類似B+樹的結構來保存region位置：
- 第一層是保存zookeeper里面的文件，它持有root region的位置。
- 第二層root region是.META.表的第一個region其中保存了.META.z表其它region的位置。通過root region，我們就可以訪問.META.表的數據。
- 第三層是.META.，它是一個特殊的表，保存了Hbase中所有數據表的region 位置信息。
說明：
- root region永遠不會被split，保證了最多需要三次跳轉，就能定位到任意region 。
- META.表每行保存一個region的位置信息，row key 采用表名+表的最后一樣編碼而成。
- 為了加快訪問，.META.表的全部region都保存在內存中。
- client會將查詢過的位置信息保存緩存起來，緩存不會主動失效，因此如果client上的緩存全部失效，則需要進行6次網絡來回，才能定位到正確的region(其中三次用來發現緩存失效，另外三次用來獲取位置信息)。
假設，.META.表的一行在內存中大約占用1KB。並且每個region限制為128MB。那么上面的三層結構可以保存的region數目為：
|
(128MB/1KB) * (128MB/1KB) = = 2(34)個region
|
讀寫過程介紹
上文提到，Hbase使用MemStore和StoreFile存儲對表的更新。
數據在更新時：
- 首先寫入Log(WAL log)和內存(MemStore)中，MemStore中的數據是排序的，
- 當MemStore累計到一定閾值時，就會創建一個新的MemStore，並且將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成為一個StoreFile。
- 於此同時，系統會在zookeeper中記錄一個redo point，表示這個時刻之前的變更已經持久化了。(minor compact)
當系統出現意外時，可能導致內存(MemStore)中的數據丟失，此時使用Log(WAL log)來恢復checkpoint之后的數據。
前面提到過StoreFile是只讀的，一旦創建后就不可以再修改。因此Hbase的更新其實是不斷追加的操作。
- 當一個Store中的StoreFile達到一定的閾值后，就會進行一次合並(major compact),將對同一個key的修改合並到一起，形成一個大的StoreFile，
- 當StoreFile的大小達到一定閾值后，又會對StoreFile進行split，等分為兩個StoreFile。
由於對表的更新是不斷追加的，處理讀請求時，
- 需要訪問Store中全部的StoreFile和MemStore，
- 將他們的按照row key進行合並，由於StoreFile和MemStore都是經過排序的，
- 並且StoreFile帶有內存中索引，合並的過程還是比較快。
寫請求處理過程：
- client向region server提交寫請求
- region server找到目標region
- region檢查數據是否與schema一致
- 如果客戶端沒有指定版本，則獲取當前系統時間作為數據版本
- 將更新寫入WAL log
- 將更新寫入Memstore
- 判斷Memstore的是否需要flush為Store文件。
region分配
任何時刻，一個region只能分配給一個region server。
master記錄了當前有哪些可用的region server。以及當前哪些region分配給了哪些region server，哪些region還沒有分配。
當存在未分配的region，並且有一個region server上有可用空間時，master就給這個region server發送一個裝載請求，把region分配給這個region server。region server得到請求后，就開始對此region提供服務。
region server上線
master使用zookeeper來跟蹤region server狀態。
- 當某個region server啟動時，會首先在zookeeper上的server目錄下建立代表自己的文件，並獲得該文件的獨占鎖。
- 由於master訂閱了server目錄上的變更消息，當server目錄下的文件出現新增或刪除操作時，master可以得到來自zookeeper的實時通知。因此一旦region server上線，master能馬上得到消息。
region server下線
當region server下線時，它和zookeeper的會話斷開，zookeeper而自動釋放代表這台server的文件上的獨占鎖。
而master不斷輪詢server目錄下文件的鎖狀態。如果master發現某個region server丟失了它自己的獨占鎖，(或者master連續幾次和region server通信都無法成功),master就是嘗試去獲取代表這個region server的讀寫鎖，一旦獲取成功，就可以確定：
- region server和zookeeper之間的網絡斷開了。
- region server掛了。
的其中一種情況發生了，無論哪種情況，region server都無法繼續為它的region提供服務了，此時master會刪除server目錄下代表這台region server的文件，並將這台region server的region分配給其它還活着的同志。
如果網絡短暫出現問題導致region server丟失了它的鎖，那么region server重新連接到zookeeper之后，只要代表它的文件還在，它就會不斷嘗試獲取這個文件上的鎖，一旦獲取到了，就可以繼續提供服務。
master上線
master啟動進行以下步驟:
- 從zookeeper上獲取唯一一個代碼master的鎖，用來阻止其它master成為master。
- 掃描zookeeper上的server目錄，獲得當前可用的region server列表。
- 和2中的每個region server通信，獲得當前已分配的region和region server的對應關系。
- 掃描.META.region的集合，計算得到當前還未分配的region，將他們放入待分配region列表。
master下線
由於master只維護表和region的元數據，而不參與表數據IO的過程，
master下線僅導致所有元數據的修改被凍結(無法創建刪除表，無法修改表的schema，無法進行region的負載均衡，無法處理region上下線，無法進行region的合並，唯一例外的是region的split可以正常進行，因為只有region server參與)，表的數據讀寫還可以正常進行。
因此master下線短時間內對整個Hbase集群沒有影響。
從上線過程可以看到，master保存的信息全是可以冗余信息(都可以從系統其它地方收集到或者計算出來)，
因此，一般Hbase集群中總是有一個master在提供服務，還有一個以上的”master”在等待時機搶占它的位置。
訪問接口
- Native Java API，最常規和高效的訪問方式，適合Hadoop MapReduce Job並行批處理HBase表數據
- HBase Shell，HBase的命令行工具，最簡單的接口，適合HBase管理使用
- Thrift Gateway，利用Thrift序列化技術，支持C++，PHP，Python等多種語言，適合其他異構系統在線訪問HBase表數據
- REST Gateway，支持REST 風格的Http API訪問HBase, 解除了語言限制
- Pig，可以使用Pig Latin流式編程語言來操作HBase中的數據，和Hive類似，本質最終也是編譯成MapReduce Job來處理HBase表數據，適合做數據統計
- Hive，當前Hive的Release版本尚沒有加入對HBase的支持，但在下一個版本Hive 0.7.0中將會支持HBase，可以使用類似SQL語言來訪問HBase
hbase 集群的搭建及使用
- 分布式實時日志系統（四） 環境搭建之centos 6.4下hbase 1.0.1 分布式集群搭建 文中介紹了集群的搭建過程，提供了一鍵安裝的腳本。
- 使用Phoenix通過sql語句更新操作hbase數據 文中介紹了如何安裝Phoenix以及使用對hbase進行更新操作。
參考資料：
Apache HBase ™ Reference Guide :http://hbase.apache.org/book.html
http://www.searchtb.com/2011/01/understanding-hbase.html
http://www.cnblogs.com/shitouer/archive/2012/06/04/2533518.html