关于分析:轻松搭建数据仓库与FreeWheel一起玩转Amazon-EMR

Amazon Elastic MapReduce(Amazon EMR)是 Amazon Web Services 提供的托管集群平台，用户能够十分不便的 应用 Amazon EMR 搭建起一套集群，用来撑持大数据框架的利用 ，如 Apache Spark，Hive，Flink，Presto 等等。因为 Amazon EMR 具备很好的 可配置性和伸缩性 ，使用者能够灵便的 依据本人的需要进行定制 ，在满足生产需要的同时， 减低对基础设施的运维老本。

FreeWheel 大数据团队在搭建数据仓库的过程中，在 Amazon EMR 的应用上积攒了大量的实际和运维教训，本文将从 Amazon EMR 实际的角度登程，讲述 FreeWheel Transformer 团队在搭建 ETL pipeline 的过程中是如何玩转 Amazon EMR 的，以期抛砖引玉。

后盾回复 ”FreeWheel”, 更多精彩内容等着你

📢  想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注 2021 亚马逊云科技中国峰会！点击图片报名吧～

一个典型的 Spark on Amazon EMR 上集群架构概览

咱们先来理解一下一个典型的 Amazon EMR 集群是什么样子的。Amazon EMR 默认应用了 Yarn 来治理集群资源。Amazon EMR 将 node 分为了 Master，Core 和 Task 三个组（通过 Yarn label 实现）。

主节点（Master node）

Amazon EMR 的 Master node 用来治理整个集群，集群至多要有一个 Master node（从 Amazon EMR-5.23 开始，如果须要 Master node HA，能够抉择实例计数为 3，此时依据不同的利用，会有不同的 HA 计划）。

以运行 Hadoop HDFS 和 Yarn 为例，Master 上会运行 Yarn ResourceManger 和 HDFS NameNode。在高可用计划下，Yarn ResourceManager 会在所有三个主节点上运行，并采纳 Active/Standby 模式进行工作。如果 ResourceManager 的主节点产生故障，Amazon EMR 将启动主动故障转移过程，具备 Standby ResourceManager 的 Master node 将接管所有操作，能够通过 yarn rmadmin-getAllServiceState 来获取以后服务状态。对于 Yarn ResourceManger HA的具体细节，能够参考 ResourceManager HA。

与 ResourceManager 相似，NodeManager 会在三个主节点中的两个节点上运行，别离处于 Active 和 Standby 状态。如果 Active NameNode 的主节点产生故障，Amazon EMR 会将启动 HDFS 故障转移过程。此时 Standby 状态的 NameNode 将变为 Active 并接管集群中的所有对 HDFS 的操作。咱们能够通过 hdfs haadmin-getAllServiceState 命令来获取以后 NameNode 状态。对于 HDFS HA 的具体细节，能够参考HDFS HA。

• ResourceManager HA
  https://hadoop.apache.org/doc…
• HDFS HA
  https://hadoop.apache.org/doc…

外围节点（Core node）

Core node 为可选组，其上运行了 HDFS DataNode。当 Core node 个数少于 4 时，Amazon EMR 默认会将 HDFS 的 replica 设置为 1，Core node 少于 10 个时 replica 为 2，其余状况为 3。如果须要进行自定义设置，能够批改启动 Amazon EMR 对 hdfs-site.xml 中 dfs.replication 的配置；这里要留神一点，如果咱们在一个曾经启动的 Amazon EMR 中，在对 Core node 进行伸缩的时候，会影响到 HDFS 数据的 re-balance，这是一个耗时的操作，不倡议频繁做 Core node 的 scaling。而且对于 replica 是 3 的集群，如果将 core node 的个数缩减为少于 3 个的话，也将无奈胜利。

工作节点（Task node）

Task node 为一般的工作节点。非常适合作为单纯的工作节点应答工作负载须要频繁伸缩的场景，其上运行了 NodeManager，在其启动之后，会退出到 Yarn 的集群治理之中。对于须要频繁 scale 的场景，仅仅 scale Task node 是一个比拟理论的计划，效率比拟高。

