前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >CDC ChangeLog Stream实时流入clickhouse最佳姿势

CDC ChangeLog Stream实时流入clickhouse最佳姿势

原创
作者头像
数据万有引力
发布2022-10-30 13:32:09
1.7K0
发布2022-10-30 13:32:09
举报
文章被收录于专栏:数据是生产力
CDC ChangeLog Stream实时流入clickhouse最佳姿势
CDC ChangeLog Stream实时流入clickhouse最佳姿势

数据知行合一 

知:掌握数据建设方法论、技术体系;

行:将数据建设方法论、技术体系与业务场景结合落地

关注“数据万有引力”公众号

正文共:3198字 11图 | 预计阅读时间:8分钟


承接上个专题 clickhosue准实时数仓能力探索 留下问题“上游实时数据怎么sink到clickhouse?”,在这里一起探索 CDC ChangeLog Stream实时流sink 到CLICKHOUSE最佳姿势。

在进行技术选型、方案设计与实操之前,先简单概述下数据库变更日志是怎么流入click house的:

CDC技术通过实时捕捉数据变更日志作为流计算引擎(如flink,spark)

数据源,这些实时流数据源ChangeLog Stream由包含变更操作列(用于插入、删除、更新(先前)、更新(新)标识)的行和实际的元数据列组成,流入flink引擎。flink再将ChangeLog Stream转换为Dynamic Table的Append或Retract或Upsert模式,然后再sink到外部系统,如:clickhouse

这里涉及到几个术语解释:

  • Dynamic Table & ChangeLog Stream
  • Append-only stream
  • Retract stream
  • Upsert stream

术语解释

01. Dynamic Table & ChangeLog Stream

Dynamic table在flink中是一个逻辑概念,。下图是ChangeLog Stream和dynamic table转换关系,先将ChangeLog Stream转化为dynamic table,再基于dynamic table进行SQL操作生成新的dynamic table。

  • Dynamic Table 就是 Flink SQL 定义的动态表,动态表和流的概念是对等的。参照上图,流可以转换成动态表,动态表也可以转换成流。
  • 在 Flink SQL中,数据在从一个算子流向另外一个算子时都是以 Changelog Stream 的形式,任意时刻的 Changelog Stream 可以翻译为一个表,也可以翻译为一个流。

上游CDC技术,实时捕捉数据库变更日志,flink实时消费日志,数据库中的变更日志作为flink流的数据源(Changelog Stream),如 MySQL 的 binlog 日志完整记录了数据库中的变更,可以把 binlog 文件当作流的数据源

在将Changelog Stream转换为Dynamic Table或将其写入外部系统时,Flink 根据数据变化类型提供三种结果的输出模式。

02. Append-only stream

Append-only stream:A dynamic table that is only modified by INSERT changes can be converted into a stream by emitting the inserted rows. flink-docs-release-1.15

Append-only 是最为简单的输出模式,只支持追加结果记录的操作。结果一旦输出以后便不会再有变更,Append 输出模式的最大特性是不可变性(immutability)

通常来说,Append 模式会用于写入不方便做撤回或者删除操作的存储系统的场景,比如 Kafka 等 MQ 或者打印到控制台。

03. Retract stream

Retract stream: A retract stream is a stream with two types of messages, add and retract messages. A dynamic table is converted into a retract stream by encoding an INSERT change as add message, a DELETE change as a retract message, and an UPDATE change as a retract message for the updated (previous) row, and an additional message for the updating (new) row. flink-docs-release-1.15

retract 流包含两种类型的 message:add messages retract messages 。通过将INSERT 操作编码为 add message、将 DELETE 操作编码为 retract message、将 UPDATE 操作编码为更新(先前)行的 retract message 和更新(新)行的 add message,将动态表转换为 retract 流。

如上图,在mysql执行update操作

代码语言:javascript
复制
update inventory.`debezium_products`  set weight=180 where id=101;

ChangeLog转为Retract stream会在dynamic table写入以下数据

op

id

name

description

weight

-U

101

scooter

description

80.000

+U

101

scooter

description

180.000

04. Upsert stream

Upsert stream: An upsert stream is a stream with two types of messages, upsert messages and delete messages. A dynamic table that is converted into an upsert stream requires a (possibly composite) unique key. flink-docs-release-1.15

upsert 流包含两种类型的 message:upsert messages 和_delete messages_。转换为 upsert 流的动态表需要(可能是组合的)唯一键。通过将 INSERT 和 UPDATE 操作编码为 upsert message,将 DELETE 操作编码为 delete message 。

