概述
大数据计算服务（MaxCompute，原名ODPS）是一种快速、完全托管的 GB/TB/PB 级数据仓库解决方案。MaxCompute 为用户提供了完善的数据导入导出方案以及多种经典的分布式计算模型，能够更快速的解决海量数据计算问题，有效降低企业成本，并保障数据安全。
随着MaxCompute的多Region部署，一些用户可能需要把MaxCompute的应用从老的Region上迁移到和自己的业务系统相同的Region上来，从而在数据传输上获得更好的性能并减少数据传输费用。本指导手册主要聚焦在数据迁移层面上，目标在于指导客户以最小业务影响的代价、简单高效的方法将数据迁移到其他Region上来。
在数据迁移完成后，用户可能需要做后续的诸如账号权限的迁移、大数据开发套件的任务的迁移甚至更加上游的产品迁移，本手册暂时不涉及这些内容，需要用户自行迁移。
本方案并非产品提供的标准服务范围内，强烈建议用户使用前先review源码并做好测试。
MaxCompute数据迁移方案
迁移流程说明
整个迁移的任务，分为准备工作、数据迁移、以及最后的结果验证。
图2.1 迁移实施流程
数据迁移的过程已经基于MaxCompute的Java SDK实现了，用户可以根据后面的操作步骤进行操作即可完成。如果有一些预期外的报错或者特殊需求无法实现的话，我们也提供了整个工程的打包，用户可以把代码进行修改后重新编译执行。
准备工作
项目创建
本次迁移是针对同一个用户下有多个Project的场景做的。假设用户已经创建云账号、通过了实名认证并且已经创建好2个Project并且其中有一个待迁出的Project内有数据。
理论上本方案也支持跨账户间的不同的Project的迁移。不过由于时间比较仓促，并未对这些方面进行完备测试，如用户有这方面的需求需要用户自行调试。
环境搭建
首先用户需要一台能连接到MaxCompute的服务器，可以是ECS云服务器，也可以是有公网访问能力的自己的电脑比如一台笔记本电脑。
需要参考文档安装MaxCompute的客户端。具体可以参考https://help.aliyun.com/document_detail/27804.html。 需要注意的是MaxCompute客户端需要JRE 1.7或以上版本。下载安装完成后，需要配置客户端的参数文件。用户需要配置2个参数文件，分别对应嵌入的项目和迁出的项目，后续的说明里，有数据待迁出的项目的参数文件是odps_config_from.ini，待迁入的项目的参数文件是odps_config_to.ini。
具体下载客户端的操作步骤：
mkdir ~/maxcompute
cd ~/maxcompute/
wget http://repo.aliyun.com/download/odpscmd/latest/odpscmd_public.zip
unzip odpscmd_public.zip
cd ./conf
cp odps_config.ini odps_config_from.ini
填写相关信息
cp odps_config_from.ini odps_config_to.ini
修改project信息
数据迁移
把打包出的jar包（或者直接使用附件提供的migrate.jar）传到~/ maxcompute/ 这个路径下。
java -classpath ./migrate.jar:./lib/* com.aliyun.maxcompute.Migrate /root/maxcompute/conf/odps_config_from.ini /root/maxcompute/conf/odps_config_to.ini
观察里面的日志，特别是WARNING和ERROR级别的日志。
迁移的代码会执行3个步骤：
1. 读取配置文件，并通过show tables命令来校验配置是否生效，是否能正常访问数据库。（会打印返回的第一张表的名字或者提示找到0张表）
2. 做表meta的迁移，把表结构拷贝过来。对于外部表不会迁移。如果是视图会执行一次SQL，但是由于视图涉及的表可能在排在这个视图之后才导入，所以可能有一些视图不会迁移成功（不成功的视图有WARNING级别的日志），需要用户手工继续迁移这些失败的视图。
3. 数据迁移，在技术选型上，有Tunnel和SQLTASK使用SQL拷贝数据两种方案。对此做了对比，本文档选择使用SQLTASK作为数据迁移的方案。主要考虑到Tunnel方案相对比较复杂，而且数据要上传下载对传输服务器的压力较大，而且走公网可能会受到网络的瓶颈。再者用Tunnel需要事先创建好分区，而目前创建表和分区的操作速度还不尽人意，如果有的用户需要迁移的表或者分区特别多，这个时间无法忍受。
注意事项
首先本迁移方案使用SQL进行迁移，每个表的数据同步会对应到MaxComupute的一个SQL，因此可能会产生计算费用（体现在导入的project里）。
瓶颈限制
本方案使用SQL进行数据同步，所以会受到MaxCompute关于SQL的各种限制。主要体现在分区表上。如果用户的分区表的分区数量特别多，超过了一万个，会导致报错。届时需要用户自行对这个表做数据迁移。迁移方案是使用SQL，每次Insert的时候用Where条件过滤只迁移部分的分区，把一张表通过多个SQL作业进行迁移。另外对于分区表的分区特别多的场景，动态分区的MergeTask可能会多消耗一些时间，这是符合预期的（这是目前针对分区表里分区特别多的场景里最快速的方案了）。
本作业会提交大量的SQL作业。目前MaxCompute对用户提交的作业会进入排队，并不会马上执行。如果需要同步的表较多，可能排队时间会比较长。特别是提现在导入项目是包年包月的项目，但是购买的CU较少的情况下。可以考虑购买更多的CU或者耐心等待。如果是按量付费的项目，由于集群的整体资源以及集群上的安全限制等原因，也可能会出现任务排队的情况。这是符合迁移预期的。
验证方法
- 查看日志，是否有WARNING级别和ERROR级别的日志，并根据错误的提示进行排查定位。
- 同步结束后，查看表的数量和表结构是否能对上。不过表的size字段无法作为数量的核对标准。数据在传输过程中可能会经过shuffle，再经过列式压缩的时候，压缩后的数据量可能会发生变化。当然如果有太明显的变化比如为0那就是有问题的。校验数据量可以用SQL来查询一下里面的数据，看看统计结果是否能对上。而且MaxComute本身计算有校验。MaxCompute SQL如果没有报错的话，数据的同步时候没有问题的。