当你的数据规模达到 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 存储桶中保留了一份数据副本。
- 设置 Tsunami UDP 服务器
- 要在 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 堆栈的指导信息。
- 通过 SSH 登录我们刚刚创建的实例，如下所示： ssh -i mykey.pem ec2-12-234-567-890.compute-1.amazonaws.com
- 利用 IAM 凭证设置 AWS CLI： aws configure
- 将维基百科统计数据复制到临时设备当中： 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
- 文件作好了各项传输准备之后，利用端口 TCP/UDP 46224 启动 Tsunami UDP 服务器并将所有文件提供给临时 RAID0 存储阵列： tsunamid --port 46224 /mnt/bigephemeral/*
- 设置 Tsunami UDP 客户端
- 在 us-east-1（即弗吉尼亚地区）启动一个 Amazon Linux 实例。为了检测这个实例是否与我们之前在 ap-northeast-1 设施中的实例属于同种类型，大家可以再次使用前面提到的 CloudFormation 模板，只不过这一次将其用在 us-east-1 当中。
- 通过 SSH 登录我们刚刚登录完成的实例。
- 数据传输与性能测试
- 运行 Tsunami UDP 客户端，利用我们在 AWS 东京区设施中启动的 Amazon EC2 实例 Tsunami UDP 服务器的公共 IP 地址替代下面中括号中的“server”部分： tsunami connect [server] get *
- 如果大家希望控制传输速率以避免网络链接使用量趋于饱和，可以使用“速率设定（set rate）”选项。举例来说，以下命令可以将传输速率限定为 100 Mbps： tsunami set rate 100M connect [server] get *
- 在 Tsunami UDP 服务器上使用 CloudWatch NetworkOut，在 Tsunami UDP 客户端上使用 NetworkIn 以获取性能表现数据。在从东京到弗吉尼亚这种长距离文件传输过程中，我们的 i2.2xlarge 实例获得了 651 Mbps，也就是 81.4 MB 每秒的出色速率表现。考虑到两地的间隔，这样的成绩相信能令大家满意。
- 为了将结果与其它基于 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 确实可以带来显著的性能提升。
- 将数据集移动至 Amazon S3 当中 当数据被传输至 ap-northeast-1 设施内的 EC2 实例中后，我们可以将其进一步迁移到 Amazon S3 内。完成这项任务后，大家就可以利用并行 COPY 命令将其导入至 Amazon Redshift，利用 Amazon EMR 对其加以直接分析或者归档以待今后使用：
- 在 AWS 东京区设施内创建新的 Amazon S3 存储桶。
- 将来自 us-east-1 Amazon EC2 实例中的数据复制到刚刚创建的存储桶当中： aws s3 cp --recursive /mnt/bigephemeral \ s3://
/ 注意: 新的通用 AWS CLI 会自动利用多通道传输机制对指向 Amazon S3 的传输活动作出数据吞吐能力优化。 注意: 如果大家在利用 Tsunami UDP 传输之前对自己的维基百科流量统计 V2 数据集进行打包，那么在利用 Amazon EMR 对其加以进一步分析之前需要首先完成解压。 - 利用 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 博客。
评论