云盘算与大数据条记之Spark【重点:流水线机制】

打印 上一主题 下一主题

主题 555|帖子 555|积分 1665

图片和部分条记来自于厦门大学-林子雨-大数据技术原理与应用(第3版) 配套PPT

三大分布式盘算体系开源项目Hadoop、Spark、Storm

Storm、Hadoop和Spark都是处置惩罚大数据的框架,但它们各自在计划上有着不同的侧重点,这导致了它们在实际应用中的不同定位。
Hadoop

   

  • 主要组件:Hadoop Distributed File System (HDFS) 和 MapReduce。
  • 计划理念:主要针对的是大规模数据集的批处置惩罚
  • 使用场景:适用于那些不需要实时处置惩罚的场景,比如大数据的存储、离线分析等。
  • 长处:稳定、成熟,生态体系丰富。
  Spark

   

  • 主要组件:Spark Core, Spark SQL, Spark Streaming, MLlib(呆板学习)和GraphX(图盘算)。
  • 计划理念:相较于Hadoop的MapReduce,Spark更加机动,可以举行批处置惩罚、交互式查询、实时分析、呆板学习和图处置惩罚。
  • 使用场景:适用于需要快速迭代数据处置惩罚使命的场景,包括实时处置惩罚和批处置惩罚。
  • 长处:速率快(在内存盘算),API丰富,可以用于多种数据处置惩罚需求。
  Storm

   

  • 主要组件:主要是其流式盘算模型。
  • 计划理念Storm专注于实时数据流的处置惩罚
  • 使用场景:适用于需要对数据流举行实时处置惩罚和分析的场景,比如实时广告投放、复杂事件处置惩罚等。
  • 长处:实时性强,可以实现低延迟的数据处置惩罚。
  为什么Storm的教学资源不如Hadoop和Spark?

   

  • 市场占有率和盛行度:Hadoop和Spark由于其通用性和广泛的应用场景,拥有更大的用户基础和社区支持。这导致更多的教育资源和开发者关注。
  • 使用场景限制:Storm专注于实时数据流处置惩罚,这是一个相对更专业和细分的领域。相较之下,Hadoop和Spark的使用场景更广泛,涵盖了批处置惩罚和实时处置惩罚等多种需求。
  • 技术发展:随着时间的推移,一些新的实时处置惩罚框架和技术(如Apache Flink)的鼓起,大概在某些方面超越了Storm,导致社区和开发者的关注点转移。
  • 学习曲线:实时数据流处置惩罚涉及的概念和模型大概对于新手来说比力复杂,这大概导致相对较少的入门级或初学者友好的教学资源。
  只管Storm在某些特定的实时处置惩罚场景中非常有效,但它的使用场景相比Hadoop和Spark来说更加专一,这大概是它教学资源相对较少的一个缘故原由。然而,对于需要处置惩罚实时数据流的应用场所,Storm仍旧是一个非常强大和有价值的工具。

Spark条记简介



Spark的计划遵循“一个软件栈满足不同应用场景”的理念,逐渐形成了一套完备的生态体系:


  • 既能够提供内存盘算框架,也可以支持SQL即时查询、实时流式盘算、呆板学习和图盘算等。
  • Spark可以部署在资源管理器YARN之上,提供一站式的大数据解决方案。
因此,Spark所提供的生态体系足以应对上述三种场景,即同时支持批处置惩罚、交互式查询和流数据处置惩罚。


Spark线程并行与MR进程并行

进程并行(MapReduce)

MapReduce 是 Hadoop 的盘算框架,计划用于大规模数据处置惩罚。它的核心是将盘算使命分解为两个阶段:Map(映射)和 Reduce(归约)。每个阶段可以在不同的数据块上独立并行运行,通常是在不同的呆板上。
   

  • 进程:在利用体系中,一个进程是运行中步伐的一个实例,拥有独立的内存空间。MapReduce 更侧重于进程并行,意味着它依靠于启动多个独立的进程,每个进程处置惩罚数据的一个子集。这些进程可以分布在一个分布式体系的不同呆板上。
  线程并行(Spark)