工作队列（InstanceFleet）

Core node 和 Task node 都能够配置实例队列，实例队列是一个十分实用的性能，尤其是在 Spot 实例的场景，在一些热门事件产生时，一些热门机型的中断率会变得很高，如果抉择繁多类型实例的话，很容易呈现无奈满足需要，咱们能够在 spot advisor 上查看以后的实例中断状况。前面章节我会详细描述咱们是如何应用实例队列的。

• spot advisor
  https://aws.amazon.com/cn/ec2…

Amazon EMR 版本

在创立 Amazon EMR 时，须要额定留神 Amazon EMR 的 release 版本，不同版本反对的利用版本也不同。从 Amazon EMR-6.1.0 版本起，曾经开始反对 Spark3.0.0 + Hadoop 3.2.1 的组合了，目前最新的 Amazon EMR-6.2.0 版本，曾经能够反对稳固版本的 Spark3.0.1 了。如果须要运行 Spark2.x 版本，能够抉择 Amazon EMR-5.x 版本或者 Amazon EMR-6.0.0。

除利用版本区别，从 Amazon EMR-6.0.0 起，零碎基于 Amazon Linux 2 和 Corretto JDK 8 构建，绝对于以往的 Amazon Linux 1 最大的区别是提供了新的零碎工具，如 Systemctl，以及优化的 Amazon linux LTS 内核。另外 Amazon Corretto JDK 8 提供通过 Java SE 认证的兼容 JDK，包含长期反对、性能加强和平安修复程序。对于 Amazon emr-6.x 的 release note，能够参考Amazon EMR release note。

另外，Amazon Web Services 最新曾经反对 Amazon EMR on Amazon EKS，咱们能够更灵便的将 Amazon EMR 创立在 Amazon EKS 中，以期更灵便应用和更低的费用，目前这一块咱们团队正在调研和 adoption，我会在和后续的文章中专门来聊这一块。

• Amazon EMR release note
  https://docs.aws.amazon.com/e…

Amazon EMR 在 FreeWheel 批处理 ETL pipeline 中的实际

在 Freewheel 批处理 ETL pipeline 中有两个重要的组件别离叫 Optimus 和 JetFire，就是大家耳熟能详的擎天柱和天火，是由我司 FreeWheel 建设的一套基于 Spark 的数据建模和解决框架（所以我司 FreeWheel Transformer team 的产品都以 Transformer 中的角色来命名）。Optimus 次要针对的是数据仓库层的建设，次要性能是将广告零碎产生的 log 经前端模块收集起来后，依据商业逻辑的需要进行抽取转换，对立建模，并做了大量业务的 enrichment，将原始数据转换成不便上游利用端进行剖析应用的 Context Data，最终由 Spark SQL 生成宽表落盘。JetFire 更偏差于一个灵便通用的基于 Spark 的 ETL Framework，能让用户更简略不便的将基于宽表之上的数据加工需要进行疾速实现。这些 pipelines 都是由 Airflow 进行工作的编排和调度。

工作特点

基于 Optimus 的批处理 ETL pipeline

• ETL pipeline 每小时一个 batch，因为客户散布在寰球各个时区，所以数据的公布需要是依照客户所在时区的零点之后公布以后时区客户前 24 小时的数据；另外有些产品也须要反对每个小时的数据都不能提早，每个小时的数据处理须要管制在 30min 以内；
• 数据量不稳固；客户在不同时区散布的密度，各个小时的流量也不同，以及区域性事件的产生，以及外部上游模块可能会产生 delay 等都会造成每小时数据量不平均。尽管每天 24 个小时的数据量散布尽管大抵趋势雷同，然而不能精确预测，只有将要开始解决这个 batch 的时候，能力从上游拿到这个 batch 的数据量信息；

