华为云用户手册

操作场景 本章节适用于 MRS 3.x及后续版本。 HDFS集群可能出现DataNode节点间磁盘利用率不平衡的情况，比如集群中添加新数据节点的场景。如果HDFS出现数据不平衡的状况，可能导致多种问题，比如MapReduce应用程序无法很好地利用本地计算的优势、数据节点之间无法达到更好的网络带宽使用率或节点磁盘无法利用等等。所以MRS集群管理员需要定期检查并保持DataNode数据平衡。 HDFS提供了一个容量均衡程序Balancer。通过运行这个程序，可以使得HDFS集群达到一个平衡的状态，使各DataNode磁盘使用率与HDFS集群磁盘使用率的偏差不超过阈值。图1和图2分别是Balance前后DataNode的磁盘使用率变化。 图1 执行均衡操作前DataNode的磁盘使用率 图2 执行均衡操作后DataNode的磁盘使用率 均衡操作时间估算受两个因素影响： 需要迁移的总数据量： 每个DataNode节点的数据量应大于（平均使用率-阈值）*平均数据量，小于（平均使用率+阈值）*平均数据量。若实际数据量小于最小值或大于最大值即存在不平衡，系统选择所有DataNode节点中偏差最多的数据量作为迁移的总数据量。 Balancer的迁移是按迭代（iteration）方式串行顺序处理的，每个iteration迁移数据量不超过10GB，每个iteration重新计算使用率的情况。 因此针对集群情况，可以大概估算每个iteration耗费的时间（可以通过执行Balancer的日志观察到每次iteration的时间），并用总数据量除以10GB估算任务执行时间。 由于按iteration处理，Balancer可以随时启动或者停止。

答案 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全局的默认分割符，如果作业的转换步骤中配置了分割符，则以转换步骤为准，转换步骤中没有配置分割符则以此处的默认分割符为准。

操作步骤 以客户端安装用户，登录安装客户端的节点。 执行以下命令，切换到客户端安装目录。 cd /opt/client 执行以下命令配置环境变量。 source bigdata_env 执行以下命令，进行用户认证。（普通模式跳过此步骤） kinit 组件业务用户 执行以下命令切换到Kafka客户端安装目录。 cd Kafka/kafka/bin 执行以下命令使用客户端工具查看帮助并使用。 ./kafka-console-consumer.sh：Kafka消息读取工具 ./kafka-console-producer.sh：Kafka消息发布工具 ./kafka-topics.sh：Kafka Topic管理工具

回答 可能原因一：配置项“delete.topic.enable”未配置为“true”，只有配置为“true”才能执行真正删除。 可能原因二：“auto.create.topics.enable”配置为“true”，其他应用程序有使用该Topic，并且一直在后台运行。 解决方法： 针对原因一：配置页面上将“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低版本环境升级上来的，升级完成之后可不进行设置。

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

回答 默认情况下，可以在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中操作本地文件。

回答 通常，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加以解决。

解决方法 找到重启前的主NameNode，进入其数据目录（查看配置项“dfs.namenode.name.dir”可获取，例如/srv/BigData/namenode/current），得到最新的FSImage文件的序号。一般如下： 查看各JournalNode的数据目录（查看配置项“dfs.journalnode.edits.dir”可获取，例如/srv/BigData/journalnode/hacluster/current），查看序号从第一部获取到的序号开始的edits文件，看是否有不连续的情况（即前一个edits文件的最后一个序号 和 后一个edits文件的第一个序号 不是连续的，如下图中的edits_0000000000013259231-0000000000013259237就和后一个edits_0000000000013259239-0000000000013259246就是不连续的）。 如果有这种不连续的edits文件，则需要查看其它的JournalNode的数据目录或NameNode数据目录中，有没有连续的该序号相关的连续的edits文件。如果可以找到，复制一个连续的片段到该JournalNode。 如此把所有的不连续的edits文件全部都修复。 重启NameNode，观察是否成功。如还是失败，请联系技术支持。

回答 目前出现上述问题时使用的是默认配置，如表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

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

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

回答 当用户在distcp命令中使用webhdfs://时，会抛出上述异常，是由于集群所使用的HTTP政策为HTTPS，即配置在“hdfs-site.xml”（文件路径为“客户端安装目录/HDFS/hadoop/etc/hadoop”）的“dfs.http.policy”值为“HTTPS_ONLY”。所以要避免出现此异常，应使用swebhdfs://替代webhdfs://。 例如： ./hadoop distcp swebhdfs://IP:PORT/testfile hdfs://IP:PORT/testfile1

