华为云用户手册

回答 当Standby NameNode存储元数据（命名空间）时，出现断电的情况，Standby NameNode启动失败，MD5文件会损坏。通过移除损坏的fsimage，然后启动Standby NameNode，可以修复此问题。Standby NameNode会加载先前的fsimage并重现所有的edits。 修复步骤： 移除损坏的fsimage。 rm -rf ${BIGDATA_DATA_HOME}/namenode/current/fsimage_0000000000000096 启动Standby NameNode。

回答 通常，HDFS执行Balance操作结束后，会自动释放“/system/balancer.id”文件，可再次正常执行Balance。 但在上述场景中，由于第一次的Balance操作是被异常停止的，所以第二次进行Balance操作时，“/system/balancer.id”文件仍然存在，则会触发append /system/balancer.id操作，进而导致Balance操作失败。 如果“/system/balancer.id”文件的释放时间超过了软租期60s，则第二次执行Balance操作的客户端的append操作会抢占租约，此时最后一个block处于under construction或者under recovery状态，会触发block的恢复操作，那么“/system/balancer.id”文件必须等待block恢复完成才能关闭，所以此次append操作失败。 append /system/balancer.id操作失败后，客户端发生RecoveryInProgressException异常： org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.protocol.RecoveryInProgressException): Failed to APPEND_FILE /system/balancer.id for DFSClient because lease recovery is in progress. Try again later. 如果该文件的释放时间没有超过默认设置60s，原有客户端会继续持有该租约，则会发生AlreadyBeingCreatedException异常，实际上向客户端返回的是null，导致客户端出现如下异常： java.io.IOException: Cannot create any NameNode Connectors.. Exiting... 可通过以下方法避免上述问题： 方案1：等待硬租期超过1小时后，原有客户端释放租约，再执行第二次Balance操作。 方案2：执行第二次Balance操作之前删除“/system/balancer.id”文件。

配置描述 请参考修改集群服务配置参数，进入HDFS的“全部配置”页面，在搜索框中输入参数名称。 表1 参数说明 参数 描述 默认值 dfs.mover.auto.enable 是否开启数据副本迁移功能，该功能支持多种。默认值为“false”，表示关闭该特性。 false dfs.mover.auto.cron.expression HDFS执行自动数据迁移的CRON表达式，用于控制数据迁移操作的开始时间。仅当dfs.mover.auto.enable设置为true时才有效。默认值“0 * * * *”表示在每个整点执行任务。表达式的具体含义可参见表2。 0 * * * * dfs.mover.auto.hdfsfiles_or_dirs 指定集群执行自动副本迁移的HDFS文件或目录列表，以空格分隔。仅当dfs.mover.auto.enable设置为true时才有效。 - 表2 Cron表达式解释 列 说明 第1列 分钟，参数值为0~59。 第2列 小时，参数值为0~23。 第3列 日期，参数值为1~31。 第4列 月份，参数值为1~12。 第5列 星期，参数值为0~6，0表示星期日。

回答 由于已备份Hive表对应的HDFS目录创建了快照，导致HDFS目录无法删除，造成Hive表删除失败。 Hive表在执行备份操作时，会创建表对应的HDFS数据目录快照。而HDFS的快照机制有一个约束：如果一个HDFS目录已创建快照，则在快照完全删除之前，该目录无法删除或修改名称。Hive表（除EXTERNAL表外）执行drop操作时，会尝试删除该表对应的HDFS数据目录，如果目录删除失败，系统会提示表删除失败。 如果确实需要删除该表，可手动删除涉及到该表的所有备份任务。

