Sqoop的容错机制

Sqoop本身的容错依赖于Hadoop,这里我们focus在Sqoop传输任务失败的处理,确切的说,focus在Sqoop如何解决传输任务失败引发的数据一致性问题

对于一个传输任务,将数据从A传输到B,如果这个传输任务失败,A和B的状态,都应该和传输开始之前是一致的。

Sqoop将一个传输作业生成一个mapreduce job,一个job有多个并行执行传输作业的mapreduce task在和外部数据库做数据传输,然后,有很多原因可以导致个别task fail,eg:

1. 违反数据库约束

2. 数据库连接丢失

3. 由于分隔符等原因,传输的列数和表的列数不一致

4. Hadoop机器硬件问题

任何一个task由于上述问题fail,会导致整个传输job fail,而这可能会导致数据出现一致性问题!

一个传输任务,由多个task并行执行,每个task本身是一个transaction,当这个task fail,这个transaction会roll back,但其他的transaction不会roll back,这就会导致非常严重的脏数据问题,数据部分导入,部分缺失,怎么办???

对于Sqoop Import任务,由于Hadoop CleanUp Task的存在,这个问题不存在

Sqoop Export任务则提供了一个“中间表”的解决办法
先将数据写入到中间表,写入中间表成功,在一个transaction中将中间表的数据写入目标表

--staging-table <staging-table-name> 中间表

--clear-staging-table 任务开始前,清空中间表

eg:

./sqoop export --connect jdbc:mysql://127.0.0.1/test --table employee --staging-table employee_tmp  --clear-staging-table -username root -password 123456 --export-dir  hdfs://localhost:9000/user/hive/warehouse/employee

传输过程中数据暂存在employee_tmp中,最终employee_tmp的数据将被move到employee

中间表的思路不错,但带来一个问题,如果要导入一份数据到数据库,需要建一个“伴身表”
如果传输工具需要通用化,这个建“伴身表”的操作就需要集成到整个传输工具中,而“建表”工作外放,DBA会是一个很大的阻力

总结:
对于一个传输工具/平台,传输任务失败不可怕,可怕的地方在于“脏数据”如何处理,3种思路:
1. 临时表:使用临时表缓存数据,然后在一个transaction中将临时表的数据move到目的表
2. 自定义回滚:通过用户自定义的语句/方法,在任务失败后,执行清数据操作
3. 传输任务的幂等性:如果一个任务失败了,产生了脏数据,解决问题后,再跑一次任务,能够最终正确,例如hive写入使用INSERT OVERWRITE

莫问

我还没有学会写个人说明!

相关推荐

debian10开启bbr加速

由于 Debian10 默认的内核就是 4.19 版本的内核而且编译了 TCP BBR 模块,所以可以直接通过 ...

4 条评论

  1. 技术我是啃不动了。

    • @小宋日志 哪里都有你,你要继续啃,这样我们才能沾光,好好玩耍的说。

  2. 文章不错非常喜欢

  3. 文章不错非常喜欢

回复 头条 取消回复

您的电子邮件地址不会被公开,必填项已用*标注。