Flink简介

1.1 Flink的引入

这几年大数据的飞速发展，出现了很多热门的开源社区，其中著名的有 Hadoop、Storm，以及后来的 Spark，他们都有着各自专注的应用场景。Spark 掀开了内存计算的先河，也以内存为赌注，赢得了内存计算的飞速发展。Spark 的火热或多或少的掩盖了其他分布式计算的系统身影。就像 Flink，也就在这个时候默默的发展着。在国外一些社区，有很多人将大数据的计算引擎分成了 4 代，当然，也有很多人不会认同。先姑且这么认为。

首先第一代的计算引擎，无疑就是 Hadoop 承载的 MapReduce。这里大家应该都不会对 MapReduce 陌生，它将计算分为两个阶段，分别为 Map 和 Reduce。对于上层应用来说，就不得不想方设法去拆分算法，甚至于不得不在上层应用实现多个 Job 的串联，以完成一个完整的算法，例如迭代计算。

由于这样的弊端，催生了支持 DAG 框架的产生。因此，支持 DAG 的框架被划分为第二代计算引擎。如 Tez 以及更上层的 Oozie。这里我们不去细究各种 DAG 实现之间的区别，不过对于当时的 Tez 和 Oozie 来说，大多还是批处理的任务。

接下来就是以 Spark 为代表的第三代的计算引擎。第三代计算引擎的特点主要是 Job 内部的 DAG 支持（不跨越Job），以及强调的实时计算。在这里，很多人也会认为第三代计算引擎也能够很好的运行批处理的 Job。

随着第三代计算引擎的出现，促进了上层应用快速发展，例如各种迭代计算的性能以及对流计算和 SQL 等的支持。Flink 的诞生就被归在了第四代。这应该主要表现在 Flink 对流计算的支持，以及更一步的实时性上面。当然Flink 也可以支持 Batch 的任务，以及 DAG 的运算。

迭代计算性能对比测试：Flink > Spark > Hadoop(MR)。迭代次数越多越明显，性能上Flink优于Spark和Hadoop最主要的原因是Flink支持增量迭代，具有对迭代自动优化的功能。

1.2 无限数据的流式处理

在详细了解Flink之前，让我们从更高层次审视处理数据时可能遇到的数据集的类型，以及可以选择处理的执行模型类型。这两个想法经常是混合的，我们需要很清楚地分开它们。

两种数据集

• 无限(Unbounded)：连续附加的无限数据集
• 有限的(Bounded)：有限的，不变的数据集

传统意义上认为的无界数据集譬如“批处理”数据事实上是有界的数据集。无论这些数据是存储在HDFS或者是基于日志系统譬如 Kafka，都是如此。

无界数据集包括但不限于如下

• 终端用户与APP或WEB交互的数据
• 物理传感器采集的数据
• 金融市场行情
• 系统或机器日志

两种执行模式

• 流式传输(Streaming) :只要数据生成，连续执行的处理
• 批处理(Batch)：在有限的时间内执行并运行到完整的处理，完成后释放计算资源

使用任一类型的执行模型来处理任一类型的数据集都是可能的，但不一定是最优的。例如批处理执行长期以来一直应用于无界数据集的处理。 Flink依赖于流式处理模型，这是一种适用于处理无界数据集的流程：流执行是对连续生成的数据进行连续处理。

1.3 Flink特性

Flink能够提供准确的结果，即使数据源是无序的或者晚到达的数据，也能保持结果的准确性。并具有状态和容错能力，可以在保持应用状态的同时无缝的从失败中恢复，并可以保持exactly-once的特性，同时可大规模执行，在数千个节点上运行，具有非常好的吞吐量和延迟特性，并也为YARN和Mesos提供支持。

Flink分布式流处理开源框架特性：

• 支持高吞吐、低延迟、高性能的流处理
• 在运行时同时支持Batch on Streaming批处理和Streaming流处理
• 支持迭代计算
• Flink在JVM内部实现了自己的内存管理
• 支持具有反压（Backpressure）功能的持续流模型
• 支持程序自动优化：避免特定情况下Shuffle、排序等昂贵操作，中间结果有必要进行缓存
• 支持高度灵活的窗口（Window）操作
  支持基于time、count、session，以及data-driven的窗口操作，Windows可以通过灵活的触发条件进行定制，以支持复杂的流式传输模式。
