安裝過程中，由於網絡終端，導致下面問題：

問題1：安裝停止在獲取安裝鎖

/tmp/scm_prepare_node.tYlmPfrT

usingSSH_CLIENT to get the SCM hostname: 172.16.77.20 33950 22
opening logging file descriptor

正在啓動安裝腳本...正在獲取安裝鎖...BEGIN flock 4

這段大概過了半個小時，一次卸載，一次等了快1個小時，終於過去了，

問題2：不能選擇主機

安裝失敗了，重新不能選主機

圖1
解決方案，需要清理安裝失敗文件
卸載 Cloudera Manager 5.1.x.和相關軟件【官網翻譯：高可用】

問題3：DNS反向解析PTR localhost：

描述：

DNS反向解析錯誤，不能正確解析Cloudera Manager Server主機名
日誌：

Detecting Cloudera Manager Server...
Detecting Cloudera Manager Server...
BEGIN host -t PTR 192.168.1.198
198.1.168.192.in-addr.arpa domain name pointerlocalhost.
END (0)
using localhost as scm server hostname
BEGIN which python
/usr/bin/python
END (0)
BEGIN python -c 'import socket; import sys; s = socket.socket(socket.AF_INET);s.settimeout(5.0); s.connect((sys.argv[1], int(sys.argv[2]))); s.close();'localhost 7182
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "<string>", line 1, in connect
socket.error: [Errno 111] Connection refused
END (1)
could not contact scm server at localhost:7182, giving up
waiting for rollback request

解決方案：

將連不上的機器 /usr/bin/host 文件刪掉,執行下面命令：

1. sudo mv/usr/bin/host /usr/bin/host.bak

複製代碼

說明：

不明白cloudera的初衷，這裏已經得到 ClouderaManager Server的ip了，卻還要把ip解析成主機名來連接

由於DNS反向解析沒有配置好，根據Cloudera ManagerServer 的ip解析主機名卻得到了localhost，造成之後的連接錯誤

這裏的解決方案是直接把/usr/bin/host刪掉，這樣ClouderaManager就會直接使用 ip進行連接，就沒有錯了

參考：

問題 4 NTP:

問題描述：

Bad Health --Clock Offset

The host's NTP service did not respond to a request forthe clock offset.

解決：

配置NTP服務

步驟參考：

CentOS配置NTP Server:

http://www.hailiangchen.com/centos-ntp/

國內常用NTP服務器地址及IP

http://www.douban.com/note/171309770/

修改配置文件：
[root@work03 ~]# vim /etc/ntp.conf

# Use public servers from the pool.ntp.org project.

# Please consider joining the pool (http://www.pool.ntp.org/join.html).

server s1a.time.edu.cn prefer

server s1b.time.edu.cn

server s1c.time.edu.cn

restrict 172.16.1.0 mask 255.255.255.0 nomodify <===放行局域網來源

啓動ntp
#service ntpd restart <===啓動ntp服務
客戶端同步時間(work02,work03）：
ntpdate work01
說明：NTP服務啓動需要大約五分鐘時間，服務啓動之前，若客戶端同步時間，則會出現錯誤“no server suitable for synchronization found”
定時同步時間：
在work02和 work03上配置crontab定時同步時間

crontab -e
00 12 * * * root /usr/sbin/ntpdate 192.168.56.121 >> /root/ntpdate.log2>&1
問題 2.2
描述：
Clock Offset

· Ensure that thehost's hostname is configured properly.

· Ensure that port7182 is accessible on the Cloudera Manager Server (check firewall rules).

· Ensure that ports9000 and 9001 are free on the host being added.

· Check agent logsin /var/log/cloudera-scm-agent/ on the host being added (some of the logs canbe found in the installation details).

問題定位：

在對應host（work02、work03）上運行 'ntpdc -c loopinfo'
[root@work03 work]# ntpdc -c loopinfo
ntpdc: read: Connection refused

解決：

開啓ntp服務：
三臺機器都開機啓動 ntp服務
chkconfig ntpd on

問題 5 heartbeat:

錯誤信息：

Installation failed. Failed to receive heartbeat from agent.

解決：關閉防火牆

問題 6 Unknow Health：

Unknow Health
重啓後：Request to theHost Monitor failed.
service --status-all| grep clo
機器上查看scm-agent狀態：cloudera-scm-agentdead but pid file exists
解決：重啓服務
service cloudera-scm-agent restart

service cloudera-scm-server restart

問題 7 canonial name hostnameconsistent：

Bad Health

The hostname and canonical name for this host are notconsistent when checked from a Java process.

canonical name：

4092 Monitor-HostMonitor throttling_loggerWARNING (29 skipped) hostname work02 differs from the canonical namework02.xinzhitang.com

解決：修改hosts 使FQDN和 hostname相同

ps：雖然解決了但是不明白爲什麼主機名和主機別名要一樣

/etc/hosts

192.168.1.185 work01 work01

192.168.1.141 work02 work02

192.168.1.198 work03 work03

問題 8 Concerning Health：

Concerning Health Issue

-- Network Interface Speed --

描述：The host has 2 network interface(s) that appear to beoperating at less than full speed. Warning threshold: any.

詳細：

This is a host health test that checks for networkinterfaces that appear to be operating at less than full speed.
A failure of this health test may indicate that network interface(s) may beconfigured incorrectly and may be causing performance problems. Use the ethtoolcommand to check and configure the host's network interfaces to use the fastestavailable link speed and duplex mode.

解決：

本次測試修改了 Cloudera Manager 的配置，應該不算是真正的解決

問題10 IOException thrown while collecting data from host: No route to host

原因：agent開啓了防火牆

解決：service iptables stop

問題11

2、Clouderarecommendssetting /proc/sys/vm/swappiness to 0. Current setting is 60. Use thesysctlcommand to change this setting at runtime and edit /etc/sysctl.conf forthissetting to be saved after a reboot. You may continue with installation, butyoumay run into issues with Cloudera Manager reporting that your hostsareunhealthy because they are swapping. The following hosts are affected:

解決：

# echo 0>/proc/sys/vm/swappiness （toapply for now）

# sysctl-wvm.swappiness=0 （to makethis persistentacross reboots）

問題12 時鐘不同步（同步至中科大時鐘服務器202.141.176.110）

# echo "0 3 * **/usr/sbin/ntpdate 202.141.176.110;/sbin/hwclock–w">>/var/spool/cron/root

# service crondrestart

# ntpdate202.141.176.110

問題13 The host's NTPservice didnot respond to a request for the clock offset.

#service ntpdstart

# ntpdc -cloopinfo (thehealth will be good if this command executed successfully)

問題14 The Cloudera ManagerAgentis not able to communicate with this role's web server.

一種原因是元數據數據庫無法連接，請檢查數據庫配置：

問題15 Hive MetastoreServer無法啓動，修改Hive元數據數據庫配置（當我們修改主機名後即應修改元數據數據庫配置）：

問題排查方式

一般的錯誤，查看錯誤輸出，按照關鍵字google
異常錯誤（如namenode、datanode莫名其妙掛了）：查看hadoop（$HADOOP_HOME/logs）或hive日誌

hadoop錯誤

問題16 datanode無法正常啓動

添加datanode後，datanode無法正常啓動，進程一會莫名其妙掛掉，查看namenode日誌顯示如下：

Text代碼

2013-06-21 18:53:39,182 FATALorg.apache.hadoop.hdfs.StateChange: BLOCK* NameSystem.getDatanode: Data nodex.x.x.x:50010 is attempting to report storage ID DS-1357535176-x.x.x.x-50010-1371808472808.Node y.y.y.y:50010 is expected to serve this storage.

原因分析：
拷貝hadoop安裝包時，包含data與tmp文件夾（見本人《hadoop安裝》一文），未成功格式化datanode
解決辦法：

Shell代碼

rm -rf /data/hadoop/hadoop-1.1.2/data

rm -rf /data/hadoop/hadoop-1.1.2/tmp

hadoop datanode -format

問題17 safe mode

Text代碼

2013-06-2010:35:43,758 ERROR org.apache.hadoop.security.UserGroupInformation:PriviledgedActionException as:hadoopcause:org.apache.hadoop.hdfs.server.namenode.SafeModeException: Cannot renewlease for DFSClient_hb_rs_wdev1.corp.qihoo.net,60020,1371631589073. Name nodeis in safe mode.

解決方案：

Shell代碼

hadoopdfsadmin -safemode leave

問題18 連接異常

Text代碼

2013-06-21 19:55:05,801 WARNorg.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: Call tohomename/x.x.x.x:9000 failed on local exception: java.io.EOFException

可能原因：

namenode監聽127.0.0.1:9000，而非0.0.0.0:9000或外網IP:9000
iptables限制

解決方案：

檢查/etc/hosts配置，使得hostname綁定到非127.0.0.1的IP上
iptables放開端口

問題19 namenode id

Text代碼

ERROR org.apache.hadoop.hdfs.server.datanode.DataNode:java.io.IOException: Incompatible namespaceIDs in/var/lib/hadoop-0.20/cache/hdfs/dfs/data: namenode namespaceID = 240012870;datanode namespaceID = 1462711424 .

問題：Namenode上namespaceID與datanode上namespaceID不一致。

　　問題產生原因：每次namenode format會重新創建一個namenodeId,而tmp/dfs/data下包含了上次format下的id,namenode format清空了namenode下的數據,但是沒有清空datanode下的數據,所以造成namenode節點上的namespaceID與 datanode節點上的namespaceID不一致。啓動失敗。

　　解決辦法：參考該網址http://blog.csdn.net/wh62592855/archive/2010/07/21/5752199.aspx 給出兩種解決方法，我們使用的是第一種解決方法：即:

　　(1)停掉集羣服務

　　(2)在出問題的datanode節點上刪除data目錄，data目錄即是在hdfs-site.xml文件中配置的 dfs.data.dir目錄，本機器上那個是/var/lib/hadoop-0.20/cache/hdfs/dfs/data/(注：我們當時在所有的datanode和namenode節點上均執行了該步驟。以防刪掉後不成功，可以先把data目錄保存一個副本).

　　(3)格式化namenode.

　　(4)重新啓動集羣。

　　問題解決。
這種方法帶來的一個副作用即是，hdfs上的所有數據丟失。如果hdfs上存放有重要數據的時候，不建議採用該方法，可以嘗試提供的網址中的第二種方法。

問題20 目錄權限

start-dfs.sh執行無錯，顯示啓動datanode，執行完後無datanode。查看datanode機器上的日誌，顯示因dfs.data.dir目錄權限不正確導致：

Text代碼

expected: drwxr-xr-x,current:drwxrwxr-x

解決辦法：
查看dfs.data.dir的目錄配置，修改權限即可。

hive錯誤

問題21 NoClassDefFoundError

Could not initialize class java.lang.NoClassDefFoundError: Could not initializeclass org.apache.hadoop.hbase.io.HbaseObjectWritable
將protobuf-***.jar添加到jars路徑

Xml代碼

//$HIVE_HOME/conf/hive-site.xml

hive.aux.jars.path

file:///data/hadoop/hive-0.10.0/lib/hive-hbase-handler-0.10.0.jar,file:///data/hadoop/hive-0.10.0/lib/hbase-0.94.8.jar,file:///data/hadoop/hive-0.10.0/lib/zookeeper-3.4.5.jar,file:///data/hadoop/hive-0.10.0/lib/guava-r09.jar,file:///data/hadoop/hive-0.10.0/lib/hive-contrib-0.10.0.jar,file:///data/hadoop/hive-0.10.0/lib/protobuf-java-2.4.0a.jar

問題22 hive動態分區異常

[Fatal Error] Operator FS_2 (id=2): Number of dynamic partitions exceededhive.exec.max.dynamic.partitions.pernode

Shell代碼

hive> sethive.exec.max.dynamic.partitions.pernode = 10000;

問題23 mapreduce進程超內存限制——hadoop Java heap space

vim mapred-site.xml添加：

Xml代碼

//mapred-site.xml

mapred.child.java.opts

-Xmx2048m

Shell代碼

#$HADOOP_HOME/conf/hadoop_env.sh

exportHADOOP_HEAPSIZE=5000

問題24 hive文件數限制

[Fatal Error] total number of created files now is 100086, which exceeds 100000

Shell代碼

hive> sethive.exec.max.created.files=655350;

問題25 hive 5.metastore連接超時

Text代碼

FAILED:SemanticException org.apache.thrift.transport.TTransportException:java.net.SocketTimeoutException: Read timed out

解決方案：

Shell代碼

hive>set hive.metastore.client.socket.timeout=500;

問題26 hive 6.java.io.IOException: error=7, Argument list too long

Text代碼

Task withthe most failures(5):

-----

Task ID:

task_201306241630_0189_r_000009

URL:

http://namenode.godlovesdog.com:50030/taskdetails.jsp?jobid=job_201306241630_0189&tipid=task_201306241630_0189_r_000009

-----

DiagnosticMessages for this Task:

java.lang.RuntimeException:org.apache.hadoop.hive.ql.metadata.HiveException: Hive Runtime Error whileprocessing row (tag=0){"key":{"reducesinkkey0":"164058872","reducesinkkey1":"djh,S1","reducesinkkey2":"20130117170703","reducesinkkey3":"xxx"},"value":{"_col0":"1","_col1":"xxx","_col2":"20130117170703","_col3":"164058872","_col4":"xxx,S1"},"alias":0}

atorg.apache.hadoop.hive.ql.exec.ExecReducer.reduce(ExecReducer.java:270)

at org.apache.hadoop.mapred.ReduceTask.runOldReducer(ReduceTask.java:520)

atorg.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:421)

atorg.apache.hadoop.mapred.Child$4.run(Child.java:255)

atjava.security.AccessController.doPrivileged(Native Method)

at javax.security.auth.Subject.doAs(Subject.java:415)

atorg.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1149)

atorg.apache.hadoop.mapred.Child.main(Child.java:249)

Caused by:org.apache.hadoop.hive.ql.metadata.HiveException: Hive Runtime Error whileprocessing row (tag=0){"key":{"reducesinkkey0":"164058872","reducesinkkey1":"xxx,S1","reducesinkkey2":"20130117170703","reducesinkkey3":"xxx"},"value":{"_col0":"1","_col1":"xxx","_col2":"20130117170703","_col3":"164058872","_col4":"djh,S1"},"alias":0}

atorg.apache.hadoop.hive.ql.exec.ExecReducer.reduce(ExecReducer.java:258)

... 7 more

Caused by:org.apache.hadoop.hive.ql.metadata.HiveException: [Error 20000]: Unable toinitialize custom script.

atorg.apache.hadoop.hive.ql.exec.ScriptOperator.processOp(ScriptOperator.java:354)

atorg.apache.hadoop.hive.ql.exec.Operator.process(Operator.java:474)

atorg.apache.hadoop.hive.ql.exec.Operator.forward(Operator.java:800)

atorg.apache.hadoop.hive.ql.exec.SelectOperator.processOp(SelectOperator.java:84)

atorg.apache.hadoop.hive.ql.exec.Operator.process(Operator.java:474)

atorg.apache.hadoop.hive.ql.exec.Operator.forward(Operator.java:800)

atorg.apache.hadoop.hive.ql.exec.ExtractOperator.processOp(ExtractOperator.java:45)

at org.apache.hadoop.hive.ql.exec.Operator.process(Operator.java:474)

atorg.apache.hadoop.hive.ql.exec.ExecReducer.reduce(ExecReducer.java:249)

... 7 more

Caused by:java.io.IOException: Cannot run program "/usr/bin/python2.7":error=7, 參數列表過長

at java.lang.ProcessBuilder.start(ProcessBuilder.java:1042)

atorg.apache.hadoop.hive.ql.exec.ScriptOperator.processOp(ScriptOperator.java:313)

... 15 more

Caused by:java.io.IOException: error=7, 參數列表過長

atjava.lang.UNIXProcess.forkAndExec(Native Method)

at java.lang.UNIXProcess.(UNIXProcess.java:135)

atjava.lang.ProcessImpl.start(ProcessImpl.java:130)

atjava.lang.ProcessBuilder.start(ProcessBuilder.java:1023)

... 16 more

FAILED:Execution Error, return code 20000 fromorg.apache.hadoop.hive.ql.exec.MapRedTask. Unable to initialize custom script.

解決方案：
升級內核或減少分區數https://issues.apache.org/jira/browse/HIVE-2372

問題27 hive 6.runtime error

