排错

20260326 HDFS更改数据目录导致NameNode无法启动 问题描述： 由于一开始硬盘还未挂载目录，安装cdh时，配置hdfs相关数据目录就用了默认的系统盘下的目录，如下 /data/dfs/nn /data/dfs/jn /data/dfs/dn 后面数据盘挂载在/hadoop/data1/下，固将hdfs的数据目录改为 /hadoop/data1/dfs/nn /hadoop/data1/dfs/jn /hadoop/data1/dfs/dn 重新启动hdfs，报错，分为三类： nameNode 无法格式化 丢失块信息100% Cloudera Manager 无法检测 HDFS 健康状态 解决： 停掉hdfs所有服务 清空/hadoop/data1/dfs/nn /hadoop/data1/dfs/jn /hadoop/data1/dfs/dn 启动dataNode，failoverController 等服务（除NameNode，journalNode外） 对activity NameNode执行format操作 启动所有journalNode 启动activity NameNode 对Standby NameNode执行Bootstrap Standby操作 启动Standby NameNode ssh客户端以hdfs用户执行hdfs dfs -chmod -R 777 /data/tmp 等命令,完成以下目录创建及赋权,后续通过ranger做权限收口 [hdfs@cdhmaster02 ~]$ hdfs dfs -ls Found 3 items drwxrwxrwt - hdfs supergroup 0 2026-03-26 12:31 /data drwxrwxrwt - hdfs supergroup 0 2026-03-26 17:25 /tmp drwxr-xr-x - hdfs supergroup 0 2026-03-26 17:24 /user 注意事项： 操作顺序不可颠倒，否则可能导致 NameNode 或 JournalNode 数据不一致 不能对 Standby NameNode 执行 format，否则会破坏 HA 集群 **(重要)**清空目录操作仅限于尚未存储业务数据的集群或测试环境 如果要迁移已有数据的数据目录，则需要rsync -avh /data/dfs/nn/ /hadoop/data1/dfs/nn/类似命令 原因解释： NameNode 无法格式化 HDFS 的 HA 模式下，Active NameNode 的元数据（fsimage + edits）必须与 Quorum Journal Nodes 保持一致。 修改 HDFS 存储目录后，如果 JournalNode 目录仍保留旧数据或未初始化，NameNode 在检查 quorum 时会发现元数据不匹配，因此无法格式化。 关键点：只允许对 Active NameNode 格式化，Standby NameNode 或 JournalNode 不能直接 format，否则会破坏 HA 的一致性机制。 丢失块信息 100% DataNode 存储目录修改后，旧数据无法被 NameNode 正确识别，因为 NameNode 的 fsimage 中没有对应块信息。 NameNode 启动时会扫描 DataNode 上报的块，如果目录未初始化或数据不匹配，则所有块都被标记为丢失，从而导致 CM 显示 100% missing blocks。 关键点：HDFS 的块映射严格依赖 NameNode 的元数据，DataNode 目录未同步会造成“逻辑丢失”，即使物理数据存在。 Cloudera Manager 无法检测 HDFS CM Canary 测试依赖基本的 HDFS I/O 操作（创建、写入、读取、删除文件）。 当 NameNode 在安全模式或丢失块状态下，读写请求无法完成，Canary 测试失败，导致 CM 显示健康异常。 关键点：CM 健康检测反映的是 NameNode 和 DataNode 的可用性与一致性，而非磁盘本身状态。 操作顺序要求严格 Active NameNode 必须先格式化并启动，使元数据初始化完成。 JournalNode 启动后才能形成 Quorum，保证 HA 的 edit log 复制。 Standby NameNode 只能通过 Bootstrap Standby 从 Active NameNode 同步元数据，否则会破坏 HA 的一致性，导致集群无法启动。 关键点：HDFS HA 的核心机制是 edit log 的 quorum 写入与 NameNode 状态同步，顺序错误会导致集群不可用。

