Impala执行带DISTINCT的INSERT INTO后目标表行数多于源表原因问询

• 写入类型问题：你使用的是INSERT INTO追加写入，而非INSERT OVERWRITE覆盖写入。如果目标表db.test1在执行插入前已有存量数据（包括本次写入的分区或者其他分区的历史数据），最终统计的全表行数自然会大于源表db.test2中a=201011过滤后的行数。
• 统计范围不匹配：如果你统计源表行数时仅统计了a=201011分区的数据，但统计目标表行数时统计的是全表所有分区的数据，会出现目标表行数更多的情况。
• 动态分区字段顺序错位：你使用了PARTITION(a,b,c,d,e,f)的动态分区写入逻辑，Impala要求动态分区插入时，select查询结果的最后N个字段（N为分区列数量，这里是6）必须和分区列的顺序完全对应。如果db.test2的字段顺序中a~f不是排在最后6位，select *返回的字段顺序不符合动态分区的要求，会导致字段插入错位，原本去重后的源表行在插入目标表后字段值错乱，出现大量不重复的新行，最终行数多于源表。
• 统计信息不准确：如果你没有使用select count(*) from 表名的全量扫描方式统计行数，而是直接使用了Impala元数据中缓存的表统计信息，当元数据统计信息未更新时，会返回错误的行数值。可以执行INVALIDATE METADATA db.test1; INVALIDATE METADATA db.test2;后重新统计行数确认。
• 字段类型隐式转换异常：如果源表和目标表的同名字段类型不一致，插入时的隐式转换可能会导致原本重复的行变成不重复行。比如源表某字段是高精度的DECIMAL(38,10)，目标表对应字段是DECIMAL(18,2)，源表中只有小数后第三位不同的行在distinct时会被判定为不同行，插入后目标表保留的是转换后的所有行，也可能出现行数多于预期的情况。
• 任务重试导致重复写入：如果插入任务执行过程中出现过失败重试，且目标表未开启ACID特性，失败的任务可能残留部分写入的文件，重试后又写入了一次完整的结果，最终导致目标表数据重复，行数变多。

内容的提问来源于stack exchange，提问作者DrGenius