熊老二的博客

Slot SharingBy default, Flink allows subtasks to share slots even if they are subtasks ofdifferent tasks, so long as they are from the same job.Slot可以被多个SubTask共享使用，需要满足一下条件：SubTask必须是不同Task，也就是说一个Slot中的SubTask属于不同Operator操作；SubTask属于一个Job中任务，必须是一个Job

Job Managers, Task Managers, ClientsFlink 应用运行时包含2个组件：JobManager和TaskManagers：JobManagers，也称为Masters，协调Flink Job分布式执行。1.They schedule tasks, coordinate checkpoints, coordinate recovery on failures, etc.2.至少一个JobManager，针对高可用HA，可以启动多个JobManager，其中一个是le

Transport PatternStream（流）可以在2个Operator之间传输数据，有两种不同Parttern（模式）传输：One-to-One streams：一对一，前一个Operator中一个SubTask将数据传输给后一个Operator中1个SubTask。类似Spark RDD中窄依赖，父RDD1个分区数据给子RDD1个分区。Redistributing streams：重分配，前一个Operator中一个SubTask将数据给后一个Operator中多个SubTask。类似

Flink 原理探析Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。Levels of Abstraction在Flink中提供不同层次抽象开发批处理Batch和流计算Streaming。abstractionProgram ModelProgram Model编写Flink 应用程序，主要分为5个步骤，如下所示：第一步、执行环境（Environment）：Obt

