华为云用户手册

前提条件 Loader和Oozie组件及客户端已经安装，并且正常运行。 已创建或获取访问Oozie服务的人机用户账号及密码。 该用户需要从属于hadoop、supergroup、hive组，同时添加Oozie的角色操作权限。如果使用Hive多实例，该用户还需要从属于具体的Hive实例组，如hive3。 用户同时还需要至少有manager_viewer权限的角色。 获取运行状态的Oozie服务器（任意实例）URL，如“https://10.1.130.10:21003/oozie”。 获取运行状态的Oozie服务器主机名，如“10-1-130-10”。 获取Yarn ResourceManager主节点IP，如10.1.130.11。 创建需要调度的Loader作业，并获取该作业ID。

操作步骤 以客户端安装用户，登录安装Oozie客户端的节点。 执行以下命令，获取安装环境信息。其中“/opt/client”为客户端安装路径，该操作的客户端目录只是举例，请根据实际安装目录修改。 source /opt/client/bigdata_env 判断集群认证模式。 安全模式，执行kinit命令进行用户认证。 例如，使用oozieuser用户进行认证。 kinit oozieuser 普通模式，执行4。 执行以下命令，进入样例目录。 cd /opt/client/Oozie/oozie-client-*/examples/apps/sqoop/ 该目录下需关注文件如表1所示。 表1 文件说明 文件名称 描述 job.properties 工作流的参数变量定义文件。 workflow.xml 工作流的规则定制文件。 执行以下命令，编辑“job.properties”文件。 vi job.properties 修改如下内容： 更改“userName”的参数值为提交任务的人机用户名，例如“userName=oozieuser”。 执行以下命令，编辑“workflow.xml”文件。 vi workflow.xml 修改如下内容： “command”的值修改为需要调度的已有Loader作业ID，例如1。 将“workflow.xml”文件上传至 "job.properties" 文件中的HDFS路径。 hdfs dfs -put -f workflow.xml /user/userName/examples/apps/sqoop 执行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界面中，可在页面表格根据jobid查看已提交的工作流信息。

前提条件 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”查看已提交的工作流信息。

操作步骤 以客户端安装用户，登录安装Oozie客户端的节点。 执行以下命令，获取安装环境信息。其中“/opt/client”为客户端安装路径，该操作的客户端目录只是举例，请根据实际安装目录修改。 source /opt/client/bigdata_env 判断集群认证模式。 安全模式，执行kinit命令进行用户认证。 例如，使用oozieuser用户进行认证。 kinit oozieuser 普通模式，执行4。 执行以下命令，进入样例目录。 cd /opt/client/Oozie/oozie-client-*/examples/apps/hive/ 该目录下需关注文件如表1所示。 表1 文件说明 文件名称 描述 hive-site.xml Hive任务的配置文件。 job.properties 工作流的参数变量定义文件。 script.q Hive任务的SQL脚本。 workflow.xml 工作流的规则定制文件。 执行以下命令，编辑“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界面中，可在页面表格根据jobid查看已提交的工作流信息。

操作场景 该任务指导用户在使用Oozie客户端提交Hive任务 Hive任务有如下类型： Hive作业 使用JDBC方式连接的Hive作业。 Hive2作业 使用Beeline方式连接的Hive作业。 本文以使用Oozie客户端提交Hive作业为例介绍。 使用Oozie客户端提交Hive2作业与提交Hive作业操作步骤一致，只需将操作步骤中对应路径的“/Hive”改成“/Hive2”即可。 例如，Hive作业运行目录“/opt/client/Oozie/oozie-client-*/examples/apps/hive/”，则Hive2对应的运行目录为“/opt/client/Oozie/oozie-client-*/examples/apps/hive2/”。 建议下载使用最新版本的客户端。

前提条件 Hive和Oozie组件及客户端已经安装，并且正常运行。 已创建或获取访问Oozie服务的人机用户账号及密码。 该用户需要从属于hadoop、supergroup、hive组，同时添加Oozie的角色操作权限。如果使用Hive多实例，该用户还需要从属于具体的Hive实例组，如hive3。 用户同时还需要至少有manager_viewer权限的角色。 获取运行状态的Oozie服务器（任意实例）URL，如“https://10.1.130.10:21003/oozie”。 获取运行状态的Oozie服务器主机名，如“10-1-130-10”。 获取Yarn ResourceManager主节点IP，如10.1.130.11。

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

回答 这是性能规格的问题，MapReduce任务运行失败的根本原因是由于ApplicationMaster的内存溢出导致的，即物理内存溢出导致被NodeManager kill。 解决方案： 将ApplicationMaster的内存配置调大，在客户端“客户端安装路径/Yarn/config/mapred-site.xml”配置文件中优化如下参数： “yarn.app.mapreduce.am.resource.mb” “yarn.app.mapreduce.am.command-opts”，该参数中-Xmx值建议为0.8*“yarn.app.mapreduce.am.resource.mb”

回答 当运行任务时，将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”。

