hbase腳本

A. sqoop2如何寫自動化腳本到hive，或者hbase

Hbase不支持sql語句查詢，如果要實現count\group等操作需要藉助Maprece程序，門檻較高；
Hive對於SQL的支持有強大的功能，我們不需要寫過多的自定義函數就能實現較為復雜的查詢
優點：
1、Hive方便地提供了Hive QL的介面來簡化MapRece的使用，而HBase提供了低延遲的資料庫訪問。如果兩者結合，可以利用MapRece的優勢針對HBase存儲的大量內容進行離線的計算和分析；
2、操作方便，hive提供了大量系統功能；
3、降低業務開發人員技術門檻，只需要掌握SQL即可；
缺點：
性能的損失，hive有這樣的功能, 他支持通過類似sql語句的語法來操作hbase中的數據, 但是速度慢；
限制條件：
Hbase表需要有多個欄位，如果是單列，欄位採用特殊字元分隔，那麼導入
1、將以下jar包拷貝到$HIVE_HOME/lib/目錄中
cp hbase-common-1.0.0-cdh5.5.0.jar$HIVE_HOME/lib/
cp hbase-server-1.0.0-cdh5.5.0.jar$HIVE_HOME/lib/
cp hbase-client-1.0.0-cdh5.5.0.jar$HIVE_HOME/lib/
cp hbase-protocol-1.0.0-cdh5.5.0.jar$HIVE_HOME/lib/
cp hbase-hadoop2-compat-1.0.0-cdh5.5.0.jar $HIVE_HOME/lib/
cp hbase-hadoop-compat-1.0.0-cdh5.5.0.jar$HIVE_HOME/lib/
cp htrace-core-3.2.0-incubating.jar$HIVE_HOME/lib/
cp netty-all-4.0.23.Final.jar$HIVE_HOME/lib/
cp metrics-core-2.2.0.jar $HIVE_HOME/lib/
2、在hive-site.xml中增加以下配置
<property>
<name>hbase.zookeeper.quorum</name>
<value>master:2181,slave1:2182,slave2:2183</value>
</property>
<property>
<name>hive.aux.jars.path</name>
<value>file:///cdh550/hive/lib/hive-hbase-handler-1.1.0-cdh5.5.0.jar,file:///cdh550/hive/lib/hbase-common-1.0.0-cdh5.5.0.jar,file:///cdh550/hive/lib/hbase-server-1.0.0-cdh5.5.0.jar,file:///cdh550/hive/lib/hbase-client-1.0.0-cdh5.5.0.jar,file:///cdh550/hive/lib/hbase-protocol-1.0.0-cdh5.5.0.jar,file:///cdh550/hive/lib/zookeeper-3.4.5-cdh5.5.0.jar</value>
</property>
3、啟動Hive服務端
ohup hive --service metastore > metastore.log
ohup hive --service hiveserver2>hiveserver2.log
4、啟動hive客戶端
hive [-hiveconf hive.root.logger=DEBUG,console]
CREATE EXTERNAL TABLE hive_hbase_1(keystring, value string)
STORED BY'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
WITH SERDEPROPERTIES("hbase.columns.mapping" = "c1:d1")
TBLPROPERTIES("hbase.table.name"= "platjava_test_20170401", "hbase.mapred.output.outputtable"= " platjava_test_20170401")
--hbase.columns.mapping指向對應的列族；多列時，data:1，data:2；多列族時，data1:1,data2:1；
--hbase.table.name指向對應的表；hbase_table_2(keystring, value string)，這個是關聯表。
注意：
建表或映射表的時候如果沒有指定:key則第一個列默認就是行鍵
HBase對應的Hive表中沒有時間戳概念，默認返回的就是最新版本的值
由於HBase中沒有數據類型信息，所以在存儲數據的時候都轉化為String類型
CREATE TABLE hbase_table_1(key int, valuestring)
STORED BY'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
WITH SERDEPROPERTIES("hbase.columns.mapping" = ":key,cf1:val")
TBLPROPERTIES ("hbase.table.name"= "xyz", "hbase.mapred.output.outputtable" ="xyz")
hbase.table.name：參數是可選的，是Hbase可識別的名字，如果不設置則和Hive表名一致；
在Hive中創建的和Hbase整合的表不支持load data導入數據，需要在Hive中創建中間表導入數據後採用insert方式導入數據。
例：INSERTOVERWRITE TABLE hbase_table_1 SELECT * FROM pokes WHERE foo=98
當有大量數據導入Hbase時，建議將WAL關閉：sethive.hbase.wal.enabled=false
FAILED: Execution Error, return code 1 fromorg.apache.hadoop.hive.ql.exec.DDLTask. java.lang.RuntimeException: MetaException(message:org.apache.hadoop.hive.serde2.SerDeExceptionorg.apache.hadoop.hive.hbase.HBaseSerDe: columns has 1 elements whilehbase.columns.mapping has 2 elements (counting the key if implicit))
在創建hive/hbase相關聯的表時，hbase表結構默認會有一個欄位key，如果沒有一個顯示的欄位'key'那麼在創建表時，會自己創建，這樣hive對應的表就會出現問題，所以在hive對應的表裡一定要加上key這個欄位，為了避免這個問題，在hbase表結構里可以顯示的添加'key'欄位，這樣不容易出問題。
1、 Hive SQL在執行過程中是否會對Hbase的實時數據讀寫造成影響？（不考慮主機資源情況下）

