曾经沧海难为水,除却巫山不是云。|

Joey-Wang

园龄:4年2个月粉丝:17关注:0

框架汇总

Hadoop

image-20211227012404862

各组件功能:

  1. NameNode:元数据管理、DataNode定位
  2. Secondary NameNode:充当NameNode的备份
  3. DataNode:数据块存储

容错机制:

  1. NameNode 故障:利用 Secondary NameNode 的FsImage和Editlog恢复,会丢失 Editlog.new 中的信息
  2. Secondary NameNode 故障:HDFS仍可对外服务,但无法应对 NameNode 故障
  3. DataNode 故障:
    • 节点上的所有数据都被标记为“不可读”
    • 定期检查备份因子:NameNode定期检查DataNode心跳,若DataNode发生宕机,会造成部分文件块副本数目<设定的副本数目,系统需在其他DataNode上对这些文件块进行备份以达到预定的副本数目。

MapReduce

image-20211227202509537
  1. JobTracker:资源管理、作业管理
  2. TaskTracker:任务管理
  3. Task:负责任务执行
  4. Client:提交作业、查看作业运行状态

容错机制:

  1. 主节点故障: JobTracker故障(宕机引起):重新启动JobTracker,所有作业需要重新执行

    • MapReduce 中JobTracker的单点故障是该架构设计的缺点
  2. 从节点故障

    • TaskTracker故障(宕机引起):JobTracker不会接收到TaskTracker的“心跳“,将失败的任务调度到其他TaskTracker重新执行
    • Task故障(JVM内存不够退出):TaskTracker在下一次心跳里向JobTracker汇报任务故障,JobTracker将调度该任务到其他节点重试,若任务经过最大尝试次数后仍失败,则整个作业标记为失败
      • 重试的Map任务:从输入路径(HDFS)重新读入数据
      • 重试的Reduce任务:重新拉取Map端的输出文件

Spark

image-20211228014503682
  1. Cluster Manager:资源管理
  2. Executor:任务执行
    • 本身是运行在工作节点上的一个进程,启动若干线程Task或线程组TaskSet执行任务
  3. Driver:启动应用程序的主方法,作业管理

Standalone模式下Spark的架构图

image-20211228021104536

Standalone中的Driver:

  • Client方式:Driver和客户端同一个进程
  • Cluster方式:系统将由某一Worker启动一个进程作为Driver(DriverWrapper)
image-20211228023113797

故障类型:

  1. Master故障:重启系统 or 借助ZooKeeper实现高可用
  2. Worker故障/Executor故障:重启发生故障的进程 or 将这些进程负责的任务交给新的Worker/Executor
  3. Driver故障:重启系统

RDD持久化、检查点

image-20211228024832947

Yarn

image-20211228053845769
  1. ResourceManager:全局资源管理、应用管理
  2. NodeManager:节点资源管理、任务管理
  3. ApplicationMaster:某个框架应用的管理
  4. Container:执行应用中具体任务的资源,是资源的抽象表示

容错机制

  1. ResourceManager故障
    • 从持久化存储系统中恢复状态信息,所有应用将会重新执行
    • 可部署多个RM并通过ZooKeeper协调,保证RM的高可用性
  2. NodeManager故障
    • RM认定MM节点上所有Container运行的任务均执行失败,将失败信息告诉AM
      • AM将向RM重新申请资源运行任务
      • RM将分配其他节点的Container执行任务
    • 若故障NM恢复,它将向RM重新注册,重置本地的状态信息
  3. ApplicationMaster故障:重启AM
  4. Container中的任务故障:重启任务

5.1 MapReduce2.0框架

MapReduce1.0 🆚 MapReduce2.0(MapReduce+Yarn)

image-20211228061722008

5.2 Yarn平台运行Spark框架

image-20211228064701247

ZooKeeper

ZooKeeper节点包含一组服务器(Server)用于存储ZooKeeper的数据。

服务器 Server:都维护一份树形结构数据的备份。根据功能不同,分为三种角色:

  • 领导者 Leader:服务器选定节点作为Leader,为客户端直接提供读写服务
  • 追随者 Follower:仅直接提供读服务,客户端的写请求要转发给Leader
  • 观察者 Observer:不参与选举Leader过程,可以没有Observer
image-20211228184917993

客户端(Client):通过执行前述API操作ZooKeeper中维护的数据。

由于分布式计算系统普遍采用ZooKeeper进行分布式协调,所以ZooKeeper的客户端往往指这些系统中的进程。

