① HBase是什麼呢，都有哪些特點呢
Hbase是一種NoSQL資料庫，這意味著它不像傳統的RDBMS資料庫那樣支持SQL作為查詢語言。Hbase是一種分布式存儲的資料庫，技術上來講，它更像是分布式存儲而不是分布式資料庫，它缺少很多RDBMS系統的特性，比如列類型，輔助索引，觸發器，和高級查詢語言等待
那Hbase有什麼特性呢？如下：
強讀寫一致，但是不是「最終一致性」的數據存儲，這使得它非常適合高速的計算聚合
自動分片，通過Region分散在集群中，當行數增長的時候，Region也會自動的切分和再分配
自動的故障轉移
Hadoop/HDFS集成，和HDFS開箱即用，不用太麻煩的銜接
豐富的「簡潔，高效」API，Thrift/REST API，Java API
塊緩存，布隆過濾器，可以高效的列查詢優化
操作管理，Hbase提供了內置的web界面來操作，還可以監控JMX指標
首先資料庫量要足夠多，如果有十億及百億行數據，那麼Hbase是一個很好的選項，如果只有幾百萬行甚至不到的數據量，RDBMS是一個很好的選擇。因為數據量小的話，真正能工作的機器量少，剩餘的機器都處於空閑的狀態
其次，如果你不需要輔助索引，靜態類型的列，事務等特性，一個已經用RDBMS的系統想要切換到Hbase，則需要重新設計系統。
最後，保證硬體資源足夠，每個HDFS集群在少於5個節點的時候，都不能表現的很好。因為HDFS默認的復制數量是3，再加上一個NameNode。
存儲業務數據:車輛GPS信息，司機點位信息，用戶操作信息，設備訪問信息。。。
存儲日誌數據:架構監控數據（登錄日誌，中間件訪問日誌，推送日誌，簡訊郵件發送記錄。。。），業務操作日誌信息
存儲業務附件：UDFS系統存儲圖像，視頻，文檔等附件信息
什麼時候用Hbase？
Hbase不適合解決所有的問題：
Hbase在單機環境也能運行，但是請在開發環境的時候使用。
內部應用
不過在公司使用的時候，一般不使用原生的Hbase API，使用原生的API會導致訪問不可監控，影響系統穩定性，以致於版本升級的不可控。
HFile
HFile是Hbase在HDFS中存儲數據的格式，它包含多層的索引，這樣在Hbase檢索數據的時候就不用完全的載入整個文件。索引的大小(keys的大小，數據量的大小)影響block的大小，在大數據集的情況下，block的大小設置為每個RegionServer 1GB也是常見的。
探討資料庫的數據存儲方式，其實就是探討數據如何在磁碟上進行有效的組織。因為我們通常以如何高效讀取和消費數據為目的，而不是數據存儲本身。
Hfile生成方式
起初，HFile中並沒有任何Block，數據還存在於MemStore中。
Flush發生時，創建HFile Writer，第一個空的Data Block出現，初始化後的Data Block中為Header部分預留了空間，Header部分用來存放一個Data Block的元數據信息。
而後，位於MemStore中的KeyValues被一個個append到位於內存中的第一個Data Block中：
註：如果配置了Data Block Encoding，則會在Append KeyValue的時候進行同步編碼，編碼後的數據不再是單純的KeyValue模式。Data Block Encoding是HBase為了降低KeyValue結構性膨脹而提供的內部編碼機制。
② 行式存儲和列式存儲優缺點和paruqet文件結構
列式存儲和行式存儲是針對數據在存儲介質中的排序形式而言的，假設存在一張table，那麼：
圖1-1所示為行式存儲和列式存儲的示意圖，一張table包含5個欄位（列）即rowid、date/time、customer name以及quantity，共7行，圖中的紅色箭頭表示存儲順序。
存儲形式的差異決定了適用場景的不同：
綜合來看，列式存儲比較適合大數據量（壓縮比高）、分析型操作（針對少數幾列）；不適合頻率較高的刪除（全列檢索）、更新（重新壓縮）操作 。
圖2-1所示為列式存儲中將某張table基於字典表進行編碼壓縮的示例，圖中左邊為源表，假設該table中的customers和material欄位的取值均只有右上表所示的5種，那麼當源表的行數很大時，customers和material欄位就會存在大量重復的取值，為了節省存儲空間對這兩個欄位進行編碼，即使用一個字典表（右上圖）記錄該兩個欄位的distinct取值，又下表則用右上表欄位取值對應的index（整數1、2、3、4、5）來代替原來的string，由於string佔用的存儲空間比這幾個index佔用的存儲空間大多了，因此可以較大程度上壓縮佔用的存儲空間。
基於列式存儲的兩個典型實現是：hbase和parquet，其中：
parquet的文件結構如圖3-1所示：
從圖中可以看出，1個parquet文件由header（1個）、block（可以多個）、footer（1個）組成，分別負責：
圖3-2所示為parquet文件中，block、rowgroup、columnchunk以及page的關系：
簡而言之：
因此如果將一個parquet文件類比成一張大excel 表，那麼：
③ HBase是什麼為什麼要使用HBase
HBase在產品中還包含了Jetty，在HBase啟動時採用嵌入式的方式來啟動Jetty，因此可以通過web界面對HBase進行管理和查看當前運行的一些狀態，非常輕巧。為什麼採用HBase？HBase 不同於一般的關系資料庫,它是一個適合於非結構化數據存儲的資料庫.所謂非結構化數據存儲就是說HBase是基於列的而不是基於行的模式，這樣方面讀寫你的大數據內容。 HBase是介於Map Entry(key & value)和DB Row之間的一種數據存儲方式。就點有點類似於現在流行的Memcache，但不僅僅是簡單的一個key對應一個 value，你很可能需要存儲多個屬性的數據結構，但沒有傳統資料庫表中那麼多的關聯關系，這就是所謂的鬆散數據。 簡單來說，你在HBase中的表創建的可以看做是一張很大的表，而這個表的屬性可以根據需求去動態增加，在HBase中沒有表與表之間關聯查詢。你只需要 告訴你的數據存儲到Hbase的那個column families 就可以了，不需要指定它的具體類型：char,varchar,int,tinyint,text等等。但是你需要注意HBase中不包含事務此類的功 能。 Apache HBase 和Google Bigtable 有非常相似的地方，一個數據行擁有一個可選擇的鍵和任意數量的列。表是疏鬆的存儲的，因此用戶可以給行定義各種不同的列，對於這樣的功能在大項目中非常實用，可以簡化設計和升級的成本。
④ HBase存儲架構
上圖是HBase的存儲架構圖。
由上圖可以知道，客戶端是通過Zookeeper找到HMaster，然後再與具體的Hregionserver進行溝通讀寫數據的。
具體到物理實現，細節包括以下這些：
首先要清楚HBase在hdfs中的存儲路徑，以及各個目錄的作用。在hbase-site.xml 文件中，配置項 <name> hbase.rootdir</name> 默認 「/hbase」，就是hbase在hdfs中的存儲根路徑。以下是hbase0.96版本的個路徑作用。1.0以後的版本請參考這里: https://blog.bcmeng.com/post/hbase-hdfs.html
1、 /hbase/.archive
HBase 在做 Split或者 compact 操作完成之後，會將 HFile 移到.archive 目錄中，然後將之前的 hfile 刪除掉，該目錄由 HMaster 上的一個定時任務定期去清理。
2、 /hbase/.corrupt
存儲HBase損壞的日誌文件，一般都是為空的。
3、 /hbase/.hbck
HBase 運維過程中偶爾會遇到元數據不一致的情況，這時候會用到提供的 hbck 工具去修復，修復過程中會使用該目錄作為臨時過度緩沖。
4、 /hbase/logs
HBase 是支持 WAL（Write Ahead Log） 的，HBase 會在第一次啟動之初會給每一台 RegionServer 在.log 下創建一個目錄，若客戶端如果開啟WAL 模式，會先將數據寫入一份到.log 下，當 RegionServer crash 或者目錄達到一定大小，會開啟 replay 模式，類似 MySQL 的 binlog。
5、 /hbase/oldlogs
當.logs 文件夾中的 HLog 沒用之後會 move 到.oldlogs 中，HMaster 會定期去清理。
6、 /hbase/.snapshot
hbase若開啟了 snapshot 功能之後，對某一個用戶表建立一個 snapshot 之後，snapshot 都存儲在該目錄下，如對表test 做了一個 名為sp_test 的snapshot，就會在/hbase/.snapshot/目錄下創建一個sp_test 文件夾，snapshot 之後的所有寫入都是記錄在這個 snapshot 之上。
7、 /hbase/.tmp
當對表做創建或者刪除操作的時候，會將表move 到該 tmp 目錄下，然後再去做處理操作。
8、 /hbase/hbase.id
它是一個文件，存儲集群唯一的 cluster id 號，是一個 uuid。
9、 /hbase/hbase.version
同樣也是一個文件，存儲集群的版本號，貌似是加密的，看不到，只能通過web-ui 才能正確顯示出來
10、 -ROOT-
該表是一張的HBase表，只是它存儲的是.META.表的信息。通過HFile文件的解析腳本 hbase org.apache.hadoop.hbase.io.hfile.HFile -e -p -f 可以查看其存儲的內容，如下所示：
以上可以看出，-ROOT-表記錄的.META.表的所在機器是dchbase2，與web界面看到的一致：
11、 .META.
通過以上表能找到.META.表的信息，該表也是一張hbase表，通過以上命令，解析其中一個region：
以上可以看出，adt_app_channel表的數據記錄在dchbase3這台reginserver上，也與界面一致，如果有多個region，則會在表名後面加上rowkey的范圍：
通過以上描述，只要找到-ROOT-表的信息，就能根據rowkey找到對應的數據，那-ROOT-在哪裡找呢？從本文一開始的圖中可以知道，就是在zookeeper中找的。進入zookeeper命令行界面：
可以看出-ROOT-表存儲在 dchbase3 機器中，對應界面如下：
以上就是HBase客戶端根據指定的rowkey從zookeeper開始找到對應的數據的過程。
那在Region下HBase是如何存儲數據的呢？
以下就具體操作一張表，查詢對應的HFile文件，看HBase的數據存儲過程。
在HBase創建一張表 test7，並插入一些數據，如下命令：
查看wal日誌，通過 hbase org.apache.hadoop.hbase.regionserver.wal.HLog --mp -p 命令可以解析HLog文件，內容如下：
查看HFile文件，內容如下：
由此可見，HFile文件就是存儲HBase的KV對，其中Key的各個欄位包含了的信息如下：
由於hbase把cf和column都存儲在HFile中，所以在設計的時候，這兩個欄位應該盡量短，以減少存儲空間。
但刪除一條記錄的時候，HBase會怎麼操作呢？執行以下命令：
刪除了rowkey為200的記錄，查看hdfs，原來的HFile並沒有改變，而是生成了一個新的HFile，內容如下：
所以在HBase中，刪除一條記錄並不是修改HFile裡面的內容，而是寫新的文件，待HBase做合並的時候，把這些文件合並成一個HFile，用時間比較新的文件覆蓋舊的文件。HBase這樣做的根本原因是，HDFS不支持修改文件。
⑤ hbase的原型是什麼
正常情況下的話，它的原型應該是嗯iOS的這一款手機當中的和steam游戲當中的相對來說可能會比較多一點，而且比較正確一點。
⑥ hbase與關系型資料庫的存儲方式有哪些不同
HBase與傳統關系資料庫的區別主要體現在以下幾個方面：1.數據類型。關系資料庫採用關系模型，具有豐富的數據類型和儲存方式。HBase則採用了更加簡單的數據模型，它把數據儲存為未經解釋的字元串，用戶可以把不同格式的結構化數據和非結構化數據都序列化成字元串保存到HBase中，用戶需要自己編寫程序把字元串解析成不同的數據類型。 2.數據操作。關系資料庫中包含了豐富的操作，如插入、刪除、更新、查詢等，其中會涉及復雜的多表連接，通常是藉助多個表之間的主外鍵關聯來實現的。HBase操作則不存在復雜的表與表之間的關系，只有簡單的插入、查詢、刪除、清空等，因為HBase在設計上就避免了復雜的表與表之。
列存儲不同於傳統的關系型資料庫，其數據在表中是按行存儲的，列方式所帶來的重要好處之一就是，由於查詢中的選擇規則是通過列來定義的，因此整個資料庫是自動索引化的。
按列存儲每個欄位的數據聚集存儲，在查詢只需要少數幾個欄位的時候，能大大減少讀取的數據量，一個欄位的數據聚集存儲，那就更容易為這種聚集存儲設計更好的壓縮/解壓演算法。
傳統的（Oracle）行存儲和（Hbase）列存儲的區別。
主要體現在以下幾個方面：1.數據類型。關系資料庫採用關系模型，具有豐富的數據類型和儲存方式。HBase則採用了更加簡單的數據模型，它把數據儲存為未經解釋的字元串，用戶可以把不同格式的結構化數據和非結構化數據都序列化成字元串保存到HBase中，用戶需要自己編寫程序把字元串解析成不同的數據類型。 2.數據操作。關系資料庫中包含了豐富的操作，如插入、刪除、更新、查詢等，其中會涉及復雜的多表連接，通常是藉助多個表之間的主外鍵關聯來實現的。HBase操作則不存在復雜的表與表之間的關系，只有簡單的插入、查詢、刪除、清空等，因為HBase在設計上就避免了復雜的表與表之間的關系，通常只採用單表的主鍵查詢。