flink学习（一）概述

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memory speed and at any scale.
根据定义：Apache Flink是一个框架和分布式处理引擎，用于有状态的计算有界和无界数据流。Flink可以在所有常见的集群环境上运行，并且可以在内存上执行任何规模的数据计算。

一、常见的集中数据处理架构：

1、 传统事务处理架构：

将数据存储在传统关系型数据库中，通过前端各种应用事件驱动进行反馈，若需要提高吞吐量，可使用分布式思想增加集群机器数量，优点：响应速度快，实时性好，可支持高吞吐量。缺点：无法支持较大数据量的复杂计算（多表联查等复杂计算时间长）。

2、 离线的分析处理架构：

也就是我们上次提到的批处理，将每个批次的数据进行处理，其实是一种离线处理方式。优点：能对数据进行长久保存，且支持大数据量的复杂计算，数据准确性较高。缺点：实时性不高（因需要进行ETL、存放在数据仓库、计算等过程），有延迟。

二、针对流处理，有如下发展过程：

1、 传统事务处理架构：

以上两种方式都有各自的优缺点，那么想要将两种方式的优点结合，就有了这种有状态的流处理结构。首先，可以通过将原本存储于关系型数据库中的数据放于本地内存状态，根据本地内存状态对前端应用的请求进行数据处理，结合分布式集群，可保证高吞吐量，支持高并发。其次，因在内存中计算，不能大量保存数据且不稳定，为防止集群中某个节点出问题，需要实现存盘和故障恢复机制，设定了周期性的检查点（checkpoint）定时将内存中的数据进行备份，以便后续如有需要，进行数据恢复的容错处理。此为第1代流处理框架，因引入分布式集群，在集群中无法保证数据处理的顺序，会存在数据顺序错乱的问题。以strom框架为代表。

2、 Lambda架构：

为解决第1代架构存在的问题，有了第2代流处理架构，使用两套系统，既能保证数据的低延迟实时性，也能保证数据结果的准确性。但是存在问题，即当时看到的处理好的数据，可能跟之后批量跑出后调整的数据不相同，且两套系统的开发难度较大，要保证两套系统处理出的数据没有误差。

3、 Flink：

相当于第3代流处理框架，特点主要是：可以处理有界和无界数据流、可以单独使用也可以部署在任何地方、可以执行任意规模的应用、可以利用内存性能。

三、Flink的层级：

1、有状态的流处理（Stateful Stream Processing）：

最低级别的版块仅提供了有状态和及时的流处理。它通过Process Function嵌入到DataStream API中。允许用户自由地处理来自一个或多个流的事件，并提供一致的容错状态。此外，用户可以根据事件发生时间和处理时间进行回调，支持复杂的计算。

2、核心API（DataStream/DataSet API）：

在实际中，很多时候并不需要对底层进行开发，而是可以针对核心 API 进行编程： DataStream API （处理流数据，包括有界/无界流）和DataSet API（批量处理有界数据集）。这些流畅的 API 为数据处理提供了通用的构建块，例如各种形式的用户指定的转换、连接、聚合、窗口、状态等。在这些 API 中处理的数据类型在各自的编程语言中表示为类。低级Process Function与DataStream API集成，可以根据需要使用低级抽象。
DataSet API提供了关于有界数据集的附加原语，例如循环/迭代。

Table API是一个以表为中心的声明性 DSL ，它可以是动态变化的表（当表示流时）。Table API遵循（扩展）关系模型：表附加了一个模式（类似于关系数据库中的表），并且 API 提供了类似的操作，例如选择、项目、连接、分组、聚合等。 Table API 程序以声明方式定义应该执行的逻辑操作， 而不是准确指定操作代码的外观。尽管 Table API 可以通过各种类型的用户定义函数进行扩展，但它的表达能力不如Core API，并且使用起来更简洁（编写的代码更少）。此外，Table API 程序还经过一个优化器，在执行前应用优化规则。

可以在表和DataStream / DataSet之间无缝转换，允许程序将Table API与DataStream和 DataSet API 混合使用。