理论与实践：如何从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上。

原文连接
本文为云栖社区原创内容，未经容许不得转载。