B. Shell腳本中實現hbase shell命令調用

為了優化性能，大數據平台上的HBase表需要在腳本跑批過程中對創建的索引進行rebuild，因此說明下如何在shell中實現hbase語句調用。

常規操作，在操作前需要在shell中先獲取kerbores安全認證許可權：
kinit user -kt /user.keytab

使用 << （重定向輸入符號）

將hbase的命令嵌入到shell中，可以在shell中如下書寫：

其中， EOF 也可以換成其他任意的字元，大小寫不論，只要成對出現即可：

編寫執行命令執行：
hbase shell firstbaseshell.txt

C. java寫的hbase腳本怎麼打包

先導入態乎hbase的相關jar包磨閉岩。 再根據瞎御api進行操作。 package com.util;import java.io.IOException;import java.util.ArrayList;import java.util.List;import org.apache.hadoop.conf.Configuration;import org.apache.hadoop.hbase.HBaseConfigura

D. 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不支持修改文件。

E. hbase清理數據 用setTimeRange 方法怎麼腳本實現

HBase是Google Bigtable的開源實現，它利用Hadoop HDFS作為其文件存儲系統，利用Hadoop MapRece來處理HBase中的海量數據，利用Zookeeper作為協同服務。

1. 簡介

HBase是一個分布式的、面向列的開源資料庫,源於google的一篇論文《bigtable：一個結構化數據的分布式存儲系統》。HBase是Google Bigtable的開源實現，它利用Hadoop HDFS作為其文件存儲系統攜逗，利用Hadoop MapRece來處理HBase中的海量數據，利用Zookeeper作為協同服務。

2. HBase的表結構

HBase以表的形式存儲數據。表有行和列組成。列劃分為若干個列族/列簇(column family)。

Row Key column-family1 column-family2 column-family3
column1 column2 column1 column2 column3 column1
key1
key2
key3

