Flink sql 自定义Connector

1. 参考官网的架构图 以及流程

在这里插入图片描述

1.1 从架构图上可以看出

Metadata(元数据)、Planning(规划),Runtime(运行时提供者)三个部分的内容。

2 Metadata - 元数据模块

1.Table API 和 SQL 都是声明式 API,表的声明。因此,如上图所示,在执行CREATE TABLE语句会导致目标目录Catalog中的元数据更新。
2.对于大多数目标目录Catalog实现,外部系统中的物理数据不会针对此类操作进行修改,因此Connector连接器的依赖项不必存在于类路径中,SQL语句中声明的选项WITH既不被验证也不被解释。
3.动态表的元数据(即通过 DDL 创建或由目录提供)表示为CatalogTable, 必要时,将在CatalogTable内部解析表名

3. Planning - 规划模块

3.1 Dynamic Table Factories - 动态表工厂

作用: 动态表工厂用于根据目录和会话信息为外部存储系统配置动态表连接器。

1. org.apache.flink.table.factories.DynamicTableSourceFactory :可以实现构造一个DynamicTableSource.
2. org.apache.flink.table.factories.DynamicTableSinkFactory:可以实现构造一个DynamicTableSink

特点:

1.默认情况下,使用connector选项的值作为工厂标识符和Java的服务提供者接口(SPI)来发现工厂。
2.在 JAR 文件中,可以将对新实现的引用添加到服务文件中:
	META-INF/services/org.apache.flink.table.factories.Factory
3.该框架由工厂标识符和请求的基类唯一标识的单个匹配工厂检查,例如:DynamicTableSourceFactory。
如有必要,目录实现可以绕过工厂发现过程。为此,目录需要返回一个实例,该实例在org.apache.flink.table.catalog.Catalog#getFactory
-----------------------------------

3.2 Dynamic Table Source - 动态表源

动态表可以随时间变化。在读取动态表时,内容可以被认为是:
一个更改日志(有限或无限),所有更改都会持续使用,直到更改日志用完,这由ScanTableSource接口表示。
一个不断变化的或非常大的外部表,其内容通常不会被完全读取,而是在必要时查询单个值 ,这由LookupTableSource 接口表示。
一个类可以同时实现这两个接口,规划器根据指定的查询决定它们的使用.

3.2.1 Scan Table Source - 扫描表源

作用

1.ScanTableSource(扫描表源)在运行时扫描来自外部存储系统的所有行。
2.扫描的行不一定只包含插入,还可以包含更新和删除。因此,表源可用于读取(有限或无限)变更日志。返回的更改日志模式指示计划程序在运行时可以预期的一组更改。
1.对于常规的批处理场景,源可以发出有限的仅插入行流。
2.对于常规流式处理方案,源可以发出无限制的仅插入行流。
3.对于变更数据捕获 (CDC) 方案,源可以发出带有插入、更新和删除行的有界或无界流

作用

Table Source可以实现进一步的能力接口,SupportsProjectionPushDown在规划期间可能会改变实例。所有能力都可以在	 	
  		org.apache.flink.table.connector.source.abilities 包中找到并列在源能力表中。

运行时实现的ScanTableSource必须产生内部数据结构,因此,记录必须以org.apache.flink.table.data.RowData. 该框架提供了运行时转换器,
因此源仍然可以处理常见的数据结构并在最后执行转换。

3.2.2 Lookup Table Source - 查找表源

Lookup TableSource在运行时通过一个或多个键查找外部存储系统的行:

