其他分享
首页 > 其他分享> > kudu性能优化

kudu性能优化

作者：互联网

一、impala + kudu一些优化心得
用了几次impala + kudu做大数据实时计算场景，一路踏坑过来，这里分享踏坑经验

由于sqoop从关系型数据直接以parquet格式导入hive会有问题，这里默认hive的表都是txt格式；每次导完到临时表，需要做invalidate metadata 表操作，不然后面直接导入kudu的时候会查不到数据
这时候kudu配置参数 --memory_limit_hard_bytes能大点就大点，因为kudu写入首先保存再内存里面，到一定阀值才溢写到磁盘，这个是直接最能提高写的方法；

当然不是所有机器都有那么多资源，可以把--maintenance_manager_num_threads 这个参数稍微调大，需要调试，提高数据从内存写入磁盘的效率
首先所有表做完全量的etl操作，必须得执行compute stats 表名，不然impala执行sql生成的计划执行数评估的内存不准确，容易评估错误导致实际执行不了

kudu表最好不要做任何压缩，保证原始扫描性能发挥最好；假如对查询性能要求比存储要求高的话；大部分企业对实时查询效率要求高，而且存储成本毕竟低；

kudu针对大表要做好分区，最好range和hash一起使用，前提是主键列包含能hash的id，但range分区一定要做好，经验告诉我一般是基于时间；

查询慢的sql，一般要拿出来；方便的话做下explain，看下kudu有没有过滤部分数据关键字kudu predicates；假如sql没问题，那在impala-shell执行这个sql，最后执行summray命令，重点查看单点峰值内存和时间比较大的点，对相关的表做优化，解决数据倾斜问题
大表不要delete，不要犹豫直接drop，在create吧；磁盘空间会释放的
网上很多分析impala + kudu 要比 impala + parquet 优越很多；谁信谁XB；

首先两个解决的场景不一样，kudu一般解决实时，hive解决的是离线（通常是T + 1或者 T -1）

hive基于hdfs，hdfs已经提供一套较为完善的存储机制，底层数据和文件操作便利；安全性，可扩展性都比kudu强很多，最重要parquet + impala效率要比kudu高，数仓首选是它

kudu最大优势是能做类似关系型数据库一样的操作，insert, update, delete，这样热点的数据可以存储在kudu里面并随时做更新
同步工具我们这里使用streamsets，一个拖拉拽的工具，非常好用；但内存使用率高，通过jconsole我们发现，所有任务同时启动；JVM新生代的内容几乎都跑到老年代了，GC没来的及，就内存溢出了；后面单独拿几台服务器出来做这个ETL工具，jvm配置G1垃圾回收器

二、问题分析-kudu数据库
1.问题聚焦到kudu数据库上，从数据库原理，特别是kudu处理请求的入手

[root@realtime-1 ~]# ps aux | grep 145440
kudu 145440 202 37.2 34052208 24452396 ? Sl Feb28 52555:59 /usr/lib/kudu/sbin/kudu-tserver --server_dump_info_path=/var/run/kudu/kudu-tserver-kudu.json --flagfile=/etc/kudu/conf/tserver.gflagfile

2.kudu用LSM 索引文件，组织数据，存储。写入过程先写内存，再刷磁盘。data+log 形式。WAL。

3.kudu 先把数据写内存(脏数据)，再写log(WAL)。随着内存中脏数据不断增加，kudu有一套机制会刷脏数据。

4.大量数据写入kudu，kudu处理不及时，造成写入失败和写入慢，一定出在kudu写数据 的瓶颈上，写数据的吞吐量不高。

5.写入吞吐量达到瓶颈，需要找出瓶颈点。 从系统架构上看，一个是软件问题，一个是硬件问题。

6.查看kudu数据和log目录，发现 两个目录(文件)，都存放到了ssd磁盘上。

7.查看该ssd盘，iostat 发现 磁盘吞吐量没有达到其极限。io有的是资源，只是kudu没有充分利用到ssd写入能力。

8.因为ssd(sas接口，eMLC),随机iops和顺序iops性能很高，随机和顺序读写 吞吐量 非常大。 而现在写入量很低，util%也非常低。