如上圖所示，key1,key2,key3是三條記錄的唯一的row key值，column-family1,column-family2,column-family3是三個列族，每個列族下又包括幾列。比如column-family1這個列族下包括兩列，名字是column1和column2，t1:abc,t2:gdxdf是由row key1和column-family1-column1唯一確定的一個單元cell。這個cell中有兩個數據，abc和gdxdf。兩個值的時間戳不一樣，分別是t1,t2, hbase會返回最新時間的值給請求者。
這些名詞的具體含義如下：
(1) Row Key
與nosql資料庫們一樣,row key是用來檢索記錄的主鍵。訪問hbase table中的行，只有三種方式：
(1.1) 通過單個row key訪問
(1.2) 通過row key的range
(1.3) 全表掃描
Row key行鍵 (Row key)可以是任意字元串(最大長度是 64KB，實際應用中長度一般為 10-100bytes)，在hbase內部，row key保存為位元組數組。
存儲時，數據按照Row key的字典序(byte order)排序存儲。設計key時，要充分排序存儲這個特性，將經常一起讀取的行存儲放到一起。(位置相關性)
注意：
字典序對int排序的結果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行鍵必須用0作左填充。
行的一次讀寫是原子操作 (不論一次讀寫多少列)。這個設計決策能夠使用戶很容易的理解程序在對同一個行進行並發更新操作時的行為。
(2) 列族 column family
hbase表中的每個列，都歸屬與某個列族。列族是表的chema的一部分(而列不是)，必須在使用表之前定義。列名都以列族作為前綴。例如courses:history ， courses:math 都屬於 courses 這個列族。
訪問控制、磁碟和內存的使用統計都是在列族層面進行的。實際應用中，列族上的控制許可權能幫助我們管理不同類型的應用：我們允許一些應用可以添加新的基本數據、一些應用可以櫻隱祥讀取基本數據並創建繼承的列族、一些應用則只允許瀏覽數據（甚至可能因為隱私的原因不能瀏覽所有數據）。
(3) 單元 Cell
HBase中通過row和columns確定的為一個存貯單元稱為cell。由{row key, column( =<family> + <label>), version} 唯一確定的單元。cell中的數據是沒有類型的，全部是位元組碼形式存貯。
(4) 時間戳 timestamp
每個cell都保存著脊搏同一份數據的多個版本。版本通過時間戳來索引。時間戳的類型是 64位整型。時間戳可以由hbase(在數據寫入時自動 )賦值，此時時間戳是精確到毫秒的當前系統時間。時間戳也可以由客戶顯式賦值。如果應用程序要避免數據版本沖突，就必須自己生成具有唯一性的時間戳。每個cell中，不同版本的數據按照時間倒序排序，即最新的數據排在最前面。
為了避免數據存在過多版本造成的的管理 (包括存貯和索引)負擔，hbase提供了兩種數據版本回收方式。一是保存數據的最後n個版本，二是保存最近一段時間內的版本（比如最近七天）。用戶可以針對每個列族進行設置。
3. HBase shell的基本用法
hbase提供了一個shell的終端給用戶交互。使用命令hbase shell進入命令界面。通過執行 help可以看到命令的幫助信息。
以網上的一個學生成績表的例子來演示hbase的用法。
name grad course
math art
Tom 5 97 87
Jim 4 89 80
這里grad對於表來說是一個只有它自己的列族,course對於表來說是一個有兩個列的列族,這個列族由兩個列組成math和art,當然我們可以根據我們的需要在course中建立更多的列族,如computer,physics等相應的列添加入course列族。

F. python可以把爬蟲的數據寫入hbase么

在已經安裝了HBase服務的伺服器中，已經自動安裝了HBase的Thrift的腳本，路徑為：/usr/lib/hbase/include/thrift 。
需要使用這個腳本生成基於Python語言的HBase的Thrift腳本，具體命令如下：
thrift --gen py hbase2.thrift
命令執行成功後會生成名為gen-py的目錄，其中包含了python版本的HBase包。
主要文件介紹如下：
l Hbase.py 中定義了一些HbaseClient可以使用的方法
l ttypes.py中定義了HbaseClient傳輸的數據類型
將生成的HBase包放入項目代碼或者放入Python環境的依賴包目錄中即可調用。

G. HBase探索篇 _ 單節點多RegionServer部署與性能測試

[toc]

隨著集群中總的Region數持續增長，每個節點平均管理的Region數已達550左右，某些大表的寫入流量一上來，Region Server就會不堪重負，相繼掛掉。

在HBase中，Region的一個列族對應一個MemStore，通常一個MemStore的默認大小為128MB（我們設置的為256MB），見參數 hbase.hregion.memstore.flush.size 。當可用內存足夠時，每個MemStore可以分配128MB的空間。

當表的寫入流量上升時，假設每個Region的寫入壓力相同，則理論上每個MemStore會平均分配可用的內存空間。

