百花齐放的大数据计算平台演进史

上一篇文章《Hadoop之HDFS架构演进之路》中，我们分享了分布式存储HDFS的架构以及演进的历程，这一篇文章我们主要讲述大数据计算引擎的发展并对它们进行比较。

 

随着互联网技术的广泛应用，5G以及物联网和云计算的迅猛发展，带动了全球数据爆发式增长，随之而来的是不断增长的数据规模和数据的动态快速产生，这对大数据计算引擎带来了极大的挑战，离线批处理、实时计算和高吞吐量催生了新技术的发展和旧技术的革新，计算引擎出现了百花齐放的景象。计算引擎大致分两类，离线计算和实时计算，下面为大家介绍几个主流的大数据计算引擎。

 

一、离线计算引擎

 

1.MapReduce

MapReduce产生的灵感来源于2004年Google发表的《MapReduce》论文中的大数据计算模型，用于大规模数据集（TB甚至PB级）的并行计算，利用分治策略，将计算过程分两个阶段，Map阶段和Reduce阶段，可谓是第一代大数据分布式计算引擎，为后来各类优秀的大数据计算引擎的出现提供了基础和可行性。

 

MapReduce的架构

MapReduce 1.x架构如下：

 

1. 客户端向JobTracker提交任务
2. JobTraker将任务拆解为多个子任务，分配给TaskTracker执行
3. TaskTracker定时与JobTracker保持心跳，汇报任务执行情况

 

存在的问题：

• 单点故障：一旦JobTracker出现故障，会导致任务无法提交和正常执行
• JobTracker负载高：所有的任务的提交和分配以及资源管理都是由JobTracker控制，压力过于集中
• 场景有限制：只能运行MapReduce作业，可兼容性差

 

为了解决MR v1的问题，MapReduce v2引入了资源管理器YARN (Yet Another Resource Negotiator)，即新一代的MapReduce 2.0。

 

认识一下YARN中的重要角色及功能：

1. ResourceManager：资源管理节点（RM），对应MR v1的JobTracker
   1. 负责处理来自客户端的提交的Job
   2. 启动Application Master管理任务
   3. 监控Application Master状态
   4. 为NodeManager分配资源（CPU、内存、磁盘、网络）
2. NodeManager：工作节点（NM），对应MR v1的TaskTracker
   1. 管理节点container任务资源和运行情况
   2. 与ResourceManager保持通信，汇报自身的状态
3. Application Master：任务管理服务（AM），其实就是ResourceManager的小弟
   1. 负责检查集群资源，申请mr程序所需资源
   2. 分配任务到相应的container容器执行
   3. 监控任务执行状态并向ResourceManager汇报任务执行情况
4. Container：YARN资源抽象，封装了节点上的资源，如内存、CPU、磁盘等

 

YARN的优势：

1. ResourceManager支持HA，解决了JobTracker单点故障的问题，提高集群可用性
2. 实现资源管理和job管理分离，解决了JobTracker负载高的难题
3. 提供Application Master负责监控所有的任务，解决了JobTracker集中管理监控的压力
4. 高扩展性，不仅可以跑mr任务，还支持spark作业以及其他计算引擎任务
5. 提高了资源的利用率

 

 

MapReduce核心计算阶段

• Mapper阶段：负责数据 的载入、解析、转换和过滤，map任务的输出被称为中间键和中间值 

 

 

• Reducer阶段：负责处理map任务输出结果，对map任务处理完的结果集进行排序、局部聚合计算再汇总结果

 

 

MapReduce为什么慢

 

• MapReduce是基于磁盘数据进行计算的
• Shuffle过程进行一系列分区、排序，耗费大量时间
• map计算结果频繁落盘
• reduce任务通过磁盘获取数据，占用IO
• spill会会产生大量的小文件，极大占用集群的资源
• 容错性差，错了就重头来过
• MapReduce抽象层次低，只有map和reduce两种，处理数据效率较低

 

因此MapReduce只适用于处理大规模离线数据，延时高。MapReduce的局限性推动了计算引擎技术的革新，Spark的出现是为了解决MapReduce计算慢的问题，随着数据量的指数增长，对数据处理效率有了更高的要求，我们需要在更短的时间内得到正确的结果。

 

 

2.SPARK

Apache Spark是用于大规模数据处理的统一分析计算引擎，最初诞生于加州大学伯克利分校的AMP Lab实验室。基于内存进行并行计算，通过使用最先进的DAG调度器、查询优化器和物理执行引擎，实现了批处理和流处理的高性能，与Hadoop MapReduce相比，运行在内存中的计算速度要快上100倍（实际上或许没有快这么多），但是可见spark是要比Hadoop MapReduce计算能力更强的计算引擎。

 

 

Spark由Spark Core、Spark SQL、Spark Streaming、MLib和GraphX四大组件构成

角色说明：

