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去除了。 

實際導入語句以下：