sqoop入hdfs出現No primary key could be found forXX的問題記錄 發布於 11 個月前 (05月28日)
- 2020 年 4 月 9 日
- 筆記
如果使用過sqoop工具，把關係型資料庫(ORACLE/Mysql)的數據導入到hdfs時，應該也會出現一些問題..如果還不知道的話，可以先到http://199604.com/1102( sqoop的簡單用法)，我這篇文章簡單入門。
最近，出現最多的問題，應該是報這個錯–>
ERROR tool.ImportTool: Error during import: No primary key could be found for table IOT_DIG_CAT_COUNT_BAK_1904. Please specify one with –split-by or perform a sequential import with '-m 1'.
從報錯的資訊提示可以看出，他表示您這個表找不到主鍵，需要我們使用把–split-by或者把參數-m設置為1。
從這個報錯的資訊里，其實也可以深入聊一下，就是 –split-by與-m的關係(小白開發也可以是垃圾開發，我寫的你們最好別信)：
1.split-by 根據不同的參數類型有不同的切分方法，如int型，Sqoop會取最大和最小split-by 欄位值，然後根據傳入的-m（–num-mappers）來確定劃分幾個區域。比如select max(id),min(id) from得到的max(id)和min(id)分別為1000和1,而這時–num-mappers（-m）為2的話，程式就會分成兩個map的區域，（1,500），（501-1000），同時也會分成2個sql給2個map去進行導入操作，其實就是分頁查詢…sql類似 select xxx欄位 from queryTableName wher id >=1 and id <=500,後面的sql省略..然後你-m的2個map就去執行這兩個sql。
2.這個問題，應該也很常見，因為我先在公司，很多表都是無主鍵的，所以有時候split-by 欄位不是int(number)類型，我解決的辦法就是最無奈的辦法了，只能用一個map 去執行，split-by不設置。時間效率就慢了下來吧。ps：當-m 設置的值大於1時，split-by必須設置欄位
3.如果split-by 設置的欄位是int(number)類型，但是呢，你的數字不是連續的..這種情況有可能會造成 一些map執行數量比較多，一些比較少，從而造成了某些map消耗時間非常久，一些馬上執行完的情況，造成數據傾斜有可能報錯…
