调优 on LeoChu Space

CDH基础配置及优化

Sun, 01 Feb 2026 00:00:00 +0000

一、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;

linux系统级优化

Sat, 31 Jan 2026 00:00:00 +0000

一、在cdh+cm部署时，已经做了部分系统优化

ssh双向免密
配置时间同步服务（本次没用ntpd，用的是chrony）
禁用透明大页、碎片整理：THP (Transparent Huge Pages)
禁用内存交换swap（常用0或1）

二、hadoop集群推荐内核参数：

参数名称	默认值	说明
文件系统参数
`fs.file-max`	6815744	系统最大文件描述符数量（所有进程可打开文件总数上限）
`fs.aio-max-nr`	1048576	异步I/O请求的最大并发数（影响高并发场景性能）
网络核心参数
`net.core.rmem_default`	262144	TCP接收缓冲区默认大小（256KB）
`net.core.wmem_default`	262144	TCP发送缓冲区默认大小（256KB）
`net.core.rmem_max`	16777216	TCP接收缓冲区最大允许值（16MB）
`net.core.wmem_max`	16777216	TCP发送缓冲区最大允许值（16MB）
TCP协议栈参数
`net.ipv4.tcp_rmem`	4096 262144 16777216	接收窗口尺寸：• 最小值4KB• 默认值256KB• 最大值16MB
`net.ipv4.tcp_wmem`	4096 262144 16777216	发送窗口尺寸：• 最小值4KB• 默认值256KB• 最大值16MB

查看当前内核配置：

sysctl -e fs.file-max fs.aio-max-nr \
 net.core.rmem_default net.core.wmem_default \
 net.core.rmem_max net.core.wmem_max \
 net.ipv4.tcp_rmem net.ipv4.tcp_wmem 2>/dev/nulll

JVM调优注意事项

Sat, 12 Apr 2025 00:00:00 +0000

·Xmx不要超过机器内存的50%，留下些内存供VM堆外内存和操作系统使用。 ·并且Xm不要超过32G。建议最大配置为30G。接近32G,JVM会启用压缩对象指针的功能，导致性能下降。常见es集群。具体可以参考：A Heap of Trouble: Managing Elasticsearch’s Managed Heap | Elastic Blog

impala配置调优

Sun, 27 Nov 2022 00:00:00 +0000

Impala Daemon 命令行参数高级配置代码段（安全阀）

-use_local_tz_for_unix_timestamp_conversions=true
-convert_legacy_hive_parquet_utc_timestamps=true

在hive中，一个中文字符长度为1

在impala中，一个中文字符长度为3

Hive调优大全

Sun, 18 Sep 2022 00:00:00 +0000

调优具体细节

Hive建表设计层面

Hive 的建表设计层面调优，主要讲的怎么样合理的组织数据，方便后续的高效计算。比如建表的类型，文件存储格式，是否压缩等等。

利用分区表优化

关于 Hive 的表的类型有哪些？
1、分区表  
2、分桶表

分区表是在某一个或者几个维度上对数据进行分类存储，一个分区对应一个目录。如果筛选条件里有分区字段，那么 Hive 只需要遍历对应分区目录下的文件即可，不需要遍历全局数据，使得处理的数据量大大减少，从而提高查询效率。

也就是说：当一个 Hive 表的查询大多数情况下，会根据某一个字段进行筛选时，那么非常适合创建为分区表，该字段即为分区字段。

select1:  select ....  where country = "china"
select2:  select ....  where country = "china"
select3:  select ....  where country = "china"
select4:  select ....  where country = "china"
.....

分门别类：这个city字段的每个值，就单独形成为一个分区。其实每个分区就对应带HDFS的一个目录

在创建表时通过启用 partitioned by 实现，用来 partition 的维度并不是实际数据的某一列，具体分区的标志是由插入内容时给定的。当要查询某一分区的内容时可以采用 where 语句，形似 where tablename.partition_column = a 来实现。

1、创建含分区的表：

CREATE TABLE page_view(viewTime INT, userid BIGINT,
                       page_url STRING, referrer_url STRING,
                       ip STRING COMMENT 'IP Address of the User')
PARTITIONED BY(date STRING, country STRING)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '1'
STORED AS TEXTFILE;

2、载入内容，并指定分区标志：

Hive 数仓建表该选用 ORC 还是 Parquet，压缩选 LZO 还是 Snappy

Sun, 24 Jul 2022 00:00:00 +0000

在数仓中，建议大家除了接口表（从其他数据库导入或者是最后要导出到其他数据库的表），其余表的存储格式与压缩格式保持一致。

在数仓中，建议大家除了接口表（从其他数据库导入或者是最后要导出到其他数据库的表），其余表的存储格式与压缩格式保持一致。

我们先来说一下目前 Hive 表主流的存储格式与压缩方式

从 Hive 官网得知，Apache Hive 支持 Apache Hadoop 中使用的几种熟悉的文件格式，如 TextFile（文本格式），RCFile（行列式文件），SequenceFile（二进制序列化文件），AVRO，ORC（优化的行列式文件）和Parquet 格式，而这其中我们目前使用最多的是TextFile，SequenceFile，ORC和Parquet。

下面来详细了解下这 2 种行列式存储。

1、ORC

1.1 ORC 的存储结构

我们先从官网上拿到 ORC 的存储模型图

看起来略微有点复杂，那我们稍微简化一下，我画了一个简单的图来说明一下

但是由于索引的高成本，在**「目前的 Hive3.X 中，已经废除了索引」**，当然也早就引入了列式存储。

列式存储的存储方式，是按照一列一列存储的，如上图中的右图，这样的话如果查询一个字段的数据，就等于是索引查询，效率高。但是如果需要查全表，它因为需要分别取所有的列最后汇总，反而更占用资源。于是 ORC 行列式存储出现了。