问题 为什么在往HDFS写数据时报“java.net.SocketException: No buffer space available”异常？ 这个问题发生在往HDFS写文件时。查看客户端和DataNode的错误日志。 客户端日志如下： 图1 客户端日志 DataNode日志如下： 2017-07-24 20:43:39,269 | ERROR | DataXceiver for client DFSClient_NONMAPREDUCE_996005058_86 at /192.168.164.155:40214 [Receiving block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 with io weight 10] | DataNode{data=FSDataset{dirpath='[/srv/BigData/hadoop/data1/dn/current, /srv/BigData/hadoop/data2/dn/current, /srv/BigData/hadoop/data3/dn/current, /srv/BigData/hadoop/data4/dn/current, /srv/BigData/hadoop/data5/dn/current, /srv/BigData/hadoop/data6/dn/current, /srv/BigData/hadoop/data7/dn/current]'}, localName='192-168-164-155:9866', datanodeUuid='a013e29c-4e72-400c-bc7b-bbbf0799604c', xmitsInProgress=0}:Exception transfering block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 to mirror 192.168.202.99:9866: java.net.SocketException: No buffer space available | DataXceiver.java:870 2017-07-24 20:43:39,269 | INFO | DataXceiver for client DFSClient_NONMAPREDUCE_996005058_86 at /192.168.164.155:40214 [Receiving block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 with io weight 10] | opWriteBlock BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 received exception java.net.SocketException: No buffer space available | DataXceiver.java:933 2017-07-24 20:43:39,270 | ERROR | DataXceiver for client DFSClient_NONMAPREDUCE_996005058_86 at /192.168.164.155:40214 [Receiving block BP-1287143557-192.168.199.6-1500707719940:blk_1074269754_528941 with io weight 10] | 192-168-164-155:9866:DataXceiver error processing WRITE_BLOCK operation src: /192.168.164.155:40214 dst: /192.168.164.155:9866 | DataXceiver.java:304 java.net.SocketException: No buffer space available at sun.nio.ch.Net.connect0(Native Method) at sun.nio.ch.Net.connect(Net.java:454) at sun.nio.ch.Net.connect(Net.java:446) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648) at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:192) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:531) at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:495) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.writeBlock(DataXceiver.java:800) at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.opWriteBlock(Receiver.java:138) at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.processOp(Receiver.java:74) at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:265) at java.lang.Thread.run(Thread.java:748)

前提条件 Spark2x和Oozie组件安装完成且运行正常，客户端安装成功。 如果当前客户端为旧版本，需要重新下载和安装客户端。 已创建或获取访问Oozie服务的人机用户账号及密码。 该用户需要从属于hadoop、supergroup、hive组，同时添加Oozie的角色操作权限。如果使用Hive多实例，该用户还需要从属于具体的Hive实例组，如hive3。 用户同时还需要至少有manager_viewer权限的角色。

操作步骤 以客户端安装用户登录安装Oozie客户端的节点。 执行以下命令，获取安装环境信息。其中“/opt/client”为客户端安装路径，该操作的客户端目录只是举例，请根据实际安装目录修改。 source /opt/client/bigdata_env 判断集群认证模式。 安全模式，执行kinit命令进行用户认证。 例如，使用oozieuser用户进行认证。 kinit oozieuser 普通模式，执行4。 执行以下命令，进入样例目录。 cd /opt/client/Oozie/oozie-client-*/examples/apps/spark2x/ 该目录下需关注文件如表1所示。 表1 文件说明 文件名称 描述 job.properties 工作流的参数变量定义文件。 workflow.xml 工作流的规则定制文件。 lib 工作流运行依赖的jar包目录。 执行以下命令，编辑“job.properties”文件。 vi job.properties 修改如下内容： 更改“userName”的参数值为提交任务的人机用户名，例如“userName=oozieuser”。 执行oozie job命令，运行工作流文件。 oozie job -oozie https://oozie角色的主机名:21003/oozie/ -config job.properties -run 命令参数解释如下： -oozie 实际执行任务的Oozie服务器URL -config 工作流属性文件 -run 运行工作流 执行完工作流文件，显示“job id”表示提交成功，例如“job: 0000021-140222101051722-oozie-omm-W”。登录Oozie管理页面，查看运行情况。 使用oozieuser用户，登录Oozie WebUI页面：https://oozie角色的ip地址:21003/oozie 。 Oozie的WebUI界面中，可在页面表格根据“job id”查看已提交的工作流信息。

