直播視頻回看，傳送門！
分享資料下載，傳送門！
更多精彩內容傳送門：大數(shù)據(jù)計算技術共享計劃 — MaxCompute技術公開課第二季?

?

以下內容根據(jù)演講視頻以及PPT整理而成。

通常而言，將Hadoop遷移到MaxCompute會分為兩個主要部分：數(shù)據(jù)遷移和任務遷移。首先，對于數(shù)據(jù)遷移而言，可以通過Datax、數(shù)據(jù)集成以及DataxOnHadoop這幾種工具實現(xiàn)。Datax是阿里云開源的一款數(shù)據(jù)傳輸工具；而數(shù)據(jù)集成的底層就是由Datax實現(xiàn)的。如果在數(shù)據(jù)遷移的過程中要使用Datax，那么需要用戶來自定義調度，這對于gateway資源具有一定的要求。Datax在做數(shù)據(jù)傳輸?shù)臅r候需要有一個管道機，通常就稱之為gateway，數(shù)據(jù)的傳輸都是通過這個gateway來實現(xiàn)的，因此在使用Datax的時候對于gateway的資源是具有一定的要求的。此外，數(shù)據(jù)集成是在DataWorks里面集成化的數(shù)據(jù)傳輸工具。如果想要應用數(shù)據(jù)集成，那么其調度就是在DataWorks里面完成的，設置完數(shù)據(jù)周期等一些屬性，DataWorks就可以自動實現(xiàn)任務的調度。如果使用數(shù)據(jù)集成，在網(wǎng)絡允許的情況下，可以使用DataWorks的gateway公共網(wǎng)絡資源，如果網(wǎng)絡不允許則可以使用自定義的調度資源。

除了上述兩種方式之外，還有DataxOnHadoop。DataxOnHadoop運行在客戶端，用戶自己進行調度，與前面的兩種方式最大的不同，就是DataxOnHadoop使用的是Hadoop集群的資源，這就相當于提交MapReduce任務，通過MapReduce任務進行數(shù)據(jù)傳輸，因此對于網(wǎng)絡的要求比較高。因為需要提交MapReduce任務，這就要求Hadoop集群的每個Worker或者DataNode Manager節(jié)點和MaxCompute的Tunnel網(wǎng)絡打通，這也是這種方案的應用難點。

除此之外，還有一些因素會影響我們在進行數(shù)據(jù)遷移時做出方案的選擇，分別是網(wǎng)絡、數(shù)據(jù)量和遷移周期。對于網(wǎng)絡而言，通常分為這樣的幾種類型，混合云VPC，也就是客戶本地機房與阿里云打通在一個VPC里面，還有客戶本地機房，一般而言客戶的本地機房會有一部分主機具有公網(wǎng)IP，這時候在進行數(shù)據(jù)遷移的時候就傾向于使用Datax，這是因為客戶的集群沒有辦法直接與MaxCompute打通，還可能使用數(shù)據(jù)集成，通過使用自定義調度資源來完成這個事情。此外，還有一種情況就是客戶集群位于阿里云上，對于經(jīng)典網(wǎng)絡集群，可以通過數(shù)據(jù)集成直接將數(shù)據(jù)遷移過來；而對于VPC網(wǎng)絡而言，數(shù)據(jù)集成可能無法直接深入VPC內部，這時候也需要自定義調度資源。當然對于VPC集群而言，也可以DataxOnHadoop，每個節(jié)點正常情況下會與MaxCompute的Tunnel可以打通。對于混合云VPC而言，其選項會比多，數(shù)據(jù)集成以及DataxOnHadoop都可以使用。而對于數(shù)據(jù)量而言，可以和遷移周期綜合起來考慮，線下機房需要遷移的數(shù)據(jù)有多大以及要求的工期有多長也會影響我們選擇的數(shù)據(jù)遷移方式，并且對于需要準備的網(wǎng)絡帶寬等資源也是有影響的。

Datax
從總體上而言，Datax改變了一種模式，就是數(shù)據(jù)的導入和導出，比如MySQL到Oracle或者MySQL到ODPS都是單點的，每一種導入和導出都會有單獨的工具作為支持。而Datax就實現(xiàn)了各種插件，無論是各個數(shù)據(jù)庫之間如何導入導出，都是通過Datax的gateway實現(xiàn)中轉的，首先到Datax，然后再到ODPS，這樣就從原來的網(wǎng)狀模式變成了星型模式。

下圖較好地解釋了Datax的應用，可以看到前面有一個ReadPlugin，無論是從哪個源端到哪個目標端，都是有一個Reader。對于MySQL而言就有一個MySQLReader，對于HDFS，就有一個HDFSWriter，這樣結合MySQLReader和HDFSWriter就能形成MySQL到HDFS的傳輸。再設想一下，下面還有一個ODPSWriter，那么也就能夠通過MySQLReader到ODPSWriter，形成這樣的鏈路，從而能夠形成各種組合，打通各條鏈路。而之前提到的Reader和Writer都是在gateway上運行的，需要從源端讀取數(shù)據(jù)，向目標端寫入數(shù)據(jù)，所以gateway需要占用帶寬資源以及CPU內存資源，這也就是為何需要考慮gateway以及其資源的原因。

任務遷移
除了數(shù)據(jù)遷移之外，還需要關注任務遷移。這部分也分為兩部分，一部分是任務本身的遷移，另外一部分是調度平臺的遷移。對于任務本身的遷移而言，比如原來使用的Hive SQL，想要遷移到MaxCompute的SQL，這樣在遷移的匹配上可能會有一些遷移的工作量。原來在Hive上定義的UDF，寫的MaxCompute程序或者Spark任務這些也都需要進行遷移。除此之外，還有一類就是調度平臺的遷移，原來的Hive SQL以及MaxCompute程序是通過某些調度工作進行周期性的任務運行，當遷移到MaxCompute之后，這些任務也需要進行相應的遷移。這里列舉了兩類，一類是遷移之后裸用MaxCompute，就相當于還作為原來的Hive來使用或者還是使用命令行或者API的方式做調用，此時原來的調度系統(tǒng)基本上不用變化，只需要將原來對Hive的接口改為對MaxCompute的接口就可以了。還有一類就是在遷移之后需要通過DataWorks進行調用，這個時候任務遷移的工作量就會大一些，首先需要將原來的任務遷移到DataWorks里面去，其次還要將原來的調度屬性也配置到DataWorks里面去。

接下來具體說明任務遷移需要做哪些具體工作，首先Hive SQL到MaxCompute SQL的兼容度非常高，目前而言，Hive的數(shù)據(jù)類型基本上直接可以對接到MaxCompute中，MaxCompute對于Hive語法而言也是基本上兼容的，僅需要簡單調試即可。如果UDF不涉及到磁盤讀寫或者網(wǎng)絡IO，也可以直接拿到ODPS來使用的，原來的Jar包不需要修改。MapReduce的改造量相對大一些，這是因為MaxCompute沙箱限制比較嚴重，那么一些文件讀寫以及網(wǎng)絡IO操作是被禁止掉的。而對于MaxCompute而言，輸出輸出都是表，而MapReduce主要針對的是HDFS的文件系統(tǒng)，因此需要做映射，對此MaxCompute也提供了相應的工具，只不過相對于UDF而言會略微麻煩一點。除此之外，還有Spark任務，這在原來的HDFS上相對會多一些，之后會有一個SparkOnMaxCompute，可以支持用戶將Spark程序無縫地遷移到MaxCompute上。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內容，未經(jīng)允許不得轉載。

總結

以上是生活随笔為你收集整理的理论与实践：如何从Hadoop迁移到MaxCompute的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。