如何在E-MapReduce中玩转OSS

本文涉及的产品
EMR Serverless StarRocks,5000CU*H 48000GB*H
简介: 在E-MapReduce中,用户可以将OSS作为Hadoop/Spark的可选数据源之一。但是在实际使用时,我们发现Hadoop读写OSS的性能不令人满意。为了解决这个问题,E-MapReduce团队对Hadoop的底层实现进行了优化,使得OSS数据源能够更好地适配Hadoop/Spark。

背景介绍

阿里云E-MapReduce公测以来,陆陆续续有一批用户开始在E-MapReduce上创建和使用集群。在和客户的交流和沟通过程中,我们发现这样一个现象:大部分用户更倾向于将数据存储在自建的集群HDFS中。这里面有几种考虑:

  • 使用习惯:很多用户曾经线下或者线上运维过自己的集群,业务数据都是存放在集群的HDFS中。他们熟悉HDFS这一套,并且在使用HDFS上具有一定的经验。
  • 性能考虑:将数据存在在HDFS中,可以在计算时充分利用数据本地性来提高计算性能。将数据存放在OSS上,计算时需要经过网络从远端拉取一次数据,存储时需要经过网络将数据上传上去,这部分开销将影响作业的整体性能。
  • 不了解OSS:也有一部分用户对OSS不了解或者根本不知道。

对于数据应该存储在HDFS还是OSS的问题,我们说其实都是可以的。不管HDFS还是OSS,都是稳定可靠的数据存储系统。但是我们推荐用户将数据或者部分冷数据存储在OSS中,这是基于以下考虑:

  • OSS的存储成本相较于ECS配属的云磁盘要更低。
  • OSS存储的安全,高可靠和弹性扩展,可以让用户更专注与计算本身,不再分散精力到HDFS系统的运维上。
  • 存储计算分离思想

计算存储分离

部署一个集群大体上可以分为两类:混合部署和分离部署。混合部署指的是计算和数据存储部署在一个集群中;分离部署指的是计算和数据存储分别部署在不同的集群中。下面两张图可以直观看出来:
_vs_

早期将HDFS和Hadoop部署在一起时,可以利用数据本地化特性来提升作业性能。但目前看来,“数据本地化(data locality)”的概念已过时。在许多Hadoop场景中,即使计算和数据存储部署在一个集群,Hadoop作业也无法受益于数据本地化。然而将计算和存储分开可以简化操作,用户可以分别扩展和管理计算和存储系统。

  • 对于计算和存储来说,所需要的机器类型也是不一样的。对于HDFS来说,你可能需要更大的磁盘空间;对于Hadoop/Spark来说你可能需要更多的CPU和更大的内存。针对HDFS和Hadoop/Spark选择合适的机型,可以让集群发挥更大的能力。
  • 从集群扩展角度来说,随着业务的发展,集群的规模常常不能满足业务的需求。也许是数据规模超过了集群存储能力,也许是业务上对数据产出的周期提出新的要求导致计算能力跟不上。这就要求我们能随时应对集群存储空间不足或者计算能力不足的挑战。将计算和存储分离,可能更好地应对单方面的不足。如果将计算和存储混合部署,常常会因为为了扩存储而带来额外的计算扩容,这其实就是一种浪费;同理,只为了提升计算能力,也会带来一段时期的存储浪费。
  • E-MapReduce的一个很大的特性是按需创建集群,也就是需要处理数据时才去创建集群,用完即可销毁。这种模式很适合那些只需要每天定时离线处理的场景,例如产出每天报表等等。但是,这种模式也带来一个要求,集群不能存放数据,否则集群释放后数据也就丢失。这就给那些希望用集群来存放数据的用户代码麻烦。计算和存储分离可以很好地解决这个问题,你只需要保证存储集群长期运行即可,计算集群可以随时使用随时创建,增加使用的灵活性。

这里只是简单说一下E-MapReduce上计算和存储分离带来的好处,关于存储计算分离部署的讨论还有很多,这里就不再赘述。

新的选择

