flink Spark 和 Flink对比

文章目录

  • 前言
    • 1. 数据处理架构
    • 2. 数据模型和运行架构
    • 3. Spark 还是 Flink?

前言

  Apache Spark 是一个通用大规模数据分析引擎。它提出的内存计算概念让大家得以从 Hadoop 繁重的 MapReduce 程序中解脱出来。除了计算速度快、可扩展性强,Spark 还为批处理(Spark SQL)、流处理(Spark Streaming)、机器学习(Spark MLlib)、图计算(Spark GraphX)提供了统一的分布式数据处理平台,整个生态经过多年的蓬勃发展已经非常完善。
  而Flink在实时处理领域异军突起,想学习一个大数据处理框架,到底选择 Spark,还是 Flink ?


1. 数据处理架构

  批处理针对的是有界数据集,非常适合需要访问海量的全部数据才能完成的计算工作,一般用于离线统计。
  流处理主要针对的是数据流,特点是无界、实时, 对系统传输的每个数据依次执行操作,一般用于实时统计。

  Spark 以批处理为根本,并尝试在批处理之上支持流计算;在 Spark 的世界观中,离线数据是一个大批次,而实时数据则是由一个一个无限的小批次组成的。所以对于流处理框架 Spark Streaming 而言,其实并不是真正意义上的“流”处理,而是“微批次”(micro-batching)处理
  而 Flink 则认为,流处理才是最基本的操作,批处理也可以统一为流处理。在 Flink 的世界观中,实时数据是标准的、没有界限的流,而离线数据则是有界限的流。

(1)无界数据流(Unbounded Data Stream)
所谓无界数据流,就是有头没尾,数据的生成和传递会开始但永远不会结束。所以对于无界数据流,必须连续处理,也就是说必须在获取数据后立即处理。在处理无界流时,为了保证结果的正确性,必须能够做到按照顺序处理数据。

(2)有界数据流(Bounded Data Stream)
有界数据流有明确定义的开始和结束,所以可以通过获取所有数据来处理有界流。处理有界流就不需要严格保证数据的顺序了,因为可以对有界数据集进行排序。有界流的处理也就是批处理
flink Spark 和 Flink对比_第1张图片

  一般来说,Spark 基于微批处理的方式做同步总有一个“攒批”的过程,所以会有额外开销,因此无法在流处理的低延迟上做到极致。在低延迟流处理场景,Flink 已经有明显的优势。而在海量数据的批处理领域,Spark 能够处理的吞吐量更大,加上其完善的生态和成熟易用的 API,目前同样优势比较明显。


2. 数据模型和运行架构

  Spark 和 Flink 在底层实现最主要的差别就在于数据模型不同:

  Spark 底层数据模型是弹性分布式数据集(RDD),Spark Streaming 进行微批处理的底层接口 DStream,实际上处理的也是一组组小批数据 RDD 的集合。可以看出,Spark 在设计上本身就是以批量的数据集作为基准的,更加适合批处理的场景。

  而 Flink 的基本数据模型是数据流(DataFlow),以及事件(Event)序列。Flink 基本上是完全按照 Google 的 DataFlow 模型实现的,所以从底层数据模型上看,Flink 是以处理流式数据作为设计目标的,更加适合流处理的场景。

  数据模型不同,对应在运行处理的流程上,自然也会有不同的架构。Spark需要将任务对应的 DAG 划分阶段(Stage),一个完成后经过 shuffle 再进行下一阶段的计算。而Flink 是标准的流式执行模式,一个事件在一个节点处理完后可以直接发往下一个节点进行处理。


3. Spark 还是 Flink?

  如果在工作中需要从 Spark 和 Flink 这两个主流框架中选择一个来进行实时流处理,更加推荐使用 Flink,主要的原因有:

Flink 的延迟是毫秒级别,而 Spark Streaming 的延迟是秒级延迟

Flink 提供了严格的精确一次性语义保证

Flink 的窗口 API 更加灵活、语义更丰富

Flink 提供事件时间语义,可以正确处理延迟数据

Flink 提供了更加灵活的对状态编程的 API


你可能感兴趣的:(flink,flink)