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

本博文主要对现如今分布式大数据处理系统进行概括整理，相关课程为华东师范大学数据科学与工程学院《大数据处理系统》，参考大夏学堂，下面主要整理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容错语义：