Flink篇-简介

是一个开源的分布式，高可用，高性能，准确的流处理框
主要由Java实现
支持流（stream）处理和批(batch)处理
flink原生支持迭代计算，内存管理和程序优化

优点

Flink的架构图

Flink的组件
DataSource: 数据源
Transformations: 算子（处理逻辑）
Data Sink：数据沉底（数据保存的位置）

流处理与批处理的区别
对于一个流处理系统，其节点的数据传输标准模型为：当一条数据被处理完之后，序列化到缓存
然后立刻通过网络传输到另一个节点，由另一个节点继续处理
对于一个批处理系统，其节点的数据传输标准模式为：当一条数据被处理完之后，序列化到缓存，并不会立马传输到另一个节点，当缓存写满，就持久到本地磁盘上，当所有数据都在当前节点处理完，才会立刻将处理后的数据传输到另一个节点。
这两种数据传输模式是两种极端，流处理对应的是低延迟的需求而批处理对应高吞吐量。
而Flink同时支持这两种模式，通过调整缓存块的值，可以达到这两种模式，缓存块为0，对应流处理，而缓存块无限大，对应批处理。

第一， Flink 具备统一的框架处理有界和无界两种数据流的能力
第二， 部署灵活，Flink 底层支持多种资源调度器，包括 Yarn、Kubernetes 等。Flink 自身带的 Standalone 的调度器，在部署上也十分灵活。
第三， 极高的可伸缩性，可伸缩性对于分布式系统十分重要，阿里巴巴双 11 大屏采用 Flink 处理海量数据，使用过程中测得 Flink 峰值可达 17 亿 / 秒。
第四， 极致的流式处理性能。Flink 相对于 Storm 最大的特点是将状态语义完全抽象到框架中，支持本地状态读取，避免了大量网络 IO，可以极大提升状态存取的性能。

开发实践
Java开发

scala开发










Source中的执行顺序为：
open()–>run()–>close()
自定义的Source需要继承RichSourceFunction

Sink中的执行顺序
继承 RichSinkFunction 抽象类，重写 invoke 方法
open()-invoke()-close()

Time
分为Event Time ，Ingestion Time和Window processing Time
Event Time : 事件时间
Ingestion Time：进入Flink的时间
Window processing Time ：达到window 中 Flink中处理的时间
通常我们所需要的为Event Time

Window （将无限的流分割成有限大的buckets)
CountWindow : 按照指定的数据条数生成一个Window,与时间无关
TimeWindow: 按照时间生成Window
TimeWindow按照原理不同又可以分为Tumbling Window 滚动窗口 Sliding滑动窗口 Session Window会话窗口

Tumbling Window : 时间对齐，窗口大小固定，没有重叠 （一个参数，窗口大小）
Sliding ：时间对齐，窗口大小固定，有重叠 （两个参数，窗口大小，滑动频率）

流处理架构

主要分为消息传输层和流处理层

状态

Row state不太常用，使用复杂

Manager state又分为一下两种

容错机制与故障恢复（确保不丢不重）

如何制作checkpoint

第二行代码：设置每1秒制作一个checkpoint
第三行：设置checkpoint的模式
第4行：设置两个checkpoint最小的等待时间，避免过于频繁制作checkpoint，消耗io
第五行：设置制作checkpoint的超时时间
第六行：设置同时有多少checkpoint在做




Table API

通过state TTL config解决状态的无限增长。

Flink Runtime解析

FLINK运行时的相关组件

Flink支持的数据类型

flink序列化最长见的场景：

Metric:指标

Graph
StreamGraph：是根据用户通过Stream API编写的代码生成的最初的图。表示程序的拓扑结构。
JobGraph： StreamGraph经过优化后生成了JobGraph，提交给JobManager的数据结构。主要的优化为，将多个符合条件的中断链连在一起作为一个节点，这样可以减少数据在数组之间流动所需要的序列化/反序列化/传输消耗。
ExecutionGraph： JobManager根据JobGraph生成ExecutionGraph。ExecutionGraph是JobGraph的并行化版本，是调度层最核心的数据结构。
物理执行图： JobManager根据ExecutionGraph对Job进行调度后，在各个TaskManager上部署Task后形成的“图”，并不是一个具体的数据结构。

状态后台的选择