要求
- Java 11+ (用于 Flink 1.17+) 或 17+ (用于 Flink 2.0+)
- Apache Flink 1.17+
Flink 版本兼容性矩阵
该连接器尚未针对早于 Flink 1.17.2 的版本进行测试。
安装与设置
作为依赖引入
对于 Flink 2.0+
- Maven
- Gradle
- SBT
适用于 Flink 1.17 及以上版本
- Maven
- Gradle
- SBT
下载二进制包
flink_version为2.0.0或1.17stable_version是稳定版本制品的发布版本
使用 DataStream API
代码示例
- Java
快速入门示例
DataStream API 连接选项
ClickHouse 客户端选项
options 和 serverSettings 应以 Map<String, String> 的形式传递给客户端。如果其中任一项为空映射,则分别使用客户端或服务端的默认值。
所有可用的 Java 客户端选项均列在 ClientConfigProperties.java 和此文档页面中。所有可用的服务端会话设置均列在此文档页面中。
- Java
Sink 选项
AsyncSinkBase:
支持的数据类型
将 Flink 中的数据插入 ClickHouse
注意:
- 执行日期操作时,必须提供
ZoneId。 - 执行 decimal 操作时,必须提供精度和标度。
- 要让 ClickHouse 将 Java String 解析为 JSON,需要在
ClickHouseClientConfig中启用enableJsonSupportAsString。 - 该 连接器 需要一个
ElementConvertor,用于将输入 DataStream 中的元素映射为 ClickHouse 载荷。为此,连接器 提供了ClickHouseConvertor和POJOConvertor,你可以结合上述DataWriter序列化方法使用它们来实现这种映射。
支持的输入格式
DataStream 序列化为 ClickHouse 载荷的格式,请使用 setClickHouseFormat 函数。例如:
默认情况下,如果在
ClickHouseClientConfig 中显式将 setSupportDefault 设置为 true 或 false,连接器将分别使用 RowBinaryWithDefaults 或 RowBinary。指标
局限性
- 该 sink 当前提供至少一次交付保证。实现精确一次语义的相关工作可在此处跟踪。
- 该 sink 目前尚不支持用于缓冲无法处理记录的死信队列 (DLQ) 。在此之前,连接器 会尝试重新 insert 失败的记录;如果仍然失败,则会将其丢弃。此功能可在此处跟踪。
- 该 sink 目前尚不支持通过 Flink 的 Table API 或 Flink SQL 创建。此功能可在此处跟踪。
ClickHouse 版本兼容性与安全
- 该连接器通过每日 CI 工作流针对一系列较新的 ClickHouse 版本进行测试,包括 latest 和 head。随着新的 ClickHouse 发行版进入活跃状态,测试版本也会定期更新。有关该连接器每日测试的版本,请参见此处。
- 有关已知安全漏洞以及如何报告漏洞,请参见 ClickHouse 安全策略。
- 我们建议持续升级该连接器,以免错过安全修复和新改进。
- 如果你在迁移过程中遇到问题,请创建 GitHub issue,我们会回复!
高级和推荐用法
- 为获得最佳性能,请确保你的 DataStream 元素类型不是 Generic 类型——请参阅这篇关于 Flink 类型区分的说明。非 Generic 元素可避免 Kryo 引入的序列化开销,并提升写入 ClickHouse 的吞吐量。
- 我们建议将
maxBatchSize设置为至少 1000,理想范围是 10,000 到 100,000。更多信息请参阅这篇关于批量 insert 的指南。 - 如需在 ClickHouse 中执行 OLTP 风格的去重或 upsert,请参阅此文档页面。注意:不要将其与发生在 retries 时的批次去重混淆。
故障排查
CANNOT_READ_ALL_DATA
吞吐量低
numRequestSubmitted 和 actualRecordsPerBatch 指标,以帮助判断如何调整批次大小 (maxBatchSize) 以及 flush 频率。另请参阅高级和推荐用法中的批次大小建议。
我的 ClickHouse 表中有行缺失
ClickHouseClientConfig.setNumberOfRetries() 设置) 。注意:默认情况下,连接器会在丢弃某个批次之前最多尝试重新插入 3 次。
解决方案:检查 TaskManager 日志和/或堆栈跟踪,以定位根本原因。