SQOOP可能会导致HDFS分片数量过多的总结

使用多少个mapreduce来进行移植数据，例如：
./sqoop import --create-hive-table --hive-import --hive-overwrite --connect jdbc:oracle:thin:@XXX.XXX.XXX.XXX:1521:orcl --username name --password pwd --table tablename --hive-database hivedatabasename -m 5
上面使用了5个任务，然后数据在每个任务不满128M的时候，存储文件也会分成5份，在数据量不是很大的情况下，还是应该只用1个任务来跑，这样文件的分片比较少，为什么要分片数量少呢？





比如下面就是用1个任务跑的





当后面用sparksql进行表数据的清洗、筛选和合并的时候，
例如我们把每日的数据最终合并到年表中，当使用
insert into tableyear select * from tableday的方式在sparksql中执行时，hive会自动把日表的文件拷贝到年表中，就会出现以下奇景：





我们发现全部是拷贝的
然后当我们在sparksql中执行某些任务的时候，那么就需要从每个数据分片查询，这都是时间，以2个月为例，每天用5个mapreduce进行sqoop移植数据，最终产生了300多个数据分片，然后执行的sparksql的count表数据的时候，我们就会发现产生了300多个Task










当存在300多个数据分片的时候进行count，我们发现就算那个分片就算是0B，至少也会损耗将近10ms的时间，如果能将分片变成1/5，比如少200个分片，以上面例子为例节省的时间就可能是2s，当然这种计算不一定合理，但至少印证了数据分片数量过多对速度上的影响。
上面的数据量大概是600万，花了5秒。
而我们另外一个数据600多万，比它还多一点数据，执行的时候第一次2秒左右，后面每次执行都1秒钟都不到，就是因为数据分片少










因为执行的任务数量少了，所以效率大幅度提高了：





总结：

如果数据比较少的情况下，我们更加建议，在关系型数据库将数据合并之后再使用sqoop移植，比如oracle我们上面的表，1天的数据本身就只有10万条左右，大小在70M左右，根本没满128M，这个时候就算一天一个HDFS文件，在后续合并区间段（比如历史所有5年的数据全部放在一个表）太长的情况下，都会显得浪费，不如把1个月的数据300万条首先的关系型数据库合并到大表，大小总共就1个G，如果分配合理，最终在hdfs中只需要产生10个左右的数据分片，2个月产生20个，相比上面我们产生了300多个数据分片，最终的效率肯定不可同日而语！！！
当数据量比较多，比如一天数据本身本身就有500万甚至上千万数据的时候，一天的大小可能就会与几个G甚至几十个G，那么这个时候我们就算用多个mapreduce任务也没关系，当然任务还是不能太多，不然很可能出现每个任务的最后产生的文件离128M差距太多，还是会对性能产生一定的影响！！！
性能优化看来是一条疯狂的道路！！！

本文出自 “一枝花傲寒” 博客，谢绝转载！