“榨干”EMR开销！AWS EMR在搭建大数据平台ETL的应用实践( 五 ) ：“榨干”EMR开销！AWSEMR在搭

针对以上case ， Transformer团队正在开发一套运行与EMR和Yarn之上的基于应用和策略角度运维的Framework-Cybertron 。我们期望能通过这个服务可以站在更全局的角度去合理的管理多个EMR集群资源，能够让应用端不去关注EMR集群的资源情况，综合Yarn的scheduler和Queue等的配置，对集群资源和任务调度能有一个更高视角的控制。
Spot和Ondemand机型的混用
实际应用中，即使我们选择了InstanceFleet ，也会由于极端的情况导致无法配齐资源，此时我们不得不Ondemand机型来补足缺口，如上面的流程图所示，当等待集群scale一定时间之后，如果依然无法配齐需求目标，我们就会申请ondemand机型用来补足，在InstanceFleet的场景下， ondemand类型的机型是和Spot机型范围是一样的。值得注意的一点是，虽然EMR中可以配置Provisioningtimeout的action是Afterxxminutes,SwitchtoOn-Demandinstances ，但实际情况是不会起作用，仍然需要我们根据实际InstanceFleet的情况去主动申请Ondemand机型。
对于更极端的情景，如黑五到来或者美国大选期间，我们会主动直接将所以申请机型直接替换成ondemand ，以防止频繁的无法配齐Spot带来的额外时间开销。
另外，在Sparkjob运行期间，如果遇到了因为Spot机型回收导致的任务中断的情况，我们会在Airflow的调度下，根据当前集群状态加大ondemand机型进行配比，以期能够快速恢复。
效果
下图是使用了主动scale方案的集群，在一天内24个小时集群根据数据量的情况进行伸缩的情况，红色柱子是集群的Memorycapcity ，蓝色+绿色的累加部分为实际使用的内存量。从实际使用来看，我们可以做到在任务提交前主动scaleout到期望的capacity ，每个batch的任务可以充分利用集群资源，在SLA时间内完成数据处理，并在不需要集群之后马上scalein进来。在降低开销的同时满足任务需求。

文章图片
下图是使用了EMRautoScale方案的集群。我们可以看到随着更多的Spark任务提交，集群负载变高，集群根据负载情况scaleout了两次，最终在任务全部做完，并空闲一段时间后将Workernode缩回了0 。

文章图片
HDFS的依赖
在我们的使用场景中， EMR仅作为计算资源，其上的HDFS仅需要支撑Spark应用即可。在一次批处理的过程中，生成的数据会先存储在HDFS上，然后由publisher将数据搬移并持久化到S3上。关于为什么不直接写入S3 ，一方面是考虑到数据的特点需要在发布的时候进行一次重新组织，而S3的最终一致性模型会带来第二次copy的时候发生数据丢失（针对这个case ，我们仍然可以由producer端在写出数据的同时产生一份filelist ，作为上下游数据的接口来解决；另外也可以通过开启一致性视图，不过这个带来额外的组件依赖和开销；根据最新的AWS文档， S3已经解决的read-after-write的问题read-after-write-consistency ，但是对于先读后写再读的case ，仍然会在list的情况下存在一致性问题）。另外， Spark直接写S3文件也存在着一定的性能问题，而且由Spark应用直接针对不同的数据发布特点组织数据形式，也会造成逻辑耦合太紧，不利于维护，还会加大Spark应用的运行时间，变相增加了成本同时，对于使用Spot竞价机器的场景，更长的运行时间也就意味着更大的被中断机会。
3总结
随着我们对EMR使用的越来越深入，在满足产品需求的同时，我们也在不断“榨干”EMR开销，本文期望能通过我们的EMR使用经验给读者启发。也感谢在这个过程中AWSEMR团队的支持。
另外， AWSEMR团队也在根据客户的实际需求不断完善和推出新的功能，目前我们正在调研试用AWS最新推出的EMRonEKS ，期望能够有更灵活的使用方式、更快的scale速度和更小的开销。我们会在后续的文章中继续更新进展。
作者介绍
彭康， LeadSoftwareEngineerFreeWheel ，毕业于中科院计算所，目前就职于ComcastFreeWheel数据产品团队，主要负责广告数据平台数据仓库的建设。
点击文末【阅读原文】移步InfoQ官网，内容更多更精彩！
赔偿9200万美元！TikTok与美国用户和解隐私诉讼
程序员的“黄金时代” ，死去又重来？
放弃大厂高薪的程序员，涌进体制内
InfoQ写作平台欢迎所有热爱技术、热爱创作、热爱分享的内容创作者入驻！
还有更多超值活动等你来！