利用Tsunami UDP將大資料移轉至雲中

標籤：aws   大資料   遷移   amazon s3   

當你的資料規模達到PB層級的時候，想要移動這樣大規模資料時就會變的費時費力，這也是企業在利用AWS規模化和彈性優勢處理分析任務時面臨的最大挑戰之一。本文主要介紹了加速檔案傳輸通訊協定，談到如何利用Tsunami DUP實現將大規模資料移轉到雲中，其中利用UDP處理資料轉送，TCP負責串連控制。

值得一提的是，與SCP、FTP或者HTTP等純粹基於TCP的協議不同，這些混合型UDP/TCP協議處理資料的輸送量更加出色，它可以充分利用當前的可用頻寬的情況下，不易受到網路延遲的影響，這些特性使其成為遠距離資料轉送當中的一個很好的選擇。例如在AWS地區基礎設施之間將大型檔案由本地傳輸到雲端。在理想狀況下，利用混合UDP/TCP模式加速的檔案傳輸通訊協定比傳統的TCP協議（例如FTP）在傳輸速率上要快幾十倍乃至上百倍。

在本文中，主要介紹到了如何使用Tsunami DUP，這套檔案傳輸方案屬於UDP/TCP混合加速檔案傳輸通訊協定，旨在將大規模資料從Amazon EC2遷移到Amazon S3當中（其它強大的檔案傳輸與工作流程加速方案還包括Aspera、ExpeDat、File Catalyst、Signiant以及Attunity。其中多數產品都可從AWS Marketplace當中獲得）。

AWS公有資料集

AWS以免費方式為社區託管著大量公有資料集。在今天的文章中，我們將嘗試對維基百科流量統計V2---總容量為650GB，包含著為期十六個月內維基百科所有文章每個小時的綜合瀏覽統計資料。這套公有資料集作為EBS快照進行儲存，大家可以在AmazonEC2執行個體當中加以使用。要瞭解處理流程的具體資訊，大家可以點擊此處查看EC2說明文檔。我們將把這套容量高達650GB（已經過壓縮）的資料集從運行在AWS弗吉尼亞地區的AmazonEC2執行個體中移動到AWS東京地區的AmazonS3儲存桶當中。一旦大規模的資料移轉到AmazonS3中，大家就可以利用這些大規模資料進行大資料分析，從而應用於你的項目當中。您可以使用AWS中的AmazonElastic MapReudce服務（簡稱EMR），以及Amazon Redshift快速匯入來自AmazonS3的資料並進行大規模分析。在本樣本中，我們的主要任務是將大規模資料集從某地區的AmazonEC2執行個體內遷移到其它地區，但其原理也適用於從內部資料中心到AWS或者相反的資料集移動流程。

Tsunami UDPTsunami UDP是一套免費的開源檔案傳輸通訊協定，另外還有相關命令列介面，旨在利用TCP實現控制，由UDP完成資料轉送。其設計目的在於利用UDP作為後備機制替代基於TCP資料包確認方案的擁塞控制機制，從而大幅提高網路傳輸效率，同時在丟包或者延遲不穩定的網路中帶來更具效率的傳輸效果。用這種方式能顯著降低和改善網路延遲對於資料吞吐能力的影響，相比之下使用傳統的純TCP協議遠遠無法達到同樣的傳輸速率水平。

Tsunami UDP最初於2002年由Mark Meiss和印地安納大學實驗室裡的同事們一同打造。今天得到廣泛使用的版本是最初代碼的fork版本，發佈於2009年且目前由Sorceforge負責打理。Tsunami UDP之所以獲得眾多AWS使用者的支援，主要是出於以下幾點原因：

（1）速度很快；

（2）完全免費；

（3）使用簡便。

在AmazonEC2執行個體中設定AWS公有資料集

在我們對TsunamiUDP進行測試之前，首先需要為自己的測試下載一套資料集。我們已經提前在ap-northeast-1地區的Amazon S3儲存桶中保留了一份資料副本。

