【MRS】【FusionInsight】Hive并发MSCK Repair实践

【背景】

在Hive数据跨集群迁移场景下（例如从一套大数据老集群往新集群迁移Hive表数据时），一般需要先迁移Hive的业务数据（即Hive存储在HDFS上的数据）和Hive表的元数据，然后对新集群上迁移后的Hive所有表做MSCK Repair操作来修复表分区，以构建元数据和业务数据之间的联系，使得客户能正常访问Hive表。

但是，若对Hive所有的表逐个进行MSCK Repair，修复效率将会很慢，例如修复1000+个表，30+万个分区，修复时长需要5~6个小时左右，耗时非常长，大大占用了变更时间窗。因此，优化改进MSCK Repair，有效提升修复效率，将变得尤为急迫和重要。

【优化思想】

 MSCK Repair命令是对库中所有表逐个串行地修复，效率低下。若能有效利用客户端的线程资源，并发Repair，修复效率将会大大提升。

【优化步骤】

        前提：1）已通过Hadoop的Distcp命令将Hive的业务数据从老集群全量迁移到了新集群；2）已对每个Hive库show create table <Table名>导出老集群所有Hive表的DDL建表语句，并在新集群上创建全量表的元数据；

步骤1    对老集群上每个Hive库通过show tables命令获取库中所有表；

步骤2    假设MSCK Repair的并发数为10，那就将Hive库的所有表名均匀放到10个文本文件中（例如总共有1000个表，表名记录到10个文本文件，每个文本文件中放100个表名）。并且，确保分区较多的表不要集中放到一个文本文件，手动调整，均匀放到不同文件，这样使得并发的10个线程能接近同时跑完，不会出现部分线程拖尾。

步骤3    执行并发Repair工具来修复Hive表，以下摘出并发Repair工具的主要代码：

# concurrently run repair script 

for tableFile in $splitTablesList

do

    nohup bash "${shellDir}/repairTables.sh" "${database}" "$splitTables/$tableFile" >/dev/null 2>&1 &

done

其中，$splitTablesList存储的是10个文本文件名，${database}是Hive库名，$tableFile是每个文件文件名。 

并且，repairTables.sh脚本的主要代码如下：

function repairTables()
{
    cat "${tableFile}" | while read eachline
    do
        "${beelineCommand}" -e "use ${database}; MSCK REPAIR TABLE ${eachline};"
    done
}

其中，${beelineCommand}为客户端Hive beeline文件所在路径。 

【执行结果对比】

优化前，执行MSCK Repair修复1000+个表，30+万个分区，修复操作需要5~6个小时左右；

优化后，10并发执行MSCK Repair修复1000+个表，30+万个分区，修复操作只需0.5小时左右，效率提升10~12倍。若加大并发数量，执行效率会提升更多。 

【结论】

在Hive数据迁移过程中做MSCK Repair时，加入并发的思想，将使得迁移的耗时大大缩短，效率得到可观的提升。