【原创】大叔经验分享（63）kudu vs parquet

一 对比

存储空间对比：

查询性能对比：

二 设计方案

将数据拆分为：历史数据（hdfs+parquet+snappy）+ 近期数据（kudu），可以兼具各种优点：

• 1）整体低于10%的磁盘占用；
• 2）更少的查询耗时；
• 3）近期数据实时更新；
• 4）近期数据可修改；
• 5）kudu集群重启时间降低90%；
• 6）impala并行scan：scan kudu + scan hdfs；

三 改造方案

利用视图

create view v_table as
select * from parquet_table where dt < 'seven days ago'
union all
select * from kudu_table where dt >= 'seven days ago';

client将kudu_table替换为v_table即可；

四 其他

kudu问题：

• flume kudu sink使用kudu client版本过低，有bug，不会自动刷新token，7天之后会因为token失效报错；升级kudu client后可以解决bug，但是kudu client和flume使用的guava库版本有冲突；
• 按dt分区后tablet数量过多，磁盘占用空间过大，内存占用过多；
• 因为tablet数量多，磁盘空间大，每次kudu集群重启需要10-20分钟做initialize；
• kudu内存占用过多时会拒绝写操作；
• 使用kudu作为单一数仓同时支持写入和查询，很容易相互影响，大量写入影响查询，大量查询影响写入，会导致数据丢失或者查询慢；
• kudu支持更新，一个delete或者drop就可以把所有数据全部删掉，作为单一数仓比较危险；