kudu性能优化

一.背景

一个实时业务，数据流  app ->  nginx ->lua  ->kafka -> spark streaming ->kudu ->zepplin 。

打开zepplin，实时数据出不来。看不到。

二.问题分析-结合链路

1.近期流量暴涨，单个用户的使用时长，由1-1.5h 增加到 8-10h。

2.大量数据进入kakfa，得不到spark streaming及时处理，kafka有大量消息堆积。

3.streaming 任务，duration时间变长。

4.spark 的executor (执行算子) 写入kudu 延时变长。

5.kudu 中 几乎快到了，拒绝写入数据(client写kudu  写入失败)的状态。

6.zepplin读kudu数据失败，延时特别长，导致打开zepplin看不到数据

三.问题分析-kudu数据库

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

[root@realtime-1 ~]# ps aux | grep 145440
root      68916  0.0  0.0 112708   964 pts/11   S+   11:09   0:00 grep --color=auto 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磁盘上。

[root@realtime-1 ~]# ls -l /proc/145440/fd
total 0
lr-x------. 1 kudu kudu 64 Mar 17 10:25 0 -> /dev/null
l-wx------. 1 kudu kudu 64 Mar 17 10:25 1 -> /var/log/kudu/kudu-tserver.out
lrwx------. 1 kudu kudu 64 Mar 17 10:25 10 -> anon_inode:[eventpoll]
lrwx------. 1 kudu kudu 64 Mar 17 10:25 100 -> /data2/kuduTabletDir/data/49d3641d988a478ca8e2f65c6803e143.metadata
lrwx------. 1 kudu kudu 64 Mar 17 10:30 1000 -> /data2/kuduTabletDir/wals/2e43a0096abf4a6eb35e14b6a4ed5b10/index.000000000
lr-x------. 1 kudu kudu 64 Mar 17 10:30 1001 -> /data2/kuduTabletDir/wals/fce526d0312b49489215ca8bafce0665/wal-000000429
lr-x------. 1 kudu kudu 64 Mar 17 10:25 102 -> /data2/kuduTabletDir/wals/3226d0d768c54e5bb292e05d486116ac/wal-000000001
l-wx------. 1 kudu kudu 64 Mar 17 10:30 1020 -> /data2/kuduTabletLogDir/kudu-tserver.realtime-1.kudu.log.ERROR.20200228-115129.145440

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的写入能力，由几个参数控制

memory_limit_hard_bytes

memory_pressure_percentage

flush_threshold_mb                               这个在低版本可以作为调优依据，现在系统默认也是可以的，不用调也可以。

memory_limit_soft_percentage              可使用内存比例，如果脏数据特别大，kudu总内存超过一定限制，kudu就拒绝写入了，因为他有太多脏数据要刷磁盘了，但是脏数据太多，超过，或者即将超过允许使用的内存总数，那么就拒绝写入了

maintenance_manager_num_threads           默认为1，调成24 (我们虽然是单块盘，但是ssd)  (机械盘：一个数据盘，分配一个1，几个数据盘配几个)

2.重点调大 maintenance_manager_num_threads      = 24

3.调大后重启kudu，再看效果，spark处理kafka数据非常快，已经没有堆积

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/[email protected]/msg00307.html

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

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

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

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

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

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

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