• 数据在 ETL 的两头过程中在 HDFS 上没有长久化需要；对于 HDFS 的需要是撑持 Spark 工作以及 Amazon EMR 集群的拜访，保障一次批工作外部的事务性即可。须要长久化的数据会由后续的模块 load 到 clickhouse，以及同步公布到 Amazon S3 上交由 hive 来治理；
• Spark 工作对于集群资源的需要：Optimus 中因为存在大量的计算（如数据序列化反序列化，metric 的计算，数据的排序聚合，Hyperloglog 计算等）和缓存（分层建模中，在 DAG 中被重复用到的数据），Spark 工作在不同阶段对集群资源的需要点是不同的：从数据 load 进内存到对数据进行 transform 进行建模的过程，是计算密集型的，须要耗费大量的 CPU，同时因为有些 dataframe 须要被更下层的模型复用，须要 cache 起来，这里须要大量的 memory；而最终在撑持大量并发 SparkSQL 的数据抽取和聚合的运算中，网络和 CPU 都是很大性能瓶颈。咱们针对 Spark 利用做了十分精密的调优工作，具体能够参考这些文章Spark 实际一，Spark 实际二。在解决一个 batch 的过程中，集群资源应用状况能够对应比拟上面三个图。

• Spark 实际一
  https://mp.weixin.qq.com/s/Mc…
• Spark 实际二
  https://mp.weixin.qq.com/s/E1…

基于 JetFire 的 DataFeed pipeline

• Datafeed 中的工作具备不同的 schedule，不同的 input 数据量，提交到 Amazon EMR 集群的工作负载无奈提前预知。这种场景下，Amazon EMR 更像是一个共享的计算平台，咱们很难从独自一个利用的角度对整体资源进行布局。
• 思考到基于 Optimus 的 ETL pipeline 是泛滥上游利用的独特依赖，须要保障很高的稳定性，咱们冀望可能在独占一个 Amazon EMR 集群的前提下尽量升高开销。而 Datafeed pipeline 工作系统且多，绝大部分工作轻量须要较快实现。

咱们来各个击破上述需要

Amazon EMR 集群配置

基于前文对 Amazon EMR 集群的介绍以及理论利用需要，总的来说，咱们应用了在 Long term 的 Amazon EMR 集群，运行单点 Ondemand 机型的 Master node + 单点 Ondemand 机型的 Core node + 动静伸缩的由 Spot&Ondemand 机型的 InstanceFleet 组成的 Task node。

Long term Amazon EMR VS 长期 Amazon EMR 集群

咱们不抉择在每次须要 Amazon EMR 集群的时候去从新创立一个集群的起因是，除了机器实例 provision 的工夫外，Amazon EMR 还须要额定执行较长时间的 bootstraping 脚本去启动很多服务能力让整个集群 ready。而 Master node 和 Core node 咱们在上文介绍过，相较于 Task node，他们不仅须要撑持 Hadoop 服务，还须要下载并配置 Spark，Ganglia 等环境，以及更多服务（依据用户勾选的 application 决定），这样频繁创立和销毁带来的工夫开销绝对于 hourly schedule 的工作而言，是不能疏忽的。所以咱们抉择创立保护一个 long term Amazon EMR 集群，通过 scale worker node 来管制负载的计划。而对于应用距离较长，如 daily 甚至 weekly job 来讲，在每次须要应用 Amazon EMR 的时候进行长期创立是一个更正当的计划。

抉择 Long term 之后咱们就须要关注集群的稳定性，然而咱们依然抉择了没有 HA 的计划，因为 Master 和 Core 均为 Ondemand 机型，这样就能够保障集群在非极其非凡状况下不会呈现 crash 的状况。而对于极其非凡状况，思考到两个 pipeline 对数据长久化并无需要，如果能在分钟级别的工夫内重建 Amazon EMR 集群并复原工作，绝对于长期存在的 HA 计划的 master + core 计划来说，在都能满足生产需要的状况下 ROI 更高。所以综合思考，咱们抉择了单点 master 和单点 core node 的计划，配合上 Terraform 脚本和 Airflow 的调度，咱们能够在产生小概率集群事变失去状况下疾速重建 Amazon EMR 集群并重跑工作，从而复原 pipeline。

