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