上一节说到了计算存储分离的优势,如果你认可这一点,那么看完这一节你还会有更多收获。现在我们部署集群时,就有Hadoop和HDFS两个集群。使用开源软件时,我们一方面享受到技术贡献的便利,同时也不得不面对服务稳定性难以保证的问题。对于数据来说,服务的稳定性和安全性是高于一切的。所以,服务稳定性,数据安全性等等问题成为我们日常维护集群所不得不面对的问题。今天,在阿里云上,已经提供类似的产品来将你从这一切繁琐的问题中解脱出来,这就是OSS。OSS是阿里云提供的海量、安全和高可靠的云存储服务。存储容量和处理能力的弹性扩展使你专注于核心业务。有了OSS,我们可以这么玩集群部署:

hadoop_oss

有了OSS存储数据,我们接下来要面对的问题是如何在MR,Hive,Pig以及Spark作业中支持OSS数据源。虽然作业种类很多,但追根溯源,我们发现只要在Hadoop上实现对OSS的支持即可。Hive和Pig实际上就是分解成很多个MR作业来处理的,而Spark也是通过Hadoop接口来实现对HDFS类文件系统的支持。有了这个思路,我们就可以很方便地实现Hadoop上对OSS的支持了。

OSS通用支持2.0

我们已经将这一部分代码开源,有兴趣的可以看这里,也欢迎大家贡献代码(Bug fix或者New feature)。本节,我们不会去谈Hadoop中如何支持OSS数据源的实现细节,而是去谈谈实际线上用户使用Hadoop+OSS时碰到的性能问题:

  • 数据读:一份相同大小的数据从OSS读过来的时间比直接从HDFS读的时间长。核心问题是网络带宽,包括集群机器的网络带宽以及OSS出数据的通道带宽。这个问题超出了E-MapReduce产品本身的范畴,需要协同OSS以及ECS来共同解决。但从实际效果看,这个读数据时间开销的差距是在可接受的范围之内,相对于作业的整体处理时间,这个读数据时间差别占了很小的部分,不会成为block作业生产的原因。当然如果OSS数据源性能真的成为瓶颈,那就得具体问题具体分析,不属于本篇文章范畴了。

    • 结论:读数据时,确实存在一定的性能差距,差距不大。
  • 数据写:一份相同大小的数据写OSS比写HDFS的时间长,当写大数据量时尤为明显,甚至达到几倍的时间。这个问题比较特殊,通过分析我们发现,整个写数据的过程可以细化为下面两个阶段:

    • 从E-MapReduce集群端到OSS存储端的网络传输阶段。和读数据类似,这部分确实也存在这一定的性能差距,但差距不大,是在作业生产的可接受范围之内。
    • 数据在OSS内部的拷贝阶段。由于Hadoop的底层实现机制,作业的输出数据首先会写到一个临时目录中,作业完成后结束前,将数据拷贝到最终目录,这一过程会多次发生。由于OSS的保护机制,数据在OSS内部的拷贝是有限制的,整体给与的带宽很小,这直接导致了数据输出过程会很“漫长”。

上面我们分析了将OSS作为数据源时存在的两类问题。其中一类问题集中在OSS端与E-MapReduce端的网络带宽问题,这个问题的影响实际上是有限的,也可以在今后不断提升基础设施来解决。另一类突出问题是Hadoop的执行机制和OSS的保护机制共同导致的,产生的影响也严重。第二个问题不解决,那么Hadoop+OSS只能是一个玩具,无法提供生产级别的作用。不过凡事也有特例,第二个问题对MR,Hive和Pig类型作业影响巨大,但对Spark作业的影响又小了很多。因为Spark执行过程中,数据都只会在E-MapReduce集群中转来转去,直到最终结果写OSS。而MR,Hive和Pig的执行过程中,中间结果会多次落回到OSS上,类比于HDFS,这样的影响就会多次放大! 今天,我们很高兴地告诉大家,通过对Hadoop底层代码的优化,我们已经较好地解决了因为数据拷贝问题导致的性能问题,最新的EMR_1.1.0镜像将使用优化后的Hadoop版本。下面我们来简单跑几个作业来看看效果把。

性能测试

集群配置

机型:4核,8GB内存, 200GB高效云盘
规模:11台,1台Master节点,10台Slave节点

测试作业

作业:TextGenerator,随机生产一定量的文本数据。
类型:Spark
配置:--driver-memory 1G --executor-memory 4G --executor-cores 4 --num-executors 10
并发:1024个partition

结果对比

_

  • 上图红线有个比较奇怪的变化,也就是200G数据写的耗时比10G数据要少。这是因为在底层实现上,当task的输出数据比较小时,采用直接上传的方式;当task的输出数据比较大时,采用direct multipart upload方式。在200GB数据时,产生了奇怪的耗时更少的现象。
  • 数据量在200G时,性能提升了12倍;数据量在1T时,性能提升了10.6倍。

