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毫秒;
但已经成功更改配置了Kudu 和 Impala的时区，为什么还会这样？还未找到原因，有知道原因的道友欢迎留言或私信。
以上都是实际项目中遇到的问题，原创不易，转载请注明出处。