• Spark Core：spark的核心，将数据抽象为弹性分布式数据集（RDD），提供了分布式任务调度，RPC通信、序列化和压缩等特性，是内存计算的框架，用于离线计算
• Spark SQL：基于Spark Core之上用于结构化数据建模和数据处理组件，实现交互式查询
• Spark Streaming：利用Spark Core快速调度能力进行流式计算
• MLib：是Spark上分布式机器学习框架，提供了大量的算法
• GraphX：是Spark上的分布式图形处理框架，能进行高效的图计算

 

 

Apache Spark 架构

Spark是一个典型的master/slave主从架构，基于内存计算引擎，提供了多种缓存机制，将RDD 缓存到内存或者磁盘中，这种机制使得Spark可以进行迭代计算和数据共享，从而减少数据读取的IO开销，架构如下：

 

 

• Driver：初始化Spark运行环境，创建SparkContext上下文环境，是用户程序的入口，即main() 方法
• Cluster Manager：资源管理器，目前支持Standalone、YARN、Mesos和Kubernetes这几种模式，在Standalone模式中，Cluster Manager即为Master节点，控制整个集群
• Worker：spark计算节点，负责计算任务的管理，为task分配并启动Executor，定时向Cluster Manager汇报任务执行情况
• Executor：Spark Task工作的容器，是用户程序在worker节点上的一个进程，运行计算任务，负责数据的读取和写入，缓存中间数据

 

 

Spark工作原理

 

1. Driver驱动程序会初始化SparkContext
2. 初始化过程中会启动DAGScheduler和TaskScheduler
3. TaskScheduler通过后台进程向Master注册用户程序
4. Master收到注册请求之后会通知Worker为用户程序启动多个Executor容器
5. Executor反向SparkContext注册
6. SparkContext将应用程序发给Executor
7. SparkContext完成初始化，构建DAG，创建Job并且根据action操作划分Stage，形成TaskSet发送给TaskScheduler，最后发给Executor执行
8. 运行完释放资源

 

 

Spark 为什么比MapReduce快

• Spark相对于MapReduce减少了磁盘IO，没有太多中间结果落盘
• Spark采用了多线程模型，基于线程池复用降低task线程的开销
• spark提供了多种缓存策略，避免了重复计算
• 灵活的内存管理策略
• Spark的DAG（有向无环图）算法
• 提供丰富的抽象方法，MapReduce只有map和reduce两种抽象
• 缓存和checkpoint，通过lineage实现高度容错性

 

以上列举了spark比MapReduce快的部分特性，Spark的出现逐步取代了MapReduce成为新一代离线计算引擎的最佳选择，不仅如此，spark还提供了Spark Streaming组件作为流式计算引擎。

 

 

二、实时计算引擎

 

3.Spark Streaming

Spark Streaming是Spark Core API的扩展，支持实时数据流的可伸缩、高吞吐量、容错流处理。支持多种数据源，数据可以从Kafka、Flume、HDFS、S3、Kinesis或TCP套接字等许多来源获取，并可以使用复杂的算法处理，这些算法由map、reduce、join和window等高级函数表达。最后，可以将处理过的数据推送到文件系统、数据库和实时仪表板中。

 

工作模型

 

Spark Streaming基于micro batch方式的计算和处理流数据，提供了称为离散流或DStream的高级抽象，它表示连续的数据流。将接收到的数据流切分为多个独立的DStream，本质上也是一系列RDD，通过spark计算引擎进行计算。

 

 

DStreams（Discretized Streams）

离散数据流是Spark Streaming提供的基本抽象，将待处理数据转变为连续不断的数据流，可以是外部数据源转换而来，也可以通过内部流之间的转换生成，从DStream的内部流模型可以看到Dstream就是由一系列的RDD组成。

实际上，Dstream执行的操作都会转换为对底层RDD的操作。

 

Spark Streaming是怎么实现数据实时计算的呢？

 

当spark Streaming接收到数据后，会将数据流切分成多个批次，形成有界的数据集，设置时间间隔，当不同批次的数据进入窗口后会触发计算机制，通过Spark Core进行一系列tranformation和action操作，因为划分批次之后的数据比较小，实时计算得出结果。

 

 

为什么要用Spark Streaming呢？

从数据的边界来说，我们可以把数据分为有界数据和无界数据。顾名思义，有界数据是有范围的，一般来说与时间是强关联的，以历史数据最为典型。而无界数据就是难以限定范围的数据，会持续不断发生变化，最常见的场景就是实时数据流，看不到数据的尽头，一直在发生。

MapReduce和Spark SQL等框架只能进行离线计算，无法满足实时性要求高的业务场景，如购买商品后进行实时推荐、实时交易业务等等。而spark Streaming巧妙地将数据细分为多个微小的批次，依赖于spark计算引擎能做到准实时计算，不是真正意义上的实时计算，尽管如此，spark Streaming还是得到了业界的认可和广泛应用。

 

Spark Streaming优势：

• 实时性：Spark Streaming 是一个实时计算框架，微批处理数据，延迟可以控制到秒级
• 高容错性：Spark Streaming底层依赖RDD lineage特性、缓存机制、checkpoint机制以及WAL预写日志，可以实现高度容错
• 高吞吐：相对于实时计算框架Storm吞吐量更高
• 一体化：依托spark生态，不仅能进行实时计算，还能应用于机器学习和Spark SQL场景

 

