本文节选自 9 月 1 日在成都举行的 Apache Flink China Meetup，分享来自于云邪。
Flink 是一款分布式的计算引擎，它可以用来做批处理，即处理静态的数据集、历史的数据集；也可以用来做流处理，即实时地处理一些实时数据流，实时地产生数据的结果；也可以用来做一些基于事件的应用，比如说滴滴通过 Flink CEP 实现实时监测用户及司机的行为流来判断用户或司机的行为是否正当。
总而言之，Flink 是一个 Stateful Computations Over Streams，即数据流上的有状态的计算。这里面有两个关键字，一个是 Streams，Flink 认为有界数据集是无界数据流的一种特例，所以说有界数据集也是一种数据流，事件流也是一种数据流。Everything is streams，即 Flink 可以用来处理任何的数据，可以支持批处理、流处理、AI、MachineLearning 等等。
另外一个关键词是 Stateful，即有状态计算。有状态计算是最近几年来越来越被用户需求的一个功能。举例说明状态的含义，比如说一个网站一天内访问 UV 数，那么这个 UV 数便为状态。Flink 提供了内置的对状态的一致性的处理，即如果任务发生了 Failover，其状态不会丢失、不会被多算少算，同时提供了非常高的性能。
那 Flink 的受欢迎离不开它身上还有很多的标签，其中包括性能优秀（尤其在流计算领域）、高可扩展性、支持容错，是一种纯内存式的一个计算引擎，做了内存管理方面的大量优化，另外也支持 eventime的处理、支持超大状态的 Job（在阿里巴巴中作业的 state大小超过TB的是非常常见的）、支持 exactly-once 的处理。
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 为了让用户在编程时能够更轻松、更容易地去管理状态，还提供了一套非常简单明了的 State API，包括里面的有 ValueState、ListState、MapState，近期添加了 BroadcastState，使用 State API 能够自动享受到这种一致性的语义。
除此之外，Flink 还实现了 Watermark 的机制，能够支持基于事件的时间的处理，或者说基于系统时间的处理，能够容忍数据的延时、容忍数据的迟到、容忍乱序的数据。
另外流计算中一般在对流数据进行操作之前都会先进行开窗，即基于一个什么样的窗口上做这个计算。Flink 提供了开箱即用的各种窗口，比如滑动窗口、滚动窗口、会话窗口以及非常灵活的自定义的窗口。
Flink API
最底层是 ProcessFunction，它能够提供非常灵活的功能，它能够访问各种各样的 State，用来注册一些 timer，利用 timer 回调的机制能够实现一些基于事件驱动的一些应用。
之上是 DataStream API，最上层是 SQL/Table API 的一种 High-level API。
Flink 的用途
Flink 能用来做什么？回顾一下 Flink up 前几站的分享，有非常多的嘉宾分享了他们在自己公司里面基于 Flink 做的一些实践，包括携程、唯品会、饿了么、滴滴、头条等等。他们的应用场景包括实时的机器学习，实时的统计分析，实时的异常监测等等。这些实践案例的共同点就是都用来做实时性的任务。
Flink Title 的变化
早期 Flink 是这样介绍自己的:『我是一个开源的流批统一的计算引擎』，当时跟 Spark 有点类似。后来Spark 改成了一长串的文字，里面有各种各样的形容词：『我是一个分布式的、高性能的、高可用的、高精确的流计算系统』。最近 Spark 又进行了修改：『我是一个数据流上的有状态的计算』。
通过观察这个变化，可以发现 Flink 社区重心的变迁，即社区现在主要精力是放在打造它的流计算引擎上。先在流计算领域扎根，领先其他对手几年，然后借助社区的力量壮大社区，再借助社区的力量扩展它的生态。