关于数据同步:百亿级数据同步如何基于-SeaTunnel-的-ClickHouse-实现

6次阅读

共计 4182 个字符,预计需要花费 11 分钟才能阅读完成。

作者 | Apache SeaTunnel(Incubating) Contributor 范佳

整顿 | 测试工程师 冯秀兰

对于百亿级批数据的导入,传统的 JDBC 形式在一些海量数据同步场景下的体现并不尽如人意。为了提供更快的写入速度,Apache SeaTunnel(Incubating) 在刚刚公布的 2.1.1 版本中提供了 ClickhouseFile-Connector 的反对,以实现 Bulk load 数据写入。

Bulk load 指把海量数据同步到指标 DB 中,目前 SeaTunnel 已实现数据同步到 ClickHouse 中。

在 Apache SeaTunnel(Incubating) 4 月 Meetup 上,Apache SeaTunnel(Incubating) Contributor 范佳分享了《基于 SeaTunnel 的 ClickHouse bulk load 实现》,具体解说了 ClickHouseFile 高效解决海量数据的具体实现原理和流程。

感激本文整顿志愿者 测试工程师 冯秀兰 对 Apache SeaTunnel(Incubating) 我的项目的反对!

本次演讲次要蕴含七个局部:

  • ClickHouse Sink 现状
  • ClickHouse Sink 弱场景
  • ClickHouseFile 插件介绍
  • ClickHouseFile 核心技术点
  • ClickHouseFile 插件的实现解析
  • 插件能力比照
  • 前期优化方向

​范 佳白鲸开源 高级工程师

01 ClickHouse Sink 现状

现阶段,SeaTunnel 把数据同步到 ClickHouse 的流程是:只有是 SeaTunnel 反对的数据源,都能够把数据抽取进去,抽取进去之后,通过转换(也能够不转换),间接把源数据写入 ClickHouse sink connector 中,再通过 JDBC 写入到 ClickHouse 的服务器中。

然而,通过传统的 JDBC 写入到 ClickHouse 服务器中会存在一些问题。

首先,现阶段应用的工具是 ClickHouse 提供的驱动,实现形式是通过 HTTP,然而 HTTP 在某些场景下,实现效率不高。其次是海量数据,如果有反复数据或者一次性写入大量数据,应用传统的形式是生成对应的插入语句,通过 HTTP 发送到 ClickHouse 服务器端,在服务器端来进行逐条或分批次解析、执行,无奈实现数据压缩。

最初就是咱们通常会遇到的问题,数据量过大可能导致 SeaTunnel 端 OOM,或者服务器端因为写入数据量过大,频率过高,导致服务器端挂掉。

于是咱们思考,是否有比 HTTP 更快的发送形式?如果能够在 SeaTunnel 端做数据预处理或数据压缩,那么网络带宽压力会升高,传输速率也会进步。

02 ClickHouse Sink 的弱场景

如果应用 HTTP 传输协定,当数据量过大,批处理以微批的模式发送申请,HTTP 可能解决不过去;

太多的 insert 申请,服务器压力大。假如带宽能够接受大量的申请,但服务器端不肯定能承载。线上的服务器不仅须要数据插入,更重要的是查问数据为其余业务团队应用。若因为插入数据过多导致服务器集群宕机,是得失相当的。

03 ClickHouse File 核心技术点

针对这些 ClickHouse 的弱场景,咱们想,有没有一种形式,既能在 Spark 端就能实现数据压缩,还能够在数据写入时不减少 Server 的资源负载,并且能疾速写入海量数据?于是咱们开发了 ClickHouseFile 插件来满足这些需要。

ClickHouseFile 插件的关键技术是 ClickHouse -local。ClickHouse-local 模式能够让用户可能对本地文件执行疾速解决,而无需部署和配置 ClickHouse 服务器。ClickHouse-local 应用与 ClickHouse Server 雷同的外围,因而它反对大多数性能以及雷同的格局和表引擎。

因为有这 2 个特点, 这意味着用户能够间接解决本地文件,而无需在 ClickHouse 服务器端做解决。因为是雷同的格局,咱们在远端或者 SeaTunnel 端进行的操作所产生的数据和服务器端是无缝兼容的,能够应用 ClickHouse local 来进行数据写入。ClickHouse local 是实现 ClickHouseFile 的核心技术点,因为有了这个插件,现阶段才可能实现 ClickHouse file 连接器。

ClickHouse local 外围应用形式:

第一行:将数据通过 Linux 管道传递给 ClickHouse-local 程序的 test_table 表。

第二至五行:创立一个 result_table 表用于接收数据。

第六行:将数据从 test\_table 到 result\_table 表。

第七行:定义数据处理的磁盘门路。

通过调用 Clickhouse-local 组件,实现在 Apache SeaTunnel(Incubating) 端实现数据文件的生成,以及数据压缩等一系列操作。再通过和 Server 进行通信,将生成的数据间接发送到 Clickhouse 的不同节点,再将数据文件提供给节点查问。

