Kudu使用最佳实践以及踩坑记录

Kudu表结构设计最佳实践

1.字段设计

• 字段数量最好不要超过300个
• 除主键外,其他字段可以为空
• 每一个字段均可以设置自己的编码以及压缩方式
• Kudu1.7.0及其高版本,已经支持Decimal字段类型,适用于金融和特定的算数运算场景

2.主键设计

• 建表必须包含主键,主键字段必须列在Schema的最前端
• 建表后,主键无法更改,只能重建表
• 不支持自增列
• 主键不能为空,并且不能为boolean/float/double类型
• 主键的值无法被更新,但是可以被delete后,re-insert
• 主键即索引,tablet中的所有行都按照主键排序.查询时,对主键指定相等或范围的谓词,Kudu扫描表的时候会过滤掉不满足条件的行

3.分区设计

• 不允许更改创建后的分区表,但可以添加或删除range分区
• 分区方式:hash分区,range分区以及组合分区
• 根据自身业务场景,选择合适的分区方式,让读与写操作在所有tablet server上均匀分布
• 根据应用查询的语句,设计合理的主键以及分区,保证读取数据时扫描最小的数据集
• 分区数量的设置,根据官方文档,每个分区的大小尽量控制在4G左右(单个tablet server最大存储8T/管理的tablets数量最大2000个≈4G),如果表数据量未来估算在40G左右,那么分区数量可以设置10个

Impala与Kudu Client场景选择最佳实践

• 就查询来说,Impala的查询速度要快于Kudu Client的scan数据扫描,建议使用Impala
• KuduClient原声API中update/delete/upsert只能根据主键操作,如果需要其他条件则需要查询一下,拿到主键再进行操作,所以不如impala写sql方便,如果同时使用impala和kuduclient最好做资源隔离

Kudu API性能优化

• 尽量采用MANUAL_FLUSH,性能最好,如果有写入Kudu错误,flush()函数会抛出异常
• 在性能要求不高的情况下,AUTO_FLUSH_SYNC也是一个很好的选择
• 仅仅在测试环境下使用 AUTO_FLUSH_BACKGROUND, 不考虑异常处理时候代码可以很简单, 性能也很好. 在生产环境下不推荐使用的原因是: 插入数据可能会是乱序的, 一旦考虑捕获异常代码就很冗长

踩坑记录

• 时钟服务NTP配置不合理,会导致Kudu服务直接崩溃,建议根据官方的推荐来配置NTP,另外可以通过修改参数max_clock_sync_error_usec值,来提高Kudu对时间偏差的容忍程度
• 在Impala中对Kudu表进行alter table A rename to B，只会更改impala的元数据，而不会更改任何Kudu的元数据，可以通过先修改Impala元数据alter table A rename to B 后，再修改Kudu元数据alter table A set TBLPROPERTIES（’kudu.table_name’=’B’）
• 没有rebalance功能,需要手动做balance
• 在Kudu1.6.0之前，如果tablet server的某个磁盘坏了，那么整个tablet server就要重新format了，如果你的集群版本大于等于1.6.0并且损坏的盘并非WAL/Meta盘，那么你可以通过kusu fs update_dirs
• 关于range分区踩坑:一
  
  再看一下设置range分区信息,注意这里只设置了aa-cc的range分区
  

接着再看一下源表的数据量和部分数据

最后看看落盘到kudu表里的信息

总结: range分区没有覆盖的数据不会落盘到kudu表中,且kudu表在upsert时根据主键自动判断是update操作还是insert操作,主键重复的数据进行update操作

• 关于range分区踩坑:二
  第二个场景是关于分区的数据类型对应关系的小坑,先看一下设置的分区信息

理论上这样分区已经对id数据进行了全覆盖,但是实际上落盘数据为0.

总结:在做数据导入时,主键的数据类型要一一对应,若数据类型不对应,数据无法落盘(oracle的number类型进行数据类型匹配时要特别注意)