通过优化 S3 读取来提高效率和减少运行时间( 二 ) 作者|BhalchandraPandit译者|平川策

改进生产作业
读取吞吐量的增加给生产作业带来了多方面的提升。
降低了作业运行时间
作业的总体运行时间减少了，因为mapper等待数据的时间减少了，可以更快地完成。
减少mapper数量
如果mapper耗时大大减少，那么我们就可以通过增加分割大小来减少mapper数量。 Mapper数量的减少可以减少由固定mapper开销所导致的CPU浪费。更重要的是，这样做并不会增加作业的运行时间。
提高CPU利用率
由于mapper完成同样的工作所花费的时间减少，所以CPU整体的利用率会提高。
结果
现在，我们的实现（S3E）使用了一个单独的存储库，提高了我们的迭代改进速度。最终，我们会将其合并到S3A ，把它回馈给社区。
单独的基准测试

文章图片
图2：S3A和S3E的吞吐量对比*
在每种情况下，我们都是顺序读取一个3.5GB的S3文件，并将其写入本地的一个临时文件。后半部分是为了模拟mapper操作期间发生的IO重叠。基准测试是在EC2c5.9xlarge实例上进行的。我们测量了读取文件的总时间，并计算每种方法的有效吞吐量。
生产运行
我们在许多大型生产作业中测试了S3E实现。这些作业每次运行时通常都要使用数以万计的vcore 。图3是对比了启用S3E和不启用S3E时获得的指标。
度量资源节省情况
我们使用以下方法度量这项优化所带来的资源节省情况。

文章图片
观测到的结果

文章图片
图3：MapReduce作业资源消耗对比*
虽然不同的生产作业工作负载有不同的特征，但我们看到，在30个成本高昂的作业中，大部分的vcore都减少了6%到45% 。
我们的方法有一个吸引人的地方，就是在一个作业中启用时不需要对作业的代码做任何修改。
未来展望
目前，我们把这个增强实现放在了一个单独的Git存储库中。将来，我们可能会升级已有的S3A实现，并把它回馈给社区。
我们正在把这项优化推广到我们的多个集群中，结果将发表在以后的博文上。
鉴于S3E输入流的核心实现不依赖于任何Hadoop代码，我们可以在其他任何需要大量访问S3数据的系统中使用它。目前，我们把这项优化用在MapReduce、Cascading和Scalding作业中。不过，经过初步评估，将其应用于Spark和SparkSQL的结果也非常令人鼓舞。
当前的实现可以通过进一步优化来提高效率。同样值得探索的是，是否可以使用过去的执行数据来优化每个作业的块大小和预取缓存大小。