不同列族分別存在不同的文件夾裏。
與MySQL比較
首先Hbase是依賴於HDFS和zookeeper的。
Zookeeper分擔了Hmaster的壹部分功能，客戶端進行DML語句的時候，都是先跟ZK交互。
RegionServer管理了很多的Region（表），RegionServer裏面的WAL(HLog)是預寫入日誌，功能是防止內存中的數據沒有來的及落盤時丟失。在Region裏面管理的Store管理的是列族，Store裏面有Mem Store（內存），Flush之後，刪除內存中的數據，同時寫入文件StoreFile Hfile,Hfile 其實是在DataNode裏面的。
Hbase的讀比寫慢。
Hbase命名空間下有壹張元數據表meta表和namespace表。meta表裏面保存了要操作的表所在的位置等元數據。
（1）首先客戶端向zk請求元數據表所在的RegionServer，zk返回給客戶端meta表所在的regionServer。
（2）然後客戶端再去對應的RegionServer查找meta表，找到真正要操作的表所在的regionServer，同時把meta表的信息緩存下來，加快後續的查詢。
（3）然後客戶端再向目標表所在的RegionServer發送put請求。先把數據寫到Hlog裏面，再寫到內存MemStore,數據會在內存排序，然後向客戶端發送ack，到這裏對於客戶端來說寫數據已經結束了。再等到MemStore的刷寫時機後，將數據刷寫到Hfile.
註：meta表所在的位置信息保存在zk的meta-region-server節點上，客戶端首先就是在這個節點上差詢meta表所在的RegionServer。meta表裏面的信息就是表與其對應的RegionServer的信息
這個stu表可能不止壹條，因為stu表可能數據量大了之後根據RowKey進行了切分，並且可能會在不同的機器上。
不同的列族是在不同的文件夾。
MemStore刷寫時機：
全局的MemStore的容量，默認是堆內存的40%。這個容量值會觸發flush操作，所有的MemStore都要刷寫，flush操作會阻塞讀寫操作。
會刷寫並阻塞到到MemStore大小降到它的最大容量的95%
WAL日誌的刷寫時機：
可以設置日誌的大小和數量，當達到壹定數量，刷寫到HDFS
（1）從zk找meta表所在的RegionServer
（2）從上述RegionServer裏的meta表裏找目標表所在的RegionServer，同時把meta表緩存，加速後面的查詢。
（3）向目標表所在的RegionServer發送get請求。可以從block Cache，MemStore還有StoreFile裏面查，具體從哪查根據時間戳，查時間戳大的，具體就都查然後merge取最新。
RegionServer裏面有block Cache可以緩存磁盤的數據，加速查詢。如果block Cache裏面有，就將緩存和MemStore的數據merge然後取最新時間戳，沒有就是把磁盤讀的和MemStore裏面的合並。所以hbase大多數讀要走磁盤，所以讀很慢。
每次刷寫會生成新的Hfile，Hfile很小並且數量多的時候會影響查詢的速度。所以要進行合並。合並分為minor Compaction和major Compaction
minor Compaction將臨近的若幹較小的Hfile合並成壹個較大的Hfile，不會清理過期和刪除的數據，major Compaction會將壹個Store裏面的所有Hfile合並成壹個大的Hfile，並且會清理掉過期和刪除的數據。
數據的讀寫可以不依賴Hmaster，只需要指定zookeeper，但是Hmaster負責region調度的元數據
但是DDL語言是要有Hmaster的
Flush和major Compact
（1）flush在同壹個內存中清除過期或刪除（刪除標記也是壹行數據）的數據，但是如果數據不同的版本分布在不同的memStroe，就不能清除。刪除的標記在flush之後不會被刪，但在後面的major compaction會把刪除標記刪除掉。
（2）major compaction 會清除過期或刪除的數據。
默認情況下，每個Table起初只有壹個Region，隨著數據的不斷寫入，Region會自動拆分，兩個子Region開始都會在壹個Regionserver裏面，但是出於負載均衡的考慮，Hmaster有可能會將某個Region傳給其他的RegionServer。
Split的時機：
（1）當壹個Region中的某個Store下的StoreFile的總大小查過某個值，由參數hbase.hregion.max.filesize設定（默認10g），該Region就會按照RowKey進行拆分。
（2）在新版本中這個值是Min（R^2*"hbase.hregion.memStore.flush.size（128M）","hbase.hregion.max.filesize"）,R是當前RegionServer中屬於該Table的Region個數。分region是按照RowKey切分的。這會導致數據傾斜，就是因為切分的閾值在變化，導致切分之後的region數據量不均勻，導致熱點的問題。所以在建表的時候要做預分區，就是用RowKey規劃好多少個region，不讓hbase自己的切分邏輯切分。
官方建議只用壹個列族，防止不同的列族之間數據不均勻，單壹列族數據量增多，導致全局的flush，數據量小的列族也要flush，這樣會形成很多小的storeFile。
delete操作：
（1）設置RowKey：打的刪除標記是deleteFamily，刪除多個版本
（2）設置RowKey+Family：打的標記是deleteFamily，刪除多個版本
（3）設置RowKey+family+column：有addColumn()和addColumns().addColumn是刪除最新的版本或者刪除指定時間戳的版本，刪除標記是delete標記。addColumns是刪除所有的版本或者刪除指定時間戳或之前的版本，刪除標記是deleteColumn
Delete的操作其實也是put操作，put的是刪除的標記。
在Hbase中HMaster負責監控HRegionServer的生命周期，均衡RegionServer的負載，如果HMaster掛掉了，那個整個Hbase集群將處於不健康的狀態，並且此時的工作狀態不會維持太久。所以Hbase支持對HMaster的高可用配置。
在Hbase的conf目錄下新建backup-masters文件，vim加入備份Master，比如slave01,slave02.在把文件分發到各個slave裏，然後再啟動hbase 就能實現HMaster的高可用了。
每壹個region維護著StartRow和EndRow，如果加入的數據符合某個region維護的RowKey範圍，則該數據交給這個region維護。那麽依照這個原則，我們可以將數據所要投放的分區提前大致的規劃好，以提高Hbase性能。
（1）手動設定預分區
手動設置RowKey分了5個region
（2）生成16進制序列預分區
（3）按照文件中設置的規則預分區
創建split.txt
然後執行
這裏如果文件裏面給的分區鍵不是按照順序的，hbase會先幫我們把鍵排序，然後按照鍵來分區。
（4）使用JavaAPI預分區
admin的創建表的方法有多個重載，可以只傳表的描述，也可以加入分區的信息。admin.createTable
規劃分區要考慮未來數據量和機器的規模。雖然提前做了分區，但是最後如果分區大於了10G,還是會觸發split。假設壹臺機器有100G磁盤，那麽預分區盡量大於10個，這樣就能避免預分區之後又觸發了大於10G的split。
（1）希望數據能夠盡量均勻的分配在多個分區裏面（散列性）。
（2）唯壹性
（3）長度原則（生產環境70到100位）
常見的設計方案：
（1）生產隨機數、hash、散列值
（2）字符串反轉
（3）字符串拼接
電信項目：
壹次通話的記錄：13112341233->18998768771 2018-12-12 12:12:21 568
假設分300個區
分區鍵怎麽設計：
（299個鍵）
000|
001|
...
298|
RowKey的前面壹般會拼上000_,001_,...,298_
這樣做的好處是，根據前三位就能知道哪個分區。
（1）我們希望手機號盡量分布在不同的分區，但是相同的手機號數據集中在同壹個分區，這樣方便查詢某個用戶的通話信息。000_13112341233
（2）因為每個人通話的需求不同，也希望把同壹個人的通話記錄也分布在不同的分區裏面。000_13112341233_2019-12-12
哈希取余：[（13112341234^201912）.hash]%299
假設要查詢某用戶2019年2月的通話記錄，可以用13112341234 201902做startRowkey，13112341234 201903做endRowKey
微博。
1、需求
（1）微博內容的瀏覽
（2）用戶社交：關註用戶，取關用戶
（3）拉取關註人的微博用戶
2、設計表
（1）微博內容表Content
行鍵：用戶id+時間戳
（2）用戶關系表
因為正常情況壹個用戶的粉絲和關註都不多，可以用壹行存儲關註和粉絲的情況。
行鍵：用戶id
（3）初始化頁面的表（顯示關註的人的最近三條微博）