kudu踩坑记之一

在开发过程中，难免会手误，由于在通过impala-shell建kudu表时候把bigint类型的字段写成了string，以致后面在计算时候报错。但由于该表有2亿的数据（交易明细表），不可能重新抽取，于是按照关系型数据库的思维来操作。

1、暂以A表示原表，新建一个正确的表B，
2、insert into B select * from A;(此步耗时2-3分钟,与机器性能有关)
3、然后drop A或者rename A to C.
4、alter table B rename to A
以上步骤完成后，在关系型数据（MySQL,Oracle等）是没问题的。

通过impala-shell也是可以查询到数据，但是后面程序在通过Kudu context读取kudu表数据的时候，一直读取不到数据,也不会报错。这个问题纠结了很久，于是去查阅了官方文档。
有如下说明：
Altering table properties only changes Impala’s metadata about the table, not the underlying table itself. These statements do not modify any Kudu data.

就是说,在impala-shell里面的alter table操作，只会更改impala的元数据，而不会更改任何kudu的数据。
可以通过ALTER TABLE B SET TBLPROPERTIES(‘kudu.table_name’ = ‘A’);

但是在impala-shell里面执行drop table操作，会删除kudu的表和kudu表里面的数据，同时也会删除kudu和impala的映射关系及impala元数据里面的表信息。

所以，如果遇到类似错误信息，可以drop table，再新建表，或者使用上述语法改名。
最好是先修改impala元数据(alter table B rename to A)，再执行ALTER TABLE B SET TBLPROPERTIES(‘kudu.table_name’ = ‘A’);

按理说这样就没问题了，暂未测试，有兴趣的自己测试。(亲，给个好评呗~)