Apache Flink - 技术栈

1、Apache Flink

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的运算。

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

Flink和Spark的差异

|------|----------------------|------------------------------------------|
| | SparkStreaming | Flink |
| 定义 | 弹性的分布式数据集，并非真正的实时计算 | 真正的流计算，就像Storm一样但Flink同时支持有限的数据流计算（批处理） |
| 高容错 | 基于RDD和checkpoint比较沉重 | checkpoint（快照），非常轻量级 |
| 内存管理 | JVM相关操作暴露给用户 | Flink在JVM中实现的是自己的内存管理 |
| 延时 | 中等100ms | 低10ms，实时性更好 |

2、Flink简介

Flink起源于Stratosphere项目，Stratosphere是在2010~2014年由3所地处柏林的大学和欧洲的一些其他的大学共同进行的研究项目，2014年4月Stratosphere的代码被复制并捐赠给了Apache软件基金会，参加这个孵化项目的初始成员是Stratosphere系统的核心开发人员，2014年12月， Flink一跃成为Apache软件基金会的顶级项目。

在德语中，Flink一词表示快速和灵巧，项目采用一只松鼠的彩色图案作为logo，这不仅是因为松鼠具有快速和灵巧的特点，还因为柏林的松鼠有一种迷人的红棕色，而Flink的松鼠logo拥有可爱的尾巴，尾巴的颜色与Apache软件基金会的logo颜色相呼应，也就是说，这是一只Apache风格的松鼠。

Flink官网

javascript 复制代码

Stateful Computations over Data Streams
Apache Flink is a framework and distributed processing engine for stateful 
computations over unbounded and bounded data streams. Flink has been designed 
to run in all common cluster environments, perform computations at in-memory \
speed and at any scale.

Flink主页在其顶部展示了该项目的理念："Apache Flink是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框果"，

数据流上的有状态计算

Apache Flink 是一个框架和分布式处理引擎，用于在无边界（流处理）和有边界（批处理）数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。

3、Flink流处理特性

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

2、支持带有事件时间的窗口(Window)操作

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

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

5、支持具有背压功能的持续流模型

6、支持基于轻量级分布式快照(Snapshot)实现的容错

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

8、Flink在JW内部实现了自己的内存管理

9、支持迭代计算

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

4、Flink基石

Flink之所以能这么流行，离不开它最重要的四个基石：Checkpoint、State、Time、Window.

首先是Checkpoint机制，这是Flink最重要的一个特性。Flink基于Chandy-Lamport算法实现了一个分布式的一致性的快照，从而提供了一致性的语义。Chandy-Lamport算法实际上在1985年的时候已经被提出来，但并没有被很广泛的应用，而Flink则把这个算法发扬光大了。Spark最近在实现 Continue streaming, Continue streaming的目的是为了降低它处理的延时，其也需要提供这种一致性的语义，最终采用Chandy-Lamport这个算法，说明Chandy-Lamport算法在业界得到了一定的肯定。

提供了一致性的语义之后，Flink为了让用户在编程时能够更轻松、更容易地去管理状态，还提供了一套非常简单明了的StateAPI，包括里面的有ValueState、ListState、MapState，近期添加了BroadcastState，使用StateAPI能够自动享受到这种一致性的语义。

除此之外，Flink还实现了Watermark的机制，能够支持基于事件的时间的处理，或者说基于系统时间的处理，能够容忍数据的延时、容忍数据的迟到、容忍乱序的数据。

另外流计算中一般在对流数据进行操作之前都会先进行开窗，即基于一个什么样的窗口上做这个计算。Flink提供了开箱即用的各种窗口，比如滑动窗口、滚动窗口、会话窗口以及非常灵活的自定义的窗口。

checkpoint：基于chandy-lamport算法实现分布式计算任务的一致性语义;

state：Flink中的状态机制，Flink天生支持state,state可以认为程序的中间计算结果或者是历史计算结果;

time：Flink中支持基于事件时间和处理时间进行计算，spark streaming只能按照process time进行处理;基于事件时间的计算我们可以解决数据迟到和乱序等问题。

window：Flink提供了更多丰富的window，基于时间，基于数量，session window，同样支持滚动和滑动窗口的计算。

5、批处理与流处理

批处理的特点是有界、持久、大量、批处理非常适合需要访问全套记录才能完成的计算工作，一般用于离线统计。流处理的特点是无界、实时，流处理方式无需针对整个数据集执行操作，而是对通过系统传输的每个数据项执行操作，一般用于实时统计。

在Spark生态体系中，对于批处理和流处理采用了不同的技术框架，批处理由SparkSQL实现，流处理由Spark Streaming实现，这也是大部分框架采用的策略，使用独立的处理器实现批处理和流处理，而Flink可以同时实现批处理和流处理。

Flink是如何同时实现批处理与流处理的呢？答案是，Flink将批处理（即处理有限的静态数据）视作一种特殊的流处理。

Flink的核心计算架构是下图中的Flink Runtime执行引擎，它是一个分布式系统，能够接受数据流程序并在一台或多台机器上以容错方式执行。

Flink Runtime执行引擎可以作为YARN(Yet Another Resource Negotiator)的应用程序在集群上运行，也可以在Mesos集群上运行，还可以在单机上运行(这对于调试Flink应用程序来说非常有用)。

Hadoop分布式文件系统(一)

无善无恶心之体，有善有恶意之动。
知善知恶是良知，为善为恶是格物。