摘要：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上。

原文鏈接

本文為雲棲社區原創內容，未經允許不得轉載。

理論與實踐：如何從Hadoop遷移到MaxCompute