因此，節點中Region過多時，每個MemStore分到的蠢棗內存空間就會變小。此時，寫入很小的數據量，就會被強制flush到磁碟，進而導致頻繁刷寫，會對集群HBase與HDFS造成很大的壓力。

同時，Region過多導致的頻繁刷寫帶頌拆，又會在磁碟上產生非常多的HFile小文件，當小文件過多的時候，HBase為了優化查詢性能就會做Compaction操作，合並HFile，減少文件數量。當小文件一直很多的時候，就會出現 「壓縮風暴」。Compaction非常消耗系統的IO資源，還會降低數據的寫入速度，嚴重時會影響正常業務的進行。

關於每個Region Server節點中，Region數量大致合理的范圍，HBase官網上也給出了定義：

可見，通常情況下，每個節點擁有20-200個Region是比較正常的。

其實，每個Region Server的最大Region數量由總的MemStore內存大小決定。每個Region的每個列族會對應一個MemStore，假設HBase表都有一個列族，那麼每個Region只包含一個櫻彎MemStore。一個MemStore大小通常在128~256MB，見參數： hbase.hregion.memstore.flush.size 。默認情況下，RegionServer會將自身堆內存的40%（我們線上60%）（見參數： hbase.regionserver.global.memstore.size ）提供給節點上的所有MemStore使用，如果所有MemStore的總大小達到該配置大小，新的更新將會被阻塞並且會強制刷寫磁碟。因此，每個節點最理想的Region數量應該由以下公式計算（假設HBase表都有統一的列族配置）：

((RS memory) * (total memstore fraction)) / ((memstore size)*(column families))

其中：

以我們線上集群的配置舉例，我們每個RegionServer的堆內存是32GB，那麼節點上最理想的Region數量應該是： 32768*0.6/256 ≈ 76 （32768*0.6/128 ≈ 153）

上述最理想的情況是假設每個Region上的填充率都一樣，包括數據寫入的頻次、寫入數據的大小，但實際上每個Region的負載各不相同，有的Region可能特別活躍、負載特別高，有的Region則比較空閑。所以，通常我們認為2 _{3倍的理想Region數量也是比較合理的，針對上面舉例來說，大概200} 300個Region左右算是合理的。

針對上文所述的Region數過多的隱患，以下內容主要從兩方面考慮來優化。

提高內存的目的是為了增加每個Region擁有的MemStore的空間，避免其寫入壓力上升時，MemStore頻繁刷寫，形成小的HFile過多，引起壓縮風暴，佔用大量IO。

但其實RS的堆內存並不是越大越好，我們開始使用HBase的時候，對CMS和G1相關的參數，進行了大量壓測，測試指標數據表明，內存分配的越大，吞吐量和p99讀寫平均延時會有一定程度的變差（也有可能是我們的JVM相關參數，當時調配的不合理）。

在我們為集群集成jdk15，設置為ZGC之後，多次壓測並分析JVM日誌之後，得出結論，在犧牲一定吞吐量的基礎上，集群的GC表現能力確實提升的較為明顯，尤其是GC的平均停頓時間，99.9%能維持在10ms以下。

而且ZGC號稱管理上T的大內存，停頓時間控制在10ms之內（JDK16把GC停頓時間控制在1ms內，期待JDK17 LTS），STW時間不會因為堆的變大而變長。

因此理論上，增加RS堆內存之後，GC一樣不會成為瓶頸。

之所以考慮在單節點上部署多個Region Server的進程，是因為我們單個物理機的資源配置很高，內存充足（三百多G，RS堆內存只分了32G）、而HBase又是弱計算類型的服務，平時CPU的利用率低的可憐，網路方面亦未見瓶頸，唯一掉鏈子的也就屬磁碟了，未上SSD，IO延遲較為嚴重。

當然，也曾考慮過虛擬機的方案，但之前YCSB壓測的數據都不太理想；K8s的調研又是起步都不算，沒有技術積累。因此，簡單、直接、易操作的方案就是多RS部署了。

