使用 Kudu Impala作为数仓，使用过程中遇到一些印象深刻的问题，以此记录为笔记作为总结
Kudu Impala的decimal 数据类型问题：
Kudu在1.7 及以上版本才支持 decimal 数据类型，impala中decimal数据类型最大长度是38，无默认长度，并且精度位不能大于长度，而oracle中支持number(1,2)类型，可存入空值或0,并且oracle中可以使用默认长度number(none,none)；
调整Kudu单表最大300列限制：
以往业务系统中有700多个字段的单表，Kudu官网资料建议Kudu建表字段数不要超过300列，很多人写的博客资料直接写上Kudu字段不能超过300列，实际Kudu表字段数可调整：
1）在CDH 的kudu管理界面的配置项，Master中有一项配置：gflagfile的Master高级配置代码段 有一组参数：
-max_num_columns=300
-unlock_unsafe_flags=flase
更改这两项参数可更改Kudu单表最大限制数：
-max_num_columns=800
-unlock_unsafe_flags=true
更改重启后即可创建不超过800列的表；
注：虽然Kudu官网建议最大列数是300，但是基于现实情况我们可以不接受这种建议。
使用Impala语句建表，可直接指定每列的数据压缩格式
建表示例：
CREATE TABLE testdb.mytest(
id STRING ,
decimalvalue DECIMAL(38,18),
lz4test STRING COMPRESSION LZ4,
snappytest STRING COMPRESSION SNAPPY,
zlibtest STRING COMPRESSION ZLIB,
PRIMARY KEY (id)
) PARTITION BY HASH(id) PARTITIONS 3 STORED AS KUDU ;
Kudu Impala时区问题：
Kudu Impala已更改配置了时区的情况下，发现一个很奇怪的问题：
1）kudu使用UNIXTIME_MICROS类型保存时间，Impala中映射为timestamp，在程序中使用Kudu API插入的时间与使用Impala SQL插入的时间相差28800000毫秒；
2）相差28800000毫秒的原因是：
8*60*60 = 28800 * 1000 = 28800000；
即：
（1）System.currentTimeMillis()是从1970-01-01开始算的毫秒数（GMT），kudu API 是采用微秒数，所以时间需要乘以1000；
（2）由于中国是在东8区，所以转成Long型需要再加8个小时，即 86060 = 28800秒 * 1000 = 28800000毫秒;
以上都是实际项目中遇到的问题，原创不易，转载请注明出处。