[root@realtime-1 ~]# iostat -x 1 100
Linux 3.10.0-514.el7.x86_64 (realtime-1) 03/17/2020 _x86_64_ (64 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
2.66 0.00 0.46 0.04 0.00 96.84
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 5.00 0.00 2.00 0.00 28.00 28.00 0.00 0.00 0.00 0.00 0.00 0.00
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 6.00 0.00 24.00 8.00 0.00 0.00 0.00 0.00 0.00 0.00
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

9.显然，kudu系统，没有充分利用完系统硬件性能。

大量数据写入，内存中dirty data堆积，不能flush到磁盘。(kudu刷脏数据中也很复杂，这里不详述)。内存使用量超过配置参数限制，导致kudu拒绝写入新数据。

可是ssd盘的处理能力，没用被kudu充分利用到 %util 基本都是0。

三、问题解决-kudu调优

1，Kudu Tablet Servers 参数调节

 

Flag Default Modify After 描述
block_cache_capacity_mb 512 12G

分配给Kudu Tablet服务器块缓存的最大内存量。（虽然较高的值有助于提高读写性能，但是不要将 block_cache_capacity_mb 提高到内存压力阈值以上,因为这将导致即使写吞吐量很低，Kudu也会频繁刷新,建议将block_cache_capacity_mb保持在内存压力阈值的50%以下）

提高读写性能, 改值建议为 memory_limit_hard_bytes 的 30% 到 50%
memory_limit_hard_bytes 4294967296 42G

写性能，控制kudu最多使用多少内存，在开始拒绝所有输入的写之前，Tablet Server 可以消耗的最大内存量。（根据机器内存去调整，如果主机有更多的内存可供Kudu使用，那么建议设置大一点。根据系统总内存自动调整大小的值为0，值-1禁用所有内存限制，单位：bytes），Tablet Server在批量写入数据时并非实时写入磁盘，而是先Cache在内存中，在flush到磁盘。这个值设置过小时，会造成Kudu数据写入性能显著下降。对于写入性能要求比较高的集群，建议设置更大的值

建议是机器总内存的百分之80，master的内存量建议是2G，

因为Kudu 的4台主机均为网络增强性，而Kudu本身对网络IO要求较高，应将这４台主机应均服务于Kudu，所以将２／３的内存分配给kudu使用。后期PRO环境在修改hostname时，移除其他节点，对节点进行调整。
maintenance_manager_num_threads 1 24

维护管理器线程池的大小。对于旋转磁盘，线程数不应超过设备数。（官网建议的维护管理器线程数是数据目录的3倍）

默认为1，调成24 (我们虽然是单块盘，但是ssd)  (机械盘：一个数据盘，分配一个1，几个数据盘配几个)
default_num_replicas 3   每个tablet的默认副本数
log_dir /tmp   存放Tablet Server 日志文件
memory_pressure_percentage      
flush_threshold_mb     这个在低版本可以作为调优依据，现在系统默认也是可以的，不用调也可以。
memory_limit_soft_percentage     可使用内存比例，如果脏数据特别大，kudu总内存超过一定限制，kudu就拒绝写入了，因为他有太多脏数据要刷磁盘了，但是脏数据太多，超过，或者即将超过允许使用的内存总数，那么就拒绝写入了
max_clock_sync_error_usec 10000000 20000000 设置ntp服务器的时间误差不超过20s（默认是10s）

2，Kudu物理内存背压解决

官网:https://kudu.apache.org/docs/troubleshooting.html#memory_limits
尽管官网给出了参数调节的说明,但在实际情况中, 当出现Kudu背压时, 所有业务均停掉, 而Kudu占用内存并没有及时下降, 导致数据无法写入使业务瘫痪.
这一原因目前并没有得到很好的解决方案, 但对以上参数的调节可尽量避免该错误的发生, 后期持续更新.
不成熟的方案: 查看各tablet server 上tablet 的内存使用情况, 查找内存使用较多的tablet 下的 table, 将该table 数据备份后删除, 使内存快速降低, 避免影响全局业务.

jbd2引起IO过高，导致KUDU 平均负载超载，只有重启kudu

3.根据生产环境主机配置和实际业务需求参考 (调优）,调大后重启kudu，再看效果，

4.调大后，再看kudu利用ssd硬件能力，写入吞吐量达到152MB，是之前的100倍。

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 8380.00 427.00 3078.00 6988.00 152704.00 91.12 31.13 8.88 20.23 7.30 0.25 86.30
sda 0.00 0.00 1.00 1.00 4.00 4.00 8.00 0.00 1.00 2.00 0.00 1.00 0.20
sdc 0.00 0.00 1.00 6.00 40.00 24.00 18.29 0.01 0.86 0.00 1.00 0.86 0.60
sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

5.初略估计，每秒 5-10万 并发没问题，对应处理事件数/s 是之前 100倍以上，吞吐率 100倍。

6.再次打开zepplin后，实时数据立刻出来的，前端显示正常。

四、kudu问题延续分析
查这个问题，看了官网和google了几个case。

1.kudu重启后需要做一些redo和undo操作，特别是需要重新组织(整理)数据，启动会非常慢。有两个参数特别重要：

num_tablets_to_delete_simultaneously 默认为1，调成 24

num_tablets_to_open_simultaneously 默认为1，调成 24

可以看看这个 https://www.mail-archive.com/user@kudu.incubator.apache.org/msg00307.html

2.针对kudu写入能力的性能测试，通过几个参数观察 qps,latency,error_rate

https://kudu.apache.org/2016/04/26/ycsb.html

里面特别提到 flush_threshold_mb 调成20G，效果显著，但是我没有测过。

3.写入性能差，写入失败，有的同学说是内存不足的问题，需要加内存100G。

这个思路完全错误，如果是读性能差，加内存，写入差要分析kudu写入数据过程，分析软件、硬件。

加内存有用，但是加完内存后，只会将脏数据在内存中堆积的越来越多。并没有落盘。

完整的思路是，软件->操作系统->硬件 这三层来展开分析。软件本身差，操作系统(比如内核参数问题)问题，硬件瓶颈。这么去分析。

 

转载：https://blog.csdn.net/qq_22473611/article/details/113935392

标签：数据,impala,性能,写入,内存,kudu,优化,0.00
来源： https://www.cnblogs.com/gentlescholar/p/15142847.html