Spark 是一种内存盘算框架,用于大规模数据处置惩罚,能够举行批处置惩罚、流处置惩罚、呆板学习等。Spark 的计划答应它在内存中处置惩罚数据,从而比基于磁盘的MapReduce更快。
   

  • 线程:线程是进程中的一个实际实行单元,共享进程的内存空间。线程并行,或在Spark中的使命并行,是指在单个或多个进程内并行运行多个线程,这些线程可以共享相同的数据和内存空间
  • 资源共享:由于线程之间可以共享内存,Spark 可以更有效地使用体系资源,减少数据在不同使命或作业间的移动和复制。
  深度对比

   

  • 资源隔离性进程间内存是隔离的,这提供了较好的容错性,但增长了数据处置惩罚的开销线程共享内存,虽然进步了服从,但在处置惩罚隔离性和错误恢复方面大概更复杂
  • 并发模型MapReduce 的并发模型基于进程,每个使命运行在独立的JVM(Java虚拟机)进程中,这简化了编程模型,但大概增长了开销Spark 通过在同一JVM进程中并行运行多个使命(线程并行)来减少这种开销,使得数据处置惩罚更快,特殊是在需要频繁读写数据的应用中。
  • 性能:Spark通常比MapReduce更快,缘故原由是它的内存盘算能力和更高效的使命调度。MapReduce适用于大规模的数据批处置惩罚,而Spark则支持快速的迭代盘算,更适合于需要复杂数据处置惩罚的使命。
  Spark实行模型

在Spark中,实行盘算的基本单元是Task,而Task在运行时实际上是作为线程在Executor进程中实行的。这是Spark实行模型的一个核心构成部分,与MapReduce的实行模型形成鲜明对比,后者在Hadoop中通常是以进程为单元举行使命的分配和实行。下面是Spark中关于Executor和Task的一些关键点:
Executor

   

  • Executor定义:在Spark中,Executor是一个运行在集群节点上的进程,负责实行Spark作业中的使命。每个Executor进程可以同时运行多个使命。
  • 内存和资源共享:由于Executor是以进程情势存在的,它为运行在其上的使命提供了共享内存和资源。这使得使命之间能够高效地共享数据,低落了数据交换和通信的开销,特殊是在实行需要频繁数据交换的利用(如Shuffle)时。
  Task

   

  • Task定义:Task是Spark中实行的最小工作单元,每个Task对应于数据集(如RDD)的一个分区,由Executor中的一个线程实行。
  • 线程并行:在单个Executor进程内部,多个Task可以并行实行,由于它们是作为线程运行的。这种并行性的级别由Executor分配给它的核心数决定。【下文将详解】
  实行模型的含义

   

  • 服从和性能:通过答应在单个Executor进程中并行实行多个Task,Spark能够更有效地使用盘算资源,减少使命启动的延迟,进步了数据处置惩罚的速率。
  • 使命调度和资源管理:Spark的这种实行模型也意味着其使命调度和资源管理机制比基于进程的模型更为复杂。Spark需要在保证实行服从的同时,也要管理好资源分配、使命之间的依靠关系以及错误恢复机制。
  
宽依靠、窄依靠与流水线

在Spark中,“流水线”优化,也被称为管道化实行,是一种优化技术,它答应在大概的情况下,将多个利用合并到单个阶段中顺序实行,从而减少盘算过程中的开销。这种优化主要适用于窄依靠的情况。为了明白这一点,首先需要区分Spark中的两种依靠范例:窄依靠和宽依靠。

窄依靠