回答 因为ResourceManager HA已启用，但是Work-preserving RM restart功能未启用。 如果Work-preserving RM restart功能未启用，ResourceManager切换时container会被kill，然后导致Application Master超时。Work-preserving RM restart功能介绍请参见： MRS 3.2.0之前版本：http://hadoop.apache.org/docs/r3.1.1/hadoop-yarn/hadoop-yarn-site/ResourceManagerRestart.html MRS 3.2.0及之后版本：https://hadoop.apache.org/docs/r3.3.1/hadoop-yarn/hadoop-yarn-site/ResourceManagerRestart.html

答案 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创建分区列、分区表。

参数说明 表1 Loader常用参数 配置参数 说明 默认值 范围 mapreduce.client.submit.file.replication MapReduce任务在运行时依赖的相关job文件在HDFS上的副本数。当集群中DataNode个数小于该参数值时，副本数等于DataNode的个数。当DataNode个数大于或等于该参数值，副本数为该参数值。 10 3～256 loader.fault.tolerance.rate 容错率。 值大于0时使能容错机制。使能容错机制时建议将作业的Map数设置为大于等于3，推荐在作业数据量大的场景下使用。 0 0～1.0 loader.input.field.separator 默认的输入字段分隔符，需要配置输入与输出转换步骤才生效，转换步骤的内容可以为空；如果作业的转换步骤中没有配置分隔符，则以此处的默认分隔符为准。 , - loader.input.line.separator 默认的输入行分隔符，需要配置输入与输出转换步骤才生效，转换步骤的内容可以为空；如果作业的转换步骤中没有配置分隔符，则以此处的默认分隔符为准。 - - loader.output.field.separator 默认的输出字段分隔符，需要配置输入与输出转换步骤才生效，转换步骤的内容可以为空；如果作业的转换步骤中没有配置分隔符，则以此处的默认分隔符为准。 , - loader.output.line.separator Loader输出数据的行分隔符。 - - 由于容错率的统计需要时间，为保证使用效果，建议在作业运行时间在2分钟以上时使用“loader.fault.tolerance.rate”参数。 此处参数设置的为Loader全局的默认分隔符，如果作业的转换步骤中配置了分隔符，则以转换步骤为准，转换步骤中没有配置分隔符则以此处的默认分隔符为准。

回答 可能原因一：配置项“delete.topic.enable”未配置为“true”，只有配置为“true”才能执行真正删除。 可能原因二：“auto.create.topics.enable”配置为“true”，其他应用程序有使用该Topic，并且一直在后台运行。 解决方法： 针对原因一：登录Manager，在Kafka配置页面上将“delete.topic.enable”设置为“true”。 针对原因二：先停掉后台使用该Topic的应用程序，或者“auto.create.topics.enable”配置为“false”（需要重启Kafka服务），然后再做删除操作。

问题 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)

操作场景 此功能适用于Hive组件。 按如下操作步骤设置参数后，在未安装HBase的环境执行Hive on Spark任务时，可避免任务卡顿。 Hive on Spark任务的Spark内核版本已经升级到Spark2x，可以支持在不安装Spark2x的情况下，执行Hive on Spark任务。如果没有安装HBase，默认在执行Spark任务时，会尝试去连接Zookeeper访问HBase，直到超时，这样会造成任务卡顿。 在未安装HBase的环境，要执行Hive on Spark任务，可以按如下操作处理。如果是从已有HBase低版本环境升级上来的，升级完成之后可不进行设置。