额定值得一提的是，在 Amazon EMR 应用初期，Terraform 上并不反对创立具备 InstanceFleet 的 Amazon EMR，过后仅可能应用命令行或者应用 boto3 的库创立一个 Amazon EMR 集群，因为没有 state 文件进行 track，所以也无奈通过 Terraform 进行对立治理（如销毁和批改等），针对 Amazon EMR 这部分只能本人实现一套 stateful 的治理脚本。目前最新版本的 Terraform 曾经退出了对带有 InstanceFleet 的 Amazon EMR 的反对。然而理论应用当中，对于应用 InstanceFleet 的 Amazon EMR 集群，很多配置只能在创立时指定，如 Master&Core&Task 的机型配置，InstanceFleet 的机型抉择，Hadoop 和 Spark 的一些 customize 的配置（这个仍然能够通过启动之后批改对应的 xml 或者 conf 文件，而后重启对应服务进行批改，然而这种做法对于产品环境并不敌对），Security group 等，如果须要批改这些，依然须要销毁集群，用新的配置从新创立。须要留神的是，对于应用 InstanceGroup 的集群是能够通过 reconfiguration 的形式 批改。

• reconfiguration 的形式
  https://docs.aws.amazon.com/e…

对于 Spot 机型和 AZ 的抉择

思考到老本，咱们会优先应用 Spot 机型作为 Task node，应用 Ondemand 机型做补充。Spot 机型在资源紧俏的状况下有可能申请不到，即便申请到也有可能会呈现中断被发出的状况，咱们会在创立 Amazon EMR 时将 AZ 设置为多个，以减少胜利申请到机器的概率。不过多 AZ 的配置仅在创立 Amazon EMR 时失效，Amazon EMR 会抉择创立时资源较为拮据的 AZ 申请 instances，而在 Amazon EMR 创立好之后，就只能在一个固定的 AZ 中应用了，后续即便这个 AZ 机器资源紧俏而其余可选的 AZ 资源富余，因为集群 Master 和 Core 曾经在以后 AZ 存在，不能再到其余 AZ 申请机器。思考到 Spark 集群通信开销，跨 AZ 带来对性能的影响不能疏忽，这种设计也是很正当的。因而，多 AZ 的设置对于每次须要从新创立 Amazon EMR 的场景是一个十分有用的性能，而对于 long term 集群的来说就无限了。在创立 long term 的集群之后，为了升高 Spot 机型带来的影响，就须要应用 InstanceFleet 配合 Spot 和 ondemand 混合应用来升高机器了，这一部分我会在 Task node 伸缩策略外面详细描述。

Master 和 Core node 机型抉择

在 Master 和 Core node 的机型抉择上，因为 Core node 须要运行 HDFS Datanode，咱们冀望在运行 Spark 工作时在存储这里有更高的吞吐和 IOPS，所以咱们抉择了存储优化型的 i 系列。另外因为 Spark 的 driver executor 默认会运行在 core node 上，对于一些须要 Spark 中须要应用到并发的代码块，driver 的 CPU core 的数量决定了并发的下限，所以这里须要按利用需要抉择适合的 CPU 机型。这里须要提及的一点，从 Amazon EMR 6.x 版本开始，默认状况下禁用的 Yarn label 的性能，然而思考到 core node 为 ondemand 机型，而 worker node 为 spot 机型并且会频繁伸缩，运行在 ondemand 的 core node 上会更加稳固，所以咱们依然抉择开启 Yarn label，并让 Driver executor 运行在 Core node 之上。

能够通过：
yarn.node-labels.enabled: true
yarn.node-labels.am.default-node-label-expression:‘CORE’
来开启这项配置。

对于 Master node，除了 NameNode 的内存开销外，就是 Spark historyServer 和 ResourceManager 的内存开销，绝对 worker node 来讲，资源并不是很缓和，所以适当抉择就好。