问题 当使用与Region Server相同的Linux用户（例如omm用户）但不同的kerberos用户（例如admin用户）时，为什么ImportTsv工具执行失败报“Permission denied”的异常？ Exception in thread "main" org.apache.hadoop.security.AccessControlException: Permission denied: user=admin, access=WRITE, inode="/user/omm-bulkload/hbase-staging/partitions_cab16de5-87c2-4153-9cca-a6f4ed4278a6":hbase:hadoop:drwx--x--x at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:342) at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:315) at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:231) at com.xxx.hadoop.adapter.hdfs.plugin.HWAccessControlEnforce.checkPermission(HWAccessControlEnforce.java:69) at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190) at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1789) at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1773) at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1756) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFileInternal(FSNamesystem.java:2490) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFileInt(FSNamesystem.java:2425) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFile(FSNamesystem.java:2308) at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.create(NameNodeRpcServer.java:745) at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.create(ClientNamenodeProtocolServerSideTranslatorPB.java:434) at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java) at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616) at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:973) at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2260) at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2256) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1781) at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2254)

操作步骤 创建工作流，请参考使用Hue创建工作流。 在工作流编辑页面，选择“Spark 程序”按钮，将其拖到操作区中。 在弹出的“Spark”窗口配置“Files”，例如“hdfs://hacluster/user/admin/examples/apps/spark2x/lib/oozie-examples.jar”。配置“jar/py name”，例如“oozie-examples.jar” ，配置完成后单击“添加”。 配置“Main class”的值。例如“org.apache.oozie.example.SparkFileCopy”。 单击“参数+”，添加输入输出相关参数。 例如添加： “hdfs://hacluster/user/admin/examples/input-data/text/data.txt” “hdfs://hacluster/user/admin/examples/output-data/spark_workflow” 在“Options list”文本框指定spark参数，例如“--conf spark.yarn.archive=hdfs://hacluster/user/spark2x/jars/xxx/spark-archive-2x.zip --conf spark.eventLog.enabled=true --conf spark.eventLog.dir=hdfs://hacluster/spark2xJobHistory2x”。 此处版本号“xxx”为示例，可登录 FusionInsight Manager界面，单击右上角的，在下拉框中单击“关于”，在弹框中查看Manager版本号。 单击右上角的配置按钮。配置“Spark Master”的值，例如“yarn-cluster”。配置“Mode”的值，例如“cluster”。 在打开的配置界面中，单击“删除+”，添加删除目录，例如“hdfs://hacluster/user/admin/examples/output-data/spark_workflow”。 单击“属性+”，添加oozie使用的sharelib，左边文本框填写属性名称“oozie.action.sharelib.for.spark”，右边文本框填写属性值“spark2x”。 单击Oozie编辑器右上角的。 保存前如果需要修改作业名称（默认为“My Workflow”），可以直接单击该名称进行修改，例如“Spark-Workflow”。 保存完成后，单击，提交该作业。 作业提交后，可通过Hue界面查看作业的详细信息、日志、进度等相关内容。

回答 在HMaster主备倒换或启动期间，HMaster为先前失败/停用的RegionServer执行WAL splitting及region恢复。 在后台运行有多个监控HMaster启动进程的线程： TableNamespaceManager 这是一个帮助类，用于在HMaster主备倒换或启动期间，管理namespace表及监控表region的分配。如果namespace表在规定时间（hbase.master.namespace.init.timeout，默认为3600000ms）内没有上线，那么它就会异常中断HMaster进程。 InitializationMonitor 这是一个主HMaster初始化线程监控类，用于监控主Master的初始化。如果在规定时间（hbase.master.initializationmonitor.timeout，默认为3600000ms）内初始化线程失败，该线程会异常终止HMaster（如果该hbase.master.initializationmonitor.haltontimeout被启动，默认为false）。 在HMaster主备倒换或启动期间，如果WAL HLog文件存在，它会初始化WAL splitting任务。如果WAL HLog splitting任务完成，它将初始化表region分配任务。 HMaster通过ZooKeeper协调log splitting任务和有效的RegionServer，并追踪任务的发展。如果主HMaster在log splitting任务期间退出，新的主HMaster会尝试重发没有完成的任务，RegionServer从头启动log splitting任务。 HMaster初始化工作完成情况会由于很多原因被延迟： 间歇性的网络故障。 磁盘瓶颈。 log split任务工作负荷较大，RegionServer运行缓慢。 RegionServer（region openning）响应缓慢。 在以上场景中，为使HMaster更早完成恢复任务，建议增加以下配置参数，否则Master将退出导致整个恢复进程被更大程度地延迟。 增加namespace表在线等待超时周期，保证Master有足够的时间协调RegionServer workers split任务，避免一次次重复相同的任务。 “hbase.master.namespace.init.timeout”（默认为3600000ms） 通过RegionServer worker增加并行split任务执行数，保证RegionServer worker能并行处理split work（RegionServer需要有更多的核心）。在“客户端安装路径/HBase/hbase/conf/hbase-site.xml”中添加参数： “hbase.regionserver.wal.max.splitters”（默认为2） 如果所有的恢复过程都需要时间，增加初始化监控线程超时时间。 “hbase.master.initializationmonitor.timeout”（默认为3600000ms）