Shell代碼

hive> show tables;

FAILED: Error in metadata: java.lang.RuntimeException:Unable to instantiate org.apache.hadoop.hive.metastore.HiveMetaStoreClient

FAILED: Execution Error, return code 1 fromorg.apache.hadoop.hive.ql.exec.DDLTask

問題排查：

Shell代碼

hive -hiveconf hive.root.logger=DEBUG,console

Text代碼

13/07/15 16:29:24 INFO hive.metastore: Trying to connectto metastore with URI thrift://xxx.xxx.xxx.xxx:9083

13/07/15 16:29:24 WARN hive.metastore: Failed to connectto the MetaStore Server...

org.apache.thrift.transport.TTransportException:java.net.ConnectException: 拒絕連接

。。。

MetaException(message:Could not connect to meta storeusing any of the URIs provided. Most recent failure:org.apache.thrift.transport.TTransportException: java.net.ConnectException: 拒絕連接

嘗試連接9083端口，netstat查看該端口確實沒有被監聽，第一反應是hiveserver沒有正常啓動。查看hiveserver進程卻存在，只是監聽10000端口。
查看hive-site.xml配置，hive客戶端連接9083端口，而hiveserver默認監聽10000，找到問題根源了
解決辦法：

Shell代碼

hive --service hiveserver -p 9083

//或修改$HIVE_HOME/conf/hive-site.xml的hive.metastore.uris部分

//將端口改爲10000

using /usr/lib/hive as HIVE_HOME

using /var/run/cloudera-scm-agent/process/193-hive-HIVEMETASTOREas HIVE_CONF_DIR

using /usr/lib/hadoop as HADOOP_HOME

using/var/run/cloudera-scm-agent/process/193-hive-HIVEMETASTORE/yarn-conf asHADOOP_CONF_DIR

ERROR: Failed to find hive-hbase storage handler jars toadd in hive-site.xml. Hive queries that use Hbase storage handler may not workuntil this is fixed.

Wed Oct 22 18:48:53 CST 2014

JAVA_HOME=/usr/java/jdk1.7.0_45-cloudera

using /usr/java/jdk1.7.0_45-cloudera as JAVA_HOME

using 5 as CDH_VERSION

using /usr/lib/hive as HIVE_HOME

using /var/run/cloudera-scm-agent/process/193-hive-HIVEMETASTOREas HIVE_CONF_DIR

using /usr/lib/hadoop as HADOOP_HOME

using/var/run/cloudera-scm-agent/process/193-hive-HIVEMETASTORE/yarn-conf asHADOOP_CONF_DIR

ERROR: Failed to find hive-hbase storage handler jars toadd in hive-site.xml. Hive queries that use Hbase storage handler may not workuntil this is fixed.

Wed Oct 22 18:48:55 CST 2014

JAVA_HOME=/usr/java/jdk1.7.0_45-cloudera

using /usr/java/jdk1.7.0_45-cloudera as JAVA_HOME

using 5 as CDH_VERSION

using /usr/lib/hive as HIVE_HOME

using/var/run/cloudera-scm-agent/process/193-hive-HIVEMETASTORE as HIVE_CONF_DIR

using /usr/lib/hadoop as HADOOP_HOME

using/var/run/cloudera-scm-agent/process/193-hive-HIVEMETASTORE/yarn-conf asHADOOP_CONF_DIR

ERROR: Failed to find hive-hbase storage handler jars toadd in hive-site.xml. Hive queries that use Hbase storage handler may not workuntil this is fixed.

Wed Oct 22 18:48:58 CST 2014

JAVA_HOME=/usr/java/jdk1.7.0_45-cloudera

using /usr/java/jdk1.7.0_45-cloudera as JAVA_HOME

using 5 as CDH_VERSION

using /usr/lib/hive as HIVE_HOME

using/var/run/cloudera-scm-agent/process/193-hive-HIVEMETASTORE as HIVE_CONF_DIR

using /usr/lib/hadoop as HADOOP_HOME

using/var/run/cloudera-scm-agent/process/193-hive-HIVEMETASTORE/yarn-conf asHADOOP_CONF_DIR

ERROR: Failed to find hive-hbase storage handler jars toadd in hive-site.xml. Hive queries that use Hbase storage handler may not workuntil this is fixed.

JAVA_HOME=/usr/java/jdk1.7.0_45-cloudera

using /usr/java/jdk1.7.0_45-cloudera as JAVA_HOME

using 5 as CDH_VERSION

using /usr/lib/hive as HIVE_HOME

using /var/run/cloudera-scm-agent/process/212-hive-metastore-create-tables as HIVE_CONF_DIR

using /usr/lib/hadoop as HADOOP_HOME

using /var/run/cloudera-scm-agent/process/212-hive-metastore-create-tables/yarn-conf as HADOOP_CONF_DIR

ERROR: Failed to find hive-hbase storage handler jars to add in hive-site.xml. Hive queries that use Hbase storage handler may not work until this is fixed.

查看 /usr/lib/hive 是否正常

正常的

下午3點21:09.801 FATAL org.apache.hadoop.hbase.master.HMaster

Unhandled exception. Starting shutdown.

java.io.IOException: error or interruptedwhile splitting logs in[hdfs://master:8020/hbase/WALs/slave2,60020,1414202360923-splitting] Task =installed = 2 done = 1 error = 1

atorg.apache.hadoop.hbase.master.SplitLogManager.splitLogDistributed(SplitLogManager.java:362)

atorg.apache.hadoop.hbase.master.MasterFileSystem.splitLog(MasterFileSystem.java:409)

atorg.apache.hadoop.hbase.master.MasterFileSystem.splitMetaLog(MasterFileSystem.java:301)

atorg.apache.hadoop.hbase.master.MasterFileSystem.splitMetaLog(MasterFileSystem.java:292)

atorg.apache.hadoop.hbase.master.HMaster.splitMetaLogBeforeAssignment(HMaster.java:1070)

atorg.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:854)

atorg.apache.hadoop.hbase.master.HMaster.run(HMaster.java:606)

atjava.lang.Thread.run(Thread.java:744)

下午3點46:12.903 FATAL org.apache.hadoop.hbase.master.HMaster

Unhandled exception. Starting shutdown.

java.io.IOException: error or interruptedwhile splitting logs in[hdfs://master:8020/hbase/WALs/slave2,60020,1414202360923-splitting] Task =installed = 1 done = 0 error = 1

atorg.apache.hadoop.hbase.master.SplitLogManager.splitLogDistributed(SplitLogManager.java:362)

atorg.apache.hadoop.hbase.master.MasterFileSystem.splitLog(MasterFileSystem.java:409)

atorg.apache.hadoop.hbase.master.MasterFileSystem.splitMetaLog(MasterFileSystem.java:301)

atorg.apache.hadoop.hbase.master.MasterFileSystem.splitMetaLog(MasterFileSystem.java:292)

atorg.apache.hadoop.hbase.master.HMaster.splitMetaLogBeforeAssignment(HMaster.java:1070)

atorg.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:854)

atorg.apache.hadoop.hbase.master.HMaster.run(HMaster.java:606)

atjava.lang.Thread.run(Thread.java:744)

解決方法：
在hbase-site.xml加入一條，讓啓動hbase集羣時不做hlog splitting

<property>
<name>hbase.master.distributed.log.splitting</name>
<value>false</value>
</property>

[root@master ~]# hadoop fs -mv/hbase/WALs/slave2,60020,1414202360923-splitting/ /test

[root@master ~]# hadoop fs -ls /test

2014-10-28 14:31:32,879 INFO[hconnection-0xd18e8a7-shared--pool2-t224] (AsyncProcess.java:673) - #3,table=session_service_201410210000_201410312359, attempt=14/35 failed 1383 ops,last exception: org.apache.hadoop.hbase.RegionTooBusyException:org.apache.hadoop.hbase.RegionTooBusyException: Above memstore limit,regionName=session_service_201410210000_201410312359,7499999991,1414203068872.08ee7bb71161cb24e18ddba4c14da0f2.,server=slave1,60020,1414380404290, memstoreSize=271430320,blockingMemStoreSize=268435456

atorg.apache.hadoop.hbase.regionserver.HRegion.checkResources(HRegion.java:2561)

atorg.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:1963)

at org.apache.hadoop.hbase.regionserver.HRegionServer.doBatchOp(HRegionServer.java:4050)

atorg.apache.hadoop.hbase.regionserver.HRegionServer.doNonAtomicRegionMutation(HRegionServer.java:3361)

atorg.apache.hadoop.hbase.regionserver.HRegionServer.multi(HRegionServer.java:3265)

atorg.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26935)

at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2175)

at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1879)

Exception	Description
ClockOutOfSyncException	當一個RegionServer始終偏移太大時，master節點結將會拋出此異常.
DoNotRetryIOException	用於提示不要再重試的異常子類: 如UnknownScannerException`.`
DroppedSnapshotException	如果在flush過程中快照內容並沒有正確的存儲到文件中時,該異常將被拋出.
HBaseIOException	所有hbase特定的IOExceptions都是HBaseIOException類的子類.
InvalidFamilyOperationException	Hbase接收修改表schema的請求，但請求中對應的列族名無效.
MasterNotRunningException	master節點沒有運行的異常
NamespaceExistException	已存在某namespace的異常
NamespaceNotFoundException	找不到該namsespace的異常
NotAllMetaRegionsOnlineException	某操作需要所有root及meta節點同時在線,但實際情況不滿足該操作要求
NotServingRegionException	向某RegionServer發送訪問請求，但是它並沒有反應或該region不可用.
PleaseHoldException	當某個ResionServer宕掉並由於重啓過快而導致master來不及處理宕掉之前的server實例, 或者用戶調用admin級操作時master正處於初始化狀態時, 或者在正在啓動的RegionServer上進行操作時都會拋出此類異常.
RegionException	訪問region時出現的異常.
RegionTooBusyException	RegionServer處於繁忙狀態並由於阻塞而等待提供服務的異常.
TableExistsException	已存在某表的異常
TableInfoMissingException	在table目錄下無法找到.tableinfo文件的異常
TableNotDisabledException	某個表沒有正常處於禁用狀態的異常
TableNotEnabledException	某個表沒有正常處於啓用狀態的異常
TableNotFoundException	無法找到某個表的異常
UnknownRegionException	訪問無法識別的region引起的異常.
UnknownScannerException	向RegionServer傳遞了無法識別的scanner id的異常.
YouAreDeadException	當一個RegionServer報告它已被處理爲dead狀態，由master拋出此異常.
ZooKeeperConnectionException	客戶端無法連接到zookeeper的異常.

INFO

org.apache.hadoop.hbase.regionserver.MemStoreFlusher

Waited 90779ms on a compaction to clean up 'too many store files'; waited long enough... proceeding with flush of session_service_201410210000_201410312359,7656249951,1414481868315.bbf0a49fb8a9b650a584769ddd1fdd89.

MemStoreFlusher實例生成時會啓動MemStoreFlusher.FlushHandler線程實例，

此線程個數通過hbase.hstore.flusher.count配置,默認爲1

一臺機器硬盤滿，一臺機器硬盤不滿的情況：

羣集中有 26,632 個副本不足的塊塊。羣集中共有 84,822 個塊。百分比副本不足的塊: 31.40%。警告閾值：10.00%。

羣集中有 27,278 個副本不足的塊塊。羣集中共有 85,476 個塊。百分比副本不足的塊: 31.91%。警告閾值：10.00%。

下午4點08:53.847	INFO	org.apache.hadoop.hbase.regionserver.DefaultStoreFlusher	Flushed, sequenceid=45525, memsize=124.2 M, hasBloomFilter=true, into tmp file hdfs://master:8020/hbase/data/default/session_service_201410260000_201410312359/a3b64675b0069b8323665274e2f95cdc/.tmp/b7fa4f5f85354ecc96aa48a09081f786
下午4點08:53.862	INFO	org.apache.hadoop.hbase.regionserver.HStore	Added hdfs://master:8020/hbase/data/default/session_service_201410260000_201410312359/a3b64675b0069b8323665274e2f95cdc/f/b7fa4f5f85354ecc96aa48a09081f786, entries=194552, sequenceid=45525, filesize=47.4 M
下午4點09:00.378	WARN	org.apache.hadoop.ipc.RpcServer	(responseTooSlow): {"processingtimems":39279,"call":"Scan(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ScanRequest)","client":"192.168.5.9:41284","starttimems":1414656501099,"queuetimems":0,"class":"HRegionServer","responsesize":16,"method":"Scan"}
下午4點09:00.379	WARN	org.apache.hadoop.ipc.RpcServer	RpcServer.respondercallId: 33398 service: ClientService methodName: Scan size: 209 connection: 192.168.5.9:41284: output error
下午4點09:00.380	WARN	org.apache.hadoop.ipc.RpcServer	RpcServer.handler=79,port=60020: caught a ClosedChannelException, this means that the server was processing a request but the client went away. The error message was: null
下午4點09:00.381	INFO	org.apache.hadoop.hbase.regionserver.HRegion	Finished memstore flush of ~128.1 M/134326016, currentsize=2.4 M/2559256 for region session_service_201410260000_201410312359,6406249959,1414571385831.a3b64675b0069b8323665274e2f95cdc. in 8133ms, sequenceid=45525, compaction requested=false
下

問題28 hbase hbase.hregion.max.filesize應該設置多少合適

默認值：256M
說明：Maximum HStoreFile size. If any one of a column families'HStoreFiles has grown to exceed this value, the hosting HRegion is splitin two.

HStoreFile的最大值。如果任何一個Column Family（或者說HStore）的HStoreFiles的大小超過這個值，那麼，其所屬的HRegion就會Split成兩個。

調優：

hbase中hfile的默認最大值(hbase.hregion.max.filesize)是256MB，而google的bigtable論文中對tablet的最大值也推薦爲100-200MB，這個大小有什麼祕密呢？
　　衆所周知hbase中數據一開始會寫入memstore，當memstore滿64MB以後，會flush到disk上而成爲storefile。當storefile數量超過3時，會啓動compaction過程將它們合併爲一個storefile。這個過程中會刪除一些timestamp過期的數據，比如update的數據。而當合並後的storefile大小大於hfile默認最大值時，會觸發split動作，將它切分成兩個region。
　　lz進行了持續insert壓力測試，並設置了不同的hbase.hregion.max.filesize，根據結果得到如下結論：值越小，平均吞吐量越大，但吞吐量越不穩定；值越大，平均吞吐量越小，吞吐量不穩定的時間相對更小。

　　爲什麼會這樣呢？推論如下：

   a 當hbase.hregion.max.filesize比較小時，觸發split的機率更大，而split的時候會將region offline，因此在split結束的時間前，訪問該region的請求將被block住，客戶端自我block的時間默認爲1s。當大量的region同時發生split時，系統的整體訪問服務將大受影響。因此容易出現吞吐量及響應時間的不穩定現象
   b 當hbase.hregion.max.filesize比較大時，單個region中觸發split的機率較小，大量region同時觸發split的機率也較小，因此吞吐量較之小hfile尺寸更加穩定些。但是由於長期得不到split，因此同一個region內發生多次compaction的機會增加了。compaction的原理是將原有數據讀一遍並重寫一遍到hdfs上，然後再刪除原有數據。無疑這種行爲會降低以io爲瓶頸的系統的速度，因此平均吞吐量會受到一些影響而下降。
   綜合以上兩種情況，hbase.hregion.max.filesize不宜過大或過小，256MB或許是一個更理想的經驗參數。對於離線型的應用，調整爲128MB會更加合適一些，而在線應用除非對split機制進行改造，否則不應該低於256MB

問題29hbase autoflush=false的影響

　　無論是官方還是很多blog都提倡爲了提高hbase的寫入速度而在應用代碼中設置autoflush=false，然後lz認爲在在線應用中應該謹慎進行該設置。原因如下：

　　a autoflush=false的原理是當客戶端提交delete或put請求時，將該請求在客戶端緩存，直到數據超過2M(hbase.client.write.buffer決定)或用戶執行了hbase.flushcommits()時才向regionserver提交請求。因此即使htable.put()執行返回成功，也並非說明請求真的成功了。假如還沒有達到該緩存而client崩潰，該部分數據將由於未發送到regionserver而丟失。這對於零容忍的在線服務是不可接受的。

