框架汇总
Hadoop

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

- JobTracker:资源管理、作业管理
- TaskTracker:任务管理
- Task:负责任务执行
- Client:提交作业、查看作业运行状态
容错机制:
-
主节点故障: JobTracker故障(宕机引起):重新启动JobTracker,所有作业需要重新执行
- MapReduce 中JobTracker的单点故障是该架构设计的缺点
-
从节点故障
- TaskTracker故障(宕机引起):JobTracker不会接收到TaskTracker的“心跳“,将失败的任务调度到其他TaskTracker重新执行
- Task故障(JVM内存不够退出):TaskTracker在下一次心跳里向JobTracker汇报任务故障,JobTracker将调度该任务到其他节点重试,若任务经过最大尝试次数后仍失败,则整个作业标记为失败
- 重试的Map任务:从输入路径(HDFS)重新读入数据
- 重试的Reduce任务:重新拉取Map端的输出文件
Spark

- Cluster Manager:资源管理
- Executor:任务执行
- 本身是运行在工作节点上的一个进程,启动若干线程Task或线程组TaskSet执行任务
- Driver:启动应用程序的主方法,作业管理
Standalone模式下Spark的架构图

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

故障类型:
- Master故障:重启系统 or 借助ZooKeeper实现高可用
- Worker故障/Executor故障:重启发生故障的进程 or 将这些进程负责的任务交给新的Worker/Executor
- Driver故障:重启系统
RDD持久化、检查点

Yarn

- ResourceManager:全局资源管理、应用管理
- NodeManager:节点资源管理、任务管理
- ApplicationMaster:某个框架应用的管理
- Container:执行应用中具体任务的资源,是资源的抽象表示
容错机制
- ResourceManager故障
- 从持久化存储系统中恢复状态信息,所有应用将会重新执行
- 可部署多个RM并通过ZooKeeper协调,保证RM的高可用性
- NodeManager故障
- RM认定MM节点上所有Container运行的任务均执行失败,将失败信息告诉AM
- AM将向RM重新申请资源运行任务
- RM将分配其他节点的Container执行任务
- 若故障NM恢复,它将向RM重新注册,重置本地的状态信息
- RM认定MM节点上所有Container运行的任务均执行失败,将失败信息告诉AM
- ApplicationMaster故障:重启AM
- Container中的任务故障:重启任务
5.1 MapReduce2.0框架
MapReduce1.0 🆚 MapReduce2.0(MapReduce+Yarn)

5.2 Yarn平台运行Spark框架

ZooKeeper
ZooKeeper节点包含一组服务器(Server)用于存储ZooKeeper的数据。
服务器 Server
:都维护一份树形结构数据的备份。根据功能不同,分为三种角色:
- 领导者 Leader:服务器选定节点作为Leader,为客户端直接提供读写服务
- 追随者 Follower:仅直接提供读服务,客户端的写请求要转发给Leader
- 观察者 Observer:不参与选举Leader过程,可以没有Observer

客户端(Client)
:通过执行前述API操作ZooKeeper中维护的数据。
由于分布式计算系统普遍采用ZooKeeper进行分布式协调,所以ZooKeeper的客户端往往指这些系统中的进程。
会话(Session)
:客户端与服务器之间建立的连接。心跳和超时机制。
- 客户端启动时会与服务器建立连接,客户端会话的生命周期开始,在会话的声明周期内客户端通过心跳与服务器保持有效连接,一旦连接断开则会话结束。
- 客户端:在Znode设置Watcher,跟踪Znode上的变化
- 服务器:一旦该Znode发生变化,服务器会通知设置Watcher的客户端
容错机制
- Leader节点故障:ZooKeeper重新进行Leader选举
- Follower/Observer节点故障:该节点无法正常服务,其他节点正常,不影响ZooKeeper的服务
- 若Follower或Observer节点发生故障后重启,其可从Leader或其他节点恢复数据
典型示例:集群管理:状态管理、选主;配置更新;同步控制
Storm

- Nimbus:系统管理
- Supervisor:节点管理
- Worker:任务执行,运行一个或多个 Executor 线程
- ZooKepper:责Nimbus和Supervisor之间的所有协调工作
Storm 🆚 MapReduce1.0 🆚 standalone模式的Spark:
- 系统进程角度:三者很相似,均由主节点负责整个系统管理的进程、从节点负责该节点管理的进程and负责任务执行的进程构成。只是不同系统使用了不同的名称。
- 任务执行角度:MapReduce采用多进程执行模型,Child进程执行任务代码Task;Spark采用多线程执行模型,Task任务代码同时以工作线程的形式存在;Storm采用多线程执行模型,Executor作为工作线程,在Task中仅实现任务代码。
- 基础接口角度:MapReduce仅提供Map、Reduce两个编程接口;Spark提供基于RDD的编程接口。Storm提供Spout、Bolt两个编程接口。

