【Flink系列1】flink与spark的区别

Flink简介

spark基本架构

flink基本架构

Spark提出的最主要抽象概念是弹性分布式数据集(RDD)

flink支持增量迭代计算。基于流执行引擎，Flink提供了诸多更高抽象层的API以方便用户编写分布式任务：

1. DataSet API, 对静态数据进行批处理操作，将静态数据抽象成分布式的数据集，用户可以方便的采用Flink提供的各种操作符对分布式数据集进行各种操作，支持Java，Scala和Python。

2. DataStream API，对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，用户可以方便的采用Flink提供的各种操作符对分布式数据流进行各种操作，支持Java和Scala。

3. Table API，对结构化数据进行查询操作，将结构化数据抽象成关系表，并通过Flink提供的类SQL的DSL对关系表进行各种查询操作，支持Java和Scala。

此外，Flink还针对特定的应用领域提供了领域库，例如：

1. Flink ML，Flink的机器学习库，提供了机器学习Pipelines API以及很多的机器学习算法实现。

2. Gelly，Flink的图计算库，提供了图计算的相关API以及很多的图计算算法实现。

Spark Streaming是Apache Spark之上支持流处理任务的子系统，看似一个特例，实则不然。Spark Streaming采用了一种micro-batch的架构，即将输入的数据流切分成细粒度的batch数据，对于每一个batch数据，以此为输入提交一个批处理Spark任务，所以Spark Streaming本质上还是基于Spark批处理系统对流式数据进行处理，和Apache Storm，Apache Smaza等完全流式的数据处理方式完全不同。Flink能够同时处理批处理任务与流处理任务，其灵活的执行引擎支持完全原生的批量的数据处理和流式的数据处理。

在执行引擎这一层，流处理系统与批处理系统最大的不同在于节点间数据传输的方式。对于一个流处理系统，其节点间数据传输的标准模型是：当一条数据被处理完成后，序列化到缓存中，然后立刻通过网络传输到下一个节点，由下一个节点继续处理。而对于一个批处理系统，其节点间数据传输的标准模型是：当一条数据被处理完成后，序列化到缓存中，并不会立刻通过网络传输到下一个节点，当缓存写满，就持久化到本地硬盘上，当所有数据都被处理完成后，才开始将处理后的数据通过网络传输到下一个节点。

这两种数据传输模式是两个极端，对应的是流处理系统对低延迟的要求和批处理系统对高吞吐量的要求。Flink的执行引擎采用了一种十分灵活的方式，同时支持了这两种数据传输模型。Flink以固定的缓存块为单位进行网络数据传输，用户可以通过缓存块超时值指定缓存块的传输时机。如果缓存块的超时值为0，则Flink的数据传输方式类似上面提到的流处理系统的标准模型，此时系统可以获得最低的处理延迟。如果缓存块的超时值为无限大，则Flink的数据传输方式类似上面提到的批处理系统的标准模型，此时系统可以获得最高的处理吞吐量。同时缓存块的超时值也可以设置为0到无限大之间的任意值。缓存块的超时阈值越小，则Flink流处理执行引擎的数据处理延迟越低，但吞吐量也会越低，缓存块的超时阈值越大时，则反之。通过调整缓存块的超时阈值，用户可根据自己的需要灵活的权衡Flink的延迟和吞吐量。

性能对比

首先它们都可以基于内存计算框架进行实时计算，所以都拥有非常好的计算性能。经过测试，Flink计算性能上略好。

测试环境：

1. CPU：7000个；
2. 内存：单机128GB；
3. 版本：Hadoop 2.3.0，Spark 1.4，Flink 0.9
4. 数据：800MB，8GB，8TB；
5. 算法：K-means：以空间中K个点为中心进行聚类，对最靠近它们的对象归类。通过迭代的方法，逐次更新各聚类中心的值，直至得到最好的聚类结果。
6. 迭代：K=10，3组数据

迭代次数（纵坐标是秒，横坐标是次数）

总结：Spark和Flink全部都运行在Hadoop YARN上，性能为Flink > Spark > Hadoop(MR)，迭代次数越多越明显，性能上，Flink优于Spark和Hadoop最主要的原因是Flink支持增量迭代，具有对迭代自动优化的功能。

流式计算比较

它们都支持流式计算，Flink是一行一行处理，而Spark是基于数据片集合（RDD）进行小批量处理，所以Spark在流式处理方面，不可避免增加一些延时。Flink的流式计算跟Storm性能差不多，支持毫秒级计算，而Spark则只能支持秒级计算。

问题

谬论1：延迟和吞吐量：只能选择一个

早期的开源流处理框架要么是“高吞吐”的，要么是“低延迟”的，而“海量且快速”一直未能成为开源流处理框架的代名词。

不过Flink(可能还有其它的框架)就同时提供了高吞吐和低延迟。这里有一个基准测试结果的样例。

让我们从底层来剖析这个例子，特别是从硬件层，并结合具有网络瓶颈的流处理管道(很多使用Flink的管道都有这个瓶颈)。在硬件层不应该存在需要作出权衡的条件，所以网络才是影响吞吐量和延迟的主要因素。

一个设计良好的软件系统应该会充分利用网络的上限而不会引入瓶颈问题。不过对Flink来说，总是有可优化的空间，可以让它更接近硬件所能提供的效能。使用一个包含10个节点的集群，Flink现在每秒可以处理千万级别的事件量，如果扩展到1000个节点，它的延迟可以降低到几十毫秒。在我们看来，这种水平已经比很多现有的方案高出很多。

参考：

http://www.csdn.net/article/2015-07-16/2825232

http://mobile.51cto.com/adatabase-524305.htm