　　b autoflush=true雖然會讓寫入速度下降2-3倍，但是對於很多在線應用來說這都是必須打開的，也正是hbase爲什麼讓它默認值爲true的原因。當該值爲true時，每次請求都會發往regionserver,而regionserver接收到請求後第一件事就是寫hlog，因此對io的要求是非常高的，爲了提高hbase的寫入速度，應該儘可能高地提高io吞吐量，比如增加磁盤、使用raid 卡、減少replication因子數等

問題 30 hbase從性能的角度談table中family和qualifier的設置

　　對於傳統關係型數據庫中的一張table，在業務轉換到hbase上建模時，從性能的角度應該如何設置family和qualifier呢？
　　最極端的，①每一列都設置成一個family，②一個表僅有一個family，所有列都是其中的一個qualifier，那麼有什麼區別呢？

　　從讀的方面考慮：
　　family越多，那麼獲取每一個cell數據的優勢越明顯，因爲io和網絡都減少了。

　　如果只有一個family，那麼每一次讀都會讀取當前rowkey的所有數據，網絡和io上會有一些損失。

　　當然如果要獲取的是固定的幾列數據，那麼把這幾列寫到一個family中比分別設置family要更好，因爲只需一次請求就能拿回所有數據。

　　從寫的角度考慮：

　　首先，內存方面來說，對於一個Region，會爲每一個表的每一個Family分配一個Store，而每一個Store，都會分配一個MemStore，所以更多的family會消耗更多的內存。
　　其次，從flush和compaction方面說，目前版本的hbase，在flush和compaction都是以region爲單位的，也就是說當一個family達到flush條件時，該region的所有family所屬的memstore都會flush一次，即使memstore中只有很少的數據也會觸發flush而生成小文件。這樣就增加了compaction發生的機率，而compaction也是以region爲單位的，這樣就很容易發生compaction風暴從而降低系統的整體吞吐量。
　　第三，從split方面考慮，由於hfile是以family爲單位的，因此對於多個family來說，數據被分散到了更多的hfile中，減小了split發生的機率。這是把雙刃劍。更少的split會導致該region的體積比較大，由於balance是以region的數目而不是大小爲單位來進行的，因此可能會導致balance失效。而從好的方面來說，更少的split會讓系統提供更加穩定的在線服務。而壞處我們可以通過在請求的低谷時間進行人工的split和balance來避免掉。
因此對於寫比較多的系統，如果是離線應該，我們儘量只用一個family好了，但如果是在線應用，那還是應該根據應用的情況合理地分配family。

問題31 hbase.regionserver.handler.count

RegionServer端開啓的RPC監聽器實例個數，也即RegionServer能夠處理的IO請求線程數。默認是10.

此參數與內存息息相關。該值設置的時候，以監控內存爲主要參考。

對於單次請求內存消耗較高的Big PUT場景（大容量單次PUT或設置了較大cache的scan，均屬於BigPUT）或ReigonServer的內存比較緊張的場景，可以設置的相對較小。

對於單次請求內存消耗低，TPS（TransactionPerSecond，每秒事務處理量）要求非常高的場景，可以設置的相對大些。

hive 查詢日誌

2014-11-06 12:39:50,825 Stage-1 map =100%, reduce = 100%, Cumulative CPU1206.39 sec

2014-11-06 12:39:51,873 Stage-1 map =100%, reduce = 100%, Cumulative CPU1206.39 sec

MapReduce Total cumulative CPU time: 20minutes 6 seconds 390 msec

Ended Job = job_1414723034537_0042

Loading data to tabledefault.session_service_t4

chgrp: changing ownership of'/user/hive/warehouse/session_service_t4/000000_0': User does not belong tohive

Table default.session_service_t4 stats:[num_partitions: 0, num_files: 1, num_rows: 0, total_size: 4191, raw_data_size:0]

MapReduce Jobs Launched:

Job 0: Map: 556 Reduce: 1 Cumulative CPU: 1206.39 sec HDFSRead: 36584800 HDFS Write: 4191 SUCCESS

Total MapReduce CPU Time Spent: 20 minutes6 seconds 390 msec

Time taken: 642.531 seconds

2013-05-20 17:39:00,153 ERRORcom.sunchangming.searchlog.CopyAppLogs: err on 2013051918_api_access_65.gz
java.io.IOException: Filesystem closed
at org.apache.hadoop.hdfs.DFSClient.checkOpen(DFSClient.java:319)
at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1026)
atorg.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:524)
at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:768)
at com.sunchangming.searchlog.CopyAppLogs.copyFile(CopyAppLogs.java:51)
at com.sunchangming.searchlog.CopyAppLogs.access$000(CopyAppLogs.java:18)
at com.sunchangming.searchlog.CopyAppLogs$1.run(CopyAppLogs.java:194)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

然後我就查，爲什麼呢。我剛剛用final FileSystem dfs =FileSystem.get(getConf()); 得到它啊。

後來發現，我是一個多線程的程序。FileSystem.get(getConf())返回的可能是一個cache中的結果，它並不是每次都創建一個新的實例。這就意味着，如果每個線程都自己去get一個文件系統，然後使用，然後關閉，就會有問題。因爲你們關閉的可能是同一個對象。而別人還在用它！

所以最好是在main函數中就創建好filesystem對象然後在不同函數之間來回傳遞吧。在main函數用用try…finally關閉它。

多線程程序中，如果你確保在你的get和close之間不會有別人調用get，也沒問題。

hbase調優

HBase性能優化的四個要點

1hbase.hregion.max.filesize應該設置多少合適

默認值：256M

說明：Maximum HStoreFile size. If any one of a columnfamilies' HStoreFiles has grown to exceed this value, the hosting HRegion issplit in two.

HStoreFile的最大值。如果任何一個Column Family（或者說HStore）的HStoreFiles的大小超過這個值，那麼，其所屬的HRegion就會Split成兩個。

調優：

hbase中hfile的默認最大值(hbase.hregion.max.filesize)是256MB，而google的bigtable論文中對tablet的最大值也推薦爲100-200MB，這個大小有什麼祕密呢？

衆所周知hbase中數據一開始會寫入memstore，當memstore滿64MB以後，會flush到disk上而成爲storefile。當storefile數量超過3時，會啓動compaction過程將它們合併爲一個storefile。這個過程中會刪除一些timestamp過期的數據，比如update的數據。而當合並後的storefile大小大於hfile默認最大值時，會觸發split動作，將它切分成兩個region。

lz進行了持續insert壓力測試，並設置了不同的hbase.hregion.max.filesize，根據結果得到如下結論：值越小，平均吞吐量越大，但吞吐量越不穩定；值越大，平均吞吐量越小，吞吐量不穩定的時間相對更小。

爲什麼會這樣呢？推論如下：

b 當hbase.hregion.max.filesize比較大時，單個region中觸發split的機率較小，大量region同時觸發split的機率也較小，因此吞吐量較之小hfile尺寸更加穩定些。但是由於長期得不到split，因此同一個region內發生多次compaction的機會增加了。compaction的原理是將原有數據讀一遍並重寫一遍到hdfs上，然後再刪除原有數據。無疑這種行爲會降低以io爲瓶頸的系統的速度，因此平均吞吐量會受到一些影響而下降。

綜合以上兩種情況，hbase.hregion.max.filesize不宜過大或過小，256MB或許是一個更理想的經驗參數。對於離線型的應用，調整爲128MB會更加合適一些，而在線應用除非對split機制進行改造，否則不應該低於256MB

2autoflush=false的影響

無論是官方還是很多blog都提倡爲了提高hbase的寫入速度而在應用代碼中設置autoflush=false，然後lz認爲在在線應用中應該謹慎進行該設置。原因如下：

a autoflush=false的原理是當客戶端提交delete或put請求時，將該請求在客戶端緩存，直到數據超過2M(hbase.client.write.buffer決定)或用戶執行了hbase.flushcommits()時才向regionserver 提交請求。因此即使htable.put()執行返回成功，也並非說明請求真的成功了。假如還沒有達到該緩存而client崩潰，該部分數據將由於未發送到regionserver而丟失。這對於零容忍的在線服務是不可接受的。

b autoflush=true雖然會讓寫入速度下降2-3倍，但是對於很多在線應用來說這都是必須打開的，也正是hbase爲什麼讓它默認值爲true的原因。當該值爲true時，每次請求都會發往regionserver,而regionserver接收到請求後第一件事就是寫hlog，因此對io的要求是非常高的，爲了提高hbase的寫入速度，應該儘可能高地提高io吞吐量，比如增加磁盤、使用raid卡、減少replication因子數等

3 從性能的角度談table中family和qualifier的設置

對於傳統關係型數據庫中的一張table，在業務轉換到hbase上建模時，從性能的角度應該如何設置family和qualifier呢？

最極端的，①每一列都設置成一個family，②一個表僅有一個family，所有列都是其中的一個qualifier，那麼有什麼區別呢？

從讀的方面考慮：

family越多，那麼獲取每一個cell數據的優勢越明顯，因爲io和網絡都減少了。

如果只有一個family，那麼每一次讀都會讀取當前rowkey的所有數據，網絡和io上會有一些損失。

當然如果要獲取的是固定的幾列數據，那麼把這幾列寫到一個family中比分別設置family要更好，因爲只需一次請求就能拿回所有數據。

從寫的角度考慮：

首先，內存方面來說，對於一個Region，會爲每一個表的每一個Family分配一個Store，而每一個Store，都會分配一個MemStore，所以更多的family會消耗更多的內存。

其次，從flush和compaction方面說，目前版本的hbase，在flush和compaction都是以region爲單位的，也就是說當一個family達到flush條件時，該region的所有family所屬的memstore都會flush一次，即使memstore中只有很少的數據也會觸發flush而生成小文件。這樣就增加了compaction發生的機率，而compaction也是以region爲單位的，這樣就很容易發生compaction風暴從而降低系統的整體吞吐量。

第三，從split方面考慮，由於hfile是以family爲單位的，因此對於多個family來說，數據被分散到了更多的hfile中，減小了 split發生的機率。這是把雙刃劍。更少的split會導致該region的體積比較大，由於balance是以region的數目而不是大小爲單位來進行的，因此可能會導致balance失效。而從好的方面來說，更少的split會讓系統提供更加穩定的在線服務。而壞處我們可以通過在請求的低谷時間進行人工的split和balance來避免掉。

因此對於寫比較多的系統，如果是離線應該，我們儘量只用一個family好了，但如果是在線應用，那還是應該根據應用的情況合理地分配family。

4hbase.regionserver.handler.count

RegionServer端開啓的RPC監聽器實例個數，也即RegionServer能夠處理的IO請求線程數。默認是10.

此參數與內存息息相關。該值設置的時候，以監控內存爲主要參考。

對於單次請求內存消耗低，TPS（TransactionPerSecond，每秒事務處理量）要求非常高的場景，可以設置的相對大些。

1.2 Row Key

HBase中row key用來檢索表中的記錄，支持以下三種方式：

· 通過單個row key訪問：即按照某個row key鍵值進行get操作；

· 通過row key的range進行scan：即通過設置startRowKey和endRowKey，在這個範圍內進行掃描；

· 全表掃描：即直接掃描整張表中所有行記錄。

在HBase中，row key可以是任意字符串，最大長度64KB，實際應用中一般爲10~100bytes，存爲byte[]字節數組，一般設計成定長的。

row key是按照字典序存儲，因此，設計row key時，要充分利用這個排序特點，將經常一起讀取的數據存儲到一塊，將最近可能會被訪問的數據放在一塊。

舉個例子：如果最近寫入HBase表中的數據是最可能被訪問的，可以考慮將時間戳作爲row key的一部分，由於是字典序排序，所以可以使用Long.MAX_VALUE –timestamp作爲row key，這樣能保證新寫入的數據在讀取時可以被快速命中。

1.3 Column Family

不要在一張表裏定義太多的column family。目前Hbase並不能很好的處理超過2~3個column family的表。因爲某個columnfamily在flush的時候，它鄰近的column family也會因關聯效應被觸發flush，最終導致系統產生更多的I/O。感興趣的同學可以對自己的HBase集羣進行實際測試，從得到的測試結果數據驗證一下。

1.4 In Memory

創建表的時候，可以通過HColumnDescriptor.setInMemory(true)將表放到RegionServer的緩存中，保證在讀取的時候被cache命中。

1.5 Max Version

創建表的時候，可以通過HColumnDescriptor.setMaxVersions(int maxVersions)設置表中數據的最大版本，如果只需要保存最新版本的數據，那麼可以設置setMaxVersions(1)。

1.6 Time To Live

創建表的時候，可以通過HColumnDescriptor.setTimeToLive(inttimeToLive)設置表中數據的存儲生命期，過期數據將自動被刪除，例如如果只需要存儲最近兩天的數據，那麼可以設置 setTimeToLive(2* 24 * 60 * 60)。

1.7 Compact & Split

在HBase中，數據在更新時首先寫入WAL 日誌(HLog)和內存(MemStore)中，MemStore中的數據是排序的，當MemStore累計到一定閾值時，就會創建一個新的 MemStore，並且將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成爲一個StoreFile。於此同時，系統會在zookeeper中記錄一個redo point，表示這個時刻之前的變更已經持久化了(minorcompact)。

StoreFile是隻讀的，一旦創建後就不可以再修改。因此Hbase的更新其實是不斷追加的操作。當一個Store中的StoreFile達到一定的閾值後，就會進行一次合併(majorcompact)，將對同一個key的修改合併到一起，形成一個大的StoreFile，當StoreFile的大小達到一定閾值後，又會對 StoreFile進行分割(split)，等分爲兩個StoreFile。

由於對錶的更新是不斷追加的，處理讀請求時，需要訪問Store中全部的StoreFile和MemStore，將它們按照row key進行合併，由於StoreFile和MemStore都是經過排序的，並且StoreFile帶有內存中索引，通常合併過程還是比較快的。

實際應用中，可以考慮必要時手動進行majorcompact，將同一個row key的修改進行合併形成一個大的StoreFile。同時，可以將StoreFile設置大些，減少split的發生。

2.2 HTable參數設置

2.2.1 Auto Flush

通過調用HTable.setAutoFlush(false)方法可以將HTable寫客戶端的自動flush關閉，這樣可以批量寫入數據到 HBase，而不是有一條put就執行一次更新，只有當put填滿客戶端寫緩存時，才實際向HBase服務端發起寫請求。默認情況下auto flush是開啓的。

2.2.2 Write Buffer

通過調用HTable.setWriteBufferSize(writeBufferSize)方法可以設置HTable客戶端的寫buffer大小，如果新設置的buffer小於當前寫buffer中的數據時，buffer將會被flush到服務端。其中，writeBufferSize的單位是 byte字節數，可以根據實際寫入數據量的多少來設置該值。

2.2.3 WAL Flag

在HBae中，客戶端向集羣中的RegionServer提交數據時（Put/Delete操作），首先會先寫WAL（Write Ahead Log）日誌（即HLog，一個RegionServer上的所有Region共享一個HLog），只有當WAL日誌寫成功後，再接着寫 MemStore，然後客戶端被通知提交數據成功；如果寫WAL日誌失敗，客戶端則被通知提交失敗。這樣做的好處是可以做到RegionServer宕機後的數據恢復。

因此，對於相對不太重要的數據，可以在Put/Delete操作時，通過調用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函數，放棄寫WAL日誌，從而提高數據寫入的性能。

值得注意的是：謹慎選擇關閉WAL日誌，因爲這樣的話，一旦RegionServer宕機，Put/Delete的數據將會無法根據WAL日誌進行恢復。

2.3 批量寫

通過調用HTable.put(Put)方法可以將一個指定的row key記錄寫入HBase，同樣HBase提供了另一個方法：通過調用HTable.put(List<Put>)方法可以將指定的row key列表，批量寫入多行記錄，這樣做的好處是批量執行，只需要一次網絡I/O開銷，這對於對數據實時性要求高，網絡傳輸RTT高的情景下可能帶來明顯的性能提升。

2.4 多線程併發寫

在客戶端開啓多個HTable寫線程，每個寫線程負責一個HTable對象的flush操作，這樣結合定時flush和寫 buffer（writeBufferSize），可以既保證在數據量小的時候，數據可以在較短時間內被flush（如1秒內），同時又保證在數據量大的時候，寫buffer一滿就及時進行flush。下面給個具體的例子：

3.2 HTable參數設置

3.2.1 Scanner Caching