Task node 伸缩策略

为了满足对不同 hourly 数据量的解决可能在限定工夫内实现，须要依据以后小时 input 的数据量进行集群 capacity 的调整，在对 Task node 的伸缩过程中，咱们思考了以下方面。

InstanceFleet 的应用

出于减低老本的思考，咱们会优先选择 Spot 机型来代替 onDemand 机型，然而在遇到机型紧俏，有大型流动的时候，热门机型就会供不应求，甚至会呈现频繁的被发出的状况，对于集群中有节点被回收的状况，Spark 工作尽管能够 handle，并在 resource 可行的状况下将那一部分数据 shuffle 到其余可用的 worker 上进行调度解决，然而数据的搬移以及 DAG 后续 task 的数据歪斜带来的性能的降落，甚至是资源有余导致的工作最终失败，可能会导致 spark 工作运行更长的工夫，从而可能引发更大的 spot 发出的机会。因而，咱们采纳了 InstanceFleet 来升高对繁多机型的依赖，InstanceFleet 能够针对 Amazon EMR 的 Master，Core 和 Task node 别离设置混合机型和 lifeCycle 类型，以期可能在实例资源缓和的状况下满足指标容量。

一个 InstanceFleet 目前能够最大反对配置 15 种机型，目前罕用的几类能够用来运行 Spark 的机型有 C 型，R 型和 M 型，C 型更偏向于计算密集型的工作。除了 C 型的 CPU 主频更高以外，几类机型的次要区别在于 vCPU/memory 的比例，R 型更适宜内存应用比拟高的工作，C 型比拟适宜计算类型的工作，而 M 型比拟折中。

不同类型的 instance capacity 不同，在 InstanceFleet 中能够依据容量设置不同的 unit 值，unit 值默认等于 vCore 的数量。理论应用中，咱们有两种做法：

• 一种是时候用默认，如 12xlarge 是 48 个 unit，那么 c5.24xlarge 就是 96 个，这样在预估好了集群所需资源之后，能够间接依据所需 CPU 资源转换成 unit 个数就能够申请了，这种状况适宜于配置到 InstanceFleet 的机型都具备一样的 CPU/memory 比例，或者是局部机型的 MEMORY 比例大于目标值，且违心承当一部分的 memory 资源节约。如果选入了 memory 比例小的机型就可能会因为该种机型 memory 有余，无奈无奈依照预期申请到足够的 executor，导致 spark application 因为资源不够停留在 accept 阶段；
• 另一种计划是依据 Spark 利用的 executor 配置资源，依据预期所选的机型上能够启动的 executor 最大个数的最大公约数作为一个 unit，这种状况的限度在于集群的申请和 spark 利用的配置绑定了起来，尽管能够更高效的应用集群资源，然而一旦利用配置变动，就须要重新部署集群，定制化程度较高，有利有弊。

在 long term Amazon EMR 的运维期间，咱们有时会遇到须要批改 Amazon EBS 存储的需要，对于 Master 和 Core node（须要是不依赖 NVMe SSD 的机型，如非 i3 系列），咱们能够借助 Elastic volumes 的性能来实现 Amazon EBS 的动静伸缩，具体介绍能够参考这篇文章Dynamically scale up storage on Amazon EMR clusters。然而对于 Task node 须要频繁 scaling 的场景，咱们应用动静伸缩 Amazon EBS 的计划就得失相当了，这种场景下如果 Amazon EMR 可能反对批改 InstanceFleet 的配置，并在下次 scaling 的时候失效，是最不便的方法。目前为了满足应用 InstanceFleet 的 Task node 的配置批改，咱们只能采纳重建集群。

• Dynamically scale up storage on Amazon EMR clusters
  https://aws.amazon.com/cn/blo…

InstanceFleet 目前还存在一些限度，如：

