使用sqoop import 命令從postgresql導(dǎo)入數(shù)據(jù)到hive中,發(fā)現(xiàn)數(shù)據(jù)行數(shù)變多了,但是任務(wù)沒有跑錯,非常奇怪。
導(dǎo)入語句為:
sqoop import
--connect jdbc:postgresql://*.*.*.*:5432/database_name
--username name111
--password password111
--table table111
--hive-import
--hive-database database111
--hive-table hive_table111
--hive-overwrite
--delete-target-dir
--hive-drop-import-delims
--null-string ''
--null-non-string ''
-m5
導(dǎo)入前pgsql數(shù)據(jù)量為3698條,但是導(dǎo)入后再hive中的數(shù)據(jù)量為3938,數(shù)據(jù)竟然變多了。最后發(fā)現(xiàn)將參數(shù)-m5,改為-m1即可解決問題。
為什么呢?
我們先來了解一下參數(shù)-m的含義以及sqoop導(dǎo)入的原理。
首先用戶輸入一個(gè) Sqoop import 命令,Sqoop 會從關(guān)系型數(shù)據(jù)庫中獲取元數(shù)據(jù)信息,比如要操作數(shù)據(jù)庫表的 schema是什么樣子,這個(gè)表有哪些字段,這些字段都是什么數(shù)據(jù)類型等。它獲取這些信息之后,會將輸入命令轉(zhuǎn)化為基于 Map 的 MapReduce作業(yè),這樣 MapReduce作業(yè)中有很多 Map 任務(wù),每個(gè) Map 任務(wù)從數(shù)據(jù)庫中讀取一片數(shù)據(jù),這樣多個(gè) Map 任務(wù)實(shí)現(xiàn)并發(fā)的拷貝,把整個(gè)數(shù)據(jù)快速的拷貝到 HDFS 上。
而決定切分成多少個(gè)map就是參數(shù)-m的作用,-m5代表切分為5個(gè)map,-m1代表切分為1個(gè)map,即不用切分。
而決定用什么字段來切分,就是用--split-by來制定的。當(dāng)sqoop import 沒有定義--split-by時(shí),默認(rèn)使用源數(shù)據(jù)表的key作為切分字段。
split-by 根據(jù)不同的參數(shù)類型有不同的切分方法,如int型,Sqoop會取最大和最小split-by字段值,然后根據(jù)傳入的num-mappers來 確定劃分幾個(gè)區(qū)域。比如select max(split_by),min(split-by) from得到的max(split-by)和min(split-by)分別為1000和1,而num-mappers(-m)為2的話,則會分成兩個(gè)區(qū)域 (1,500)和(501-1000),同時(shí)也會分成2個(gè)sql給2個(gè)map去進(jìn)行導(dǎo)入操作,分別為select XXX from table where split-by>=1 and split-by500和select XXX from table where split-by>=501 and split-by=1000.最后每個(gè)map各自獲取各自SQL中的數(shù)據(jù)進(jìn)行導(dǎo)入工作。
![](/d/20211018/6e2d3e5f2bcd0df5389b094fe16aab60.gif)
那回到最開始的問題,為什么切分?jǐn)?shù)目不一樣,結(jié)果就不一樣呢?理論上無論怎么切分,導(dǎo)入的數(shù)據(jù)都應(yīng)該是一樣的,但現(xiàn)在甚至還多了?這是因?yàn)椋脕砬蟹值淖侄尾挥押?,不是int型或者有排序規(guī)律的。
![](/d/20211018/8ff8aaf44edf95dc18a524f1b80b1381.gif)
這種id內(nèi)容是沒有排序規(guī)則的,比如本來10條id切兩份得到(5,5),現(xiàn)在切出來時(shí)(5,6),有一個(gè)id重復(fù)了,就導(dǎo)致數(shù)量變多了。
所以解決辦法有兩個(gè):
一是將 -m5 改成 -m1 直接不切分;
二是 --split-by制定另外的字段,換一個(gè)int型的或者有明確排序順序的字段。
除了以上這種原因?qū)е聰?shù)據(jù)變多,語句缺少 --hive-drop-import-delims 也可能導(dǎo)致問題的出現(xiàn),解決如下:
關(guān)于在sqoop導(dǎo)入數(shù)據(jù)的時(shí)候,數(shù)據(jù)量變多的解決方案。
今天使用sqoop導(dǎo)入一張表,我去查數(shù)據(jù)庫當(dāng)中的數(shù)據(jù)量為650條數(shù)據(jù),但是我將數(shù)據(jù)導(dǎo)入到hive表當(dāng)中的時(shí)候出現(xiàn)了563條數(shù)據(jù),這就很奇怪了,我以為是數(shù)據(jù)錯了,然后多導(dǎo)入了幾次數(shù)據(jù)發(fā)現(xiàn)還是一樣的問題。
然后我去查數(shù)據(jù)字段ID的值然后發(fā)現(xiàn)建了主鍵的數(shù)據(jù)怎么可能為空的那。然后我去看數(shù)據(jù)庫當(dāng)中的數(shù)據(jù)發(fā)現(xiàn),數(shù)據(jù)在存入的時(shí)候不知道加入了什么鬼東西,導(dǎo)致數(shù)據(jù)從哪一行截?cái)嗔耍瑢?dǎo)致多出現(xiàn)了三條數(shù)據(jù)。下面是有問題的字段。
![](/d/20211018/59d12c1a98278131714be35d1d53abf6.gif)
這里我也不知道數(shù)據(jù)為啥會是這樣,我猜想是在導(dǎo)入數(shù)據(jù)的時(shí)候hive默認(rèn)行的分割符號是按照\n的形式導(dǎo)入進(jìn)來的,到這里遇到了這樣的字符就對其按照下一行進(jìn)行對待將數(shù)據(jù)截?cái)嗔恕?/p>
然后我測試了一直自定義的去指定hive的行的分割符號,使用--lines-terminated-by 指定hive的行的分割符號,但是不幸的是好像這個(gè)是不能改的。他會報(bào)下面的錯誤:
FAILED: SemanticException 1:424 LINES TERMINATED BY only supports newline '\n' right now. Error encountered near token ''\164'' 于是上網(wǎng)找資料,然后發(fā)現(xiàn)可以使用一個(gè)配置清除掉hive當(dāng)中默認(rèn)的分割符號,然后導(dǎo)入數(shù)據(jù),配置如下: --hive-drop-import-delims 這個(gè)參數(shù)是去掉hive默認(rèn)的分割符號,加上這個(gè)參數(shù)然后在使用--fields-terminated-by 指定hive的行的分割符號 最終數(shù)據(jù)導(dǎo)入成功,數(shù)據(jù)量和原來數(shù)庫當(dāng)中的數(shù)據(jù)一致。
![](/d/20211018/0be3119d0d5951cca00fc291e033f682.gif)
![](/d/20211018/e4186afca7378d2ec0c1f13f8255bd4e.gif)
上面是sqoop腳本的部分內(nèi)容,下面是執(zhí)行完hive之后,hive創(chuàng)建的表,字段之間默認(rèn)的分割符號。
至此問題得到了解決。
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方,望不吝賜教。
您可能感興趣的文章:- 在Hadoop集群環(huán)境中為MySQL安裝配置Sqoop的教程
- sqoop export導(dǎo)出 map100% reduce0% 卡住的多種原因及解決
- 解決sqoop從postgresql拉數(shù)據(jù),報(bào)錯TCP/IP連接的問題
- sqoop讀取postgresql數(shù)據(jù)庫表格導(dǎo)入到hdfs中的實(shí)現(xiàn)
- sqoop 實(shí)現(xiàn)將postgresql表導(dǎo)入hive表
- 使用shell腳本執(zhí)行hive、sqoop命令的方法
- Sqoop的安裝與使用詳細(xì)教程