Flink原理
Flink 是可以同时支持高吞吐、低延迟、高性能的分布式处理框架
国内比较出名的互联网公司如阿里巴巴、美团、滴滴等，都在大规模使用flink作为企业的分布式大数据处理引擎
Flink逐渐被人们所熟知，不仅是因为flink提供同时支持高吞吐、低延迟和exactly-once语义的实时计算能力，同时flink还提供了基于流式计算引擎处理批量数据的计算能力，真正意义上实现了批流统一
一、Flink的优势：
- 同时支持高吞吐、低延迟、高性能 ：
Flink是目前开源社区中唯一一套集这3者于一身的分布式流式数据处理框架。像apache spark也只能兼顾高吞吐和高性能，主要是因为在spark streaming流式计算中无法做到低延迟保障；而流式计算框架apache storm只能支持低延迟和高性能特性，无法满足高吞吐的要求
- 支持事件时间（event time）概念：
在流式计算领域中，窗口计算的地位举足轻重，但目前大多数框架窗口计算采用的都是系统时间（process time），也就是时间传输到计算框架处理时，系统主机的当前时间。Flink能支持基于时间（event time）语义进行窗口计算，即使用事件产生的时间，这种基于事件驱动的机制使得事件及时乱序达到，流系统也能够计算出精确的结果，保持了时间原本产生时的时序性，尽可能避免网络传输或者系统的影响
- 支持有状态计算：
Flink在1.4版本实现了状态管理，所谓状态就是在流式计算过程中将算子的中间结果数据保存在内存或者文件系统中，等下一个事件进入算子后可以从之前的状态中获取中间结果，来计算当前的结果，从而无须每次都基于全部的原始数据来统计结果，这种方式极大的提升了系统的性能，并降低了数据计算过程中的资源消耗。
- 支持高度灵活的窗口（window）操作：
在流处理应用中，数据是连续不断的，需要通过窗口的方式对流数据进行一定范围的聚合计算，例如统计在过去1分钟内有多少用户点击某一网页，在这种情况下，我们必须定义一个窗口，用来收集最近1分钟内的数据，并对这个窗口内的数据进行在计算。
Flink将窗口划分为基于time、count、session，以及data_driven等类型的窗口操作，窗口可以用灵活的触发条件定制化来达到对复杂流传输模式的支持，用户可以定义不同的窗口触发机制来满足不同的需求
- 基于轻量级分布式快照（snapshot）实现的容错：
Flink能够分布式运行在上千个节点上，将一个大型计算任务的流程拆解成小的计算过程，然后将task分布到并行节点上进行处理。在任务执行过程中，能够自动发现事件处理过程中的错误而导致数据不一致的问题，如：节点宕机、网络传输问题、或者时由于用户因为升级或者修复问题而导致计算服务重启等。在这些情况下，通过基于分布式快照技术的checkpoints，将执行过程中的状态信息进行持久化存储，一旦任务出现异常停止，flink就能够从checkpoints中进行任务的自动恢复，以确保数据处理过程中的一致性
- 基于JVM实现独立的内存管理：
内存管理是所有计算框架需要重点考虑的部分，尤其是对于计算量比较重大的计算场景，数据在内存中该如何进行管理显得至关重要。针对内存管理，flink实现了自身管理内存的机制，尽量减少JVM GC对系统的影响。另外，flink通过序列化/反序列化方法将所有的数据对象转成二进制在内存中存储，降低数据存储的大小的同时，能够更加有效的对内存空间进行利用，降低GC带来的性能下降或者任务异常的风险，因此flink较其他分布式处理的架构会更显的更加稳定
- Save Points(保存点)：
对于7*24小时运行的流式应用，数据源源不断的接入，在一段事件内应用的终止有可能导致数据的丢失或者计算结果的不准确，如：进行集群版本的升级、停机运维操作等。值得一提的是，flink通过save points技术将任务自行的快照保存在存储介质上，当任务重启的时候可以直接从事先保存的save points恢复原有的计算状态，使得任务继续按照停机前的状态运行，save points计算可以让用户更好的管理和运维实时流应用
二、Flink应用场景
- 实时智能推荐
- 复杂事件处理
- 实时欺诈检测
- 实时数仓与ETL类型
- 流数据分析类型
- 实时报表类型等实时业务场景
三、Flink基本架构
1.基本组件栈
在flink整个基本架构体系中，同样遵循着分层的架构设计理念，在降低系统耦合度的同时，也为上层用户构建flink应用提供了丰富且友好的接口
Flink架构体系基本上分三层（自顶向下）：API&Libraries层、Runtime核心层、物理部署层
1. 1 API&Libraries层
Flink同时提供了支撑流计算和批计算的接口，同时在此基础上抽象出不同的应用类型组件库，如基于流处理的CEP（复杂事件处理库）、SQL&Table库和基于批处理的FlinkML（机器学习库）等、Gelly(图处理库)等。
API层包括构建流计算应用的DataStream API和批计算应用的DataSet API，两者都提供给用户丰富的数据处理高级API，例如Map、FlatMap操作等，同时也提供比较低级的ProcessFunction API，用户可以直接操作状态和事件等底层数据
1.2 Runtime核心层
该层主要负责对上层不同接口提供基础服务，也是Flink分布式计算框架的核心实现层，支持分布式Stream作业的执行、JobGraph到ExecutionGraph的映射转换、任务调度等。将DataStream和DataSet转成统一的可执行的TaskOperator，达到在流式引擎下同时处理批量计算和流式计算的目的
1. 3 物理部署层
该层主要涉及Flink的部署模式，目前Flink支持多种部署模式：本地、集群（Standalone/YARN）、云（GCE/EC2）、Kubenetes。Flink能够通过该层支持不同的平台部署，用户可以根据需要选择使用对应的部署模式
2.基本架构
Flink整个系统主要由2个组件组成：JobManager和TaskManager。Flink架构也遵循Master-Slave架构设计原则，JobManager为Master节点，TaskManager为Workwer（slave）节点。所有组件之间的通信都是借助于Akka 来实现，包括任务的状态以及CheckPoint触发信息。
Flink基本架构图
2.1 Client客户端
客户端负责将任务提交到集群，与JobManager构建Akka连接，然后将任务提交到JobManager，通过和JobManager之间进行交互获取任务执行状态。
客户端你提交任务可以采用CLI方式或者通过使用FlinkWebUI提交，也可以在应用程序中指定JobManager的RPC网络端口构建ExecutionEnvironment提交Flink应用
2. 2 JobManager
JobManager负责整个Flink集群任务的调度以及资源的管理：从客户端中获取提交的应用，然后根据集群中的TaskManager上的TaskSlot的使用情况，为提交的应用分配相应的TaskSlot资源并命令TaskManager启动从客户端获取的应用。
JobManager相当于整个集群的Master节点，且整个集群中有且仅有一个活跃的JobManager，负责整个集群的任务管理和资源管理。
JobManager和TaskManager之间通过Actor System进行通信，获取任务执行的情况并通过Actor System将应用的任务执行情况发送给客户端。同时在任务执行过程中，Flink JobManager会触发Checkpoints操作，每个TaskManager节点收到Checkpoint触发指令后，完成Checkpoint操作，所有的Checkpoint协调过程都是在 Flink JobManager中完成。当任务完成后，Flink会将任务执行信息反馈给客户端，并且释放掉TaskManager的资源以供下一次提交任务使用
2.3 TaskManager
TaskManager相当于整个集群的Slave节点，负责每个的任务执行和对应任务在每个节点上的资源申请与管理。
客户端通过将编写好的Flink应用编译打包，提交到JobManager,然后JobManager会根据已经注册在JobManager中的TaskManager资源情况，将任务分配给有资源的TaskManager节点，然后启动并运行任务。
TaskManager从JobManager接收需要部署的任务，然后使用Slot资源启动Task，建立数据接入的网络连接，接收数据并开始数据处理。同时TaskManager之间的数据交互都是通过数据流的方式进行的。
可以看出，Flink的任务运行其实是采用多线程的方式，这和MapReduce多JVM进程的方式有很大的区别，Flink能够极大提高CPU使用效率，在多个任务和Task之间通过TaskSlot方式共享系统资源，每个TaskManager中通过管理多个TaskSlot资源池进行对资源的有效管理
