hbasemob存儲
❶ hbase採用了什麼樣的數據結構
HBase採用了類似Google Bigtable的數據模型，即一個稀疏的、分布式的、持久化的多維映射表，每個表都由行鍵、列族、列限定符和時間戳組成。
在底層實現上，HBase使用了基於Hadoop的分布式文件系統HDFS來存儲數據，並且使用了一搏皮搜種稱為LSM-Tree（Log-Structured Merge-Tree）的數據結構來管理數據。LSM-Tree是一種支持高寫入吞吐量的數據結構，它把數據分成多個層，每層採用不同的策略來管理數據，包括內存中的緩存、寫入磁碟的SSTable、和合並SSTable的操作。通過這種方式，HBase能夠支持高並發、高吞吐量的數據寫入，同時保證數據的一致性和可靠性。
另外，HBase還採用了Bloom Filter、MemStore和Compaction等技術來提高數據查詢效率和存儲效率。Bloom Filter是一種快速的數據過濾技術，可以幫助HBase快速地過濾掉無效的查詢請求，提高查詢效率。MemStore是一種緩存機制，可以幫助基歷HBase加速數據寫入，提高數據握中寫入效率。Compaction則是一種數據壓縮和合並技術，可以幫助HBase節省存儲空間，提高存儲效率。
綜上所述，HBase採用了LSM-Tree、Bloom Filter、MemStore和Compaction等多種數據結構和技術，以實現高並發、高吞吐量的分布式存儲和查詢功能。
❷ hbase與關系型資料庫的存儲方式有哪些不同
HBase與傳統關系資料庫的區別主要體現在以下幾個方面：1.數據類型。關系資料庫採用關系模型，具有豐富的數據類型和儲存方式。HBase則採用了更加簡單的數據模型，它把數據儲存為未經解釋的字元串，用戶可以把不同格式的結構化數據和非結構化數據都序列化成字元串保存到HBase中，用戶需要自己編寫程序把字元串解析成不同的數據類型。 2.數據操作。關系資料庫中包含了豐富的操作，如插入、刪除、更新、查詢等，其中會涉及復雜的多表連接，通常是藉助多個表之間的主外鍵關聯來實現的。HBase操作則不存在復雜的表與表之間的關系，只有簡單的插入、查詢、刪除、清空等，因為HBase在設計上就避免了復雜的表與表之。
列存儲不同於傳統的關系型資料庫，其數據在表中是按行存儲的，列方式所帶來的重要好處之一就是，由於查詢中的選擇規則是通過列來定義的，因此整個資料庫是自動索引化的。
按列存儲每個欄位的數據聚集存儲，在查詢只需要少數幾個欄位的時候，能大大減少讀取的數據量，一個欄位的數據聚集存儲，那就更容易為這種聚集存儲設計更好的壓縮/解壓演算法。
傳統的（Oracle）行存儲和（Hbase）列存儲的區別。
主要體現在以下幾個方面：1.數據類型。關系資料庫採用關系模型，具有豐富的數據類型和儲存方式。HBase則採用了更加簡單的數據模型，它把數據儲存為未經解釋的字元串，用戶可以把不同格式的結構化數據和非結構化數據都序列化成字元串保存到HBase中，用戶需要自己編寫程序把字元串解析成不同的數據類型。 2.數據操作。關系資料庫中包含了豐富的操作，如插入、刪除、更新、查詢等，其中會涉及復雜的多表連接，通常是藉助多個表之間的主外鍵關聯來實現的。HBase操作則不存在復雜的表與表之間的關系，只有簡單的插入、查詢、刪除、清空等，因為HBase在設計上就避免了復雜的表與表之間的關系，通常只採用單表的主鍵查詢。
❸ 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"
❹ 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 是什麼意思
HBase是一個分布式的、面向列的開源資料庫，基於Hadoop生態圈，在NoSQL蓬勃發展的今天被國內外眾多公司選擇，應用於現代互聯網系統的不同業務。
HBase業務場景
1.標簽數據的存儲
標簽數據是稀疏矩陣的代表，描述了實體的各類屬性，主要應用於智能推薦、商務智能或營銷引擎等領域。
2. 車聯網數據的收集
車聯網系統是利用車載設備收集車輛運行時產生的各項數據，通過網路實時上傳，在平台進行動態分析和利用。
3. 交易記錄的保存
在移動支付領域，保證歷史交易記錄等敏感信息的安全性是一個重要的話題。當數據中心遭遇自然災害、外部攻擊時，必須保證這些信息不丟，而且從業務角度要保證RTO盡可能短、RPO盡可能為0。
HBase基於底層的HDFS作為存儲系統，HDFS實現了三副本策略，按照一定的規則將副本放在不同的節點或機架中，本身具有較高的容災能力。在工程實踐中，也產生了Region replica、主備集群、互備雙活等策略來盡可能進行災備並保證高可用。
❻ 解讀Hadoop Hbase適合存儲哪類數據
最適合使用Hbase存儲的數據是非常稀疏的數據(非結構化或者半結構化的數據)。Hbase之所以擅長存儲這類數據，是因為Hbase是column-oriented列導向的存儲機制，而我們熟知的RDBMS都是row- oriented行導向的存儲機制(郁悶的是我看過N本關於關系資料庫的介紹從來沒有提到過row- oriented行導向存儲這個概念)。在列導向的存儲機制下對於Null值得存儲是不佔用任何空間的。比如，如果某個表 UserTable有10列，但在存儲時只有一列有數據，那麼其他空值的9列是不佔用存儲空間的(普通的資料庫MySql是如何佔用存儲空間的呢?)。 Hbase適合存儲非結構化的稀疏數據的另一原因是他對列集合 column families 處理機制。 打個比方，ruby和python這樣的動態語言和c++、java類的編譯語言有什麼不同? 對於我來說，最顯然的不同就是你不需要為變數預先指定一個類型。Ok ，現在Hbase為未來的DBA也帶來了這個激動人心的特性，你只需要告訴你的數據存儲到Hbase的那個column families 就可以了，不需要指定它的具體類型：char,varchar,int,tinyint,text等等。 Hbase還有很多特性，比如不支持join查詢，但你存儲時可以用：parent-child tuple 的方式來變相解決。 由於它是Google BigTable的 Java 實現，你可以參考一下：google bigtable 。
解讀Hadoop Hbase適合存儲哪類數據，參考：http://e.51cto.com/course/course_id-3819.html