分布式大数据系统概览（HDFS/MapReduce/Spark/Yarn/Zookeeper/Storm/SparkStreaming/Lambda/DataFlow/Flink/Giraph）

Posted 2022-12-22

分布式大数据处理系统概览（三）

  本博文主要对现如今分布式大数据处理系统进行概括整理，相关课程为华东师范大学数据科学与工程学院《大数据处理系统》，参考​​大夏学堂​​，下面主要整理HDFS/MapReduce/Spark/Yarn/Zookeeper/Storm/SparkStreaming/Lambda/DataFlow/Flink/Giraph有关的内容。

---

分布式大数据处理系统大纲

• 分布式大数据处理系统概览（一）：​​HDFS/MapReduce/Spark​​
• 分布式大数据处理系统概览（二）：​​Yarn/Zookeeper​​
• 分布式大数据处理系统概览（三）：​​Storm/SparkStreaming​​
• 分布式大数据处理系统概览（四）：​​Lambda/DataFlow/Flink/Giraph​​

---

8 流计算系统Storm

8.1 Storm设计模式：

（1）Storm流数据的特征：
# 数据快速持续到达；
# 数据来源众多，格式复杂；
# 数据量大；
# 注重数据整体价值；
# 数据顺序颠倒，或不完整，系统无法控制将要处理新到达的数据元素的顺序
（2）Storm数据类型：Tuple元组，逻辑上看类似于关系数据库中的一行记录；
（3）Storm逻辑计算类型：Topology流转换图，任务的抽象概念：
# 顶点：Spout或Bolt表示计算组件；Spout表示源头，从外部数据中读取数据，封装成tuple；Bolt描述流转换过程，将处理后的tuple转发给其他Bolt
# 边：表示数据流向（数据从上一个组件流向下一个组件）

8.2 Storm系统架构

（1）Nimbus：主节点，负责分发代码，分配任务，检测故障，是调度中心；

（2）Supervisor：从节点，负责执行任务，

（3）Work：任务执行进程，一个从节点可拥有一个或多个Work；

（4）Zookeeper：负责主从节点之间的协调工作；

（5）executor：产生于Work进程内部的线程，可以执行同一个组件中一个或多个任务

8.3 Storm运行流程：

（1）用户编写Topology程序，经过序列化，打包提交给主节点；
（2）主节点创建一个配置信息，并写入Znode中；
（3）所有从节点监听Znode，获得所在节点所需执行的任务；
（4）从节点从主节点处拉取可执行代码，并启动若干work进程；
（5）work进程根据zookeeper获取的配置信息，启动若干线程，执行Spolt和Bolt所描述的task任务

8.4 Storm Grouping策略：Spout和Bolt之间，或者不同的Bolt之间的Tuple传输表现为属于上游组件的task和属于下游组件的task之间的Tuple传输。Grouping策略解决两个组件之间如何进行tuple传输：

8.4 Storm容错：

（1）元组树：Spout发射的每一个tuple，会被后续的Bolt进行处理，编号记为Spout-Tuple-id。每一个tuple可抽象为一个树；

（2）元组树的Tuple的传输表现为不同组件之间task的消息传递，每一个消息传递编号记为Message-id；

（3）ACK机制：

# acker：一个单独的线程，来追踪tuple的处理过程。acker线程数量可以设置。

# 上游组件的Task发射消息的同时，会向Acker报告Message-id及Spout-Tuple-id；当下游组件的Task接收到消息时向Acker报告Message-id及Spout-Tuple-id

# 每一个Tuple在Spout中生成的时候,都会分配到一个64位的message-Id。通过对message-Id进行哈希我们可以执行要对哪个acker线程发送消息来通知它监听这个Tuple。acker线程收到消息后,会将发出消息的Spout和那个message-Id绑定起来。然后开始跟踪该tuple的处理流程。如果这个tuple全部都处理完，那么acker线程就会调用发起这个tuple的那个spout实例的ack()方法。如果超过一定时间这个tuple还没处理完，那么acker线程就会调用对应spout的fail()方法,通知spout消息处理失败。spout组件就可以重新发送这个tuple（可能会导致消息重复）。

# acker数据结构及原理（STid指Spout-Tuple-id，保持不变，Mid指Message-id，ack_val表示当前的状态值）：

9 流计算系统Spark Streaming

9.1 Spark Streaming

（1）数据模型：

# Storm中将流数据视为一系列连续的元组；Spark Streaming将连续的流数据切片（离散化），生成一系列小块数据

# 根据用户指定的时间间隔对数据进行切割

# Stream维护一系列的RDD信息

（2）逻辑计算模型：OperateDAG以及DStream LIneage机制

（3）物理计算模型：

（4）Spark Streaming架构

# Driver：构造StreamingContext用于管理流计算的元数据；

# Executor：执行单个或多个任务，其中身份为Receiver的某些task负责从外部数据源源源不断的获取流数据；

9.2 Spark Streaming工作原理

（1）Spark Streaming提供了一种高级的抽象，叫做DStream，英文全称为Discretized Stream，中文翻译为“离散流”，它代表了一个持续不断的数据流。DStream可以通过输入数据源来创建，比如Kafka、Flume、ZMQ和Kinesis；也可以通过对其他DStream应用高阶函数来创建，比如map、reduce、join、window；

（2）由用户确定的时间片作为拆分数据的依据，划分为多个Batch，并转化为DStream，每个DStream包含时间顺序的RDD序列；

（3）Transform：允许用户在每个DStream的每个RDD上执行操作；

（4）窗口操作：

# 窗口长度：窗口持续的时间，必须为划分batch时间片的整数倍；

# 滑动间隔：窗口操作的时间间隔，必须为划分batch时间片的整数倍；

# 窗口操作的应用：统计过去一定时间内操作记录，如图：每当窗口滑过DStream时，落在窗口内的源RDD被组合并被执行操作以产生windowed DStream的RDD，窗口长度为3个时间单位，滑动间隔为2个时间单位，因此表示每2个时间单位计算过去3个时间内的数据

# 窗口类型：滑动窗口、滚动窗口、跳跃窗口

9.3 Spark Streaming容错

（1）Executor（Work）故障：

# 不含Receiver：Spark基于RDD的容错机制

（2）含Receiver和Driver故障：

# 日志：Receiver、Driver日志

# 检查点Checkpoint：数据检查点：将状态转换操作生成的RDD周期性的写入检查点；元数据：包括配置信息、未完成的batch信息、DStream操作信息

（3）故障恢复：

（4）容错语义分类：

# At most once（最多一次）。每条数据记录最多被处理一次，潜台词也表明数据会有丢失（没被处理掉）的可能。

# At least once（最少一次）。每条数据记录至少被处理一次。这个比上一点强的地方在于这里至少保证数据不会丢，至少被处理过，唯一不足之处在于数据可能会被重复处理。

# Exactly once（恰好一次）。每条数据记录正好被处理一次。没有数据丢失，也没有重复的数据处理。这一点是3个语义里要求最高的。

（5）Spark Streaming容错语义：

---

分布式大数据处理系统大纲

• 分布式大数据处理系统概览（一）：​​HDFS/MapReduce/Spark​​
• 分布式大数据处理系统概览（二）：​​Yarn/Zookeeper​​
• 分布式大数据处理系统概览（三）：​​Storm/SparkStreaming​​
• 分布式大数据处理系统概览（四）：​​Lambda/DataFlow/Flink/Giraph​​

---