操作场景 HDFS部署在具有多个NameNode实例的HA（High Availability）模式中，HDFS客户端需要依次连接到每个NameNode，以确定当前活动的NameNode是什么，并将其用于客户端操作。 一旦识别出来，当前活动的NameNode的详细信息就可以被缓存并共享给在客户端机器中运行的所有客户端。这样，每个新客户端可以首先尝试从缓存加载活动的Name Node的详细信息，并将RPC调用保存到备用的NameNode。在异常情况下有很多优势，例如当备用的NameNode连接长时间不响应时。 当发生故障，将另一个NameNode切换为活动状态时，缓存的详细信息将被更新为当前活动的NameNode的信息。 本章节适用于 MRS 3.x及后续版本。

回答 ImportTsv工具在“客户端安装路径/HBase/hbase/conf/hbase-site.xml”文件中“hbase.fs.tmp.dir”参数所配置的HBase临时目录中创建partition文件。因此客户端（kerberos用户）应该在指定的临时目录上具有rwx的权限来执行ImportTsv操作。“hbase.fs.tmp.dir”参数的默认值为“/user/${user.name}/hbase-staging”（例如“/user/omm/hbase-staging”），此处“$ {user.name}”是操作系统用户名（即omm用户），客户端（kerberos用户，例如admin用户）不具备该目录的rwx权限。 上述问题可通过执行以下步骤解决： 在客户端将“hbase.fs.tmp.dir”参数设置为当前kerberos用户的目录（如“/user/admin/hbase-staging”），或者为客户端（kerberos用户）提供已配置的目录所必须的rwx权限。 重试ImportTsv操作。

创建HetuEngine计算实例前提条件 已创建用于访问HetuEngine WebUI界面的用户，如hetu_user，用户创建具体操作请参见创建HetuEngine权限角色。 已在待操作集群创建所需租户。请确保修改HetuEngine计算实例配置时，对应的租户有足够的内存和CPU资源。 创建HetuEngine计算实例时必须使用“叶子租户”类型的租户，只有叶子租户的队列才能提交Yarn任务。 为了避免资源竞争带来的不确定性因素，建议为HetuEngine使用的租户创建独立资源池。

计算实例状态说明 计算实例创建成功后，可在“计算实例”页签查看当前已创建的实例信息，包括实例所属租户名、对应实例数量、实例状态和资源总量等，实例状态信息如下： 图1 计算实例状态 绿色图标：实例处于运行中或亚健康状态。 红色图标：实例故障。 灰色图标：实例已停止、待启动。 蓝色图标：实例处于其他状态，包括扩容中、缩容中、滚动重启中、创建中、启动中、安全启动中、停止中、安全停机中、删除中、已删除、停止中等。

HetuEngine元数据缓存介绍 当HetuEngine访问Hive数据源时，需要访问Hive metastore获取元数据信息。HetuEngine提供了元数据缓存的功能，当首次访问Hive数据源的库或表时，会将该库或表的元数据信息（数据库名、表名、表字段、分区信息、权限信息等）缓存起来，后续访问时不需要再次访问Hive metastore，在Hive数据源的表数据变化不频繁的场景下，可以一定程度上提升查询的性能。

