AWS EMR 与 Azure HDInsight 产品分析

AWS EMR 与 Azure HDInsight 产品分析

AWS 和 Azure 是全球最大的两家云厂商,分别对应于亚马逊和微软的云计算平台,本文要介绍的 EMR 和 HDInsight 分别是其大数据集群服务。下面先看看官方定义:

AWS EMR:Amazon EMR 是一个托管集群平台,可简化在 AWS 上运行大数据框架(如 Apache Hadoop 和 Apache Spark)以处理和分析海量数据的操作。

Azure HDInsight :Azure HDInsight 是一项用于进行开源分析的经济高效的企业级服务,可用于轻松运行常见的开源框架,包括 Apache Hadoop、Spark 和 Kafka。

简单来说,它们是多台虚拟机组成的集群,附加大数据组件,可以在创建时进行各种配置,比如安装 Hadoop 环境、Spark 环境等,减少自己搭集群的成本,按需付费,主要用于大数据处理,提供云上处理海量数据的环境。

以下从不同方面对这两款产品进行对比分析。

实例类型

当你计划买一台电脑时,会考虑不同电脑的配置,云上的服务器也如此,云厂商提供了不同的机型和配置,由 CPU、内存、存储和网络容量组成不同的组合,以应对不同使用场景,云产商还针对不同使用场景提供优化过的机型。EMR 和 HDI 集群底层就是这些云服务器组成的集群,不同配置的集群依赖于不同的服务器,用户可以自定义机型配置。

集群类型

机器实例就像是一座大厦的根基,当根基打牢后,我们就构建上层应用。大数据集群中可以安装不同的 Hadoop 组件,每一种 Hadoop 组件的组合可以看做是一种集群类型。HDI 有 7 个不同类型的集群,每个集群类型支持一组不同的组件,所有集群类型都支持 Hive。而 EMR 则是所有需要的组件都自定义,不同 EMR 版本有不同的可选组件。

灵活性

通过对 AWS 和 Azure 的使用,AWS 提供的每个服务都比较独立,方便用户自定义组合,Azure 相对有更多的封装,各有优劣,看用户的使用习惯。比如 Azure 提供了资源组这个功能,将相关资源划分在一个资源组下,相当于一个容器,便于统一管理,而 AWS 的资源组则是根据标签进行分组,两者管理资源的思路不一样。对于集群来说,Azure 将 HDI 的每个组件组合在一起,不对外提供自定义,EMR 则是所有组件自由选择,相对更灵活。

节点架构

AWS EMR 可以创建单节点集群,也就是只包含主节点,这种情况比较少用,我们讨论多节点集群。一般情况下都是具备主节点、核心节点以及任务节点。

  • 主节点:主节点负责管理集群,调度任务;
  • 核心节点:至少有一个核心节点,运行任务且使用 HDFS 存储数据;
  • 任务节点:可以没有,该节点只运行任务。

EMR 5.23.0 及之后的版本支持 1 个主节点和 3 个主节点两种类型,3 个主节点的类型需要通过命令行创建。

HDInsight 固定两个 Head 节点,至少一个 Worker 节点。

EMR 和 HDInsight 对比可发现,区别在于 EMR 可以有任务节点。任务节点的存在让计算节点更灵活,更具有弹性。当计算和存储在同一个节点上,计算能力的更改会导致存储的变化,比如删除核心节点会同时影响存储。如果计算节点单独存在,这时可以将计算节点看做是无状态的,可以自由伸缩。EMR 的设计中考虑了这种弹性,HDInsight 则没有,但 HDInsight 通过计算与存储分离,将存储放至 Azure Storage 中,也实现了弹性计算节点的能力。

存储

通过前文我们了解到 EMR 有主节点、核心节点、任务节点三种节点,其中任务节点不是必须的,而 HDInsight 只有主节点和工作节点。EMR 会将数据存储在核心节点,任务节点只运行任务,而 HDInsight 默认就将数据存储在了 Azure 存储中。

EMR 的数据默认存储在集群 HDFS 文件系统中,同时支持 EMRFS 文件系统,可以将数据存储在 S3。

HDInsight 数据默认存储在 Azure Storage 中,也可以选择存储在 Azure Data Lake Storage。

EMR 三个主节点的高可用性

  • 高可用 HDFS:EMR 三个主节点,NameNode 只会在其中两个节点上运行,一个 NameNode 处于 active 状态,另一个处于 standby 状态,如果 active NameNode 主节点发生故障,standby NameNode 的主节点将变成 active NameNode 节点,新的主节点替换出故障的主节点,作为 standby NameNode。
  • 高可用 YARN ResourceManager:YARN ResourceManager 在所有三个主节点上运行。一个 ResourceManager 处于 active 状态,另两个处于 standby 状态。如果具有 active ResourceManager 的主节点发生故障,具有 standby ResourceManager 的主节点会接管所有操作。EMR 用新的主节点替换故障的主节点,新节点将作为 standby 重新加入 ResourceManager。