通過調用HTable.setScannerCaching(intscannerCaching)可以設置HBase scanner一次從服務端抓取的數據條數，默認情況下一次一條。通過將此值設置成一個合理的值，可以減少scan過程中next()的時間開銷，代價是 scanner需要通過客戶端的內存來維持這些被cache的行記錄。

3.2.2 Scan AttributeSelection

scan時指定需要的ColumnFamily，可以減少網絡傳輸數據量，否則默認scan操作會返回整行所有Column Family的數據。

3.2.3 Close ResultScanner

通過scan取完數據後，記得要關閉ResultScanner，否則RegionServer可能會出現問題（對應的Server資源無法釋放）。

3.3 批量讀

通過調用HTable.get(Get)方法可以根據一個指定的row key獲取一行記錄，同樣HBase提供了另一個方法：通過調用HTable.get(List)方法可以根據一個指定的row key列表，批量獲取多行記錄，這樣做的好處是批量執行，只需要一次網絡I/O開銷，這對於對數據實時性要求高而且網絡傳輸RTT高的情景下可能帶來明顯的性能提升。

3.4 多線程併發讀

在客戶端開啓多個HTable讀線程，每個讀線程負責通過HTable對象進行get操作。下面是一個多線程併發讀取HBase，獲取店鋪一天內各分鐘PV值的例子：

3.5 緩存查詢結果

對於頻繁查詢HBase的應用場景，可以考慮在應用程序中做緩存，當有新的查詢請求時，首先在緩存中查找，如果存在則直接返回，不再查詢HBase；否則對HBase發起讀請求查詢，然後在應用程序中將查詢結果緩存起來。至於緩存的替換策略，可以考慮LRU等常用的策略。

3.6 Blockcache

HBase上Regionserver的內存分爲兩個部分，一部分作爲Memstore，主要用來寫；另外一部分作爲BlockCache，主要用於讀。

寫請求會先寫入Memstore，Regionserver會給每個region提供一個Memstore，當Memstore滿64MB以後，會啓動 flush刷新到磁盤。當Memstore的總大小超過限制時（heapsize *hbase.regionserver.global.memstore.upperLimit * 0.9），會強行啓動flush進程，從最大的Memstore開始flush直到低於限制。

讀請求先到Memstore中查數據，查不到就到BlockCache中查，再查不到就會到磁盤上讀，並把讀的結果放入BlockCache。由於 BlockCache採用的是LRU策略，因此BlockCache達到上限(heapsize *hfile.block.cache.size * 0.85)後，會啓動淘汰機制，淘汰掉最老的一批數據。

一個Regionserver上有一個BlockCache和N個Memstore，它們的大小之和不能大於等於heapsize *0.8，否則HBase不能啓動。默認BlockCache爲0.2，而Memstore爲0.4。對於注重讀響應時間的系統，可以將 BlockCache設大些，比如設置BlockCache=0.4，Memstore=0.39，以加大緩存的命中率。

有關BlockCache機制，請參考這裏：HBase的Block cache，HBase的blockcache機制，hbase中的緩存的計算與使用。

4.數據計算

4.1 服務端計算

Coprocessor運行於HBaseRegionServer服務端，各個Regions保持對與其相關的coprocessor實現類的引用，coprocessor類可以通過 RegionServer上classpath中的本地jar或HDFS的classloader進行加載。

目前，已提供有幾種coprocessor：

Coprocessor：提供對於region管理的鉤子，例如region的open/close/split/flush/compact等；
RegionObserver：提供用於從客戶端監控表相關操作的鉤子，例如表的get/put/scan/delete等；
Endpoint：提供可以在region上執行任意函數的命令觸發器。一個使用例子是RegionServer端的列聚合，這裏有代碼示例。
以上只是有關coprocessor的一些基本介紹，本人沒有對其實際使用的經驗，對它的可用性和性能數據不得而知。感興趣的同學可以嘗試一下，歡迎討論。

4.2 寫端計算

4.2.1 計數

HBase本身可以看作是一個可以水平擴展的Key-Value存儲系統，但是其本身的計算能力有限（Coprocessor可以提供一定的服務端計算），因此，使用HBase時，往往需要從寫端或者讀端進行計算，然後將最終的計算結果返回給調用者。舉兩個簡單的例子：

PV計算：通過在HBase寫端內存中，累加計數，維護PV值的更新，同時爲了做到持久化，定期（如1秒）將PV計算結果同步到HBase中，這樣查詢端最多會有1秒鐘的延遲，能看到秒級延遲的PV結果。
分鐘PV計算：與上面提到的PV計算方法相結合，每分鐘將當前的累計PV值，按照rowkey + minute作爲新的rowkey寫入HBase中，然後在查詢端通過scan得到當天各個分鐘以前的累計PV值，然後順次將前後兩分鐘的累計PV值相減，就得到了當前一分鐘內的PV值，從而最終也就得到當天各個分鐘內的PV值。

4.2.2 去重

對於UV的計算，就是個去重計算的例子。分兩種情況：

如果內存可以容納，那麼可以在Hash表中維護所有已經存在的UV標識，每當新來一個標識時，通過快速查找Hash確定是否是一個新的UV，若是則UV值加1，否則UV值不變。另外，爲了做到持久化或提供給查詢接口使用，可以定期（如1秒）將UV計算結果同步到HBase中。
如果內存不能容納，可以考慮採用Bloom Filter來實現，從而儘可能的減少內存的佔用情況。除了UV的計算外，判斷URL是否存在也是個典型的應用場景。

4.3 讀端計算

如果對於響應時間要求比較苛刻的情況（如單次http請求要在毫秒級時間內返回），個人覺得讀端不宜做過多複雜的計算邏輯，儘量做到讀端功能單一化：即從 HBaseRegionServer讀到數據（scan或get方式）後，按照數據格式進行簡單的拼接，直接返回給前端使用。當然，如果對於響應時間要求一般，或者業務特點需要，也可以在讀端進行一些計算邏輯。

5.總結

作爲一個Key-Value存儲系統，HBase並不是萬能的，它有自己獨特的地方。因此，基於它來做應用時，我們往往需要從多方面進行優化改進（表設計、讀表操作、寫表操作、數據計算等），有時甚至還需要從系統級對HBase進行配置調優，更甚至可以對HBase本身進行優化。這屬於不同的層次範疇。

總之，概括來講，對系統進行優化時，首先定位到影響你的程序運行性能的瓶頸之處，然後有的放矢進行鍼對行的優化。如果優化後滿足你的期望，那麼就可以停止優化；否則繼續尋找新的瓶頸之處，開始新的優化，直到滿足性能要求。

HBase實現分頁核心代碼

· Scan scan = new Scan();

· scan.setStartRow(getBytes(startRow));

· scan.setStopRow(getBytes(stopRow));

· scan.setCaching(1000);

· scan.setCacheBlocks(false);

· ResultScanner scanner = table.getScanner(scan);

· int i = 0;

· List<byte[]> rowList = new LinkedList<byte[]>();

· // 遍歷掃描器對象，並將需要查詢出來的數據row key取出

· for (Result result : scanner)

· {

· String row = toStr(result.getRow());

· if (i >= firstPage && i < endPage)

· {

· rowList.add(getBytes(row));

· }

· i++;

· }

· // 獲取取出的row key的GET對象

· List<Get> getList = getList(rowList);

· Result[] results = table.get(getList);

· List<Map<String, String>> mapList

· // 遍歷結果

· for (Result result : results)

· {

· Map<byte[], byte[]> fmap = packFamilyMap(result);

· Map<String, String> rmap = packRowMap(fmap);

· mapList.add(rmap);

· }

· List<Get> getList(List<byte[]> rowList)

· {

· List<Get> list = new LinkedList<Get>();

· for (byte[] row : rowList)

· {

· Get get = new Get(row);

· get.addColumn(getBytes("family1"), getBytes("column1"));

· get.addColumn(getBytes("family1"), getBytes("column2"));

· get.addColumn(getBytes("family2"), getBytes("column1"));

· list.add(get);

· }

· return list;

· }

· Map<byte[], byte[]> packFamilyMap(Result result)

· {

· Map<byte[], byte[]> dataMap = null;

· dataMap = new LinkedHashMap<byte[], byte[]>();

· dataMap.putAll(result.getFamilyMap(getBytes("family1")));

· dataMap.putAll(result.getFamilyMap(getBytes("family2")));

· return dataMap;

· }

· Map<byte[], byte[]> packFamilyMap(Result result)

· {

· Map<byte[], byte[]> dataMap = null;

· dataMap = new LinkedHashMap<byte[], byte[]>();

· dataMap.putAll(result.getFamilyMap(getBytes("family1")));

· dataMap.putAll(result.getFamilyMap(getBytes("family2")));

· return dataMap;

· }

在配置hadoop HA的時候,遇到了一個常見的問題,但網上的解說各樣情況卻都不能解決我的這個問題。困擾了我一個上午。現在把解決辦法share出來跟大家一起分享:

問題：

我在向配好的HADOOP的hdfs上傳文件時，出錯了:

[user01@ocdc41 hadoop-2.0.0-cdh4.2.1]$ hadoop fs -putzookeeper.out /surq

14/05/06 10:25:36 WARN util.NativeCodeLoader: Unable toload native-hadoop library for your platform... using builtin-java classeswhere applicable

14/05/06 10:25:38 INFO hdfs.DFSClient: Exception increateBlockOutputStream

java.io.EOFException: Premature EOF: no length prefixavailable

atorg.apache.hadoop.hdfs.protocol.HdfsProtoUtil.vintPrefixed(HdfsProtoUtil.java:171)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.createBlockOutputStream(DFSOutputStream.java:1105)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1039)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:487)

14/05/06 10:25:38 INFO hdfs.DFSClient: AbandoningBP-622801129-10.1.251.41-1399285006530:blk_4261023822429760593_1050

14/05/06 10:25:38 INFO hdfs.DFSClient: Excluding datanode10.1.251.41:50011

14/05/06 10:25:38 INFO hdfs.DFSClient: Exception increateBlockOutputStream

java.io.EOFException: Premature EOF: no length prefixavailable

atorg.apache.hadoop.hdfs.protocol.HdfsProtoUtil.vintPrefixed(HdfsProtoUtil.java:171)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.createBlockOutputStream(DFSOutputStream.java:1105)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1039)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:487)

14/05/06 10:25:38 INFO hdfs.DFSClient: AbandoningBP-622801129-10.1.251.41-1399285006530:blk_-7023175867132719132_1051

14/05/06 10:25:38 INFO hdfs.DFSClient: Excluding datanode10.1.251.46:50011

14/05/06 10:25:38 INFO hdfs.DFSClient: Exception increateBlockOutputStream

java.io.EOFException: Premature EOF: no length prefixavailable

atorg.apache.hadoop.hdfs.protocol.HdfsProtoUtil.vintPrefixed(HdfsProtoUtil.java:171)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.createBlockOutputStream(DFSOutputStream.java:1105)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1039)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:487)

14/05/06 10:25:38 INFO hdfs.DFSClient: AbandoningBP-622801129-10.1.251.41-1399285006530:blk_318554080720123545_1052

14/05/06 10:25:38 INFO hdfs.DFSClient: Excluding datanode10.1.251.45:50011

14/05/06 10:25:38 WARN hdfs.DFSClient: DataStreamerException

org.apache.hadoop.ipc.RemoteException(java.io.IOException):File /surq/zookeeper.out._COPYING_ could only be replicated to 0 nodes insteadof minReplication (=1). There are 3 datanode(s) running and 3 node(s) areexcluded in this operation.

atorg.apache.hadoop.hdfs.server.blockmanagement.BlockManager.chooseTarget(BlockManager.java:1327)

atorg.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock(FSNamesystem.java:2278)

atorg.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.addBlock(NameNodeRpcServer.java:480)

at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.addBlock(ClientNamenodeProtocolServerSideTranslatorPB.java:297)

atorg.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java:44080)

atorg.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:453)

atorg.apache.hadoop.ipc.RPC$Server.call(RPC.java:1002)

at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1695)

atorg.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1691)

atjava.security.AccessController.doPrivileged(Native Method)

atjavax.security.auth.Subject.doAs(Subject.java:415)

at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1408)

atorg.apache.hadoop.ipc.Server$Handler.run(Server.java:1689)

atorg.apache.hadoop.ipc.Client.call(Client.java:1225)

atorg.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:202)

atcom.sun.proxy.$Proxy9.addBlock(Unknown Source)

atorg.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.addBlock(ClientNamenodeProtocolTranslatorPB.java:290)

atsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

atjava.lang.reflect.Method.invoke(Method.java:606)

atorg.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:164)

atorg.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:83)

atcom.sun.proxy.$Proxy10.addBlock(Unknown Source)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.locateFollowingBlock(DFSOutputStream.java:1176)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1029)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:487)

put: File /surq/zookeeper.out._COPYING_ could only bereplicated to 0 nodes instead of minReplication (=1). There are 3datanode(s) running and 3 node(s) are excluded in this operation.

14/05/06 10:25:38 ERROR hdfs.DFSClient: Failed to closefile /surq/zookeeper.out._COPYING_

atorg.apache.hadoop.hdfs.server.blockmanagement.BlockManager.chooseTarget(BlockManager.java:1327)

at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock(FSNamesystem.java:2278)

atorg.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.addBlock(NameNodeRpcServer.java:480)

atorg.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.addBlock(ClientNamenodeProtocolServerSideTranslatorPB.java:297)

atorg.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java:44080)

atorg.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:453)

atorg.apache.hadoop.ipc.RPC$Server.call(RPC.java:1002)

atorg.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1695)

at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1691)

atjava.security.AccessController.doPrivileged(Native Method)

atjavax.security.auth.Subject.doAs(Subject.java:415)

atorg.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1408)

atorg.apache.hadoop.ipc.Server$Handler.run(Server.java:1689)

atorg.apache.hadoop.ipc.Client.call(Client.java:1225)

atorg.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:202)

atcom.sun.proxy.$Proxy9.addBlock(Unknown Source)

atorg.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.addBlock(ClientNamenodeProtocolTranslatorPB.java:290)

atsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

atjava.lang.reflect.Method.invoke(Method.java:606)

atorg.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:164)

atorg.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:83)

atcom.sun.proxy.$Proxy10.addBlock(Unknown Source)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.locateFollowingBlock(DFSOutputStream.java:1176)

atorg.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1029)

at org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:487)

解決辦法: 關於 INFOorg.apache.hadoop.hdfs.DFSClient: Exception in createBlockOutputStreamjava.io.EOFException: Premature EOF: no length prefix available 由於DataNode終止了block的傳輸，所以client會出現這種錯誤，導致client無法正常數據讀寫. 從Excluding datanode 10.1.251.41:50011入手問題分析：個人認爲:namenode和datanade通信用到的全是ip:port,而在配置中的dfs.datanode.address=localhost:50011,local對應的是127.0.0.1本機之外是無法訪問的故要把local改爲datanode的IP才行，以因爲是集羣把每臺datanode的datanode.address改爲自已的IP不現實，因此需要修改./etc/hosts文件。 1、修改/etc/hosts 修改各datanode的hosts,定義一個統一的名hostip 127.0.0.1 localhost10.1.251.41 ocdc41 hostip 2、修改hdfs-site.xml文件: dfs.datanode.address=localhost:50011改爲hostip:500113、重啓datanode一切，再向HDFS傳文件成功。

hbase 實時系統HBase讀寫優化--大量寫入無障礙在使用hbase過程中發現在寫入hbase的數據量很大

實時系統HBase讀寫優化--大量寫入無障礙

　　在使用hbase過程中發現在寫入hbase的數據量很大時，經常發生寫不進去的情況。而我們基於hbase的應用是對實時性要求很高的，一旦hbase不能讀寫則會大大影響系統的使用。下面將記錄hbase寫優化的過程。

　　1.禁止Major Compaction

　　在hbase進行Major Compaction時，該region將合併所有的storefile，因此整個region都不可讀，所有對此region的查詢都會block。 HBase默認一天左右執行一次Major Compaction。我們將Major Compaction禁掉並用Cron腳本每天在系統空閒時對所有表執行major compaction。

　　Major Compaction的配置：

<property><name>hbase.hregion.majorcompaction</name><value>0</value> </property>

　　默認是1天，每個region會在創建時以當前時間初始化regionMajorCompactionTime，並將下一次的major compaction時間設爲1+-0.2天。配置中將此值設爲0禁止majorcompaction。

　　major_compaction的腳本：取出所有table，一一執行major_compact：