回答 当运行任务时，将MR ApplicationMaster或ResourceManager移动为D状态（不间断睡眠状态）或T状态（停止状态），客户端会等待返回任务运行的状态，由于AM无返回，客户端会一直处于等待状态。 为避免出现上述场景，使用“core-site.xml”中的“ipc.client.rpc.timeout”配置项设置客户端超时时间。 该参数的参数值为毫秒。默认值为0，表示无超时。客户端超时的取值范围可以为0～2147483647毫秒。 如果Hadoop进程已处于D状态，重启该进程所处的节点。 “core-site.xml”配置文件在客户端安装路径的conf目录下，例如“/opt/client/Yarn/config”。

答案 generic-jdbc-connector 使用JDBC方式从Oracle数据库读取数据，适用于支持JDBC的数据库。 在这种方式下，Loader加载数据的性能受限于分区列的数据分布是否均匀。当分区列的数据偏斜（数据集中在一个或者几个值）时，个别Map需要处理绝大部分数据，进而导致索引失效，造成SQL查询性能急剧下降。 generic-jdbc-connector支持视图的导入导出，而oracle-partition-connector和oracle-connector暂不支持，因此导入视图只能选择该连接器。 oracle-partition-connector和oracle-connector 这两种连接器都支持按照Oracle的ROWID进行分区（oracle-partition-connector是自研，oracle-connector是社区开源版本），二者的性能较为接近。 oracle-connector需要的系统表权限较多，下面是各自需要的系统表，需要赋予读权限。 oracle-connector：dba_tab_partitions、dba_constraints、dba_tables、dba_segments、v$version、dba_objects、v$instance、SYS_CONTEXT函数、dba_extents、dba_tab_subpartitions。 oracle-partition-connector：DBA_OBJE CTS 、DBA_EXTENTS。 相比于generic-jdbc-connector，oracle-partition-connector和oracle-connector具有以下优点： 负载均匀，数据分片的个数和范围与源表的数据无关，而是由源表的存储结构（数据块）确定，颗粒度可以达到“每个数据块一个分区”。 性能稳定，完全消除“数据偏斜”和“绑定变量窥探”导致的“索引失效”。 查询速度快，数据分片的查询速度比用索引快。 水平扩展性好，如果数据量越大，产生的分片就越多，所以只要增加任务的并发数，就可以获得较理想的性能；反之，减少任务并发数，就可以节省资源。 简化数据分片逻辑，不需要考虑“精度丢失”、“类型兼容”和“绑定变量”等问题。 易用性得到增强，用户不需要专门为Loader创建分区列、分区表。

操作步骤 创建工作流，请参考使用Hue创建工作流。 在工作流编辑页面，选择“HiveServer2 脚本”按钮，将其拖到操作区中。 在弹出的“HiveServer2 Script”窗口中配置HDFS上的脚本路径，例如“/user/admin/examples/apps/hive2/script.q”，然后单击“添加”。 单击“参数+”，添加输入输出参数。 例如输入参数为“INPUT=/user/admin/examples/input-data/table”，输出参数为“OUTPUT=/user/admin/examples/output-data/hive2_workflow”。 单击右上角的配置按钮。在打开的配置界面中，单击“删除+”，添加删除目录，例如“/user/admin/examples/output-data/hive2_workflow”。 配置“作业 XML”，值为“客户端安装目录/Oozie/oozie-client-*/examples/apps/hive/hive-site.xml”上传至HDFS目录中所在路径，例如“/user/admin/examples/apps/hive2/hive-site.xml”。HiveServer2 URL”及其他参数无需配置。 如果以上的参数和值在使用过程中发生了修改，可在“Oozie客户端安装目录/oozie-client-*/conf/hive-site.xml”文件中查询。 单击Oozie编辑器右上角的。 保存前如果需要修改作业名称（默认为“My Workflow”），可以直接单击该名称进行修改，例如“Hive2-Workflow”。 保存完成后，单击，提交该作业。 作业提交后，可通过Hue界面查看作业的详细信息、日志、进度等相关内容。