1、設定 Tsunami UDP伺服器（1）要在ap-northeast-1地區（也就是東京）啟動一套Amazon Linux執行個體，我們首先需要指定10Gbit網路以及充足的臨時性容量以儲存這套資料集。比如您可以選擇i2.8xlarge Amazon EC2執行個體，當然c3.4xlarge則可以作為更具成本效率的備選方案。要獲得更多與可用Amazon EC2執行個體類型相關的細節資訊，大家可以點擊此處查看Amazon EC2執行個體類型頁面。為了方便起見，我們已經建立了一套CloudFormation模板以啟動Amazon EC2執行個體，其初始連接埠為TCP 22與TCP/UDP 46224，用於SSH與Tsunami UDP接入。接下來在EC2執行個體上設定一套本地臨時性分卷，並從https://console.aws.amazon.com/cloudformation/home?region=ap-northeast-1- cstack=sn%7ETsunamiUDP|turl%7E  https://s3.amazonaws.com/aws-blog-examples/tsunami.template源中安裝Tsunami UDP應用程式。如果遇到實施阻礙，大家可以點擊此處查看AWS說明文檔中關於如何啟動CloudFormation堆棧的指導資訊。

（2）通過SSH登入我們剛剛建立的執行個體，如下所示：

ssh -i mykey.pem ec2-12-234-567-890.compute-1.amazonaws.com

（3）利用IAM憑證設定 AWS CLI：

aws configure

（4）將維基百科統計資料複製到臨時裝置當中：

aws s3 cp --region ap-northeast-1 --recursive s3://accel-file-tx-demo-tokyo/\ /mnt/bigephemeral

下載這些檔案需要耗費很長一段時間。如果大家不打算利用Hadoop對資料集進行後續操作，而只打算測試資料吞吐能力或者Tsunami UDP的相關功能，則可以在自己的Amazon Linux執行個體中使用下列代碼以快速建立一個臨時檔案，利用它來代替測試所需要的650G實際資料集：

fallocate -l 650G bigfile.img

Tsunami UDP 輸機制只需很短時間就能達到最大可用傳輸速率。在傳輸對象為大量小型檔案時，協調處理任務恐怕會對效能造成負面影響，因此我們最好移動少數大規模檔案而非大量小規模檔案。舉例為說，在i2.2xlarge執行個體當中，Tsunami UDP在傳輸單一650GB檔案時能夠將速率穩定在650Mbps左右。相比之下，傳輸大量個體體積在50MB左右的頁面計數檔案只能帶來約250Mbps傳輸水平。

為了為維基百科資料最大限度提供資料轉送效果，大家可以利用以下命令建立出單一大型tar檔案：

tar cvf /mnt/bigephemeral/wikistats.tar \ /mnt/bigephemeral

（5）檔案作好了各項傳輸準備之後，利用連接埠TCP/UDP46224啟動TsunamiUDP伺服器並將所有檔案提供給臨時RAID0存放裝置陣列：