在窄依靠中,每个父分区被一个或少数子分区所依靠,这意味着父RDD的每个分区只需要为一个子RDD的少数分区(通常是一个)提供数据。这种依靠关系答应Spark在不同的转换利用之间实现流水线优化,由于这些利用可以在不举行额外shuffle的情况下连续实行
流水线优化:在窄依靠的情况下,Spark可以将多个转换利用(如map、filter等)合并成一个使命连续实行,而不需要在每个利用之间写入磁盘或举行网络传输。这类似于在生产线上,一个产品可以从一个加工步骤直接进入下一个步骤,而不需要回到仓库中等待。这种优化减少了I/O开销,进步了实行服从。
宽依靠

在宽依靠中,父RDD的每个分区大概会被多个子分区所依靠,通常在这种依靠关系中,需要对数据举行重新构造(比方,通过shuffle利用),以确保每个子分区可以获取到它需要处置惩罚的全部数据。宽依靠通常出现在groupBy、reduceByKey等利用中,这些利用需要将不同分区的数据集中到一起处置惩罚。
无法实现流水线优化宽依靠涉及到的shuffle利用需要将数据从一个阶段的使命输出到另一个阶段的使命输入,这个过程需要写磁盘和网络传输,导致无法像窄依靠那样直接在内存中流水线实行多个利用。每次shuffle利用都大概成为数据处置惩罚的瓶颈,由于它涉及到磁盘I/O和网络I/O,明显增长了盘算的开销
明白流水线

明白Spark中的“流水线”优化,可以想象一个装配线,其中产品(数据)在装配线上移动时,可以不间断地颠末多个工作站(利用)举行加工。在窄依靠的场景下,数据可以顺畅地流过多个利用,每个利用像装配线上的一个工作站,接连不绝地对数据举行加工。但在宽依靠的场景下,数据需要颠末一个重组的过程(类似于中断了装配线,将产品重新分配到不同的线上),这个过程会打断流水线的连续性,造成额外的开销
通过这种方式,Spark尽大概地在内存中处置惩罚数据,减少了对磁盘的依靠,进步了整个数据处置惩罚流程的服从。

Executor流水线与CPU流水线

   前置知识:在Spark中,使命(Task)的资源使用情况既不完满是集中式的,也不是每个Task都有完全独立的资源槽。实际上,它采用的是一种中间态——资源在Executor级别被分配,而在这些Executor内部,多个Task共享这些资源
  在Spark中,流水线实行主要指的是将多个数据处置惩罚利用(如map、filter等)在同一个使命(Task)中无缝地串联起来,以减少数据移动和中间存储的开销。这种优化在窄依靠的利用中特殊有效,由于这些利用不需要重组(shuffle)数据就能在上鄙俚RDD之间顺畅地传递。
单核Executor中的Task实行

在单核Executor的情况下,由于只有一个CPU核心可用,Executor一次只能实行一个Task。这意味着在任何给定时候,Executor都在处置惩罚单个Task上的利用。这里的“流水线”实际上是指在这个单个Task中,多个数据处置惩罚利用可以连续实行,而不是多个Task同时实行。
   
每个Task将会按顺序实行,完成一个Task的全部利用后,才会开始实行下一个Task。

  流水线的实现机制

在Spark的流水线机制中,数据在内存中从一个利用传递到下一个利用,这些利用都是在单个Task的上下文中顺序实行的。比方,一个map利用背面紧跟一个filter利用,Spark会尽量将这两个利用合并在同一个Task中顺序实行,而无需将map利用的结果写入磁盘或举行网络传输等待filter利用处置惩罚。
与CPU流水线的对比

