运用Tsunami UDP将大数据迁移至云中

当你的数据规模达到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快照进行保存，大家可以在Amazon EC2实例当中加以使用。要了解处理流程的具体信息，大家可以点击此处查看EC2说明文档。我们将把这套容量高达650GB（已经过压缩）的数据集从运行在AWS弗吉尼亚地区的Amazon EC2实例中移动到AWS东京地区的Amazon S3存储桶当中。一旦大规模的数据迁移到Amazon S3中，大家就可以利用这些大规模数据进行大数据分析，从而应用于你的项目当中。您可以使用AWS中的Amazon Elastic MapReudce服务（简称EMR），以及Amazon Redshift快速导入来自Amazon S3的数据并进行大规模分析。在本示例中，我们的主要任务是将大规模数据集从某区域的Amazon EC2实例内迁移到其它区域，但其原理也适用于从内部数据中心到AWS或者相反的数据集移动流程。

Tsunami UDP

Tsunami UDP是一套免费的开源文件传输协议，另外还有相关命令行界面，旨在利用TCP实现控制，由UDP完成数据传输。其设计目的在于利用UDP作为后备机制替代基于TCP数据包确认方案的拥塞控制机制，从而大幅提高网络传输效率，同时在丢包或者延迟不稳定的网络中带来更具效率的传输效果。用这种方式能显著降低和改善网络延迟对于数据吞吐能力的影响，相比之下使用传统的纯TCP协议远远无法达到同样的传输速率水平。 Tsunami UDP最初于2002年由Mark Meiss和印第安纳大学实验室里的同事们一同打造。今天得到广泛使用的版本是最初代码的fork版本，发布于2009年且目前由Sorceforge负责打理。Tsunami UDP之所以获得众多AWS用户的支持，主要是出于以下几点原因：

• 速度很快
• 完全免费
• 使用简便

在Amazon EC2实例中设置AWS公有数据集

在我们对Tsunami UDP进行测试之前，首先需要为自己的测试下载一套数据集。我们已经提前在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%7Ehttps://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/UDP 46224启动Tsunami UDP服务器并将所有文件提供给临时RAID0存储阵列： tsunamid --port 46224 /mnt/bigephemeral/*
2. 设置Tsunami UDP客户端
   1. 在us-east-1（即弗吉尼亚地区）启动一个Amazon Linux实例。为了检测这个实例是否与我们之前在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服务器上使用CloudWatch NetworkOut，在Tsunami UDP客户端上使用NetworkIn以获取性能表现数据。在从东京到弗吉尼亚这种长距离文件传输过程中，我们的i2.2xlarge实例获得了651 Mbps，也就是81.4 MB每秒的出色速率表现。考虑到两地的间隔，这样的成绩相信能令大家满意。
   4. 为了将结果与其它基于TCP的协议进行对比，大家可以尝试利用scp协议（即Secure copy）再作一次传输以便进行比较。举例如下： scp -i yourkey.pem ec2-user@[server]:/mnt/bigephemeral/bigfile.img 我们为服务器、客户端以及SCP协议提供同样的i2.2xlarge实例，在传输单一650GB大型文件时我们只能得到约9MB每秒的传输效果。这样的表现只达到Tsunami UDP的十分之一。由此可见，即使考虑到SCP所引入的加密SSH连接因素，但Tsunami UDP确实可以带来显著的性能提升。
4. 将数据集移动至Amazon S3当中 当数据被传输至ap-northeast-1设施内的EC2实例中后，我们可以将其进一步迁移到Amazon S3内。完成这项任务后，大家就可以利用并行COPY命令将其导入至Amazon Redshift，利用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对其加以进一步分析之前需要首先完成解压。
5. 利用Amazon EMR进行数据集分析 当数据集被保存在Amazon S3之后，大家还可以利用Amazon EMR对其进行大数据分析。在本文中使用的示例专门针对维基百科数据集，大家可以点击此处利用Amazon EMR上的Apache Spark对其统计内容进行查询。

总结

Tsunami UDP提供一种免费、简便、高效的文件传输方式，允许大家将大规模数据在AWS与本地环境或者不同区域之间随意传输，还可以与AWS CLI的多通道上传机制相结合， Tsunami UDP又能成为一种便捷而无需投入成本的大规模数据集移动方式。利用Amazon S3和Amazon Glacier不仅能够提供持久且成本极低的对象存储服务，同时允许我们利用Amazon EMR以及Amazon Redshift等AWS服务对其进行大数据分析，不但能帮助您解决时间成本，同时能给您带来更好的效率。 当然，还需要指出的是，Tsunami UDP也存在自己的局限。它不支持原生加密机制，只能通过单线程实施传输而且由于缺少SDK或者插件的辅助而很难实现自动化执行。利用单线程运行多个客户端及服务器有可能在传输时中断，导致重试，这通常会降低整体数据的吞吐能力。Tsunami UDP也不支持原生Amazon S3集成，因此Amazon EC2实例上的传输机制必须首先中止，然后再利用AWS CLI等工具被重新发送至Amazon S3处。 最后，由于Tsunami UDP代码库的最近一次更新已经是2009年的事了，因此目前其不具备任何商用支持机制也没有与该产品相关的任何活跃开源论坛。相比之下，ExpeDat S3 Gateway与Signiant SkyDrop这两款文件加速传输方案很好地解决了这些弊端，而且这两款产品都支持加密机制，提供原生S3集成而且包含更多额外功能，这也使得这两种方案具备相当强大的商用客户吸引力。

本文原载于WAS博客。