回答 当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调用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)

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

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

配置场景 DiskBalancer是一个在线磁盘均衡器，旨在根据各种指标重新平衡正在运行的DataNode上的磁盘数据。工作方式与HDFS的Balancer工具类似。不同的是，HDFS Balancer工具用于DataNode节点间的数据均衡，而HDFS DiskBalancer用于单个DataNode节点上各磁盘之间的数据均衡。 长时间运行的集群会因为曾经删除过大量的文件，或者集群中的节点做磁盘扩容等操作导致节点上出现磁盘间数据不均衡的现象。磁盘间数据不均衡会引起HDFS整体并发读写性能的下降或者因为不恰当的HDFS写策略导致业务故障。此时需要平衡节点磁盘间的数据密度，防止异构的小磁盘成为该节点的性能瓶颈。 本章节适用于MRS 3.x及后续版本。

配置描述 请参考修改集群服务配置参数，进入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 使用此功能时，需要先将参数dfs.disk.balancer.auto.enabled设置为true，并配置合理的CRON表达式。其它参数依据集群状况设置。 表2 CRON表达式解释 列 说明 第1列 分钟，参数值为0~59。 第2列 小时，参数值为0~23。 第3列 日期，参数值为1~31。 第4列 月份，参数值为1~12。 第5列 星期，参数值为0~6，0表示星期日。

多余块副本删除选择 如果块副本数超过参数“dfs.replication”值（即用户指定的文件副本数，可以参考修改集群服务配置参数进入HDFS服务全部配置页面，搜索对应参数查看），hdfs会删除多余块副本来保证集群资源利用率。 删除规则如下： 优先删除不满足任何表达式的副本。 示例：文件默认副本数为3 /test标签表达式为“LA[replica=1],LB[replica=1],LC[replica=1]”， /test文件副本分布的四个节点（D1～D4）以及对应标签（LA～LD）： D1:LAD2:LBD3:LCD4:LD 则选择删除D4节点上的副本块。 如果所有副本都满足表达式，删除多于表达式指定的数量的副本。 示例：文件默认副本数为3 /test标签表达式为“LA[replica=1],LB[replica=1],LC[replica=1]”， /test文件副本分布的四个节点以及对应标签： D1:LAD2:LAD3:LBD4:LC 则选择删除D1或者D2上的副本块。 如果文件所有者或文件所有者的组不能访问某个标签，则优先删除映射到该标签的DataNode中的副本。

配置描述 Datanode节点标签配置 请参考修改集群服务配置参数，进入HDFS的“全部配置”页面，在搜索框中输入参数名称。 表1 参数说明 参数 描述 默认值 dfs.block.replicator.classname 配置HDFS的DataNode原则策略。 如果需要开启NodeLabeNodel功能，需要将该值设置为org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicyWithNodeLabel。 org.apache.hadoop.hdfs.server.blockmanagement.AvailableSpaceBlockPlacementPolicy host2tags 配置DataNode主机与标签的对应关系。 主机名称支持配置IP扩展表达式（如192.168.1.[1-128]或者192.168.[2-3].[1-128]，且IP必须为业务IP），或者为前后加上 / 的主机名的正则表达式（如/datanode-[123]/或者/datanode-\d{2}/）。标签配置名称不允许包含 = / \ 字符。【注意】配置IP时必须是业务IP。 - host2tags配置项内容详细说明： 假如有一套集群，有20个Datanode：dn-1到dn-20，对应的IP地址为10.1.120.1到10.1.120.20，host2tags配置文件内容可以使用如下的表示方式。 主机名正则表达式 “/dn-\d/ = label-1”表示dn-1到dn-9对应的标签为label-1，即dn-1 = label-1，dn-2 = label-1，...dn-9 = label-1。 “/dn-((1[0-9]$)|(20$))/ = label-2”表示dn-10到dn-20对应的标签为label-2，即dn-10 = label-2，dn-11 = label-2，...dn-20 = label-2。 IP地址范围表示方式 “10.1.120.[1-9] = label-1”表示10.1.120.1到10.1.120.9对应的标签为label-1，即10.1.120.1 = label-1，10.1.120.2 = label-1，...10.1.120.9 = label-1。 “10.1.120.[10-20] = label-2”表示10.1.120.10到10.1.120.20对应的标签为label-2，即10.1.120.10 = label-2，10.1.120.11 = label-2，...10.1.120.20 = label-2。 基于标签的数据块摆放策略支持扩容减容场景： 当集群中新增加DataNode节点时，如果该DataNode对应的IP匹配host2tags配置项中的IP地址范围，或者该DataNode的主机名匹配host2tags配置项中的主机名正则表达式，则该DataNode节点会被设置成对应的标签。 例如“host2tags”配置值为10.1.120.[1-9] = label-1，而当前集群只有10.1.120.1到10.1.120.3三个数据节点。进行扩容后，又添加了10.1.120.4这个数据节点，则该数据节点会被设置成label-1的标签；如果10.1.120.3这个数据节点被删除或者退出服务后，数据块不会再被分配到该节点上。 设置目录/文件的标签表达式 在HDFS参数配置页面配置“path2expression”，配置HDFS目录与标签的对应关系。当配置的HDFS目录不存在时，也可以配置成功，新建不存在的同名目录，已设置的标签对应关系将在30分钟之内被继承。设置了标签的目录被删除后，新增一个同名目录，原有的对应关系也将在30分钟之内被继承。 命令行设置方式请参考hdfs nodelabel -setLabelExpression命令。 Java API设置方式通过NodeLabelFileSystem实例化对象调用setLabelExpression(String src, String labelExpression)方法。src为HDFS上的目录或文件路径，“labelExpression”为标签表达式。 开启NodeLabel特性后，可以通过命令hdfs nodelabel -listNodeLabels查看每个Datanode的标签信息。