流计算 🆚 批处理:
- 流计算:一次一元组;数据传输立即进行,无阻塞
- 批处理:数据传输成块进行;MapReduce和Spark的Shuffle阶段存在阻塞
容错机制
- 主节点故障:Nimbus进程故障:重启。
- 但为了保证主节点的高可用,Storm可类似MapReduce、Spark,配置一个Nimbus列表(元信息存储在所有主备Nimbus或外部可靠的分布式存储系统e.g.,HDFS),一旦主Nimbus出故障,系统就在若干备Nimbus中选一个作为新的主Nimbus。
- 从节点故障:
- Supervisor故障
- 判断该节点能否重启Supervisor,若能则重新启动;
- 若不能则启动新的Supervisor进程,原来监控的所有Worker重新调度、启动。
- Worker故障:重新启动。
- Supervisor与Worker同时故障:Nimbus命令其他节点的Supervisor启动Worker进程。
- Supervisor故障
- ZooKeeper故障:ZooKeeper本身具有容错机制,可认为该部件是可靠的。极端情况下,ZooKeeper不可用将导致Storm系统无法正常工作
Storm采用的容错策略:
- Storm将Spout发出的每条源元组(Spout Tuple)及其后续衍生的Tuple视为一颗
元组树
,若元组树中所有Tuple均由系统成功输出,则源元组得到成功处理。 - 在运行拓扑的过程中,Storm使用
ACK机制
对元组树中的Tuple进行确认,一旦元组树中某一Tuple因故障无法得到确认,则系统从Spout将源元组重放
。
—— Spout所在线程无故障的前提下,此容错策略达到至少一次的容错语义。
Mid 🆚 STid
Mid是系统定义的消息传递标识,每条消息的Mid都不同。
STid是用户定义的标识,同一元组树的STid都相同。
Spark Streaming
Spark Streaming不是一个独立的系统,而是依赖于Spark系统的实时流计算工具库。
从物理架构看,Spark Streaming和Spark相同,Spark Streaming对Driver和Executor部件进行了扩充。

- Driver:Spark Streaming对SparkContext进行扩充,构造了StreamingContext,包含用于管理流计算的元数据
- Executor: Executor中作为Receiver的某些Task,负责从外部数据源源源不断的获取流数据(这和spark批处理读取数据的方式不同)
Spark Streaming将 描述DStream转换的Operator DAG 转为 描述RDD转换的Operator DAG,交给底层的Spark批处理引擎,进而针对不断到达的小批数据生成一系列作业。
容错机制:
- Cluster Manager故障:重启或使用ZooKeeper实现高可用(本节不讨论)
- 不含Receiver的Executor故障:利用RDD Lineage进行恢复(Spark批处理引擎的容错机制)
- 含Receiver的Executor故障:利用日志进行恢复
- Receiver日志:哪些输入数据已做备份
- Driver日志:哪些输入数据已被处理
- Driver故障:利用元数据检查点进行恢复
Spark Streaming的检查点包括:数据检查点、元数据检查点。数据检查点是为了加快Executor的故障恢复;元数据检查点是为了保证Driver的故障恢复。
写检查点与写日志是同时进行的。
流计算系统的容错语义:至少一次、至多一次、准确一次。
Storm能达到至少一次的容错语义,Spark Streaming在上述容错机制上能保证准确一次。
但一个完整的流计算处理流程不仅涉及流计算系统本身,还涉及提供数据源和接收处理结果的系统,即端到端的过程
。
Flink

与Spark类似,Flink的具体架构根据是否使用Yarn资源管理系统进行系统部署,分为Standalone、Yarn两种模式;
与Spark不同,Flink没有使用Driver进行作业管理,而是JobManager负责,所以没有Client、Cluster模式之分。
Standalone模式下:
- JobManager:资源管理、作业管理。(进程名为StandaloneSessionClusterEntrypoint)
- TaskManager:资源管理、任务管理、任务执行。(进程名为TaskManagerRunner)
- Client:将用户编写的DataStream程序翻译为逻辑执行图并进行chaining优化,并将优化后的逻辑执行图提交到JobManager。 (进程名为 CliFrontend)
Yarn模式下:
- 资源管理交给:ResourceManager、NodeManager
- YarnJobClusterEntrypoint进程是基于Yarn进行Flink作业的ApplicationMaster,负责管理该作业,启动YarnTaskExecutorRunner进程执行任务。
- Client:将用户编写的DataStream程序翻译为逻辑执行图并进行chaining优化,并将优化后的逻辑执行图提交到JobManager


Flink系统将 迭代作为内部的算子嵌入DAG 实现迭代计算。迭代计算过程由系统控制。
- 对于DAG来说,整个迭代过程是一个算子,迭代算子的内部实现存在环路
MapReduce、Spark原生不支持迭代计算,迭代计算过程由用户编写的外部驱动程序控制。
- MapReduce实现迭代计算的方式:将一轮迭代计算作为一个作业提交给MapReduce系统
- Spark实现迭代计算的方式:用户编写带有循环的应用程序,由Driver控制迭代计算的执行

Flink的Pipeline 🆚 Spark的Pipeline:
- Flink的Pipeline:不同Task之间的数据传输方式
- Spark的Pipeline:Stage内部同一个Task实现多个不同算子间的数据传输方式
Spark Pipeline和Flink Chaining类似。
Task间的数据传输方式:
阻塞式数据传输
:上游Task处理完所有数据,将结果写入磁盘,才会发送数据给下游Task或被其读取- MapReduce中Map和Reduce任务间的 shuffle
- Spark中不同Stage的任务间的 shuffle
非阻塞式数据传输
:上游Task处理一部分数据,将结果放在缓存,就发送数据给下游Task或被其读取- Storm的消息传递机制:一次传输一条记录
- Flink的Pipeline机制:一次传输一个缓冲区
容错机制
- JobManager故障:导致系统无法正常工作,重启/借助ZooKeeper实现高可用
- TaskManager故障:导致部分计算任务失败,重启TaskManager/将故障TaskManager负责执行的任务交给新的TaskManager
- 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任务间不会进行数据传输。

容错机制
- Master故障:意味着主控节点丢失,整个作业将失败
- Worker故障:该Worker维护的计算信息丢失。
- 设置检查点:用户设置写检查点的间隔(每隔多少超步写检查点)
本文作者:Joey-Wang
本文链接:https://www.cnblogs.com/joey-wang/p/15789788.html
版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 【.NET】调用本地 Deepseek 模型
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库