• 支持带有事件时间（event time）的窗口（Window）操作
  事件时间的语义使流计算的结果更加精确，尤其是可能产生无序数据或者数据延迟到达的情况下。
• 支持有状态计算的Exactly-once语义
  有状态意味着程序可以保持已经处理过的数据，同时Flink的checkpoint机制可以确保在发生故障时应用程序状态的一致性语义。
• 支持基于轻量级的容错机制
  它使得系统既能保持高的吞吐率又能保证exactly-once的一致性，使Flink能从零数据丢失的故障中恢复（可靠性和延迟可以忽略不计），通过分布式状态快照（Snapshot）实现
• 支持savepoints 状态版本控制机制（一般手动触发）
  可以将应用的运行状态保存下来，使得在升级应用或处理历史数据时，而不会丢失状态和确保宕机时间最小

1.4 Flink流处理与批处理

Apache Flink® - Stateful Computations over Data Streams——有状态的数据流计算

Apache Flink是一个开源的分布式、高性能、高可用，准确的流处理框架。主要由java代码实现，它能够基于同一个Flink运行时，提供实时流（Stream）处理和批（batch）处理的功能，批数据只是流数据的一个极限特例。原生支持迭代计算、内存管理和程序优化。

现有的开源计算方案，会把流处理和批处理作为两种不同的应用类型，因为它们所提供的SLA（Service-Level-Aggreement：服务等级协议）是完全不相同的：流处理一般需要支持低延迟、Exactly-once保证，而批处理需要支持高吞吐、高效处理。比较典型的有：实现批处理的开源方案有MapReduce、Spark；实现流处理的开源方案有Storm；Spark的Streaming 其实本质上也是微批处理。

Flink从另一个视角看待流处理和批处理，将二者统一起来：Flink会把所有的任务当成流来处理，这也是其最大的特点。在具体的实现过程中，作为流处理看待时输入数据流是无界的；批处理只是流处理的一个极限特例，它被作为一种特殊的流处理，只是它的输入数据流被定义为有界的。在基于Flink运行时（Flink Runtime）分别提供了流处理和批处理API，而这两种API也是实现上层面向流处理、批处理类型应用框架的基础。

无界数据：DataStream API 有限数据：DataSet API

• 流处理Streaming：StreamExecutionEnvironment DataStreaming
• 批处理Batch：ExecutionEnvironment DataSet

Flink把批处理作为特殊的流处理程序来执行，许多概念也都可以应用的批处理中，除了一些小的不同：

• 批处理的API(DataSet API )不使用checkpoints，恢复通过完整的流回放来实现
• DataSet API的有状态操作使用简单的内存和堆外内存 的数据结构，而不是key/value的索引
• DataSet API 引入一种同步的迭代操作，这个仅应用于有界数据流。

Flink通过灵活的执行引擎，能够同时支持批处理任务与流处理任务

• 在执行引擎这一层，流处理系统与批处理系统最大不同在于节点间的数据传输方式。
• 对于一个流处理系统，其节点间数据传输的标准模型是：当一条数据被处理完成后，序列化到缓存中，然后立刻通过网络传输到下一个节点，由下一个节点继续处理
• 而对于一个批处理系统，其节点间数据传输的标准模型是：当一条数据被处理完成后，序列化到缓存中，并不会立刻通过网络传输到下一个节点，当缓存写满，就持久化到本地硬盘上，当所有数据都被处理完成后，才开始将处理后的数据通过网络传输到下一个节点
• 这两种数据传输模式是两个极端，对应的是流处理系统对低延迟的要求和批处理系统对高吞吐量的要求
• Flink的执行引擎采用了一种十分灵活的方式，同时支持了这两种数据传输模型
• Flink以固定的缓存块为单位进行网络数据传输，用户可以通过设置缓存块超时值指定缓存块的传输时机。如果缓存块的超时值为0，则Flink的数据传输方式类似上文所提到流处理系统的标准模型，此时系统可以获得最低的处理延迟
• 如果缓存块的超时值为无限大，则Flink的数据传输方式类似上文所提到批处理系统的标准模型，此时系统可以获得最高的吞吐量
• 同时缓存块的超时值也可以设置为0到无限大之间的任意值。缓存块的超时阈值越小，则Flink流处理执行引
  擎的数据处理延迟越低，但吞吐量也会降低，反之亦然。通过调整缓存块的超时阈值，用户可根据需求灵活地权衡系统延迟和吞吐量