admin
一、impala + kudu一些优化心得
用了几次impala + kudu做大数据实时计算场景，一路踏坑过来，这里分享踏坑经验
一开始需要全量导入kudu，这时候我们先用sqoop把关系数据库数据导入临时表，再用impala从临时表导入kudu目标表
由于sqoop从关系型数据直接以parquet格式导入hive会有问题，这里默认hive的表都是txt格式；每次导完到临时表，需要做invalidate metadata 表操作，不然后面直接导入kudu的时候会查不到数据
除了查询，建议所有impala操作都在impala-shell而不在hue上面执行impala并发写入kudu的时候，数据量比较大的时候
这时候kudu配置参数 --memory_limit_hard_bytes能大点就大点，因为kudu写入首先保存再内存里面，到一定阀值才溢写到磁盘，这个是直接最能提高写的方法；
当然不是所有机器都有那么多资源，可以把--maintenance_manager_num_threads 这个参数稍微调大，需要调试，提高数据从内存写入磁盘的效率
impala查询kudu
首先所有表做完全量的etl操作，必须得执行compute stats 表名，不然impala执行sql生成的计划执行数评估的内存不准确，容易评估错误导致实际执行不了
kudu表最好不要做任何压缩，保证原始扫描性能发挥最好；假如对查询性能要求比存储要求高的话；大部分企业对实时查询效率要求高，而且存储成本毕竟低；
kudu针对大表要做好分区，最好range和hash一起使用，前提是主键列包含能hash的id，但range分区一定要做好，经验告诉我一般是基于时间；
查询慢的sql，一般要拿出来；方便的话做下explain，看下kudu有没有过滤部分数据关键字kudu predicates；假如sql没问题，那在impala-shell执行这个sql，最后执行summray命令，重点查看单点峰值内存和时间比较大的点，对相关的表做优化，解决数据倾斜问题
kudu数据删除
大表不要delete，不要犹豫直接drop，在create吧；磁盘空间会释放的
关于impala + kudu 和 impala + parquet
网上很多分析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 参数调节
FlagDefaultModify After描述–block_cache_capacity_mb51212G 分配给Kudu Tablet服务器块缓存的最大内存量。（虽然较高的值有助于提高读写性能，但是不要将 block_cache_capacity_mb 提高到内存压力阈值以上,因为这将导致即使写吞吐量很低，Kudu也会频繁刷新,建议将block_cache_capacity_mb保持在内存压力阈值的50%以下）
提高读写性能, 改值建议为 memory_limit_hard_bytes 的 30% 到 50%.
–-memory_limit_hard_bytes429496729642G 写性能，控制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_threads124 维护管理器线程池的大小。对于旋转磁盘，线程数不应超过设备数。（官网建议的维护管理器线程数是数据目录的3倍）
默认为1，调成24 (我们虽然是单块盘，但是ssd) (机械盘：一个数据盘，分配一个1，几个数据盘配几个)
–default_num_replicas3每个tablet的默认副本数–log_dir/tmp存放Tablet Server 日志文件–memory_pressure_percentage–flush_threshold_mb这个在低版本可以作为调优依据，现在系统默认也是可以的，不用调也可以。–memory_limit_soft_percentage可使用内存比例，如果脏数据特别大，kudu总内存超过一定限制，kudu就拒绝写入了，因为他有太多脏数据要刷磁盘了，但是脏数据太多，超过，或者即将超过允许使用的内存总数，那么就拒绝写入了max_clock_sync_error_usec1000000020000000 设置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
可以看看这个 Re: Imroving the insert peformance with INSERT INTO SELECT - gFlagfile
2.针对kudu写入能力的性能测试，通过几个参数观察 qps,latency,error_rate
Apache Kudu - Benchmarking and Improving Kudu Insert Performance with YCSB
里面特别提到 flush_threshold_mb 调成20G，效果显著，但是我没有测过。
3.写入性能差，写入失败，有的同学说是内存不足的问题，需要加内存100G。
这个思路完全错误，如果是读性能差，加内存，写入差要分析kudu写入数据过程，分析软件、硬件。
加内存有用，但是加完内存后，只会将脏数据在内存中堆积的越来越多。并没有落盘。
完整的思路是，软件->操作系统->硬件 这三层来展开分析。软件本身差，操作系统(比如内核参数问题)问题，硬件瓶颈。这么去分析。
kudu参数优化设置，让集群飞起来
根据数据体量，结合集群各节点的CPU、内存、磁盘的表现，合理优化设置kudu参数，让集群飞起来~
如有雷同，纯属借鉴~
1.Kudu后台对数据进行维护操作，如写入数据时的并发线程数，一般设置为4，官网建议的是数据目录的3倍 Kudu Tablet Server Maintenance Threads 这个参数决定了Kudu后台对数据进行维护操作，如写入数据时的并发线程数。并发数越大，吞吐量越高，但对集群计算能力的要求也越高。默认值为1，表示Kudu会采用单线程操作；对于需要大量数据进行快速写入/删除的集群，可以设置更大的值。该值可以设置跟计算节点的数据磁盘数量和CPU核数有关，一般来说，建议设置为4以获取比较均衡的性能，最大不超过8。 参数：maintenance_manager_num_threads
2.分配给Kudu Tablet Server块缓存的最大内存量，建议是2-4G Kudu Tablet Server Block Cache Capacity Tablet的Block buffer cache，根据集群内存配置和数据量规模设置。一般建议至少2GB～4GB。 参数：block_cache_capacity_mb
3.Tablet Server能使用的最大内存量，有多大，设置多大。 tablet Server在批量写入数据时并非实时写入磁盘，而是先Cache在内存中， 在flush到磁盘。这个值设置过小时，会造成Kudu数据写入性能显著下降。 对于写入性能要求比较高的集群，建议设置更大的值（一般是机器内存的百分之80） Kudu Tablet Server Hard Memory Limit Kudu的Tablet Server能使用的最大内存。 参数：memory_limit_hard_bytes
4.参数决定了Kudu能够同时打开的操作系统文件数。不设置则使用系统的ulimits值，设置后会覆盖系统的设置。 需要根据集群的规模及并发处理能力，非常谨慎的设置这个值。 参数：Maximum Process File Descriptors
5.参数设置了每个Tablet的默认复制因子，默认值为3，表示每个表的数据会在Kudu中存储3份副本。 我们可以根据需要修改这个全局默认值，也可以在建表语句中通过’kudu.num_tablet_replicas’属性来设置每个表的副本数， 参数：kudu.num_tablet_replicas=1
6.tserver宕掉后，5分钟后没有恢复的情况下，该机器上的tablet会移动到其他机器 参数：--follower_unavailable_considered_failed_sec=300
7.超过参数时间的历史数据会被清理，如果是base数据不会被清理。而真实运行时数据大小持续累加，没有被清理。 参数：--tablet_history_max_age_sec=900
8.hash分区数量 * range分区数量不能超过60个（1.7.0版本之后没限制了）
9.设置block的管理器为文件管理器（默认是日志服务器） 解释：并非所有文件系统格式都需要设置该选项。ext4、xfs格式支持hole punching（打孔），所以不需要设置block_manager=file，但是ext3 格式需要。可以通过df -Th命令来查看文件系统的格式。 参数：--block_manager=file
10.设置ntp服务器的时间误差不超过20s（默认是10s） 参数：max_clock_sync_error_usec=20000000
11.设置rpc的连接时长（默认是3s，建议不要设置） 参数：--rpc_negotiation_timeout_ms=300000
12.设置rpc一致性选择的连接时长（默认为1s，建议不要设置） 参数：--consensus_rpc_timeout_ms=1000
13.记录kudu的crash的信息 解释： Kudu在遇到崩溃时，使用Google Breakpad库来生成minidump。这些minidumps的大小通常只有几MB，即使禁用了核心转储生成，也会生成， 生成minidumps只能在Linux上建立。 minidump文件包含有关崩溃的进程的重要调试信息，包括加载的共享库及其版本，崩溃时运行的线程列表，处理器寄存器的状态和每个线程的堆栈内存副本， 以及CPU和操作系统版本信息。 Minitump可以通过电子邮件发送给Kudu开发人员或附加到JIRA，以帮助Kudu开发人员调试崩溃。为了使其有用， 开发人员将需要知道Kudu的确切版本和发生崩溃的操作系统。请注意，虽然minidump不包含堆内存转储，但它确实包含堆栈内存， 因此可以将应用程序数据显示在minidump中。如果机密或个人信息存储在群集上，请不要共享minidump文件。 参数： --minidump_path=minidumps --max_minidumps=9 （默认是在设置的log目录下生成minidumps目录，里边包含最多9个以dmp结尾的文件，无法设置为空值，需要注意的是如果自定义minidump文件， 在master不能启动的情况下，需要将该目录中的文件删除）
14.Stack WatchLog 解释：每个Kudu服务器进程都有一个称为Stack Watchdog的后台线程，它监视服务器中的其他线程，以防它们被阻塞超过预期的时间段。 这些跟踪可以指示操作系统问题或瓶颈存储。通过WARN日志信息的跟踪（Trace）可以用于诊断由于Kudu以下的系统（如磁盘控制器或文件系统）引起的根本原因延迟问题。
15.cdh设置多master 参数：--master_addresses=cdh01:7051,cdh02:7051cdh03:7051
16.kudu出现启动速度特别慢 解决办法： 1、取消所有配置参数（除了资源、时间同步） 2、升级版本到kudu1.6.0 3、client必须停止（client不占用io的情况，3台机器，每台机器60G，127分区数量，启动速度3分钟） 4、查看io使用情况 iostat -d -x -k 1 200
17.单hash分区最大是60
18.安装kudu过程中，会要求CPU支持ssc4.2指令集，但是我们的虚拟机cpu没有这个执行集，所以无法安装
19.设置client长连接过期时间 参数：--authn_token_validity_seconds=12960000（150天） 注意：设置到tserver的配置文件中
20.tserver和master的wal和data目录要分隔（或者是目录设置为lvm卷轴） 原因：wal目录只能设置为1个 参数：--fs_wal_dir_reserved_bytes 解释： Number of bytes to reserve on the log directory filesystem for non-Kudu usage. The default, which is represented by -1, is that 1% of the disk space on each disk will be reserved. Any other value specified represents the number of bytes reserved and must be greater than or equal to 0. Explicit percentages to reserve are not currently supported 用于非kudu都使用的日志目录文件系统的字节数，默认情况下是-1，每个磁盘上的磁盘空间的1%将被保留，指定的任何其他值表示保留的字节数，必须大于或等于0。
21.设置用户权限，能移动tablet 参数：--superuser_acl=*
【小编废话】
在日常开发中，还需要结合集群的实际情况，任务的差异性，结合任务日志，针对性的调整参数，两个原则：
原则1：当资源紧张时，重要任务优先（需结合调度时间优化）。
原则2：在保证原则1的前提下，提升整个集群的效率。当时效要求高时，尽量压缩总体运行时间；当稳定性要求更高时，错峰执行，负载均衡。
参数调优核心总结为两个字：平衡。
1、时效和稳定性的平衡；
2、资源的平衡，在某一时间点，集群的内存、io、cpu等负载均衡。 原文链接：https://blog.csdn.net/weixin_39032019/article/details/110534549