排错 on LeoChu Space

HDFS更改数据目录导致NameNode无法启动

Thu, 26 Mar 2026 00:00:00 +0000

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参数num-executors未生效

Sat, 23 Nov 2024 00:00:00 +0000

问题：

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

kafka集群运行节点运行不成功

Sat, 26 Oct 2024 00:00:00 +0000

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

hiveOnSpak客户端RemoteSparkDriver超时

Sat, 12 Oct 2024 00:00:00 +0000

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作业状态的超时时间，如果没有指定时间单位，默认就是秒。

hdfs文件未关闭

Sat, 28 Sep 2024 00:00:00 +0000

问题描述：

使用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文件的地址执行检查命令

hdfs文件块异常

Sat, 14 Sep 2024 00:00:00 +0000

问题描述：

使用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文件的地址执行检查命令

Flume内存溢出卡死

Sat, 31 Aug 2024 00:00:00 +0000

问题：agent启动后跑到一半报错卡死

解决：修改flume_ng启动脚本中jvm参数：

vi /opt/cloudera/parcels/CDH/lib/flume-ng/bin/flume-ng

把 JAVA_OPTS="-Xmx20m" 改为 JAVA_OPTS="-Xmx2048m"

重启agent，顺畅running

flume不关闭临时文件

Sat, 17 Aug 2024 00:00:00 +0000

问题描述：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

flink虚拟内存不足

Sat, 03 Aug 2024 00:00:00 +0000

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映射hive数据类型date无法解析

Sat, 06 Jul 2024 00:00:00 +0000

在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.

dolphin踩坑

Sat, 22 Jun 2024 00:00:00 +0000

一个sql节点只能写一条sql且结尾不能写分号
使用sql节点时由于dolohin写了hive的预编译，某些时候变量不能正确传入，比如 location ‘xxxxx${变量名}’,在预编译过程中会直接变成 location ‘xxxxx?’ **解决方案：**把sql节点替换成shell节点用hive -e ‘………….. location ‘xxxxx${变量名}’来实现变量传参
节点开启非严格模式，从节点偶尔会失效 **解决方案：**每个需要动态分区的sql都加上设置非严格模式的前置sql
sql节点无法使用hive永久注册的udf **解决方案：**在dolphin资源中心上传udf并创建（会注册成临时udf）
sql节点使用 REPLACE函数会有bug，导致任务流无法保存 **解决方案：**使用REGEXP_REPLACE函数
sql节点添加扩展jar包，无法使用本地路径 **解决方案：**需要先上传jar到hdfs，然后加上hdfs://nameservice1/前缀

Hive 字段中文注释乱码

Sun, 07 Aug 2022 00:00:00 +0000

Hive 字段中文乱码，如执行 show create table xxx 时，表级别注释、字段级别注释发现有乱码现象（都是？？？？），一般都是由 hive 元数据库的配置不当造成的。

此时可按如下步骤进行配置调整：

1、设置 hive 元数据库字符集

show create database hive;

查看为 utf8，需变更为 latin1

_alter database hive character set latin1;

2、更改如下表字段为字符集编码为 utf8

①修改表字段注解和表注解
alter table COLUMNS_V2 modify column COMMENT varchar(256) character set utf8
alter table TABLE_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8
② 修改分区字段注解：
alter table PARTITION_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8 ;
alter table PARTITION_KEYS modify column PKEY_COMMENT varchar(4000) character set utf8;
③修改索引注解：
alter table INDEX_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8;