hadoop hbase hive 常见问题解决

创建时间：2015-03-24 投稿人：浏览次数：48425

安装过程中，由于网络终端，导致下面问题：

/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个小时，终于过去了，

安装失败了，重新不能选主机

图1
解决方案，需要清理安装失败文件
卸载 Cloudera Manager 5.1.x.和相关软件【官网翻译：高可用】

描述：

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进行连接，就没有错了

参考：

问题描述：

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

错误信息：

Installation failed. Failed to receive heartbeat from agent.

解决：关闭防火墙

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

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

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 的配置，应该不算是真正的解决

原因：agent开启了防火墙

解决：service iptables stop

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）

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

# service crondrestart

# ntpdate202.141.176.110

#service ntpdstart

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

一种原因是元数据数据库无法连接，请检查数据库配置：

问题排查方式

一般的错误，查看错误输出，按照关键字google
异常错误（如namenode、datanode莫名其妙挂了）：查看hadoop（$HADOOP_HOME/logs）或hive日志

hadoop错误

添加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

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

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放开端口

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上存放有重要数据的时候，不建议采用该方法，可以尝试提供的网址中的第二种方法。

start-dfs.sh执行无错，显示启动datanode，执行完后无datanode。查看datanode机器上的日志，显示因dfs.data.dir目录权限不正确导致：

Text代码

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

解决办法：
查看dfs.data.dir的目录配置，修改权限即可。

hive错误

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

[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;

vim mapred-site.xml添加：

Xml代码

//mapred-site.xml

mapred.child.java.opts

-Xmx2048m

Shell代码

#$HADOOP_HOME/conf/hadoop_env.sh

exportHADOOP_HEAPSIZE=5000

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

Shell代码

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

Text代码

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

解决方案：

Shell代码

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

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

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
下

默认值：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

　　无论是官方还是很多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因子数等

　　对于传统关系型数据库中的一张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。

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调优

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一次从服务端抓取的数据条数，默认情

声明：该文观点仅代表作者本人，牛骨文系教育信息发布平台，牛骨文仅提供信息存储空间服务。

上一篇： TP3.2的URL忽略大小写配置导致找不到模板
下一篇： php curl获取到json对象并转成数组array

热门文章: CTF writeup 2_南邮网络攻防训...; SSM框架——详细整合教程（...; Linux Shell脚本编程－－curl命...; HttpClient使用详解; Java面试题全集（上）; JAVA设计模式之单例模式; java.lang.OutOfMemoryError: PermGen ...; TCP协议中的三次握手和四次...; form表单的两种提交方式，su...; String,StringBuffer与StringBuilder...

最新文章: Java之品优购课程讲义_day20（7）; 剑指 Offer - 8：跳台阶; Netty权威指南_札记02_NIO编程; mysql时间属性之时间戳和datetime之...; 虚拟现实或许可以拯救古埃及的“...; spring cloud服务注册中心eureka---集群...; Java SE 第六章; HTTP请求+数据库; HIDL学习笔记之HIDL C++（第二天）; ubuntu系统下指定tomcat运行时为JDK1.8...