hbase小文件存儲
特點：（1）大：一個表可以有數十億行，上百萬列；
（2）無模式：每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態的增加，同一張表中不同的行可以有截然不同的列；
（3）面向列：面向列（族）的存儲和許可權控制，列（族）獨立檢索；？
（4）稀疏：空（null）列並不佔用存儲空間，表可以設計的非常稀疏；
（5）數據多版本：每個單元中的數據可以有多個版本，默認情況下版本號自動分配，是單元格插入時的時間戳；
（6）數據類型單一：Hbase中的數據都是字元串，沒有類型。
㈡ HBase應用場景
1、用戶畫像
比如大型的視頻網站，電商平台產生的用戶點擊行為、瀏覽行為等等存儲在HBase中為後續的智能推薦做數據支撐。
2、消息/訂單存儲
這個場景主要應用在電商平台，因為HBase提供了一個低延時、高並發的訪問能力
3、對象存儲
這里的對象存儲實際是中等對象存儲，是對HDFS存儲文件的一個緩沖過度，因為如果我們大量的1M或2M這種小文件直接存儲在HDFS上，會對NAMENODE造成元數據維護的壓力，所以在HBase中可以很好的做過度合並後在持久化到HDFS上。HBase提供了中等對現象的存儲能力，中等對象的大小范圍在100k至10M之間。
4、時序數據
這里的時序數據是指隨著時間而變化的數據，比如速度的展示，天氣、溫度、風速、車流量等等
5、Cube分析（KyLin）
通過KyLin將Hive或kafka中的數據，來構建Cube，這些Cube會存儲在HBase中，以供其他的應用或其他的系統做實時查詢或實時展示。
6、Feeds流
這個場景主要是應用在抖音、或其他小視頻系統中，可以把Feeds流理解為一種內容聚合器，它可以幫助用戶實時的獲取最新的訂閱源內容。
㈢ Hbase擴容原理
Hbase是Hadoop的一個存儲組件可以提供低延遲的讀寫操作，它一般構建在HDFS之上，可以處理海量的數據。Hbase有個很好的特性是可以自動分片，也就是意味著當表的數據量變得很大的時候，系統可以自動的分配這些數據。
Hbase的基本存儲單位是Region，Region是表數據的子集，多個Region的數據集合可以組成一張完成的表數據。Region本質上存儲的一些排好序的，連續的行數據。最初的時候一張表只有一個Region，當Region變得非常大的時候，Region就會從中間分裂成兩個基本等大的Region。
在Hbase中，slave也被稱作RegionServer，每個RegionServer負責管理一些Region，同時一個Region只能屬於一個RegionServer。
一個RegionServer可以服務一個或多個Region，每個Region在Region Server啟動的時候被分配。Master可以決定將一些Region從一個RegionServer中移動到令一個RegionServer裡面，以便更好的負載均衡。當某個RegionServer故障的時候，Master也可以將它的Region分配給其他的RegionServer。
Region與RegionServer之間的映射關系存儲在Zookeeper中的META表中，通過讀取META表，你就可以知道那個Region可以負責處理你的rowkey操作，其實這也代表著在HBase讀寫操作的時候是不用經過Master節點的，你可以之間聯系RegionServer。
如圖，在客戶端進行scan的時候，它可以之間聯系多個RegionServer處理當前的操作。
Meta表是用來跟蹤Region的，它包含伺服器的名稱，Region的名稱，表名，還有Region的startkey。通過startkey的范圍，客戶端就可以定位到當前的key要去哪一個Region了。
客戶端在請求過META表之後，一般會將表緩存起來，防止每次操作都去獲取。在Region進行分裂的時候，客戶端去RegionServer操作Region的時候回返回異常，然後客戶端會重新獲取最新的META表信息。
Hbase的java客戶端API有兩個主要的介面：
通過上面介紹，可以知道HBase雖然是Master/Slave架構的，但是並不是每次操作都經過Master的，讀寫數據的時候HBase只需要直接聯系RegionServer即可。這也是HBase可以「無限擴容」的原因。在吞吐量不夠的時候，通過增加RegionServer節點，可以增加吞吐量。
㈣ 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作為存儲系統( )
選擇D，HBase適合小文件的存儲
㈥ hbase的作用
HBase 是典型的 NoSQL 資料庫，通常被描述成稀疏的、分布式的、持久化的，由行鍵、列鍵和時間戳進行索引的多維有序映射資料庫，主要用來存儲非結構化和半結構化的數據。因為 HBase 基於 Hadoop 的 HDFS 完成分布式存儲，以及 MapRece 完成分布式並行計算，所以它的一些特點與 Hadoop 相同，依靠橫向擴展，通過不斷增加性價比高的商業伺服器來增加計算和存儲能力。
HBase 雖然基於 Bigtable 的開源實現，但它們之間還是有很多差別的，Bigtable 經常被描述成鍵值資料庫，而 HBase 則是面向列存儲的分布式資料庫。
下面介紹 HBase 具備的顯著特性，這些特性讓 HBase 成為當前和未來最實用的資料庫之一。
容量巨大
HBase 的單表可以有百億行、百萬列，可以在橫向和縱向兩個維度插入數據，具有很大的彈性。
當關系型資料庫的單個表的記錄在億級時，查詢和寫入的性能都會呈現指數級下降，這種龐大的數據量對傳統資料庫來說是一種災難，而 HBase 在限定某個列的情況下對於單表存儲百億甚至更多的數據都沒有性能問題。
HBase 採用 LSM 樹作為內部數據存儲結構，這種結構會周期性地將較小文件合並成大文件，以減少對磁碟的訪問。
擴展性強
HBase 工作在 HDFS 之上，理所當然地支持分布式表，也繼承了 HDFS 的可擴展性。HBase 的擴展是橫向的，橫向擴展是指在擴展時不需要提升伺服器本身的性能，只需添加伺服器到現有集群即可。
HBase 表根據 Region 大小進行分區，分別存在集群中不同的節點上，當添加新的節點時，集群就重新調整，在新的節點啟動 HBase 伺服器，動態地實現擴展。這里需要指出，HBase 的擴展是熱擴展，即在不停止現有服務的前提下，可以隨時添加或者減少節點。
高可靠性
HBase 運行在 HDFS 上，HDFS 的多副本存儲可以讓它在岀現故障時自動恢復，同時 HBase 內部也提供 WAL 和 Replication 機制。
WAL（Write-Ahead-Log）預寫日誌是在 HBase 伺服器處理數據插入和刪除的過程中用來記錄操作內容的日誌，保證了數據寫入時不會因集群異常而導致寫入數據的丟失；而 Replication 機制是基於日誌操作來做數據同步的。
㈦ 小文件存儲
小文件存儲對hbase不太合適。會產生太多小塊。hbase是按照rowkey來分片的。所以太多小文件了
https://zhuanlan.hu.com/p/136705670
fb的haystack。
思路是：把目錄做成單獨的service，
文件合並成大文件，這樣在物理存儲層上，metadata的存儲壓力就小。
㈧ hbase存儲信息怎麼展示
hbase存儲的信息一般是這樣展示的。首先打開電子設備，找到設置裡面的我的存儲，然後查看存儲信息就可以看到了。
㈨ 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結構性膨脹而提供的內部編碼機制。
㈩ hbase 的數據存儲及Region變化（flush compaction spilt）和性能調優
1. 對表做預分區處理（即在建表時指定Region數量和拆分邊界）；
2.配置hbase.hregion.max.filesize為50GB
以fileServer為例，在使用默認的split策略-- 的情況下，16個預分區Region, 則單個Resion容量達到 min(32,50),即32GB時分裂。
3.修改Linux最大文件句柄數
因為hbase是以文件的形式存儲數據，最大文件句柄數影響著hbase的並發量。
用root許可權修改/etc/security/limits.conf文件，增加以下內容（前面的*不能忽略）：
* soft nproc 10240
* hard nproc 10240
* soft nofile 10240
* hard nofile 10240
編輯/etc/pam.d/common-session，加入一行
session required pam_limits.so
編輯/etc/profile，加入
ulimit -SHn 51200
重新登陸，生效
4.HRegionServer掛掉異常和解決：
is not online on......
常規解決方案：
刪除zk中hbase的緩存
重啟hbase
使用上述解決方案後本次異常依舊存在，並且HMaster和HRegionServer都不斷的自動掛掉。
HMaster報錯：
解決方案：
新增配置（看情況決定使用不使用，建議在HMaster不能啟動時排除錯誤使用）（讓啟動hbase時只讓HMaster去進行日誌split，缺點是恢復數據時候速度慢）：
<property>
<name>hbase.master.distributed.log.splitting</name>
<value>false</value>
</property>
刪除WAL文件（會丟數據）：
6. RPC請求的最大線程數
hbase.regionserver.handler.count 默認是10，在伺服器測試時建議設置到50（經測試在單個Region Server時無用，單個RegionServer 最多在6個線程put時保持穩定）
7.日誌分割（hbase出錯後恢復數據）
MemStore中大量更新丟失時，對數據進行恢復時會做日誌分割
hbase.regionserver.hlog.splitlog.writer.threads 日誌分割的線程數， 默認為3 ，建議設定為10
8.Region Server頻繁掉線
出現Hbase Region Server頻繁掉線的情況，表現為在多線程put的情況下，忽然Hbase Region Server掉線
猜測是GC或者split過程中沒有及時和ZK通信，導致與ZK連接時間超時，zk返回dead region到master，當Hbase Region恢復正常後，找不到wal,產生如下報錯。
zookeeper.session.timeout ：默認值是3分鍾
但是 hbase regionserver和zookeeper的timeout不是單方面決定的，是取決於hbase的zookeeper.session.timeout和zookeeper的MaxSessionTimeout中的最小值
配置hbase:
zookeeper.session.timeout
600000
配置zookeeper:
tickTime=30000
9.內存及GC優化
在測試的過程中依舊出現Hbase Region Server掉線的情況，報錯如下
2021-02-0318:49:14,091INFO[sync.0]wal.FSHLog: Slow sync cost:1955ms, current pipeline: []
2021-02-0318:49:14,091WARN[regionserver/botsc/192.168.0.107:16020.append-pool5-t1]wal.MetricsWAL: regionserver/botsc/192.168.0.107:16020.append-pool5-t1 took1953ms appending an edit to wal; len~=109
2021-02-0318:49:14,106ERROR[sync.3]wal.FSHLog:Errorsyncing, request close of WAL
java.io .IOException:io.grpc.StatusRuntimeException: CANCELLED: Failed to stream message
at seaweed.hdfs.SeaweedOutputStream.(SeaweedOutputStream.java:78)
at seaweed.hdfs.SeaweedOutputStream.(SeaweedOutputStream.java:263)
at seaweed.hdfs.SeaweedOutputStream.flushInternalAsync(SeaweedOutputStream.java:243)
at seaweed.hdfs.SeaweedOutputStream.flush(SeaweedOutputStream.java:129)
at java.io .FilterOutputStream.flush(FilterOutputStream.java:140)
at java.io .DataOutputStream.flush(DataOutputStream.java:123)
at org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter.sync(ProtobufLogWriter.java:170)
at org.apache.hadoop.hbase.regionserver.wal.FSHLog$SyncRunner.run(FSHLog.java:1286)
at java.lang.Thread.run(Thread.java:748)
修改hbase的配置文件hbase-env.sh，GC優化如下：
export HBASE_HEAPSIZE=21384
export master_heapsize=8292
export regionserver_heapsize=21384
export HBASE_OPTS="$HBASE_OPTS -XX:+UseConcMarkSweepGC -XX:=60 -XX:+UseParNewGC -XX:ParallelGCThreads=6"
export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE -Xmx8g -Xms8g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:=70"
export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE -Xmx20g -Xms20g -Xmn1g -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC -XX:=70"