为什么80%的码农都做不了架构师？>>> 
使用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去除了。
实际导入语句如下：