如上图,在mysql执行update操作

代码语言:javascript
复制
update inventory.`debezium_products`  set weight=180 where id=101;

ChangeLog转为Retract stream会在dynamic table写入以下数据

op

id

name

description

weight

-D

101

scooter

description

80.000

+I

101

scooter

description

180.000

ChangeLog Stream 写入clickhosue方案

由于clickhosue以下特性,ChangeLog Stream 写入clickhosue需要相应解决方案

  • clickhosue不适合大量单条数据的写请求,因为写入过快时后台合并不过来,会报Too many parts等错误
  • clickhosue不适合高频繁的数据更新和删除操作,因为变更数据的聚合处理需要时间,短期内可能出现数据不准的现象,同时clickhosue对事务支持也不够完善。

通过以下方案,解决ChangeLog Stream 写入clickhosue存在以上局限问题

  • 使用CollapsingMergeTree表承接Retract stream与Upsert stream写入。
  • 使用VersionedCollapsingMergeTree表承接Versioned Table 的Retract stream写入。
  • 使用ReplacingMergeTree表承接Append-only stream或特定场景(没有物理删除)Retract stream写入。
  • 某些数据量小,变更不频繁维表的Upsert stream可以使用other engines of this family (*MergeTree)表承接写入
  • 按数据批次大小以及批次间隔两个条件控制写入频率,在part merge压力和数据实时性两方面取得平衡。

基于以上解决方案,flink-connector-clickhouse设计如下图 ,

扫下面二维码或搜一搜“数据万有引力”关注公众号获取 “flink-connector-clickhouse.jar”,私信获取源码

  • 首先考虑到ClickHouse擅长大批量写入的特点,通过batch option 可以支持攒批写入,避免频繁写入造成的性能下降问题;同时通过batchTime option兼顾数据实时性;两个option,只要其中一个满足条件就触发sink,从而在part merge压力和数据实时性两方面取得平衡。
  • 其次是ChangeLog Stream包含大量的更新和删除操作。为了支持频繁变更的数据,将Flink的Retract Stream(回撤流)、Upsert Stream(更新-插入流)含有状态标记的数据流,写入到ClickHouse的 CollapsingMergeTree引擎表中
  • 然后是Versioned Table(dynamic table with a PRIMARY KEY constraint and time attribute),通过将event time生成version,根据状态标记生成sign,再将数据流写入ClickHouse的VersionedCollapsingMergeTree引擎表中

CDC技术选型

在flink cdc connector与flink Debezium Format对CDC技术进行选型,通过上图架构与对比

  • flink cdc connector需要维护组件更少,实时链路更简单,部署成本低;全量阶段支持数据并发读取,并且支持全量阶段checkpoint;可以不需要对库或表加锁来保证数据一致性。
  • Debezium的使用人数多,社区活跃,框架也比较成熟,技术更稳定;在保证数据一致性时,需要对读取的库或表加锁;全量阶段读取阶段,只支持单并发。

虽然flink cdc 有很多亮点能力,不过项目还在孵化阶段,有些操作不是很丝滑;如果有功力深厚的技术架构团队来驾驭它(陪社区一起成长,拥抱社区并与之合作),flink cdc 可以覆盖业务场景会更深。

如果业务场景对稳定要求比较高,同时又不想投入高成本驾驭技术,其实Debezium已经可以覆盖很多场景了

可以将Debezium作为Flink的嵌入式引擎,作为一个依赖包嵌入到代码库,而不用通过kafka connector运行,同样也可以不再需要直接与 MySQL 服务器通信,不需要处理复杂快照、GTID、锁等等优点。同时简化

全过程解决方案

根据上面探索,最终CDC ChangeLog Stream实时流sink 到CLICKHOUSE全过程解决方案如上图

  • flink cdc connector实时捕捉数据变更日志,实现数据全量与实时增量采集。
  • 自研flink-connector-clickhouse实现不同ChangeLog Stream模式(append\retract\upsert)输出到相应的clickhosue表引擎。
  • 在clickhouse使用相应表引擎承接上游数据输入。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 术语解释
    • 01. Dynamic Table & ChangeLog Stream
      • 02. Append-only stream
        • 03. Retract stream
          • 04. Upsert stream
          • ChangeLog Stream 写入clickhosue方案
          • CDC技术选型
          • 全过程解决方案
          相关产品与服务
          数据库
          云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档