在Application执行之前,会将所有的资源(Executor)申请完毕,直接资源申请完毕后,才会进行任务调春碰度,直到最后一个task执行完毕,才会释放掉这部分资源
优点:每一个task执行之前不需要自己去申请资源,直接使用资源就可以,那么每一个task执行时间也就缩短了,stage执行时间也缩短了,job的执行时间也就缩短了Application执行时间也就缩短了。
缺点:一直到最后task执行完毕孙森启才会释放资源,集群资源不能充分利用
二.细粒度资源调度:典型:MR
在Application之行之前不需要先将资源申请完毕,而是直接进行任务的资源调度,每一个task在执行之前自己去申请资源,则如申请到了就执行,申请不到资源就继续申请,每一个task执行完毕后,都会将自己申请的那部分资源释放掉
优点:充分利用集群的资源情况
缺点:task执行时间变长了
大数据的浪潮风靡全球的时候,Spark火了。在国外 Yahoo!、Twitter、Intel、Amazon、Cloudera 等公司率先应用并推广 Spark 技术,在国内阿里巴巴、百度、淘宝、腾讯、网易、星环等公司敢为人先,并乐于分享。在随后的发展中,IBM、Hortonworks、微策略等公司纷纷将 Spark 融进现有解决方案,并加入 Spark 阵营。Spark 在IT业界的应用可谓星火燎原之势。创新都是站在巨人的肩膀上产生的,在大数据领域Spark也不例外。在 Spark 出现前,要在一个平台内同时完成批处理、各团升种机器学习、流式计算、图计算、SQL 查询等数种大数据分析任务,就不得不与多套独立的系统打交道,这需要系统间进行代价较大的数据转储,但是这无疑会增加运维负担。Spark一开始就瞄准了性能,实现了在内存中计算。 话题讨论:1.Spark为啥这么火?Spark框架采用的编程语言是什么?是否容易上手?2. Spark能否成为Hadoop的替代者呢?为什么?它们有哪些相似点与区别?3.作为一种内存的迭代计算框架,Spark使用哪些场景?4.淘宝为什么会选择Spark计算框架呢?5.Mesos 是一个能够让多个分布式应用和框架运行在同一集群上的集群管理平台。那么它是如何来调度和运行Spark的呢?6.Spark 为什么会选择d性分布式数据集(RDD)作为它的数据存储核心?而不是分布式共享内存(Distributed Shared Memory)DSM?它们有哪些区别? 7.Spark on YARN与Spark有啥区别?8.有人觉得,大数据时代,最精髓的IT技术是Hadoop ,Yarn,Spark,您是否体验过?看好哪个?
1.Spark为啥这么火?Spark框架采用的编程语言是什么?是否容易上手?
Spark是基于内存的迭代计算框架,适用于需要多次 *** 作特定数据集的应用场合,如pageRank、K-Means等算法就非常适合内存迭代计算。Spark整个生态体系正逐渐完善中,GraphX 、 SparkSQL、 SparkStreaming 、 MLlib,等到Spark有了自己的数据仓库后,那就完全能与Hadoop生态体系相媲美。 Spark框架采用函数式编程语言Scala,Scala语言的面向对象、函数式、高并发模型等特点,使得Spark拥有了更高的灵活性及性能。如果你学过java,可能会对scala中的一些新铅或橡概念表示陌生,如隐式转换、模式匹配、伴生类等,但一旦入门,你会感觉scala语言的简洁与强大。
2. Spark能否成为Hadoop的替代者呢?为什么?它们有哪些相似点与区别?
两者的侧重点不同,使用场景不同,个人认为没有替代之说。Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面,有RDD的概念。RDD可以cache到内存中,那么每次对RDD数据集的 *** 作之后的结果,都可以存放到内存中,下一个 *** 作可以直接从内存中输入,省去了MapReduce大量的磁盘IO *** 作。但是,我们也要看到spark的限制:内存。我认为Hadoop虽然费时,但是在OLAP等大规模数据的应用场景,还是受欢迎的。目前Hadoop涵盖了从数据收集、槐旁到分布式存储,再到分布式计算的各个领域,在各领域都有自己独特优势。
3. 作为一种内存的迭代计算框架,Spark适用哪些场景?
适用于迭代次数比较多的场景。迭代次数多的机器学习算法等。如pageRank、K-Means等。
4. 淘宝为什么会选择Spark计算框架呢?
这主要基于淘宝业务的应用场景,其涉及了大规模的数据处理与分析。其主要是应用Spark的GraphX图计算,以便进行用户图计算:基于最大连通图的社区发现、基于三角形计数的关系衡量、基于随机游走的用户属性传播等。
5.Mesos 是一个能够让多个分布式应用和框架运行在同一集群上的集群管理平台。那么它是如何来调度和运行Spark的呢?
目前在Spark On Mesos环境中,用户可选择两种调度模式之一运行自己的应用程序 粗粒度模式(Coarse-grained Mode):每个应用程序的运行环境由一个Dirver和若干个Executor组成,其中,每个Executor占用若干资源,内部可运行多个Task(对应多少个“slot”)。应用程序的各个任务正式运行之前,需要将运行环境中的资源全部申请好,且运行过程中要一直占用这些资源,即使不用,最后程序运行结束后,回收这些资源。举个例子,比如你提交应用程序时,指定使用5个executor运行你的应用程序,每个executor占用5GB内存和5个CPU,每个executor内部设置了5个slot,则Mesos需要先为executor分配资源并启动它们,之后开始调度任务。另外,在程序运行过程中,mesos的master和slave并不知道executor内部各个task的运行情况,executor直接将任务状态通过内部的通信机制汇报给Driver,从一定程度上可以认为,每个应用程序利用mesos搭建了一个虚拟集群自己使用。 细粒度模式(Fine-grained Mode):鉴于粗粒度模式会造成大量资源浪费,Spark On Mesos还提供了另外一种调度模式:细粒度模式,这种模式类似于现在的云计算,思想是按需分配。与粗粒度模式一样,应用程序启动时,先会启动executor,但每个executor占用资源仅仅是自己运行所需的资源,不需要考虑将来要运行的任务,之后,mesos会为每个executor动态分配资源,每分配一些,便可以运行一个新任务,单个Task运行完之后可以马上释放对应的资源。每个Task会汇报状态给Mesos slave和Mesos Master,便于更加细粒度管理和容错,这种调度模式类似于MapReduce调度模式,每个Task完全独立,优点是便于资源控制和隔离,但缺点也很明显,短作业运行延迟大。
6.Spark 为什么会选择d性分布式数据集(RDD)作为它的数据存储核心?而不是分布式共享内存(Distributed Shared Memory)DSM?它们有哪些区别?
RDD是Spark的最基本抽象,是对分布式内存的抽象使用,实现了以 *** 作本地集合的方式来 *** 作分布式数据集的抽象实现。RDD是Spark最核心的东西,它表示已被分区,不可变的并能够被并行 *** 作的数据集合,不同的数据集格式对应不同的RDD实现。RDD必须是可序列化的。RDD可以cache到内存中,每次对RDD数据集的 *** 作之后的结果,都可以存放到内存中,下一个 *** 作可以直接从内存中输入,省去了MapReduce大量的磁盘IO *** 作。这对于迭代运算比较常见的机器学习算法, 交互式数据挖掘来说,效率提升比较大。 RDD只能从持久存储或通过Transformations *** 作产生,相比于分布式共享内存(DSM)可以更高效实现容错,对于丢失部分数据分区只需根据它的lineage就可重新计算出来,而不需要做特定的Checkpoint。
7.Spark on YARN与Spark有啥区别?
让Spark运行在一个通用的资源管理系统(如yarn)之上,最大的好处是降低运维成本和提高资源利用率(资源按需分配),部分容错性和资源管理交由统一的资源管理系统完成。而spark单独是无法有效提高资源利用率。
8.有人觉得,大数据时代,最精髓的IT技术是Hadoop ,Yarn,Spark,您是否体验过?看好哪个?
Yarn不就是Hadoop MapReduce新框架吗,这里为何要单独列出。个人认为当下Hadoop生态体系相当庞大,且技术日趋成熟,Spark还有待发展。如果有一天,Hadoop加进内存计算模型,到时,Spark又会是怎样的处境呢?
学院北京101407)(版权归原作者所有)
摘要
文章介绍了作者凯激在过击5年中在微内核技术上所做的工作.由于集成电路、计算机网络、分布式处理、多机并行处理、容错等技术的迅速发展,面向单处理机,采用内核不可抢占技术的Unix *** 作系统已经很难适应硬件技术的发展.为了适应以上技术的发展,Unix *** 作系统的内核越做越大,越做越复杂.完全丧失了其初始设计目标:系统短小精悍,容易理解.卡内基梅隆大学在美国国防部、国家科学基金的资助下,于1986年推出了一个基于微内核结构的 *** 作系统Math.口:随后.斯坦福大学等研究机构纷纷发表了他们在这个领域所做的工作, 各个大公司纷纷推出了基于微内核结构的 *** 作系统、D 微内核技术已成为新一代 *** 作系统体系结构的研究热点.
基于微内核结构的 *** 作系统和传统 *** 作系统相}匕,具有以下特点:① 内核精巧.通常内核只由任务管理、虚存管理和进程间通信3个部分组成.传统 *** 作系统内核中的许多部分都被移出内核.采取服务器方式实现;② 面向多处理机和分布式系统.基于微内核的 *** 作系统,在内核中引入了多处理机调度和管理机制,并引入了细粒度并发机制——
线程,使得多个处理机可以在同一个任务中并行地执行;③ 基于客户/服务器体系结构.在微内核结构的 *** 作系统中,任务间通信机制—— 消息机制是系统的基础, *** 作系统的各种功能都以服务器方式实现,向用户提供服务.用户对服务器的请求是以消息传递的方式传给服务器的.
“八五”期间,耪们在国家“八五攻关项目的支持下,对 *** 作系统微内核技术进行了探入研究,在微内核系统调度技术、存储管理技术、计时模型、微内核系统扩展技术及微内核 *** 作系统原型系统构造方面取得了一些研究成果.本文将介绍这些研究成果.
正文
1 微内核系统调度技术
与传统的 *** 作系统内核相比,微内核调度系统中最突出的特征是增加了处理机和处理机集及线程的管理,并且向用户提供了灵活的手段来控翩自己的程序在处理机上的运行.这{羊,微内核系统就能很好地支持多处理机体系结构.同时,线程为用户提供了细粒度的并行处理机制,使得同一个用户任务中的不同线程可以同时在多个处理机上运行.
与进程相比,线程中所带的资源很少,因此,创建线程和撤消线程的开销就比进程小.线程也称为“轻进程.在系统调度中,线程的切换开销也比进程步,但是不同任务中的线程切换会引起任务的切换,在这种情况下,线程和进程的调度开销就变成一样了.为了优化系统效率,减步由于线程切换而弓I起的任务切换,在调度算法中加入了以下代码:
IF (所选中的线程和当前运行的城程属于同一十任务)
THEN 不做任务切换}
ELSE进行任务切换 *** 作}
显然,这种方法在某种情况下会对系统性能有所帮助,但是这种方法在很大程度上属于一种“被动的,或者说是一种“碰运气”的方法.另外,单纯以线程为主的调度算法对用户任务有失公平性,以线程为主的调颂睁度算法是完全参照传统 *** 作系统中的调度算法设计而成的.当线程投入运行时,系统为它分配周定大小的时间片,系统中线程按时间片轮转.这样,就产生了公平性问题:如果一个任务中有两个线程,那么,从理论上讲,它将比只用一个线程实现的任务多获得近1倍的处理机时间.在传统的进程调度系统中,一个用户可以通过创建多个进程来获得更多的处理机调度机会,但是,它是建立在增加了创建进程和进程间通讯的系统开销代价的基础上的相比之下,创建线程的开销非常小,同一任务间的线程之闭通讯开销也很小为了解决上述问题,我们提出并实现了一种将传统的任务和新的线程调度机翩相结合的方法:以任务为单位分配时间片(这样可以保证调度的公平性),在线程调度时,当一个线程不是由于任务时间片用完的原因而放弃处理机时,只要系统中没有高优先级线程,就从本任务中选取线程,从而使得由线程切换而引起的任务切换 *** 作开销达到最小.
从目前的发展来看,用户任务的并行粒度越来越小,即用户任务中的线程越来越多,而每个线程所执行的 *** 作会越来越步.因此,使用线程+任务的方法可以有效地减少单纯的以线程为主的系统调度所引起的系统开销.
2 微内核虚拟存储管理技术
微内核虚拟存储管理系统弓『入了存储对象(Memory Object)的概念,将物理内存看成外部存储对象的(如磁盘盯樱袜)高速缓存(Cache),实现了虚拟存储器写时拷贝(Copy onWrite)技术,引入了lazy evaluation技术.定义了虚拟存储器和硬件存储管理机制的接口(Pmap),实现了与机器无关的虚拟存储系统.
虚拟存储器写时拷贝算法是微内核虚拟存储管理系统的核心算法.它的弓f入使得虚拟存储器管理的效率大大提高了一步.但是,它的实现依赖于硬件存储管理机制的页面保护机制,对于一个具有写时拷贝共享属性的存储区,其页面保护被设置成写保护.多个用户可以共享的方式对它进行读 *** 作,但是,当用户试图对这块区域进行写 *** 作时,将产生写保护故障,页面故障管理程序将为用户进程复制物理页面.从而达到写时拷贝的目的.
在I386体系结构下,只有用户态页面允许写保护,在其他机器状态下,硬件存取机制将绕过页面保护机翩,直接对页面进行写 *** 作.在这种状态下,写时拷贝算法将失效.而在微内核体系结构中,可能有各种状态下的服务器,如在内核态下运行的服务器.为了解决这个问题。我们引入了写时拷贝和访问时拷贝(Copy oil Reference)相结合的算法.
即在用户态上使用写时拷贝算法,在其他状态下使用访问时拷贝算法来替换写时拷贝算法,以解决写时拷周算法失效的问题.访问时拷贝算法的实现依赖于页面保护机制的映页机制.这样,在其他状态下,在设置页面保护时将写保护改成映页即可.新的方法在效率上比写时拷贝算法低,但是比完全拷贝的方法高出许多,特别是与lazy evaluation技术相配合时
效率会更高.由于微内核提供的写时拷贝算法是对用户透明的,即对于用户编写的任何状态下的服务器都将使用写时拷贝算法.因此,在I386体系结构下,在非用户态上运行的用户服务器有可能出错,新的算法解决了这个问题.
3 微内核计时模型
在传统 *** 作系统中,为统计出每个进程的处理机时间使用量的单元.系统计时一般是放在处理机时钟中断服务程序中.系统
IF (当前盎程处于用户态)
增加当前进程的用户奋处理机时间使用量
在每个进程结构中都没有统计进程使用处理机时间
般采用如下代码段来进行用户进程的时间统计.
ELSE
增加当前进程的系统态处理机时闻使用量
由于在传统的 *** 作系统中, *** 作系统提供的服务完全由 *** 作系统内核来完成。用户通过系统调用进入内核来取得服务.因此,采用上述方法能比较准确地统计出用户所用的处理机时间.但是,这种计时方法是一种比较粗糙的计时方法.每次时钟中断时,它就将一个固定的时间片(时钟中断周期)加入披中断的进程中,而不管该进程是否完全使用了这些处理机对向.由于这种方法实现起来非常简单,系统开销很小,几乎所有的 *** 作系绕都采用了这种方法.在新的 *** 作系统中引入了细粒度的并行执行部件—— 线程。对于线程的计时也采用了和进程相同的方法.为了取得精确的处理机时同统计精度.一些新型 *** 作系统弓『入了新的计时机制.如MACH 3.0中引^了基于时间戳的精确计时机制.在微内核体系结构下.传统的 *** 作系统功能是通过服务器的方式来实现的.服务器和用户任务一样,也作为一个进程运行.当用户进程调用 *** 作系统服务时,微内核通过消息将系统服务的参数传递给 *** 作系统服务器,由 *** 作系统服务器来完成用户请求,并将结果通过消息传递给用户进程.这样,如果采用传统的方法来进行进程的处理机时问统十。就会将 *** 作系统为用户提供服务所用的处理机时间记入服务器中.而不是用户进程中.
为了解决这个问题,我们引^了委托线程的概念,建立了新的用户进程计时模型.在客户/服务器模型中,用户通过消息请求服务器的服务,服务器接收用户的消息完成用户的请求,再通过消息将结果传给用户.在这种体系结构下,可看成用户将自己的一部分工作委托给服务器完成,服务器是在为委托线程服务.当用户线程向服务器发出请求时,将用户线程标识传递给服务器,当服务器中的某个线程处理这个请求时,将用户线程标识记^服务器线程结构中的委托线程域中.在系统时钟中断服务程序中增加为委托线程计时的代码。就可将 *** 作系统服务器为用户进程限务的时同计算到用户进程中.
IF(当前线程结构中有委托线程)
IF(当前线程赴于用户态)
增加委托线程的用户态赴理机时间使用量
ELSE
增加委托线程的系统态处理机时间使用量
在多服务器体系结构下,一个用户请求往往需要多个服务器的协同服务,如一个文件读 *** 作,需要文件服务器的服务,如果文件服务器发现数据存放在磁盘中,它就需要请求设备服务器的眼务,设备服务器实际上是在为用户线程服务.因此,在多服务器情况下,当一个服务器向另一个服务器发出请求时,必须将自己的委托线程标识号传递给目标服务器.这样, *** 作系统为一个线程提供所有服务所使用的处理机时间都将计算到用户线程中击.为了完成以上功能,必须对微内核的消息传递机制进行扩充,使用户在请求服务时能将线程的标识传递给服务器,服务器在接收消息时能接收到委托线程标识.所有这些 *** 作必须对用户透明.微内核的消息传递机制由消息发送和消息接收两部分组成.通过在这两个原语中加入以下逻辑来实现委托线程标识的发送和接收.
SEND :
IF(当前线程结构中有委托线程标识)
将委托线程标识传递出去
ELSE
将当前线程的标识传递出击
RECEIVE:
IF(当前线程是服务器)
将委托线程号放凡服务器线程结构
在发送原语中,可将委托线程标识从一个服务器传递到另一个服务器.在接收逻辑中,通过增加服务器标识的判断可以避免非服务器线程之间的偶发通讯而导致的用户线程的计时错误.
4 结论
微内核技术是当今 *** 作系统发展的最新成果.在体系结构方面,它采用了面向对象技术来描述 *** 作系统内核对象,提出并实现了基于客户服务器体系结构的 *** 作系统.在算法方面,提出了许多高教新颖的算法,如线程及处理机调度算法、写时拷贝算法、与硬件无关的存储管理算法以及精确计时算法等等.在国产微内核 *** 作系统COSIX2.0的研制过程中,通过对国外微内核技术的消化和研究,提出并实现了一些新的算法和模型,改进了系统的性能,提高了系统的可靠性,做到了有所继承,有所刨新目前,我们正在进行基于微内核的JAVA虚拟机,支持服务质量(Quality of Services)的调度系统微内核热重启(Hot Restart)技术的研究.以上内容是我们一部分研究工作的总结.
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)