Hive 数仓是大多数迁移客户都会遇到的场景。在迁移过程中，不建议同时在新集群进行业务升级（比如从 Hive on MR 迁移到 Hive on Tez 或 Spark SQL等），这些业务升级可以在迁移完成后进行。

1. 元数据同步

Hive 元数据是对于 Hive 表来说非常关键，除了表结构信息，里面还记录着 Hive 表与底层文件系统的关联关系，许多上层服务都依赖 Hive 元数据提供服务。

a. 准备工作

在实际业务场景中，元数据经常会发生变化，为了避免迁移过程中元数据发生改变，建议先保证原有元数据的稳定性。这里可以通过 hive.metastore.pre.event.listeners 配置自己实现的 listener，在一段时间（比如每天9:00～15:00）内禁止修改元数据（建议在 listener 内通过外部服务实现灵活控制，不要求重启metastore），利用实现的同步脚本在这段时间内同步两侧元数据，同时保证原有环境元数据服务可读。

Hive 元数据服务依赖底层的 mysql/自建rds/统一rds 等服务。根据实际的规划选择使用的底层服务后，如果使用自建 rds 方案，需要确保 rds 用户的权限配置。

另外，在迁移 Hive 元数据时，还要考虑版本兼容性的问题。在本阶段，建议先收集原有元数据库的版本，在实际同步阶段使用。

b. 导出原有元数据

原有元数据导出，可以使用 mysqldump 工具进行。在老集群上执行如下命令：

mysqldump -t DATABASENAME -h HOST -P PORT -u USERNAME** -p PASSWORD** > /tmp/metastore.sql

命令中的一些参数，可以查看老集群 hive metastore 服务的 xml 配置文件，以javax.jdo.option.ConnectionUserName、javax.jdo.option.ConnectionPassword 和 javax.jdo.option.ConnectionURL 的实际值为准。

导出的 /tmp/metastore.sql 即为导出的元数据。

c. 修改导出数据

根据原集群配置，找到所有设计到底层路径的字段。如果原集群使用 HDFS，那么应该是 HDFS 的路径（注意除了hdfs:// 开头的路径，还有 / 开头的路径），如果原集群是 S3 则找到所有 S3 的路径。需要在 .sql 文件中全部替换为相应的 OSS 路径，另存为 metastore-oss.sql .

d. 同步到现有元数据库

这一步建议在数据同步后进行。

如果使用 RDS，首先修改新 EMR 集群 Master 节点上的 /usr/local/emr/emr-agent/run/meta_db_info.json，把里面的 use_local_meta_db 设置为false，meta 数据库的链接地址、用户名和密码换成RDS的信息。如果是 HA 集群，那么每个 master 都需要处理。这个步骤只需要做一次即可。

使用 mysqldump 命令，将 metastore-oss.sql 文件导入新集群的 mysql 或 RDS，命令如下：

mysql -u root -p database_name < metastore-oss.sql

如果 Hive 版本不一致，同步后，使用 hive 提供的脚本解决 metastore 版本问题。脚本位于 /usr/lib/hive-current/scripts/metastore/upgrade/mysql/ 下，依次执行脚本升级到 EMR 集群 hive 版本即可。

同步完成后建议重启新集群的 Hive metastore 和 hiveserver2（清除一些缓存的统计信息），然后在 hivecli 或 beeline 中验证元数据可用。这种同步方式无需再用 msck 命令修复分区。

对于每天的增量，可以构建上述 b、c、d步骤的脚本，每天全量同步原集群的元数据到新集群（mysqldump 的脚本中一般会删除原有 mysql 数据）。

2. 数据同步

数据同步指 Hive 数仓内数据文件的同步。这一块的同步参见文件系统的数据同步。在元数据同步与数据同步均完成后，可以在两套环境中通过 presto 查询对每张表执行 count(*) 保证数据数量一致。

如果元数据比较稳定，不会做与数据同步同周期的同步，对于一些按天/小时等进行分区的表，还需在数据同步后手动执行 msck 命令在 hive metastore 中修复分区。

3. 作业迁移

a. 搭建作业调度框架

根据老集群的使用习惯，可能需要自己搭建作业调度框架（例如airflow等），然后把老集群的作业全部复制到新集群，注意需要修改作业调度框架中定义的客户端/服务的地址。

自建作业调度框架建议部署在 EMR gateway 上。

b. 解决作业兼容性

这里的兼容性指运行报错方面的问题。有些运行报错是因为配置不同步（需要调整某些配置开关）引起的，所以在执行前，最好先保证两边 hive/spark 等引擎配置一致。然后我们启动作业调度框架，根据失败任务的日志分析兼容性问题。

一种兼容性问题是业务引起的，比如依赖的某个外部服务没有安装或配置不对。这种情况很容易通过报错信息发现。另一种兼容性问题来自引擎版本的区别。如果是从 Hive 1.x 迁移到 Hive 2.x 以上版本，由于 Hive 2.x 引入了 Calcite 作为默认的优化器，可能有较多不兼容场景（EMR团队已经修复了很多 Calcite 的 bug，但还是不能保证面面俱到），可以先设置 hive.cbo.enable = false 绕开，然后提交给 EMR 技术团队进行修复解决。

确保所有作业能正常运行后，进入对数阶段。

c. 对数

在完成作业迁移之后，还需要对作业的结果进行比对，确保和原环境一致。一般来说，如果数据同步完成后每张表的数据都已经一样，对数环节应该不会有太大偏差。主要的偏差来源于引擎不同版本的语法区别、自定义udf函数不稳定、作业本身结果不稳定。由于实际业务场景可能非常复杂，所需处理的作业数量很多，应当先理清业务之间的依赖关系，找到出问题的作业和原因，然后同步给相关业务方进行修改。

由于一些调度作业依赖历史数据，所以在对数阶段，需要保证每天运行前先做好数据同步工作。

要找到出问题的作业，首先要构建作业间的依赖关系。Airflow 的 DAG 信息中可以查看作业的依赖关系，也可以使用 Hive 的 post hook 和 Spark 的 QueryExecutionListener 机制，收集表之间的依赖关系。查询依赖关系后，可以从最终不一致的表出发，寻找到上游出问题的作业，根据作业分析问题所在。常见的原因有不稳定的UDF（依赖分区方式或外部服务等）、不一致的 SQL 语义（不同引擎版本）等。根据具体情况，由业务方进行修改，可以咨询 EMR 技术团队获取依赖关系收集和查询的帮助，以及作业修改意见。

对数全部通过，作业调度稳定运行一段时间（比如一周），迁移即完成，此时可以下线老集群。