Flink编程模型

4.1 抽象的层级

• 有状态的数据流处理层。最底层的抽象仅仅提供有状态的数据流，它通过处理函数（Process Function）嵌入到数据流api(DataStream API). 用户可以通过它自由的处理单流或者多流，并保持一致性和容错。同时用户可以注册事件时间和处理时间的回调处理，以实现复杂的计算逻辑。
• 核心API层，DataSet 处理有界的数据集，DataStream 处理有界或者无界的数据流。它提供了数据处理的基础模块，像各种transformation, join,aggregations,windows,stat 以及数据类型等等。用户可以通过各种方法（map / flatmap / window / keyby / sum / max / min / avg / join 等）将数据进行转换 / 计算。
• Table API层。 是以关系表为中心的声明式DSL(领域描述语言)，其中表可能会动态变化（在表达流数据时）。Table API遵循了关系模型的标准：Table类型关系型数据库中的表，API也提供了相应的操作，像select,project,join,group-by,aggregate等。Table API声明式的定义了逻辑上的操作（logical operation）不是code for the operation；Flink会对Table API逻辑在执行前进行优化。同时代码上，允许程序将 Table API 与 DataStream 以及 DataSet 混合使用。
• SQL层。是Flink 提供的最高层级的抽象，它很类似Table API的语法和表达，但是是以 SQL查询表达式的形式表现程序。SQL 抽象与 Table API 交互密切，同时 SQL 查询可以直接在 Table API 定义的表上执行。

4.2 代码结构

Flink系统核心可分为多个子项目。分割项目旨在减少开发Flink程序需要的依赖数量，并对测试和开发小组件提供便捷。

1. Flink-dist：distribution项目。它定义了如何将编译后的代码、脚本和其他资源整合到最终可用的目录结构中。
2. Flink-quick-start：有关quickstart和教程的脚本、maven原型和示例程序
3. flink-contrib：一系列有用户开发的早起版本和有用的工具的项目。后期的代码主要由外部贡献者继续维护，被flink-contirb接受的代码的要求低于其他项目的要求。

4.3 程序和数据流

Flink程序时由Stream和Transformation这两个基本构建块组成，其中Stream是一个中间结果数据，而Transformation是一个操作，它对一个或多个输入Stream进行计算处理，输出一个或多个结果Stream。从数据源提取数据的操作叫做Source Operator，中间的map()、聚合、统计等操作可以统称为Tranformation Operators，最后结果数据的流出被称为sink operators。

当一个Flink程序被执行的时候，它会被映射为Streaming Dataflow。一个Streaming Dataflow是由一组Stream和Transformation Operator组成，它类似于一个DAG图，在启动的时候从一个或多个Source Operator开始，结束于一个或多个Sink Operator。下面是一个由Flink程序映射为Streaming Dataflow的示意图，如下所示：

上图中，FlinkKafkaConsumer是一个Source Operator，map、keyBy、timeWindow、apply是Transformation Operator，RollingSink是一个Sink Operator。

1、Source: 数据源，Flink 在流处理和批处理上的 source 大概有 4 类：基于本地集合的 source、基于文件的 source、基于网络套接字的 source、自定义的 source。自定义的 source 常见的有 Apache kafka、Amazon Kinesis Streams、RabbitMQ、Twitter Streaming API、Apache NiFi 等，当然你也可以定义自己的 source。

2、Transformation：数据转换的各种操作，有 Map / FlatMap / Filter / KeyBy / Reduce / Fold / Aggregations / Window / WindowAll / Union / Window join / Split / Select / Project 等，操作很多，可以将数据转换计算成你想要的数据。

3、Sink：接收器，Flink 将转换计算后的数据发送的地点 ，你可能需要存储下来，Flink 常见的 Sink 大概有如下几类：写入文件、打印出来、写入 socket 、自定义的 sink 。自定义的 sink 常见的有 Apache kafka、RabbitMQ、MySQL、ElasticSearch、Apache Cassandra、Hadoop FileSystem 等，同理你也可以定义自己的 sink。

4.4 并行数据流

Flink的程序内在是并行和分布式的，一个Stream可以被分成多个Stream分区（Stream Partitions），一个Operator可以被分成多个Operator Subtask，每一个Operator Subtask是在不同的容器中分不同的线程中独立执行。一个Operator的并行度，等于Operator Subtask的个数，一个Stream的并行度总是等于生成它的Operator的并行度。程序不同的operator阶段可能有不同的并行数，如下图所示，source operator的并行数为2，但最后的sink operator为1。

数据在两个operator之间传递的时候有两种模式：

One-to-one模式：两个operator用此模式传递的时候，会保持数据的分区数和数据的排序；
比如从Source[1]到map()[1]，它保持了Source的分区特性（Partitioning）和分区内元素处理的有序性，也就是说map()[1]的Subtask看到数据流中记录的顺序，与Source[1]中看到的记录顺序是一致的。

Redistribution模式

这种模式会改变数据的分区数；每个一个operator subtask会根据选择transformation把数据发送到不同的目标subtasks,比如keyBy()会通过hashcode重新分区,broadcast()和rebalance()方法会随机重新分区；

这种模式改变了输入数据流的分区，比如从map()[1]、map()[2]到keyBy()/window()/apply()[1]、keyBy()/window()/apply()[2]，上游的Subtask向下游的多个不同的Subtask发送数据，改变了数据流的分区，这与实际应用所选择的Operator有关系。

上图Streaming Dataflow的并行视图中，展现了在两个Operator之间的Stream的两种模式：

• One-to-one模式：比如从Source[1]到map()[1]，它保持了Source的分区特性（Partitioning）和分区内元素处理的有序性，也就是说map()[1]的Subtask看到数据流中记录的顺序，与Source[1]中看到的记录顺序是一致的。
• Redistribution模式：这种模式改变了输入数据流的分区，比如从map()[1]、map()[2]到keyBy()/window()/apply()[1]、keyBy()/window()/apply()[2]，上游的Subtask向下游的多个不同的Subtask发送数据，改变了数据流的分区，这与实际应用所选择的Operator有关系。
  另外，Source Operator对应2个Subtask，所以并行度为2，而Sink Operator的Subtask只有1个，故而并行度为1。

4.5 任务、操作符链

对于分布式计算，Flink封装operator subtasks 链化为tasks;每个task由一个线程执行；把tasks链化有助于优化，它减少了开销线程和线程之间的交接和缓冲；增加了吞吐量和减少延迟时间；链化的作用可以见下图：在没有链化之前，source operator和map operator 是两个线程运行的两个task，也就是说下面的dataflow 最初应该有7个subtasks;

Flink分布式执行环境中，会将多个Operator Subtask串起来组成一个Operator Chain，实际上就是一个执行链，每个执行链会在TaskManager上一个独立的线程中执行。

但经过优化链化后，source和map合并为一个task，有一个线程执行，这样优化可以减少source operator 和map operator两个线程之间的交接和缓存开销；链化后只有5个task。