会话(Session):客户端与服务器之间建立的连接。心跳和超时机制。

  • 客户端启动时会与服务器建立连接,客户端会话的生命周期开始,在会话的声明周期内客户端通过心跳与服务器保持有效连接,一旦连接断开则会话结束。
  • 客户端:在Znode设置Watcher,跟踪Znode上的变化
  • 服务器:一旦该Znode发生变化,服务器会通知设置Watcher的客户端

容错机制

  1. Leader节点故障:ZooKeeper重新进行Leader选举
  2. Follower/Observer节点故障:该节点无法正常服务,其他节点正常,不影响ZooKeeper的服务
    • 若Follower或Observer节点发生故障后重启,其可从Leader或其他节点恢复数据

典型示例:集群管理:状态管理、选主;配置更新;同步控制

Storm

image-20211228230635868
  1. Nimbus:系统管理
  2. Supervisor:节点管理
  3. Worker:任务执行,运行一个或多个 Executor 线程
  4. ZooKepper:责Nimbus和Supervisor之间的所有协调工作

Storm 🆚 MapReduce1.0 🆚 standalone模式的Spark:

  1. 系统进程角度:三者很相似,均由主节点负责整个系统管理的进程、从节点负责该节点管理的进程and负责任务执行的进程构成。只是不同系统使用了不同的名称。
  2. 任务执行角度:MapReduce采用多进程执行模型,Child进程执行任务代码Task;Spark采用多线程执行模型,Task任务代码同时以工作线程的形式存在;Storm采用多线程执行模型,Executor作为工作线程,在Task中仅实现任务代码。
  3. 基础接口角度:MapReduce仅提供Map、Reduce两个编程接口;Spark提供基于RDD的编程接口。Storm提供Spout、Bolt两个编程接口。
image-20211228231519759

流计算 🆚 批处理:

  1. 流计算:一次一元组;数据传输立即进行,无阻塞
  2. 批处理:数据传输成块进行;MapReduce和Spark的Shuffle阶段存在阻塞

容错机制

  1. 主节点故障:Nimbus进程故障:重启。
    • 但为了保证主节点的高可用,Storm可类似MapReduce、Spark,配置一个Nimbus列表(元信息存储在所有主备Nimbus或外部可靠的分布式存储系统e.g.,HDFS),一旦主Nimbus出故障,系统就在若干备Nimbus中选一个作为新的主Nimbus。
  2. 从节点故障:
    • Supervisor故障
      • 判断该节点能否重启Supervisor,若能则重新启动;
      • 若不能则启动新的Supervisor进程,原来监控的所有Worker重新调度、启动。
    • Worker故障:重新启动。
    • Supervisor与Worker同时故障:Nimbus命令其他节点的Supervisor启动Worker进程。
  3. ZooKeeper故障:ZooKeeper本身具有容错机制,可认为该部件是可靠的。极端情况下,ZooKeeper不可用将导致Storm系统无法正常工作

Storm采用的容错策略:

  1. Storm将Spout发出的每条源元组(Spout Tuple)及其后续衍生的Tuple视为一颗元组树,若元组树中所有Tuple均由系统成功输出,则源元组得到成功处理。
  2. 在运行拓扑的过程中,Storm使用ACK机制对元组树中的Tuple进行确认,一旦元组树中某一Tuple因故障无法得到确认,则系统从Spout将源元组重放

—— Spout所在线程无故障的前提下,此容错策略达到至少一次的容错语义。

Mid 🆚 STid

Mid是系统定义的消息传递标识,每条消息的Mid都不同。
STid是用户定义的标识,同一元组树的STid都相同。

Spark Streaming

Spark Streaming不是一个独立的系统,而是依赖于Spark系统的实时流计算工具库。

从物理架构看,Spark Streaming和Spark相同,Spark Streaming对Driver和Executor部件进行了扩充。

image-20211229045100081
  • Driver:Spark Streaming对SparkContext进行扩充,构造了StreamingContext,包含用于管理流计算的元数据
  • Executor: Executor中作为Receiver的某些Task,负责从外部数据源源源不断的获取流数据(这和spark批处理读取数据的方式不同)

Spark Streaming将 描述DStream转换的Operator DAG 转为 描述RDD转换的Operator DAG,交给底层的Spark批处理引擎,进而针对不断到达的小批数据生成一系列作业。