问题 Hive创建超过3.2万分区的表，执行带有WHERE分区的条件查询时出现异常。 “metastore.log”中打印的异常信息包含以下信息： Caused by: java.io.IOException: Tried to send an out-of-range integer as a 2-byte value: 32970 at org.postgresql.core.PGStream.SendInteger2(PGStream.java:199) at org.postgresql.core.v3.QueryExecutorImpl.sendParse(QueryExecutorImpl.java:1330) at org.postgresql.core.v3.QueryExecutorImpl.sendOneQuery(QueryExecutorImpl.java:1601) at org.postgresql.core.v3.QueryExecutorImpl.sendParse(QueryExecutorImpl.java:1191) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:346)

问题 使用hbck工具检查Region状态，如果日志中存在“ERROR: (regions region1 and region2) There is an overlap in the region chain.”或者“ERROR: (region region1) Multiple regions have the same startkey: xxx”信息，表示某些region存在overlap的问题，需要如何解决？

回答 使用操作系统命令lsof或者netstat发现大量TCP连接处于CLOSE_WAIT状态，且连接持有者为HBase RegionServer，可能导致网络端口耗尽或HDFS连接超限，那样可能会导致其他服务不稳定。HBase CLOSE_WAIT现象为HBase机制。 HBase CLOSE_WAIT产生原因：HBase数据以HFile形式存储在HDFS上，这里可以叫StoreFiles，HBase作为HDFS的客户端，HBase在创建StoreFile或启动加载StoreFile时创建了HDFS连接，当创建StoreFile或加载StoreFile完成时，HDFS方面认为任务已完成，将连接关闭权交给HBase，但HBase为了保证实时响应，有请求时就可以连接对应数据文件，需要保持连接，选择不关闭连接，所以连接状态为CLOSE_WAIT（需客户端关闭）。 什么时候会创建StoreFile：当HBase执行Flush时。 什么时候执行Flush：HBase写入数据首先会存在内存MemStore，只有内存使用达到阈值或手动执行flush命令时会触发flush操作，将数据写入HDFS。 解决方法： 由于HBase连接机制，如果想减小HBase端口占用，则需控制StoreFile数量，具体可以通过触发HBase的compaction动作完成，即触发HBase文件合并，方法如下： 方法1：使用HBase shell客户端，在客户端手动执行major_compact操作。 方法2：编写HBase客户端代码，调用HBaseAdmin类中的compact方法触发HBase的compaction动作。 如果compact无法解决HBase端口占用现象，说明HBase使用情况已经达到瓶颈，需考虑如下几点： table的Region数初始设置是否合适。 是否存在无用数据。 如果存在无用数据，可删除对应数据以减小HBase存储文件数量，如果以上情况都不满足，则需考虑扩容。

回答 在执行HBase shell期间，JRuby会在“java.io.tmpdir”路径下创建一个临时文件，该路径的默认值为“/tmp”。如果为“/tmp”目录设置NOEXEC权限，然后HBase shell会启动失败并发生“java.lang.UnsatisfiedLinkError: Permission denied”异常。 因此，如果为“/tmp”目录设置了NOEXEC权限，那么“java.io.tmpdir”必须设置为HBASE_OPTS/CLIENT_GC_OPTS中不同的路径。

配置场景 本章节适用于MRS 3.x及后续版本。 数个成品Hadoop集群由于NameNode超负荷运行并失去响应而发生故障。 这种阻塞现象是由于Hadoop的初始设计造成的。在Hadoop中，NameNode作为单独的机器，在其namespace内协调HDFS的各种操作。这些操作包括获取数据块位置，列出目录及创建文件。NameNode接受HDFS的操作，将其视作RPC调用并置入FIFO调用队列，供读取线程处理。虽然FIFO在先到先服务的情况下足够公平，但如果用户执行的I/O操作较多，相比I/O操作较少的用户，将获得更多的服务。在这种情况下，FIFO有失公平并且会导致延迟增加。 图1 基于FIFO调用队列的NameNode请求处理 如果将FIFO队列替换为一种被称作FairCallQueue的新型队列，这种情况就能够得到改善。按照这种方法，FAIR队列会根据调用者的调用规模将传入的RPC调用分配至多个队列中。调度模块会跟踪最新的调用，并为调用量较小的用户分配更高的优先级。 图2 基于FAIRCallQueue的NameNode请求处理