基于标签的数据块摆放策略样例 假如有一套集群，有六个DataNode：dn-1，dn-2，dn-3，dn-4，dn-5以及dn-6，对应的IP为10.1.120.[1-6]。有六个目录需要配置标签表达式，Block默认备份数为3。 下面给出3种DataNode标签信息在“host2labels”文件中的表示方式，其作用是一样的。 主机名正则表达式 /dn-[1456]/ = label-1,label-2/dn-[26]/ = label-1,label-3/dn-[3456]/ = label-1,label-4/dn-5/ = label-5 IP地址范围表示方式 10.1.120.[1-6] = label-110.1.120.1 = label-210.1.120.2 = label-310.1.120.[3-6] = label-410.1.120.[4-6] = label-210.1.120.5 = label-510.1.120.6 = label-3 普通的主机名表达式 /dn-1/ = label-1, label-2/dn-2/ = label-1, label-3/dn-3/ = label-1, label-4/dn-4/ = label-1, label-2, label-4/dn-5/ = label-1, label-2, label-4, label-5/dn-6/ = label-1, label-2, label-3, label-4 目录的标签表达式设置结果如下： /dir1 = label-1/dir2 = label-1 && label-3/dir3 = label-2 || label-4[replica=2]/dir4 = (label-2 || label-3) && label-4/dir5 = !label-1/sdir2.txt = label-1 && label-3[replica=3,fallback=NONE]/dir6 = label-4[replica=2],label-2 标签表达式设置方式请参考hdfs nodelabel -setLabelExpression命令。 文件的数据块存放结果如下： “/dir1”目录下文件的数据块可存放在dn-1，dn-2，dn-3，dn-4，dn-5和dn-6六个节点中的任意一个。 “/dir2”目录下文件的数据块可存放在dn-2和dn-6节点上。Block默认备份数为3，表达式只匹配了两个DataNode节点，第三个副本会在集群上剩余的节点中选择一个DataNode节点存放。 “/dir3”目录下文件的数据块可存放在dn-1，dn-3，dn-4，dn-5和dn-6中的任意三个节点上。 “/dir4”目录下文件的数据块可存放在dn-4，dn-5和dn-6。 “/dir5”目录下文件的数据块没有匹配到任何一个DataNode，会从整个集群中任意选择三个节点存放（和默认选块策略行为一致）。 “/sdir2.txt”文件的数据块，两个副本存放在dn-2和dn-6节点上，虽然还缺失一个备份节点，但由于使用了fallback=NONE参数，所以只存放两个备份。 “/dir6”目录下文件的数据块在具备label-4的节点中选择2个节点(dn-3 -- dn-6)，然后在label-2中选择一个节点，如果用户指定“/dir6”下文件副本数大于3，则多出来的副本均在label-2。

