踩坑 | LeoChu Space

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

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 状态同步，顺序错误会导致集群不可用。

线程不安全的simpleDateFormat

1.什么是线程不安全？线程不安全也叫非线程安全，是指多线程执行中，程序的执行结果和预期的结果不符的情况就叫做线程不安全。线程不安全的代码 SimpleDateFormat 就是一个典型的线程不安全事例，接下来我们动手来实现一下。首先我们先创建 10 个线程来格式化时间，时间格式化每次传递的待格式化时间都是不同的，所以程序如果正确执行将会打印 10 个不同的值，接下来我们来看具体的代码实现： import java.text.SimpleDateFormat; import java.util.Date; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class SimpleDateFormatExample { // 创建 SimpleDateFormat 对象 private static SimpleDateFormat simpleDateFormat = new SimpleDateFormat("mm:ss"); public static void main(String[] args) { // 创建线程池 ExecutorService threadPool = Executors.newFixedThreadPool(10); // 执行 10 次时间格式化 for (int i = 0; i < 10; i++) { int finalI = i; // 线程池执行任务 threadPool.execute(new Runnable() { @Override public void run() { // 创建时间对象 Date date = new Date(finalI * 1000); // 执行时间格式化并打印结果 System.out.println(simpleDateFormat.format(date)); } }); } } } 我们预期的正确结果是这样的（10 次打印的值都不同）： ...

spark参数num-executors未生效

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

maven打包去除dependency-reduced-pom.xml文件

标签 #maven 场景工作时间 2023年2月14日17:58:09 一、问题描述每次打包的时候，项目目录会多出一个莫名的文件dependency-reduced-pom.xml 二、导致原因 maven打包插件maven-shade-plugin打包时自动生成，createDependencyReducedPom默认为true。 dependency-reduced-pom.xml 删除了已经在你的着色 jar 中的传递依赖项。这可以防止消费者两次拉他们，从而避免无用的重复。三、解决方案添加以下配置 <configuration> <createDependencyReducedPom>false</createDependencyReducedPom> </configuration> 如： <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.1.1</version> <configuration> <createDependencyReducedPom>false</createDependencyReducedPom> </configuration> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <artifactSet> <excludes> <exclude>org.slf4j:*</exclude> <exclude>log4j:*</exclude> <exclude>ch.qos.logback:*</exclude> <exclude>com.google.code.findbugs:jsr305</exclude> </excludes> </artifactSet> <filters> <filter>  <artifact>*:*</artifact> <excludes> <exclude>META-INF/*.SF</exclude> <exclude>META-INF/*.DSA</exclude> <exclude>META-INF/*.RSA</exclude> </excludes> </filter> </filters> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">  <mainClass>my.programs.main.clazz</mainClass> </transformer> <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/> </transformers> </configuration> </execution> </executions> </plugin>

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

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超时

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文件未关闭

问题描述：使用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文件块异常

问题描述：使用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内存溢出卡死

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

flume不关闭临时文件

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