回答 当集群中有超过阈值的节点都被加入黑名单时，黑名单会释放这些节点，其中阈值为故障节点数与集群总节点数的比值。现在每个节点都有其标签表达式，黑名单阈值应根据有效节点标签表达式关联的节点数进行计算，其值为故障节点数与有效节点标签表达式关联的节点数的比值。 假设集群中有100个节点，其中有10个节点为有效节点标签表达式关联的节点（labelA）。其中所有有效节点标签表达式关联的节点都已经故障，黑名单节点释放阈值默认值为0.33，按照传统的计算方式，10/100=0.1，远小于该阈值。这就造成这10个节点永远无法得到释放，Map&Reduce任务一直无法获取节点，应用程序无法正常运行。实际需要根据与Map&Reduce任务的有效节点关联的节点总数进行计算，即10/10=1，大于黑名单节点释放阈值，节点被释放。 因此即使故障节点数与集群总节点数的比值没有超过阈值，也存在黑名单将这些节点释放的情况。

配置场景 当Yarn本地目录和DataNode目录配置在同一个磁盘时，具有较大容量的磁盘可以运行更多的任务，因此将有更多的中间数据存储在Yarn本地目录。 目前DataNode支持通过配置“dfs.datanode.du.reserved”来配置预留磁盘空间大小。配置较小的数值不能满足更大的磁盘要求。但对于更小的磁盘配置更大的数值将浪费大量的空间。 为了避免这种情况，添加一个新的参数“dfs.datanode.du.reserved.percentage”来配置预留磁盘空间占总磁盘空间大小的百分比，那样可以基于总的磁盘空间来预留磁盘百分比。 如果用户同时配置“dfs.datanode.du.reserved.percentage”和“dfs.datanode.du.reserved”，则采用这两个参数较大的数值作为DataNode的预留空间大小。 建议基于磁盘空间设置“dfs.datanode.du.reserved”或者“dfs.datanode.du.reserved.percentage”。

配置描述 请参考修改集群服务配置参数，进入HDFS的“全部配置”页面，在搜索框中输入参数名称。 表1 参数说明 参数 描述 默认值 dfs.disk.balancer.auto.enabled 是否开启自动执行HDFS DiskBalancer特性。默认值为“false”，表示关闭该特性。 false dfs.disk.balancer.auto.cron.expression HDFS 磁盘均衡操作的CRON表达式，用于控制均衡操作的开始时间。仅当dfs.disk.balancer.auto.enabled设置为true时才有效。默认值“0 1 * * 6”表示在每周六的1点执行任务。表达式的具体含义可参见表2。 0 1 * * 6 dfs.disk.balancer.max.disk.throughputInMBperSec 执行磁盘数据均衡时可使用的最大磁盘带宽。单位为MB/s，默认值为10，可依据集群的实际磁盘条件设置。 10 dfs.disk.balancer.max.disk.errors 设置能够容忍的在指定的移动过程中出现的最大错误次数，超过此阈值则移动失败。 5 dfs.disk.balancer.block.tolerance.percent 设置磁盘之间进行数据均衡操作时，各个磁盘的数据存储量与理想状态之间的差异阈值。例如，各个磁盘的理想数据存储量为1TB，此参数设置为10。那么，当目标磁盘的数据存储量达到900GB时，就认为该磁盘的存储状态就已经足够好了。取值范围[1-100]。 10 dfs.disk.balancer.plan.threshold.percent 设置在磁盘数据均衡中可容忍的两磁盘之间的数据密度阈值差。如果任意两个磁盘数据密度差值的绝对值超过了此阈值，意味着对应的磁盘应该进行数据均衡。取值范围[1-100]。 10 dfs.disk.balancer.top.nodes.number 该参数用来指定集群中需要执行磁盘数据均衡的Top N 节点。 5 表2为HDFS磁盘均衡操作的CRON表达式。使用此功能时，需要先将参数dfs.disk.balancer.auto.enabled设置为true。其它参数依据集群状况设置。 表2 CRON表达式解释 列 说明 第1列 分钟，参数值为0~59。 第2列 小时，参数值为0~23。 第3列 日期，参数值为1~31。 第4列 月份，参数值为1~12。 第5列 星期，参数值为0~6，0表示星期日。

