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的差异
2、Flink简介
Flink起源于Stratosphere项目，Stratosphere是在2010~2014年由3所地处柏林的大学和欧洲的一些其他的大学共同进行的研究项目，2014年4月Stratosphere的代码被复制并捐赠给了Apache软件基金会，参加这个孵化项目的初始成员是Stratosphere系统的核心开发人员，2014年12月， Flink一跃成为Apache软件基金会的顶级项目。
在德语中，Flink一词表示快速和灵巧，项目采用一只松鼠的彩色图案作为logo，这不仅是因为松鼠具有快速和灵巧的特点，还因为柏林的松鼠有一种迷人的红棕色，而Flink的松鼠logo拥有可爱的尾巴，尾巴的颜色与Apache软件基金会的logo颜色相呼应，也就是说，这是一只Apache风格的松鼠。
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应用程序来说非常有用)。
无善无恶心之体，有善有恶意之动。
知善知恶是良知，为善为恶是格物。