hbase數據原理及基本架構
hbase是apache hadoop生態系統中的重要一員，主要用於海量結構化數據存儲
從邏輯上講，hbase將數據按照表、行和列進行存儲
hbase表特點：
1.大：一個表可以有數十億行，上百萬列；
2.無模式：每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態的增加，同一張表中不同的行可以有截然不同的列；
3.面向列：面向列（族）的存儲和權限控制，列（族）獨立檢索；
4.稀疏：對於空（null）的列，並不占用存儲空間，表可以設計的非常稀疏；
5.數據多版本：每個單元中的數據可以有多個版本，默認情況下版本號自動分配，是單元格插入時的時間戳；
6.數據類型單一：hbase中的數據都是字符串，沒有類型
hbase與hdfs的對比：
1.兩者都具有良好的容錯性和擴展性，都可以擴展到成百上千個節點。
2.hdfs適合批處理場景,不支持數據隨機查找，不適合增量數據處理，不支持數據更新。
行存儲與列存儲：
傳統行式數據庫：
1.數據是按行存儲的
2.沒有索引的查詢使用大量I/O
3.建立索引和物化視圖需要花費大量時間和資源
4.面向查詢的需求，數據庫必須被大量膨脹才能滿足性能要求
列式數據庫:
1.數據是按列存儲-每一列單獨存放
2.數據即是索引
3.指訪問查詢涉及的列-大量降低系統I/O
4.每一列由一個線索來處理-查詢的並發處理
5.數據類型一致，數據特征相似-高效壓縮
第二：hbase數據模型
hbase是基於Google BigTable模型開發的，典型的key/value系統
第一：hbase介紹
hbase是一個構建在hdfs上的分布式列存儲系統；
hbase是apache hadoop生態系統中的重要一員，主要用於海量結構化數據存儲
從邏輯上講，hbase將數據按照表、行和列進行存儲
hbase表特點：
1.大：一個表可以有數十億行，上百萬列；
2.無模式：每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態的增加，同一張表中不同的行可以有截然不同的列；
3.面向列：面向列（族）的存儲和權限控制，列（族）獨立檢索；
4.稀疏：對於空（null）的列，並不占用存儲空間，表可以設計的非常稀疏；
5.數據多版本：每個單元中的數據可以有多個版本，默認情況下版本號自動分配，是單元格插入時的時間戳；
6.數據類型單一：hbase中的數據都是字符串，沒有類型
hbase與hdfs的對比：
1.兩者都具有良好的容錯性和擴展性，都可以擴展到成百上千個節點。
2.hdfs適合批處理場景,不支持數據隨機查找，不適合增量數據處理，不支持數據更新。
行存儲與列存儲：
傳統行式數據庫：
1.數據是按行存儲的
2.沒有索引的查詢使用大量I/O
3.建立索引和物化視圖需要花費大量時間和資源
4.面向查詢的需求，數據庫必須被大量膨脹才能滿足性能要求
列式數據庫:
1.數據是按列存儲-每一列單獨存放
2.數據即是索引
3.指訪問查詢涉及的列-大量降低系統I/O
4.每一列由一個線索來處理-查詢的並發處理
5.數據類型一致，數據特征相似-高效壓縮
第二：hbase數據模型
hbase是基於Google BigTable模型開發的，典型的key/value系統
第三：hbase物理模型
每個column family存儲在HDFS上的一個單獨文件中；
Key和Version number在每個column family中均有一份
空值不被保存
eg:
info Column Family:
roles Column Family
數據物理存儲：
1.Table中所有的行都按照row key的字典序列排列；
2.Table在行的方向上被分割為多個Region；
3.Region按照大小分割的，每個表開始只有一個region，隨著數據的增多，region不斷的增大，當增大到一個閥值的時候，region就會等分成兩個新的region，之後會有越來越多的region；
4.Region是Hbase中分布式存儲和負載均衡的最小單元，不同的region分布在不同RegionServer上；
5.Region雖然是分布式存儲的最小單元，但並不是存儲的最小單元。
1）Region是由一個或者多個Store組成，每個store保存一個columns family；
2）每個Store又由一個memStore和0或多個StoreFile組成
3）memStore存儲在內存中，StoreFile存儲在HDFS上。
第四：hbase基礎架構
Hbase架構：
在分布式的生產環境中，HBase 需要運行在 HDFS 之上，以 HDFS 作為其基礎的存儲設施。在 HBase 的集群中主要由 Master 和 Region Server 組成，以及 Zookeeper
Hbase相關的組件：
Clinet：
包含訪問Hbase的接口，並維護cache來加快對Hbase的訪問。
zookeeper:
保證任何時候，集群中只有一個master
存儲所有Region的尋址入口
實時監控Region Server的上線或者下線信息，並實時通知給Master
存儲HBase的schema和table元數據
zookeeper作用：
HBase依賴zk；
默認情況下Hbase管理zk實例，eg：啟動或者停止zk
Master與RegionServers啟動時會向zk註冊
Zookeeper的引入使得Master不在是單點故障
Master:
為Region Server分配region
負責Region Server的負載均衡
發現失效的Region Server並重新分配他上面的region
管理用戶對table的增刪改查操作
Region Server:
維護region，處理對這些region的IO請求
負責切分在運行過程中變得過大的region
-ROOT-表與-META-表：
-ROOT-表：
包含-META-表所在的region列表，該表只會有一個Region；
zookeeper中記錄了-ROOT-表的位置
-META-表：
包含所有的用戶空間region列表，以及RegionServer的服務器地址
詳解：
1.HBase的所有Region元數據被存儲在.META.表中，隨著Region的增多，.META.表中的數據也會增大，並分裂成多個新的Region。為了定位.META.表中各個Region的位置，把.META.表中所有Region的元數據保存在-ROOT-表中，最後由Zookeeper記錄-ROOT-表的位置信息。所有客戶端訪問用戶數據前，需要首先訪問Zookeeper獲得-ROOT-的位置，然後訪問-ROOT-表獲得.META.表的位置，最後根據.META.表中的信息確定用戶數據存放的位置，如上圖所示。
2.-ROOT-表永遠不會被分割，它只有一個Region，這樣可以保證最多只需要三次跳轉就可以定位任意一個Region。為了加快訪問速度，.META.表的所有Region全部保存在內存中。客戶端會將查詢過的位置信息緩存起來，且緩存不會主動失效。如果客戶端根據緩存信息還訪問不到數據，則詢問相關.META.表的Region服務器，試圖獲取數據的位置，如果還是失敗，則詢問-ROOT-表相關的.META.表在哪裏。最後，如果前面的信息全部失效，則通過ZooKeeper重新定位Region的信息。所以如果客戶端上的緩存全部是失效，則需要進行6次網絡來回，才能定位到正確的Region。
高可用
Write-Ahead-Log（WAL）保障數據高可用
理解高可用首先：必須理解下HLog的作用，HBase中的Hlog機制是WAL的一種實現，而WAL是事務機制中常見的一致性的實現方式。每個RegionServer中都會有一個HLog的實例，RegionServer會將更新操作（put，delete等），先記錄到WAL（也就是HLog中），然後再將其寫入到Store的MemStore，最終Memstore達到一定的閥值後，在寫入到HFile中，這樣就保證了HBase的寫的可靠性，若沒有WAL，當RegionServer掛掉的時候，MemStore還沒有寫到HFile的數據，或者說StoreFile沒有保存的時候，數據會丟失。（說到這裏或許有人會問，假如HFile本身丟失了怎麽辦，這是由HDFS來保證的。在HDFS中的數據默認會有3份）
HFile是由很多個數據塊（Block）組成，並且有一個固定的結尾塊，其中的數據塊是由一個Header和多個Key-Value的鍵值對組成，在結尾的數據塊中包含了數據相關的索引信息，系統也是通過結尾的索引信息找到HFile中的數據。
組件的高可用
Master容錯：Zookeeper重新選擇一個新的Master
無Master過程中，數據讀取任然照常進行
無Master過程中，region切分、負載均衡等無法進行
RegionServer容錯：
定時向Zookeeper匯報心跳，如果一旦一段時間內未出現心跳，Master將該RegionServer上的Region重新分配到其他的RegionServer上；
失效的服務器上“預寫”日誌由主服務器進行分割並派送給新的RegionServer上
zookeeper容錯：zookeeper是一個可靠的服務
一般是3到5個zookeeper實例
讀寫流程
寫操作：
1）client通過zookeeper的調度，向regionserver發出寫數據的請求，在Region中寫數據
2）數據首先記錄在HLog中，然後再將其寫入到Store的MemStore，直到MemStore達到預定閥值
3）MemStore中的數據被Flush成一個StoreFile
4）隨著StoreFile文件的不斷增多，當其數據增長到一定閥值後，觸發Compact合並操作，將多個StoreFile合並成一個StoreFile，同時進行版本合並和數據刪除
5）StoreFiles通過不斷的Compact合並操作，逐步形成越來越大的StoreFile
6）單個StoreFile大小超過一定閥值後，觸發Split操作，把當前Region Split成2個新的Region，父Region會下線，新Split出的2個子Region會被HMaster分配到相應的RegionServer上，使原先1個Region的壓力得以分流到2個Region上面
通過上述的寫流程可以發現，HBase更新、刪除等操作都是在後續Compact歷程中進行的，使得用戶的寫操作只要進入內存就可以立刻返回，實現可HBase I/0的高性能。
讀操作：
1）client訪問zk，查找-ROOT-表，獲取.META.表的信息。
2）從.META.表查找，獲取存放目標數據的Region信息，從而找到對應的RegionServer。
3）通過RegionServer獲取需要查找的數據
4）RegionServer的內存分為MemStore和BlockCache兩部分，MemStore主要用於寫數據，BlockCache主要用於讀數據，讀請求先到MemStore中查數據，查不到就到BlockCache中查，在查不到就會到StoreFile上讀，並把讀的結果放入BlockCache中。
讀取流程：client-->zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client
hbase數據原理及基本架構