Kudu Impala使用過程中印象深刻的問題總結

使用 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毫秒;
以上都是實際項目中遇到的問題，原創不易，轉載請注明出處。