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

线程不安全的simpleDateFormat

Sat, 18 Jan 2025 00:00:00 +0000

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未生效

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

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

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

标签	#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>
                        <!-- Do not copy the signatures in the META-INF folder.
                        Otherwise, this might cause SecurityExceptions when using the JAR. -->
                        <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">
                        <!-- Replace this with the main class of your job -->
                        <mainClass>my.programs.main.clazz</mainClass>
                    </transformer>
                    <transformer
                            implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
                </transformers>
            </configuration>
        </execution>
    </executions>
</plugin>

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>

flink查看stdout日志

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

问题:

flink的web管理界面在日志过大时无法加载且无法下载

解决:

复制该任务task manager的container编号 container_e01_1675618892497_0264_01_000003
远程登录该task manager所在服务器
使用命令查询进程 ps -ef | grep taskmanager | grep -v "bash -c" |grep container_e01_1675618892497_0264_01_000003
进入该目录
各文件用途 taskmanager.out：业务侧的输出文件，该文件中的内容一般是业务代码中，使用算子的print()方法或者使用java的System.out.print()产生的内容，与前台的taskmanager输出打印内容一致
taskmanager.log就是运行中的taskmanager的日志
taskmanager.err ：taskmanager中出错时候的异常信息
gc.log.x.current：taskmanager的gc日志

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/前缀

部署CDH踩坑总结

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

1.zookeeper刚启动时会报错，晾它两分钟会就好了

2.更改或迁移服务时一定要切换到维护模式并停止当前服务！！！

3.cdh01的hadoop组件起不来，原因是一些文件夹的权限问题，更改权限并且更改拥有者及组（参照其他服务器）

4.内存不足主要因为NodeManager内存调的太高，调小即可（个人经验，5台机器可用内存和为30*4+20=160G，可同时对20G的数据做处理，感觉够用了）

5.oozie报错：Failed to install Oozie ShareLib，这个问题是cdh6.2的通病，只要安装oozie就会出现(无论是升级，还是新装。

解决：

cd /opt/cloudera/parcels/CDH/lib/oozie/libtools

ln -s ../../../jars/logredactor-2.0.7.jar logredactor-2.0.7.jar

执行完后重启oozie。

6.oozie端口号11000冲突，改为11002

7.从节点不要提前安装agent服务！！！直接在web界面安装！

8.把CM和CDH装好后面就轻松多了

9.==主机名不要出现下划线!==

sql中!=的陷阱

Sun, 06 Aug 2023 00:00:00 +0000

mysql/SQL server有，clickhouse也有，hive未验证。

null 值的比较这里另外说下 SQL 里 null 值的比较，任何与 null 值的比较结果，最后都会变成 null，以PostgreSQL为例，如下：select null != null;

select null = null;
select null > 1;
select null <> 1;

以上结果都是 null，而不是什么 true 或者 false。另外有些函数是不支持 null 值作为输入参数的，比如count()或者sum()等。

在写 SQL 条件语句时经常用到不等于 != 的筛选条件。此时要注意此条件会将字段为 Null 的数据也当做满足不等于的条件而将数据筛选掉。（也就是说会忽略过滤掉为 null 的数据，导致数据不准确）。

SELECT * FROM A WHERE B1 != 1

不会查出null值

修改：

SELECT * FROM A WHERE B1 != 1 OR B1 is Null

SELECT * FROM A WHERE IFNULL(B1,'')  != 1

为什么会这样呢？这还得从 mysql 的底层开始说起，因为 NULL 不是一个「值」，而是「没有值」。

　　「没有值」不满足「值不等于1」这个条件，怎么解决可以使用 ifnull() 方法，将 null 转为空字符串，或者这个字段做出判断加上OR a is null。当然使用 ifnull 相率会更好

select null = null返回也是null。null只能用is或is not

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;

取消HDP hive默认开启ACID配置

Sun, 20 Mar 2022 00:00:00 +0000

问题描述

原因排查

HDP 的 hive 使用的版本较高为3.1.0 ，默认建表都是使用 ACID 的事务表。而 HDP的spark版本较低为2.3 目前还不支持 hive 的 ACID 功能，因此无法读取 ACID 表的数据，准确来说是内表的数据。

官方资料

spark issues 地址： SPARK-15348 Hive ACID

解决方案

修改hive以下配置，重启hive

hive.strict.managed.tables =false
hive.create.as.insert.only =false
metastore.create.as.acid =false

其他资料

Hive 中支持的表类型和 ACID 特性


表类型	ACID	文件格式	插入	更新 / 删除
托管表：CRUD 事务	是	ORC	是	是
托管表：仅插入式事务	是	任意格式	是	没有
托管表：临时	没有	任意格式	是	没有
外部表	没有	任意格式	是	没有

查看表的属性，指令：desc formatted tb_name