做数据开发这几年我陆陆续续接过好几个 Oracle 向 Hadoop 迁移的活儿有银行核心报表的有互联网公司用户行为分析的也有传统企业 ERP 数据归档的。每次做这类迁移表面上看起来就是把数据从 A 库搬到 B 库但真做起来从表结构映射、增量策略、字符集处理到跑批任务的性能调优每个环节都有不少暗坑。今天就把我这些年总结的迁移思路、实操步骤和踩坑记录完整写出来给准备做同类迁移的同学一个参考。先说结论Oracle 到 Hadoop 的迁移没有一步到位的银弹最稳妥的路径是先全量、再增量、后校验工具选型上 Sqoop 依然是离线批量迁移的首选。1. 迁移前先别急着动手需求评估与整体方案选型1.1 先盘清楚要迁什么数据资产摸底很多人拿到迁移任务的第一反应是找工具、写脚本但我在实际项目里吃过大亏之后现在坚持先用至少一两天把数据资产彻底摸清楚。摸底阶段要输出的核心清单包括库中总共有多少张业务表、每张表的记录量级、是否存在超大分区表或历史归档表、哪些表有 CLOB/BLOB 字段、哪些表更新频繁、哪些表是只读的维度表。这些信息直接决定迁移方案怎么写。我习惯用下面这组 SQL 把表清单拉出来先按数据量级做个粗略排序-- 查看用户下所有表的记录数估算 SELECT table_name, num_rows, last_analyzed FROM all_tables WHERE owner SCOTT ORDER BY num_rows DESC;注意num_rows是上次统计信息收集时的记录数不是实时的所以只能用来做量级参考。真正要精确了解数据量还是得对核心大表跑SELECT COUNT(*)或者抽查几个关键分区。盘完表之后要把表分成三类维度表与配置表数据量小、基本不更新或低频更新这类表迁移最简单全量覆盖即可。流水表与业务明细表持续增长、有明确时间字段或自增主键这类表是全量和增量迁移的核心对象。日志表与历史归档表体量大、访问频率低这类表优先考虑直接迁到分区表并做压缩。这一步很多人嫌麻烦直接跳过但事实是迁移过程中的大部分问题都出在没提前评估上。比如有个表字段里有特殊字符\0导入 Hive 后下游解析全乱了再比如某张表有 8 个 CLOB 字段Sqoop 默认内存配置根本扛不住。提前摸清底细后面才能少踩坑。1.2 方案选型Sqoop、DataX 还是 Flume工具选型是迁移方案里最核心的决策点。市面上的主流选择有 Sqoop、DataX、Flume、Kettle还有基于 Spark 的自研同步程序。我不推荐一上来就选重型自研方案大多数业务场景下一个成熟的同步工具加少量定制脚本就够用了。这三个工具的适用场景差异比较大我用一个表格来对比工具适用场景优势劣势Sqoop离线批量导入导出关系型数据库与 HDFS/Hive/HBase 之间与 Hive 集成好支持增量、支持多种文件格式社区成熟MapReduce 框架下性能受 YARN 资源影响配置稍复杂DataX异构数据源之间同步尤其擅长 Oracle、MySQL、HDFS、各种数仓插件化架构、单机多线程、性能稳定中文文档友好默认不支持 Hive 直接写需要走 HDFS 中间层Flume日志型流式数据实时采集准实时、可靠、可监控不适合批量离线导入事务保证弱我的选型建议很简单如果是一次性全量 每日增量的离线数仓场景Sqoop 优先因为 Hive 表结构可以直接映射增量参数也够用。如果数据源和目标端类型很多、团队对 Java/Shell 比较熟或者需要更细粒度的并发控制DataX 优先性能调优更直观。如果源头是日志文件、消息队列需要秒级延迟那就别考虑前两个了Flume 或直接写 Flink 作业更合适。顺便说一句关于从 Oracle 迁到 Hadoop 是不是一定要用 Hive SQL 来查很多人也有误区。Hadoop 生态里 Hive 只是数据仓库组件真正落地的文件格式、分区策略、压缩方式选择会影响后续 Spark、Presto、Flink 的查询效率。这些在方案阶段就要定下来否则后期返工成本极高。2. 目标端准备与迁移环境搭建2.1 Hadoop 集群侧要确认的三件事迁移之前目标端的 Hadoop 环境必须提前验证好。我见过不少项目源端 Oracle 那边都准备好了结果 Hadoop 集群本身问题一堆NameNode 没做 HA、YARN 队列资源配错、Hive 元数据库用的内置 Derby 导致并发操作锁死。这些基础环境问题会让迁移过程非常痛苦。首先要确认的是集群版本和组件兼容性。比如 Sqoop1 与 Hadoop 2.x、Hive 2.x 的兼容组合比较成熟如果用 Hive 3.x就要注意 Sqoop 导入时生成的文件格式变化以及 JDBC 驱动兼容问题。我的经验是迁移前把各个组件的版本号整理成一张清单并留档后续排查问题能省很多时间。其次要确认HDFS 目录规划与磁盘空间。数据迁过来之后会占用多少空间受制于文件格式与压缩算法。比如 Oracle 里一张 2TB 的表迁到 Hive 用 ORC Snappy 压缩后实测通常只有 500GB 到 800GB 左右。如果团队后续主要用 Spark SQL 或 Presto 查询ORC 格式在性能和存储压缩比上都很均衡如果主要走 Hive 跑批并且后续有跨系统文件交换需求Parquet 也是不错的选择。第三要确认NameNode 的高可用。如果只有一个 NameNode 节点那么迁移期间一旦它重启所有 Sqoop 导入任务都会失败虽然可以重跑但调度链上的依赖任务很容易乱掉。有条件尽量提前搭好 HA 或至少做好 NameNode 元数据备份。热词里也经常有人搜hadoop和zookeeper整合实战说的就是 HA 场景下 Zookeeper 的配置这一块其实值得提前做。2.2 Sqoop 安装与 Oracle JDBC 驱动配置Sqoop 的安装本身不算复杂下载二进制包解压、配环境变量就行。但有一个环节特别容易被忽略Oracle JDBC 驱动必须手动下载并放到指定目录。因为 Oracle 的驱动有协议限制Sqoop 发布包不会内置ojdbc。以 Sqoop1 为例解压完成后需要把ojdbc8.jar对应 Oracle 12c 及以上或ojdbc6.jar对应 Oracle 11g 及以下拷贝到$SQOOP_HOME/lib/目录下。这一步做完后先执行一条最简单的命令验证连通性sqoop list-tables \ --connect jdbc:oracle:thin:192.168.1.10:1521/ORCLPDB1 \ --username scott \ --password tiger如果能正常列出表名说明环境和驱动都没问题。注意Oracle 11g 和 12c 的 JDBC 驱动不要混用。我踩过一次坑源库是 Oracle 11.2.0.4用了 ojdbc8 去连结果偶尔报ORA-28040: No matching authentication protocol换成 ojdbc6 后问题消失。驱动版本兼容性在迁移这种长时任务里尤其重要宁可保守也别追新。另外生产环境的 Oracle 账号密码不要直接写在命令行参数里建议使用--password-file配合 HDFS 上的鉴权文件或者用环境变量方式传递避免密码被 YARN 的日志收集器打印出来。2.3 Hive 表结构设计分区、存储格式与压缩在跑 Sqoop 导入之前我建议先把 Hive 目标表结构建好而不是完全依赖 Sqoop 自动建表。自动建表虽然方便但有很多问题默认生成的表通常没分区、文件格式是 TextFile、字段注释和 Oracle 列的注释对不上、某些特殊类型处理不符合预期。我一般按下面的规范提前建表CREATE TABLE dwd_order_detail ( order_id BIGINT, user_id BIGINT, product_id BIGINT, order_amount DECIMAL(12,2), order_status STRING, create_time TIMESTAMP ) PARTITIONED BY (dt STRING) STORED AS ORC TBLPROPERTIES (orc.compressSNAPPY);分区字段的选择很关键。对于有明确时间字段的流水表按天分区是最常见的选择对于超大历史表可以考虑按月和按天二级分区。每个分区的大小最好控制在 100MB 到 1GB 之间分区太小会导致 HDFS 上小文件过多分区太大会让查询扫描成本增加。存储格式方面我强烈建议生产环境不要用默认的 TextFile。虽然 TextFile 容易排查问题直接 cat 就能看数据但它的存储空间占用大、查询性能差。ORC 在 Hive 和 Spark 场景下性能表现最好Parquet 在列式存储生态里兼容性更好。如果拿不准就选 ORC Snappy 压缩这是目前离线数仓里最常见的组合。3. 全量迁移实操从第一张表到一百张表3.1 第一张表怎么迁Sqoop 导入命令拆解环境就绪后先从一张小表开始试水。用一个小表做连通性验证比如用户维度表sqoop import \ --connect jdbc:oracle:thin:192.168.1.10:1521/ORCLPDB1 \ --username scott \ --password tiger \ --table USER_DIM \ --hive-import \ --hive-table default.user_dim \ --create-hive-table \ --target-dir /user/hive/warehouse/user_dim \ -m 4这条命令的作用通过 JDBC 读取 Oracle 的USER_DIM表转换成 MapReduce 作业将结果写入 HDFS 指定目录然后自动生成 Hive 表并加载数据。这里有几个参数我要特别解释一下-m 4表示启动 4 个并行 map 任务。Sqoop 的并行度靠这个参数控制但并不是越大越好后面会详细说。--split-by参数决定了数据如何切分。如果表有主键Sqoop 默认用主键做分片否则要手动指定--split-by。我建议显式指定一个数值型的、分布均匀的字段比如--split-by order_id。如果指定的字段分布不均匀比如有很多空值或者某几个值占比特别大会出现严重的数据倾斜。--hive-import会自动将 HDFS 上的数据文件 load 进 Hive 表但要注意它默认使用的分隔符是\001如果下游有人直接读文件必须提前约定好。3.2 身份证号变成科学计数法字段类型映射与格式化这是一个非常典型的问题热词里“数据库 sql 导出的身份证信息是科学计数法”其实就是这个坑的现实版本。Oracle 里如果身份证号用NUMBER类型存储导出到文本时超过一定位数的数字会被 Excel 或某些导出工具显示成科学计数法。但在 Hadoop 迁移场景下问题的表现形式稍有不同如果用 Sqoop 默认的映射Oracle 的NUMBER(18,0)会被映射成 Hive 的BIGINT而身份证号通常是 18 位已超过 BIGINT 的精度范围导入后末尾几位会变成 0数据直接错了。解决思路有两个最彻底的办法是在 Oracle 侧就把字段转成字符串再导出比如查询时写成TO_CHAR(id_card)。如果表已经在 Sqoop 导入中可以建 Hive 表时把id_card列为STRING并在 Sqoop 里通过--map-column-java或--map-column-hive强制类型映射sqoop import \ --connect jdbc:oracle:thin:192.168.1.10:1521/ORCLPDB1 \ --username scott \ --password tiger \ --table USER_INFO \ --hive-import \ --hive-table default.user_info \ --map-column-java ID_CARDString \ --map-column-hive ID_CARDSTRING \ -m 4在 Oracle 里凡是超过 9 位数字的NUMBER字段最好都人工检查一下语义。比如手机号、身份证、银行卡号它们本质上是“编号”而不是“数值”只要源表设计不够规范迁移时大概率会踩精度丢失的坑。这个 check 做在迁移方案阶段远比重跑数据省时间。3.3 字段类型映射对照Oracle 到 HiveOracle 和 Hive 的数据类型并不完全一一对应Sqoop 的表结构映射偶尔会给出意外结果。下面是我整理的一份常用映射对照表建议迁移前对照源表逐列确认Oracle 类型Hive 类型说明NUMBER(p,0)BIGINT / INTp ≤ 9 用 INTp ≤ 18 用 BIGINT超过 18 建议用 STRINGNUMBER(p,s)DECIMAL(p,s)金额等带小数的字段用 DECIMAL 精确存储VARCHAR2(n)STRING长度无需严格限制但注意字符集CHAR(n)STRING尾部空格是否保留要和下游约定DATETIMESTAMPSqoop 默认可能映射为 STRING建议显式指定TIMESTAMPTIMESTAMP注意时区问题统一用 UTC 或东八区存储CLOBSTRING大字段导入要注意内存配置小文件处理BLOBBINARY二进制对象下游要做专门处理BINARY_DOUBLEDOUBLE浮点数精度问题要提前约定RAW(n)BINARY不常见但存在这个表看着简单但实际项目里最容易出问题的就是DATE和TIMESTAMP。Oracle 的DATE本身只精确到秒而 Sqoop 在导入 Hive 时如果 Hive 表字段类型是STRING会直接写成年月日的字符串如果类型是TIMESTAMP则可能带上00:00的时区后缀。踩过几次坑之后我现在的习惯是时间字段统一用TIMESTAMP存储并且在查询时显式用from_utc_timestamp或to_utc_timestamp做转换从源头保证时间语义一致。3.4 并发度、数据倾斜与内存配置Sqoop 的-m参数是最常被调错的地方之一。之前有次迁移我图省事把-m直接开到 20结果 Oracle 数据库压力过大源库的 CPU 直接飙高DBA 差点打电话来质问同时 YARN 资源被 20 个 map 一抢而空其他正常跑批任务全被阻塞。-m参数的合理值取决于几个因素Oracle 侧的资源余量源数据库如果是 OLTP 核心库并发查询过大会影响线上交易。表的数据量和分布--split-by字段的值分布是否均匀如果不均匀再高的并发也快不起来。YARN 的资源配额单个 map 任务的内存mapreduce.map.memory.mb乘以并发数不能超过队列可用资源。我通常从小表数据量在千万级以内开始用-m 4试跑观察数据拉取速度和源库负载大表亿级以上会先做测试分区再用-m 8或-m 12并且配合--fetch-size参数控制 JDBC 每次拉取的行数默认 100 在某些场景下太保守。sqoop import \ --connect jdbc:oracle:thin:192.168.1.10:1521/ORCLPDB1 \ --username scott \ --password tiger \ --table ORDER_RECORD \ --hive-import \ --hive-table default.order_record \ --split-by order_id \ --fetch-size 5000 \ -m 8另外Sqoop 导入大表时偶尔会碰到堆内存溢出尤其是 CLOB/BLOB 字段很多的情况可以在 Sqoop 启动前设置export HADOOP_CLIENT_OPTS-Xmx2048m注意这里的HADOOP_CLIENT_OPTS只对客户端进程生效实际 MapReduce Task 的内存还是要走mapreduce.map.memory.mb和mapreduce.reduce.memory.mb配置。4. 增量同步与日常运维4.1 增量采集两种常用方式时间戳与自增主键全量迁移只是第一步真正的长期工作是从一次性导入切换到每日自动增量。Sqoop 提供了incremental import参数理论上支持两种模式append模式基于自增主键把大于上次最大主键值的数据追加进来。lastmodified模式基于时间戳字段把上次导入时间之后被修改或新增的数据同步过来。命令模板是这样的sqoop import \ --connect jdbc:oracle:thin:192.168.1.10:1521/ORCLPDB1 \ --username scott \ --password tiger \ --table ORDER_RECORD \ --hive-import \ --hive-table default.order_record \ --check-column UPDATE_TIME \ --incremental lastmodified \ --last-value 2024-06-01 00:00:00 \ -m 4--last-value是增量起点每次任务跑完后 Sqoop 会把新的last-value输出到控制台或保存到 metastore需要自己维护。我的习惯是把它写到调度系统Azkaban/ DolphinScheduler的变量里每次任务结束读取最大值并回写。但这里我要提醒一个非常重要的问题如果源表数据有物理删除或 UPDATE 只改了某些字段但没有更新时间戳lastmodified模式会漏数据。Oracle 里很多业务表都有软删除标记最稳妥的增量方案是结合时间戳字段和T1 抽取策略每天只同步前一天的数据这样可以极大减少因时间窗口内修改带来的不一致。4.2 跑批任务串起来调度的基本思路增量任务搭建好后自然要面对一个更现实的问题多个表的同步顺序、失败重试、任务状态监控。这部分建议直接用现成的调度平台DolphinScheduler 或 Azkaban 都行。比如在 DolphinScheduler 里可以把每个表的 Sqoop 导入封装成一个 Shell 任务配置依赖关系再配合定时调度。关键是要在任务里做两件事一是失败自动重试一般重试 2 次二是把任务日志输出到统一文件系统方便排查问题。下面是一段我在生产环境用的 Shell 包装脚本的简化版本#!/bin/bash export HADOOP_CLIENT_OPTS-Xmx2048m TABLE_NAME$1 LAST_VALUE$2 sqoop import \ --connect jdbc:oracle:thin:(DESCRIPTION(ADDRESS(PROTOCOLTCP)(HOSTdbserver)(PORT1521))(CONNECT_DATA(SERVICE_NAMEorclpdb1))) \ --username $ORACLE_USER \ --password-file /user/sqoop/oracle.pwd \ --table $TABLE_NAME \ --hive-import \ --hive-table ods.${TABLE_NAME,,} \ --check-column UPDATE_TIME \ --incremental lastmodified \ --last-value $LAST_VALUE \ -m 4 if [ $? -eq 0 ]; then echo SUCCESS else echo FAILED exit 1 fi4.3 数据校验怎么确认迁完的数据是对的迁移后的数据对不对是所有环节里最重要的。我常用的校验方式有三种按覆盖面从大到小排列行数校验Oracle 侧SELECT COUNT(*)Hive 侧SELECT COUNT(*)两边的数量要对上。对于大表行数校验要放到 ODS 层完成越早越好。抽样明细校验对关键业务表用关联键做抽样对比。比如订单表按订单号抽几十条样本比较金额、状态、时间等关键字段是否一致。汇总指标校验在 Oracle 和 Hive 里分别执行相同的聚合 SQL比如按天的总金额、总订单量对比结果是否在误差范围内。校验脚本我用过 Scala 写的 Spark 任务也用过纯 Shell SQL。对于中小规模表直接写 SQL 对比最方便对于大表或者要校验的维度太多建议写一个通用的数据校验工具输入两张表和关联字段自动输出差异。-- Oracle 侧 SELECT TO_CHAR(create_time, YYYY-MM-DD) AS dt, COUNT(*) AS cnt, SUM(order_amount) AS amt FROM order_record WHERE create_time DATE 2024-06-01 GROUP BY TO_CHAR(create_time, YYYY-MM-DD); -- Hive 侧注意时间字段类型 SELECT SUBSTR(create_time, 1, 10) AS dt, COUNT(*) AS cnt, SUM(order_amount) AS amt FROM ods.order_record WHERE create_time 2024-06-01 GROUP BY SUBSTR(create_time, 1, 10);如果两边汇总数据对不上优先检查增量任务的last-value是否重叠其次是--split-by字段是否有空值导致部分数据没被分配到 mapper 处理。5. 常见问题与排查技巧实录5.1 ORA-28547连接服务器失败检查监听配置这个报错在热词里出现了也是我从 Oracle 迁 Hadoop 时第一次见的报错。ORA-28547: connection to server failed, probable Oracle Net admin error字面意思是连接到非 Oracle 系统的连接失败可能是 Oracle Net 管理错误。这个报错最经典的成因有两个一是sqlnet.ora中配置了SQLNET.AUTHENTICATION_SERVICES (NTS)但当前 Oracle 客户端的认证方式不对二是监听器配置的协议或端口与客户端连接字符串不一致。排查思路按顺序来先检查sqlnet.ora和listener.ora的配置是否匹配lsnrctl status如果监听服务没有启动会报另一个经典错误ORA-12541: TNS:no listener。这时需要手动启动lsnrctl start再检查客户端连接字符串。比如我的 Sqoop 连接串写的是jdbc:oracle:thin:192.168.1.10:1521/ORCLPDB1但监听器配置的端口不是 1521就会触发 ORA-28547。用tnsping命令可以快速验证tnsping ORCLPDB1还有一类情况是数据库版本和客户端版本不兼容特别是 11g 和 12c 之间建议直接用 Oracle 官方推荐的驱动版本。热词里有人搜oracle 11.2.0.4补丁如果源库是 11.2.0.4最好先确认补丁是否打全再确认客户端驱动是 11g 系列避免驱动版本引发认证协议问题。5.2 驱动找不到ClassNotFound 与版本冲突Sqoop 提交作业时报java.lang.ClassNotFoundException: oracle.jdbc.OracleDriver是很常见的新手问题。原因通常是$SQOOP_HOME/lib下没有 ojdbc 驱动或者驱动版本与 JDK 不兼容。这里有一个细节如果你的 Hadoop 集群启用了 YARN 的mapreduce.jobhistory或引入了较多外部依赖可能出现驱动冲突。表现是本地测试sqoop list-tables没问题但提交到集群后运行失败。这种情况不是驱动没放而是驱动类加载顺序出了问题。我处理这类问题的顺序确认$SQOOP_HOME/lib下有且只有一个 ojdbc 驱动版本不要混放多个版本。检查HADOOP_CLASSPATH是否包含了 sqoop 的 lib 目录export HADOOP_CLASSPATH$HADOOP_CLASSPATH:$SQOOP_HOME/lib/*如果还是报错用--driver参数显式指定驱动类名sqoop import \ --driver oracle.jdbc.OracleDriver \ --connect jdbc:oracle:thin:192.168.1.10:1521/ORCLPDB1 \ ...5.3 小文件过多与动态分区问题增量跑了一段时间后HDFS 目录下会出现大量小文件。每个 Sqoop 任务默认生成的 map 输出文件数和-m一致如果每天跑几十张表累积起来就是几百上千个小文件对 NameNode 内存和后续 Spark 查询性能非常不友好。缓解方案有几种在 Hive 侧对小文件进行合并SQL 里可以用INSERT OVERWRITE加DISTRIBUTE BY的方式重写。将 Sqoop 导入的目标改成先落临时目录再合并进正式分区的流程。对增量频率做降频处理从每小时增量改成每天一次。这里特别说一下 Hive 动态分区的问题。如果一张表的分区很多比如按天分区且跨 3 年Sqoop 导入时同时写多个分区很容易触发Hive: Per-reducer limit on rows相关的报错。这是因为每个 reducer 写分区文件时内存受限。解决办法是控制单次导入的分区数或者调大hive.exec.max.dynamic.partitions.pernode参数。5.4 字符集与中文乱码问题Oracle 字符集一般是AL32UTF8或ZHS16GBKHDFS 上默认存 UTF-8。如果 Oracle 是 GBK 而 Sqoop 导入时没有指定字符集中文会乱码。解决办法是在 JDBC 连接串里加useUnicodetruecharacterEncodingUTF-8或者在 Sqoop 命令里指定sqoop import \ --connect jdbc:oracle:thin:192.168.1.10:1521:ORCLPDB1?useUnicodetruecharacterEncodingUTF-8 \ ...不过需要注意Oracle 的 JDBC 连接串不支持像 MySQL 那样随意加参数。更通用的做法是在查询 SQL 里显式转码CONVERT(column_name, UTF8, ZHS16GBK)。我在一个项目里就遇到过 Oracle 是 ZHS16GBK、但个别字段混入了特殊字符的情况直接CONVERT后会变成?这个问题只能通过规范源端数据来解决。5.5 大表迁移性能太慢怎么调大表迁移慢是最常被问的问题。我的调优顺序是这样的先看-m是否太低。默认-m 4对于亿级以下表够用但十亿级以上的表在源库负载允许的情况下可以提到-m 12以上。再看--fetch-size。Oracle JDBC 默认一次 fetch 100 行对网络往返开销影响不小。调成5000或10000后导入速度往往有明显提升。然后看--split-by是否合理。如果用时间字段做 split而该字段有大量重复值会导致部分 mapper 处理数据量严重不均。最后检查 YARN 资源。如果任务在提交后长时间处于 ACCEPTED 状态说明队列资源不足。一个典型的调优结果是同样一张 2 亿行的表把-m从 4 调到 8、--fetch-size从 100 调到 5000 后耗时从 70 分钟降到 25 分钟以内。但也要注意继续往上加不一定更快因为源库的 CPU 和 IO 会成为新的瓶颈。6. 我的一些经验总结做这种迁移项目我个人最大的感受是真正决定项目成败的不是工具多强大而是前期评估和基线比对做得够不够细。Oracle 是高度成熟的商业数据库Hadoop 生态灵活但相对松散两者之间的逻辑对齐远比数据搬运复杂。给准备动手的同行几个建议迁移之前一定先梳理源表的数据字典尤其是NUMBER超长字段、CLOB字段、DATE字段。把字段类型映射表提前建好迁移时按图索骥不要临时临了再改。先挑 1 张千万级的小表跑通全流程包括建表、导入、校验、查询。验证没问题了再放大规模这样能最大限度降低返工成本。上线后的前两周每天都要做一次行数和关键指标校验。这段时间最容易发现增量逻辑的边界问题比如跨天时间窗口、更新延迟等。另外最后分享一个小技巧Sqoop 导完数据后_SUCCESS文件生成说明任务正常结束但不代表数据完全正确。我在项目里习惯再加一道文件行数累计校验用wc -l或 Hive 的COUNT(*)与 Oracle 的总行数比对。多花五分钟能免掉后面几天的排查之苦。
空间优化)
