wt334502157的博客

​ 动态表( Dynamic Tables ) 是 Flink 的支持流数据的 Table API 和 SQL 的核心概念。与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们。查询动态表将生成一个连续查询( Continuous Query )。一个连续查询永远不会终止，结果会生成一个动态表。查询不断更新其动态结果表，以反映其动态输入表上的更改。需要注意的是，连续查询的结果在语义上总是等价于以批处理模式在输入表快照上执行的相同查询的结果。

​ 流的barrier是Flink的Checkpoint中的一个核心概念。可以理解成流数据中加入一个个分界线，多个barrier被插入到数据流中，然后作为数据流的一部分随着数据流动( 有点类似于Watermark )。这些barrier不会跨越流中的数据。​ 每个barrier会把数据流分成两部分: 一部分数据进入当前的快照 , 另一部分数据进入下一个快照。每个barrier携带着快照的id。barrier 不会暂停数据的流动，所以非常轻量级。

​ Operator State算子状态可以用在所有算子上，每个算子子任务或者说每个算子实例共享一个状态，流入这个算子子任务的数据可以访问和更新这个状态注意: 算子子任务之间的状态不能互相访问​ 算子状态的作用范围限定为算子任务。这意味着由同一并行任务所处理的所有数据都可以访问到相同的状态，状态对于同一任务而言是共享的。算子状态不能由相同或不同算子的另一个任务访问。

支持event time的流式处理框架需要一种能够测量event time 进度的方式。比如一个窗口算子创建了一个长度为1小时的窗口，那么这个算子需要知道事件时间已经到达了这个窗口的关闭时间，从而在程序中去关闭这个窗口。​ 事件时间可以不依赖处理时间来表示时间的进度。例如在程序中, 即使处理时间和事件时间有相同的速度，事件时间可能会轻微的落后处理时间。另外一方面，使用事件时间可以在几秒内处理已经缓存在Kafka中多周的数据，这些数据可以照样被正确处理，就像实时发生的一样能够进入正确的窗口。

窗口分为两大类: - 基于时间的窗口 - 时间窗口以时间点到来定义窗口的开始（start）和结束（end），所以截取出的就是某一时间段的数据。到达时间时，窗口不再收集数据，触发计算输出结果，并将窗口关闭销毁 - 窗口大小 = 结束时间 - 开始时间- 基于元素个数 - 基于元素的个数来截取数据，到达固定的个数时就触发计算并关闭窗口 - 只需指定窗口大小，就可以把数据分配到对应的窗口中

独立部署（Standalone）模式由Flink自身提供计算资源，无需其他框架提供资源，这种方式降低了和其他第三方资源框架的耦合性，独立性非常强。但Flink主要是计算框架，而不是资源调度框架，所以本身提供的资源调度并不是它的强项，生产环境普遍采用专业的资源调度框架集成搭配使用，在国内工作环境中，搭配Yarn使用的非常普遍

flink1.12.0学习笔记第1篇-部署与入门 https://blog.youkuaiyun.com/wt334502157/article/details/127258751flink1.12.0学习笔记第2篇-流批一体API https://blog.youkuaiyun.com/wt334502157/article/details/127258835flink1.12.0学习笔记第3篇-高级API https://blog.youkuaiyun.com/wt334502157/article/details/127258

​ 由于集群运行后很难发现内部的实际状况，跑得慢或快，是否异常等，开发人员无法实时查看所有的 Task 日志，比如作业很大或者有很多作业的情况下，该如何处理？此时 Metrics 可以很好的帮助开发人员了解作业的当前状况。Flink 提供的 Metrics 可以在 Flink 内部收集一些指标，通过这些指标让开发人员更好地理解作业或集群的状态。

在开发过程中，如果遇到需要下发/广播配置、规则等低吞吐事件流到下游所有 task 时，就可以使用 Broadcast State。Broadcast State 是 Flink 1.5 引入的新特性。下游的 task 接收这些配置、规则并保存为 BroadcastState, 将这些配置应用到另一个数据流的计算中场景举例动态更新计算规则: 如事件流需要根据最新的规则进行计算，则可将规则作为广播状态广播到下游Task中。

flink1.12.0学习笔记第 5 篇-业务案例实践。

Flink的Table模块包括 Table API 和 SQL：Table API 是一种类SQL的API，通过Table API，用户可以像操作表一样操作数据，非常直观和方便SQL作为一种声明式语言，有着标准的语法和规范，用户可以不用关心底层实现即可进行数据的处理，非常易于上手Flink Table API 和 SQL 的实现上有80%左右的代码是公用的。作为一个流批统一的计算引擎，Flink 的 Runtime 层是统一的Table API & SQL的特点。

​ 实际开发中我们希望基于事件时间来处理数据，但因为数据可能因为网络延迟等原因，出现了乱序或延迟到达，那么可能处理的结果不是我们想要的甚至出现数据丢失的情况，所以需要一种机制来解决一定程度上的数据乱序或延迟到底的问题！Watermaker水印机制/水位线机制可以解决这样的乱序情况。Watermaker就是给数据再额外的加的一个时间列，也就是Watermaker是个时间戳概念Flink为了方便不同分类的State的存储和管理,提供了如下的API/数据结构来存储State。

​ Flink 诞生于欧洲的一个大数据研究项目 StratoSphere。该项目是柏林工业大学的一个研究性项目。早期， Flink 是做 Batch 计算的，但在 2014 年， StratoSphere 里面的核心成员孵化出 Flink，同年将 Flink 捐赠 Apache，并在后来成为 Apache 的顶级大数据项目，同时 Flink 计算的主流方向被定位为 Streaming， 即用流式计算来做所有大数据的计算，这就是 Flink 技术诞生的背景。