Flink入坑指南 第三章：第一个作业

2022-02-11 02:17:10

摘要： Flink入坑指南系列文章，从实际例子入手，一步步引导用户零基础入门实时计算/Flink，并成长为使用Flink的高阶用户。本文属个人原创，仅做技术交流之用，笔者才疏学浅，如有错误，欢迎指正。转载请注明出处，侵权必究。

Flink接口

Flink支持三种接口，也就是三种写作业的方式：

  • SQL：实时计算产品与开源Flink相比，提供更全面的语法支持，目前95%的用户都是使用SQL解决其问题
  • TableAPI：表达能力与SQL相同
  • DataStream API：底层API，需要一定基础
    本系列文章会从流式SQL开始介绍。重点是帮助用户理解批和流SQL的区别，使用户能快速上手，在Flink上写出正确的流SQL。

不会介绍实时计算/Flink SQL的语法细节，关于SQL语法或各内置函数的用法，请参考文档：帮助手册
有志于了解FlinkSQL实现原理或研究Flink代码的同学，可以参考《Apache Flink 漫谈系列 - SQL概览》

有问题？点我提问

明确需求

接上一章内容，本章计算一个指标：

  1. 当天0点开始，全网的成交量
    使用系统：
  • 上游（SOURCE）：Kafka
  • 下游（SINK）：MySQL

开始写第一个作业

原始数据

ctime category_id shop_id item_id price
2018-12-04 15:44:54 cat_01 shop_01 item_01 10
2018-12-04 15:45:46 cat_02 shop_02 item_02 11.1
2018-12-04 15:46:11 cat_01 shop_03 item_03 12.4

主要逻辑

源表：

-- 源表DDL
create table src(
    ctime timestamp,       -- 交易时间戳
    category_id varchar,   -- 类目id
    shop_id varchar,       -- 店铺id
    item_id varchar,       -- 商品id
    price double           -- 价格
)

-- 结果表DDL
create table sink(
    cdate date,            -- 日期
    gmv_daily double       -- 从零点开始，每天的全网成交金额
)

批SQL写法

一般批的写法：

SELECT 
    date_format(ctime, '%Y%m%d') as cdate, -- 将数据从时间戳格式（2018-12-04 15:44:54），转换为date格式(20181204)
       SUM(price) AS gmv_daily
 FROM src
 GROUP BY date_format(ctime, '%Y%m%d') ; --按照天做聚合

结果：

cdate gmv_daily
20181204 33.5

特点：

  • 每次执行前，数据库中都保存了当天已经入库的全量数据
  • 每次执行SQL，都会拿到__一个__返回值，然后SQL执行结束

Flink SQL写法

SELECT 
    date_format(ctime, '%Y%m%d') as cdate, -- 将数据从时间戳格式（2018-12-04 15:44:54），转换为date格式(20181204)
       SUM(price) AS gmv_daily
 FROM src
 GROUP BY date_format(ctime, '%Y%m%d') ; --按照天做聚合

特点：

  • Flink SQL是个常驻进程，一个SQL文件，就对应与一个Flink作业。如果用户不杀掉这个作业，这个SQL就会一直存在
  • 每来一条数据，这个Flink作业都会输出一个值。如果MySQL结果表中没有加主键，那看到的结果如下：
cdate gmv_daily
20181204 10.0
20181204 21.1
20181204 33.5

如果把MySQL结果表中的cdate字段作为主键，那么每来一条数据，这个Flink作业都会输出一个值，三条数据的主键相同，因此会覆盖之前的结果，等三条数据都经过Flink计算后，得到的结果如下：

cdate gmv_daily
20181204 33.5

原理介绍

这个例子中，批和流的SQL相同，从最终结果看也相同。但是批引擎（比如MySQL/Hive等）的执行模式，和流引擎（如Flink）是完全不同的。这就导致同一个SQL在处理数据的行为上，会有很多区别。如果要深入使用Flink SQL，并且保证结果的正确性，成为Flink SQL调优专家，就需要对Flink底层实现有一定的了解。接下来每一章的例子之后，都会介绍一下本章所用的基础原理。但不会讲实现细节，需要了解实现细节的同学，可以follow flink源代码。

1. 从批和流SQL的行为开始 - 持续查询

从直观上看，批和流SQL行为非常不同：

  • 批SQL每执行一次，只返回一次结果，针对计算时刻数据库中数据的快照做计算
  • 流SQL只要启动，就会一直执行，在有数据的情况下会不停的产生结果
    这里涉及到的流计算中新增的一个非常重要且基础的概念持续查询。简单理解，持续查询的特点，Flink 作业会一直执行其SQL的逻辑，每到一条新数据，都会触发下游计算，从而源源不断的产生输出。

