在AWS环境下基于EMR、Alluxio和S3构建高效数据分析流水线

一、目 的

如今，由于以AWS为代表的公有云的可扩展性，弹性和成本效益，许多公司正在将它们的数据分析流水线从本地数据仓库迁移到AWS等公共云上。但是，这个过程绝不仅仅是简单地将数据从HDFS移至S3，然后将Apache Hadoop的程序运行到EMR等技术堆栈上。对于数据工程师来说，要在云环境的技术堆栈上高效地运行原有的数据密集型工作负载存在许多隐患和挑战。

本文介绍了我们从先前一个项目迁移到云环境中获得的经验教训，该数据分析流水线项目原先使用的是我们团队自己管理的Hadoop本地集群，后来迁移到了AWS环境中使用了EMR和S3。我们原先的目标是利用EMR的弹性来减轻运营工作的负载，并使S3成为一个数据湖，从而使不同的团队可以在其上轻松地跨项目共享数据。

二、技术挑战分析

因为我们的数据分析流水线日常需要处理的数据量达数百TB，所以在迁移到S3上的新EMR堆栈过程中，我们发现了一些与I/O相关的技术挑战：

潜在的I/O性能瓶颈：在从S3读取或写入数据时，我们遇到了性能瓶颈。与原先在Hadoop集群上构建的数据分析流水线不同（原来的架构中计算节点和存储节点深度耦合，具有很高的数据局部性），迁移后新的技术堆栈使用S3作为数据湖，然而数据远程读取和写入我们的S3数据湖可能开销非常昂贵。更可怕的是我们的工作负载还需要在每个分析流水线作业中多次执行I/O操作，这会使情况变得更糟。

峰值负载处理：我们经常观察到系统存在一些峰值I/O流量，尤其是在最后阶段分析作业正在写入输出结果时。当IO请求率急剧增加时，S3将限制请求数量。但是，当前的基于Hadoop的分析应用程序设计开发通常不会考虑应对I/O节流的情况，并且应用程序也没有调节输出速率的机制。这导致了为了解决这种问题，流水线必须承受非常昂贵的计算成本进行不断重试。

高成本的S3重命名操作：重命名操作在S3上开销非常昂贵，因为它是通过复制一个新对象后删除旧对象来完成的。然而，Spark或Hive的作业在运行过程中通常会写入临时的阶段性目录，并在作业完成后将结果移至最终目标地址处。这对S3造成了很多不必要的压力。不少用户会采用一种常见的技术方案是先写入EMRFS（EMRFS提供更高效的重命名实现），然后将数据再次复制到S3，这显然需要额外的步骤以及更长的完成时间。

三、解决方案

系统架构：我们将开源数据编排系统Alluxio引入了我们的技术栈。与S3相比，Alluxio以内存作为主要存储，提供了更快的数据访问速度。在我们的测试中，我们能够在1分钟内将约100GB的数据写入Alluxio，并在后台7分钟内从Alluxio持久化到S3。相反，如果我们直接写入S3，通常会受到流量限制或花费更长的时间。

在读取路径上，我们使用Alluxio来充当共享读取缓冲区，使得我们可减少每个流水线作业上所需的读取次数。在写入路径上，我们以两种方式利用Alluxio。对于使用后可以删除的中间结果或丢失后可以廉价重新计算的瞬态结果，与S3相比，Alluxio更适合提高这些输出数据的写入性能。对于需要持久化保存到S3供将来使用或重新计算成本较大的最终结果，Alluxio有助于加速，可能更重要的是简化了在应用程序层写入到持久存储的流程。

优势：通过使用Alluxio作为数据缓冲层来平滑IO流并避免S3限流或减速，可以极大地简化整个系统架构。应用流水线可以便捷地将数据写入Alluxio，而无需在应用程序逻辑中显式地处理峰值负载。

具体来说，Alluxio为用户提供了一种控制到S3输出节奏并避免被限流的机制。通过Alluxio1.8，我们用Hadoopdistcp命令将数据复制到S3，并利用Alluxio调整了将数据复制到S3的节奏。通过Alluxio 2.0，用户将数据持续存储到诸如S3之类的底层文件系统中可以是异步的，因此从应用程序的角度来看，文件一旦写入Alluxio后就可以使用。Alluxio是基于内存的，并且避免了副本复制的阻塞，这提供了比EMRFS更好的性能。

将Alluxio引入数据分析流水线还具有显著的性能优势，并有助于解决来自底层文件系统行为方式导致的多重挑战。简而言之，Alluxio作为基于内存的共享缓存具有巨大的性能优势。它还提供了良好的抽象性，因此应用程序在利用底层存储系统工作时无需直接处理与它们的交互。