前言
与DataStream同样,官方在Flink SQL上也提供了很多连接器,今天来学习总结一下JDBC连接器
环境准备
如果使用编码,需要引入两个依赖包,Flink提供的jdbc连接器依赖和和对应的mysql驱动包,
以下为1.12.0 提供的jdbc连接器依赖
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-connector-jdbc_2.11</artifactId>
<version>1.12.0</version>
</dependency>
使用学习
The JDBC sink operate in upsert mode for exchange UPDATE/DELETE messages with the external system if a primary key is defined on the DDL, otherwise, it operates in append mode and doesn’t support to consume UPDATE/DELETE messages.
来自官网的一段介绍,简单翻译一下就是说,如果DDL上定义了主键,则JDBC接收器以upsert模式操作与外部系统交互,否则以append模型来进行交互。
本人测试了一下,详细步骤就不写了,和官网差不多,测试主要步骤如下:
外部数据库DDL设置主键,Flink SQL DDL设置主键
外部数据库DDL不设置主键,Flink SQL DDL设置主键
外部数据库DDL设置主键,Flink SQL DDL不设置主键
外部数据库DDL不设置主键,Flink SQL DDL不设置主键
结果如下:
外部系统DDL有主键 | 外部系统DDL无主键 | |
---|---|---|
Flink SQL DDL 有主键 | upsert | append |
Flink SQL DDL 无主键 | upsert | append |
总结:JDBC sink的操作时,如果外部系统定义的DDL存在主键,则JDBC连接器将使用upsert语义而不是简单的insert,在Flink任务执行中如果出现了故障,Flink作业将会从上一个成功的检查点恢复并重新处理,这可能导致在恢复期间重新处理消息。
强烈建议使用upsert模式,因为使用append模式需要重新处理记录,下游可能会出现重复数据。
重要特性
Partitioned Scan
为了加速并行Source任务实例中的数据读取,Flink 在JDBC连接器中提供了scan.partition.column,scan.partition.num,scan.partition.lower-bound,scan.partition.upper-bound 这4个配置属性。其原理简单解释一下:
如果一个线程去读一张很大的表,从头读到尾,肯定很慢,如果想加快速度,自然能想到使用多线程。如何使用呢?
比如假设有id为0到100的数据,id不连续,并且实际上有50条记录,如果我们希望分而治之,那么最好是五个线程,每个线程读取10条数据。但是肯定是做不到这么精确的。最简单的办法是,产生五条如下的SQL:
select * from xxx where id<20;
select * from xxx where id>=20 and id <40;
select * from xxx where id>=40 and id <60;
select * from xxx where id>=60 and id <80;
select * from xxx where id>=80;
因为id中间有空隙,所以每条SQL实际拿到的数据并不一样。但没关系,通过五个线程执行这五条SQL,我们肯定可以通过更少的时间获取到全量数据。
所以在分区扫描中,确定了4个属性规则,用来并行的读这些数据
scan.partition.column: 按照哪个列进行分区
scan.partition.num:分区数量
scan.partition.lower-bound:分区字段的最小值
scan.partition.upper-bound:分区字段的最大值
这个其实和之前博客中写的过优化SQL方法原理是一样的,链接请看:
简单来说就是,如果这个比如这样(...,20),[20,40),[40,60),[60,80)....[80,...) 。少还可以,如果面对上百组的情况,后续不容易维护,比如上面的例子,第一组的最小值是20,最后一组的最大值是80,然后总共5组,这样Flink就知道20-80之间还要再分三组。
目前Flink 支持 数字,日期,时间戳等类型的分区扫描配置。
Lookup Cache
JDBC连接器在作为Source维度表使用时,可以开启缓存来提高临时连接JDBC连接器的性能。
默认情况下,不启用查找缓存,因此所有请求都发送到外部数据库。启用查找缓存后,每个进程(即TaskManager)将保存一个缓存。Flink将首先查找缓存,并且仅在缺少缓存时才将请求发送到外部数据库,并使用返回的行更新缓存。当缓存达到最大缓存行数lookup.cache.max-rows
或超过最大生存时间时,缓存中最旧的行将过期lookup.cache.ttl
。缓存的行可能不是最新的,用户可以调整lookup.cache.ttl
为较小的值以获取更好的新鲜数据,但这可能会增加发送到数据库的请求的数量。因此,这是吞吐量和正确性之间的平衡。
lookup.max-retries
则配置在查询失败后重试的次数
Buffer-flush
当mysql被使用被Sink时,可以配置
sink.buffer-flush.max-rows
:配置刷新前缓冲记录的最大大小
sink.buffer-flush.interval
:配置刷新间隔,单位为毫秒,在此期间,异步线程将刷新数据。可以设置为'0'来禁用它。注意,”sink.buffer-flush.max-rows'可以设置为'0',并设置刷新间隔,以允许完成异步处理缓冲的动作。
总结
本文是本文学习和使用Flink SQL JDBC 连接器的学习笔记和总结,如果出现描述问题,欢迎大家留言指出,一起努力。
-- by 两只猴