2.禁掉split

　　hbase通過split region實現水平的sharding，但在split的過程中舊的region會下線，新region還會做compaction，中間有一段時間大量的數據不能被讀寫，這對於我們這種online系統是不能忍受的。我們同樣禁掉自動的split，而在晚上系統空閒時執行我們的splittool手動的split。

　　禁止split的配置：

<property> <name>hbase.hregion.max.filesize</name><value>536870912000</value> </property>

配置項的含義是當region的大小大於設定值後hbase就會開始split，我們將此值設爲500G，我們認爲在白天系統繁忙時一個region不會超過此大小，在晚上時運行splittool將region分割開。

　　splittool的邏輯比較簡單。遍歷所有region的信息，如果region大小大於某值（比如1G）則split該region，這樣爲一輪split，如果一輪後沒有大於某值的region則結束，如果還有大於某個值的region則繼續新一輪split，直到沒有region大於某個閾值爲止。這裏提一下判斷split完成的方法：通過檢查hdfs上舊region的文件夾是否被清除來判斷split是否結束。

　　3.設置blockingStoreFiles

　　這個參數的重要性是在我們的性能測試中發現的。我們禁掉major_compaction和split後理論上寫入應該無障礙了，但在測試中發現寫入單個region速度大於10M/s時還是會出現長時間無法寫入的情況。通過查看log，我們發現了這行log“Waited 90314ms on acompaction to clean up 'too many store files'”，通過查看代碼發現原來是blockingStoreFiles這個參數在作怪。

　　在flushRegion時會檢測當前store中hfile的數量是否大於此值，如果大於則會block數據的寫入，等待其他線程將hfile compact掉。這樣，如果寫入速度超過compact的速度，hbase就會阻止該region的數據寫入。

　　private boolean flushRegion(final FlushRegionEntry fqe) { HRegionregion = fqe.region; if (!fqe.region.getRegionInfo().isMetaRegion() &&isTooManyStoreFiles(region)) { if (fqe.isMaximumWait(this.blockingWaitTime)) {LOG.info("Waited " + (System.currentTimeMillis() - fqe.createTime) +"ms on a compaction to clean up 'too many store files'; waited " +"long enough... proceeding with flush of " + region.getRegionNameAsString());}

默認值爲7

　　this.blockingStoreFilesNumber =conf.getInt("hbase.hstore.blockingStoreFiles", 7); if(this.blockingStoreFilesNumber == -1) { this.blockingStoreFilesNumber = 1 +conf.getInt("hbaspactionThreshold", 3); }

我們將此值設爲很大的值，使得此問題不會block我們的寫入。

<property> <name>hbase.hstore.blockingStoreFiles</name><value>2100000000</value> </property>

1.禁止Major Compaction

在hbase進行Major Compaction時，該region將合併所有的storefile，因此整個region都不可讀，所有對此region的查詢都會block。HBase默認一天左右執行一次Major Compaction。我們將Major Compaction禁掉並用Cron腳本每天在系統空閒時對所有表執行major compaction。

Major Compaction的配置：

[html] viewplain copy

<property>
<name>hbase.hregion.majorcompaction</name>
<value>0</value>
</property>

major_compaction的腳本：取出所有table，一一執行major_compact：

[java] viewplain copy

TMP_FILE=tmp_tables
TABLES_FILE=tables.txt
echo "list" | hbase shell > tmp_tables
sleep 2
sed '1,6d' $TMP_FILE | tac | sed '1,2d' | tac > $TABLES_FILE
sleep 2
for table in $(cat $TABLES_FILE); do
echo "major_compact '$table'" | hbase shell
sleep 10
done

2.禁掉split

禁止split的配置：

[html] viewplain copy

<property>
<name>hbase.hregion.max.filesize</name>
<value>536870912000</value>
</property>

splittool的邏輯比較簡單。遍歷所有region的信息，如果region大小大於某值（比如1G）則split該region，這樣爲一輪split，如果一輪後沒有大於某值的region則結束，如果還有大於某個值的 region則繼續新一輪split，直到沒有region大於某個閾值爲止。這裏提一下判斷split完成的方法：通過檢查hdfs上舊region的文件夾是否被清除來判斷split是否結束。

3.設置blockingStoreFiles

這個參數的重要性是在我們的性能測試中發現的。我們禁掉major_compaction和split後理論上寫入應該無障礙了，但在測試中發現寫入單個region速度大於10M/s時還是會出現長時間無法寫入的情況。通過查看log，我們發現了這行log“Waited 90314ms on a compaction to cleanup 'too many store files'”，通過查看代碼發現原來是blockingStoreFiles這個參數在作怪。

[java] viewplain copy

private boolean flushRegion(final FlushRegionEntry fqe) {
HRegion region = fqe.region;
if (!fqe.region.getRegionInfo().isMetaRegion() &&
isTooManyStoreFiles(region)) {
if (fqe.isMaximumWait(this.blockingWaitTime)) {
LOG.info("Waited " + (System.currentTimeMillis() - fqe.createTime) +
"ms on a compaction to clean up 'too many store files'; waited " +
"long enough... proceeding with flush of " +
region.getRegionNameAsString());
}

默認值爲7

[java] viewplain copy

this.blockingStoreFilesNumber =
conf.getInt("hbase.hstore.blockingStoreFiles", 7);
if (this.blockingStoreFilesNumber == -1) {
this.blockingStoreFilesNumber = 1 +
conf.getInt("hbase.hstore.compactionThreshold", 3);
}

我們將此值設爲很大的值，使得此問題不會block我們的寫入。

[html] viewplain copy

<property>
<name>hbase.hstore.blockingStoreFiles</name>
<value>2100000000</value>
</property>

版本信息： hadoop 2.3.0 hive 0.11.0

1. Application Master 無法訪問

點擊application mater 鏈接，出現 http 500 錯誤，java.lang.Connect.exception：問題是由於設定web ui時，50030 端口對應的ip地址爲0.0.0.0，導致applicationmaster 鏈接無法定位。
解決辦法: yarn-site.xml 文件 <property> <description>The address of the RM webapplication.</description><name>yarn.resourcemanager.webapp.address</name> <value>xxxxxxxxxx:50030</value></property> 這是2.3.0 的裏面的一個bug 1811 ，2.4.0已經修復

2. History UI 無法訪問和 container 打不開

點擊 TrackingURL:History無法訪問問題是 history service 沒有啓動解決辦法: 配置：選擇（xxxxxxxxxx: 作爲historysever） <property><name>yarn.log-aggregation-enable</name><value>true</value> </property> <property><name>mapreduce.jobhistory.address</name><value>xxxxxxxxxx::10020</value> </property>
<property> <name>mapreduce.jobhistory.webapp.address</name><value>xxxxxxxxxx:19888</value> </property>
sbin/mr-jobhistory-daemon.sh starthistoryserver 相關鏈接:http://www.iteblog.com/archives/936

3 yarn 平臺的優化設置虛擬cpu的個數

<property><name>yarn.nodemanager.resource.cpu-vcores</name><value>23</value> </property> 設置使用的內存<property> <name>yarn.nodemanager.resource.memory-mb</name><value>61440</value> <description>the amount of memory on theNodeManager in GB</description> </property> 設置每個任務最大使用的內存<property> <name>yarn.scheduler.maximum-allocation-mb</name><value>49152</value> <source>yarn-default.xml</source></property>

4 運行任務提示： Foundinterface org.apache.hadoop.mapreduce.Counter, but class was expected

修改pom，重新install <dependency><groupId>org.apache.hadoop</groupId><artifactId>hadoop-common</artifactId><version>2.3.0</version> </dependency> <dependency><groupId>org.apache.hadoop</groupId> <artifactId>hadoop-mapreduce-client-core</artifactId><version>2.3.0</version> </dependency> <dependency><groupId>org.apache.mrunit</groupId><artifactId>mrunit</artifactId><version>1.0.0</version> <classifier>hadoop2</classifier><scope>test</scope> </dependency> jdk 換成1.7

5 運行任務提示shuffle內存溢出

Java heap space 2014-05-14 16:44:22,010FATAL [IPC Server handler 4 on 44508]org.apache.hadoop.mapred.TaskAttemptListenerImpl: Task:attempt_1400048775904_0006_r_000004_0 - exited :org.apache.hadoop.mapreduce.task.reduce.Shuffle$ShuffleError: error in shufflein fetcher#3 atorg.apache.hadoop.mapreduce.task.reduce.Shuffle.run(Shuffle.java:134) atorg.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:376) atorg.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:168) atjava.security.AccessController.doPrivileged(Native Method) atjavax.security.auth.Subject.doAs(Subject.java:415) atorg.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1548)at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:163) Caused by:java.lang.OutOfMemoryError: Java heap space atorg.apache.hadoop.io.BoundedByteArrayOutputStream.<init>(BoundedByteArrayOutputStream.java:56)atorg.apache.hadoop.io.BoundedByteArrayOutputStream.<init>(BoundedByteArrayOutputStream.java:46)at org.apache.hadoop.mapreduce.task.reduce.InMemoryMapOutput.<init>(InMemoryMapOutput.java:63)atorg.apache.hadoop.mapreduce.task.reduce.MergeManagerImpl.unconditionalReserve(MergeManagerImpl.java:297)atorg.apache.hadoop.mapreduce.task.reduce.MergeManagerImpl.reserve(MergeManagerImpl.java:287)atorg.apache.hadoop.mapreduce.task.reduce.Fetcher.copyMapOutput(Fetcher.java:411)atorg.apache.hadoop.mapreduce.task.reduce.Fetcher.copyFromHost(Fetcher.java:341)at org.apache.hadoop.mapreduce.task.reduce.Fetcher.run(Fetcher.java:165)
來源： <http:/xxxxxxxxxx:19888/jobhistory/logs/ST-L09-05-back-tj-yarn15:8034/container_1400048775904_0006_01_000001/job_1400048775904_0006/hadoop/syslog/?start=0>
解決方法：調低mapreduce.reduce.shuffle.memory.limit.percent的值默認爲0.25 現在調成0.10

參考： http://www.sqlparty.com/yarn%E5%9C%A8shuffle%E9%98%B6%E6%AE%B5%E5%86%85%E5%AD%98%E4%B8%8D%E8%B6%B3%E9%97%AE%E9%A2%98error-in-shuffle-in-fetcher/

6 reduce 任務的log 中間發現：

2014-05-14 17:51:21,835 WARN [Readahead Thread #2]org.apache.hadoop.io.ReadaheadPool: Failed readahead on ifile EINVAL: Invalidargument at org.apache.hadoop.io.nativeio.NativeIO$POSIX.posix_fadvise(NativeMethod) atorg.apache.hadoop.io.nativeio.NativeIO$POSIX.posixFadviseIfPossible(NativeIO.java:263)at org.apache.hadoop.io.nativeio.NativeIO$POSIX$CacheManipulator.posixFadviseIfPossible(NativeIO.java:142)atorg.apache.hadoop.io.ReadaheadPool$ReadaheadRequestImpl.run(ReadaheadPool.java:206)atjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)at java.lang.Thread.run(Thread.java:745)
來源：<http://xxxxxxxxxx:8042/node/containerlogs/container_1400060792764_0001_01_000726/hadoop/syslog/?start=-4096> ps：錯誤沒有再現，暫無解決方法

7 hive 任務

java.lang.InstantiationException: org.antlr.runtime.CommonToken Continuing ...java.lang.RuntimeException: failed to evaluate: <unbound>=Class.new(); 參考:https://issues.apache.org/jira/browse/HIVE-4222s

8 hive 任務自動把join裝換mapjoin時內存溢出，

解決方法：關閉自動裝換，11前的版本默認值爲false，後面的爲true; 在任務腳本里面加上：set hive.auto.convert.join=false; 或者在hive-site.xml 配上爲false；出錯日誌： SLF4J:Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] 2014-05-1502:40:58 Starting to launch local task to process map join; maximum memory =1011351552 2014-05-15 02:41:00 Processing rows: 200000 Hashtable size: 199999Memory usage: 110092544 rate: 0.109 2014-05-15 02:41:01 Processing rows: 300000Hashtable size: 299999 Memory usage: 229345424 rate: 0.227 2014-05-15 02:41:01Processing rows: 400000 Hashtable size: 399999 Memory usage: 170296368 rate:0.168 2014-05-15 02:41:01 Processing rows: 500000 Hashtable size: 499999 Memoryusage: 285961568 rate: 0.283 2014-05-15 02:41:02 Processing rows: 600000Hashtable size: 599999 Memory usage: 408727616 rate: 0.404 2014-05-15 02:41:02Processing rows: 700000 Hashtable size: 699999 Memory usage: 333867920 rate:0.33 2014-05-15 02:41:02 Processing rows: 800000 Hashtable size: 799999 Memoryusage: 459541208 rate: 0.454 2014-05-15 02:41:03 Processing rows: 900000Hashtable size: 899999 Memory usage: 391524456 rate: 0.387 2014-05-15 02:41:03Processing rows: 1000000 Hashtable size: 999999 Memory usage: 514140152 rate:0.508 2014-05-15 02:41:03 Processing rows: 1029052 Hashtable size: 1029052Memory usage: 546126888 rate: 0.54 2014-05-15 02:41:03 Dump the hashtable intofile:file:/tmp/hadoop/hive_2014-05-15_14-40-53_413_3806680380261480764/-local-10002/HashTable-Stage-4/MapJoin-mapfile01--.hashtable2014-05-15 02:41:06 Upload 1 File to:file:/tmp/hadoop/hive_2014-05-15_14-40-53_413_3806680380261480764/-local-10002/HashTable-Stage-4/MapJoin-mapfile01--.hashtableFile size: 68300588 2014-05-15 02:41:06 End of local task; Time Taken: 8.301sec. Execution completed successfully Mapred Local Task Succeeded . Convert theJoin into MapJoin Mapred Local Task Succeeded . Convert the Join into MapJoinLaunching Job 2 out of 2
log出錯日誌： 2014-05-15 13:52:54,007 FATAL [main]org.apache.hadoop.mapred.YarnChild: Error running child :java.lang.OutOfMemoryError: Java heap space atjava.io.ObjectInputStream$HandleTable.grow(ObjectInputStream.java:3465) atjava.io.ObjectInputStream$HandleTable.assign(ObjectInputStream.java:3271) atjava.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1789) atjava.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)at java.util.HashMap.readObject(HashMap.java:1183) atsun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:606) atjava.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017) atjava.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893) atjava.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798) atjava.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) atjava.io.ObjectInputStream.readObject(ObjectInputStream.java:370) at org.apache.hadoop.hive.ql.exec.persistence.HashMapWrapper.initilizePersistentHash(HashMapWrapper.java:128)atorg.apache.hadoop.hive.ql.exec.MapJoinOperator.loadHashTable(MapJoinOperator.java:194)at org.apache.hadoop.hive.ql.exec.MapJoinOperator.cleanUpInputFileChangedOp(MapJoinOperator.java:212)atorg.apache.hadoop.hive.ql.exec.Operator.cleanUpInputFileChanged(Operator.java:1377)atorg.apache.hadoop.hive.ql.exec.Operator.cleanUpInputFileChanged(Operator.java:1381)
來源：<http://xxxxxxxxxx:19888/jobhistory/logs/ST-L09-10-back-tj-yarn21:8034/container_1400064445468_0013_01_000002/attempt_1400064445468_0013_m_000000_0/hadoop/syslog/?start=0>

9 hive運行時提示： failed to evaluate: <unbound>=Class.new();

，升級到0.13.0 參考https://issues.apache.org/jira/browse/HIVE-4222 https://issues.apache.org/jira/browse/HIVE-3739SLF4J: Seehttp://www.slf4j.org/codes.html#multiple_bindings for an explanation.SLF4J:Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]OKTime taken: 2.28secondsjava.lang.InstantiationException: org.antlr.runtime.CommonTokenContinuing...java.lang.RuntimeException: failed to evaluate:<unbound>=Class.new();Continuing ...java.lang.InstantiationException:org.antlr.runtime.CommonTokenContinuing ...java.lang.RuntimeException: failedto evaluate: <unbound>=Class.new();Continuing...java.lang.InstantiationException: org.antlr.runtime.CommonTokenContinuing...java.lang.RuntimeException: failed to evaluate:<unbound>=Class.new();Continuing ...java.lang.InstantiationException:org.antlr.runtime.CommonTokenContinuing ...java.lang.RuntimeException: failedto evaluate: <unbound>=Class.new();Continuing...java.lang.InstantiationException: org.antlr.runtime.CommonTokenContinuing...
這個應該升級後能解決，不過不知道爲什麼我升級12.0 和13.0 ，一運行就報錯fileNotfundHIVE_PLANxxxxxxxxx 。ps （參考11）應該是我配置有問題，暫無解決方法。

