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上。
“HDFS到MaxCompute的資料遷移流程”的具體實操内容示範請見視訊内容。
視訊傳送門