Flink是一个低延迟、高吞吐的实时计算引擎，其利用分布式一致性快照实现检查点容错机制，并实现了更好的状态管理，Flink可在毫秒级的延迟下处理上亿次/秒的消息或者事件，同时提供了一个Exactly-once的一致性语义，保证了数据的正确性，使得Flink可以提供金融级的数据处理能力，总结其高级特性包括CSTW(CheckPoint，Statue，Time，windows)
Flink和Spark对比
设计思路
Spark的技术理念是基于批来模拟流，微批处理的延时较高（无法优化到秒以下的数量级），且无法支持基于event_time的时间窗口做聚合逻辑。Flink和spark相反，它基于流计算来模拟批计算，更切合数据的生成方式，技术上有更好的扩展性。
状态管理
流处理任务要对数据进行统计，如Sum, Count, Min, Max,这些值是需要存储的，因为要不断更新，这些值或者变量就可以理解为一种状态，如果数据源是在读取Kafka, RocketMQ，可能要记录读取到什么位置，并记录Offset，这些Offset变量都是要计算的状态。
Flink提供了内置的状态管理，可以把这些状态存储在Flink内部，而不需要把它存储在外部系统，这样做的好处：① 降低了计算引擎对外部系统的依赖以及部署，使运维更加简单；② 对性能带来了极大的提升：如果通过外部去访问如Redis , HBase 需要网络及RPC资源，如果通过Flink内部去访问，只通过自身的进程去访问这些变量。
同时Flink会定期将这些状态做Checkpoint持久化，把Checkpoint存储到一个分布式的持久化系统中，比如HDFS，这样当Flink的任务出现任何故障时，它都会从最近的一次Checkpoint将整个流的状态进行恢复，然后继续运行它的流处理，对用户没有任何数据上的影响。
设计架构
Flink是一个分层的架构系统，每一层所包含的组件都提供了特定的抽象，用来服务于上层组件，Flink的分层体现有四层，分别是Deploy层、core层、API层/Libraries层，其中Deploy层主要涉及的是Flink的部署模式及同资源调度组件的交互模式，Core层提供了支持Flink计算的全部核心实现，API层/Libraries层提供了Flink的API接口和基于API接口的特定应用的计算框架；
Deploy层：该层主要涉及了Flink的部署模式，Flink支持多种部署模式：本地、集群（Standalone/YARN）、云（GCE/EC2），Standalone 部署模式与Spark类似；
Runtime层：Runtime层提供了支持Flink计算的全部核心实现，比如：支持分布式Stream处理、Job Graph到Execution Graph的映射、调度 等，为上层API层提供基础服务。
API层：API层主要实现了面向无界Stream的流处理和面向Batch的批处理API，其中面向流处理对应DataStream API，面向批处理对应DataSet API。
Libraries层：该层也可以称为Flink应用框架层，根据API层的划分，在API层之上构建的满足特定应用的实时计算框架，也分别对应于面向流处理 和面向批处理两类。面向流处理支持：CEP（复杂事件处理）、SQL-like的操作（基于Table的关系操作）；面向批处理支持： FlinkML（机器学习库）、Gelly（图处理）。
Flink on yarn
Flink支持增量迭代，具有对迭代自行优化的功能，因此在on yarn上提交的任务性能略好于 Spark，Flink提供2种方式在yarn上提交任务：启动1个一直运行的 Yarn session（分离模式）和在 Yarn 上运行1个 Flink 任务(客户端模式)；
流程分析
参考：https://www.cnblogs.com/leesf456/p/11136344.html
分离模式：通过命令yarn-session.sh先启动集群，然后再提交作业，接着会向yarn申请一块空间后，资源永远保持不变。如果资源满了，下一个作业就无法提交，只能等到yarn中的其中一个作业执行完成后，释放了资源，下个作业才会正常提交。所有作业共享Dispatcher和ResourceManager；共享资源；适合规模小执行时间短的作业。
客户端模式：通过命令bin/flink run -m yarn-cluster提交任务，每提交一个作业会根据自身的情况，都会单独向yarn申请资源，直到作业执行完成，一个作业的失败与否并不会影响下一个作业的正常提交和运行，适合规模大长时间运行的作业；
（后面没看懂）