HDInsight 主节点的高可用性

HDInsight 与上述 EMR 中的 HDFS 和 YARN 类似,但是只有两个主节点,一个处于 active 状态,另一个处于 standby 状态。

通过对 EMR 和 HDInsight 的存储以及高可用性进行分析后,我们可以再看看它们节点架构不同的原因:

  • HDInsight 没有核心节点是与其默认存储有关,使用外部存储,不产生特殊化节点。
  • EMR 高可用情况有三个主节点,HDInsight 固定两个主节点,这与其设计有关,云服务器本来就相当稳定,所以 EMR 默认集群类型是一个主节点,同时提供三个主节点的备选项,HDInsight 为了保证高可用,仅提供两个主节点的集群类型。

Edge Node

HDInsight 中可以在页面上以添加 Appcalition 的方式创建边缘节点,但是在 Azure 页面上操作只能添加 Azure 已经内置的第三方应用,比如 Kyligence Enterprise。要想创建空的边缘节点或者在边缘节点上自定义软件,那么可以通过 Azure 资源管理器模板进行创建,相关细节不再赘述,可参考官方文档:在 HDInsight 上创建边缘节点

EMR 中没有 edge node 的概念,可以通过创建单独的 EC2 节点进行配置,与 EMR 集群进行通信,将作业任务提交到 EMR 集群,以此来拥有像 HDInsight 中 edge node 的角色。

由于 Azure 服务相对 AWS 服务封装性更强,在 AWS 中创建的 EMR 集群,我们可以在虚拟机服务下找到 EMR 集群对应的虚拟机,而 HDInsight 创建完之后,我们无法找到对应的虚拟机。除此之外,对于边缘节点也是如此,EMR 中的边缘节点一般通过创建 EC2 的方式绑定到集群,HDInsight 通过模板创建空的边缘节点,实际上也是一台 Linux 虚拟机,只是由于 Azure 的封装性,它只提供 Application 的方式给我们查看边缘节点相关信息。

这是由于两家云产商的设计理念不同吧,安装边缘节点一般情况下就是在其上安装应用,HDInsight 正好就将边缘节点上的应用暴露出来,其他内容都隐藏起来,用户只看到它需要的东西即可。

Azure HDInsight 边缘节点存在的问题

在使用 Azure HDInsight Application 碰到一些已经与 Azure 官方确认过存在的问题,下面做个小汇总:

  • HDInsight Application 通过命令行方式创建时,无法指定 https endpoint 相关信息,也就是在边缘节点安装的应用无法为其设置访问链接。目前只能通过模板的方式创建比较完善的边缘节点。
  • HDInsight Application 不支持比较合适的删除方式,尽管页面上提供了删除按钮,并且提供删除 Application 的命令,但直接使用它们都会出错,需要登录 Ambari 手动停止所有服务后再进行删除。
  • HDInsight 提供了 az hdinsight application wait 命令用于等待 Application 创建完成,但是该命令仍然存在问题,不能保证 Application 完全创建完成,只能手动在该命令执行完之后添加适当的超时时间尽量让 Application 创建完成。由于整个 Application 创建过程比较复杂,目前没有很好的手段去确认当前创建任务已经完全执行完成。
  • 如果需要创建多个边缘节点,HDInsight 不支持并行创建 Application,只能串行创建,但由于上一个问题的存在,HDInsight 无法保证前一个 Application 已经创建完成,导致串行创建的过程中也会存在创建失败的情况。

初始化脚本

在很多场景下我们需要在启动的机器实例/集群上做一些初始化操作,比如配置环境、安装软件、开启某项服务。

EMR 提供引导操作在集群启动时执行脚本,可以在脚本中安装其他软件或自定义集群实例的配置。如果有几个实例初始化失败,EMR 会尝试重新分配失败的实例并继续执行,如果太多实例导致引导操作失败,EMR 会终止集群。此处的引导操作是针对 EMR 的,而在使用边缘节点的场景中,在 AWS 平台,我们是通过创建单独的 EC2 作为边缘节点,那么初始化就是对 EC2 进行初始化。

AWS 对 EC2 初始化有两种形式:

  • Shell 脚本:这种方式相对简单,熟悉 shell 脚本即可进行编写,不需要额外的学习成本。AWS 会完成脚本的执行,并且会将脚本以及脚本产生的日志存放在特定目录下。详情可参考:https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/user-data.html
  • cloud-init 指令:它不是 AWS 的一个功能,而是一个 Linux 上的一个工具,可将它用于定制云上虚拟机实例,对于没有安装 cloud-init 的虚拟机镜像,则无法使用该功能,需要手动安装 cloud-init。使用 cloud -init 可以通过指令的方式对虚拟机进行初始化,并且可以使用相关指令获取执行结果,相当于回调函数,可以方便地进行虚拟机初始化。详情可参考:cloud-init 官方文档