在需要全表扫描时，可以按照行组读取
如果需要取列数据，在行组的基础上，读取指定的列，而不需要所有行组内所有行的数据和一行内所有字段的数据。

了解了 ORC 存储的基本逻辑后，我们再来看看它的存储模型图。

同时我也把详细的文字也附在下面，大家可以对照着看看：

条带 (stripe)：ORC 文件存储数据的地方，每个 stripe 一般为 HDFS 的块大小。（包含以下 3 部分）

index data:保存了所在条带的一些统计信息,以及数据在 stripe中的位置索引信息。
rows data:数据存储的地方,由多个行组构成，每10000行构成一个行组，数据以流( stream)的形式进行存储。
stripe footer:保存数据所在的文件目录

文件脚注 (file footer)：包含了文件中 sipe 的列表, 每个 stripe 的行数, 以及每个列的数据类型。它还包含每个列的最小值、最大值、行计数、求和等聚合信息。
postscript：含有压缩参数和压缩大小相关的信息

所以其实发现，ORC 提供了 3 级索引，文件级、条带级、行组级，所以在查询的时候，利用这些索引可以规避大部分不满足查询条件的文件和数据块。

CDH组件参数调优

Sun, 29 May 2022 00:00:00 +0000

1.YARN参数调优

检查项	当前值	修改值
JobHistory Server 的 Java 堆栈大小	1GB	2GB
NodeManager 的 Java 堆栈大小	1GB	2GB
ResourceManager 的 Java 堆栈大小	1GB	2GB
容器内存 yarn.nodemanager.resource.memory-mb	24GB	32GB
最小容器内存 yarn.scheduler.minimum-allocation-mb	10GB	8GB
最大容器内存 yarn.scheduler.maximum-allocation-mb	40GB	56GB
Map 任务内存 mapreduce.map.memory.mb	0M	12GB
Reduce 任务内存 mapreduce.reduce.memory.mb	0M	24GB
Application Master容器内存 yarn.app.mapreduce.am.resource.mb	24GB	32GB
Map 任务 Java 选项库 mapreduce.map.java.opts	-Djava.net.preferIPv4Stack=true	-Dmapreduce.map.java.opts=-Xmx2048m
Reduce 任务 Java 选项库 mapreduce.reduce.java.opts	-Djava.net.preferIPv4Stack=true	-Dmapreduce.reduce.java.opts=-Xmx2048m
yarn.resourcemanager.scheduler.class	org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler	org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

yarn.scheduler.capacity.root.queues:

当前值：

<configuration>
    <property>
        <name>yarn.scheduler.capacity.root.queues</name>
        <value>default</value>
    </property>
    <property>
        <name>yarn.scheduler.capacity.root.capacity</name>
        <value>100</value>
    </property>
    <property>
        <name>yarn.scheduler.capacity.root.default.capacity</name>
        <value>100</value>
    </property>
</configuration>

修改值：

如何调优 Kafka

Sun, 03 Apr 2022 00:00:00 +0000

调优目标

在做调优之前，我们必须明确优化 Kafka 的目标是什么。通常来说，调优是为了满足系统常见的非功能性需求。在众多的非功能性需求中，性能绝对是我们最关心的那一个。不同的系统对性能有不同的诉求，比如对于数据库用户而言，性能意味着请求的响应时间，用户总是希望查询或更新请求能够被更快地处理完并返回。

对 Kafka 而言，性能一般是指吞吐量和延时。

吞吐量，也就是 TPS，是指 Broker 端进程或 Client 端应用程序每秒能处理的字节数或消息数，这个值自然是越大越好。

延时和我们刚才说的响应时间类似，它表示从 Producer 端发送消息到 Broker 端持久化完成之间的时间间隔。这个指标也可以代表端到端的延时（End-to-End，E2E），也就是从 Producer 发送消息到 Consumer 成功消费该消息的总时长。和 TPS 相反，我们通常希望延时越短越好。

总之，高吞吐量、低延时是我们调优 Kafka 集群的主要目标，一会儿我们会详细讨论如何达成这些目标。在此之前，我想先谈一谈优化漏斗的问题。

优化漏斗

优化漏斗是一个调优过程中的分层漏斗，我们可以在每一层上执行相应的优化调整。总体来说，层级越靠上，其调优的效果越明显，整体优化效果是自上而下衰减的，如下图所示：

第 1 层：应用程序层。它是指优化 Kafka 客户端应用程序代码。比如，使用合理的数据结构、缓存计算开销大的运算结果，抑或是复用构造成本高的对象实例等。这一层的优化效果最为明显，通常也是比较简单的。
第 2 层：框架层。它指的是合理设置 Kafka 集群的各种参数。毕竟，直接修改 Kafka 源码进行调优并不容易，但根据实际场景恰当地配置关键参数的值，还是很容易实现的。
第 3 层：JVM 层。Kafka Broker 进程是普通的 JVM 进程，各种对 JVM 的优化在这里也是适用的。优化这一层的效果虽然比不上前两层，但有时也能带来巨大的改善效果。
第 4 层：操作系统层。对操作系统层的优化很重要，但效果往往不如想象得那么好。与应用程序层的优化效果相比，它是有很大差距的。

基础性调优

接下来，我就来分别介绍一下优化漏斗的 4 个分层的调优。

操作系统调优

我先来说说操作系统层的调优。在操作系统层面，你最好在挂载（Mount）文件系统时禁掉 atime 更新。atime 的全称是 access time，记录的是文件最后被访问的时间。记录 atime 需要操作系统访问 inode 资源，而禁掉 atime 可以避免 inode 访问时间的写入操作，减少文件系统的写操作数。你可以执行 mount -o noatime 命令进行设置。