是时候考虑让你的 Spark 跑在K8s 上了

泪湿孤枕 提交于 2020-01-24 03:18:16

原文链接:https://mp.weixin.qq.com/s/RT7QNQNQ0NRsAmwUMtw6ig

编者荐语:

Spark社区从2.3版本开始,已经可以很好的支持跑着Kubernetes上了。这对于统一资源池,提高整体资源利用率,降低运维成本(特别是技术栈归一)有着非常大的帮助。这些趋势是一个大数据人不得不重视的信号,所以一起提前了解并考虑起来吧!

以下文章来源于容器魔方 ,作者tsjsdbd

大数据邂逅云计算

相信玩Spark的你已经注意到最新的Spark版本已经支持不做任何修改就可以直接跑在K8s上了,即以Kubernetes容器集群作为Cluster Manager的实现。

其实早在2017年底Spark 2.2版本开始的时候,Spark社区就开始合入用K8s管理Spark集群的能力,只是那时候功能上还没有很完善。加之彼时Kubernetes还没有像现在这么普及,被广泛地接受成为应用基础设施层。经过了2年了持续迭代,Spark on Kubernetes已经成为帅气的小伙,大家可以围观起来了。

其实,大数据和云计算一直分属两个不同的领域。大数据主要关注怎么将数据集中起来,挖掘数据的价值;云计算主要关注怎么更高效地使用资源,提升资源的利用效率。当大数据发展到一定阶段的时候,它就会和云计算不期而遇。

现状并不美丽

在技术层面上,当前的大数据计算如Hadoop和Spark将计算和存储结合在一起的模式,是分布式架构构建的一种尝试。但是当社区修改HDFS以支持Hadoop 3.0的ErasureCode(纠删码)时,即接受了:不(Wu)再(Fa)支持就近读取的策略。它就代表了一种新趋势。数据层面,为取代 HDFS,可以用大规模的基于云的对象存储,构建在 AWS S3 模型上。计算层面,要能够根据需要启动计算,也可以考虑使用类似 Kubernetes 的虚拟化技术,而不是绑定 YARN。

曾经,数据处理任务从远程物理机读取数据开销大。以数据为“中心”,将数据处理任务迁移到数据所在的物理机上,能有效降低网络带宽,保证了整体性能。这就是存算一体的大数据技术架构。经过十多年的发展,网络性能已经提升了100倍,内存容量也提升了数十倍。大数据处理的瓶颈逐渐从网络转移到CPU上,上述存算一体架构的缺点也逐渐突显出来。

不同场景需要的存储空间和算力配比是不一样的。实际使用中要么计算资源达到瓶颈,要么是存储容量不足,只能对集群进行刚性扩容,造成集群资源浪费。

不同时期需要的算力是不固定的,存在波峰和波谷。物理机中存储数据造成无法大规模关闭闲置节点,造成算力闲置和能源浪费。

不同业务对运行环境需求不一样。Spark应用需要绑定Spark集群运行。Web类型需要实例快速水平扩展。所以通过统一平台来混合部署提升资源利用率的需求强烈。

容器技术的出现,给了IT行业统一运行环境一线希望。它以自己的build once,run every where的旗帜挥舞到各个IT行业。可以说如果还不考虑使用容器技术,你的基础平台的灵活性是绝对不够的。

统一的ABC平台

当前大数据的实现代表了构建分布式系统的一种方法:计算和存储以及基础架构结合在一起。但是这条路是否畅通也不好说,毕竟近期有好多文章在说大数据已死。不过话说回来,大数据的数据量是越来越大,大数据的业务需求也只增不减,只是在实现大数据需求的途径上,方向发生了些偏移。所以并不是大数据本身已死,而是原来的大数据框架底层设施有了新的方向,云原生大数据已经崭露头角。

所谓的ABC就是指AI + Bigdata + Cloud,一般由于业务部门的划分,或者历史遗留,各厂家做法普遍都是不同的研发部门维护不同的资源池。这就带来了计算、存储资源不均衡,资源调度最佳利用率和基础设施能力共享的问题。特别的基础设施技术不需要维护多套,降低研发人力成本。

