Sqoop从Oracle导入到Hive(小坑)

使用sqoop从oracel导入数据到hive数据错位，第一个想到的问题就是可能分隔符形成的，

默认使用'\001'来切分字段，使用'\n'来切分行，这一切看起来挺好，可是若是导入的内容中包含了'\001'或者'\n'就会致使数据错位的问题。这个问题人家sqoop早就想到啦，因此导入数据到hive的时候就支持一个命令参数--hive-drop-import-delims，这个命令参数是干吗的呢，

官方解释就是： 去除字段中全部的\n,\r\01等特殊字符，

OK，这不正是想要的么，万事大吉，好东西，觉得高枕无忧了。

但是问题仍是来了，数据错位了致使记录数几乎翻倍，这缘由很明显呀，数据错位了，但是--hive-drop-import-delims不是已经把特殊字符给去掉了么，怎么还会和'\001','\n'冲突呢，

查看hive表的数据原文件，发现字段分隔很正常(即便用\001都分隔正确了)，可是\n确实存在，不少换行呀，字段内容的换行竟然没去掉？ 这个--hive-drop-import-delims不是坑么，

好吧，这个冲突暂且放下，既然\n没有删掉，那么行记录就不用\n了 改用\002吧

想象是好的！

一执行直接报异常：hive目前仅支持\n分隔行记录(坑爹！！！)

最终，找呀找，发现原来那些\n没有去除的字段是CLOB字段。--hive-drop-import-delims对CLOB字段不起做用。

找到缘由了解决起来就简单了：

首先解决方案是 直接在sql语句中将  clob字段使用to_char函数，而后使用replace函数将全部的换行字符替换 replace(to_char(FIELD),char(10),' ')   注意：oracle中换行使用char(10)，就这样解决了问题！

可是以后用相同方法处理大字段的clob时新问题又来了，大致意思就是to_char函数支持clob长度为4000如下的转换，若是clob内容长度超过4000就报缓冲区不足！（坑！）

后来找呀找，发现了这么个参数--map-column-java

意思就是将SQL中的字段类型转换成JAVA 的string类型，那么我所须要的就是将sql中的clob字段转换成String类型，这样--hive-drop-import-delims这个参数就能够对该字段起做用了，能够将\n去除了。 

实际导入语句以下：