HDInsight 提供了使用脚本自定义集群的功能,并且有两种形式:

  • 集群创建过程中的脚本操作。该方式在脚本执行失败的情况下,会导致集群创建失败。
  • 正在运行的集群上的脚本操作。该方式脚本执行失败不会影响集群的状态。

在使用 edge node 的场景中,我们可以使用第二种形式,基于已经在运行的集群,再其上安装 edge node 并且执行 script action,可以在配置中指定某类节点执行 script action。

Resize 功能

AWS EMR 节点 Resize 支持手动伸缩和自动伸缩两种方式:

  • 手动伸缩:通过 AWS 控制台或 AWS Cli 命令行,指定 EMR 目标实例组节点数量;
  • 自动伸缩:AWS 提供了丰富的自定义伸缩规则,当达到某些规则时,EMR 可进行自动伸缩,可对不同的实例组配置不同的规则。

对于边缘节点, AWS 使用单独创建的 EC2 作为边缘节点,可通过将边缘节点加入到 Auto Scaling Group 进行统一管理,配置好伸缩规则即可。

Auto Scaling Group 是包含 EC2 实例的集合,这些实例在逻辑上进行了分组,用于自动扩展和管理,通过配置伸缩策略实现 EC2 实例数量的增减。

Azure HDInsight worker 节点也支持手动伸缩和自动伸缩两种方式:

  • 手动伸缩:通过 Azure Portal 或 Azure Cli 等方式,指定 worker 节点的数量。
  • 自动伸缩:该功能目前仅在 Azure Global 支持,并且支持两种自动伸缩:基于负载的伸缩和基于计划的伸缩。基于负载的伸缩是根据 CPU 利用率进行自动伸缩,基于计划的伸缩是根据用户自定义的时间进行伸缩。

对于 HDInsight 边缘节点,Azure 目前不支持伸缩,并且 Azure Application 删除目前还存在问题,前文已经介绍过,所以也无法通过手动创建和删除 Application 的方式达到伸缩的目的。

Spot 实例

AWS EC2 实例按照购买模式来分有多种类型,按需实例、预留实例、专用实例、Spot 实例等。按需实例就是我们常用的按使用时间的计费方式,Spot 实例则是请求未使用的 EC2 实例,利用 AWS 的空闲计算容量,显著降低用户成本,详细可参考官方文档:实例购买选项

spot 实例是利用 AWS 服务中可用的空闲计算容量,相当于这台实例就是没那么稳定,但是可以显著降低用户成本,主要有以下两个特点:

  • 实例价格随供需随时变化;
  • 实例可能会被 EC2 中断;

可以用于容错或者较灵活的场景,比如测试或者开发环境,无状态 Web 服务器等。

在创建 EMR 时,对节点设置为 Spot 实例后,只要指定的最高价超过指定实例的当前 Spot 价格,并且具有可用的容量,那么请求 Spot 实例就会成功。创建 EMR 节点 Spot 实例设置最高价有两种方式:使用按需价格作为最高价格、手动设置最高价格。

使用 Spot 实例时,要做好应对终端的准备,如果 Spot 实例需求增加或 Spot 实例供应减少,在 Spot 价格超过我们设置的最高价时,EC2 可能会中断 Spot 实例。

在创建 EMR 时可以指定任意节点为 Spot 实例,但是对于主节点和核心节点不推荐使用这种方式的,毕竟 Spot 实例可能会被中断,而主节点的重要性不必多说,核心节点需要存储数据也要保证机器不中断。任务节点仅仅是跑任务,可以将其设置为 Spot 实例。

Azure VM 支持使用类似 Spot 实例这样的购买方式,在 Azure 中叫 Low-Priority VM,通过创建 virtual machine scale set,设置 VM 为 low priority,这样既可大幅降低成本。但 Azure HDInsight 不支持 Low-Priority VM 这样的模式。

所以综上来看,AWS 在 Spot 实例方面占优势,在大规模集群下可以降低成本。

总结

经过以上的对比分析,EMR 和 HDInsight 在基础功能上都类似,只是实现方式有差异,它们在不同方面各有优势,个人感觉 AWS 相对还是更稳定更完善,在使用过程中可以从多方面综合考虑选择云平台。

本文对 EMR 和 HDInsight 作了粗浅的对比,关于 EMR 和 HDInsight 还有非常多的知识值得去探索。

i

发表评论

电子邮件地址不会被公开。 必填项已用*标注