pblh123的专栏

在 Flink1.9 之前，开发人员如果需要处理批计算和流计算，需要同时掌握两种编程接口，对应的业务代码也是两套。一直到 2019 年阿里巴巴 Blink 团队在 Blink 中实现了 Table API 和 SQL，并将 Blink 贡献给 Flink 社区之后，这一问题才得以解决。由于 Table API 和 SQL 出现的时间较晚，所以功能尚不完善，但是已有功能已经可以解决开发人员的很多困难。根据上图我们可以看到，Flink 中最底层的编程接口是，在其的上面一层就是。

在本节实验中，我们介绍了 Flink 中的三个时间语义（Event Time、Ingestion Time、Processing Time）和 Watermark（水位线）。时间语义好理解，Watermark 虽然使用起来比较简单，有成熟的 API 可以调用，而且有固定的编程模式，无非就是传个参数。但是要结合到企业的业务实践中去，就必须要能够深入了解它的概念，只有这样才能应对不同的业务场景，并根据不同场景做相应的参数调整。

Window 是流处理中非常常用，也是非常重要的一种处理方式。其中 Time Window 可以说是重点中的重点，大家在学习的时候要认真理解示例图，搞清楚窗口大小和窗口滑动大小的关系。万变不离其宗，不论业务过程如何复杂，最终都会转化到本实验的编程模型中，唯一需要替换的就是聚合部分的业务逻辑。Keyed Window 和 Global Window 大家简单了解就好，有兴趣的同学可以自行实验。

本节实验我们介绍了 Flink 中的状态管理，包括 State 分类、Checkpoint 机制和 StateBackends。其中 State 分类包括 Keyed State 和 Operator State。在 Flink 状态管理中，使用相对来说比较简单，重点是概念理解。如果你学习过 Spark，请不要用 Spark 中的 Checkpoint 来类比 Flink 中的 Checkpoint，这是两种完全不同的机制。另外，在 Keyed State 案例中的。

一般来说，Flink 官方提供的 Source 和第三方依赖提供的 Source 已经完全可以满足我们日常的开发需求了，但是如果存在不能满足的情况，那么就需要我们自己去实现一个 Source 了。虽然这种情况少之又少，但其依然是一个很重要的知识点。细心的同学可能已经发现了，我们在前面的实验中通过，env对象是有一个addSource方法的，这个方法就是我们自定义 Source 用的。自定义一个类MySource，继承并重写其方法将MySource的实例对象作为参数传入addSource。

本节实验中我们介绍了 Flink 中的多流转换算子，其中 Union 是将两个或者多个类型相同的输入流转换成一个输入流，而filter是将一个输入流根据给定的条件切分成多个子输入流。这部分内容在工作中会经常用到，大家一定要理解。

在本节实验中我们介绍了 Flink 中基于 Key 的算子，keyBy 和 reduce 好理解，但是 Rolling Aggregation 算子的输出结果可能会和大家预想的不一样，特别是 min(minBy)和 max(maxBy)，请一定要注意它们之间的区别。需要自己练习，确定效果。

本节实验中，我们介绍了流处理的基本流程以及三个最基础的算子，也是日常工作中使用相当频繁的三个算子。相信对于有 Spark 使用经验的同学来说并没有什么难度，对于刚入行学习的新同学来说，flatMap 算子可能会比较烧脑，但是不要气馁，所谓熟能生巧。

Flink有三种部署模式，分别是 Standalone、Yarn 模式和 Kubernetes。在本次实验中我们的重点是 Standalone 模式，Yarn 和 Kubernetes 只需要了解即可

Flink 运行时架构主要包括四个不同的组件，它们会在运行流处理应用程序时协同工作：作业管理器（JobManager）、资源管理器（ResourceManager）、任务管理器（TaskManager），以及分发器（Dispatcher）。因为 Flink 是用 Java 和 Scala 实现的，所以所有组件都会运行在 Java 虚拟机上

Flink快速入门，流处理概述Flink 简介Flink 批处理 WordCountFlink 流处理 WordCount