tsunamid --port 46224 /mnt/bigephemeral/*

2、設定Tsunami UDP用戶端

（1）在us-east-1（即弗吉尼亞地區）啟動一個AmazonLinux執行個體。為了檢測這個執行個體是否與我們之前在ap-northeast-1設施中的執行個體屬於同種類型，大家可以再次使用前面提到的CloudFormation模板，只不過這一次將其用在us-east-1當中。

（2）通過SSH登入我們剛剛登入完成的執行個體。

3、資料轉送與效能測試

（1）運行Tsunami UDP用戶端，利用我們在AWS東京區設施中啟動的Amazon EC2執行個體Tsunami UDP伺服器的公用IP地址替代下面中括弧中的“server”部分：

tsunami connect [server] get *

（2）如果大家希望控制傳輸速率以避免網路連結使用量趨於飽和，可以使用“速率設定（set rate）”選項。舉例來說，以下命令可以將傳輸速率限定為100 Mbps：

tsunami set rate 100M connect [server] get *

（3）在Tsunami UDP伺服器上使用CloudWatchNetworkOut，在Tsunami UDP用戶端上使用NetworkIn以擷取效能表現資料。

在從東京到弗吉尼亞這種長距離檔案傳輸過程中，我們的i2.2xlarge執行個體獲得了651 Mbps，也就是81.4 MB每秒的出色速率表現。考慮到兩地的間隔，這樣的成績相信能令大家滿意。

（4）為了將結果與其它基於TCP的協議進行對比，大家可以嘗試利用scp協議（即Secure copy）再作一次傳輸以便進行比較。舉例如下：

scp -i yourkey.pem [email protected][server]:/mnt/bigephemeral/bigfile.img

我們為伺服器、用戶端以及SCP協議提供同樣的i2.2xlarge執行個體，在傳輸單一650GB大型檔案時我們只能得到約9MB每秒的傳輸效果。這樣的表現只達到Tsunami UDP的十分之一。由此可見，即使考慮到SCP所引入的加密SSH串連因素，但Tsunami UDP確實可以帶來顯著的效能提升。

將資料集移動至Amazon S3當中

當資料被傳輸至ap-northeast-1設施內的EC2執行個體中後，我們可以將其進一步遷移到Amazon S3內。完成這項任務後，大家就可以利用並行COPY命令將其匯入至AmazonRedshift，利用Amazon EMR對其加以直接分析或者歸檔以待今後使用：

（1）在AWS東京區設施內建立新的Amazon S3儲存桶。

（2）將來自us-east-1 Amazon EC2執行個體中的資料複製到剛剛建立的儲存桶當中：

aws s3 cp --recursive /mnt/bigephemeral \ s3://<your-new-bucket>/

注意: 新的通用AWS CLI會自動利用多通道傳輸機制對指向Amazon S3的傳輸活動作出資料吞吐能力最佳化。

注意: 如果大家在利用Tsunami UDP傳輸之前對自己的維基百科流量統計V2資料集進行打包，那麼在利用Amazon EMR對其加以進一步分析之前需要首先完成解壓。

利用Amazon EMR進行資料集分析

當資料集被儲存在AmazonS3之後，大家還可以利用Amazon EMR對其進行大資料分析。在本文中使用的樣本專門針對維基百科資料集，大家可以點擊此處利用Amazon EMR上的ApacheSpark對其統計內容進行查詢。

總結：

Tsunami UDP提供一種免費、簡便、高效的檔案傳輸方式，允許大家將大規模資料在AWS與本地環境或者不同地區之間隨意傳輸，還可以與AWS CLI的多通道上傳機制相結合，Tsunami UDP又能成為一種便捷而無需投入成本的大規模資料集移動方式。利用Amazon S3和Amazon Glacier不僅能夠提供持久且成本極低的Object Storage Service服務，同時允許我們利用AmazonEMR以及Amazon Redshift等AWS服務對其進行大資料分析，不但能協助您解決時間成本，同時能給您帶來更好的效率。

當然，還需要指出的是，Tsunami UDP也存在自己的局限。它不支援原生加密機制，只能通過單線程實施傳輸而且由於缺少SDK或者外掛程式的輔助而很難實現自動化執行。利用單線程運行多個用戶端及伺服器有可能在傳輸時中斷，導致重試，這通常會降低整體資料的吞吐能力。Tsunami UDP也不支援原生Amazon S3整合，因此Amazon EC2執行個體上的傳輸機制必須首先中止，然後再利用AWS CLI等工具被重新發送至Amazon S3處。

最後，由於Tsunami UDP程式碼程式庫的最近一次更新已經是2010年的事了，因此目前其不具備任何商用支援機制也沒有與該產品相關的任何活躍開源論壇。相比之下，ExpeDat S3 Gateway與Signiant SkyDrop這兩款檔案加速傳輸方案很好地解決了這些弊端，而且這兩款產品都支援加密機制，提供原生S3整合而且包含更多額外功能，這也使得這兩種方案具備相當強大的商用客戶吸引力。