大数据计算引擎原理和架构

随着互联网技术的广泛应用，5G以及物联网和云计算的迅猛发展，动员了环球数据发作式增长，随之而来的是不停增长的数据规模和数据的动态快速产生，这对大数据计算引擎带来了极大的寻衅，离线批处置惩罚、及时计算和高吞吐量催生了新技术的发展和旧技术的革新，计算引擎出现了百花齐放的情形。计算引擎大抵分两类，离线计算和及时计算，下面为大家介绍几个主流的大数据计算引擎。
一、离线计算引擎

1. MapReduce

MapReduce产生的灵感泉源于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.  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上的分布式图形处置惩罚框架，能进行高效的图计算
  

（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 Streaming

Spark 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. Storm

storm是一个真正的及时流计算引擎，相对于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. Flink

Apache 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各自不同的功能特性和架构组成，希望资助大家熟悉当前主流的大数据计算引擎的根本概念、原理和架构。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。