Flink1.12 SQL连接器之JDBC Connector介绍与使用总结

前言

与DataStream同样,官方在Flink SQL上也提供了很多连接器,今天来学习总结一下JDBC连接器

环境准备

如果使用编码,需要引入两个依赖包,Flink提供的jdbc连接器依赖和和对应的mysql驱动包,

以下为1.12.0 提供的jdbc连接器依赖


  org.apache.flink
  flink-connector-jdbc_2.11
  1.12.0

mysql依赖下载地址

使用学习

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方法原理是一样的,链接请看:

SQL优化之使用数学的方式动态的确定区间并统计02

简单来说就是,如果这个比如这样(...,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 两只猴

你可能感兴趣的:(Flink1.12 SQL连接器之JDBC Connector介绍与使用总结)