关于flink:基于FlinkClickHouse打造轻量级点击流实时数仓

53次阅读

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

Flink 和 ClickHouse 别离是实时计算和(近实时)OLAP 畛域的翘楚,也是近些年十分火爆的开源框架,很多大厂都在将两者联合应用来构建各种用处的实时平台,成果很好。对于两者的长处就不再赘述,本文来简略介绍笔者团队在点击流实时数仓方面的一点实践经验。

点击流及其维度建模

所谓点击流(click stream),就是指用户拜访网站、App 等 Web 前端时在后端留下的轨迹数据,也是流量剖析(traffic analysis)和用户行为剖析(user behavior analysis)的根底。点击流数据个别以拜访日志和埋点日志的模式存储,其特点是量大、维度丰盛。以咱们一个中等体量的一般电商平台为例,每天产生约 200GB 左右、数十亿条的原始日志,埋点事件 100+ 个,波及 50+ 个维度。

依照 Kimball 的维度建模实践,点击流数仓遵循典型的星形模型,简图如下。

点击流数仓分层设计

点击流实时数仓的分层设计依然能够借鉴传统数仓的计划,以扁平为上策,尽量减少数据传输中途的提早。简图如下。

  • DIM 层 :维度层,MySQL 镜像库,存储所有维度数据。
  • ODS 层 :贴源层,原始数据由 Flume 间接进入 Kafka 的对应 topic。
  • DWD 层 :明细层,通过 Flink 将 Kafka 中数据进行必要的 ETL 与实时维度 join 操作,造成标准的明细数据,并写回 Kafka 以便上游与其余业务应用。再通过 Flink 将明细数据别离写入 ClickHouse 和 Hive 打成大宽表,前者作为查问与剖析的外围,后者作为备份和数据质量保证(对数、补数等)。
  • DWS 层 :服务层,局部指标通过 Flink 实时汇总至 Redis,供大屏类业务应用。更多的指标则通过 ClickHouse 物化视图等机制周期性汇总,造成报表与页面热力求。特地地,局部明细数据也在此层凋谢,不便高级 BI 人员进行漏斗、留存、用户门路等灵便的 ad-hoc 查问,这些也是 ClickHouse 远超过其余 OLAP 引擎的弱小之处。

要点与注意事项

Flink 实时维度关联

Flink 框架的异步 I/O 机制为用户在流式作业中拜访内部存储提供了很大的便当。针对咱们的状况,有以下三点须要留神:

  • 应用异步 MySQL 客户端,如 Vert.x MySQL Client。
  • AsyncFunction 内增加内存缓存(如 Guava Cache、Caffeine 等),并设定正当的缓存驱赶机制,防止频繁申请 MySQL 库。
  • 实时维度关联仅实用于迟缓变动维度,如地理位置信息、商品及分类信息等。疾速变动维度(如用户信息)则不太适宜打进宽表,咱们采纳 MySQL 表引擎将快变维度表间接映射到 ClickHouse 中,而 ClickHouse 反对异构查问,也可能撑持规模较小的维表 join 场景。将来则思考应用 MaterializedMySQL 引擎(以后仍未正式公布)将局部维度表通过 binlog 镜像到 ClickHouse。
Flink-ClickHouse Sink 设计

能够通过 JDBC(flink-connector-jdbc)形式来间接写入 ClickHouse,但灵活性欠佳。好在 clickhouse-jdbc 我的项目提供了适配 ClickHouse 集群的 BalancedClickhouseDataSource 组件,咱们基于它设计了 Flink-ClickHouse Sink,要点有三:

  • 写入本地表,而非分布式表,陈词滥调了。
  • 按数据批次大小以及批次距离两个条件管制写入频率,在 part merge 压力和数据实时性两方面获得均衡。目前咱们采纳 10000 条的批次大小与 15 秒的距离,只有满足其一则触发写入。
  • BalancedClickhouseDataSource 通过随机路由保障了各 ClickHouse 实例的负载平衡,然而只是通过周期性 ping 来探活,并屏蔽掉以后不能拜访的实例,而没有故障转移——亦即一旦试图写入曾经失败的节点,就会失落数据。为此咱们设计了重试机制,重试次数和距离均可配置,如果当重试机会耗尽后依然无奈胜利写入,就将该批次数据转存至配置好的门路下,并报警要求及时查看与回填。

以后咱们仅实现了 DataStream API 格调的 Flink-ClickHouse Sink,随着 Flink 作业 SQL 化的大潮,在将来还打算实现 SQL 格调的 ClickHouse Sink,打磨强壮后会适时回馈给社区。另外,除了随机路由,咱们也打算退出轮询和 sharding key hash 等更灵便的路由形式。

还有一点就是,ClickHouse 并不反对事务,所以也不用费神思考 2PC Sink 等保障 exactly once 语义的操作。如果 Flink 到 ClickHouse 的链路呈现问题导致作业重启,作业会间接从最新的位点(即 Kafka 的 latest offset)开始生产,失落的数据再经由 Hive 进行回填即可。

ClickHouse 数据重均衡

ClickHouse 集群扩容之后,数据的重均衡(reshard)是一件麻烦事,因为不存在相似 HDFS Balancer 这种开箱即用的工具。一种比较简单粗犷的思路是批改 ClickHouse 配置文件中的 shard weight,使新退出的 shard 多写入数据,直到所有节点近似均衡之后再调整回来。然而这会造成显著的热点问题,并且仅对间接写入分布式表才无效,并不可取。

因而,咱们采纳了一种比拟波折的办法:将原表重命名,在所有节点上建设与原表 schema 雷同的新表,将实时数据写入新表,同时用 clickhouse-copier 工具将历史数据整体迁徙到新表上来,再删除原表。当然在迁徙期间,被重均衡的表是无奈提供服务的,依然不那么优雅。如果大佬们有更好的计划,欢送交换。

The End

对于 Flink 和 ClickHouse 等组件的配置、调优、提早监控、权限治理等常识,笔者在之前的博客中多少讲到过,更多详情请见作者原文链接:

https://www.jianshu.com/p/bed…

正文完
 0