Flink---调研

1.1 Flink 同类框架

Flink官方定义的是基于状态的分布式流处理引擎，虽然定义的是流处理引擎但是flink也可以处理批数据并且有一套专门的处理批数据的DataSet API 。

所以也可以说Flink是一种既可以处理流数据又可以处理批数据的混合大数据处理框架。下面主要是Flink和同样是混合大数据处理框架的Spark的性能对比，

还有Flink和纯流处理框架Storm的对比。

1. Flink与Spark对比：

Spark:

Micro Batching(微批式)模式，最低延迟Spark能达到0.5~2秒左右

不支持对late data 的处理

Flink:

Native Streaming(纯流式)模式，最低延时能达到微秒

使用WaterMark机制可以解决late data的问题但是会影响整体的计算性能

	Spark	Flink
定义	弹性的分布式数据集，并非真正的实时计算	真正的流计算，就像storm一样；但flink同时支持有限的数据流计算（批处理）
高容错	沉重	非常轻量级
内存管理	JVM相关操作暴露给用户	Flink在JVM中实现的是自己的内存管理
程序调优	只有SQL有自动优化机制	自动地优化一些场景，比如避免一些昂贵的操作（如shuffle和sorts），还有一些中间缓存

2. Flink和Storm进行对比：

2.1 flink和storm测试

简单的输入-输出模型，主要的指标为吞吐量和延迟。

测试环境：

Flink和storm分别搭建1个master和2个slaver

测试结果：

结果：蓝色为storm单线程吞吐量，橙色为flink单线程吞吐量。可以看出flink的吞吐量约为storm的3倍左右。

•采用 outTime - eventTime 作为延迟，图中蓝色折线为 Storm，橙色折线为 Flink。虚线为 99 线，实线为中位数。

• 从图中可以看出随着数据量逐渐增大，Identity 的延迟逐渐增大。其中 99 线的增大速度比中位数快，Storm 的增大速度比 Flink 快。

• 其中 QPS 在 80000 以上的测试数据超过了 Storm 单线程的吞吐能力，无法对 Storm 进行测试，只有 Flink 的曲线。

• 对比折线最右端的数据可以看出，Storm QPS 接近吞吐时延迟中位数约 100 毫秒，99 线约 700 毫秒，Flink 中位数约 50 毫秒，99 线约 300 毫秒。Flink 在满吞吐时的延迟约为 Storm 的一半。

1.2 Flink简介

Flink源于柏林理工大学的一个研究项目Strato Sphere，在2014年成为Apache旗下的项目之一，然后迅速成为了ASF ASF（Apache Software Foundation）的顶级项目之一。国内大多数人可能都是在2015年才听到flink这个词的，现在Flink的最新版本已经更新到了1.7。

Flink 是一个针对流数据和批数据的分布式处理引擎。它主要是由 Java 代码实现。目前主要还是依靠开源社区的贡献而发展。对 Flink 而言，其所要处理的主要场景就是流数据，批数据只是流数据的一个极限特例而已。再换句话说，Flink 会把所有任务当成流来处理，这也是其最大的特点。

Flink 可以支持本地的快速迭代，以及一些环形的迭代任务。并且 Flink 可以定制化内存管理。在这点，如果要对比 Flink 和 Spark 的话，Flink 并没有将内存完全交给应用层。这也是为什么 Spark 相对于 Flink，更容易出现 OOM 的原因（out of memory）。就框架本身与应用场景来说，Flink 更相似与 Storm。下面让我们先来看下 Flink 的架构图。

我们可以了解到 Flink 几个最基础的概念，Client、JobManager 和 TaskManager。Client 用来提交任务给 JobManager，JobManager 分发任务给 TaskManager 去执行，然后 TaskManager 会心跳的汇报任务状态。看到这里，有的人应该已经有种回到 Hadoop 一代的错觉。确实，从架构图去看，JobManager 很像当年的 JobTracker，TaskManager 也很像当年的 TaskTracker。然而有一个最重要的区别就是 TaskManager 之间是是流（Stream）。其次，Hadoop 一代中，只有 Map 和 Reduce 之间的 Shuffle，而对 Flink 而言，可能是很多级，并且在 TaskManager 内部和 TaskManager 之间都会有数据传递，而不像 Hadoop，是固定的 Map 到 Reduce。

1.3Flink的特性

1.3.1流处理特性

支持高吞吐、低延迟、高性能的流处理

支持带有事件时间的窗口（Window）操作

支持有状态计算的Exactly-once语义

支持高度灵活的窗口（Window）操作，支持基于time、count、session，以及data-driven的窗口操作

支持具有Backpressure功能的持续流模型

支持基于轻量级分布式快照（Snapshot）实现的容错

一个运行时同时支持Batch on Streaming处理和Streaming处理

Flink在JVM内部实现了自己的内存管理

支持迭代计算

支持程序自动优化：避免特定情况下Shuffle、排序等昂贵操作，中间结果有必要进行缓存

1.3.2 API支持

对Streaming数据类应用，提供DataStream API

对批处理类应用，提供DataSet API（支持Java/Scala）

1.3.3 Libraries支持

支持机器学习（FlinkML）

支持图分析（Gelly）

支持关系数据处理（Table）

支持复杂事件处理（CEP）

1.3.4 整合支持

支持Flink on YARN

支持HDFS

支持来自Kafka的输入数据

支持Apache HBase

支持Hadoop程序

支持Tachyon

支持ElasticSearch

支持RabbitMQ

支持Apache Storm

支持S3

支持XtreemFS

1.4 Flink生态圈

一个计算框架要有长远的发展，必须打造一个完整的 Stack。不然就跟纸上谈兵一样，没有任何意义。只有上层有了具体的应用，并能很好的发挥计算框架本身的优势，那么这个计算框架才能吸引更多的资源，才会更快的进步。所以 Flink 也在努力构建自己的 Stack。

Flink 首先支持了 Scala 和 Java 的 API，Python 也正在测试中。Flink 通过 Gelly 支持了图操作，还有机器学习的 FlinkML。Table 是一种接口化的 SQL 支持，也就是 API 支持，而不是文本化的 SQL 解析和执行。对于完整的 Stack 我们可以参考下图。

1.5Flink的搭建

Flink按照不同的需求支持3种部署模式Local,Cluster,Cloud, 同时Apache Flink在部署上能够与其他成熟的生态产品进行完美集成Cluster模式下可以利用YARN(Yet Another Resource Negotiator)/Mesos集成进行资源管理，在Cloud部署模式下可以与GCE(Google Compute Engine), EC2(Elastic Compute Cloud)进行集成.