咱们无奈被动设置不同 instance type 的 provision 优先级。在一些场景下，咱们冀望退出更多的机型备选，然而其中的某些实例类型咱们仅心愿在主力机型有余的状况下作为补充机型退出，这种诉求目前是无奈实现的；官网给出的解释是，其外部会有算法来计算咱们须要的 units，会联合总体开销和实例资源状况综合思考进行机器的 provision。

另外就是在 Amazon console 上查看 InstanceFleet 的状态时，无奈高效的找到以后处于某种状态的机器，因为 fleet 会保留历史上 1000 个机器的记录，当超过 1000 个历史机器时，就会抛弃掉最早的记录，始终保持然而页面上须要一直刷新能力获取残缺的 list，此时对于在 WEB 上进行直观调试的用户而言不太敌对，而对于应用 amazon cli 的用户来说，咱们能够通过 list fleet 并 filter 某种状态的 instance 来获取本人想要的后果。

上面是应用的 InstanceFleet 的配置状况：

集群伸缩策略

对于不同的利用场景，咱们目前应用了两种伸缩策略，一种是由任务调度端依据工作状况进行被动 scale，一种是通过监控集群状态由 Amazon EMR 进行被动的 scale。

被动伸缩的形式

对于基于 Optimus 的 ETL pipeline 来说，对于每个 batch，Spark 须要多少 resource 进行计算，咱们能够通过历史数据进行拟合，找出数据量和所需资源的关系，并通过一直反馈，能够越来越精确的预计出对于给定量的数据集所需的集群资源，因为 Optimus 运行的 Amazon EMR 集群是 dedicated 的，所以咱们就能够在提交 Spark 工作之前就去精准的 scale 集群达到目标 capacity。下图是 Task node 伸缩在 Airflow 调度下的 workflow。

被动伸缩的形式

Datafeed pipeline，实际上是多条不同 schedule 距离，不同资源需要，以及不同工作 SLA 需要的工作汇合，因为每个工作之间互相独立，此时 Amazon EMR 相当于一个共享的计算资源池，很难从每个工作 schedule 的维度去治理 Amazon EMR 集群的 capacity。所以咱们采纳了Amazon EMR managed scaling。启动了此项性能之后，Amazon EMR 会继续评估集群指标，做出扩大决策，动静的进行扩容。此性能实用于由实例组或实例队列组成的集群。另外咱们在 Yarn 上设置了不同的 queue，以期可能将不同资源需要和优先级的工作做粗粒度的隔离，联合上 Yarn 的 capacity scheduler，让整体集群资源尽量正当应用。在理论应用中，咱们屡次遇到了无奈主动伸缩的状况，此时须要手动触发一次伸缩，之后就能够复原主动了，目前起因不详。

• Amazon EMR managed scaling
  https://docs.aws.amazon.com/z…

以上采纳的两种计划各有利弊，对于第一种计划，更实用于一个 dedicated 集群用于提交齐全可预知 capacity 的场景，这种状况下咱们在提交工作之前就能够被动的将集群 size 设置成咱们想要的 capacity，疾速而精确；而对于第二种场景，非常适合用于 Amazon EMR 作为一个共享的计算平台，利用端作为繁多的工作提交者无奈获取以后及将来提交的工作全貌，也就无奈计算 Amazon EMR 所需裁减的 capacity，这种状况下 Amazon EMR 集群须要在工作提交之后依据一些集群 metrics 能力进行动静调整伸缩，在时效性上会有提早，对于一些 DAG 较为简单，两头步骤较多且对 shuffle 和数据歪斜敏感的 Spark 利用来讲也不敌对。

针对以上 case，Transformer 团队正在开发一套运行与 Amazon EMR 和 Yarn 之上的基于利用和策略角度运维的 Framework – Cybertron。咱们冀望能通过这个服务能够站在更全局的角度去正当的治理多个 Amazon EMR 集群资源，可能让利用端不去关注 Amazon EMR 集群的资源状况，综合 Yarn 的 scheduler 和 Queue 等的配置，对集群资源和任务调度能有一个更高视角的管制。