10 hive 創建表或者數據庫的時候 Couldnt obtain a new sequence (unique id) : You have an error inyour SQL syntax

解決方法：這個是因爲hive元數據庫的名字是yarn-hive,sql中中劃線是關鍵詞，所以sql錯誤。把數據庫名去掉中劃線，問題解決。錯誤日誌： FAILED: Error in metadata: MetaException(message:javax.jdo.JDOException:Couldnt obtain a new sequence (unique id) : You have an error in your SQLsyntax; check the manual that corresponds to your MySQL server version for theright syntax to use near '-hive.`SEQUENCE_TABLE` WHERE`SEQUENCE_NAME`='org.apache.hadoop.hive.metastore.m' at line 1 atorg.datanucleus.api.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:596)atorg.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:732)at org.datanucleus.api.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:752)atorg.apache.hadoop.hive.metastore.ObjectStore.createTable(ObjectStore.java:643)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:606) atorg.apache.hadoop.hive.metastore.RetryingRawStore.invoke(RetryingRawStore.java:111)at com.sun.proxy.$Proxy14.createTable(Unknown Source) atorg.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.create_table_core(HiveMetaStore.java:1070)atorg.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.create_table_with_environment_context(HiveMetaStore.java:1103)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:606) atorg.apache.hadoop.hive.metastore.RetryingHMSHandler.invoke(RetryingHMSHandler.java:103)at com.sun.proxy.$Proxy15.create_table_with_environment_context(Unknown Source)at org.apache.hadoop.hive.metastore.HiveMetaStoreClient.createTable(HiveMetaStoreClient.java:466)atorg.apache.hadoop.hive.metastore.HiveMetaStoreClient.createTable(HiveMetaStoreClient.java:455)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:606) atorg.apache.hadoop.hive.metastore.RetryingMetaStoreClient.invoke(RetryingMetaStoreClient.java:74)at com.sun.proxy.$Proxy16.createTable(Unknown Source) atorg.apache.hadoop.hive.ql.metadata.Hive.createTable(Hive.java:597) atorg.apache.hadoop.hive.ql.exec.DDLTask.createTable(DDLTask.java:3777) at org.apache.hadoop.hive.ql.exec.DDLTask.execute(DDLTask.java:256)at org.apache.hadoop.hive.ql.exec.Task.executeTask(Task.java:144) atorg.apache.hadoop.hive.ql.exec.TaskRunner.runSequential(TaskRunner.java:57) atorg.apache.hadoop.hive.ql.Driver.launchTask(Driver.java:1362) atorg.apache.hadoop.hive.ql.Driver.execute(Driver.java:1146) atorg.apache.hadoop.hive.ql.Driver.run(Driver.java:952) atshark.SharkCliDriver.processCmd(SharkCliDriver.scala:338) atorg.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:413) atshark.SharkCliDriver$.main(SharkCliDriver.scala:235) atshark.SharkCliDriver.main(SharkCliDriver.scala) NestedThrowablesStackTrace:com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error inyour SQL syntax; check the manual that corresponds to your MySQL server versionfor the right syntax to use near '-hive.`SEQUENCE_TABLE` WHERE`SEQUENCE_NAME`='org.apache.hadoop.hive.metastore.m' at line 1 atsun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)atsun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)at java.lang.reflect.Constructor.newInstance(Constructor.java:526) atcom.mysql.jdbc.Util.handleNewInstance(Util.java:406) atcom.mysql.jdbc.Util.getInstance(Util.java:381) atcom.mysql.jdbc.SQLError.createSQLException(SQLError.java:1030) atcom.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3558)at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3490) atcom.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959) atcom.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2109) atcom.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2648) atcom.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2077)at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2228)at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)atorg.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)atorg.datanucleus.store.rdbms.ParamLoggingPreparedStatement.executeQuery(ParamLoggingPreparedStatement.java:381)atorg.datanucleus.store.rdbms.SQLController.executeStatementQuery(SQLController.java:504)atorg.datanucleus.store.rdbms.valuegenerator.SequenceTable.getNextVal(SequenceTable.java:197)at org.datanucleus.store.rdbms.valuegenerator.TableGenerator.reserveBlock(TableGenerator.java:190)atorg.datanucleus.store.valuegenerator.AbstractGenerator.reserveBlock(AbstractGenerator.java:305)atorg.datanucleus.store.rdbms.valuegenerator.AbstractRDBMSGenerator.obtainGenerationBlock(AbstractRDBMSGenerator.java:170)atorg.datanucleus.store.valuegenerator.AbstractGenerator.obtainGenerationBlock(AbstractGenerator.java:197)atorg.datanucleus.store.valuegenerator.AbstractGenerator.next(AbstractGenerator.java:105)at org.datanucleus.store.rdbms.RDBMSStoreManager.getStrategyValueForGenerator(RDBMSStoreManager.java:2019)atorg.datanucleus.store.AbstractStoreManager.getStrategyValue(AbstractStoreManager.java:1385)atorg.datanucleus.ExecutionContextImpl.newObjectId(ExecutionContextImpl.java:3727)at org.datanucleus.state.JDOStateManager.setIdentity(JDOStateManager.java:2574)atorg.datanucleus.state.JDOStateManager.initialiseForPersistentNew(JDOStateManager.java:526)atorg.datanucleus.state.ObjectProviderFactoryImpl.newForPersistentNew(ObjectProviderFactoryImpl.java:202)atorg.datanucleus.ExecutionContextImpl.newObjectProviderForPersistentNew(ExecutionContextImpl.java:1326)atorg.datanucleus.ExecutionContextImpl.persistObjectInternal(ExecutionContextImpl.java:2123)at org.datanucleus.ExecutionContextImpl.persistObjectWork(ExecutionContextImpl.java:1972)atorg.datanucleus.ExecutionContextImpl.persistObject(ExecutionContextImpl.java:1820)atorg.datanucleus.ExecutionContextThreadedImpl.persistObject(ExecutionContextThreadedImpl.java:217)at org.datanucleus.api.jdo.JDOPersistenceManager.jdoMakePersistent(JDOPersistenceManager.java:727)atorg.datanucleus.api.jdo.JDOPersistenceManager.makePersistent(JDOPersistenceManager.java:752)atorg.apache.hadoop.hive.metastore.ObjectStore.createTable(ObjectStore.java:643)

11 安裝hive 12 和13 後，運行任務報錯提示：FileNotFoundException: HIVE_PLAN 解決方法：可能是hive一個bug，也可能那裏配置錯了，待解決
錯誤日誌

2014-05-16 10:27:07,896 INFO [main] org.apache.hadoop.mapred.MapTask:Processing split:Paths:/user/hive/warehouse/game_predata.db/game_login_log/dt=0000-00-00/000000_0:201326592+60792998,/user/hive/warehouse/game_predata.db/game_login_log/dt=0000-00-00/000001_0_copy_1:201326592+58503492,/user/hive/warehouse/game_predata.db/game_login_log/dt=0000-00-00/000001_0_copy_2:67108864+67108864,/user/hive/warehouse/game_predata.db/game_login_log/dt=0000-00-00/000001_0_copy_2:134217728+67108864,/user/hive/warehouse/game_predata.db/game_login_log/dt=0000-00-00/000002_0_copy_1:67108864+67108864InputFormatClass:org.apache.hadoop.mapred.TextInputFormat 2014-05-16 10:27:07,954 WARN [main]org.apache.hadoop.mapred.YarnChild: Exception running child :java.lang.RuntimeException: java.io.FileNotFoundException:HIVE_PLAN14c8af69-0156-4633-9273-6a812eb91a4c (沒有那個文件或目錄) atorg.apache.hadoop.hive.ql.exec.Utilities.getMapRedWork(Utilities.java:230) atorg.apache.hadoop.hive.ql.io.HiveInputFormat.init(HiveInputFormat.java:255) atorg.apache.hadoop.hive.ql.io.HiveInputFormat.pushProjectionsAndFilters(HiveInputFormat.java:381)at org.apache.hadoop.hive.ql.io.HiveInputFormat.pushProjectionsAndFilters(HiveInputFormat.java:374)atorg.apache.hadoop.hive.ql.io.CombineHiveInputFormat.getRecordReader(CombineHiveInputFormat.java:540)atorg.apache.hadoop.mapred.MapTask$TrackedRecordReader.<init>(MapTask.java:168)at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:409) atorg.apache.hadoop.mapred.MapTask.run(MapTask.java:342) atorg.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:168) atjava.security.AccessController.doPrivileged(Native Method) atjavax.security.auth.Subject.doAs(Subject.java:415) atorg.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1548)at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:163) Caused by:java.io.FileNotFoundException: HIVE_PLAN14c8af69-0156-4633-9273-6a812eb91a4c (沒有那個文件或目錄) atjava.io.FileInputStream.open(Native Method) atjava.io.FileInputStream.<init>(FileInputStream.java:146) atjava.io.FileInputStream.<init>(FileInputStream.java:101) atorg.apache.hadoop.hive.ql.exec.Utilities.getMapRedWork(Utilities.java:221) ...12 more 2014-05-16 10:27:07,957 INFO [main] org.apache.hadoop.mapred.Task:Runnning cleanup for the task
來源：<http://sxxxxxxxxxx:19888/jobhistory/logs/ST-L10-10-back-tj-yarn10:8034/container_1400136017046_0026_01_000030/attempt_1400136017046_0026_m_000000_0/hadoop>

12java.lang.OutOfMemoryError: GC overhead limit exceeded

13hive hive 0.10.0爲了執行效率考慮，簡單的查詢

就是隻是select，不帶count,sum,group by這樣的，都不走map/reduce，直接讀取hdfs文件進行filter過濾。這樣做的好處就是不新開mr任務，執行效率要提高不少，但是不好的地方就是用戶界面不友好，有時候數據量大還是要等很長時間，但是又沒有任何返回。

改這個很簡單，在hive-site.xml裏面有個配置參數叫

hive.fetch.task.conversion

將這個參數設置爲more，簡單查詢就不走map/reduce了，設置爲minimal，就任何簡單select都會走map/reduce。

來源：<http://slaytanic.blog.51cto.com/2057708/1170431> 參考14

14 運行mr 任務的時候提示：

錯誤日誌

Container [pid=30486,containerID=container_1400229396615_0011_01_000012] is running beyond physical memory limits. Current usage: 1.0 GB of 1 GB physical memory used; 1.7 GB of 2.1 GB virtual memory used. Killing container. Dump of the process-tree for container_1400229396615_0011_01_000012 : |- PID PPID PGRPID SESSID CMD_NAME USER_MODE_TIME(MILLIS) SYSTEM_TIME(MILLIS) VMEM_USAGE(BYTES) RSSMEM_USAGE(PAGES) FULL_CMD_LINE |- 30501 30486 30486 30486 (java) 3924 322 1720471552 262096 /opt/jdk1.7.0_55/bin/java -Djava.net.preferIPv4Stack=true -Dhadoop.metrics.log.level=WARN -Xmx1024m -XX:-UseGCOverheadLimit -Djava.io.tmpdir=/home/nodemanager/local/usercache/hadoop/appcache/application_1400229396615_0011/container_1400229396615_0011_01_000012/tmp -Dlog4j.configuration=container-log4j.properties -Dyarn.app.container.log.dir=/home/hadoop/logs/nodemanager/logs/application_1400229396615_0011/container_1400229396615_0011_01_000012 -Dyarn.app.container.log.filesize=0 -Dhadoop.root.logger=INFO,CLA org.apache.hadoop.mapred.YarnChild 30.30.30.39 47925 attempt_1400229396615_0011_m_000000_0 12 |- 30486 12812 30486 30486 (bash) 0 0 108642304 302 /bin/bash -c /opt/jdk1.7.0_55/bin/java -Djava.net.preferIPv4Stack=true -Dhadoop.metrics.log.level=WARN -Xmx1024m -XX:-UseGCOverheadLimit -Djava.io.tmpdir=/home/nodemanager/local/usercache/hadoop/appcache/application_1400229396615_0011/container_1400229396615_0011_01_000012/tmp -Dlog4j.configuration=container-log4j.properties -Dyarn.app.container.log.dir=/home/hadoop/logs/nodemanager/logs/application_1400229396615_0011/container_1400229396615_0011_01_000012 -Dyarn.app.container.log.filesize=0 -Dhadoop.root.logger=INFO,CLA org.apache.hadoop.mapred.YarnChild 30.30.30.39 47925 attempt_1400229396615_0011_m_000000_0 12 1>/home/hadoop/logs/nodemanager/logs/application_1400229396615_0011/container_1400229396615_0011_01_000012/stdout 2>/home/hadoop/logs/nodemanager/logs/application_1400229396615_0011/container_1400229396615_0011_01_000012/stderr Container killed on request. Exit code is 143 Container exited with a non-zero exit code 143

來源： <http://xxxxxxxxxx:50030/proxy/application_1400229396615_0011/mapreduce/attempts/job_1400229396615_0011/m/FAILED> 解決方法： 下面的參數是關於mapreduce任務運行時的內存設置，如果有的任務需要可單獨配置，就統一配置了。如果有container被kill 可以適當調高 mapreduce.map.memory.mb map任務的最大內存 mapreduce.map.java.opts -Xmx1024M map任務jvm的參數 mapreduce.reduce.memory.mb reduce任務的最大內存 mapreduce.reduce.java.opts -Xmx2560M reduce任務jvm的參數 mapreduce.task.io.sort.mb 512 Higher memory-limit while sorting data for efficiency.

摘自：http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/ClusterSetup.html#Configuring_the_Hadoop_Daemons_in_Non-Secure_Mode 關閉內存檢測進程： 是在搞不清楚 問什麼有的任務就物理內存200多MB ，虛擬內存就飆到2.7G了，估計內存檢測進程有問題，而且我有的任務是需要大內存的，爲了進度，索性關了，一下子解決所有內存問題。 yarn.nodemanager.pmem-check-enabled false yarn.nodemanager.vmem-check-enabled false

15 yarn 的webUI 有關的調整：

1 cluser 頁面 application的starttime 和finishtime 都是 UTC格式，改成 +8區時間也就是北京時間。
./share/hadoop/yarn/hadoop-yarn-common-2.3.0.jar 裏面的webapps.static.yarn.dt.plugins.js
或者源碼包裏面：/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common/src/main/resources/webapps/static/yarn.dt.plugins.js
添加代碼：

Date.prototype.Format = function (fmt) { //author: meizz

    var o = {

        "M+": this.getMonth() + 1, //月份

        "d+": this.getDate(), //日

        "h+": this.getHours(), //小時

        "m+": this.getMinutes(), //分

        "s+": this.getSeconds(), //秒

        "q+": Math.floor((this.getMonth() + 3) / 3), //季度

        "S": this.getMilliseconds() //毫秒

};

    if (/(y+)/.test(fmt)) fmt = fmt.replace(RegExp.$1, (this.getFullYear() + "").substr(4 - RegExp.$1.length));

    for (var k in o)

    if (new RegExp("(" + k + ")").test(fmt)) fmt = fmt.replace(RegExp.$1, (RegExp.$1.length == 1) ? (o[k]) : (("00" + o[k]).substr(("" + o[k]).length)));

    return fmt;

};

同時按下面修改下的代碼

function renderHadoopDate(data, type, full)