CPU流水线依靠于CPU内部的多个物理单元同时工作,即使是单核CPU也拥有多个如许的单元,每个单元负责不同的处置惩罚阶段。因此,在某一时候,第一个指令大概在实行阶段,而第二个指令已经在取指或译码阶段了。如许的并行处置惩罚大大进步了CPU的实行服从。
单核Executor无法同时开始实行另一个Task。这意味着,不同Task之间的利用无法像CPU流水线中的指令那样重叠实行。 
   

  • 物理并行性单核CPU的流水线通过使用CPU内部的多个物理单元(用于不同指令实行阶段)来实现并行性,即使在单核心情况下也能同时处置惩罚多个指令的不同部分。这种并行性是创建在硬件层面上的
  • 软件并行性限制:相比之下,Spark中的单核Executor受限于单个CPU核心,无法同时实行多个Task。其并行性主要是通过多个Executor(大概在不同的物理或虚拟机上)来实现的,而不是在单个Executor内部。
  
想想就行啦,现在很少有单核Executor啦!

Spark的计划和广泛应用确实受益于当代硬件发展的几个关键趋势,特殊是内存容量的增长和多核处置惩罚器的普及。这些硬件进步为Spark提供了理想的运行情况,使其能够有效地处置惩罚大规模数据集,并充分使用内存盘算来进步性能。
多核Executor的优势

   

  • 并行处置惩罚能力多核Executor可以同时实行多个使命(Task),这明显进步了数据处置惩罚的并行度和整体作业的实行服从。
  • 内存使用率:Spark使用了内存盘算的优势,能够在处置惩罚大数据集时减少对磁盘I/O的依靠。多核Executor能够更高效地使用其分配的内存资源,加速数据处置惩罚和分析使命。
  • 资源设置的机动性:在集群管理器(如Apache YARN、Mesos或Spark自身的Standalone模式)的资助下,Spark答应机动地设置Executor的数目、每个Executor的内核数以及内存巨细,以顺应不同的数据处置惩罚需求和优化性能。
  企业情况中的应用

在实际的企业情况中,使用多核Executor已经成为常态,主要缘故原由包括:
   

  • 硬件资源的可用性:随着多核处置惩罚器成为尺度设置,企业拥有的盘算资源普遍支持并行处置惩罚。
  • 性能要求:大数据应用和实时数据处置惩罚需求的增长,驱动企业优化资源设置以实现更快的数据处置惩罚速率。
  • 本钱服从:合理设置的多核Executor可以进步资源的使用率,从而低落运行本钱。
  
多核CPU是怎么实行指令的呢?每个核照旧用流水线吗?

是的,多核CPU中的每个核心仍旧使用流水线技术来实行指令,以进步服从和处置惩罚速率。多核CPU的计划答应同时并行处置惩罚多个盘算使命,而每个核心内部的流水线则进一步进步了单个核心处置惩罚指令的能力。如许,多核CPU结合了两个层面的并行处置惩罚能力:核心间的并行性和核心内的流水线并行性。
多核CPU的工作原理

   

  • 核心间并行:多核CPU有多个处置惩罚核心,每个核心可以独立实行不同的使命或线程。这意味着,假如一个步伐能够被分解为多个可以并行实行的部分,那么多核CPU可以明显进步这个步伐的实行速率。
  • 核心内流水线:只管每个核心可以独立实行使命,每个核心内部照旧采用了流水线技术来实行单个使掷中的指令。流水线技术将指令实行过程分解为多个阶段,如取指、译码、实行、访存和写回等。通过在不同阶段并行处置惩罚多个指令,每个核心的处置惩罚速率得到了提升。
  流水线的效益

流水线技术能够明显进步处置惩罚速率的缘故原由在于其能够减少处置惩罚器空闲的时间。在没有流水线的情况下,CPU在实行一个指令的不同阶段时,其他部分大概处于空闲状态。而流水线答应后续指令在前一个指令完成其第一阶段后立即进入处置惩罚器开始其第一阶段的处置惩罚,如许就几乎可以同时在不同阶段处置惩罚多个指令。
多核与流水线的结合