结语

我们可以看出,在EMR1.1.0版本集群中,Hadoop写OSS的性能得到了显著的提升。这个优化可以极大地提升在E-MapReduce上使用MR,Hive和Pig分析OSS数据的使用感受。当然,在Hadoop上支持OSS数据源的实现方式还有很多有待提升的地方,欢迎大家参与到E-MapReduce的开源项目中。

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
目录
相关文章
|
消息中间件 分布式计算 Kafka
使用E-MapReduce服务将Kafka数据导入OSS
kafka是一个开源社区常用的消息队列,虽然kafka官方(Confluent公司)提供插件从Kafka直接导入数据到HDFS的connector,但对阿里云对文件存储系统OSS却没有官方的支持。本文会举一个简单的例子,实现kafka的数据写入阿里云OSS。因为阿里云E-MapReduce服...
7972 0
|
SQL 大数据 对象存储
E-MapReduce的Presto组件默认支持访问oss数据
阿里云E-MapReduce从EMR-2.1.0版本镜像开始,Presto组件默认就支持访问oss数据了,不再需要引导操作额外支持。
2626 0
|
5月前
|
机器学习/深度学习 人工智能 专有云
人工智能平台PAI使用问题之怎么将DLC的数据写入到另一个阿里云主账号的OSS中
阿里云人工智能平台PAI是一个功能强大、易于使用的AI开发平台,旨在降低AI开发门槛,加速创新,助力企业和开发者高效构建、部署和管理人工智能应用。其中包含了一系列相互协同的产品与服务,共同构成一个完整的人工智能开发与应用生态系统。以下是对PAI产品使用合集的概述,涵盖数据处理、模型开发、训练加速、模型部署及管理等多个环节。
|
1月前
|
分布式计算 Java 开发工具
阿里云MaxCompute-XGBoost on Spark 极限梯度提升算法的分布式训练与模型持久化oss的实现与代码浅析
本文介绍了XGBoost在MaxCompute+OSS架构下模型持久化遇到的问题及其解决方案。首先简要介绍了XGBoost的特点和应用场景,随后详细描述了客户在将XGBoost on Spark任务从HDFS迁移到OSS时遇到的异常情况。通过分析异常堆栈和源代码,发现使用的`nativeBooster.saveModel`方法不支持OSS路径,而使用`write.overwrite().save`方法则能成功保存模型。最后提供了完整的Scala代码示例、Maven配置和提交命令,帮助用户顺利迁移模型存储路径。
|
4月前
|
存储 机器学习/深度学习 弹性计算
阿里云EMR数据湖文件系统问题之OSS-HDFS全托管服务的问题如何解决
阿里云EMR数据湖文件系统问题之OSS-HDFS全托管服务的问题如何解决
|
5月前
|
消息中间件 分布式计算 DataWorks
DataWorks产品使用合集之如何使用Python和阿里云SDK读取OSS中的文件
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
5月前
|
存储 运维 安全
阿里云OSS的优势
【7月更文挑战第19天】阿里云OSS的优势
205 2
|
5月前
|
存储 API 开发工具
阿里云OSS
【7月更文挑战第19天】阿里云OSS
197 1
|
5月前
|
存储 弹性计算 对象存储
预留空间是什么?阿里云OSS对象存储预留空间说明
阿里云OSS预留空间是预付费存储产品,提供折扣价以锁定特定容量,适用于抵扣有地域属性的Bucket标准存储费用及ECS快照费。通过购买预留空间,如500GB通用预留+100GB标准-本地冗余存储包,用户可优化成本。
221 4
|
5月前
|
人工智能 对象存储
【阿里云AI助理】自家产品提供错误答案。阿里云OSS 资源包类型: 下行流量 地域: 中国内地通用 下行流量包规格: 300 GB 套餐: 下行流量包(中国内地) ,包1年。那么这个是每月300GB,1年是3600GB的流量;还是1年只有300GB的流量?
自家产品提供错误答案。阿里云OSS 资源包类型: 下行流量 地域: 中国内地通用 下行流量包规格: 300 GB 套餐: 下行流量包(中国内地) ,包1年。那么这个是每月300GB,1年是3600GB的流量;还是1年只有300GB的流量?
133 1