问题： spark-submit --master yarn --conf spark.default.parallelism=100 \ --deploy-mode cluster --driver-memory 4G --executor-memory 4G \ --num-executors 40 --executor-cores 2 \ --conf spark.yarn.executor.memoryOverhead=5g \ --class com.lz.hbase.CompanyInfo /tmp/test_langzi/original-spark_hbase01-1.0-SNAPSHOT.jar 以上提交参数中的–num-executors 40没有生效，executors 大于40并且占满yarn资源，导致后来的yarn任务阻塞 原因： 官方参数解释 –num-executors NUM Number of executors to launch (Default: 2). If dynamic allocation is enabled, the initial number of executors will be at least NUM. 当开启动态分配时，num-executors成为了最小executors 数，而cdh中spark默认开启dynamic allocation，所以当yarn队列资源空闲时，真正的excutor数会大于设置的num-executors 解决方案： 提交参数添加--conf spark.dynamicAllocation.maxExecutors=40 限制最大excutor数 附：spark提交任务模板 spark-submit --master yarn --conf spark.default.parallelism=100 \ --conf spark.dynamicAllocation.maxExecutors=40\ --deploy-mode cluster --driver-memory 4G --executor-memory 4G \ --num-executors 40 --executor-cores 3 \ --conf spark.yarn.executor.memoryOverhead=4G \ --class com.lz.hbase.CompanyInfo /tmp/test_langzi/original-spark_hbase01-1.0-SNAPSHOT.jar

1.现象 由于zookeeper挂掉，造成kafka出现：There are 60 offline partitions。 2.造成的原因 经过排查发现，由于kafka之前Topic在zookeeper中的数据还在，再重新建立会产生冲突导致失败。 3.解决方案 进入Zookeeper中将之前的脏数据删掉再重启kafka。 #1.进入zookeeper sh /opt/cloudera/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554/lib/zookeeper/bin/zkCli.sh #2.删除掉脏数据 deleteall /brokers/topics

1.现象 2.原因 集群资源使用率过高时可能会导致Hive On Spark查询失败-查询超时。 从hive on spark的架构看出超时的位置： 3.解决 修改以下参数，重启集群 ### 其他可设置的参考参数 # 在Hive client和远程Spark driver通信过程中，随机生成密码的比特数。最好设置成8的倍数。　hive.spark.client.secret.bits # 远程Spark drive用于处理RPC事件所用的最大线程数，默认是8。　hive.spark.client.rpc.threads # Hive client和远程Spark driver通信最大的消息大小（单位：byte）,默认是50MB。　hive.spark.client.rpc.max.size # 远程Spark driver的通道日志级别，必须是DEBUG, ERROR, INFO, TRACE, WARN中的一个。　hive.spark.client.channel.log.level # 用于身份验证的SASL机制的名称。 hive.spark.client.rpc.sasl.mechanisms #生产集群设置的相应参数： hive.spark.client.future.timeout=360s # Hive client请求Spark driver的超时时间，如果没有指定时间单位，默认就是秒。 hive.metastore.client.socket.timeout=360s # 客户端socket超时时间，默认20秒。 hive.spark.client.connect.timeout=360000ms # Spark driver连接Hive client的超时时间，如果没有指定时间单位，默认就是毫秒。 hive.spark.client.server.connect.timeout=360000ms # Hive client和远程Spark driver握手时的超时时间，这个会在两边都检查的，如果没有指定时间单位，默认就是毫秒。 hive.spark.job.monitor.timeout=180s # Job监控获取Spark作业状态的超时时间，如果没有指定时间单位，默认就是秒。