以下內容先敘述CDH中多RS進程部署的一些關鍵流程，後續將在多RS、單RS、單RS大堆環境中，對集群進行基準性能測試，並對比試驗數據，分析上述兩種優化方案的優劣。

我們使用的HBase版本是 2.1.0-cdh6.3.2 ，非商業版，未上Kerberos，CDH中HBase相關的jar包已替換為用JDK15編譯的jar。

多Region Server的部署比較簡單，最關鍵的是修改 hbase-site.xml 中region server的相關埠，避免埠沖突即可。可操作流程如下。

修改所需配置文件

hbase-site.xml 配置文件一定不要直接從 /etc/hbase/conf 中獲取，這里的配置文件是給客戶端用的。CDH管理的HBase，配置文件都是運行時載入的，所以，找到HBase最新啟動時創建的進程相關的目錄，即可獲取到服務端最新的配置文件，如：/var/run/cloudera-scm-agent/process/5347-hbase-REGIONSERVER。需要准備的目錄結構如下：

不需要HBase完整安裝包中的內容（在自編譯的完整安裝包中運行RS進程時，依賴沖突或其他莫名其妙的報錯會折磨的你抓狂），只需要bin、conf目錄即可，pids文件夾是自定義的，RS進程對應pid文件的輸出目錄，start_rs.sh、stop_rs.sh是自定義的RS進程的啟動和關閉腳本。

重點修改下圖標注的配置文件，

還有日誌文件名的一些輸出細節，可以按需在 bin/hbase-daemon.sh 中修改。

運行或關閉RS進程

中間有異常，請查看相關日誌輸出。

集群Region數瘋漲，當寫入存在壓力時，會導致RS節點異常退出。為了解決目前的這種窘境，本次優化主要從單節點多Region Server部署和提高單個Region Server節點的堆內存兩方面著手。

那這兩種優化方案對HBase的讀寫性能指標，又會產生什麼樣的影響呢？我們以YCSB基準測試的結果指標數據做為參考，大致評價下這兩種應急方案的優劣。

用於此次測試的HBase集群的配置

此次測試使用的數據集大小

測試方法

壓測時選擇的讀寫負載盡量模擬線上的讀寫場景，分別為：讀寫3/7、讀寫7/3、讀寫5/5；

壓測時唯一的變數條件是：多RS部署（32G堆，在每個節點上啟動3個RS進程，相當於集群中一共有15個RS節點）、單RS部署（32G小堆）和單RS部署（100G大堆），並盡可能保證其他實驗條件不變，每個YCSB的工作負載各自運行20分鍾左右，並且重復完整地運行5次，兩次運行之間沒有重新啟動，以測量YCSB的吞吐量等指標，收集的測試結果數據是5次運行中最後3次運行的平均值，為了避免第一輪和第二輪的偶然性，忽略了前兩次的測試。

YCSB壓測的命令是：

收集實驗數據後，大致得出不同讀寫負載場景下、各個實驗條件下的指標數據，如下圖。

上述的測試數據比較粗糙，但大致也能得出些結論，提供一定程度上的參考。

多RS進程部署的模式，起到了一定程度上的進程間資源隔離的作用，分擔了原先單台RS管理Region的壓力，最大化利用了物理機的資源，但多出來的一些Region Server，需要單獨的管理腳本和監控系統來維護，增加了維護成本。多個RS依賴同一台物理機，物理節點宕機便會影響多個RS進程，同時，某一個Region Server出現熱點，壓力過大，資源消耗過度，也許會引起同機其他進程的不良，在一定程度上，犧牲了穩定性和可靠性。

增加單個RS進程的堆內存，MemStore在一定程度上會被分配更充裕的內存空間，減小了flush的頻次，勢必會削弱寫入的壓力，但也可能會增加GC的負擔，我們或許需要調整出合適的GC參數，甚至需要調優HBase本身的一些核心參數，才能兼顧穩定和性能。然而，這就又是一件漫長而繁瑣的事情了，在此不過分探討。

面對性能瓶頸的出現，我們不能盲目地擴充機器，在應急方案採取之後，我們需要做一些額外的、大量的優化工作，這或許才是上上之策。