{ if (type === 'display' || type === 'filter') { if(data === '0') { return "N/A"; }

return new Date(parseInt(data)).Format("yyyy-MM-dd hh:mm:ss"); }

16 MR1的任務用到DistributedCache 的任務遷移到MR2上出錯。原來我裏面使用文件名區分不同的緩存文件，MR2裏面分發文件以後只保留的文件名如：

application_xxxxxxx/container_14xxxx/part-m-00000

application_xxxxxxx/container_14xxxx/part-m-00001

application_xxxxxxx/container_14xxxx/00000_0

解決方法：每個緩存文件添加符號鏈接，鏈接爲父級名字+文件名

DistributedCache.addCacheFile(new URI(path.toString() + "#"+ path.getParent().getName() + "_" + path.getName()),

configuration);

這樣就會生成帶有文件名的緩存文件

For our example cluster, we have the minimum RAM for a Container(yarn.scheduler.minimum-allocation-mb) = 2 GB. We’ll thus assign 4 GB for Maptask Containers, and 8 GB for Reduce tasks Containers.

In mapred-site.xml:

mapreduce.map.memory.mb: 4096

mapreduce.reduce.memory.mb: 8192

Each Container will run JVMs for the Map and Reduce tasks. The JVM heapsize should be set to lower than the Map and Reduce memory defined above, sothat they are within the bounds of the Container memory allocated by YARN.

In mapred-site.xml:

mapreduce.map.java.opts: -Xmx3072m

mapreduce.reduce.java.opts: -Xmx6144m

The above settings configure the upper limit of the physical RAM thatMap and Reduce tasks will use.

To sum it up:

In YARN, you should use the mapreduce configs, not the mapred ones. EDIT: This comment is not applicable anymore now that you've edited your question.
What you are configuring is actually how much you want to request, not what is the max to allocate.
The max limits are configured with the java.opts settings listed above.

2 down vote

I can't comment on the accepted answer, due to low reputation. However, I would like to add, this behavior is by design. The NodeManager is killing your container. It sounds like you are trying to use hadoop streaming which is running as a child process of the map-reduce task. The NodeManager monitors the entire process tree of the task and if it eats up more memory than the maximum set in mapreduce.map.memory.mb or mapreduce.reduce.memory.mb respectively, we would expect the Nodemanager to kill the task, otherwise your task is stealing memory belonging to other containers, which you don't want.

yarn_scheduler_minimum_allocation_mb

修改

ERROR tool.ImportTool: Imported Failed: Attempted togenerate class with no columns!

這個原因是因爲：-username micmiu 用戶名這個參數，需要把用戶名大寫：-username MICMIU ，再執行就ok了。

Initialization failed for block pool Block pool

2013-06-08 17:57:27,519 FATAL org.apache.hadoop.hdfs.server.datanode.DataNode: Initialization failed for block pool Block pool BP-770817654-172.17.50.119-1370685416301 (storage id DS-803461661-172.17.50.119-50010-1370681848198) service to localhost/127.0.0.1:9000

java.io.IOException: Incompatible clusterIDs in /usr/hadoop/tmp/dfs/data: namenode clusterID = CID-cd47cf1e-0f81-41b0-97df-7407db9f1fa5; datanode clusterID = CID-0462092f-2740-40a4-bf96-246be2efc49f

        at org.apache.hadoop.hdfs.server.datanode.DataStorage.doTransition(DataStorage.java:390)

        at org.apache.hadoop.hdfs.server.datanode.DataStorage.recoverTransitionRead(DataStorage.java:190)

        at org.apache.hadoop.hdfs.server.datanode.DataStorage.recoverTransitionRead(DataStorage.java:218)

        at org.apache.hadoop.hdfs.server.datanode.DataNode.initStorage(DataNode.java:851)

        at org.apache.hadoop.hdfs.server.datanode.DataNode.initBlockPool(DataNode.java:822)

        at org.apache.hadoop.hdfs.server.datanode.BPOfferService.verifyAndSetNamespaceInfo(BPOfferService.java:279)

        at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake(BPServiceActor.java:218)

        at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:661)

        at java.lang.Thread.run(Thread.java:619)

因爲每次namenode format會重新創建一個namenodeId,而存放datanode數據的tmp/dfs/data目錄下包含了上次format下的 id,namenode format清空了namenode下的數據,但是沒有清除datanode下的數據,導致啓動時失敗,所要做的就是每次fotmat前,清空tmp一下的所有目錄.

installphase

安裝環境：Ubuntu 12.04.3 LTS

硬件環境：三臺服務器，兩臺namenode，一臺datanode，分別如下：

ü 192.168.111.130，主namenode，zookeeper，journalnode，zkfc

ü 192.168.111.131，datanode，zookeeper，journalnode

ü 192.168.111.132，備namenode，zookeeper，journalnode，zkfc

0、首先把各個zookeeper起來，如果zookeeper集羣還沒有啓動的話。

./bin/zkServer.sh start

1、然後在某一個namenode節點執行如下命令，創建命名空間

./bin/hdfs zkfc -formatZK

2、在各個節點用如下命令啓日誌程序

./sbin/hadoop-daemon.sh start journalnode

3、在主namenode節點用./bin/hadoopnamenode -format格式化namenode和journalnode目錄

./bin/hadoop namenode -format mycluster

4、在主namenode節點啓動./sbin/hadoop-daemon.shstart namenode進程

./sbin/hadoop-daemon.sh start namenode

5、在備節點執行第一行命令，這個是把備namenode節點的目錄格式化並把元數據從主namenode節點copy過來，並且這個命令不會把journalnode目錄再格式化了！然後用第二個命令啓動備namenode進程！

./bin/hdfs namenode –bootstrapStandby

./sbin/hadoop-daemon.sh start namenode

6、在兩個namenode節點都執行以下命令

./sbin/hadoop-daemon.sh start zkfc

7、在所有datanode節點都執行以下命令啓動datanode

./sbin/hadoop-daemon.sh start datanode

準備記錄下我在學習和工作中遇到的hbase報錯信息及解決方案。

描述：HMaster啓動之後自動掛掉，並且master的log裏出現“TableExistsException: hbase:namespace”字樣

很可能是更換了Hbase的版本過後zookeeper還保留着上一次的Hbase設置，所以造成了衝突。

解決：zookeeper還保留着上一次的Hbase設置，所以造成了衝突。刪除zookeeper信息，重啓之後就沒問題了

1.切換到zookeeper的bin目錄；

2.執行$sh zkCli.sh

輸入‘ls /’

4.輸入‘rmr /hbase’（這個是遞歸刪除，新版的zookeeper不支持這個命令，必須按照目錄一個一個子目錄刪）

5.退出

重啓hbase即可。

原文地址：RSA host key has just been changed and fail to log on作者：whfwind

when I ssh to log on the server,

there is a error msg:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOSTIDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOINGSOMETHING NASTY!

Someone could be eavesdropping on you rightnow (man-in-the-middle attack)!

It is also possible that the RSA host keyhas just been changed.

The fingerprint for the RSA key sent by theremote host is

28:5d:a3:42:1f:ac:d5:2b:9a:6a:b1:28:b1:6b:55:f8.

Please contact your system administrator.

Add correct host key in/home/whfwind/.ssh/known_hosts to get rid of this message.

Offending key in/home/whfwind/.ssh/known_hosts:2

RSA host key for 192.168.100.5 has changedand you have requested strict checking.

Host key verification failed.

then I searched on the internet, so Icollected here:

you just need to delete or annote the lineof your home ~/.ssh/known_host file of the IP you have failed logged

The directory is alreadylocked

運行：hadoop namenode -format 報錯誤信息如下：
14/05/15 17:13:35 INFO common.Storage: Cannot lock storage /usr/hadoop/dfs/name. The directory is already locked.
14/05/15 17:13:35 ERROR namenode.NameNode: java.io.IOException: Cannot lockstorage /usr/hadoop/dfs/name. The directory is already locked.
        atorg.apache.hadoop.hdfs.server.common.Storage$StorageDirectory.lock(Storage.java:602)
        atorg.apache.hadoop.hdfs.server.namenode.FSImage.format(FSImage.java:1321)
        at org.apache.hadoop.hdfs.server.namenode.FSImage.format(FSImage.java:1339)
        atorg.apache.hadoop.hdfs.server.namenode.NameNode.format(NameNode.java:1164)
        atorg.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1271)
        atorg.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1288)

解決方法：
[root@localhost hadoop-1.0.3]# chown -R root:123456 /usr/hadoop

root爲當前登錄用戶名，123456：爲登錄密碼

其中：cat conf/core-site.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl"href="configuration.xsl"?>

<configuration>
 <property>
 <name>hadoop.tmp.dir</name>
 <value>/usr/hadoop</value>
 </property>
 <property>
 <name>fs.default.name</name>
 <value>hdfs://192.168.0.109:9000</value>
 </property>

</configuration>

2、 DataNode不能啓動：

在客戶端日誌顯示 namenode namespaceID = 1713611278; datanode namespaceID = 596511341

這個問題基本上是因爲在namenode端多次運行hadoop namenode –format 導致的。在hadoop的core-site.xml文件中（不同的hadoop版本名字會有不同）找到<name>hadoop.tmp.dir</name>，清空對應的文件夾。舉例：

[hadoop@hadoop-datanode1 hadoop]$ cat core-site.xml<?xml version="1.0"?><?xml-stylesheet type="text/xsl"href="configuration.xsl"?><configuration><property><name>hadoop.tmp.dir</name><value>/usr/hadoop/tmp</value></property>

清空