该SQL中有两个关键操作：

  • Group By：分组操作，在批SQL和流SQL中，group by的行为是相同的，都是按某几个字段对数据进行分组。

  • SUM：求和操作，在批SQL和流SQL中，SUM求和操作的语义上相同的，都是对每个分组的某个字段，做求和操作。但是批SQL和流SQL的实现方式是不同的：

    • 批：已经知道了所有数据，把每个分组的求和字段拿出来相加即可。
    • 流：数据是一条条进入系统的，并不知道全部数据，来一条加一条，产出一条结果。

2. group by + SUM（）- 状态

Flink SQL持续计算过程中，数据源源不断流入，以本文中例子来看，三条数据先后进入Flink，Flink中需要按cdate做一个全局group by，然后对每个cdate中所有数据的price做一个聚合运算（SUM），过程如下：

  1. item_01: sum1=0+10
  2. item_02: sum2=sum1+11.1=21.1
  3. item_03: sum3=sum2+12.3=33.4

这就产生了个问题：每条数据的SUM计算，都要依赖上一条数据的计算结果。Flink在计算的时候，会保留这些中间结果么？答案是：会保存。而这些中间结果，就是一个作业的状态(state)的一部分。

关于state的几个关键问题：

  • __是不是所有的作业都有状态？__是，但是只有聚合操作/JOIN等，state中才会保存中间结果。简单的运算，如filter等，state中不需要保存中间结果。State官方文档，请参阅：Apache Flink Doc，Flink Committer解析请参考 《Apache Flink 漫谈系列 - State》
  • state会保存多长时间？ state会一直保存么？不会。流计算中state都是有过期时间的。实时计算产品中，默认是36小时。
  • __state过期是什么意思？__state过期，是指36小时前的状态都会被删掉。这样做是为了节省系统存储空间，在大窗口join计算过程中，需要保存很多数据，如果都存下来，集群磁盘会满。

  • __state过期规则是什么？__state过期规则

    • 不同group by分组的state互不相关
    • 与该group by分组上次state更新的时间有关，如果 __现在时间 - 某个key的state最近更新的时间>state过期时间__，则这个group by分组的state会被清理掉。
  • state过期时间能调么？能，实时计算产品中，单作业可以配置这个参数：state.backend.rocksdb.ttl.ms=129600000，单位毫秒。
  • __如果state过期会对作业造成什么影响__：
    以这个例子来说，极端一点，假设我们把state过期参数设成5分钟。如果3条原始数据进入Flink的时间__相差5分钟以上__，以ptime定义数据进入flink的时间，如下所示：
ctime category_id shop_id item_id price ptime
2018-12-04 15:44:54 cat_01 shop_01 item_01 10 2018-12-04 15:45:00
2018-12-04 15:45:46 cat_02 shop_02 item_02 11.1 2018-12-04 15:45:10
2018-12-04 15:46:11 cat_01 shop_03 item_03 12.4 2018-12-04 15:52:00

此时:

  1. item_01(ptime=2018-12-04 15:45:00): sum1=0+10
  2. item_02(ptime=__2018-12-04 15:45:10__): sum2=sum1+11.1=21.1
  3. item_03(ptime=__2018-12-04 15:52:00__): sum3=0+12.3=12.3
    item_02和item_03之间超过5min，因此state中sum2的值被清掉，导致item_03到来时，sum3的值计算错误。

该例子中：

  • ctime就是数据产生的时间，流计算中的术语叫event time（事件时间）
  • ptime是数据进入Flink的事件，流计算中术语叫process time（处理时间）
    这两个时间域是流计算的基础概念。要正确使用流计算，还需要理解以下这两个概念，相关文章：

《Streaming System 第一章：Streaming 101》
《Streaming System 第二章：The What- Where- When- and How of Data Processing》

SQL优化

上述SQL中，每来一条数据就要就要计算一次，在输入数量大的情况下，容易产生性能瓶颈。每来一条数据，后端都会read和write一次state，发生序列化和反序列化操作，甚至是磁盘的 I/O 操作。对复杂场景，比如JOIN/TopN等，因此状态的相关操作通常都会成为整个任务的性能瓶颈。
如何避免这个问题呢？使用microbatch策略。microbatch顾名思义，就是攒批。不是来一条处理一条，而是攒一批再处理。相关配置如下：
​​


#攒批的间隔时间，使用 microbatch 策略时需要加上该配置，且建议和 blink.miniBatch.allowLatencyMs 保持一致
blink.microBatch.allowLatencyMs=5000
# 使用 microbatch 时需要保留以下两个 minibatch 配置
blink.miniBatch.allowLatencyMs=5000
# 防止OOM，每个批次最多缓存多少条数据
blink.miniBatch.size=20000。

相关知识点

有问题？点我提问

上一篇：隐私问题成远程量子计算最大障碍，新加坡科学家十余年研究出“盲量子计算”有望破解困局


下一篇：Flink入坑指南 第二章 - 从一个需求开始