hbase的內部機制--存儲機制-region概念-store概念-memstore概念
hbase的物理存儲方式
Hbase是一個集羣，master在數據管理裏面是沒有任何功能的，表在hbase裏面存儲，每一個regionserver是否要響應機器，
hbase的存儲機制
hbase的內部機制--存儲機制-region概念-store概念-memstore概念
一臺機器能搞定，則就不需要集羣，但是高併發的訪問，是負載不過來的，所以一臺機器是處理不了所
有的io請求，必須獲取到資源的才能先訪問，所以不能實時的獲取數據，所以regionServer不可能響應
所以客戶端的請求，則需要分開，通過多臺機器存儲下來，劃分區域，每臺機器管一個區，region就是
在regionserver機器上，但是數據存儲是在hdfs之上，regionserver與hdfs之間是透明的，根本不知道
這些機器的存儲，regionserver只是管理區域範圍，但是不存儲數據，，每一個region都有一個STORE
就是一個列簇，目錄名和列簇名是一樣的，store裏面還有一個manstore是內存緩衝區，存儲的是熱數
據，(用戶經常訪問的，操作過的，正在被訪問的數據)，要請求某數據，則會直接與相應的
regionServer進行關聯，但是如果突然機器掛了，manstore的緩存就會丟了，讀的話沒什麼影響，但是
寫呢，就會有影響，因爲寫的是先在緩存裏面達到伐值後，才能寫入hdfs中，掛了如何保證數據不丟失
，如何解決呢?可以用log日記，log也是存儲在hdfs之上，(真是數據和操作日記都存儲在hdfs之上)，
如果掛了，則資源被重新分配，如果一臺機器起來，接管了region，則region裏面是否需要預先加載數
據，重新分配相當於繼承遺產，向外報告一聲，所有都歸我了，regionserver找數據是先找manstore，
此時manstore裏面是一個空的，沒有任何的數據，一個空的如何找，但是他會和hdfs交互，交互則會讀
取數據，將數據讀取到manstore裏面，先將先將我文件上lonkey的數據讀過來，然後找到log的數據，
每一次log裏面保存的都是最新的操作，將log裏面的操作再一次寫到內存中，如果是一個權限的，是不
需要加載數據，如果客戶端發送請求的，先去manstore，如果沒有，則regionserver就會去找hdfs，把
這條lowkey的數據讀出來，讀出來後再去翻看log，有沒有對我這條lowkey進行的操作，將所有對
lowkey的操作在內存讀了一遍，此時的數據是最新的，將返回客戶端請求的數據。
hbase的內部機制--數據可靠性--快速訪問memstore-storefile
如果達到128M，則落地到hdfs，但是寫完之後，manstore就會立馬清空，清空之後，請求的getput的
lowkey的值又沒有數據的，沒有數據就再重複先hdfs上去，將log在內存執行一次，manstore始終保留
最新的數據，就是所謂的實時訪問，依賴於manstore
regionserver與hdfs的交互--確定數據存儲在那個文件
regionserver與hdfs的交互不可能將所有的數據都緩存起來的，一個manstore裏面就是一個文件，如果
能確定rowkey在哪個範圍，則交互的時候讀取的時候就比較快，所以用哪個機制來判斷包含哪個rowkey
或者不包含哪個rowkey，需要用到bloomfilter過濾器（犧牲數據的準確率，來達到急劇縮小內存空間
的 存儲換來存儲空間的節約），(做一個hashcode取模)這樣就可以確認在哪些文件內，則直接讀取文
件，這樣大的數據就輕鬆的存儲了
bloomfilter過濾器
最找應用於爬蟲項目，爬過的就不需要再爬了，
hbase的內部機制--存儲機制--region的膨脹、分裂、負載均衡
如果膨脹了則對半切，平方任務，兩個region，一分爲二是由regionserver來切的，剛開始還是由原來
的regionserver管理，定時向master報告負載情況，切成兩個之後，分一個給別的regionserver,這就
是region的膨脹分裂
hbase的尋址機制
數據的查找，客戶端的請求需要知道是哪個regionserver管理的，如何去找呢？每一個範圍就是一個region，每一個regionserver裏面存儲着region，但是客戶端請求一個數據，到底到哪裏去請求呢，regionserver是管理的，可以將表明-編號-等信息寫到一個region裏面，描述region的位置，先讀取所在region位置的信息，再讀取region裏面的內容，整個就是一個meta，將meta存儲到zookeeper裏面，但是數據不斷增多呢，則很快也存完了，又回到了找不到的問題上，所以用到二級索引表，也就是root表，
1、尋找第一步先找zookeeper，獲取到root表的位置，2、再依據root表的所在的regionserver，返回mate表的位置，客戶端拿到位置後，3、與mate交互，返回實質數據的管理位置，4、與數據所在region交互，5、regionserver會將io發送到對應的region上面，對應的region就會找它的manstore，如果manstore有數據就會返回，如果沒有呢regionserver就要和hdfs進行交互，交互就是要獲取到rowkey的數據，讀取過來後，先將數據寫到manstore裏，然後再返回到客戶端。（既要讀數據也要讀操作日記）
如果客戶端一直都在查詢這幾條數據，客戶端是可以緩存region的位置信息，客戶端發請求，先看客戶端緩存，如果有則返回，如果沒有再與hdfs交互，保存返回。
但是萬一機器掛了呢？怎麼辦，一般是找這個位置重複三次，如果三次都不行，則客戶端將緩存幹掉，去重新找，（因爲機器掛了，master會重新分配），
hmaster：
分配region（開始的時候默認整個大表是一個region，如果master沒有了，則不能分配）
監控regionserver的負載均衡
合併之後垃圾回收（文件的合併，因爲數據都是一個個的128M數據，但是不適合存儲小文件，所以要合併，所有的小文件都可以做垃圾回收）
schema(如何和zookeeper直接交互，就不需要master,必須有這種結構化信息)
hregionserver的功能如下：
管理region
處理客戶端的IO請求
負責切分變大的region
與hdfs交互
0.96版本之後，是沒有root表了，因爲經過多年的時間，任務mate表不會超過10g
實際的region的split過程：
128M*2^(n-1) > 10G ? 10G,128M*2^(n-1)
切的次數的方數乘以128M，每塊的大小，與10G進行比較，就可以算出操作多少次比10G大
rowKey：rk00001 base_info:name：gaoyuanyuan
hbase、hive和hdfs的關係
mysql的結構上固定的，hbase的列是可以擴展的，隨着需求的增加可以動態的增加列