回答 由于在删除了大量文件之后，DataNode需要时间去删除对应的Block。当立刻重启NameNode时，NameNode会去检查所有DataNode上报的Block信息，发现已删除的Block时，会输出对应的INFO日志信息，如下所示： 2015-06-10 19:25:50,215 | INFO | IPC Server handler 36 on 25000 | BLOCK* processReport: blk_1075861877_2121067 on node 10.91.8.218:9866 size 10249 does not belong to any file | org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.processReport(BlockManager.java:1854) 每一个被删除的Block会产生一条日志信息，一个文件可能会存在一个或多个Block。当删除的文件数过多时，NameNode会花大量的时间打印日志，然后导致NameNode启动慢。 当出现这种现象时，您可以通过如下方式提升NameNode的启动速度。 删除大量文件时，不要立刻重启NameNode，待DataNode删除了对应的Block后重启NameNode，即不会存在这种情况。 您可以通过hdfs dfsadmin -report命令来查看磁盘空间，检查文件是否删除完毕。 如已大量出现以上日志，您可以将NameNode的日志级别修改为ERROR，NameNode不会再打印此日志信息。 等待NameNode启动完毕后，再将此日志级别修改为INFO。修改日志级别后无需重启服务。

配置描述 请参考修改集群服务配置参数，进入HDFS的“全部配置”页面，在搜索框中输入参数名称。 表1 NameNode blacklisting的相关参数 参数 描述 默认值 dfs.client.failover.proxy.provider.[nameservice ID] 利用已通过的协议创建namenode代理的Client Failover proxy provider类。 将参数值设置为“org.apache.hadoop.hdfs.server.namenode.ha.BlackListingFailoverProxyProvider”， 可使用从NameNode支持读的特性。 org.apache.hadoop.hdfs.server.namenode.ha.AdaptiveFailoverProxyProvider

问题 HDFS调用FileInputFormat的getSplit方法的时候，出现ArrayIndexOutOfBoundsException: 0，日志如下： java.lang.ArrayIndexOutOfBoundsException: 0at org.apache.hadoop.mapred.FileInputFormat.identifyHosts(FileInputFormat.java:708)at org.apache.hadoop.mapred.FileInputFormat.getSplitHostsAndCachedHosts(FileInputFormat.java:675)at org.apache.hadoop.mapred.FileInputFormat.getSplits(FileInputFormat.java:359)at org.apache.spark.rdd.HadoopRDD.getPartitions(HadoopRDD.scala:210)at org.apache.spark.rdd.RDD$$anonfun$partitions$2.apply(RDD.scala:239)at org.apache.spark.rdd.RDD$$anonfun$partitions$2.apply(RDD.scala:237)at scala.Option.getOrElse(Option.scala:120)at org.apache.spark.rdd.RDD.partitions(RDD.scala:237)at org.apache.spark.rdd.MapPartitionsRDD.getPartitions(MapPartitionsRDD.scala:35)

回答 原因分析 NameNode的主节点重启后，之前在ZooKeeper上建立的临时节点（/hadoop-ha/hacluster/ActiveStandbyElectorLock）就会被清理。同时，NameNode备节点发现该信息后进行抢占希望升主，所以它重新在ZooKeeper上建立了active的节点/hadoop-ha/hacluster/ActiveStandbyElectorLock。但是NameNode备节点通过客户端（ZKFC）与ZooKeeper建立连接时，由于网络问题、CPU使用率高、集群压力大等原因，出现了客户端（ZKFC）的session（0x144cb2b3e4b36ae4）与ZooKeeper服务端的session（0x164cb2b3e4b36ae4）不一致的问题，导致NameNode备节点的watcher没有感知到自己已经成功建立临时节点，依然认为自己还是备。 而NameNode主节点启动后，发现/hadoop-ha/hacluster目录下已经有active的节点，所以也无法升主，导致两个节点都为备。 解决方法 建议通过在FusionInsight Manager界面上重启HDFS的两个ZKFC加以解决。