问题描述： 使用hive load hdfs文件时报错： FAILED: Execution Error, return code 3 from org.apache.hadoop.hive.ql.exec.spark.SparkTask. Spark job failed due to task failures: Cannot obtain block length for LocatedBlock{BP-1984322900-192.168.102.3-1594185446267:blk_1180034904_106295094; getBlockSize()=4179; corrupt=false; offset=0; locs=[DatanodeInfoWithStorage[192.168.102.11:9866,DS-cb5a2e07-20e9-45fd-869b-5d8b4ad170a4,DISK], DatanodeInfoWithStorage[192.168.102.9:9866,DS-74706bce-bb23-4aaf-a6eb-ceaa9bdbf38c,DISK], DatanodeInfoWithStorage[192.168.102.5:9866,DS-57f122fb-b6ca-437c-a52e-5f81efdd239c,DISK]]} 22/02/23 16:31:17 ERROR ql.Driver: FAILED: Execution Error, return code 3 from org.apache.hadoop.hive.ql.exec.spark.SparkTask. Spark job failed due to task failures: Cannot obtain block length for LocatedBlock{BP-1984322900-192.168.102.3-1594185446267:blk_1180034904_106295094; getBlockSize()=4179; corrupt=false; offset=0; locs=[DatanodeInfoWithStorage[192.168.102.11:9866,DS-cb5a2e07-20e9-45fd-869b-5d8b4ad170a4,DISK], DatanodeInfoWithStorage[192.168.102.9:9866,DS-74706bce-bb23-4aaf-a6eb-ceaa9bdbf38c,DISK], DatanodeInfoWithStorage[192.168.102.5:9866,DS-57f122fb-b6ca-437c-a52e-5f81efdd239c,DISK]]} 分析问题： 可得知hdfs文件块出现异常，Cannot obtain block length for LocatedBlock，无法获取块文件长度信息 猜测是因为昨日yarn重启导致hdfs文件未关闭写状态 解决问题： 对hive load hdfs文件的地址执行检查命令 ...

问题描述： 使用hive load hdfs文件时报错： FAILED: Execution Error, return code 3 from org.apache.hadoop.hive.ql.exec.spark.SparkTask. Spark job failed due to task failures: Cannot obtain block length for LocatedBlock{BP-1984322900-192.168.102.3-1594185446267:blk1180034904106295094; getBlockSize()=4179; corrupt=false; offset=0; locs=[DatanodeInfoWithStorage[192.168.102.11:9866,DS-cb5a2e07-20e9-45fd-869b-5d8b4ad170a4,DISK], DatanodeInfoWithStorage[192.168.102.9:9866,DS-74706bce-bb23-4aaf-a6eb-ceaa9bdbf38c,DISK], DatanodeInfoWithStorage[192.168.102.5:9866,DS-57f122fb-b6ca-437c-a52e-5f81efdd239c,DISK]]} 22/02/23 16:31:17 ERROR ql.Driver: FAILED: Execution Error, return code 3 from org.apache.hadoop.hive.ql.exec.spark.SparkTask. Spark job failed due to task failures: Cannot obtain block length for LocatedBlock{BP-1984322900-192.168.102.3-1594185446267:blk1180034904106295094; getBlockSize()=4179; corrupt=false; offset=0; locs=[DatanodeInfoWithStorage[192.168.102.11:9866,DS-cb5a2e07-20e9-45fd-869b-5d8b4ad170a4,DISK], DatanodeInfoWithStorage[192.168.102.9:9866,DS-74706bce-bb23-4aaf-a6eb-ceaa9bdbf38c,DISK], DatanodeInfoWithStorage[192.168.102.5:9866,DS-57f122fb-b6ca-437c-a52e-5f81efdd239c,DISK]]} 分析问题： 可得知hdfs文件块出现异常，Cannot obtain block length for LocatedBlock，无法获取块文件长度信息 因为昨日CDH重启导致hdfs文件未关闭写状态 解决问题： 对hive load hdfs文件的地址执行检查命令 ...

问题：agent启动后跑到一半报错卡死 解决：修改flume_ng启动脚本中jvm参数： vi /opt/cloudera/parcels/CDH/lib/flume-ng/bin/flume-ng 把 JAVA_OPTS="-Xmx20m" 改为 JAVA_OPTS="-Xmx2048m" 重启agent，顺畅running

