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分区踩坑:一
kudu表信息.png
再看一下设置range分区信息,注意这里只设置了aa-cc的range分区
range分区信息
接着再看一下源表的数据量和部分数据
原始数据.png
原始数据信息.png
最后看看落盘到kudu表里的信息
落盘数据.png
总结:range分区没有覆盖的数据不会落盘到kudu表中,且kudu表在upsert时根据主键自动判断是update操作还是insert操作,主键重复的数据进行update操作
-
关于range分区踩坑:二
第二个场景是关于分区的数据类型对应关系的小坑,先看一下设置的分区信息
int分区.png
理论上这样分区已经对id数据进行了全覆盖,但是实际上落盘数据为0.
2019-08-31_104627.png
总结:在做数据导入时,主键的数据类型要一一对应,若数据类型不对应,数据无法落盘(oracle的number类型进行数据类型匹配时要特别注意)
