近段时间，由于公司项目的相关需求，需要对Flink做详细的梳理，我把学习过程整理成Flink详解系列的10篇左右的总结，供大家参考。
大数据计算引擎的发展
近年来随着大数据的发展，涌现出了一大批开源的大数据处理引擎，比如hadoop, storm, spark等。国外的一些社区将这些大数据计算引擎分为4代：
第一代以hadoop承载的mapreduce为标志，开启了大数据处理的先河。mapreduce将处理过程分为map和reduce两个阶段，对于复杂应用，需要拆分为多个mapreduce的job, 并有应用层去管理各个job的依赖关系。
第二代以支持DAG框架为标志，也是以批处理为主，具体如Tez，以及更上层的Oozie。
第三代以spark为代表，开启了内存计算的时代，支持job内部DAG管理，同时支持流处理、批处理，并提供SQL高层API支持。
第四代就该系列要介绍的Flink，主要是由于Flink对流计算的支持。
Flink于2014年12月成为Apache软件基金会的顶级项目，2015年9月发布第一个稳定版本0.9，到目前为止已经发布到1.12版本，社区非常活跃。
全球有越来越多的公司在使用Flink, 国内主流互联网公司都在大规模使用Flink作为企业分布式大数据处理引擎。Flink之所以如此受到青睐，除了其提供高吞吐、低延迟和Exactly-once一致性语义支持外，更重要的是它能以流数据的处理方式来处理批数据，可以真正意义上实现批流处理的统一。正是由于这些特性，使Flink逐渐成为主流的大数据处理框架，并将在不久的将来成为下一代大数据处理的标准。
Flink架构
Flink是一个分布式系统，它的运行涉及到多个进程，这些进程会分布到集群的多台不同机器上。分布式系统就需要面对这样的几个问题：分配和管理集群计算资源，进程协调，持久且高可用的数据存储及故障恢复等。
Flink并不依靠自身去实现这些功能，而是在已有集群基础设施和服务之上专注于它的核心功能--分布式流数据处理。它和很多集群管理器（比如：YARN、Mesosd等）能很好的集成，也可以独立运行。它不提供分布式持久化存储，而是使用现有的分布式文件系统（HDFS）和对象存储（S3）。它使用ZooKeeper来完成可用性配置中的领导选举工作。
1、任务提交过程
以YARN作为资源管理器为例，Flink任务提交后，Client向HDFS上传Flink的Jar包和配置，之后向Yarn资源管理器提交任务，资源管理器分配容器资源并通知对应的NodeManager启动ApplicationMaster，ApplicationMaster启动后加载Flink的Jar包和配置构建环境，然后启动JobManager，之后ApplicationMaster向资源管理器申请资源启动TaskManager，资源管理器分配容器资源后，由ApplicationMaster通知资源所在节点的NodeManager启动TaskManager，NodeManager加载Flink的Jar包和配置构建环境并启动TaskManager，TaskManager启动后向JobManager发送心跳包，并等待JobManager向其分配任务。
2、运行架构
从上面的Flink任务执行图可以看到，运行时有两个主要的进程：JobManager和TaskManager。client不是Flink程序运行时和程序执行的一部分，它主要负责准备和提交dataFlow到JobManager， 并接收JobManager返回的程序执行结果。
JobManager负责协调Flink程序的执行，包括：任务的调度、任务运行完成与失败的处理，协调检查点与恢复等，主要包括以下项职能：
ResourceManager：负责资源分配，管理任务slot, 这个是flink集群资源管理的单位。
Dispatcher：提供应用程序提交的REST接口，对每一个提交的作业启动JobMaster，并运行Flink WebUI提供作业执行的信息。
JobMaster：负责单个作业图（JobGraph）的执行。一个集群可以同时运行多个作业，每个作业都有自己的JobMaster。
TaskManager负责执行dataflow中的任务，缓存和交换数据流。一个作业执行时，至少要有一个TaskManager,TaskManager中资源调度的最小单位是slot。一个TaskManager中的slot数表示的是该TaskManager中可以并行执行任务的数量
3、任务和算子链
为方便执行，Flink将不同算子的子任务（subtask）链接到一个任务里，每一个任务在一个线程中执行。这是一个非常有用的优化方式，它减小了进程间数据交换和缓存的开销，而且在减少延迟同时增加了吞吐量。这种链接关系是可配置的，下面是一个有5个子任务(subtask)的示例，有5个线程并行执行。
4、任务Slot和资源
每个worker（TaskManager）都是一个JVM进程，可以执行一个或多个子任务（subtask）。任务槽（task slot）就是为了控制一个worker能同时运行多少个任务的（至少一个）。
每个任务槽(task slot)代表TaskManager一个设定的资源子集。比如， 一个TaskManager有3个槽，会将其管理的1/3的内存分给每个槽位。将资源分成不同的槽位意味着一个子任务（subtask）不会跟其他作业的子任务竞争资源，而是会拥有一定量的保留资源。需要注意的是，这里不涉及CPU隔离，目前任务槽仅仅分割task管理的内存。
为了适配任务槽（task slot）的数量，用户可以定义子任务（subtask）是如何隔离的。如果每个TaskManager有一个槽，就意味着task组运行在不同的GJVM里。如果每个TaskManager有多个槽意味着多个字任务（subtask）共享同一个JVM。任务在同一个JVM运行可以共享TCP链接和心跳信息。它们可以共享数据集和数据结构，因此可以减少每个任务的开销。