Spot 和 Ondemand 机型的混用

理论利用中，即便咱们抉择了 InstanceFleet，也会因为极其的状况导致无奈配齐资源，此时咱们不得不用 Ondemand 机型来补足缺口，如下面的流程图所示，当期待集群 scale 肯定工夫之后，如果仍然无奈配齐需要指标，咱们就会申请 ondemand 机型用来补足，在 InstanceFleet 的场景下，ondemand 类型的机型是和 Spot 机型范畴是一样的。值得注意的一点是，尽管 Amazon EMR 中能够配置 Provisioning timeout 的 action 是 After xx minutes, Switch to On-Demand instances，但理论状况是这个策略仅在首次创立时 provisioning 失效，不实用在运行集群中启动 spot 的状况，因而咱们依然须要依据理论 InstanceFleet 的状况去被动申请 Ondemand 机型。

对于更极其的情景，如黑五到来或者美国大选期间，咱们会被动间接将所以申请机型间接替换成 ondemand，以避免频繁的无奈配齐 Spot 带来的额定工夫开销。另外，在 Spark job 运行期间，如果遇到了因为 Spot 机型回收导致的工作中断的状况，咱们会在 Airflow 的调度下，依据以后集群状态加大 ondemand 机型进行配比，以期可能疾速复原。

成果

下图是应用了被动 scale 计划的集群，在一天内 24 个小时集群依据数据量的状况进行伸缩的状况，红色柱子是集群的 Memory capacity，蓝色 + 绿色的累加局部为理论应用的内存量。从理论应用来看，咱们能够做到在工作提交前被动 scale out 到冀望的 capacity，每个 batch 的工作能够充分利用集群资源，在 SLA 工夫内实现数据处理，并在不须要集群之后马上 scale in 进来。在升高开销的同时满足工作需要。

下图是应用了 Amazon EMR autoScale 计划的集群。咱们能够看到随着更多的 Spark 工作提交，集群负载变高，集群依据负载状况 scale out 了两次，最终在工作全副做完，并闲暇一段时间后将 Task node 缩回了 0。

HDFS 的依赖

在咱们的应用场景中，Amazon EMR 仅作为计算资源，其上的 HDFS 仅须要撑持 Spark 利用即可。在一次批处理的过程中，生成的数据会先存储在 HDFS 上，而后由 publisher 将数据搬移并长久化到 Amazon S3 上。对于为什么不间接写入 Amazon S3，次要是思考到业务数据的特点以及 Amazon S3 的个性（笔者在写这篇文章的时候，看到 Amazon Web Services 曾经解决了 Amazon S3 的强统一模型，极大的简化了很多零碎设计，能够参考 Strong Read-After-Write Consistency 的形容）。从零碎设计的角度，咱们也不冀望数据流上下游因为数据模式耦合的太紧，这样不仅不利于保护，还会加大 Spark 利用的运行工夫，变相减少了老本同时，对于应用 Spot 竞价机器的场景，更长的运行工夫也就意味着更大的被中断机会。

• Strong Read-After-Write Consistency
  https://aws.amazon.com/cn/blo…

总结

随着咱们对 Amazon EMR 应用的越来越深刻，在满足产品需要的同时，咱们也在一直“榨干”Amazon EMR 开销，本文冀望能通过咱们的 Amazon EMR 应用教训给读者启发。也感激在这个过程中 Amazon EMR 团队的反对。

另外 Amazon EMR 团队也在依据客户的理论需要不断完善和推出新的性能。目前咱们正在调研试用 Amazon Web Services 最新推出的 Amazon EMR on Amazon EKS，冀望可能有更灵便的应用形式，更快的 scale 速度和更小的开销。咱们会在后续的文章中持续更新停顿。

本篇作者

彭康
FreeWheel 高级软件工程师

毕业于中科院计算所，目前就任于 Comcast FreeWheel 数据产品团队，次要负责广告数据平台数据仓库的建设