金昌市建设局网站,上海建设摩托车官网,有赞微商城登录首页登录入口,wordpress 连不到js直播视频回看#xff0c;传送门#xff01;分享资料下载#xff0c;传送门#xff01;更多精彩内容传送门#xff1a;大数据计算技术共享计划 — MaxCompute技术公开课第二季 以下内容根据演讲视频以及PPT整理而成。
通常而言#xff0c;将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上。
原文链接 本文为云栖社区原创内容未经允许不得转载。
