随着互联网技术的广泛应用,5G以及物联网和云计算的迅猛发展,带动了全球数据爆发式增长,随之而来的是
不断增长的数据规模和数据的动态快速产生,这对大数据计算引擎带来了极大的挑战,离线批处理、实时计算和高吞吐量催生了新技术的发展和旧技术的革新,计算引擎出现了百花齐放的景象。计算引擎大致分两类,离线计算和实时计算,下面为大家介绍几个主流的大数据计算引擎。 一、离线计算引擎1. MapReduceMapReduce产生的灵感来源于2004年Google发表的《MapReduce》论文中的大数据计算模型,用于大规模数据集(TB甚至PB级)的并行计算,利用分治策略,将计算过程分两个阶段,Map阶段和Reduce阶段,可谓是第一代大数据分布式计算引擎,为后来各类优秀的大数据计算引擎的出现提供了基础和可行性。 (1)MapReduce的架构MapReduce 1.x架构如下:
-
客户端向JobTracker提交任务
-
JobTraker将任务拆解为多个子任务,分配给TaskTracker执行
-
TaskTracker定时与JobTracker保持心跳,汇报任务执行情况
存在的问题:
-
单点故障:一旦JobTracker出现故障,会导致任务无法提交和正常执行
-
JobTracker负载高:所有的任务的提交和分配以及资源管理都是由JobTracker控制,压力过于集中
-
场景有限制:只能运行MapReduce作业,可兼容性差
为了解决MR v1的问题,MapReduce v2引入了资源管理器YARN (Yet Another Resource Negotiator),即新一代的MapReduce 2.0。
认识一下YARN中的重要角色及功能:
-
ResourceManager:资源管理节点(RM),对应MR v1的JobTracker
-
负责处理来自客户端的提交的Job
-
启动Application Master管理任务
-
监控Application Master状态
-
为NodeManager分配资源(CPU、内存、磁盘、网络)
-
NodeManager:工作节点(NM),对应MR v1的TaskTracker
-
管理节点container任务资源和运行情况
-
与ResourceManager保持通信,汇报自身的状态
-
Application Master:任务管理服务(AM),其实就是ResourceManager的小弟
-
负责检查集群资源,申请mr程序所需资源
-
分配任务到相应的container容器执行
-
监控任务执行状态并向ResourceManager汇报任务执行情况
-
Container:YARN资源抽象,封装了节点上的资源,如内存、CPU、磁盘等
YARN的优势:
-
ResourceManager支持HA,解决了JobTracker单点故障的问题,提高集群可用性
-
实现资源管理和job管理分离,解决了JobTracker负载高的难题
-
提供Application Master负责监控所有的任务,解决了JobTracker集中管理监控的压力
-
高扩展性,不仅可以跑mr任务,还支持spark作业以及其他计算引擎任务
-
提高了资源的利用率
(2)MapReduce核心计算阶段-
Mapper阶段:负责数据 的载入、解析、转换和过滤,map任务的输出被称为中间键和中间值
-
Reducer阶段:负责处理map任务输出结果,对map任务处理完的结果集进行排序、局部聚合计算再汇总结果
(3)MapReduce为什么慢? -
MapReduce是基于磁盘数据进行计算的
-
Shuffle过程进行一系列分区、排序,耗费大量时间
-
map计算结果频繁落盘
-
reduce任务通过磁盘获取数据,占用IO
-
spill会会产生大量的小文件,极大占用集群的资源
-
容错性差,错了就重头来过
-
MapReduce抽象层次低,只有map和reduce两种,处理数据效率较低
因此MapReduce只适用于处理大规模离线数据,延时高。MapReduce的局限性推动了计算引擎技术的革新,Spark的出现是为了解决MapReduce计算慢的问题,随着数据量的指数增长,对数据处理效率有了更高的要求,我们需要在更短的时间内得到正确的结果。
2. SPARKApache 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上的分布式图形处理框架,能进行高效的图计算
(1)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节点上的一个进程,运行计算任务,负责数据的读取和写入,缓存中间数据
(2)Spark工作原理 -
Driver驱动程序会初始化SparkContext
-
初始化过程中会启动DAGScheduler和TaskScheduler
-
TaskScheduler通过后台进程向Master注册用户程序
-
Master收到注册请求之后会通知Worker为用户程序启动多个Executor容器
-
Executor反向SparkContext注册
-
SparkContext将应用程序发给Executor
-
SparkContext完成初始化,构建DAG,创建Job并且根据action操作划分Stage,形成TaskSet发送给TaskScheduler,最后发给Executor执行
-
运行完释放资源
(3)Spark 为什么比MapReduce快-
Spark相对于MapReduce减少了磁盘IO,没有太多中间结果落盘
-
Spark采用了多线程模型,基于线程池复用降低task线程的开销
-
spark提供了多种缓存策略,避免了重复计算
-
灵活的内存管理策略
-
Spark的DAG(有向无环图)算法
-
提供丰富的抽象方法,MapReduce只有map和reduce两种抽象
-
缓存和checkpoint,通过lineage实现高度容错性
以上列举了spark比MapReduce快的部分特性,Spark的出现逐步取代了MapReduce成为新一代离线计算引擎的最佳选择,不仅如此,spark还提供了Spark Streaming组件作为流式计算引擎。
二、实时计算引擎3. Spark StreamingSpark Streaming是Spark Core API的扩展,支持实时数据流的可伸缩、高吞吐量、容错流处理。支持多种数据源,数据可以从Kafka、Flume、HDFS、S3、Kinesis或TCP套接字等许多来源获取,并可以使用复杂的算法处理,这些算法由map、reduce、join和window等高级函数表达。最后,可以将处理过的数据推送到文件系统、数据库和实时仪表板中。 (1)工作模型 Spark Streaming基于micro batch方式的计算和处理流数据,提供了称为离散流或DStream的高级抽象,它表示连续的数据流。将接收到的数据流切分为多个独立的DStream,本质上也是一系列RDD,通过spark计算引擎进行计算。 (2)DStreams(Discretized Streams)离散数据流是Spark Streaming提供的基本抽象,将待处理数据转变为连续不断的数据流,可以是外部数据源转换而来,也可以通过内部流之间的转换生成,从DStream的内部流模型可以看到Dstream就是由一系列的RDD组成。
实际上,Dstream执行的操作都会转换为对底层RDD的操作。
Spark Streaming是怎么实现数据实时计算的呢?
当spark Streaming接收到数据后,会将数据流切分成多个批次,形成有界的数据集,设置时间间隔,当不同批次的数据进入窗口后会触发计算机制,通过Spark Core进行一系列tranformation和action操作,因为划分批次之后的数据比较小,实时计算得出结果。
(3)为什么要用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. Stormstorm是一个真正的实时流计算引擎,相对于Spark Streaming的微批处理,storm则是来一条数据计算一条数据,延时可以控制到毫秒级。
(1)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进程
(2)Storm工作流程 -
客户端提交topology任务到Nimbus节点
-
Nimbus主节点将任务提交到zookeeper集群管理
-
Supervisor节点从Zookeeper集群获取任务信息
-
启动worker进程开始执行任务
(3)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. FlinkApache Flink是
一个分布式处理引擎,用于在无边界和有边界数据流上进行有状态的计算。Flink能在所有常见集群环境中运行,并能以内存速度和任意规模进行计算。现在Flink也是主流的实时流计算框架并且同时支持批处理,支持基于有状态的事件时间进行计算,成为大数据计算引擎的领头羊,大有盖过Spark风头之势。 擅长处理有界(
bounded)数据和无界(
unbounded)数据,有界数据通常指的是离线历史数据,用于批处理,而无界数据指数据流有定义数据产生的开始,却无法定义数据何时结束,因此无界数据流通常说的就是实时流,用于实时计算。
(1)Flink架构Flink和Spark一样,也是主从架构,由JobManager和TaskManager组成
JobManager:主节点,负责处理客户端提交的Job,管理Job状态信息,调度分配集群任务,
对完成的 Task 或执行失败做出反应、协调 checkpoint、并且协调从失败中恢复TaskManager:从节点,负责管理节点上的资源,向JobManager汇报集群状态,执行计算JobManager分配的Task
(2)Flink工作调度 -
用户提交Flink程序时,client会对程序进行预处理,构建Dataflow graph,封装成Job提交到JobManager
-
JobManager接收到client提交的Job,获取并管理Job的基本信息,构建DAG执行计划,通过Scheduler调度任务并分配到对应的TaskManager节点
-
TaskManager向JobManager注册,JobManager将Job分配到TaskManager执行,每个Task Slot代表着用来执行Task的资源,包括了内存、cpu等
-
TaskManager与JobManager保持心跳,定时汇报节点资源情况以及任务执行情况
-
JobManager将将任务执行的状态和结果反馈给客户端
(3)Flink的优势-
Flink支持实时计算,且基于内存管理,性能优越
-
具有高吞吐、低延迟、高性能的流处理特性
-
Flink与Hadoop生态高度融合
-
高度灵活的时间窗口语义
-
流批一体化,同时支持批处理和流计算
-
高容错,基于分布式快照(snapshot)和checkpoint检查点机制
-
具有反压(Backpressure)功能
-
支持有状态计算的Exactly-once语义
-
可以进行机器学习处理(FlinkML)、图分析(Gelly)、关系数据处理(FLink SQL)以及复杂事件处理(CEP)
(4)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各自不同的功能特性和架构组成,希望帮助大家熟悉当前主流的大数据计算引擎的基本概念、原理和架构。