多核处置惩罚器与流水线技术的结合,为当代盘算使命提供了极高的处置惩罚能力。多核提供了在不同核心上并行实行多个使命的能力,而每个核心内的流水线则确保了每个核心在实行单个使命时能够高效使用其内部资源。这种计划使得多核处置惩罚器非常适合实行多线程步伐和并行盘算密集型应用。
在实际应用中,如何充分使用多核处置惩罚器的能力取决于软件的并行化计划,包括利用体系的调度策略、步伐的多线程计划以及应用的并行算法等。精确的并行化计划和优化可以明显进步步伐在多核处置惩罚器上的实行服从。

作者总结(一)

以是Executor和CPU的流水线照旧不一样,前者是串行流水线,后者是并行流水线。而在多核情况下,Executor是并行流水线并且线程之间相互独立,CPU是并行中的并行流水线,第一个并行是多核之间相互独立,第二个并行是CPU流水线带来的不是完全意义上的逻辑并行。
Executor的流水线(在Spark中)

   

  • 串行流水线:在单核Executor的情况下,虽然使命(Task)内部可以实现利用的流水线实行(比方,将多个map或filter利用顺序实行而不需要中间存储),但由于只有一个核心,这些使命必须串行实行。因此,这种情况下的流水线是串行的,一个使命完成全部利用后,另一个使命才能开始。
  • 并行流水线:在多核Executor的情况下,可以同时实行多个使命,每个使命在各自的线程上运行,线程之间相互独立。这提供了一种并行流水线,每个核心(或线程)可以独立地实行自己的使命流水线。
  CPU的流水线

   

  • 并行中的并行:CPU的流水线技术答应在单个核心内部并行处置惩罚多个指令的不同阶段。当结合多核处置惩罚器时,这种并行性被扩展到了更高的层面,每个核心可以独立处置惩罚不同的使命或线程,而每个核心内部的流水线则进一步进步了其处置惩罚指令的服从。因此,多核CPU实现了两层面的并行:多核之间的并行处置惩罚不同的使命,以及核心内部通过流水线技术并行处置惩罚指令的不同阶段。
  
作者总结(二)

   其实说到底照旧一个Stage中的Task比指令复杂的多,导致其不能让Executor中的集中式共享资源按照每一个SubTask去分配物理资源,这应该是最根本的缘故原由。
  复杂性的来源


  • 使命的粒度:Spark中的一个Task通常包罗对数据集的一系列利用,这些利用大概涉及复杂的数据处置惩罚逻辑,如数据转换、聚合或毗连等。相比之下,CPU的一个指令通常实行非常详细和原子化的利用,如加法、乘法或者数据移动等。Task的高级抽象和利用的复杂性导致其无法像指令那样被精致地拆分和流水线处置惩罚。
  • 资源共享与调度:在Spark中,只管多个Task可以在多核Executor上并行实行,但这些Task共享Executor的资源(如内存和CPU)。资源的共享和调度需要在软件层面上举行管理,以确保每个Task的实行服从和整体作业的性能。而CPU内部的资源(如寄存器、算术逻辑单元等)在计划时就思量了流水线并行,每个指令的不同阶段可以使用这些硬件资源举行高效实行。
根本缘故原由



  • 实行单元的不同:Spark的实行单元是Task,它在逻辑上代表了对数据集一部分的一系列复杂利用。而CPU的实行单元是指令,它是硬件层面的原子利用。这种在实行单元粒度上的根本差异导致了并行处置惩罚和资源分配策略的不同。
  • 并行处置惩罚机制Spark的并行处置惩罚侧重于在软件层面上通过多线程和多核心处置惩罚器实现数据处置惩罚使命的并行。而CPU的并行处置惩罚机制是通过硬件计划,特殊是流水线和多核技术,来在指令级别实现并行。
  • 资源分配与管理:在Spark中,对物理资源的分配和管理是由使命调度器和实行器在软件层面上完成的,思量到使命的复杂性和资源共享的需求。CPU则通过硬件级别的计划来优化资源的使用,实现高效的流水线并行处置惩罚。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

熊熊出没

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表