原阶段和现阶段实现形式比照:

原来是 Spark 把数据包含 insert 语句,发送给服务器端,服务器端做 SQL 的解析,表的数据文件生成、压缩,生成对应的文件、建设对应索引。若应用 ClickHouse local 技术,则由 SeaTunnel 端做数据文件的生成、文件压缩,以及索引的创立,最终产出就是给服务器端应用的文件或文件夹,同步给服务器后,服务器就只需对数据查问,不须要做额定的操作。

04 核心技术点

以上流程能够促使数据同步更加高效,得益于咱们对其中的三点优化。

第一,数据实际上师从管道传输到 ClickHouseFile,在长度和内存上会有限度。为此,咱们将 ClickHouse connector,也就是 sink 端收到的数据通过 MMAP 技术写入临时文件,再由 ClickHouse local 读取临时文件的数据,生成咱们的指标 local file,以达到增量读取数据的成果,解决 OM 的问题。

第二,反对分片。因为如果在集群中应用,如果只生成一个文件或文件夹,实际上文件只散发到一个节点上,会大大降低查问的性能。因而,咱们进行了分片反对,用户能够在配置文件夹中设置分片的 key,算法会将数据分为多个 log file,写入到不同的集群节点中,大幅晋升读取性能。

第三个重要的优化是文件传输,目前 SeaTunnel 反对两种文件传输方式,一种是 SCP,其特点是平安、通用、无需额定配置;另一种是 RSYNC,其有点事疾速高效,反对断点续传,但须要额定配置,用户能够依据须要抉择适宜本人的形式。

05 插件实现解析

概括而言,ClickHouseFile 的总体实现流程如下:

  • 缓存数据,缓存到 ClickHouse sink 端;
  • 调用本地的 ClickHouse-local 生成文件;
  • 将数据发送到 ClickHouse 服务端;
  • 执行 ATTACH 命令

通过以上四个步骤,生成的数据达到可查问的状态。

06 插件能力比照

从数据传输角度来说,ClickHouseFile 更实用于海量数据,劣势在于不须要额定的配置,通用性强,而 ClickHouseFile 配置比较复杂,目前反对的 engine 较少;

就环境复杂度来说,ClickHouse 更适宜环境复杂度高的状况,不须要额定配置就能间接运行;

在通用性上,ClickHouse 因为是 SeaTunnel 官网反对的 JDBC diver,基本上反对所有的 engine 的数据写入,ClickHouseFile 反对的 engine 绝对较少;从服务器压力方面来说,ClickHouseFile 的劣势在海量数据传输时就体现进去了,不会对服务器造成太大的压力。

但这二者并不是竞争关系,须要依据应用场景来抉择。

07 后续打算

目前尽管 SeaTunnel 反对 ClickHouseFile 插件,然而还有很多中央须要优化,次要包含:

  • Rsync 反对;
  • Exactly-Once 反对;
  • 反对 Zero Copy 传输数据文件;
  • 更多 Engine 的反对

08 参加奉献

欢送感兴趣的小伙伴能够参加到这些后续打算的奉献中来,或者提供参考意见,谢谢大家!微信号 : Seatunnel

Apache SeaTunnel(Incubating) 是一个分布式、高性能、易扩大、用于海量数据(离线 & 实时)同步和转化的数据集成平台。

仓库地址:https://github.com/apache/incubator-seatunnel

网址:https://seatunnel.apache.org/

Proposal:https://cwiki.apache.org/confluence/display/INCUBATOR/SeaTunnelProposal

Apache SeaTunnel(Incubating) 2.1.0 下载地址:https://seatunnel.apache.org/download 衷心欢送更多人退出!

可能进入 Apache 孵化器,SeaTunnel(原 Waterdrop) 新的途程才刚刚开始,但社区的发展壮大须要更多人的退出。咱们置信,在「Community Over Code」(社区大于代码)、「Open and Cooperation」(凋谢合作)、「Meritocracy」(精英治理)、以及「多样性与共识决策」等 The Apache Way 的指引下,咱们将迎来更加多元化和容纳的社区生态,共建开源精力带来的技术提高!

咱们诚邀各位有志于让外乡开源立足寰球的搭档退出 SeaTunnel 贡献者小家庭,一起共建开源!

提交问题和倡议:https://github.com/apache/incubator-seatunnel/issues

奉献代码:https://github.com/apache/incubator-seatunnel/pulls

订阅社区开发邮件列表 :dev-subscribe@seatunnel.apach…

开发邮件列表:dev@seatunnel.apache.org

退出 Slack:https://join.slack.com/t/apacheseatunnel/shared\_invite/zt-123jmewxe-RjB\_DW3M3gV~xL91pZ0oVQ

关注 Twitter:https://twitter.com/ASFSeaTunnel

正文完
 0