BroadcastState 动态更新需求实时过滤出配置中的用户，并在事件流中补全这批用户的基础信息。事件流：表示用户在某个时刻浏览或点击了某个商品，格式如下。{"userID": "user_3", "eventTime": "2019-08-17 12:19:47", "eventType": "browse", "productID": 1}{"userID": "user_2", "eventTime": "2019-08-17 12:19:48", "eventType": "cli

订单自动好评需求在电商领域会有这么一个场景，如果用户买了商品，在订单完成之后，一定时间之内没有做出评价，系统自动给与五星好评，使用Flink 定时器Timer来简单实现这一功能。Flink TimerTimer（定时器）是Flink Streaming API提供的用于感知并利用处理时间/事件时间变化的机制。Ververica blog上给出的描述如下：对于普通用户来说，最常见的显式利用Timer的地方就是KeyedProcessFunction，在其processElement()方

Flink Action 综合案例需求在大数据的实时处理中，实时大屏展示已经成了一个很重要的展示项，比如最有名的双十一大屏实时销售成交额展示。除了这个，还有一些其他场景的应用，比如在后台系统实时的展示网站当前的pv、uv等等，其实做法都是类似的。做一个最简单的模拟电商统计大屏的小例子，需求如下：1.实时计算出当天零点截止到当前时间的销售总额2.计算出各个分类的销售top33.每秒钟更新一次统计结果window: [2020-10-25 19:08:31]: 男装 = 1051.2wi

Flink SQL 常用算子SELECTSELECT 用于从 DataSet/DataStream 中选择数据，用于筛选出某些列。示例：SELECT * FROM Table；// 取出表中的所有列SELECT name，age FROM Table；// 取出表中name 和 age 两列与此同时 SELECT 语句中可以使用函数和别名，例如上面提到的 WordCount 中：SELECT word, COUNT(word) FROM table GROUP BY word;WHE

流计算需求使用Flink SQL进行实时交易订单数据基本统计分析：每隔5秒统计最近5秒的每个用户的订单总数、订单的最大金额、订单的最小金额自定义数据源Source，模拟产生交易订单数据，订单实体类：OrderInfopackage xx.xxxxxx.flink.stream;import lombok.AllArgsConstructor;import lombok.Data;import lombok.NoArgsConstructor;@Data@NoArgsConstruct

批处理数据有sql_students.txt 保存学生信息：id，name，classname1,张三,1班2,李四,1班3,王五,2班4,赵六,2班5,田七,2班有sql_scores.txt 保存成绩：id，chinese，math，english1,100,90,802,97,87,743,70,50,434,100,99,995,80,81,82需求1.初始化flink env2.读取文件数据，读取student.txt、scores.txt两张表3.数

入门案例：流计算使用Flink Table API和SQL分别对流计算编写入门案例，具体如下所示。SQL 案例Flink SQL流式数据处理案例演示，官方Example案例，具体代码如下所示：package xx.xxxxxx.flink.start.stream;import lombok.*;import org.apache.flink.streaming.api.datastream.DataStream;import org.apache.flink.streaming.api.e

入门案例依赖依赖<!-- Either... --><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-table-api-java-bridge_2.11</artifactId> <version>1.10.0</version> <scope>provided</scope></

Table API& SQL发展历程自2015年开始，阿里巴巴开始调研开源流计算引擎，最终决定基于 Flink 打造新一代计算引擎，针对 Flink 存在的不足进行优化和改进，并且在 2019 年初将最终代码开源，也就是Blink。Blink 在原来的 Flink 基础上最显著的一个贡献就是 Flink SQL 的实现。随着版本的不断更新，API 也出现了很多不兼容的地方。在 Flink 1.9 中，Table 模块迎来了核心架构的升级，引入了阿里巴巴Blink团队贡献的诸多功能，Flink

Flink Table API 与 SQLProcessFunction 函数如下图，在常规的业务开发中，SQL、Table API、DataStream API比较常用，处于Low-level的Porcession相对用得较少，通过实战来熟悉处理函数(Process Function)。处理函数有很多种，最基础的应该ProcessFunction类，从它的类图可见有RichFunction的特性open、close，然后自己有两个重要的方法processElement和onTimer。实际项目中往

异步IO介绍Async I/O是阿里巴巴贡献给社区的一个呼声非常高的特性，于1.2版本引入。主要目的是为了解决与外部系统交互时网络延迟成为了系统瓶颈的问题。异步IO操作的需求asynico.html流计算系统中经常需要与外部系统进行交互，通常的做法，如向数据库发送用户A的查询请求，然后等待结果返回，在之前，程序无法发送用户B的查询请求。这是一种同步访问方式，如下图所示左图所示：通常实现方式是向数据库发送用户a的查询请求（例如在MapFunction中），然后等待结果返回，在这之前，无法发送用户

Flink+Kafka实现End-to-End Exactly-Oncehttps://ververica.cn/developers/flink-kafka-end-to-end-exactly-once-analysis/package xx.xxxxxx.flink.exactly;import org.apache.flink.api.common.serialization.SimpleStringSchema;import org.apache.flink.streaming.api.C

Flink+Kafka：End-to-End Exactly-Once代码示例analysis/package xx.xxxxxx.flink.exactly;import org.apache.flink.api.common.serialization.SimpleStringSchema;import org.apache.flink.streaming.api.CheckpointingMode;import org.apache.flink.streaming.api.datastrea

Flink+Kafka：End-to-End Exactly-OnceFlink的 End-to-End Exactly-Once需要Checkpoint+事务的提交/回滚操作，在分布式系统中协调提交和回滚的方法就是使用两阶段提交协议。了解下Flink的TwoPhaseCommitSinkFunction是如何支持End-to-End Exactly-Once的。版本说明Flink 1.4版本之前，支持Exactly Once语义，仅限于应用内部。Flink 1.4版本之后，通过两阶段提交(Two

Sink需要支持幂等写入或事务写入(Flink的两阶段提交需要事务支持)。1）、幂等写入（Idempotent Writes）幂等写操作是指：任意多次向一个系统写入数据，只对目标系统产生一次结果影响。例如，重复向一个HashMap里插入同一个Key-Value二元对，第一次插入时这个HashMap发生变化，后续的插入操作不会改变HashMap的结果，这就是一个幂等写操作。HBase、Redis和Cassandra这样的KV数据库一般经常用来作为Sink，用以实现端到端的Exactly-Once。

End-to-End Exactly-Once 实现Flink内部借助分布式快照Checkpoint已经实现了内部的Exactly-Once，但是Flink自身是无法保证外部其他系统“精确一次”语义的，所以Flink 若要实现所谓“端到端（End to End）的精确一次”的要求，那么外部系统必须支持“精确一次”语义；然后借助一些其他手段才能实现StructuredStreaming 流式应用程序精确一次性语义实现：Flink 流式应用程序精确一次性语义实现Source发生故障时需要支持重设数

扩展：End-to-End Exactly-Once流处理的数据处理语义对于批处理，fault-tolerant（容错性）很容易做，失败只需要replay，就可以完美做到容错。对于流处理，数据流本身是动态，没有所谓的开始或结束，虽然可以replay buffer的部分数据，但fault-tolerant做起来会复杂的多。流处理（有时称为事件处理）可以简单地描述为是对无界数据或事件的连续处理。流或事件处理应用程序可以或多或少地被描述为有向图，并且通常被描述为有向无环图（DAG）。在这样的图中，每个边

Savepoint保存点由用户手动创建、拥有和删除，它们的用例用于有计划的、手动的备份和恢复。savepointsSavepoint 介绍Savepoint：保存点，类似于以前玩游戏的时候，遇到难关/遇到boss，赶紧手动存个档，然后接着玩，如果失败了，赶紧从上次的存档中恢复，然后接着玩。在实际开发中，可能会遇到这样的情况：如要对集群进行停机维护/扩容…那么这时候需要执行一次Savepoint，也就是执行一次手动的Checkpoint，也就是手动的发一个barrier栅栏，那么这样的话，程序的

自动重启策略和恢复1）、重启策略配置方式配置文件在flink-conf.yml中可以进行配置，示例如下:restart-strategy: fixed-delayrestart-strategy.fixed-delay.attempts: 3restart-strategy.fixed-delay.delay: 10 s代码中可以在代码中针对该任务进行配置，示例如下:env.setRestartStrategy(RestartStrategies.fixedDelayRestart(

状态恢复和重启策略手动重启并恢复1.把程序打包2.启动Flink集群(本地单机版，集群版都可以)/export/server/flink/bin/start-cluster.sh3.访问webUIhttp://node1.itcast.cn:8081/#/overview4.使用FlinkWebUI提交cn.itcast.flink.checkpoint.StreamCheckpointDemohdfs://node1.itcast.cn:8020/flink-checkpo

Checkpoint 配置方式1）、全局配置修改flink-conf.yaml#jobmanager(即MemoryStateBackend), #filesystem(即FsStateBackend), #rocksdb(即RocksDBStateBackend)state.backend: filesystem state.checkpoints.dir: hdfs://namenode:8020/flink-checkpoints/checkpoint2）、在代码中配置//1.Me

State 状态后端注意：前面学习Checkpoint其实就是Flink中某一时刻，所有的Operator的全局快照，那么快照应该要有一个地方进行存储，而这个存储的地方叫做状态后端（StateBackend）。Flink中的State状态后端有很多种：state_backends1）、MemStateBackend内存存储，即MemoryStateBackend，构造方法是设置最大的StateSize，选择是否做异步快照。对于State存储在 TaskManager 节点也就是执行节点内存中

Flink 容错机制checkpointsCheckpointState Vs CheckpointState：维护/存储的是某一个Operator的运行的状态/历史值，是维护在内存中。一般指一个具体的Operator的状态（operator的状态表示一些算子在运行的过程中会产生的一些历史结果，如前面的maxBy底层会维护当前的最大值，也就是会维护一个keyedOperator，这个State里面存放就是maxBy这个Operator中的最大值）；State数据默认保存在Java的堆内存中/T

存储 State 数据结构前面说过：有状态计算其实就是需要考虑历史数据，而历史数据需要搞个地方存储起来。Flink为了方便不同分类的State的存储和管理，提供了如下API/数据结构来存储State。1）、Keyed StateKeyed State 通过 RuntimeContext 访问，这需要 Operator 是一个RichFunction。保存Keyed state的数据结构:  ValueState：即类型为T的单值状态。这个状态与对应的key绑定，是最简单的状态。它可以通过upd

状态分类working-with-state1 组织形式划分转态State存在的两种形式（Forms）：Managed（管理）和Raw（原始）。从Flink是否接管角度，状态可以分为：ManagedState(托管状态)RawState(原始状态)两者的区别如下：从状态管理方式的方式，Managed State 由 Flink Runtime 管理，自动存储，自动恢复，在内存管理上有优化；而 Raw State 需要用户自己管理，需要自己序列化，Flink不知道 State中存入的数据是

什么是状态state-fault先回顾一下到底什么是 state，流式计算的数据往往是转瞬即逝， 当然，真实业务场景不可能说所有的数据都是进来之后就走掉，没有任何东西留下来，那么留下来的东西其实就是称之为state，中文可以翻译成状态。在下面这个图中，所有的原始数据进入用户代码之后再输出到下游，如果中间涉及到 state 的读写，这些状态会存储在本地的 state backend（可以对标成嵌入式本地 kv 存储）当中。状态分类working-with-state1.组织形式划分转态Stat

有状态计算场景什么场景会用到状态呢，下面列举了常见的 4 种：去重（Distinct）：比如上游的系统数据可能会有重复，落到下游系统时希望把重复的数据都去掉。去重需要先了解哪些数据来过，哪些数据还没有来，也就是把所有的主键都记录下来，当一条数据到来后，能够看到在主键当中是否存在。  窗口计算（Window）：比如统计每分钟 Nginx 日志 API 被访问了多少次。窗口是一分钟计算一次，在窗口触发前，如 08:00 ~ 08:01 这个窗口，前59秒的数据来了需要先放入内存，即需要把这个窗口之内的数

无状态和有状态计算1 无状态计算无状态（Stateless）计算特性：不需要考虑历史数据相同的输入得到相同的输出如map、filter、flatMap等方法首先举一个无状态计算的例子：消费延迟计算。假设现在有一个消息队列，消息队列中有一个生产者持续往消费队列写入消息，多个消费者分别从消息队列中读取消息。从图上可以看出，生产者已经写入 16 条消息，Offset 停留在 15 ；有 3 个消费者，有的消费快，而有的消费慢。消费快的已经消费了 13 条数据，消费者慢的才消费了 8 条数据。如

Flink 状态管理state1 Flink 有状态计算注意：Flink中已经对需要进行有状态计算的API，做了封装，底层已经维护好了状态！例如，之前下面代码，直接使用即可，不需要像SparkStreaming那样还得自己写updateStateByKey。学习的State只需要掌握原理，实际开发中一般都是使用Flink底层维护好的状态或第三方维护好的状态（如Flink整合Kafka的offset维护底层就是使用的State，已经实现好的）。package xx.xxxxx.flink.star

扩展：并行度（Parallelism）的Task(线程)来执行， 一个Operator的并行Task(线程)数目就被称为该Operator(任务)的并行度(Parallel)。并行度可以有如下几种指定方式1.Operator Level（算子级别）(可以使用)一个算子、数据源和sink的并行度可以通过调用 setParallelism()方法来指定2.Execution Environment Level（Env级别）(可以使用)执行环境(任务)的默认并行度可以通过调用setParalleli

扩展：Streaming File SinkstreamFile1 场景描述StreamingFileSink是Flink1.7中推出的新特性，是为了解决如下的问题：大数据业务场景中，经常有一种场景：外部数据发送到kafka中，Flink作为中间件消费kafka数据并进行业务处理；处理完成之后的数据可能还需要写入到数据库或者文件系统中，如写入hdfs中。StreamingFileSink就可以用来将分区文件写入到支持 Flink FileSystem 接口的文件系统中，支持Exactly-O

Time与Watermakerevent_time1 Time 时间分类在Flink的流式处理中，会涉及到时间的不同概念，如下图所示：事件时间EventTime: 事件真真正正发生产生的时间；摄入时间IngestionTime: 事件到达Flink的时间；处理时间ProcessingTime: 事件真正被处理/计算的时间；问题: 上面的三个时间，实际业务计算时更关注哪一个?答案: 更关注事件时间EventTime !因为: 事件时间更能反映事件的本质， 只要事件时间一产生就不会变化。

案例：时间会话窗口1 需求设置会话超时时间为10s，10s内没有数据到来，则触发上个窗口的计算2 代码实现窗口统计案例演示：时间会话窗口（Time Session Window)，数字累加求和统计package xx.xxxxxx.flink.window.session;import org.apache.flink.streaming.api.datastream.DataStreamSource;import org.apache.flink.streaming.api.datastr

案例：计数窗口假设有1个滑动计数窗口，每2个元素计算1次最近4个元素的总和，窗口工作示意图如下所示：上图中所示的各个窗口逻辑上是不同的窗口，但在物理上是同一个窗口。该滑动计数窗口，trigger的触发条件是元素个数达到2个（每进入_x0010_2个元素就会触发一次），evictor保留的元素个数是4个，每次计算完窗口总和后会保留剩余的元素。所以第一次触发trigger是当元素5进入，第三次触发trigger是当元素2进入，并驱逐5和2，计算剩余的4个元素的总和（22）并发送出去，保留下2,4,9,7元

案例：时间窗口1 需求nc -lk 9999有如下数据表示：信号灯编号和通过该信号灯的车的数量a,3a,2a,7d,9b,6a,5b,3e,7e,4需求1：基于时间的滚动窗口，窗口大小window size=滑动大小slide size每5秒钟统计一次，最近5秒钟内，各个路口通过红绿灯汽车的数量需求2：基于时间的滑动窗口，窗口大小window size>滑动大小slide size每5秒钟统计一次，最近10秒钟内，各个路口通过红绿灯汽车的数量2 代码实现

Window API1 window和windowAll使用keyBy的流：Keyed Stream，应该使用window方法