开头用Sqoop导数据慢到怀疑人生明明集群资源充足MapReduce任务却像老牛拉车一样几百万条数据跑个十几分钟都算运气好如果你也遇到过这种情况那这篇内容就是写给你的。今天我们只聊一件事Sqoop的--direct模式到底是什么它凭什么能带来肉眼可见的性能提升以及最关键的问题——它到底适合用在哪些场景。先说结论--direct模式的核心思路是绕过Sqoop默认的JDBCMapReduce导入路径直接调用数据库原生的导入/导出工具来完成数据搬运。以MySQL为例导入时它走的是mysqldump/mysqlimport这套原生工具链而不是一条条地通过JDBC读取再写入HDFS。听起来很简单对吧但就是这一下“绕路”在特定场景下能把导入速度拉满到原来的几倍甚至十几倍。当然没有任何银弹。--direct的适用边界非常清晰用对了是加速器用错了就是给自己挖坑。这篇内容适合正在用Sqoop做数据同步、被全量初始化或者大表导入性能折磨过的同学。不管你是刚接触Sqoop没几天的新手还是已经踩过不少坑的资深运维下面这些关于--direct模式的原理拆解、参数细节和实战经验都应该能让你少走几步弯路。我会把为什么快、什么时候快、什么时候千万别用以及我实际踩过的那些坑一次说清楚。1. 先说透Sqoop普通导入和 --direct 到底差在哪1.1 默认导入路径的问题所在Sqoop默认的导入逻辑本质上是一个跑在MapReduce上的JDBC客户端。JobTracker拿到导入任务后会切分成若干个map task每个map task负责一段数据区间通过Splitting Strategy计算出边界比如按主键ID范围切分。然后每个map task各自建立JDBC连接用SELECT * FROM table WHERE id BETWEEN ? AND ?这种方式去数据库里捞数据。问题就出在这里。JDBC驱动的实现方式决定了它必须逐行从数据库服务端取数据虽然是流式读取但每一行都要经过完整的协议解析、类型转换、序列化然后写入HDFS。大表导入的时候这种逐行读取的模式会带来两个严重的瓶颈第一个瓶颈是网络往返开销。每条记录都要走一次数据库协议栈虽然JDBC驱动有fetch size这样的批量参数可以优化但--direct模式的存在本身就说明默认路径的优化空间已经触及天花板了。第二个瓶颈是单行处理的CPU开销。类型转换、字符串解析、NULL值处理这些操作都会消耗大量CPU资源而且这部分开销完全和数据库原生工具的C语言实现不在一个数量级上。这里我补充一个实际经验。当我第一次用Sqoop导一张1亿条记录、单条记录大小平均200字节的表时默认模式跑完花了整整37分钟。后来切换成--direct模式同样的表、同样的集群14分钟就跑完了速度快了不止一倍。虽然这个数字会因为表结构、集群负载、网络状况等因素浮动但性能差距是实实在在的。1.2 --direct 模式的执行路径拆解--direct模式的执行路径和默认模式完全不同。以MySQL为例当你加上这个参数时Sqoop在导入阶段做的是这样一件事它不再写MapReduce的JDBC读数据逻辑而是直接调用mysqldump这个MySQL自带的逻辑备份工具先把数据导出成文本流再由Sqoop封装后写入HDFS。这个过程更像是“管道接力”mysqldump把数据按文本格式流式输出Sqoop拿到这些文本数据后做简单的解析和切分然后交给HDFS写入。因为绕过了JDBC这条相对笨重的老路直接利用了MySQL原生工具经过多年优化和沉淀的C语言代码性能自然就有了质的提升。导出方向的原理也类似。--direct模式导出数据时调用的是mysqlimport这个工具的支持逻辑和mysqldump对称专门负责高效地从文本文件批量导入数据到MySQL表。同样它比Sqoop默认的逐条INSERT或者批量INSERT方式要高效得多因为mysqlimport内部做了大量批量处理优化包括多行打包提交、减少事务日志刷新次数等。需要特别注意的是--direct模式并不是Sqoop自己实现了什么黑科技它更像是一个“转发器”把数据导入导出的核心工作转发给了数据库最成熟的原生工具。这个设计思路背后有一个很朴素的逻辑数据库厂商对自己产品的数据读写机制最了解他们的原生工具在性能和稳定性上是最值得信赖的。2. 为什么它能快底层原理与关键设计2.1 从JDBC逐行读取到流式管道传输的质变如果要给这两个模式做一个比喻默认的JDBC导入模式就像你雇了一百个人每个人手里拿着一张纸条上面写着需要取的数据范围然后这一百个人各自跑到数据库门口排着队一条一条地报ID等数据库把对应数据拿出来再誊抄到本子上。而--direct模式更像是数据库自己开了一个专用的出货口里面的人用最高效的打包方式直接把整箱整箱的货物往传送带上搬。这个“传送带”就是标准的输入输出流Stream。mysqldump 的输出会被Sqoop直接读取并写入HDFS中间不再有任何逐条解释的环节。而且很多数据库原生工具在导出时都支持并行、分批、流式写盘等多种优化手段Sqoop实际上是把这些能力原封不动地接了过来。还有个容易被忽视的点是数据类型处理。JDBC路径下每个字段的值都要经过Java类型的转换比如把MySQL的TINYINT转成Java的Byte把DATETIME转成java.sql.Timestamp。这些转换在Java/JVM层面虽然不算慢但架不住数据量大。--direct模式直接拿到的是文本格式的数据Sqoop只需要做极轻量的文本切割和字段映射CPU开销小了很多。2.2 边界条件对性能的关键影响这里必须说清楚一件事--direct模式不是所有情况下都快。它的性能优势高度依赖于数据库类型和具体的工具支持。Sqoop原生直接支持的数据库包括MySQL、PostgreSQL、Oracle部分版本、SQL Server等主流关系型数据库但不同数据库走--direct模式时底层调用的工具和参数差异很大。以MySQL为例导入时Sqoop调用mysqldump时会精细化地设置很多参数比如--no-create-info不导出建表语句、--compact紧凑输出格式、--skip-triggers跳过触发器等这些参数保证了输出的文本流能被HDFS直接识别和存储。如果你没有指定这些参数实际上Sqoop内部已经帮你处理好了。但如果是SQL Server情况就不太一样。SQL Server的--direct支持依赖的是它自己的BCPBulk Copy Program工具这个工具的高效导入导出能力没话说但它对文件格式、分隔符、转义符的约定和MySQL的mysqldump完全不同。也就是说你在MySQL上验证过的参数和性能数据不能直接平移到SQL Server上这一点容易被很多初学者忽略。所以在我参与过的数据同步项目里定义了一条不成文的规矩--direct模式上线前必须用生产环境全量数据做一次基准测试。因为真实性能不仅取决于工具本身还和表结构字段数量、字段类型、是否有大字段、网络带宽、磁盘I/O能力、数据库所在服务器的负载状况都强相关。理论分析替代不了实测这句话在数据同步场景里尤其适用。3. 实操指南哪些场景用 --direct 能吃到最大红利3.1 全量初始化导入利润最丰厚的场景全量初始化是--direct模式最舒服的使用场景。所谓全量初始化一般是指在新环境搭建、数据仓库初始化、或者某个业务表从零开始同步时一次性把整张表的数据从源数据库导入到HDFS或Hive。这种场景的特点是数据量巨大、没有增量逻辑、时间窗口比较宽裕但也不希望拖太久。我用一个实际案例来说明。一次数仓初始化需要把订单表导入到Hive订单表大概有8500万条数据包含订单ID、用户ID、商品ID、金额、创建时间、支付时间、收货地址JSON等字段平均单行大小约300字节。用默认模式跑的时候任务启动阶段光生成split就花了40多秒整个任务跑了52分钟。后来加了--direct参数同样的任务22分钟完成。这个案例里核心的加速点有三个。一是数据读取方式的升级mysqldump根本不需要建立任何JDBC连接而是直接从存储引擎导出数据少了连接池和协议解析的开销。二是数据格式的简化mysqldump输出的文本流不需要进行Java类型转换Sqoop拿到后基本只是做文本切分和字段映射。三是内存效率的提升mysqldump在导出时做了缓冲区和分批读写的优化不会因为一条超长记录把JVM堆内存打满。当然全量初始化场景下还有一点需要注意如果表里有CLOB/TEXT类型的大字段--direct模式的性能优势可能会被削弱因为大字段本身在导出和写盘过程中会占用大量I/O带宽。但即便如此它依然比默认的JDBC逐行读取要好得多。3.2 大表定期全量刷新另一个能明显感知加速的场景除了初始化导入还有一种业务场景也非常适合--direct定期全量刷新。有些业务表的数据量虽然大但变化频率不高不需要做复杂的增量同步只需要每隔一段时间把整表数据重建一次。比如维度表、配置表、标签表这类数据就属于典型的重建型数据。这类场景下我在实践中总结了一套操作规范。首先每次刷新前先清理旧数据避免HDFS上产生大量小文件其次在Sqoop导入命令中加上--delete-target-dir参数保证目标目录干净然后根据表数据量评估到底要不要加--split-by参数。这里有个反直觉的经验在--direct模式下--split-by对性能的影响反而变小了因为数据读取的瓶颈已经不在JDBC连接这一层而在HDFS写入带宽和集群处理能力上。但为了保证MapReduce的并行度合理我一般还是会指定--split-by主键并设置合适的--num-mappers。你可能会问--num-mappers设置多少个合适这个没有标准答案需要根据HDFS NameNode的压力、DataNode的写入带宽、数据库服务器的导出能力综合判断。我在4个DataNode、每个DataNode 8块盘的集群上导入500GB级别的数据时--num-mappers设置在8到16之间表现最稳定。如果超过32个mapper反而会因为写入小文件过多、NameNode压力过大而拖慢整体速度。3.3 不适合用 --direct 的场景列裁剪、查询过滤与并行写库的冲突任何工具都有它的局限性--direct模式也不例外。这个模式对SQL查询的支持非常弱它本质上是一个“整表导出器”而不是一个“查询导出器”。如果你需要在导入前做列裁剪只导几个字段、或者加上WHERE条件做数据过滤、或者join多张表后再导入那么--direct模式基本帮不上忙。原因不难理解。mysqldump是一个物理或逻辑级别的导出工具它不支持任意SQL语义。你让它导出整张表它可以做得又快又稳但你让它执行一条复杂的SELECT a, b, c FROM t WHERE x 10它就无能为力了。这种情况下Sqoop会静默地自动回退到默认JDBC模式你根本感受不到--direct带来的加速效果反而可能因为参数配置不当引发不必要的错误。这里有个更隐蔽的坑如果你在启动Sqoop任务时加了--direct同时又指定了--columns或--where那么Sqoop的行为可能会变得不可预期。旧版本1.4.x系列的某些build版本中这种组合甚至可能导致Sqoop抛出异常或者导出数据不完整。所以我的建议是在进行列裁剪、条件过滤这些操作时主动放弃--direct老老实实用默认模式。此外还有一个数据库端的并发写库风险。mysqlimport在导入数据的最后阶段会把数据写入MySQL的表这个操作会持有表锁如果你在同一个数据库上还有其他正在写入该表的业务线程就可能会产生锁等待甚至锁阻塞。所以在生产环境使用--direct模式做数据导出到MySQL时一定要确认目标表没有在线业务依赖或者安排在业务低峰期操作。4. 实战记录一次全量同步的完整操作与参数调优4.1 基础命令与参数速查先直接给你一套我在生产环境用过的命令模板看完再解释每个参数的含义。sqoop import \ --connect jdbc:mysql://10.10.10.10:3306/business_db \ --username sync_account \ --password-file /data/secure/sync_pwd.txt \ --table order_main \ --target-dir /warehouse/ods/order_main \ --direct \ --num-mappers 8 \ --split-by id \ --fields-terminated-by \001 \ --lines-terminated-by \n \ --null-string \\N \ --null-non-string \\N \ --delete-target-dir \ --compress \ --compression-codec snappy拆解一下关键参数。--direct不必多说是本次加速的核心开关。--num-mappers 8控制MapReduce的并行度8个map task并行从mysqldump的输出流中读取并写入HDFS。--fields-terminated-by \001指定字段分隔符为\001CtrlA这是Hive和数仓场景下的主流分隔符选择因为业务数据里几乎不会出现\001不会有转义冲突。--null-string和--null-non-string都设为\\N这是为了让Hive能正确识别NULL值。--compress --compression-codec snappy开启Snappy压缩能显著减少HDFS写入的I/O量同时Snappy的解压开销极低查询时性能影响很小。这里特别强调一下--password-file的用法。直接把密码写在命令行里是相当危险的操作在进程列表里就能被其他人看到而且还会写进shell历史记录。Sqoop支持通过文件方式读取密码先创建一个权限为600的密码文件然后在参数里指定。这个习惯在多人共用的集群环境中极其重要我已经见过太多人因为密码暴露在进程参数里导致数据库账号泄露。4.2 实测带压缩和并行度调优后的性能表现在一次生产环境的数据初始化操作中我导了订单明细表order_detail表结构包含36个字段其中有order_id、user_id、sku_id、sku_name、price、discount_amount、pay_amount、order_time、deal_time、region_id、warehouse_id等关键字段。数据总量约1.2亿行原始数据大小约为47GBHDFS目标路径是/warehouse/ods/order_detail。第一次跑我用的是完全没有任何优化的默认命令也就是不带--direct只指定了--num-mappers 8。整个任务用了61分钟。注意这个数字包含了从MySQL读取数据、MapReduce的处理调度、写入HDFS的全部时间。第二次跑我在命令里加上--direct其他参数不变但先不启用压缩。结果任务耗时降到了31分钟。为什么有接近一倍的提升最核心的原因是mysqldump导出的文本流本身就比JDBC逐行读取要快得多同时省掉了Java类型转换和JVM序列化的开销整个管道的吞吐量上了一个台阶。第三次跑我在--direct的基础上加了Snappy压缩并把--num-mappers从8调到了12。结果任务耗时进一步降到了19分钟。压缩减少了写往HDFS的数据量47GB的原始文本压缩下来大概只有14GB磁盘I/O的压力大大缓解而12个map task的并行度也让mysqldump的文本流产出能够被更充分地消费掉。三次测试的数据放在一起对比就很直观了。配置组合任务耗时较默认模式提升默认模式JDBC逐行读61分钟基准--direct不压缩31分钟约2倍--direct Snappy压缩 12并发19分钟约3.2倍需要说明的是这个提升比例在不同的集群环境、不同的表结构、不同的数据库负载下一定会有所波动。比如在万兆网卡下网络I/O不再是瓶颈性能提升比例可能更高而在千兆网卡下HDFS写入和数据库导出共用同一条网络链路提升幅度就可能被网络带宽卡住。所以建议大家都用自己的真实数据做一次基准测试不要直接照搬我的数字。4.3 导出场景Sqoop Export的参数差异讲了半天的导入别忘了Sqoop还有另一个重要方向导出。把HDFS或Hive里的数据写回MySQL这个场景同样可以用--direct加速但参数配置上有些差异。sqoop export \ --connect jdbc:mysql://10.10.10.10:3306/business_db \ --username sync_account \ --password-file /data/secure/sync_pwd.txt \ --table order_stat \ --export-dir /warehouse/ads/order_stat \ --direct \ --num-mappers 6 \ --fields-terminated-by \001 \ --input-null-string \\N \ --input-null-non-string \\N \ --update-mode allowinsert \ --update-key id导出时加--direct的作用是让Sqoop调用mysqlimport批量装载数据而不是通过JDBC逐条执行INSERT语句。mysqlimport支持多行打包插入配合MySQL的批量提交机制性能提升非常显著。在我做过的某个BI报表数据回库场景中导出3000万行数据从默认模式的26分钟降到了9分钟。但这里有个非常大的坑一定要提醒大家如果目标表有触发器Trigger或者外键约束--direct导出模式可能会导致数据不一致甚至导入失败。原因是mysqlimport在批量装载时部分触发器的顺序和约束检查机制与逐行INSERT不同。我在一次导出操作中就因为目标表存在一个更新时间戳字段的BEFORE INSERT触发器导致所有行的更新时间戳都是导入开始的那一刻而不是业务期望的每个时间点。排查了很久才发现是--direct模式的问题后来在目标表上临时禁用触发器或改回默认JDBC模式才解决了问题。所以使用--direct导出前务必确认两件事目标表没有复杂的触发器和外键依赖目标表允许被临时锁定mysqlimport装载期间会有表锁。5. 常见问题与排查技巧实录5.1 --direct 参数不生效任务还是慢吞吞这是一个很典型的“假配置”问题。我接到过好几次类似的工单运维人员反映说加了--direct参数但任务耗时完全没变化和没加一个样。排查思路其实很清晰。第一步确认Sqoop版本1.4.6及以后版本对--direct的支持已经比较稳定但如果你用的还是1.4.5及以前的版本某些数据库类型的--direct支持存在bug。第二步查看任务日志Sqoop在启动阶段会打印使用的导入方式日志里如果出现DirectImport或DirectMySQLImport相关的字样说明--direct确实生效如果日志里跳过了这些说明静默回退成了JDBC模式。第三步检查是否添加了--where、--columns等参数这些参数会导致Sqoop自动回退到JDBC模式而Sqoop不一定会在日志里明确警告你。我几次排查到最后发现基本都是因为命令里带了--columns做列裁剪导致--direct被静默回退。如果你既要列裁剪、又要高性能我的建议是可以分两步第一次用--direct全量导入到一个临时表或临时目录第二步再用Hive SQL或Spark SQL做列裁剪。这样虽然多了一步但总体时间可能反而更短。5.2 mysqldump版本不兼容导致的中文字符乱码--direct模式调用mysqldump时默认使用的字符集可能与源表或目标表的字符集不一致导致导入到HDFS后中文变成乱码。这个问题的根源在于mysqldump导出时如果不显式指定字符集会使用数据库全局的character_set_database设置。如果源表使用utf8mb4而全局设置是latin1导出出来的文本流自然就是乱码。解决办法是给Sqoop命令加上数据库连接参数中的字符集声明在JDBC连接URL里加?useUnicodetruecharacterEncodingutf8同时在命令里通过--mysql-skip-optimize之类的参数控制mysqldump的额外行为。但更可靠的做法是在mysql客户端或mysqldump层面强制指定字符集比如在Sqoop通过--connection-manager或--driver自定义路径时手动注入--default-character-setutf8mb4。这里分享一个我踩过的坑当时导一个用户表里面的用户昵称有很多生僻字用默认模式导出来没问题加了--direct后昵称全变成问号。排查了很久发现是Sqoop内部生成的mysqldump命令没有带上字符集参数而mysql客户端的默认字符集是latin1。最后通过在JDBC URL里显式指定useUnicodetruecharacterEncodingUTF-8解决了问题。但要注意的是MySQL 8.0之后的驱动包对characterEncoding参数的兼容性有些变化建议在切换驱动版本后重新测试一次。5.3 mysqldump 执行权限不足导致任务直接失败很多时候--direct模式跑不起来并不是参数配错了而是执行Sqoop任务的账号在数据库端没有足够的权限。mysqldump要读取表结构和表数据至少需要SELECT权限如果需要导出触发器或存储过程还需要额外权限。我遇到过一次非常隐蔽的情况开发环境用root账号测试--direct完全没问题到了生产环境换成只读账号后任务在启动阶段报错错误信息是Access denied for user readonly% to database business_db。关键点在于这个报错信息指向数据库访问很多人会以为是JDBC连接配置错了但实际上是--direct模式下Sqoop调用mysqldump时使用的是同一个JDBC URL里的账号密码去连接MySQL而mysqldump的登录方式对账号权限的要求比JDBC更严格。排查方式很简单先手工在数据库服务器上用同一个账号执行一遍mysqldump命令看能不能成功导出数据如果能导出但Sqoop还是失败再检查Sqoop日志看有没有其他参数层面的原因。还有一个容易忽略的问题--direct模式需要Sqoop在执行任务的机器上能够找到mysqldump或mysqlimport的可执行文件。如果数据库客户端工具没有安装或者安装路径不在PATH环境变量中Sqoop就会报Cannot find mysql/mysqldump in PATH之类的错误。解决方法是把MySQL客户端的bin目录添加到执行Sqoop的节点环境变量中或者在调用Sqoop时通过--driver和连接管理器手动指定工具路径。5.4 导出的数据行数与源表不一致这是比性能问题更严重的数据正确性问题。我在一次--direct导入的校验环节发现HDFS上的数据行数比源表少了近千行。逐行比对后发现丢失的数据都是某些特殊字符比如换行符嵌入在字段值中、或者字段值里包含\转义符导致的解析错位。这个问题的根源在mysqldump输出文本流时Sqoop对字段分隔符和行分隔符的处理逻辑与JDBC模式不同。JDBC模式通过ResultSet元数据精确定位每个字段的边界而--direct模式拿到的是一串文本Sqoop只能依靠分隔符来切分字段。当字段值内部出现和分隔符相同的字符时切分就会出错。解决方案有两个方向。一个是优化分隔符的选择不要用业务数据中可能出现的字符作为字段分隔符推荐使用\001这种控制字符它几乎不会出现在正常业务数据中。另一个思路是使用--escaped-by和--enclosed-by等参数为Sqoop明确指定转义和包裹规则。但需要注意的是这些参数在不同数据库类型的--direct实现中支持程度不同MySQL下通常支持良好其他数据库可能需要实测验证。我这里还留了个习惯每次--direct导入完成后都会用Hive SQL执行一次SELECT COUNT(*) FROM table和源库的行数做对比确保数据完整。数据同步最忌讳的就是“只求快不求对”性能再高数据错了就是白干。6. 工具选型与扩展思考--direct 不是终点是起点6.1 什么时候应该选择 --direct什么时候应该选择其他同步方案很多人一听说--direct能加速就恨不得所有导入导出都加上这个参数。这是需要纠正的。--direct固然在特定场景下性能突出但它天然存在着适用范围窄、对查询语义支持弱、依赖数据库原生工具等限制。在数据同步的工具选型上正确的做法是先明确场景再选工具。我个人的决策流程是这样的同步方是不是整表全量如果是且数据库类型是MySQL或PostgreSQL且对同步时间有较高要求那么--direct是一个非常好的选择。如果需要做增量同步那优先考虑Sqoop的增量模式或基于binlog的CDC工具。如果需要做复杂的转换、清洗、字段映射那我更倾向于用Spark或Flink来读取数据毕竟它们对整个数据处理链路的掌控性更强虽然初始的读取吞吐不如--direct但胜在灵活。如果是超大表比如单表几百GB甚至上TB级别的全量初始化--direct虽然能用但数据库端的压力会非常大。这个场景下我更建议使用专门的数据库迁移工具比如MySQL的mysqldump直接导出到本地文件再用分布式文件传输工具上传到HDFS或者直接用Spark的JDBC分区读取 并行写入HDFS。总而言之--direct是工具箱里的一把快刀但它不是万能工具。6.2 从 --direct 延伸到更多性能调优思路--direct模式让我在性能调优上开了窍。它本质上提醒了我一个事很多性能瓶颈不是靠堆机器就能解决的而是要看你能不能找到绕过瓶颈的那条路。数据同步这类I/O密集型的任务瓶颈往往在一条链路上的几个关键节点只要把最慢的那个节点打破整体性能就会大幅提升。在--direct的基础上我后来又尝试过几种组合优化。比如把Sqoop产出直接落到Hive表而不是HDFS目录使用--hive-import参数让Sqoop自动建表并加载数据省一次手动load的步骤。比如在导入前评估源表的数据分布合理设置--boundary-query来精确控制map task的数量避免因为split生成不合理导致的某些task数据倾斜。再比如配合Sqoop的--fetch-size参数虽然它在--direct模式下意义有限但在默认模式下能帮助减少网络往返次数做默认模式下的调优。和社区的同行交流时我发现很多人把性能调优理解为“抄一个参数模板”实际上每个集群的环境都不同数据库的负载模式也不同。正确的做法应该是带着实验的心态先做一轮基准测试确定基线性能然后每次只改动一个变量观察性能的变化。这比盲目堆参数要科学得多。7. 最终的实操心得与建议做了这么多年数据同步我的切身体会是性能调优这件事七分靠理解原理二分靠实践验证一分靠运气。--direct模式加速数据导入这件事原理其实非常直白借用数据库自己的快车道。但正因为直白很多人在使用时会忽略它背后的适应边界和潜在风险。如果你准备在生产环境使用--direct我建议你记住下面几条第一永远先做基准测试。别拿理论推算代替实测。同一张表在开发环境的速度提升和生产环境可能完全不同唯一的判断标准是自己的数据跑出来的数字。第二用--direct时不要同时使用--where、--columns这类破坏整表语义的参数不然它会静默回退到JDBC模式性能提升自动消失。如果你确实需要列裁剪先全量导到HDFS再说后续用Hive或Spark处理。第三注意目标端的数据完整性和一致性校验。无论是导入还是导出任务跑完后都要做行数对比和抽样验证。数据同步的正确性永远排在性能前面。第四生产环境操作前评估数据库端的压力和锁影响。mysqldump导出会消耗数据库服务器资源mysqlimport导入会持有表锁。这些影响要提前评估尽量避免在业务高峰操作。最后再分享一个小技巧。如果你在生产环境多次使用--direct且数据量巨大可以给mysqldump的调用加上--single-transaction参数。这个参数能让导出操作在一个事务中执行保证快照一致性避免在导出过程中源表被写入而导致数据不一致。虽然Sqoop默认不会显式传递这个参数但你可以通过Sqoop的支持参数或者自定义连接管理器实现。这个细节很少被人提到但数据一致性价值巨大。这也是我在无数个深夜排查Sqoop任务后最想告诉你的一条经验。