MaxCompute 是阿里巴巴自研的旗舰大数据仓库服务，与开源 Hadoop 搭建的数仓相比，一个很大的不同点是 MaxCompute 并不直接开放类似 HDFS 这样的分布式文件系统的接口，数据进出 MaxCompute 都要经由结构化数据通道 Tunnel。因此已经使用 Hadoop 建仓的用户在选择 MaxCompute 时，首先需要考虑的问题是数据怎么搬迁。
搬站形式和使用场景
目前其实有多种途径将数据迁移至 MaxCompute，下表分别列出各种途径的优缺点及适用场景：
| 搬迁形式 | 需要使用的工具/服务 | 原理 | 适用场景 |
|---|---|---|---|
| 数据集成 | DataWorks | 数据集成提供资源执行作业，拉取数据 | - 数据集成支持的数据源 - 表数量有限（目前需要按表单独配置） |
| MMA: 闪电立方 | MMA、闪电立方、OSS | 1. 邮寄闪电立方设备进入用户机房进行本地拷贝 1. 闪电立方邮寄回阿里云并挂载到 OSS 1. MaxCompute 通过 OSS 外表机制导入数据 |
- MaxC 外表支持的文件格式 - 大数据量一次性搬迁 - 机房出口带宽受限或不具备安装专线条件 |
| MMA: Hive SQL | MMA | 使用客户 Hadoop 集群资源执行 Hive SQL，通过 UDTF 的形式读取数据并写入 MaxCompute | - 最好的数据格式支持（包括 Hive 外表） - 数据量有限或具备到阿里云的专线 - 现有集群能够承担搬站任务的资源负载 |
表格中的 MMA 为 MaxCompute Migrate Assist 的缩写，是一套辅助 Hadoop 用户搬迁数据的工具。这套工具可以自动化批量爬取 Hive Meta，创建对应的 MaxCompute 表和分区，为客户 Hadoop 集群生成配套的 Hive SQL 搬迁任务或为 OSS 外表生成 MaxCompute 外表导入任务，并能够自动调度、监督、管理这些任务的执行，以及数据搬迁完毕后的校验工作，从而大大简化搬站中的手工操作步骤。
本文主要讨论使用 MMA: Hive SQL 形式进行大规模数据搬站时的常见问题及解法。
MMA: Hive SQL 常见问题及解法
MMA 搬站工具的原理是在用户侧的 Hadoop 集群执行 Hive SQL读取数据，并使用 UDTF 通过 Tunnel 将数据写入 MaxCompute。因此，MMA 搬站任务重度依赖于 Hive SQL 在客户集群的正常运行，背后其实体现对 Hadoop 集群的管理运维水平。当集群负载较高或情况复杂时，搬站作业可能会因多种原因失败而延迟搬迁进度。
作业规模问题：OOM
首先常见的问题是 OOM。MMA 使用 MR 模式执行 Hive SQL，因为当输入表文件非常多，hive cli 在进行 SQL 解析并生成 MR 任务时非常容易内存不足。
现象是 hive cli 会消耗较长时间频繁 Full GC，并最终因内存不足退出：
FAILED: Execution Error, return code -101 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask. GC overhead limit exceededFAILED: Execution Error, return code -101 from org.apache.hadoop.hive.ql.exec.mr.MapRedTask. Java heap spaceException: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main-EventThread"因为内存不足发生在客户端，因此需要调大 hive cli 的 Xmx 设置，如 HADOOP_CLIENT_OPTS。但具体设置生效的做法可能会因 Hadoop 部署版本不同，而且因为某些 Hadoop 版本 bug 的原因，在 java 进程启动参数中可能有多个 Xmx，比较难以准确找到并控制实际生效的参数，因此，MMA 提供了一个更加直接的解决办法：找到 hadoop 的启动脚本（不同版本的 Hadoop 部署也会稍微不同，这里以 Aliyun E-MapReduce 为例），在 exec java 的 class 前加上 MMA_OPTS 环境变量（如下），MMA 会在调用 hive cli 时通过 MMA_OPTS 将搬站作业的 Xmx 控制在 5GB，同时不影响集群现有的默认配置。
[root@emr-header-1 bin]# which hadoop
/usr/lib/hadoop-current/bin/hadoop
[root@emr-header-1 bin]# tail /usr/lib/hadoop-current/bin/hadoop
HADOOP_OPTS="$HADOOP_OPTS $HADOOP_CLIENT_OPTS"
#make sure security appender is turned off
HADOOP_OPTS="$HADOOP_OPTS -Dhadoop.security.logger=${HADOOP_SECURITY_LOGGER:-INFO,NullAppender}"
export CLASSPATH=$CLASSPATH
exec "$JAVA" $JAVA_HEAP_MAX $HADOOP_OPTS $MMA_OPTS $CLASS "$@"
;;
esac数据问题：HDFS
搬站作业失败或者不稳定的另一大类原因则跟 HDFS 相关。
- 文件未正常关闭导致无法读取
Caused by: java.io.IOException: Cannot obtain block length for LocatedBlock{BP-2042735465-10.1.5.152-1530865291994:blk_1789042978_715673405; getBlockSize()=1724740; corrupt=false; offset=0; locs=[DatanodeInfoWithStorage[10.40.11.121:50010,DS-ad53ff64-1a7c-4656-b89e-180b8f53bd20,DISK], DatanodeInfoWithStorage[10.40.11.79:50010,DS-dd8bc397-2889-4e04-842b-e1b5eee3bdec,DISK], DatanodeInfoWithStorage[10.40.11.83:50010,DS-2fc4ff46-47aa-41bb-932f-080456fccbd7,DISK]]}通常是软件 bug 导致（Flume 常见），解决办法参考文档，需要使用 hdfs 工具对指定文件做 recoverLease 操作
hdfs debug recoverLease -path <path-of-the-file> -retries 3- 文件损坏导致无法读取
Caused by: java.io.IOException: Could not obtain the last block locations.输入表文件缺失了 block，需要对表对应的 hdfs location 进行 fsck。
- HDFS IO 负载过高导致写出文件概率失败
Caused by: org.apache.hadoop.hive.ql.metadata.HiveException: java.io.IOException: Unable to close file because the last block BP-2042735465-10.1.5.152-1530865291994:blk_2290288983_1218244259 does not have enough number of replicas.MMA 搬站作业在执行完毕之后，会向 HDFS 写入少量作业相关信息（Hive SQL 默认行为，非 MMA 刻意为之），如果 HDFS IO 负载特别高，有概率因写入失败导致作业失败。
此时可以选择重跑作业，当然还有一定概率失败，所以根治的办法是减轻 HDFS 的 IO 压力。IO 压力可能来自随 Hadoop 集群混部的其他系统，如 Presto。配置减少 Presto 实例数量可以缓解问题，提升搬站任务的成功率。
资源问题：vcore 优化
MMA 搬站作业是执行在客户 Hadoop 集群的 Hive SQL，因此，搬迁的效率实际上由作业能够并发的 Container 数量，集群出口带宽，以及 MaxCompute Tunnel 服务的入口带宽限制三者构成。
MMA 搬站作业为简单的读数据写 Tunnel 操作，单个 Container 使用的 CPU 和内存都非常受控，通常使用 Yarn 默认配置可以满足需求。如果因为集群默认配置被人为改动过，额外供给了 CPU 及内存，只会造成浪费。我们建议保持每个 Container 默认 1 vcore，不超过 4GB。可以通过调整集群以下参数来降低对集群 cpu 的浪费（MMA 搬站作业是 Map only 的 SQL，但校验作业带有 reducer）
| mapreduce.map.cpu.vcore | 1 | |
|---|---|---|
| mapreduce.map.memory.mb | 4096 | MMA 对作业内存没有高要求，此处可按照集群整体 CPU 和 Memory 配比来配置 |
| mapreduce.reduce.cpu.vcore | 1 |
资源问题：memory 优化
当 Hadoop 集群处于资源超卖状态且实际内存使用负载较高时，MMA 任务容易因为内存不足而失败（此时内存不足的问题发生在 Hadoop 集群而非提交作业的客户端）。
在 Hadoop 与 Presto 混合部署的场景中，Presto 很可能不仅有很高的 IO 负载，在繁忙时段还会消耗大量的内存，进而影响 Hive SQL 作业的正常运行。典型的报错如下：
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 232259584 bytes for committing reserved memory.Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00000007aa780000, 232259584, 0) failed; error='Cannot allocate memory' (errno=12)此时减小 MMA 作业并发可以在一定程度上降低作业失败的概率，根本性的做法需要控制 Presto 内存使用。
