1.流计算基础概念
1.1 Dataflow图
Dataflow程序描述了数据如何在不同操作之间流动。Dataflow程序通常表示为有向图。图中顶点为算子，表示计算；而边表示数据依赖关系。算子
是Dataflow程序的基本单元，它们从输入获取数据，对其进行计算，然后产生数据并发往输出以供后续处理。没有输入端的算子成为数据源，没有出
输出端的算子称为数据汇。一个DataFlow图至少有一个数据源和一个数据汇。
1.2 数据并行和任务并行
将输入数据分组，让同一操作的多个任务并行执行在不同数据子集上，这种并行称为数据并行。让不同算子的任务（基于相同或不同的数据）并行计算，
这种并行称为任务并行。
1.3 数据交换策略
转发策略：在发送端任务和接受端任务之间一对一地进行数据传输。
广播策略：把每个数据项发往下游算子的全部并行任务。
基于键值的策略：根据某一键值属性对数据分区，并保证键值相同的数据项会交有同一任务处理。
1.4 延迟和吞吐
延迟：表示处理一个事件所需时间。本质上，它是从接受事件到在输出中观察到事件效果的时间间隔；即从你进入咖啡店门的一刻到你喝到第一口咖啡的时间
吞吐：用来衡量系统处理能力（处理速率）的指标，它告诉我们系统每单位时间可以处理多少事件。
背压：如果系统持续以力不能及的高速率接受数据，那么缓冲区可能会用尽，继而导致数据丢失，这种情形通常称为背压。
1.5 转换操作
转换操作是一类“只过一次”的操作，它们会分别处理每个事件。这些操作逐个读取事件，对其应用某些转换产生一条新的输出流。
1.6 滚动聚合
滚动聚合（如求和、求最小值和求最大值）会根据每个到来的事件持续更新结果。聚合操作都是有状态的，它们通过将新到来的事件合并到已有状态来生成更
新后的聚合值。
1.7 时间语义
处理时间：是当前流处理算子所在机器上的本地时钟时间。
事件时间：是数据流中时间发生的时间，它以附加在数据流中事件的时间戳为依据。
水位线：是一个全局指标，表示我们确信不会再有延迟时间到来的某个时间点。本质上，水位线提供了一个逻辑时钟，用来通知系统当前的事件时间，当一个
算子接受到时间为T的水位线，就可以认为不会再收到任何时间戳小于或等于T的事件了，水位线对于事件时间窗口还是处理乱序事件的算子都很关键。算子一
旦收到某个水位线，就相当于接受到信号：某个特定时间区间的时间戳已经到齐，可以触发窗口计算或对接受的数据进行排序了。激进的水位线策略保证了
低延迟，但随之而来的是低可信度。保守的水位线，虽然可信度得以保证，但可能会无谓地增加处理延迟。
1.8 状态
状态管理：系统需要高效管理状态并保证它们不受并发更新的影响。
状态划分：状态按照键值划分，并独立管理每一部分。
状态恢复：有状态算子需要保证状态可以恢复，并且即使出现故障也要确保结果正确。
1.10 任务故障
任务故障有可能发生如下三个步骤的其中之一：
1）接收事件并将它们存在本地缓冲区；
2）选择性地更新内部状态；
3）产生输出记录。
1.11 结果保障
1) 至多一次：保证每个事件至多被处理一次，换句话说，事件可以随意丢弃，没有任何机制来保证结果的正确性。这类保障也被称作“没有保障”，因为即便
系统丢掉所有事件也能满足其条件。如果你能接受近似结果并且仅关注怎样降低延迟，这种保障似乎也可以接受。
2) 至少一次：不丢事件，这类保障称为至少一次。意味着所有事件最终都会处理，虽然有些可能会处理多次，如果正确性仅依赖信息的完整度，那重复处理
或许可以接受。采取的办法是记录确认，该方法会将所有事件存放在缓冲区中，直到处理管道中所有任务都确认某个事件已经处理完毕才会将事件丢弃。
3) 精确一次：表示不但没有事件丢弃，而且每个事件对于内部状态的更新都只有一次。本质上，精确一次保障意味着应用总会提供正确的结果，就如同故障
从未发生过一般。Flink采用轻量级检查点机制来实现精确一次结果保障。
4) 端到端的精确一次：在整个数据处理管道上结果都是正确的。
2.Flink的设计理念
Flink 是一个纯流式的计算引擎，它的基本数据模型是数据流。流可以是无边界的无限流，即一般意义上的流处理。也可以是有边界的有限流，
这样就是批处理。 因此 Flink 用一套架构同时支持了流处理和批处理。
3.Flink 的特点
1). 流批统一
2). 支持高吞吐、低延迟、高性能的流处理
3). 支持带有事件时间窗口（Window）操作
4). 支持有状态计算的Exactly-once语义
5). 支持高度灵活的窗口（Window）操作，支持基于time、count、session窗口操作
6). 支持具有背压（Backpressure）功能的持续流模型
7). 支持基于轻量级分布式快照（Snapshot）实现的容错
8). 支持迭代计算
9). Flink 在JVM内部实现了自己的内存管理
10).支持程序自动优化，避免特定情况下Shuffle、排序等昂贵操作，中间结果有必要进行缓存
4. Flink 应用场景
4.1 事件驱动型应用
事件驱动型应用是一类具有状态的应用，该应用会根据事件流中的事件触发计算、更新状态或进行外部系统操作。 事件驱动型应用常见于实时计算业务中，
比如：实时推荐、金融反欺诈、实时规则预警等。
4.2 数据分析型应用
数据分析型应用是从原始数据中提取有价值的信息和指标。
4.3 数据分析型应用vs事件驱动型应用
4.4 数据管道&ETL应用
ETL (Extract-Transform-Load)从数据源抽取/转换/加载/数据至目的端的过程。ETL数据同步方式分为：增量同步、全量同步、实时同步
5.Flink与其他计算框架对比
| 框架 | 优点 | 缺点 |
|---|---|---|
| Storm | 低延迟 | 吞吐量低、不能保证exactly-once、编程API不丰富 |
| Spark Streaming | 吞吐量高、可以保证exactly-once、编程API丰富 | 延迟较高 |
| Flink | 低延迟、吞吐量高、可以保证exactly-once、编程API丰富 | 快速迭代中，API变化比较快 |
6.Flink与Spark Streaming 角色对比
| Spark Streaming | Flink |
|---|---|
| DStream | DataStream |
| Trasnformation | Trasnformation |
| Action | Sink |
| Task | SubTask |
| Pipeline | Oprator chains |
| DAG | DataFlow Graph |
| Master + Driver | JobManager |
| Work + Executor | TaskManager |
**下面我们就分几个方面对比两个框架的主要区别：**
1）架构模型Spark Streaming 在运行时的主要角色包括：Master、Worker、Driver、Executor，Flink 在运行时主要包含：Jobmanager、
Taskmanager和Slot。
2）任务调度Spark Streaming 连续不断的生成微小的数据批次，构建有向无环图DAG，Spark Streaming 会依次创建 DStreamGraph、
JobGenerator、JobScheduler。 Flink 根据用户提交的代码生成 StreamGraph，经过优化生成 JobGraph，然后提交给 JobManager进行处理，
JobManager 会根据 JobGraph 生成 ExecutionGraph，ExecutionGraph 是 Flink 调度最核心的数据结构，JobManager 根据
ExecutionGraph 对 Job 进行调度。
3）时间机制Spark Streaming 支持的时间机制有限，只支持处理时间。 Flink 支持了流处理程序在时间上的三个定义：处理时间、事件时间、
注入时间。同时也支持 watermark 机制来处理滞后数据。
4）容错机制对于 Spark Streaming 任务，我们可以设置 checkpoint，然后假如发生故障并重启，我们可以从上次 checkpoint 之处恢复，但是这
个行为只能使得数据不丢失，可能会重复处理，不能做到恰好一次处理语义。Flink 则使用两阶段提交协议来解决这个问题。
【学习资源】
跟星哥学习Flink
Apache Flink 知其然，知其所以然
Flink 中文社区