对于大部分企业来说，秒级的延时是可以接受的，而且一个大数据项目通常会包含离线计算、交互式查询、数据分析、实时计算等模块，Spark Streaming毫无疑问是很好的选择。

 

 

4.Storm

storm是一个真正的实时流计算引擎，相对于Spark Streaming的微批处理，storm则是来一条数据计算一条数据，延时可以控制到毫秒级。

 

 

Storm架构

storm的架构与Hadoop相似，都是master/slave主从架构。

成员	Storm	Hadoop
主节点	Nimbus	JobTracker
从节点	Supervisor	TaskTracker
计算模型	Spout / Bolt	Map / Reduce
应用程序	Topology	Job
工作进程	Worker	Child

 

 

Nimbus：master节点，负责提交任务，分配到supervisor的worker上，运行Topology上的Spout/Bolt任务

Zookeeper：协调节点，负责管理storm集群的元数据信息，比如heartbeat信息、集群状态和配置信息以及Nimbus分配的任务信息等

Supervisor：slave节点，负责管理运行在supervisor节点上的worker进程

 

 

Storm工作流程

 

1. 客户端提交topology任务到Nimbus节点
2. Nimbus主节点将任务提交到zookeeper集群管理
3. Supervisor节点从Zookeeper集群获取任务信息
4. 启动worker进程开始执行任务

 

 

Storm Vs Spark Streaming

用一个生动形象的生活场景来比喻Storm和Spark Streaming，Storm好比是手扶电梯，一直在运行，来一个人都会将他带上/下楼，而Spark Streaming更像是升降电梯，要装满一批人才开始启动。

• storm可以实现毫米级计算响应 VS Spark Streaming只能做到秒级响应
• Storm吞吐量低 VS Spark Streaming吞吐量高

Item	Storm	Spark Streaming
Streaming Model	Native	Micro-Batch
Guarantees	At-Least-Once	Exactly-Once
Back Pressure	No	Yes
Latency	Very Low	Low
Throughput	Low	High
Fault Tolerance	Record ACKs	RDD Based CheckPoint
Stateful	No	Yes（DStream）

 

 

5.Flink

Apache Flink是一个分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。现在Flink也是主流的实时流计算框架并且同时支持批处理，支持基于有状态的事件时间进行计算，成为大数据计算引擎的领头羊，大有盖过Spark风头之势。

 

擅长处理有界（bounded）数据和无界（unbounded）数据，有界数据通常指的是离线历史数据，用于批处理，而无界数据指数据流有定义数据产生的开始，却无法定义数据何时结束，因此无界数据流通常说的就是实时流，用于实时计算。

 

 

 

Flink架构

Flink和Spark一样，也是主从架构，由JobManager和TaskManager组成

JobManager：主节点，负责处理客户端提交的Job，管理Job状态信息，调度分配集群任务，对完成的 Task 或执行失败做出反应、协调 checkpoint、并且协调从失败中恢复

TaskManager：从节点，负责管理节点上的资源，向JobManager汇报集群状态，执行计算JobManager分配的Task

 

 

Flink工作调度

 

1. 用户提交Flink程序时，client会对程序进行预处理，构建Dataflow graph，封装成Job提交到JobManager
2. JobManager接收到client提交的Job，获取并管理Job的基本信息，构建DAG执行计划，通过Scheduler调度任务并分配到对应的TaskManager节点
3. TaskManager向JobManager注册，JobManager将Job分配到TaskManager执行，每个Task Slot代表着用来执行Task的资源，包括了内存、cpu等
4. TaskManager与JobManager保持心跳，定时汇报节点资源情况以及任务执行情况
5. JobManager将将任务执行的状态和结果反馈给客户端

 

 

Flink的优势

• Flink支持实时计算，且基于内存管理，性能优越
• 具有高吞吐、低延迟、高性能的流处理特性
• Flink与Hadoop生态高度融合
• 高度灵活的时间窗口语义
• 流批一体化，同时支持批处理和流计算
• 高容错，基于分布式快照（snapshot）和checkpoint检查点机制
• 具有反压（Backpressure）功能
• 支持有状态计算的Exactly-once语义
• 可以进行机器学习处理（FlinkML）、图分析（Gelly）、关系数据处理（FLink SQL）以及复杂事件处理（CEP）

 

 

Flink VS Storm VS Spark Streaming

Item	Flink	Storm	Spark Streaming
Streaming Model	Native	Native	Micro-Batch
Guarantees	Exactly-Once	At-Least-Once	Exactly-Once
Back Pressure	Yes	No	Yes
Latency	Medium	Very Low	Low
Throughput	High	Low	High
Fault Tolerance	Checkouting	Record ACKs	RDD Based CheckPoint
Stateful	Yes（Operators）	No	Yes（DStream）

 

综合以上，我们介绍了离线计算引擎Hadoop MapReduce、Spark和实时计算引擎Spark Streaming、Storm和Flink各自不同的功能特性和架构组成，希望帮助大家熟悉当前主流的大数据计算引擎的基本概念、原理和架构。