问题描述：flume采集到hdfs上的文件一直不关闭，有tmp后缀，hive读不到 原配置： # 当前文件写入达到该值时间后触发滚动创建新文件，单位：秒，设置为24小时防止产生小文件 ex_trade_agent.sinks.k1.hdfs.rollInterval = 86400 # 当前文件写入达到该大小后触发滚动创建新文件，单位：字节，设置为128M ex_trade_agent.sinks.k1.hdfs.rollSize = 134217700 # 向 HDFS 写入内容时每次批量操作的 Event 数量 ex_trade_agent.sinks.k1.hdfs.batchSize = 2000 # 不根据 Event 数量来分割文件 ex_trade_agent.sinks.k1.hdfs.rollCount = 0 可以看到只按照128m和24小时来判断是否写新文件，如果两者都不满足那就不关闭临时文件 解决方案： # 当前文件写入达到该值时间后触发滚动创建新文件，单位：秒，设置为4小时防止产生小文件 ex_trade_agent.sinks.k1.hdfs.rollInterval = 14400 # 当非活动文件超过4小时，关闭该文件 ex_trade_agent.sinks.k1.hdfs.idleTimeout = 14400

1.现象 flink任务提交任务虚拟内存不足导致的失败 Container [pid=3007,containerID=container_1599018748796_0004_01_000004] is running 342252032B beyond the 'VIRTUAL' memory limit. Current usage: 416.0 MB of 1 GB physical memory used; 2.4 GB of 2.1 GB virtual memory used. Killing container. 2.原因 因为yarn强制检查虚拟内存是否符合配置导致的，当我们的服务器或者虚拟机的内存达不到配置要求，可能就会报这个错误 。 3.解决 修改检查虚拟内存的属性为false <property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property>

在es中数据类型为date： "addTime": { "format": "yyyy-MM-dd HH:mm:ss", "type": "date" } 在hive建映射表 CREATE EXTERNAL TABLE hive_es.cty_test1( addTime date ) STORED BY 'org.elasticsearch.hadoop.hive.EsStorageHandler' TBLPROPERTIES('es.resource' = 'cty_test/cty_test', 'es.nodes'='172.16.98.113,172.16.98.149,172.16.98.150,172.16.98.151,172.16.98.152', 'es.port'='9200', 'es.mapping.names'= 'addTime:addTime', 'es.date.format'='yyyy-MM-dd HH:mm:ss', 'es.index.auto.create'='false', ) 查询报错： 更改hive表数据类型为string CREATE EXTERNAL TABLE hive_es.cty_test5( addTime string ) STORED BY 'org.elasticsearch.hadoop.hive.EsStorageHandler' TBLPROPERTIES('es.resource' = 'cty_test/cty_test', 'es.nodes'='172.16.98.113,172.16.98.149,172.16.98.150,172.16.98.151,172.16.98.152', 'es.port'='9200', 'es.mapping.names'= 'addTime:addTime', 'es.date.format'='yyyy-MM-dd HH:mm:ss', 'es.index.auto.create'='false', ) 查询继续报错： 查阅资料： elasticsearch-hadoop中用于将ES中的日期转换为Hive中的日期格式的类为org.elasticsearch.hadoop.hive.HiveValueReader，通过查看该类的源码，其实现的用户日期转换的方法为： @Override protected Object parseDate(String value, boolean richDate) { return (richDate ? new TimestampWritable(new Timestamp(DatatypeConverter.parseDateTime(value).getTimeInMillis())) : parseString(value)); } 可以看到它是通过javax.xml.bind.DatatypeConverter.parseDateTime(String)方法将对应的日期字符串转换为日期的，该方法不支持的日期字符串格式为“yyyy-MM-dd HH:mm:ss”的字符串，它支持的日期字符串的格式为“yyyy-MM-ddTHH:mm:ss”这样的。 解决方案： 在建表时设置参数’es.mapping.date.rich’=‘false’，然后hive字段类型设为string。 官方解释： Whether to create a rich Date like object for Date fields in Elasticsearch or returned them as primitives (String or long). By default this is true. The actual object type is based on the library used; noteable exception being Map/Reduce which provides no built-in Date object and as such LongWritable and Text are returned regardless of this setting. ...