解决了上篇文章的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的数据缺失的一次处理
这个数据过大。。。。。值得深思，那肯定和上面的473M>256M有关。难道。。。。是把473M切成了2个切片，只取了一个切片？不可能，阿里的人不会这么lowb，感觉快要接近真相了，研究下源码。
好吧，我不是发现问题就去研究源码。我是百度了才去看源码
DATAX hdfsreader orc格式读取丢数问题修复及验证 - 简书 原文章
fix orcFileStartRead by wangchuande · Pull Request #262 · alibaba/DataX · GitHub 解决文章。
左边获取切片个数 splits 然后 直接开始搞第一个切片？？？？后面切片不要了？？？
改成右边那个for循环就ok
这个最基本的解决思路。
还有另外一种思路。上面我还有一个site表是正常的。说明切分任务，最后文件也会切分，切分成多个 自然就会<256M了。还有一种方式就是压缩例如snappy。当然这都是治标不治本。
为什么我要说下这个方法，这个涉及到后面导数提速。。。。下篇文章再说