块副本位置选择 Nodelabel支持对各个副本的摆放采用不同的策略，如表达式“label-1,label-2,label-3”，表示3个副本分别放到含有label-1、label-2、label-3的DataNode中，不同的副本策略用逗号分隔。 如果label-1，希望放2个副本，可以这样设置表达式：“label-1[replica=2],label-2,label-3”。这种情况下，如果默认副本数是3，则会选择2个带有label-1和一个label-2的节点；如果默认副本数是4，会选择2个带有label-1、一个label-2以及一个label-3的节点。可以注意到，副本数是从左到右依次满足各个副本策略的，但也有副本数超过表达式表述的情况，当默认副本数为5时，多出来的一个副本会放到最后一个节点中，也就是label-3的节点里。 当启用ACLs功能并且用户无权访问表达式中使用的标签时，将不会为副本选择属于该标签的DataNode。

配置场景 在配置了HA的HDFS集群中，存在一个主NameNode和一个备NameNode。主NameNode处理所有的客户端请求，备NameNode保持最新的元数据信息和块位置信息。但是在这种架构存在一个缺点：主NameNode会成为客户端请求处理的瓶颈，在请求繁忙的集群中表现更为明显。 为了解决主NameNode的瓶颈问题，引入了一个新状态的NameNode：从NameNode。从NameNode类似于备NameNode，也保持着最新的元数据信息和块位置信息。除此之外，从NameNode也可以像主NameNode一样处理客户端的读请求。由于在典型的HDFS集群中，读请求占大多数，因此从NameNode支持读可以降低主NameNode的负载，提高集群处理能力。 本章节适用于MRS 3.x及后续版本。

配置场景 用户需要通过数据特征灵活配置HDFS文件数据块的存储节点。通过设置HDFS目录/文件对应一个标签表达式，同时设置每个Datanode对应一个或多个标签，从而给文件的数据块存储指定了特定范围的Datanode。 当使用基于标签的数据块摆放策略，为指定的文件选择DataNode节点进行存放时，会根据文件的标签表达式选择出Datanode节点范围，然后在这些Datanode节点范围内，选择出合适的存放节点。 本章节适用于MRS 3.x及后续版本。 开启单集群跨AZ高可用后，不支持配置HDFS NodeLabel功能。 场景1 DataNodes分区场景。 场景说明： 用户需要让不同的应用数据运行在不同的节点，分开管理，就可以通过标签表达式，来实现不同业务的分离，指定业务存放到对应的节点上。 通过配置NodeLabel特性使得： /HBase下的数据存储在DN1、DN2、DN3、DN4节点上。 /Spark下的数据存储在DN5、DN6、DN7、DN8节点上。 图1 DataNode分区场景 通过hdfs nodelabel -setLabelExpression -expression 'LabelA[fallback=NONE]' -path /Hbase命令，给Hbase目录设置表达式。从图1中可知，“/Hbase”文件的数据块副本会被放置在有LabelA标签的节点上，即DN1、DN2、DN3、DN4。同理，通过hdfs nodelabel -setLabelExpression -expression 'LabelB[fallback=NONE]' -path /Spark命令，给Spark目录设置表达式。在“/Spark”目录下文件对应的数据块副本只能放置到LabelB标签上的节点，如DN5、DN6、DN7、DN8。 设置数据节点的标签参考配置描述。 如果同一个集群上存在多个机架，每个标签下可以有多个机架的datanodes，以确保数据块摆放的可靠性。 场景2 多机架下指定副本位置场景 场景说明： 在异构集群中，客户需要分配一些特定的具有高可靠性的节点用以存放重要的商业数据，可以通过标签表达式指定副本位置，指定文件数据块的其中一个副本存放到高可靠性的节点上。 “/data”目录下的数据块，默认三副本情况下，其中至少有一个副本会被存放到RACK1或RACK2机架的节点上（RACK1和RACK2机架的节点为高可靠性节点），另外两个副本会被分别存放到RACK3和RACK4机架的节点上。 图2 场景样例 通过 hdfs nodelabel -setLabelExpression -expression 'LabelA||LabelB[fallback=NONE],LabelC,LabelD' -path /data命令给“/data”目录设置表达式。 当向“/data”目录下写数据时，至少有一个数据块副本存放在LabelA或者LabelB标签的节点中，剩余的两个数据块副本会被存放在有LabelC和LabelD标签的节点上。

配置描述 请参考修改集群服务配置参数，进入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表示星期日。