容错机制:

  1. Cluster Manager故障:重启或使用ZooKeeper实现高可用(本节不讨论)
  2. 不含Receiver的Executor故障:利用RDD Lineage进行恢复(Spark批处理引擎的容错机制
  3. 含Receiver的Executor故障:利用日志进行恢复
    • Receiver日志:哪些输入数据已做备份
    • Driver日志:哪些输入数据已被处理
  4. Driver故障:利用元数据检查点进行恢复

Spark Streaming的检查点包括:数据检查点、元数据检查点。数据检查点是为了加快Executor的故障恢复;元数据检查点是为了保证Driver的故障恢复。

写检查点与写日志是同时进行的。

流计算系统的容错语义:至少一次、至多一次、准确一次。

Storm能达到至少一次的容错语义,Spark Streaming在上述容错机制上能保证准确一次。

但一个完整的流计算处理流程不仅涉及流计算系统本身,还涉及提供数据源和接收处理结果的系统,即端到端的过程

image-20211230015726529

与Spark类似,Flink的具体架构根据是否使用Yarn资源管理系统进行系统部署,分为Standalone、Yarn两种模式;
与Spark不同,Flink没有使用Driver进行作业管理,而是JobManager负责,所以没有Client、Cluster模式之分。

Standalone模式下:

  1. JobManager:资源管理、作业管理。(进程名为StandaloneSessionClusterEntrypoint)
  2. TaskManager:资源管理、任务管理、任务执行。(进程名为TaskManagerRunner)
  3. Client:将用户编写的DataStream程序翻译为逻辑执行图并进行chaining优化,并将优化后的逻辑执行图提交到JobManager。 (进程名为 CliFrontend)

Yarn模式下:

  1. 资源管理交给:ResourceManager、NodeManager
  2. YarnJobClusterEntrypoint进程是基于Yarn进行Flink作业的ApplicationMaster,负责管理该作业,启动YarnTaskExecutorRunner进程执行任务。
  3. Client:将用户编写的DataStream程序翻译为逻辑执行图并进行chaining优化,并将优化后的逻辑执行图提交到JobManager
image-20211230022742210
image-20211230022825395

Flink系统将 迭代作为内部的算子嵌入DAG 实现迭代计算。迭代计算过程由系统控制。

  • 对于DAG来说,整个迭代过程是一个算子,迭代算子的内部实现存在环路

MapReduce、Spark原生不支持迭代计算,迭代计算过程由用户编写的外部驱动程序控制。

  • MapReduce实现迭代计算的方式:将一轮迭代计算作为一个作业提交给MapReduce系统
  • Spark实现迭代计算的方式:用户编写带有循环的应用程序,由Driver控制迭代计算的执行
image-20211230013408240

Flink的Pipeline 🆚 Spark的Pipeline:

  • Flink的Pipeline:不同Task之间的数据传输方式
  • Spark的Pipeline:Stage内部同一个Task实现多个不同算子间的数据传输方式

Spark Pipeline和Flink Chaining类似。

Task间的数据传输方式:

  1. 阻塞式数据传输:上游Task处理完所有数据,将结果写入磁盘,才会发送数据给下游Task或被其读取
    • MapReduce中Map和Reduce任务间的 shuffle
    • Spark中不同Stage的任务间的 shuffle
  2. 非阻塞式数据传输:上游Task处理一部分数据,将结果放在缓存,就发送数据给下游Task或被其读取
    • Storm的消息传递机制:一次传输一条记录
    • Flink的Pipeline机制:一次传输一个缓冲区

容错机制

  1. JobManager故障:导致系统无法正常工作,重启/借助ZooKeeper实现高可用
  2. TaskManager故障:导致部分计算任务失败,重启TaskManager/将故障TaskManager负责执行的任务交给新的TaskManager
  3. Client故障:只要作业成功提交给系统,并不影响系统中作业的运行

Giraph

Giraph参考了Pregel体系架构,但在实现时借用了MapReduce框架启动Master和Worker这些进程。

  • Giraph并没有像普通MapReduce程序那样编写Map和Reduce方法,而是将所有的图处理逻辑都在启动Map任务的run方法中实现
  • 从MapReduce框架的角度来看,执行Giraph作业仅启动了Map任务,在这些Map中有一个作为Giraph的Master,其余作为Worker。——使用ZooKeeper的协调服务功能进行分布式选主(Zookeeper还能实现BSP模型的栅栏同步功能)

⚠️ Worker之间可相互传输数据,MapReduce中Map任务间不会进行数据传输。

image-20211230064641769

容错机制

  1. Master故障:意味着主控节点丢失,整个作业将失败
  2. Worker故障:该Worker维护的计算信息丢失。
    • 设置检查点:用户设置写检查点的间隔(每隔多少超步写检查点)

本文作者:Joey-Wang

本文链接:https://www.cnblogs.com/joey-wang/p/15789788.html

版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。

posted @   Joey-Wang  阅读(108)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 【.NET】调用本地 Deepseek 模型
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
点击右上角即可分享
微信分享提示
评论
收藏
关注
推荐
深色
回顶
展开