[hadoop@hadoop-datanode1 tmp]$ rm -rf /usr/hadoop/tmp/*

然後重新啓動hadoop，在datanode端用jps看是否datanode已經啓動了。

3、通過命令和查看日誌文件查看hadoop啓動和運行情況

在NameNode端，可以通過

tail -100/var/log/hadoop/hadoop/hadoop-hadoop-namenode-hadoop-namenode.log

查看NameNode的運行日誌

在DataNode端也可以通過

cat/var/log/hadoop/hadoop/hadoop-hadoop-datanode-hadoop-datanode1.log

查看DataNode的運行日誌。

通過jps命令分別在datanode和namenode端運行，查看已啓動的服務。

4、ERRORorg.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException:Incompatible namespaceIDs in

ERROR org.apache.hadoop.hdfs.server.datanode.DataNode:java.io.IOException: Incompatible namespaceIDs in /usr/hadoop/dfs/data:namenode namespaceID = 1988494166; datanode namespaceID = 1906089544

導致datanode啓動不了。

原因:每次namenode format會重新創建一個namenodeId,而dfs.data.dir參數配置的目錄中包含的是上次format創建的id,和dfs.name.dir參數配置的目錄中的id不一致。namenodeformat清空了namenode下的數據,但是沒有清空datanode下的數據,導致啓動時失敗,所要做的就是每次fotmat前,清空dfs.data.dir參數配置的目錄.
格式化hdfs的命令

Shell代碼

hadoop namenode -format

5、Warning: $HADOOP_HOME is deprecated.hadoop1.0.4解決方法

啓動Hadoop時報了一個警告信息，我安裝的Hadoop版本是hadoop1.0.4，具體警告信息如下：

Shell代碼

[root@localhost hadoop-1.0.4]# ./bin/start-all.sh
Warning: $HADOOP_HOME is deprecated.

網上的說法是因爲Hadoop本身對HADOOP_HOME做了判斷，具體在bin/hadoop和bin/hadoop-config.sh裏。在hadoop-config.sh裏有如下的配置：

Shell代碼

if [ "$HADOOP_HOME_WARN_SUPPRESS" ="" ] && [ "$HADOOP_HOME" !="" ]; then
echo "Warning: \$HADOOP_HOME is deprecated."1>&2
echo 1>&2
fi

對於這個警告問題，解決方法如下：

1.註釋掉hadoop-config.sh裏的上面給出的這段if fi配置（不推薦）

2.在當前用戶home/.bash_profile裏增加一個環境變量：

vi .bash_profile

在文件中輸入：

export HADOOP_HOME_WARN_SUPPRESS=1 / true ?自己試試

注：修改完.bash_profile後需要執行source操作使其生效

Shell代碼

[root@localhost ~]# source .bash_profile

執行完後我們可以檢驗一下配置是否成功，重新執行start-all.sh腳本：

Shell代碼

[root@localhost hadoop-1.0.4]# ./bin/start-all.sh
starting namenode, logging to /root/hadoop-1.0.4/libexec/../logs/hadoop-root-namenode-localhost.out
localhost: starting datanode, logging to /root/hadoop-1.0.4/libexec/../logs/hadoop-root-datanode-localhost.out
localhost: starting secondarynamenode, logging to /root/hadoop-1.0.4/libexec/../logs/hadoop-root-secondarynamenode-localhost.out
starting jobtracker, logging to /root/hadoop-1.0.4/libexec/../logs/hadoop-root-jobtracker-localhost.out
localhost: starting tasktracker, logging to /root/hadoop-1.0.4/libexec/../logs/hadoop-root-tasktracker-localhost.out

沒有出現Warning: $HADOOP_HOME is deprecated，說明問題已經解決。

6、Hadoop MapReduce輸出結果中文亂碼問題解決

在Reduce程序的

public void reduce(Text key, Iterable<Text> values, Contextcontext) throws IOException, InterruptedException

的方法最後寫入文件時，對內容進行轉碼爲GBK，如下程序代碼：

       Text record = new Text();
    record.set(line.toString().getBytes("GBK"));//輸出爲中文
    context.write(record,null);

YARN常見異常

異常1：

2012-05-16 16:18:42,468 WARNorg.apache.hadoop.yarn.server.nodemanager.containermanager.launcher.ContainerLaunch:Failed to launch container.

java.io.FileNotFoundException: File/tmp/nm-local-dir/usercache/a/appcache/application_1337150856633_0016 does notexist

? ? ? ? atorg.apache.hadoop.fs.RawLocalFileSystem.getFileStatus(RawLocalFileSystem.java:449)

? ? ? ? atorg.apache.hadoop.fs.FileSystem.primitiveMkdir(FileSystem.java:864)

? ? ? ? atorg.apache.hadoop.fs.DelegateToFileSystem.mkdir(DelegateToFileSystem.java:143)

? ? ? ? atorg.apache.hadoop.fs.FilterFs.mkdir(FilterFs.java:189)

? ? ? ? atorg.apache.hadoop.fs.FileContext$4.next(FileContext.java:700)

? ? ? ? atorg.apache.hadoop.fs.FileContext$4.next(FileContext.java:697)

? ? ? ? atorg.apache.hadoop.fs.FileContext$FSLinkResolver.resolve(FileContext.java:2319)

? ? ? ? at org.apache.hadoop.fs.FileContext.mkdir(FileContext.java:697)

原因A:

yarn-site.xml中參數yarn.nodemanager.local-dirs和yarn.nodemanager.log-dirs使用

默認路徑（/tmp/..），導致將磁盤空間撐爆

原因B:

在org.apache.hadoop.yarn.server.nodemanager.DefaultContainerExecutor文件中，創建目錄方法在默認情況下需要創建的目錄父目錄不存在則失敗，具體代碼如下

lfs.mkdir(containerDir, null, true);

異常2：

2012-05-16 09:56:57,078 INFOorg.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService:Localizer failed

java.lang.ArithmeticException: / by zero

? ? ? ? at org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext.getLocalPathForWrite(LocalDirAllocator.java:355)

? ? ? ? atorg.apache.hadoop.fs.LocalDirAllocator.getLocalPathForWrite(LocalDirAllocator.java:150)

? ? ? ? at org.apache.hadoop.fs.LocalDirAllocator.getLocalPathForWrite(LocalDirAllocator.java:131)

? ? ? ? atorg.apache.hadoop.fs.LocalDirAllocator.getLocalPathForWrite(LocalDirAllocator.java:115)

? ? ? ? atorg.apache.hadoop.yarn.server.nodemanager.LocalDirsHandlerService.getLocalPathForWrite(LocalDirsHandlerService.java:257)

? ? ? ? atorg.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService$LocalizerRunner.run(ResourceLocalizationService.java:854)

原因：

該錯誤是由於無法創建本地文件而產生的，可能會由上述磁盤空間不足導致,重定向上面提到的兩個參數即可

異常3：

查看log沒有明顯的ERROR，但存在類似以下描述的日誌

2012-05-16 13:08:20,876 INFOorg.apache.hadoop.yarn.server.nodemanager.NodeStatusUpdaterImpl: Sending outstatus for container: container_id {, app_attempt_id {, application_id {, id:18, cluster_timestamp: 1337134318909, }, attemptId: 1, }, id: 6, }, state:C_COMPLETE, diagnostics: "Container[pid=15641,containerID=container_1337134318909_0018_01_000006] is runningbeyond virtual memory limits. Current usage: 32.1mb of 1.0gb physical memory used; 6.2gb of2.1gb virtual memory used. Killing container.\nDump of theprocess-tree for container_1337134318909_0018_01_000006 :\n\t|- PID PPID PGRPIDSESSID CMD_NAME USER_MODE_TIME(MILLIS) SYSTEM_TIME(MILLIS) VMEM_USAGE(BYTES)RSSMEM_USAGE(PAGES) FULL_CMD_LINE\n\t|- 15641 26354 15641 15641 (java) 36 26686339072 8207 /home/zhouchen.zm/jdk1.6.0_23/bin/java

原因：

該錯誤是YARN的虛擬內存計算方式導致，上例中用戶程序申請的內存爲1Gb，YARN根據此值乘以一個比例（默認爲2.1）得出申請的虛擬內存的值，當YARN計算的用戶程序所需虛擬內存值大於計算出來的值時，就會報出以上錯誤。調節比例值可以解決該問題。具體參數爲：yarn-site.xml中的yarn.nodemanager.vmem-pmem-ratio

hadoop一些錯誤

錯誤1：bin/hadoop dfs 不能正常啓動，持續提示：

INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:9000. Alreadytried 0 time(s).
原因：由於 dfs 的部分文件默認保存在tmp文件夾，在系統重啓時被刪除。
解決：修改core-site.xml 的 hadoop.tmp.dir配置文件路徑：/home/hadoop/tmp。

錯誤2：hadoop出現了一些問題。用$ bin/hadoop dfsadmin -report 測試的時候，發現dfs沒有加載。

顯示如下：
         Configured Capacity: 0 (0 KB)
         Present Capacity: 0 (0 KB)
         DFS Remaining: 0 (0 KB)
         DFS Used: 0 (0 KB)
         DFS Used%: ?%
         Under replicated blocks: 0
         Blocks with corrupt replicas:0
         Missing blocks: 0
         查看日誌：
         ERRORorg.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException:Incompatible namespaceIDs in /home/hadoop/data: namenode namespaceID=      2033006627; datanode namespaceID = 1589898341
        經分析，是由於namenodenamespaceID = 2033006627;和datanode namespaceID = 1589898341 不一致造成原因。
        修改了namenodenamespaceID = 1589898341 可以使用，但是重啓之後，又不可以用了。
最後解決方案：刪除hadoop用戶下的name文件夾，data文件夾，tmp文件夾，temp文件裏的內容，然後重新執行namenode命令。
（在datanode的存儲數據結果中，最大的數據結構是storage，實現類中用版本控制信息。如果hadoop調整文件結果佈局，version就會改變。以保證文件結構和應用一致）；
重啓電腦之後，正常。

錯誤3：File /home/hadoop/tmp/mapred/system/jobtracker.info could only bereplicated to 0 nodes, instead of 1

出現此錯誤，一般發生在datanode與namenode還沒有進行連接，就開始往hdfs系統上put數據了。稍等待一會，就可以了。
也可以使用：hadoop dfsadmin –report命令查看集羣的狀態。

錯誤4：
每次啓動總有部分datanade不能去全部啓動，查看日誌文件，顯示爲：
ERROR org.apache.hadoop.hdfs.server.datanode.DataNode:java.net.UnknownHostException: zgchen-ubutun: zgchen-ubutun atjava.net.InetAddress.getLocalHost(InetAddress.java:1426)。

分析：這是由於 datanode 找不到服務host引起的。
解決：通過查找/etc/hostname 找到hostname；比如：ubuntu。
然後找到/etc/hosts ，添加：127.0.1.1 ubuntu

錯誤5：
java.lang.OutOfMemoryError: GC overhead limit exceeded

分析：這個是JDK6新添的錯誤類型。是發生在GC佔用大量時間爲釋放很小空間的時候發生的，是一種保護機制。解決方案是，關閉該功能，可以添加JVM的啓動參數來限制使用內存： -XX:-UseGCOverheadLimit
添加位置是：mapred-site.xml 裏新增項：mapred.child.java.opts 內容：-XX:-UseGCOverheadLimit
java.lang.OutOfMemoryError: Java heap space
出現這種異常，明顯是jvm內存不夠得原因，要修改所有的datanode的jvm內存大小。
Java -Xms1024m -Xmx4096m
一般jvm的最大內存使用應該爲總內存大小的一半，我們使用的8G內存，所以設置爲4096m，這一值可能依舊不是最優的值。（其實對於最好設置爲真實物理內存大小的0.8）

錯誤6：Too many fetch-failures

Answer:
出現這個問題主要是結點間的連通不夠全面。
1) 檢查、/etc/hosts
   要求本機ip 對應服務器名
   要求要包含所有的服務器ip + 服務器名
2) 檢查 .ssh/authorized_keys
   要求包含所有服務器（包括其自身）的public key

錯誤7：處理速度特別的慢出現map很快但是reduce很慢而且反覆出現 reduce=0%

Answer:
結合第二點，然後修改可用內存大小。
conf/hadoop-env.sh 中的export HADOOP_HEAPSIZE=4000

錯誤8：能夠啓動datanode，但無法訪問，也無法結束的錯誤

在重新格式化一個新的分佈式文件時，需要將你NameNode上所配置的dfs.name.dir這一namenode用來存放NameNode 持久存儲名字空間及事務日誌的本地文件系統路徑刪除，同時將各DataNode上的dfs.data.dir的路徑 DataNode 存放塊數據的本地文件系統路徑的目錄也刪除。如本此配置就是在NameNode上刪除/home/hadoop/NameData，在DataNode上刪除/home/hadoop/DataNode1和/home/hadoop/DataNode2。這是因爲Hadoop在格式化一個新的分佈式文件系統時，每個存儲的名字空間都對應了建立時間的那個版本（可以查看/home/hadoop /NameData/current目錄下的VERSION文件，上面記錄了版本信息），在重新格式化新的分佈式系統文件時，最好先刪除NameData 目錄。必須刪除各DataNode的dfs.data.dir。這樣纔可以使namedode和datanode記錄的信息版本對應。
注意：刪除是個很危險的動作，不能確認的情況下不能刪除！！做好刪除的文件等通通備份！！

錯誤9：java.io.IOException: Could not obtain block:blk_194219614024901469_1100 file=/user/hive/warehouse/src_20100924_log/src_20100924_log

出現這種情況大多是結點斷了，沒有連接上。或者 mapred.tasktracker.map.tasks.maximum 的設置超過 cpu cores數目，導致出現獲取不到文件。

錯誤10：Task Id : attempt_201010291615_0001_m_000234_0, Status : FAILEDError: java.io.IOException: No space left on device

Task Id : attempt_201010291615_0001_m_000240_0, Status : FAILEDjava.io.IOException: Spill failed
磁盤空間不夠，應該分析磁盤空間df -h 檢查是否還存在磁盤空間。

錯誤11:Task Id : attempt_201011011336_0007_m_000001_0, Status : FAILED
org.apache.hadoop.hbase.client.RegionOfflineException: region offline:lm,,1288597709144

網上說，將/hbase刪除；重啓hbase後，可以正常應用了。但是我找不到/hbase目錄，只好自己重新刪除掉一些hadoop文件，重新生成文件管理系統。
還有一個可能是，配置錯了/hbase/conf/hbase-env.sh的HBASE_CLASSPATH，這個默認是不配置的，所以可以不配置。

錯誤12：org.apache.hadoop.hbase.TableNotFoundException:org.apache.hadoop.hbase.TableNotFoundException: lm

找不到表，hbase啓動了，檢查一下是否存在需要的Htable。

AMContainer is running beyond virtual memory limits

From the error message, you can see that you're using more virtual memory than your current limit of 1.0gb. This can be resolved in two ways:

Disable Virtual Memory Limit Checking

YARN will simply ignore the limit; in order to do this, add this to your yarn-site.xml:

<name>yarn.nodemanager.vmem-check-enabled</name>

<value>false</value>

<description>Whether virtual memory limits will be enforced for containers.</description>

</property>

The default for this setting is true.

Increase Virtual Memory to Physical Memory Ratio

In your yarn-site.xml change this to a higher value than is currently set

<name>yarn.nodemanager.vmem-pmem-ratio</name>

<description>Ratio between virtual memory to physical memory when setting memory limits for containers. Container allocations are expressed in terms of physical memory, and virtual memory usage is allowed to exceed this allocation by this ratio.</description>

</property>

The default is 2.1

You could also increase the amount of physical memory you allocate to a container.

Make sure you don't forget to restart yarn after you change the config.

mapred.job.shuffle.input.buffer.percent（R1） 2014-03-11 11:10:55

分類： Hadoop

說明:用來緩存shuffle數據的reduce task heap百分比

Reduce在shuffle階段對下載來的map數據，並不是立刻就寫入磁盤的，而是會先緩存在內存中，然後當使用內存達到一定量的時候才刷入磁盤。

這個內存大小的控制就不像map一樣可以通過io.sort.mb來設定了，而是通過另外一個參數來設置：mapred.job.shuffle.input.buffer.percent（default0.7），

這個參數其實是一個百分比，意思是說，shuffile在reduce內存中的數據最多使用內存量爲：0.7 × maxHeap of reduce task。

也就是說，如果該reduce task的最大heap使用量（通常通過mapred.child.java.opts來設置，比如設置爲-Xmx1024m）的一定比例用來緩存數據。

默認情況下，reduce會使用其heapsize的70%來在內存中緩存數據。

如果reduce的heap由於業務原因調整的比較大，相應的緩存大小也會變大，這也是爲什麼reduce用來做緩存的參數是一個百分比，而不是一個固定的值了。

修改 hive的內存：

if [ "$SERVICE" = "cli"]; then

if[ -z "$DEBUG" ]; then

export HADOOP_OPTS="$HADOOP_OPTS -XX:NewRatio=12 -Xms10m-XX:MaxHeapFreeRatio=40 -XX:MinHeapFreeRatio=15 -XX:+UseParNewGC-XX:-UseGCOverheadLimit"

else

export HADOOP_OPTS="$HADOOP_OPTS -XX:NewRatio=12 -Xms10m-XX:MaxHeapFreeRatio=40 -XX:MinHeapFreeRatio=15 -XX:-UseGCOverheadLimit"

exportHADOOP_CLIENT_OPTS="-Xms268435456 -Xmx2147483648-Djava.net.preferIPv4Stack=true $HADOOP_CLIENT_OPTS"

以 horntonworks給出推薦配置爲藍本，給出一種常見的Hadoop集羣上各組件的內存分配方案。方案最右側一欄是一個8G VM的分配方案，方案預留1-2G的內存給操作系統，分配4G給Yarn/MapReduce，當然也包括了HIVE，剩餘的2-3G是在需要使用HBase時預留給HBase的。

Configuration File	Configuration Setting	Value Calculation	8G VM (4G For MR)
yarn-site.xml	yarn.nodemanager.resource.memory-mb	= containers * RAM-per-container	4096
yarn-site.xml	yarn.scheduler.minimum-allocation-mb	= RAM-per-container	1024
yarn-site.xml	yarn.scheduler.maximum-allocation-mb	= containers * RAM-per-container	4096
mapred-site.xml	mapreduce.map.memory.mb	= RAM-per-container	1024
mapred-site.xml	mapreduce.reduce.memory.mb	= 2 * RAM-per-container	2048
mapred-site.xml	mapreduce.map.java.opts	= 0.8 * RAM-per-container	819
mapred-site.xml	mapreduce.reduce.java.opts	= 0.8 * 2 * RAM-per-container	1638
yarn-site.xml (check)	yarn.app.mapreduce.am.resource.mb	= 2 * RAM-per-container	2048
yarn-site.xml (check)	yarn.app.mapreduce.am.command-opts	= 0.8 * 2 * RAM-per-container	1638
tez-site.xml	tez.am.resource.memory.mb	= RAM-per-container	1024
tez-site.xml	tez.am.java.opts	= 0.8 * RAM-per-container	819
tez-site.xml	hive.tez.container.size	= RAM-per-container	1024
tez-site.xml	hive.tez.java.opts	= 0.8 * RAM-per-container	819

允許磁盤有多少個壞的

<property>
 <name>dfs.datanode.failed.volumes.tolerated</name>
 <value>1</value>
 </property>

hadoop hbase hive 常見問題解決

問題1：安裝停止在獲取安裝鎖

問題2：不能選擇主機

問題3：DNS反向解析PTR localhost：

問題 4 NTP:

問題 5 heartbeat:

問題 6 Unknow Health：

問題 7 canonial name hostnameconsistent：

問題 8 Concerning Health：

問題10 IOException thrown while collecting data from host: No route to host

問題11

問題12 時鐘不同步（同步至中科大時鐘服務器202.141.176.110）

問題13 The host's NTPservice didnot respond to a request for the clock offset.

問題14 The Cloudera ManagerAgentis not able to communicate with this role's web server.

問題15 Hive MetastoreServer無法啓動，修改Hive元數據數據庫配置（當我們修改主機名後即應修改元數據數據庫配置）：

問題16 datanode無法正常啓動

問題17 safe mode

問題18 連接異常

問題19 namenode id

問題20 目錄權限

問題21 NoClassDefFoundError

問題22 hive動態分區異常

問題23 mapreduce進程超內存限制——hadoop Java heap space

問題24 hive文件數限制

問題25 hive 5.metastore連接超時

問題26 hive 6.java.io.IOException: error=7, Argument list too long

問題27 hive 6.runtime error

問題28 hbase hbase.hregion.max.filesize應該設置多少合適

問題29hbase autoflush=false的影響

問題 30 hbase從性能的角度談table中family和qualifier的設置

問題31 hbase.regionserver.handler.count

HBase性能優化的四個要點

1.2 Row Key

1.3 Column Family

1.4 In Memory

1.5 Max Version

1.6 Time To Live

1.7 Compact & Split

2.2 HTable參數設置

2.2.1 Auto Flush

2.2.2 Write Buffer

2.2.3 WAL Flag

2.3 批量寫

2.4 多線程併發寫

3.2 HTable參數設置

3.2.1 Scanner Caching

3.2.2 Scan AttributeSelection

3.2.3 Close ResultScanner

3.3 批量讀

3.4 多線程併發讀

3.5 緩存查詢結果

3.6 Blockcache

4.數據計算

4.1 服務端計算

4.2 寫端計算

4.2.1 計數

4.2.2 去重

4.3 讀端計算

5.總結

1.禁止Major Compaction

2.禁掉split

3.設置blockingStoreFiles

1. Application Master 無法訪問

2. History UI 無法訪問和 container 打不開

3 yarn 平臺的優化設置 虛擬cpu的個數

4 運行任務 提示： Foundinterface org.apache.hadoop.mapreduce.Counter, but class was expected

5 運行任務提示shuffle內存溢出

6 reduce 任務的log 中間發現：

7 hive 任務

8 hive 任務自動把join裝換mapjoin時內存溢出，

9 hive運行時提示： failed to evaluate: <unbound>=Class.new();

10 hive 創建表或者數據庫的時候 Couldnt obtain a new sequence (unique id) : You have an error inyour SQL syntax

11 安裝hive 12 和13 後，運行任務報錯提示：FileNotFoundException: HIVE_PLAN 解決方法：可能是hive一個bug，也可能那裏配置錯了 ，待解決 錯誤日誌

12java.lang.OutOfMemoryError: GC overhead limit exceeded

13hive hive 0.10.0爲了執行效率考慮，簡單的查詢

14 運行mr 任務的時候提示：

15 yarn 的webUI 有關的調整：

16 MR1的任務用到DistributedCache 的任務遷移到MR2上出錯。原來我裏面使用文件名區分不同的緩存文件，MR2裏面分發文件以後只保留的文件名如：

Initialization failed for block pool Block pool

installphase

　　1.禁止Major Compaction

　　3.設置blockingStoreFiles

3 yarn 平臺的優化設置虛擬cpu的個數

4 運行任務提示： Foundinterface org.apache.hadoop.mapreduce.Counter, but class was expected

11 安裝hive 12 和13 後，運行任務報錯提示：FileNotFoundException: HIVE_PLAN 解決方法：可能是hive一個bug，也可能那裏配置錯了，待解決
錯誤日誌

錯誤4：
每次啓動總有部分datanade不能去全部啓動，查看日誌文件，顯示爲：
ERROR org.apache.hadoop.hdfs.server.datanode.DataNode:java.net.UnknownHostException: zgchen-ubutun: zgchen-ubutun atjava.net.InetAddress.getLocalHost(InetAddress.java:1426)。

錯誤5：
java.lang.OutOfMemoryError: GC overhead limit exceeded

錯誤11:Task Id : attempt_201011011336_0007_m_000001_0, Status : FAILED
org.apache.hadoop.hbase.client.RegionOfflineException: region offline:lm,,1288597709144