Ⅰ hbase與客戶端的通信過程解析
hbase通信主要涵蓋了兩個技術，一個是 google的protobuf rpc通信框架 ，一個是 java的NIO通信 ；
org.apache.hadoop.hbase.regionserver.HRegionServer這個類是regionserver的啟動類；
org.apache.hadoop.hbase.master.HMaster這個類是Hmaster的啟動類，繼承了HRegionServer;
而HRegionServer定義了一個org.apache.hadoop.hbase.regionserver.RSRpcServices變數：
因此整個通信過程最核心的就是這兩個類：RSRpcServices和RpcServer
hbase的protobuf的使用流程如下：
此過程主要是以下要討論的 JAVA NIO做的工作；
Message callBlockingMethod(MethodDescriptor var1, RpcController var2, Message var3) throws ServiceException;
關於 java NIO的使用，主要集中於RpcServer類中：
主要使用了一個listener，但是實際情況這不是一個常見的listener模式，而是用來監聽請求的監聽器。
而它的實現如下：
主要定義了一個acceptChannel，一個selector和多個readers，每個reader對應一個selector；
它的主線程是監控selector中的accept請求，進行doAccept操作：
主要是對每個accept請求創建了一個connection對象，每個connection對應一個讀寫數據的channel，然後注冊channel給某一個reader的selector；
對於每個reader線程來說，會對自己selector綁定的所有的SelectionKey進行查看，如果接收到數據，那麼對綁定的connection進行處理，最後調用connection的process方法；
解析收到的請求，然後創建請求；通過scheler執行，
scheler是整個regionserver處理所有請求的核心，創建scheler需要用到參數如下，因此hbase.regionserver.handler.count參數決定了同時進行處理請求的handler個數，即regionserver的並發能力。
最後再rpcserver中調用call函數：
Message result = service.callBlockingMethod(md, controller, param);
上邊寫到數據的具體執行在CallRunner中，執行結束後調用Call.setResponse方法，
其中通過IPCUtil.(result)把messgae數據序列化成buffer，調用google提供的com.google.protobuf.CodedOutputStream實現的序列化方法。
以下是reponder提供的方法：
最後將數據寫進屬於自己的channel中。
Ⅱ hbase java端調用
這是缺少必要的類org/apache/hadoop/thirdparty/guava/common/primitives/UnsignedBytes
你可以到jarsearch上搜索含有這個類的jar包，然後把它放到classpath下就行了
Ⅲ 【日更挑戰】CDH下無法啟動hbase節點的問題解決
繼昨天解決Kafka的位移問題後，今天又發現一個hbase的region server無法重新啟動的問題。這個server本身是有問題的，目前問題還未查。但是再重啟的時候，會報三組錯。其中一個明確為PG的錯誤，大意如下
首先想到的就是檢查本地磁碟，發現其實並沒有滿，這就很奇怪了。之後想到CDH會使用pg，那就把這部分先了解下。
查詢了一下，發現確實是的，會有一個地方存儲著pg相關登錄信息。按網文說是 /etc/cloudera-scm-server ，但我發現幾個機器都只有 /etc/cloudera-scm-agent 。所以必須找到server的機器，而其他集群里的都是agent的機器。
找到這個機器後，發現確實是空間滿了。
那麼依次用 -h --max-depth 1 命令查看目錄，最終發現CDH的kafka manager的nohup文件是罪魁禍首。
用 > nohup.out 把文件清空，再用CDH重啟節點就沒有問題了！
Ⅳ 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本身的一些核心參數，才能兼顧穩定和性能。然而，這就又是一件漫長而繁瑣的事情了，在此不過分探討。
面對性能瓶頸的出現，我們不能盲目地擴充機器，在應急方案採取之後，我們需要做一些額外的、大量的優化工作，這或許才是上上之策。
Ⅳ 求助帖，hbase新手，windows中的java怎麼連接linux中的hbase
一、新建本地java工程
file->new->java project
二、添加jar包和配置文件
1、添加JAR包
右擊Propertie在彈出的快捷菜單中選擇Java Build Path對話框，在該對話框中單擊Libraries選項卡，在該選項卡下單擊
Add External JARs按鈕，定位到$HBASE/lib目錄下，並選取如下JAR包。
hadoop-core-1.0.0.jar
commons-loggings-version.jar
commons-cli-version.jar
commons-lang-version.jar
commons-configuration-version.jar
hbase-0.94.1.jar
zookeeper-3.4.3.jar
slf4j-api-1.5.8.jar
slf4j-log4j12-1.5.8.jar
log4j-1.2.16.jar
protobuf-java-2.4.1.jar
2、添加hbase-site.xml配置文件
在工程根目錄下創建conf文件夾，將$HBASE_HOME/conf/目錄中的hbase-site.xml文件復制到該文件夾中。通過右鍵
選擇Propertie->Java Build Path->Libraries->Add Class Folder。
3、windows下開發HBase應用程序，HBase部署在linux環境中，在運行調試時可能會出現無法找到主機，類似異常信息如下：java.net.UnknownHostException: unknown host: master
解決辦法如下：在C:\WINDOWS\system32\drivers\etc\hosts文件中添加如下信息
192.168.2.34 master
Ⅵ 如何解決CDH5中找不到JAVA
找不到JAVA_HOME 說明JDK環境變數沒有配置正確,建議查看一下是否有安裝JDK,再查看一下path里有沒有增加JAVA_HOME的環境變數. eoch path 即可查看。
在安裝presudo版本的CDH5中，第一次需要格式化HDFS，執行：
$ sudo -u hdfs hdfs namenode -format
但是會出現：
[root@AY1312280620257702e0Z conf]# sudo -u hdfs hdfs namenode -format
Error: JAVA_HOME is not set and could not be found.
[root@AY1312280620257702e0Z conf]# echo $JAVA_HOME
/usr/qiuxin/software/jdk1.7.0_25
[root@AY1312280620257702e0Z conf]# echo $JAVA_HOME
/usr/qiuxin/software/jdk1.7.0_25
[root@AY1312280620257702e0Z conf]# sudo -u hdfs hdfs namenode -format
Error: JAVA_HOME is not set and could not be found.
[root@AY1312280620257702e0Z conf]# java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
[root@AY1312280620257702e0Z conf]#
[root@AY1312280620257702e0Z ~]# for x in `cd /etc/init.d ; ls hadoop-hdfs-*` ; do sudo service $x start ; done
Starting Hadoop datanode:[ OK ]
Error: JAVA_HOME is not set and could not be found.
Starting Hadoop namenode:[ OK ]
Error: JAVA_HOME is not set and could not be found.
Starting Hadoop secondarynamenode:[ OK ]
Error: JAVA_HOME is not set and could not be found.
需要進行如下配置，即可解決如上問題：
在/etc/sudores 的最後一行增加：
On systems on which
sudo
clears or restricts environment variables, you also need to add the following line to the
/etc/sudoers
file:
Defaults env_keep+=JAVA_HOME
同時需要配置：
If your JDK is located at one of the standard locations, it's detected by the script (using this component called bigtop-utils). However, if it's not, you'd have to go to /etc/default/bigtop-utils and set and export JAVA_HOME ( to /usr/qiuxin/software/jdk1.7.0_25) there. You only need to do it once and all CDH components would use that variable to figure out where JDK is.
[root@AY1312280620257702e0Z ~]# vi /etc/default/bigtop-utils
增加：export JAVA_HOME=/usr/qiuxin/software/jdk1.7.0_25
[root@AY1312280620257702e0Z ~]# source /etc/default/bigtop-utils
Ⅶ hbase單機模式下，使用java API遠程連接hbase的問題。
首先你應該看Master進程是否已經成功啟動，檢查下master的60010監控界面。這日誌報的是連接拒絕 ，或者關閉防火牆
極有可能是你PC機網路無法連接到虛擬機里邊，你可以從本機telnet下虛擬機上master的埠，看下能連上不
Ⅷ 如何修改cloudera默認的java路徑
java默認路徑？？
是java的系統變數 配置么？
右擊我的電腦—>屬性—>高級—>環境變數—>系統變數
在系統變數 選項里 -〉 新建
舉例：
java_home 的路徑 如C:\j2sdk1.4.2_01;
在path中添加 java的bin路徑 如C:\j2sdk1.4.2_01\bin;
新建classpath 中添加.;lib\dt.jar;lib\tools.jar;
如 .;C:\j2sdk1.4.2_01\lib\dt.jar;C:\j2sdk1.4.2_01\lib\tools.jar;
一定記得有一個".;"要不你的java在本地編譯的時候不好用.
Ⅸ 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 shell客戶端工具
進入hbase shell console
$HBASE_HOME/bin/hbase shell
如果有kerberos認證，需要事先使用相應的keytab進行一下認證（使用kinit命令），認證成功之後再使用hbase shell進入可以使用whoami命令可查看當前用戶
hbase(main)> whoami
表的管理
1）查看有哪些表
hbase(main)> list
2）創建表
# 語法：create <table>, {NAME => <family>, VERSIONS => <VERSIONS>}
# 例如：創建表t1，有兩個family name：f1，f2，且版本數均為2
hbase(main)> create 't1',{NAME => 'f1', VERSIONS => 2},{NAME => 'f2', VERSIONS => 2}
3）刪除表
分兩步：首先disable，然後drop
例如：刪除表t1
hbase(main)> disable 't1'
hbase(main)> drop 't1'
4）查看錶的結構
# 語法：describe <table>
# 例如：查看錶t1的結構
hbase(main)> describe 't1'
5）修改表結構
修改表結構必須先disable
# 語法：alter 't1', {NAME => 'f1'}, {NAME => 'f2', METHOD => 'delete'}
# 例如：修改表test1的cf的TTL為180天
hbase(main)> disable 'test1'
hbase(main)> alter 'test1',{NAME=>'body',TTL=>'15552000'},{NAME=>'meta', TTL=>'15552000'}
hbase(main)> enable 'test1'
許可權管理
1）分配許可權
# 語法 : grant <user> <permissions> <table> <column family> <column qualifier> 參數後面用逗號分隔
# 許可權用五個字母表示： "RWXCA".
# READ('R'), WRITE('W'), EXEC('X'), CREATE('C'), ADMIN('A')
# 例如，給用戶『test'分配對表t1有讀寫的許可權，
hbase(main)> grant 'test','RW','t1'
2）查看許可權
# 語法：user_permission <table>
# 例如，查看錶t1的許可權列表
hbase(main)> user_permission 't1'
3）收回許可權
# 與分配許可權類似，語法：revoke <user> <table> <column family> <column qualifier>
# 例如，收回test用戶在表t1上的許可權
hbase(main)> revoke 'test','t1'
表數據的增刪改查
1）添加數據
# 語法：put <table>,<rowkey>,<family:column>,<value>,<timestamp>
# 例如：給表t1的添加一行記錄：rowkey是rowkey001，family name：f1，column name：col1，value：value01，timestamp：系統默認
hbase(main)> put 't1','rowkey001','f1:col1','value01'
用法比較單一。
2）查詢數據
a）查詢某行記錄
# 語法：get <table>,<rowkey>,[<family:column>,....]
# 例如：查詢表t1，rowkey001中的f1下的col1的值
hbase(main)> get 't1','rowkey001', 'f1:col1'
# 或者：
hbase(main)> get 't1','rowkey001', {COLUMN=>'f1:col1'}
# 查詢表t1，rowke002中的f1下的所有列值
hbase(main)> get 't1','rowkey001'
b）掃描表
# 語法：scan <table>, {COLUMNS => [ <family:column>,.... ], LIMIT => num}
# 另外，還可以添加STARTROW、TIMERANGE和FITLER等高級功能
# 例如：掃描表t1的前5條數據
hbase(main)> scan 't1',{LIMIT=>5}
c）查詢表中的數據行數
# 語法：count <table>, {INTERVAL => intervalNum, CACHE => cacheNum}
# INTERVAL設置多少行顯示一次及對應的rowkey，默認1000；CACHE每次去取的緩存區大小，默認是10，調整該參數可提高查詢速度
# 例如，查詢表t1中的行數，每100條顯示一次，緩存區為500
hbase(main)> count 't1', {INTERVAL => 100, CACHE => 500}
3）刪除數據
a )刪除行中的某個列值
# 語法：delete <table>, <rowkey>, <family:column> , <timestamp>,必須指定列名
# 例如：刪除表t1，rowkey001中的f1:col1的數據
hbase(main)> delete 't1','rowkey001','f1:col1'
註：將刪除改行f1:col1列所有版本的數據
b )刪除行
# 語法：deleteall <table>, <rowkey>, <family:column> , <timestamp>，可以不指定列名，刪除整行數據
# 例如：刪除表t1，rowk001的數據
hbase(main)> deleteall 't1','rowkey001'
c）刪除表中的所有數據
# 語法： truncate <table>
# 其具體過程是：disable table -> drop table -> create table
# 例如：刪除表t1的所有數據
hbase(main)> truncate 't1'
Region管理
1）移動region
# 語法：move 'encodeRegionName', 'ServerName'
# encodeRegionName指的regioName後面的編碼，ServerName指的是master-status的Region Servers列表
# 示例
hbase(main)>move '', 'db-41.xxx.xxx.org,60020,1390274516739'
2）開啟/關閉region
# 語法：balance_switch true|false
hbase(main)> balance_switch
3）手動split
# 語法：split 'regionName', 'splitKey'
4）手動觸發major compaction
#語法：
#Compact all regions in a table:
#hbase> major_compact 't1'
#Compact an entire region:
#hbase> major_compact 'r1'
#Compact a single column family within a region:
#hbase> major_compact 'r1', 'c1'
#Compact a single column family within a table:
#hbase> major_compact 't1', 'c1'
配置管理及節點重啟
1）修改hdfs配置
hdfs配置位置：/etc/hadoop/conf
# 同步hdfs配置
cat /home/hadoop/slaves|xargs -i -t scp /etc/hadoop/conf/hdfs-site.xml hadoop@{}:/etc/hadoop/conf/hdfs-site.xml
#關閉：
cat /home/hadoop/slaves|xargs -i -t ssh hadoop@{} "sudo /home/hadoop/cdh4/hadoop-2.0.0-cdh4.2.1/sbin/hadoop-daemon.sh --config /etc/hadoop/conf stop datanode"
#啟動：
cat /home/hadoop/slaves|xargs -i -t ssh hadoop@{} "sudo /home/hadoop/cdh4/hadoop-2.0.0-cdh4.2.1/sbin/hadoop-daemon.sh --config /etc/hadoop/conf start datanode"
2）修改hbase配置
hbase配置位置：
# 同步hbase配置
cat /home/hadoop/hbase/conf/regionservers|xargs -i -t scp /home/hadoop/hbase/conf/hbase-site.xml hadoop@{}:/home/hadoop/hbase/conf/hbase-site.xml
# graceful重啟
cd ~/hbase
bin/graceful_stop.sh --restart --reload --debug inspurXXX.xxx.xxx.org