回答 默认情况下，可以在UDF中用文件的相对路径来操作文件，如下示例代码： public String evaluate(String text) { // some logic File file = new File("foo.txt"); // some logic // do return here } 在Hive中使用时，将UDF中用到的文件“foo.txt”上传到HDFS上，如上传到“hdfs://hacluster/tmp/foo.txt”，使用以下语句创建UDF，在UDF中就可以直接操作“foo.txt”文件了： create function testFunc as 'some.class' using jar 'hdfs://hacluster/somejar.jar', file 'hdfs://hacluster/tmp/foo.txt'; 例外情况下，如果“hive.fetch.task.conversion”参数的值为“more”，在UDF中不能再使用相对路径来操作文件，而要使用绝对路径，并且保证所有的HiveServer节点和NodeManager节点上该文件是存在的且omm用户对该文件有相应的权限，才能正常在UDF中操作本地文件。

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

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

配置Hive UDF 用户通过在配置文件“udf.properties”中添加注册信息来注册Hive UDF，需按“函数名称 类路径”格式添加每一行内容： 以“udf.properties” 为例，已明确要注册的四个Hive UDF： booleanudf io.hetu.core.hive.dynamicfunctions.examples.udf.BooleanUDF shortudf io.hetu.core.hive.dynamicfunctions.examples.udf.ShortUDF byteudf io.hetu.core.hive.dynamicfunctions.examples.udf.ByteUDF intudf io.hetu.core.hive.dynamicfunctions.examples.udf.IntUDF 如果用户添加的Hive UDF注册信息有误，比如错误的格式或者不存在的类路径，系统将忽略这些错误的注册信息，并打印相应日志。 如果用户注册重复的Hive UDF，系统将只注册一次，并忽略重复的注册。 如果用户注册的Hive UDF与系统内部注册的相同，系统将会发生异常并无法正常启动。解决该异常需要用户删除对应的Hive UDF注册信息。

资源组使用场景 通过资源组可以实现计算实例内的资源管理。对不同用户、不同查询分配不同的资源组，可以起到资源隔离的作用，避免单个用户或查询独占计算实例的资源，也能通过资源组之间的权重优先级配置保障重要任务优先执行。典型资源组使用场景如表1所示。 表1 典型资源组使用场景 典型场景 解决方案 随着使用计算实例的业务团队的增加，当某个团队的任务更加重要并且不想执行查询时没有资源。 每个团队分配一个指定的资源组；重要任务分配到资源较多的资源组；保证子资源组的占比和小于等于100%时，可保证某一个队列的资源不被其他资源组抢占，类似于静态化分资源。 当实例资源负载很高时，两个用户同时提交一个查询。一开始，两个查询都在排队。当有空闲资源时，可以调度特定用户的查询首先获取到资源。 两个用户分配不同的资源组，重要的任务可以分配到权重高或优先级高的资源组，调度策略由schedulingPolicy配置，不同的调度策略，会有不同的资源分配顺序。 对于即席查询和批量查询，可以根据不同的SQL类型进行更合理的资源分配。 可以对不同的查询类型，比如EXPLAIN、INSERT、SELECT和DATA_DEFINITION等类型，匹配到不同的资源组，分配不同的资源来执行查询。

前提条件 集群已安装HetuEngine、Hive服务及其所依赖的服务（DBService、KrbServer、Zookeeper、HDFS、Yarn、MapReduce）且运行正常。 如集群已启用Kerberos认证，需提前创建HetuEngine的用户并授予相关权限，具体操作请参见创建HetuEngine权限角色。且需要通过Ranger为该用户配置操作数据源的数据库、表、列的管理权限，具体操作请参考添加HetuEngine的Ranger访问权限策略。 已安装集群客户端，例如安装目录为“/opt/client”。

回答 通常，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”文件。

回答 原因分析 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加以解决。

问题 为什么在往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)

回答 “dfs.datanode.data.dir”配置项用于指定数据块在DataNode上的存储目录，在系统安装时需要指定根目录，并且可以指定多个根目录。 请谨慎修改该配置项，可以添加新的数据根目录。 禁止删除原有存储目录，否则会造成数据块丢失，导致文件无法正常读写。 禁止手动删除或修改存储目录下的数据块，否则可能会造成数据块丢失。 NameNode和JournalNode存在类似的配置项，也同样禁止删除原有存储目录，禁止手动删除或修改存储目录下的数据块。 dfs.namenode.edits.dir dfs.namenode.name.dir dfs.journalnode.edits.dir

回答 目前出现上述问题时使用的是默认配置，如表1所示，HDFS客户端到NameNode的RPC连接存在keep alive机制，保持连接不会超时，尽力等待服务器的响应，因此导致已经连接的HDFS客户端的操作会长时间无响应。 对于已经长时间无响应的HDFS客户端，可以进行如下操作： 等待NameNode响应，一旦NameNode所在节点的CPU利用率回落，NameNode可以重新获得CPU资源时，HDFS客户端即可得到响应。 如果无法等待更长时间，需要重启HDFS客户端所在的应用程序进程，使得HDFS客户端重新连接空闲的NameNode。 解决措施： 为了避免该问题出现，可以在“客户端安装路径/HDFS/hadoop/etc/hadoop/core-site.xml”中做如下配置。 表1 参数说明 参数 描述 默认值 ipc.client.ping 当配置为true时，客户端会尽力等待服务端响应，定期发送ping消息，使得连接不会因为tcp timeout而断开。 当配置为false时，客户端会使用配置项“ipc.ping.interval”对应的值，作为timeout时间，在该时间内没有得到响应，即会超时。 在上述问题场景下，建议配置为false。 true ipc.ping.interval 当“ipc.client.ping”配置为true时，表示发送ping消息的周期。 当“ipc.client.ping”设置为false时，表示连接的超时时间。 在上述问题场景下，建议配置一个较大的超时时间，避免服务繁忙时的超时，建议配置为900000，单位为ms。 60000

问题 HDFS调用FileInputFormat的getSplit方法的时候，出现ArrayIndexOutOfBoundsException: 0，日志如下： java.lang.ArrayIndexOutOfBoundsException: 0 at 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)

回答 由于断电，当写操作完成之后，缓存中的block不会立即被写入磁盘，如果要同步地将缓存的block写入磁盘，用户需要将“客户端安装路径/HDFS/hadoop/etc/hadoop/hdfs-site.xml”中的“dfs.datanode.synconclose”设置为“true”。 默认情况下，“dfs.datanode.synconclose”为“false”，虽然性能很高，但是断电之后，存储在缓存中的数据会丢失。将“dfs.datanode.synconclose”设置为“true”，可以解决此问题，但对性能有很大影响。请根据具体的应用场景决定是否开启该参数。

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