5.2 EXPORT与IMPORT及查询导出

5.2 EXPORT 与 IMPORT 及查询导出

本节摘要：数据离开 Hive 有三类需求：迁移整张表、分发查询结果、留档备份。EXPORT 与 IMPORT 打包"数据目录加元数据存档"，在目标环境恢复出结构一致的表；INSERT DIRECTORY 家族把查询结果落到本地或 HDFS 指定目录；本节末尾给出三类需求的选型表与迁移演练清单。

为什么手工拷目录不算迁移

一个常见误区：迁移表就是把 HDFS 上的表目录拷到新集群。拷完之后新集群根本"看不见"这张表——第 1 章讲过，表的存在性登记在 Metastore 里，HDFS 上只有匿名目录。你还得在新集群重建表结构、对齐列名类型、逐个登记分区，任何一项手工出错，就是"数据在、表不对"的灵异现场。

EXPORT 把这两样一起打包：

EXPORT TABLE mall.orders TO '/backup/orders_export';
​

目标目录里出现两类内容：数据文件（按分区原样组织的目录树）加一个元数据存档文件（表结构、分区清单、统计信息的序列化记录）。IMPORT 在目标环境反向恢复：

IMPORT TABLE mall.orders FROM '/backup/orders_export';
​

新集群的 Metastore 里长出一张结构与来源完全一致的表，分区登记齐全，数据就位。可以只导部分分区：

EXPORT TABLE mall.orders PARTITION (dt = '2026-01-15') TO '/backup/orders_115';
​

跨集群迁移的操作形态：先 distcp 把导出目录拷到目标集群（或双集群共挂载的中间存储），再在目标端 IMPORT。EXPORT 的价值不在搬字节，而在让元数据与字节始终成对出现——迁移的正确性由机制保证，而不是靠操作者的细心。

IMPORT 还支持外部表形态恢复（数据留在导出目录、只登记引用）与改名恢复，用于测试环境拉生产表的场景：测试库 IMPORT 出外部表指向一份拷贝，生产表本体毫发无损。

查询结果的三种去处

日常更高频的需求是把查询结果送出去：给分析师一份 CSV、给下游系统一个 HDFS 数据集、给自己留一段验证样本。对应三条路。

导出到 HDFS 目录（给下游系统消费的标准路径）：

INSERT OVERWRITE DIRECTORY '/output/region_stats'
ROW FORMAT DELIMITED FIELDS TERMINATED BY ','
SELECT region, COUNT(*) AS cnt, SUM(amount) AS amt
FROM mall.orders
WHERE dt = '2026-01-16'
GROUP BY region;
​

执行计划是标准查询计划，末端 File Output Operator 的目的地从表目录换成指定目录，序列化格式由 ROW FORMAT 声明。注意 DIRECTORY 写出默认可能带压缩（与服务器配置相关），下游若按纯文本读需要显式关闭或解压。

导出到本地（拿一小份结果做检查或喂本地工具）：

INSERT OVERWRITE LOCAL DIRECTORY '/tmp/region_stats'
SELECT region, cnt FROM (前述查询) t;
​

LOCAL 形态是"集群算、结果拉回客户端机器"，结果集大时网络与客户端磁盘都是瓶颈，只适合小体量。大数据量给下游，永远走 HDFS DIRECTORY 或干脆落表让对方查表。

Beeline 静默输出（脚本化取数的轻量方案）：用 Beeline 的静默模式加输出格式参数把结果直接落成文件，适合调度脚本里取监控指标这类几百行的结果，省去建目录的仪式。它不经过 INSERT 计划，纯客户端行为。

备份策略的最小闭环

把 EXPORT 放进运维视角，一张重要表的备份闭环至少回答四问：

• 备什么：外部表（原始数据在共享目录，通常由数据湖备份方案覆盖）与内部表（Hive 拥有数据，必须纳入 EXPORT 计划）分开对待；
• 备到哪：EXPORT 目录应在异地存储或快照策略覆盖之下，否则备份与生产同生共死；
• 多久备一次：按分区滚动——每日分区表只 EXPORT 增量分区，全表 EXPORT 留给结构变更前；
• 怎么验证：定期在隔离环境 IMPORT 回来跑行数与抽样校验。没验证过的备份只是心理安慰。

结合第 4 章的所有权模型正好复习一遍：内部表的生死系于 DROP 一念，EXPORT 是它的保险单；外部表的 DROP 不伤数据，但要防"登记被删后重建困难"，定期 EXPORT 元数据存档（或 Metastore 数据库备份）同样必要——这份存档小得多，却决定重建的难易。

三类需求选型表

迁移演练清单

拿一个真实迁移任务（测试库搬到新集群）串起本章与前面章节的知识点，按序核对：

1. 盘点迁移对象：表清单、每张表内部还是外部、分区总量与数据量（内部表是主角）；
2. 目标端预检：版本兼容（低往高迁通常平滑，跨大版本查发行说明）、同名对象冲突；
3. 逐表 EXPORT：大表按分区批次导出，控制单批体量；
4. distcp 拷贝导出目录到目标集群，校验文件数与字节数；
5. 目标端 IMPORT，抽查 DESCRIBE FORMATTED 确认 Location 与格式正确；
6. 行数对账：关键分区 COUNT 比对，抽样若干行逐列比对；
7. 查询对账：挑三条典型业务 SQL，两边 EXPLAIN 比对计划结构（算子与路径一致即可，任务数因集群规模不同属正常），再比对结果；
8. 切换与回退预案：新表验证通过前，老表保留只读。

第七步是全册方法论的收官应用：迁移的对账不靠肉眼 trust，靠计划与结果的机械比对。EXPLAIN 在这里再一次证明它是贯穿建造、调优、迁移全生命周期的通用语言。

本节要点回顾

• EXPORT 成对打包：数据目录加元数据存档，IMPORT 反向恢复，迁移正确性由机制保证；
• 手工拷目录的残缺：HDFS 只有匿名目录，表的存在性在 Metastore，两者必须一起走；
• 分区级导出：滚动备份与大表迁移的粒度选择；
• 结果导出三通道：HDFS DIRECTORY 给系统、LOCAL 给小样本、Beeline 静默给脚本；
• 备份四问：备什么备到哪多久备怎么验，未验证的备份不算备份；
• 迁移对账：行数、抽样、EXPLAIN 计划结构三重比对，机械验证优于肉眼 trust。