如果想提高整体资源利用率,那就得有统一infrastructure平台。而且,不同业务类型对资源述求不一样,比如AI以GPU为主,Web业务以CPU为主等。所以要求基础设施平台,必须能够支持多种计算资源,统一调度能力。并且业务也得有统一的运行环境的标准,保证开发&生产的运行一致性。

很明显,以Docker+Kubernetes技术打造云原生计算平台具备这样的气质。特别是,以Docker的普适性,真的在各领域势如破竹。中国联通数据中心总经理王志军在2019年6月分享的《中国联通容器化大数据平台的探索与实践》中,提到各省公司的AI训练,大数据,容器化应用都统一在以Kubernetes+Docker为底座的统一平台上,目前拥有节点437个,大量任务同时跑在该平台上。也是这一趋势的实践。

Kubernetes as Infrastructure

大数据领域,计算资源会越来越多容器化。以前容器化主要是被 DevOps和微服务所使用,最近随着大数据应用的依赖越来越复杂,需要用容器化做更好的依赖管理和资源隔离。容器的一次构建,随处可运行的特点,非常契合应用运行环境的一致性述求。

大规模容器集群管理,Kubernetes已经是无可争议的事实标准。作为Mesos商业化的重要推手,Mesosphere 在2019年8月宣布正式更名为 D2IQ,关注点也随即转向 Kubernetes 及云原生领域。VMware则在VMworld 2019宣布推出新的产品和服务品牌VMware Tanza,全面拥抱K8s。各个领域也是遍地开花,基因数据分析,高性能计算HPC,AI机器学习,传统互联网纷纷拥抱容器技术,无不选择K8s作为容器计算平台。践行了Docker诞生时的理念,不仅仅是build once,并且run every where。

现在已经到处都是容器,该轮到大数据了!幸运的是Spark社区已经上车了,那么你呢?Spakr on K8s可以有。

Volcano

增强型K8s资源调度器

K8s自带的的资源调度器,有一个明显的特点是,依次调度每个容器。但是AI训练、大数据计算这样必须多个容器同时配合执行的情况下,依次调度是无法满足需要的。因为这些计算任务包含的容器们想要的是,要么同时都成功,要么就都别执行。

比如,某个大数据应用需要跑1个Driver容器+10个Executor容器。如果容器是一个一个的调度,假设在启动最后一个executor容器时,由于资源不足而调度失败无法启动。那么前面的9个executor容器虽然运行着,其实也是浪费的。AI训练也是一样的道理,必须所有的Worker都同时运行,才能进行训练,坏一个,其他的容器就等于白跑。要知道GPU被容器霸占着却不能开始计算,成本是非常高的。

所以当你的(1)总体资源需求<集群资源时,普通的K8s自带调度器可以跑,没问题。但是当(2)总体资源需求>集群资源时,K8s自带调度器会因为随机依次调度容器,使得部分容器无法调度,从而导致业务占着资源又不能开始计算,死锁着浪费资源。

那么场景(1)和场景(2)谁说常态呢?不用想,肯定是(2)了,谁能大方到一直让集群空着呢?此时就必须需要增强型的K8s资源调度器Volcano了。

Volcano首先要解决的问题就是Gang Scheduling的问题,即一组容器要么都成功,要么都别调度,解决了资源死锁的问题,可以很好的提高资源利用率。除此之外,它还提供了多种调度算法,例如priority优先级,DRF(dominant resource fairness), binpack,task-topology亲和,GPU感知,batchwisepack等。

多种调度算法插件,根据权重条件,就可以很好的满足各种复杂场景需求。真正做到统一资源平台,最佳资源利用率。

结语

统一的资源池,统一的计算平台,统一的基础设施技术栈,让资源利用和人力成本都达到最优,可以聚焦到业务创新方向。那么所有的技术都已经ready,是时候让你的Spark跑在K8s上了!

END

Volcano

云原生批量计算平台

开源项目Volcano是一个基于Kubernetes的云原生批量计算平台,意喻助力企业算力像火山一样爆发。

当前项目已经吸引了来自腾讯,百度,快手以及AWS等多个公司的贡献者,在不断的发展壮大,更多特性也在设计和开发阶段。

项目地址:http://github.com/volcano-sh/volcano

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!