摘要： MaxCompute大数据计算服务，能提供快速、完全托管的PB级数据仓库解决方案，能够使用户经济且高效地分析处理海量数据。而用户往往之前使用了Hadoop实现大数据计算任务，在选择了阿里云大数据计算服务之后，如何从Hadoop向MaxCompute进行迁移就成为了一个需要面对的问题了。
摘要：MaxCompute大数据计算服务，能提供快速、完全托管的PB级数据仓库解决方案，能够使用户经济且高效地分析处理海量数据。而用户往往之前使用了Hadoop实现大数据计算任务，在选择了阿里云大数据计算服务之后，如何从Hadoop向MaxCompute进行迁移就成为了一个需要面对的问题了。在本文中，阿里云数据技术专家结网就为大家分享了从Hadoop迁移到MaxCompute的理论与实践。
直播视频回看，传送门！
分享资料下载，传送门！
更多精彩内容传送门：大数据计算技术共享计划 — MaxCompute技术公开课第二季
以下内容根据演讲视频以及PPT整理而成。
通常而言，将Hadoop迁移到MaxCompute会分为两个主要部分：数据迁移和任务迁移。首先，对于数据迁移而言，可以通过Datax、数据集成以及DataxOnHadoop这几种工具实现。Datax是阿里云开源的一款数据传输工具；而数据集成的底层就是由Datax实现的。如果在数据迁移的过程中要使用Datax，那么需要用户来自定义调度，这对于gateway资源具有一定的要求。Datax在做数据传输的时候需要有一个管道机，通常就称之为gateway，数据的传输都是通过这个gateway来实现的，因此在使用Datax的时候对于gateway的资源是具有一定的要求的。此外，数据集成是在DataWorks里面集成化的数据传输工具。如果想要应用数据集成，那么其调度就是在DataWorks里面完成的，设置完数据周期等一些属性，DataWorks就可以自动实现任务的调度。如果使用数据集成，在网络允许的情况下，可以使用DataWorks的gateway公共网络资源，如果网络不允许则可以使用自定义的调度资源。
除了上述两种方式之外，还有DataxOnHadoop。DataxOnHadoop运行在客户端，用户自己进行调度，与前面的两种方式最大的不同，就是DataxOnHadoop使用的是Hadoop集群的资源，这就相当于提交MapReduce任务，通过MapReduce任务进行数据传输，因此对于网络的要求比较高。因为需要提交MapReduce任务，这就要求Hadoop集群的每个Worker或者DataNode Manager节点和MaxCompute的Tunnel网络打通，这也是这种方案的应用难点。
除此之外，还有一些因素会影响我们在进行数据迁移时做出方案的选择，分别是网络、数据量和迁移周期。对于网络而言，通常分为这样的几种类型，混合云VPC，也就是客户本地机房与阿里云打通在一个VPC里面，还有客户本地机房，一般而言客户的本地机房会有一部分主机具有公网IP，这时候在进行数据迁移的时候就倾向于使用Datax，这是因为客户的集群没有办法直接与MaxCompute打通，还可能使用数据集成，通过使用自定义调度资源来完成这个事情。此外，还有一种情况就是客户集群位于阿里云上，对于经典网络集群，可以通过数据集成直接将数据迁移过来；而对于VPC网络而言，数据集成可能无法直接深入VPC内部，这时候也需要自定义调度资源。当然对于VPC集群而言，也可以DataxOnHadoop，每个节点正常情况下会与MaxCompute的Tunnel可以打通。对于混合云VPC而言，其选项会比多，数据集成以及DataxOnHadoop都可以使用。而对于数据量而言，可以和迁移周期综合起来考虑，线下机房需要迁移的数据有多大以及要求的工期有多长也会影响我们选择的数据迁移方式，并且对于需要准备的网络带宽等资源也是有影响的。
Datax
从总体上而言，Datax改变了一种模式，就是数据的导入和导出，比如MySQL到Oracle或者MySQL到ODPS都是单点的，每一种导入和导出都会有单独的工具作为支持。而Datax就实现了各种插件，无论是各个数据库之间如何导入导出，都是通过Datax的gateway实现中转的，首先到Datax，然后再到ODPS，这样就从原来的网状模式变成了星型模式。
下图较好地解释了Datax的应用，可以看到前面有一个ReadPlugin，无论是从哪个源端到哪个目标端，都是有一个Reader。对于MySQL而言就有一个MySQLReader，对于HDFS，就有一个HDFSWriter，这样结合MySQLReader和HDFSWriter就能形成MySQL到HDFS的传输。再设想一下，下面还有一个ODPSWriter，那么也就能够通过MySQLReader到ODPSWriter，形成这样的链路，从而能够形成各种组合，打通各条链路。而之前提到的Reader和Writer都是在gateway上运行的，需要从源端读取数据，向目标端写入数据，所以gateway需要占用带宽资源以及CPU内存资源，这也就是为何需要考虑gateway以及其资源的原因。
任务迁移
除了数据迁移之外，还需要关注任务迁移。这部分也分为两部分，一部分是任务本身的迁移，另外一部分是调度平台的迁移。对于任务本身的迁移而言，比如原来使用的Hive SQL，想要迁移到MaxCompute的SQL，这样在迁移的匹配上可能会有一些迁移的工作量。原来在Hive上定义的UDF，写的MaxCompute程序或者Spark任务这些也都需要进行迁移。除此之外，还有一类就是调度平台的迁移，原来的Hive SQL以及MaxCompute程序是通过某些调度工作进行周期性的任务运行，当迁移到MaxCompute之后，这些任务也需要进行相应的迁移。这里列举了两类，一类是迁移之后裸用MaxCompute，就相当于还作为原来的Hive来使用或者还是使用命令行或者API的方式做调用，此时原来的调度系统基本上不用变化，只需要将原来对Hive的接口改为对MaxCompute的接口就可以了。还有一类就是在迁移之后需要通过DataWorks进行调用，这个时候任务迁移的工作量就会大一些，首先需要将原来的任务迁移到DataWorks里面去，其次还要将原来的调度属性也配置到DataWorks里面去。
接下来具体说明任务迁移需要做哪些具体工作，首先Hive SQL到MaxCompute SQL的兼容度非常高，目前而言，Hive的数据类型基本上直接可以对接到MaxCompute中，MaxCompute对于Hive语法而言也是基本上兼容的，仅需要简单调试即可。如果UDF不涉及到磁盘读写或者网络IO，也可以直接拿到ODPS来使用的，原来的Jar包不需要修改。MapReduce的改造量相对大一些，这是因为MaxCompute沙箱限制比较严重，那么一些文件读写以及网络IO操作是被禁止掉的。而对于MaxCompute而言，输出输出都是表，而MapReduce主要针对的是HDFS的文件系统，因此需要做映射，对此MaxCompute也提供了相应的工具，只不过相对于UDF而言会略微麻烦一点。除此之外，还有Spark任务，这在原来的HDFS上相对会多一些，之后会有一个SparkOnMaxCompute，可以支持用户将Spark程序无缝地迁移到MaxCompute上。
本文为云栖社区原创内容，未经允许不得转载。
原文地址：http://blog.51cto.com/13952056/2285337