Sqoop export 数据表字段不一致问题

今天从hdfs中导数据到mysql,遇到如下错误。

com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'is_removed' at row 1 at 

最终发现是因为hdfs中数据表字段是46个,而本地数据表字段是48个,比hdfs中多了两个,可能导致字段映射错误,把别的字段误解析成is_removed字段了(is_removed类型是1个长度的char)。

结论就是要保证导入的mysql表字段和hdfs中的字段一致。

后来经过深入研究,发现要想正确从hive导数据到mysql,要保证如下两个条件

1、hive中的表字段数目和目标mysql表字段数目一致
2、 hive中的表字段和目标mysql表字段名称对齐,即顺序一致

原因如下,查看执行sqoop执行时产生的java代码:


image.png

sqoop执行map时是将hive数据文件的一行按顺序解析成了一个String List,然后按顺序解析为相应的字段,主要,这里是按索引解析为对应字段,而不是按字段名称映射。

然后解析完成后,按照下面的方式组装map插入数据库。


img.png

那么,重点来了,程序是从哪里拿到的表字段名们呢?要知道,export源数据是存在hdfs文件里的,里面没有任何字段名的信息!有的只是一行一行的数据。hive里之所以有字段信息是因为hive表的表信息存在hive元信息里。所以,我猜测,sqoop是从目标mysql数据库里取的列字段信息,然后每解析一行数据,就按顺序解析为目标mysql中对应的字段(以及字段类型)。最后进行insert。

由这两个过程可知,其是按照默认字段索引顺序来映射字段的,所以如果字段顺序不一致,或者数目不一致,很可能导致错位,插入类型解析失败等错误。

由sqoop脚本的配置里也可以看出,sqoop只和hdfs和目标mysql交互,不涉及hive,所以只能是从mysql里查找出所以的字段信息。

查询mysql表的字段信息:

mysql> SHOW FULL COLUMNS FROM subscribe;
+-------------------+-------------+--------------------+------+-----+-------------------+----------------+---------------------------------+-----------------------+
| Field             | Type        | Collation          | Null | Key | Default           | Extra          | Privileges                      | Comment               |
+-------------------+-------------+--------------------+------+-----+-------------------+----------------+---------------------------------+-----------------------+
| id                | bigint(20)  | NULL               | NO   | PRI | NULL              | auto_increment | select,insert,update,references | 主键                  |
| user_id           | bigint(20)  | NULL               | YES  | MUL | NULL              |                | select,insert,update,references | 订阅者用户id          |
| type              | int(11)     | NULL               | YES  |     | NULL              |                | select,insert,update,references | 订阅类型              |
| subordinate       | varchar(64) | utf8mb4_general_ci | YES  |     | NULL              |                | select,insert,update,references | 所属                  |
| trigger_type      | int(11)     | NULL               | YES  |     | NULL              |                | select,insert,update,references | 触发条件类型          |
| trigger_value     | int(11)     | NULL               | YES  |     | NULL              |                | select,insert,update,references | 触发值                |
| create_time       | datetime    | NULL               | YES  |     | CURRENT_TIMESTAMP |                | select,insert,update,references | 创建时间              |
| publish_time      | datetime    | NULL               | YES  | MUL | NULL              |                | select,insert,update,references | 发布时间              |
| last_publish_time | datetime    | NULL               | YES  |     | NULL              |                | select,insert,update,references | 上一次发布时间        |
| publish_frequency | int(11)     | NULL               | YES  |     | NULL              |                | select,insert,update,references | 发布频率              |
| delete_time       | datetime    | NULL               | YES  |     | NULL              |                | select,insert,update,references | 删除时间              |
| is_deleted        | tinyint(1)  | NULL               | YES  |     | 0                 |                | select,insert,update,references | 删除                  |
+-------------------+-------------+--------------------+------+-----+-------------------+----------------+---------------------------------+-----------------------+
12 rows in set (0.01 sec)
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,928评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,192评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,468评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,186评论 1 286
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,295评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,374评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,403评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,186评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,610评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,906评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,075评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,755评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,393评论 3 320
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,079评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,313评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,934评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,963评论 2 351

推荐阅读更多精彩内容

  • 转 # https://www.cnblogs.com/easypass/archive/2010/12/ 08/...
    吕品㗊阅读 9,714评论 0 44
  • 什么是数据库? 数据库是存储数据的集合的单独的应用程序。每个数据库具有一个或多个不同的API,用于创建,访问,管理...
    chen_000阅读 4,034评论 0 19
  • 1、引言 数据库设计过程中表、字段等的命名规范也算是设计规范的一部分,不过设计规范更多的是为了确保数据库设计的合理...
    SnowflakeCloud阅读 40,974评论 0 48
  • ORA-00001: 违反唯一约束条件 (.) 错误说明:当在唯一索引所对应的列上键入重复值时,会触发此异常。 O...
    我想起个好名字阅读 5,268评论 0 9
  • 这样玩扑克牌孩子将更优秀! 关键词:高效、自律、合作、权衡、数学思维、多重延迟满足 扑克牌是全民熟悉的一种可以自娱...
    虎爸慢慢跑阅读 224评论 0 0