1.与ScanTableSource相比,源不必读取整个表,并且可以在必要时从(可能不断变化的)外部表中懒惰地获取单个值。
2.与ScanTableSource相比, LookupTableSource当前仅支持发出仅插入更改。
接口 描述
SupportsFilterPushDown 启用将过滤器下推到DynamicTableSource. 为了提高效率,源可以将过滤器进一步向下推,以接近实际数据生成。
SupportsLimitPushDown 允许将限制(预期的最大生成记录数)下推到DynamicTableSource.
SupportsPartitionPushDown 允许将可用分区传递给规划器并将分区下推到DynamicTableSource. 在运行时,源将只从传递的分区列表中读取数据以提高效率。
SupportsProjectionPushDown 能够将(可能是嵌套的)投影下推到DynamicTableSource. 为了提高效率,源可以将投影进一步向下推,以接近实际的数据生成。如果源也实现SupportsReadingMetadata了,源也将只读取所需的元数据
SupportsReadingMetadata 允许从DynamicTableSource. 源负责在生成的行末尾添加所需的元数据。这包括可能从包含的格式转发元数据列
SupportsWatermarkPushDown 能够将水印策略下推到DynamicTableSource. 水印策略是时间戳提取和水印生成的构建器/工厂。在运行时,水印生成器位于源内部,并且能够生成每个分区的水印。
SupportsSourceWatermark 可以完全依赖ScanTableSource 自身提供的水印策略。因此,CREATE TABLEDDL 能够使用SOURCE_WATERMARK()内置标记功能,计划器将检测到该功能,并在可用时将其转换为对该接口的调用

3.3 Dynamic Table Sink - 动态表接收器

特点:
动态表可以随时间变化。在编写动态表时,可以始终将内容视为更改日志(有限或无限),其中所有更改都被连续写出,直到更改日志用完为止。返回的更改日志模式 指示接收器在运行时接受的更改集。
有一下几种情况

1.对于常规批处理场景,接收器可以仅接受仅插入行并写出有界流。
2.对于常规的流式处理方案,接收器只能接受仅插入行,并且可以写出无界流。
3.对于变更数据捕获 (CDC) 场景,接收器可以使用插入、更新和删除行写出有界或无界流。

其中:所有能力都可以在org.apache.flink.table.connector.sink.abilities 包装中找到,并列在水槽能力表中。
运行时实现DynamicTableSink必须使用内部数据结构。因此,记录必须被接受为org.apache.flink.table.data.RowData, 该框架提供了运行时转换器,因此接收器仍然可以在通用数据结构上工作并在开始时执行转换。
接口 描述
SupportsOverwrite 允许覆盖DynamicTableSink. 默认情况下,如果未实现此接口,则无法使用例如 SQL INSERT OVERWRITE子句覆盖现有表或分区
SupportsPartitioning 允许将分区数据写入DynamicTableSink.
SupportsWritingMetadata 允许将元数据列写入DynamicTableSource. 表接收器负责在消费行的末尾接受请求的元数据列并将它们持久化。这包括可能将元数据列转发到包含的格式

3.4 Encoding / Decoding Formats - 编码/解码格式

一些表连接器接受对键和/或值进行编码和解码的不同格式。

格式的工作方式类似于模式DynamicTableSourceFactory -> DynamicTableSource -> ScanRuntimeProvider,工厂负责翻译选项,源负责创建运行时逻辑。

因为格式可能位于不同的模块中,所以使用类似于表工厂的 Java 服务提供者接口来发现它们。为了发现格式工厂,动态表工厂搜索与工厂标识符和特定于连接器的基类相对应的工厂。

例如,Kafka 表源需要一个DeserializationSchema作为运行时接口的解码格式。因此,Kafka 表源工厂使用该value.format选项的值来发现一个DeserializationFormatFactory.

当前支持以下格式工厂:

org.apache.flink.table.factories.DeserializationFormatFactory
org.apache.flink.table.factories.SerializationFormatFactory

些表连接器接受对键和/或值进行编码和解码的不同格式。

格式的工作方式类似于模式DynamicTableSourceFactory -> DynamicTableSource -> ScanRuntimeProvider,工厂负责翻译选项,源负责创建运行时逻辑。

因为格式可能位于不同的模块中,所以使用类似于表工厂的 Java 服务提供者接口来发现它们。为了发现格式工厂,动态表工厂搜索与工厂标识符和特定于连接器的基类相对应的工厂。

猜你喜欢

转载自blog.csdn.net/wudonglianga/article/details/126730674