Sqoop

柔情只为你懂 2022-03-15 02:24 249阅读 0赞

Sqoop优化  
参考这个https://blog.csdn.net/u010185220/article/details/79085119

如何判断读取的数据是否完整？可以采用，感觉完全没用啊。。。只能通过hdfs 产看文件大小或者count计数  
或者sum求几个重要指标这类比较实在。

也可以使用count \* 计算是否行数一样

为什么多个map之后会有分区为空的解释  
[https://blog.csdn.net/lyn1539815919/article/details/52400555][https_blog.csdn.net_lyn1539815919_article_details_52400555]

sqoop 中split by 导致的数据倾斜问题  
[https://blog.csdn.net/weihua0722/article/details/78551070][https_blog.csdn.net_weihua0722_article_details_78551070]

**关于split-by字段的选择**  
用自增的字段，或者date时间字段来进行划分，这个更加有效率一些。实际测试发现，切分字段均匀非常重要，不然产生数据倾斜，map字段增加的效果会大打折扣。所以一般最好用自增的id，不行也要是数字或者时间格式，string切分效果很差。

之所以慢，sqoop中的sql语句相当于是mysql中的，mysql中的数据过多，那么查询也会相应的变慢，就比如如果没用到索引的话查询都是秒级的。所以你在这里max,min啥的查询都会满，回去自己补补mysql高级索引部分。

同时很奇怪的一点，增加map个数后反而运行速度更慢，猜测是每个map可以处理的数据量有一个值，大约在3G-4G,不然更多的map初始化就会挺消耗时间。少了的话运行的量增多也会变慢。当然这个要根据具体的sql来确定，如果sql 复杂就要更小的数据块了。同时注意，如果启用了split-by的话，从一个变成2个map可能反而运行会更慢，原因是split-by还要经过最大最小值的计算，所以如果数据量不是很大的情况没有必要采用，只是浪费时间。

select \* 虽然一直说浪费资源，这个是因为每次查询的时候，都会先把字段拼接到一起然后开始执行sql查询，但是如果你查询的本来就是全表字段，你还一个个写的话就没有必要了，这个时候好像“ \* ”的效率会更高一点。但是查询后可以发现，\* *之所以不被推荐，虽然要在内存中加载表结构，但这个影响很小，主要是* 的话用不到索引，这样查询的时候效率会降低或者换句话说查询占用了更多的IO性能，而且后期维护的话不太方便。

要熟悉和了解map 和reduce如何划分，如何修改，如何运行，我怎么知道靠

hive优化，有实操的，这个棒  
[https://blog.csdn.net/hellojoy/article/details/81211138][https_blog.csdn.net_hellojoy_article_details_81211138]

**union**  
就是从不同的表里面提取数据放到一个表里面，比如第一行数据来自A , 第二行数据来自B, 这种就要求每个sql查询的列数要相同，类型要形同，union all 表示不去除重复数据，反之去除。因为union要去重，所以会对其进行去重的操作，如果不需要或者可以肯定没有数据重复的话用union all 代替可以提高效率

**sqoop中字段的含义**  
null-string 的使用情况  
作用在于如果数据库传来的数据是null的话，不加这个东西就会存储为null字段，加了之后就以‘\\n’的形式存在  
[https://blog.csdn.net/jxlhc09/article/details/16856873][https_blog.csdn.net_jxlhc09_article_details_16856873]

zerodatetimebehavior=converttonull配置的含义，传入的时间格式不对的话可以转化为null  
[https://blog.csdn.net/sinat\_30397435/article/details/72518215][https_blog.csdn.net_sinat_30397435_article_details_72518215]

Hive多个表导入 [https://blog.csdn.net/niityzu/article/details/42917223][https_blog.csdn.net_niityzu_article_details_42917223]  
注意这个时候不识别一些字段，比如split-by, where 等字段，全表导入有待测试，就是导入的时候是分别创建不同的表还是可以导入到一张表里面，后面可以测试一下，同样的，因为多个表导入的话不支持split by 字段，所以只能默认是1，这样的话效率也比较低，所以可以采用union的方式整合起来

实操过程中，遇到情况是在计算min max的时候消耗了非常多的时间，所以考虑用boundary-query来取代sqoop的计算，缺陷在于要估算每日的数据，但是优点非常明显，省去计算最大最小值的时间。参考官方文档和这个  
[https://www.oreilly.com/library/view/apache-sqoop-cookbook/9781449364618/ch04.html][https_www.oreilly.com_library_view_apache-sqoop-cookbook_9781449364618_ch04.html]  
测试的时候并发产生了很好的效果，但是在晚上运行的时候仍然很慢，每个map执行的速度都很低，不知道为什么，主要应该是资源的缘故，那个时间点跑的任务数很多，所以导致每个map分配的资源少了还是等待的时间变长了？yarn动态分配资源，所以在资源运行紧张的时候相对应的分配的cpu和内存等都会减少，相应的计算就会变慢。

目前发现公司sqoop导入存在的问题。每天的数据都是全量导入，所以随着数据量越来越大，导入的速度越来越慢，但是要求每天都要保存全量表，本来我想的是优化一下每天改成增量导入减少数据量，但是要求是每日全量日志，那么一开始考虑的是insert overwrite 改成insert  
into 追加导入的方式，但是这种导入的话如果重跑会造成数据的重复，不予采用，于是想到建立一个临时表保存昨天的数据，然后每天union all今天sqoop传入的数据，但增量导入的话要指定增量的时间或者自增id，因为自增id暂时没有想到办法动态获取，如果采用每天sql查询的话这样可能会浪费更多资源？不对吧要不试试。目前采用的是增量时间的方式，但是也存在缺陷，是这种方法不知道为什么导入的数据量不大，但是导入的速度很慢，不知道是因为全表扫描的关系还是？

脑子有包，这个地方实测过，id比时间的更好，速度差别在一倍吧，猜测是索引的缘故，另外自增id是因为字段last value 的需要，这个应该可以通过前面获取变量的方式来获得，但是这有点多此一举，所以说脑子笨。。。 sqoop里面直接加上限制条件 id >20334532(某一天开始的id),这样以后导入都从这一天开始导入，虽然也会有重复数据，但是数据量会重新计算大大减少，目前能想到的话吧，一种是每次运行前获取上次的id，不知道怎么整，另一种就是直接写死，可以等数据量很大的时候再进行修改，感觉不太好哦，可是这样省事啊。。。

感谢这位答主解决了疑惑！果然是这个问题  
[http://bigdata.51cto.com/art/201703/535606.htm][http_bigdata.51cto.com_art_201703_535606.htm]  
生成的时间是string类型的，但是sql里面是datetime类型，进行比较的时候要进行转换，所以可以cast（time as datetime）这样的话可以大大缩短时间。鬼哦，自己测试的有问题，这是下午集群闲得慌，没转换也没差，MMP的，害我高兴半天

[https_blog.csdn.net_lyn1539815919_article_details_52400555]: https://blog.csdn.net/lyn1539815919/article/details/52400555
[https_blog.csdn.net_weihua0722_article_details_78551070]: https://blog.csdn.net/weihua0722/article/details/78551070
[https_blog.csdn.net_hellojoy_article_details_81211138]: https://blog.csdn.net/hellojoy/article/details/81211138
[https_blog.csdn.net_jxlhc09_article_details_16856873]: https://blog.csdn.net/jxlhc09/article/details/16856873
[https_blog.csdn.net_sinat_30397435_article_details_72518215]: https://blog.csdn.net/sinat_30397435/article/details/72518215
[https_blog.csdn.net_niityzu_article_details_42917223]: https://blog.csdn.net/niityzu/article/details/42917223
[https_www.oreilly.com_library_view_apache-sqoop-cookbook_9781449364618_ch04.html]: https://www.oreilly.com/library/view/apache-sqoop-cookbook/9781449364618/ch04.html
[http_bigdata.51cto.com_art_201703_535606.htm]: http://bigdata.51cto.com/art/201703/535606.htm