1.Hive迁移的场景
在大数据数据仓库实践中，Hive是数仓最原始的实现方案，面对日新月异的技术迭代，更多类型的数仓或者湖仓展示在用户面前，如果要切换到新的数仓或湖仓解决方案中。这里就会遇到Hive的迁移。
还有一些灾备场景也会遇到，需要讲集群A的Hive数据同步到集群B，集群B作为灾备集群，处于冷备状态。
2.Hive迁移方案
Hive的迁移包括两大块：一块是表数据迁移，可能存放在HDFS或者对象存储系统中。另一块是Hive表元数据迁移，Hive元数据由Hive Metastore管理，数据存在关系型数据库中，比如Mysql、PostgreSQL等。
2.1.Hive表数据迁移
因为数据存放在HDFS等文件存储系统中，可直接通过HDFS原生同步工具——distcp进行数据迁移，
如果有增量场景，则可以通过distcp的update选项来进行数据复制。
2.2.元数据全量迁移
Hive元数据存放在Mysql中，由Hive MetaStore管理，其迁移方案有以下几种。
2.2.1.方案一：msyql数据拷贝
将源端mysql的数据导出为sql文件，并导入到目的端，注意迁移前后分区目录的变化，可能需要进行调整。
2.2.1.1.方案缺点
主要有以下几个缺点：
（1）一个是mysql版本兼容性问题，不同版本到处的sql可能无法通用。
（2）源端和目的端HiveMetastore使用的关系性数据库可能是互为异构数据库，也可能存在sql无法通用的场景。
（3）可能需要手动调整分区目录location
2.2.1.2.方案优点
这是业界通用的方案，有标准的操作文档。
2.2.2.方案二：MetaStore接口
通过HIveMetaStore的接口从源端进行查询，并在目的端进行表的同步创建。
2.2.2.1.方案缺点
Hive Metastore是thrift rpc接口，客户端版本非常重要，不同场景需要使用不同版本的rpc client，否则可能会不兼容的情况。
2.2.2.2.方案优点
使用Hive提供的原生功能，能够防止迁移后数据不匹配的场景。
并且，该方案能适配所有的场景，每个Hive都会有MetaStore。
2.2.3.方案三：HiveServer2进行表的重建
首先通过HiveServer2查询源端表的建表语句，再通过HiveServer2在目的端创建相同的表。
2.2.3.1.方案缺点
也需要防止源端和目的端Hive版本不匹配，DDL语法不兼容的问题。
对于视图的表无法覆盖。
2.2.3.2.方案优点
比较简单，可手动操作，无须工具也可实现。
2.3.元数据增量迁移
当元数据全量迁移完成后，在业务没有完全切换完成前，可能还会有部分DDL操作，所以需要设计元数据的增量迁移。
增量迁移方案主要有以下几种：
2.3.1.方案一：再跑一次全量迁移
通过MetaStore拿到所有的表信息，如果有变化，就进行更新。
方案优点：复用全量迁移方案，简单。
方案缺点：性能比较慢。在单线程测试中，3.5万张表，1200万分区，在少量变更的情况下，也需要16分钟。
2.3.2.方案二：Hook来实现
MetaStore提供hook机制，用于感知元数据的变化，并把变化同步到目的端Hive。
对应的接口为org.apache.hadoop.hive.metastore.MetaStoreEventListener，我们需要实现MetaStoreEventListener中的方法，并将实现类配置到hive-site.xml中的hive.metastore.event.listeners参数。
方案优点：精准找到对应的元数据变更，效率非常高。
方案缺点：需要实现MetaStoreEventListener，对源端Hive有一定的侵入。需要额外维护变更状态，并对变更内容做解析。
2.3.3.方案三：MNotificationLog来实现
Hive提供了org.apache.hadoop.hive.metastore.model.MNotificationLog，当元数据发生变更时，将变更信息打包为一个事件，写入到数据库中。客户端从数据库中查询变更的事件，并将变更事件解析为元数据变更请求，同步到目的端Hive。
方案优点：对源端Hive无侵入作用，实现简单，效率高，由客户端来控制同步效率。
方案缺点：MNotificationLog有TTL，如果过期可能导致遗漏。同样需要对MNotificationLog内容做解析。
2.3.4.方案四：通过MetaStore查询到变更的表或分区
调用源端Hive Metastore的thrift rpc接口，获取上次同步完成时间之后有变更的表和分区（参考transient_lastDdlTime字段值），并封装成元数据变更请求，调用目的端Hive Metastore的thrift rpc接口进行变更。
方案优点：实现简单，使用hive原生api。
方案缺点：需要遍历所有的表和分区，效率低。且无法识别到删除的表。
2.3.5.方案五：通过MetaDB查询到变更的表或分区
直接进行DB侧的同步，对比源端和目的端的元数据库，生成更新的sql，在目的端的DB执行。
方案优点：方案简单，最直接获取到变更点。
方案缺点：无法识别到删除的表。比如源端没有A表，而目的端有A表，无法判断是源端删除了A表还是目的端新增了A表。