datax导数-＞hdfsReader到postgresql数据丢失？

解决了上篇文章的tpg的特殊字符invalid byte sequence for encoding "UTF8": 0x00 问题。

原以为可以开开心心等结果就好。

最后发现导的8个表中有4个表数量对不上？？？？简直不敢想象，仔细看了下dolphin上的日志，一切正常。

背景说下

sms_vendor_contact_t：oracle:8198715  hive:8198715  tpg:4195000  少数据

sms_vendor_site_t:     oracle:9578067  hive:9578067  tpg:9578067  没问题

这就奇了怪了。两个表数量都很多，为啥一个数据少了 一个数据多了？两个没啥区别呀。

重新跑一遍。还是4195000.。。。那肯定是有datax有问题了。先仔细回想下，

这个site表比较特殊呀。因为这个表当时数据比较多 跑的比较慢，采用了splitPk的方式,分了10个channel,难道是这？

下面的473M激起了学习hadoop hive的回忆 256 128.... 好吧其实是我百度了有个话提醒了我

datax的数据缺失的一次处理_宛风轻云的博客-CSDN博客_datax数据缺失

这个数据过大。。。。。值得深思，那肯定和上面的473M>256M有关。难道。。。。是把473M切成了2个切片，只取了一个切片？不可能，阿里的人不会这么lowb，感觉快要接近真相了，研究下源码。

好吧，我不是发现问题就去研究源码。我是百度了才去看源码

DATAX hdfsreader orc格式读取丢数问题修复及验证 - 简书    原文章

fix orcFileStartRead by wangchuande · Pull Request #262 · alibaba/DataX · GitHub   解决文章。

左边获取切片个数 splits 然后 直接开始搞第一个切片？？？？后面切片不要了？？？

改成右边那个for循环就ok 

这个最基本的解决思路。

还有另外一种思路。上面我还有一个site表是正常的。说明切分任务，最后文件也会切分，切分成多个 自然就会<256M了。还有一种方式就是压缩例如snappy。当然这都是治标不治本。

为什么我要说下这个方法，这个涉及到后面导数提速。。。。下篇文章再说

如果帮到你，点个赞，谢了。