关于AWS Elastic Map Reduce和Spark的学习

  • 利用S3和EMRFS,
  • 省钱,在现货市场上狩猎,
  • 最佳文件大小:128MB是最佳选择,
  • bzip2lzo用于智能压缩; gzip如果您不在乎,
  • 为了获得最佳的群集大小, 反复试验是必经之路,
  • 监控或艺术品,以确保您能得到所付的钱。

去年(即2017年),我已经使用AWS EMR集群与集群计算框架Spark进行了广泛合作。 我的个人经验是发现一种新的数据工程方式。 一种依赖于瞬态工作负载,不变的数据存储,更精细的成本控制,也许更重要的是计算与存储分离。 ……我已经超越了自己,让我们开始吧!


EMRFS,又名EMR文件系统

如果您已经使用过Spark,那么您将知道它基于Hadoop技术构建。 您可能还听说过HDFS,这是Hadoop的goto文件存储。 HDFS为Hadoop和Spark提供了最佳性能,但是,如果您使用AWS EMR,则一定要考虑Elastic Map Reduce文件系统,即EMRFS。

EMRFS是HDFS的一种实现,它允许在S3(来自AWS的基于对象的存储)上存储和检索数据。 在性能方面,很难击败HDFS。 使用EMRFS会带来一些损失,尤其是在初始数据检索和最终存储方面; 中间映射没有费用,但是减少了步骤。

然后可能会问,与EMRFS相关的好处是什么? 最重要的一项功能是将作业输出永久保存到S3的能力。 这意味着您可以为特定任务运行集群,将其输出卸载到S3,最后关闭集群。 然后,您将使用瞬态 EMR群集; 顺便说一下,自去年10月以来,EC2实例被记为第二个实例,因此,瞬态群集更为重要。

在以下各节中,我可能会交替使用S3和EMRFS。

走向无服务器

是的,我对这个时髦的词非常满意。🙂好的,我真正的意思是一个名为计算和存储分离的数据范例; 这个概念很简单,但是它的全部内容都值得发表。 简而言之,让我们假设计算和存储绑定在一起的情况。 例如Redshift群集或HDFS之上的裸机Hadoop等。然后,您将始终需要为存储而不是计算能力付费—无论您是否在运行计算。

计算与存储分离”方法背后的思想是,数据按需放置,而计算资源是按需生成的,并且一旦任务完成就将其关闭。 这使我们受益于EMRFS; 对S3中存储的数据按需运行分析工作负载的能力。

S3在EMR中的表现非常出色,但不仅如此; 它与其他AWS产品(如AthenaSpectrum)并驾齐驱。 本部分的标题实际上是非常相关的,因为S3与列文件格式( ParquetORC等)结合在一起,将无用的范例带入了数据工程,经典数据仓库,商业智能和分析领域。

要结束关于EMRFS的这一部分,让我分享一些代码,展示如何使用PySpark与EMRFS进行交互,

通常,与分析相关的工作负载不是关键业务。 可以对它们进行设计,以便在出现故障后足以重新启动它们-这种属性称为idempotenc e 。 能够在偶发性故障中幸存下来可以节省成本,因为这样您就可以利用现货市场并节省多达80%的成本。 另一方面,如果您的工作量很关键,您仍然可以部分依赖现货市场。 您只需要清楚了解不同的EMR节点类型以及丢失其中任何一个所带来的风险。

EMR集群是弹性计算云 (EC2)实例的集合。 集群中的每个实例都称为节点,可以具有3个角色之一:

主节点(恰好为1)主节点管理集群,协调映射/减少可执行文件和数据子集到核心和任务实例的分布。 如果您的工作负载很关键,那么就不要在这里执行实例。

核心节点(0个或多个)核心节点运行任务,并根据需要使用HDFS在本地存储数据; 在调整群集大小时,请牢记这一点,在此处选择竞价型实例还存在数据丢失的风险-尽管实际上该工作已终止。

任务节点(0个或多个)是最佳竞价型实例候选者。 该节点仅运行任务,用于加速工作负载。 当任务节点死亡时,不会丢失任何数据; 主节点将仅注意到该作业并将其重新分配给其他节点(任务或核心)。


文件不要太小!

很小的文件会严重影响EMR的工作时间。 无需赘述:每个文件的加载都需要EMR生成JVM进程,从而导致CPU时间开销; 而且由于您有小文件,这意味着您有很多文件-对吗? 否则,您将不会使用EMR集群,是吗? 同样从EMRFS角度来看,您拥有的文件越多,执行的网络调用就越多。 简而言之,小文件是个坏主意。

但是, “小”是什么意思呢? 最佳尺寸是什么? 这里的魔术数字是128MB ,好吧,这不是魔术: 128MB是用于EMR的Hadoop块大小设置,它是您应该追求的目标; 您不希望低于该数字一个数量级。

如果您无法控制文件大小, S3DistCp可以使用S3DistCp工具来帮助您; 它基本上允许您使用HDFS将小文件重组为更大的文件-看看这篇文章。

当压缩很重要时

在上一节中,我们研究了许多小文件的情况,现在让我们谈谈少数但大文件的情况。 在这种情况下,您需要注意文件的压缩。 或更具体地讲,称为“ 可拆分性”的压缩算法的功能。 不言而喻:使用可拆分算法压缩的文件可以拆分并重新组合,而无需任何解压缩步骤。 当EMR处理这样的文件时,如果足够大,该文件将被分成许多分区,每个分区都分配给一个映射器任务。 所有节点并行工作,您得到的货真好!

现在,让我们看一个使用不可拆分算法压缩的大文件的极端情况。 在这种情况下,整个文件将分配给单个映射器任务,这意味着一个节点上大约有一个核心。 因此,工作负载总体上将变慢,此外,在您支付的整个集群中,只有一个节点正在工作。 不好! 尽可能地拆分。

如果您喜欢的压缩算法是可拆分的,请在下表中查找:

对于此优化问题,应考虑的变量是:

  • EC2实例类型
  • 核心节点数
  • hadoop / yarn配置(请参阅AWS文档)

为了进行监视,我建议在启动集群时启用Ganglia Web界面。 监视是关键,这就是我们发现压缩文件导致的空闲节点问题的方式。 如果使用EMRFS,则还应注意网络吞吐量。 通常,您不想在内存,CPU,磁盘I / O方面遇到瓶颈,以便从群集中提取最大价值。

关于节点类型,通常是通用EC2实例m4 家庭是一个很好的起点(例如m4.xlarge )。

对于YARN配置,我们只需关闭以下配置即可将工作时间减少50%: spark.dynamicAllocation.enabled 。 基本上,它允许在多个步骤中重用Spark执行程序,更多内容在文档中。

如果您使用的是AWS平台,则生成一个小型集群并测试您的假设真的很容易; 不要犹豫进行深思熟虑的实验,回报可能是巨大的。


包起来!

这个职位最终变得比原先预期的更长。 有很多话要说,还有很多要学习。 无论如何,我希望您能在这里找到有用的东西。 如果您有任何反馈意见,我想向您学习!