flink 实时数仓构建与开发[记录一些坑]

这篇具有很好参考价值的文章主要介绍了flink 实时数仓构建与开发[记录一些坑]。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

业务场景描述

1、业务库使用pg数据库, 业务数据可以改动任意时间段数据
2、监听采集业务库数据,实时捕捉业务库数据变更,同时实时变更目标表和报表数据

数仓架构

实时数据流图与分层设计说明
flink 实时开发,flink,大数据,flink,kafka,java
1、debezium采集pg库表数据同步到kafka 【kafka模式】
2、flink 消费kafka写入pg或kafka 【upset-kafka,新版kafka可以基于source 过滤重复数据,降低下游重复计算压力】
3、重复第二步,截止计算完成

同时写入pg和kafka 的目的
1、若验证pg表数据不一致,消费kafka数据分析数据异常原因
2、多层计算任务可以再次消费kafka数据进行实时计算

数仓分层

ods

1、表结构基本同业务表结构,做数据合并或同步操作,数据写入pg,目的是写入pg库的目的是为了与计算完成的表进行关联
2、表结构基本同业务表结构,做数据合并或同步操作,数据写入Kafka,供下游实时计算使用,同时还能为下游过滤重复数据【新版kafka支持】
3、日期字段格式化处理【因debezium采集datetime日期类型会强转为bigint类型,且比当前时区加8个时区,要编写java代码进行日期格式转换处理,不一定非java】

dim

维度表计算任务

dwd

主要是做明细事实表规范化处理层

1、数仓整体字段命名一致性与规范化处理【看数仓开发规范】,复杂字符串解析【如json、数组等类型】

dws

主要基于明细数据做轻度汇总

1、事实明细表关联维度表进行某个维度上的汇总操作
2、source 维度表时,只需要source维度表的id字段

数仓建模注意项

1、事实表之间的关联关系是一对一 ,一对多,多对一,多对多
2、若主表与join表是一对多或多对多 , 实时数仓etl的时候要把主表和join表的主键取出来做联合主键,不然写入数据库或kafka,数据可能会乱序,从而引起数据漏数,导致数据不一致。【致命问题】

数仓建模开发规范

命名规范

1、字段命名规范

日期、数值、字符串等字段类型同一规范化命名

2、库名、表名命名规范

结合业务线和表的作用或用途来规范化命名

3、模型字段排序规范
事实表模型规范

1、主键在前,维度表字段id紧追其后,维度字段从大到小排序【或小到大】,事实指标在维度表字段后,最后加计算时间字段。
2、事实表建议不要加维度表id对应的name值【实时数仓非常不建议,若name值可以修改,轻则会导致下游数据回撤,重则可能导致写有数据乱序或漏数,具体场景原因分析,下次遇到再分析】

维度表模型规范

主键在前, 维度字段从大到小排序【或小到大】,维度id和id对应的name值可以放一起【或先放id字段,name值同一放在后面】

问题与原因分析

1、debezium 采集pg 表,数据类型问题

因debezium采集datetime日期类型会强转为bigint类型,且比当前时区加8个时区,要编写java代码进行日期格式转换处理,不一定非java

2、业务库出现大批量刷表数据,debezium采集connector 可能会挂

原因分析:
业务库若大批量刷表,debezium的connector服务无法承接大批量增量采集数据的压力;

解决方法:
1、暂停debezium增量同步任务,理论上不需要暂停可以撑住【真实场景:业务刷新某个业务表的某个字段,表数据量1.5亿】
2、评估影响采集端压力,在不暂停采集任务的同时,持续观察下游计算任务稳定,保证计算任务若失败快速从checkpoint 恢复

3、业务库出现大批量刷表数据,实时计算任务会出现长时间延迟或内存溢出或任务失败

原因分析:
1、大批量数据发往下游,计算任务会出现大批量数据回撤
2、因刷新数据问题,数据库日志位移会落后,追赶数据库日志需要耗费一点时间
3、大批量数据发往下游,分配给任务的内存过小,导致内存溢出,从而导致任务失败
解决方法:
1、新增upset-kafka过滤层,可以按source字段过滤重复数据,有效避免下游任务出现大量数据回撤
2、因内存溢出导致任务失败,通过增加内存,再次从checkpoint 启动即可

3、业务库会修改维度表数据,导致实时任务出现数据延迟【或数据恢复耗时较长】

原因分析
1、维度表与事实表关系:一对多
2、把维度表的name值加到source ,【批量】修改维度表某个字段的name值,因一条维度记录会关联到非常多的事实数据,导致下游关联任务发生大量数据回撤【若有多个依赖任务,每个依赖任务都会受到影响】

解决方法:

4、多表关联多并发数据乱序

问题描述:
1、多表(left)join时,(left)join的表出现多次修改,多并发sink到pg的表数据出现数据乱序

sql 如下:

select A.id , B.name
from A
left join B on B.id = A.id  -- id 仅为关联条件,不是表主键

原因分析:
1、主键不变,修改id的name值,left join的表出现多次修改,即kafka会收到多条修改数据同时也会收到对修改记录的删除数据【如:主键,null ; 代表回撤主键对应的数据】;
1、 仅仅靠左表joinkey1并不能保证下游数据的唯一性。
2、flink sql内部在高并发下,以joinkey1和joinkey2的拼接字符串做哈希,然后根据哈希值分配给不同的并发(线程)计算。
3、在joinkey1或者joinkey2发生update的话,会将变更信息发送到下游kafka。
4、初始化或者变更数多时,每次批次处理数据对于同一条a_source.id,有多条不同joinkey值的数据,一起处理。
5、对于相同a_source.id(即下游唯一的id),不同的joinkey数据会发送到不同的并发线程处理,导致下游相同a.source_id写入kafka相同的分区,不同并发处理能力不同,从而相同a.source_id的变更信息数据并不会按照变更时间进行处理,导致数据乱序。

解决方法:
1、把每个表的主键和left join关联条件字段放一起做联合主键,修改sql如下

select A.pk_id || B.pk_id || B.id as pk_id ,A.id , B.name  -- pk_id  分别是表A、B的主键字段
from A
left join B on B.id = A.id  -- id 仅为关联条件,不是表主键

5、多并发写入pg库表死锁

问题描述
1、事实表关联维度表计算,在一个实时计算间隔内维度表出现一个id对应多个name值,导致sink到pg时,对应的表记录死锁了

解决方案:
1、维度表的name值不参与实时计算,实时任务计算完成后,在pg表关联维度表取name值
2、在实时任务中使用max(name),保证发往下游只有一条name的记录

6、明细数据一致性对比验证

业务库与实时库表主键对比

7、数据容错与恢复

1、增量checkpoint , 可以设置保留checkpoint的个数,
在配置文件【flink-conf.yaml】中加:state.checkpoints.num-retained:24

2、全量checkpoint

8、下游表没有数据或漏数分析

原因分析:
1、pg表A字段(join 关联字段)类型为varchar , flink source 表时,A字段类型是int , 使用debezium 采集, source 表数据时,A字段数值不能转换,值为null,关联条件不匹配导致没有数据输出

2、pg表A字段(join 关联字段)类型为date ,若使用debezium 采集, A字段数值会转换为 bignint 类型, 若flink source 表的A字段类型是int , 类型值准确性丢失,导致表数据关联失败,没有数据输出

解决:修改pg表A字段类型,重跑任务解决

注意:这种情况任务不会报错,要排查数据情况才能发现

9、实时思想

1、join 和where 条件一样,本质都是对from 主表 数据的筛选
2、left join 只是在主表上加字段,不会筛选主表数据,但会影响sink端的数据回撤,具体解析看上面内容
3、sink 到下游每条记录都有应该有主键

10、多表关联比单表计算性能慢的原因分析

业务场景:
exactly-once 模式
flink upset-kafka模式

Alignment happens only for operators with multiple predecessors (joins) as well as operators with multiple senders (after a stream repartitioning/shuffle). Because of that, dataflows with only embarrassingly parallel streaming operations (map(), flatMap(), filter(), …) actually give exactly once guarantees even in at least once mode.

flink 官网:https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/concepts/stateful-stream-processing/#exactly-once-vs-at-least-once

11、flink sql - 多表关联乱序的思考

1、dwd 明细数据不关联code ,取name
2、dws 要拆分多个code,取name后拼接成一行;使用单并发跑
3、代码任务管理:逻辑相同的代码放在一个任务里跑,
1)一个表并发到多个表
2) 多表关联逻辑,单并发跑
以上的情况分两个任务,即使source 有一部分一样文章来源地址https://www.toymoban.com/news/detail-601899.html

到了这里,关于flink 实时数仓构建与开发[记录一些坑]的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 构建高效实时数据流水线:Flink、Kafka 和 CnosDB 的完美组合

    当今的数据技术生态系统中,实时数据处理已经成为许多企业不可或缺的一部分。为了满足这种需求,Apache Flink、Apache Kafka和CnosDB等开源工具的结合应运而生,使得实时数据流的收集、处理和存储变得更加高效和可靠。本篇文章将介绍如何使用 Flink、Kafka 和 CnosDB 来构建一个

    2024年02月10日
    浏览(43)
  • Flink 实时数仓关键技术解读:Upsert Kafka 和 动态表(Dynamic Table)

    博主历时三年精心创作的《大数据平台架构与原型实现:数据中台建设实战》一书现已由知名IT图书品牌电子工业出版社博文视点出版发行,点击《重磅推荐:建大数据平台太难了!给我发个工程原型吧!》了解图书详情,京东购书链接:https://item.jd.com/12677623.html,扫描左侧

    2024年02月22日
    浏览(47)
  • 如何基于 Apache Doris 与 Apache Flink 快速构建极速易用的实时数仓

    随着大数据应用的不断深入,企业不再满足离线数据加工计算的时效,实时数据需求已成为数据应用新常态。伴随着实时分析需求的不断膨胀,传统的数据架构面临的成本高、实时性无法保证、组件繁冗、运维难度高等问题日益凸显。为了适应业务快速迭代的特点,帮助企业

    2024年02月12日
    浏览(48)
  • Apache Flink X Apache Doris构建极速易用的实时数仓架构

    大家好,我叫王磊。是SelectDB 大数据研发。今天给大家带来的分享是《Apache Flink X Apache Doris构建极速易用的实时数仓架构》。 下面是我们的个人介绍:我是Apache Doris Contributor 和阿里云 MVP。同时著有《 图解 Spark 大数据快速分析实战》等书籍。 接下来咱们进入本次演讲的正题

    2023年04月24日
    浏览(49)
  • Flink 实时数仓 (一) --------- 数据采集层

    1. 普通实时计算与实时数仓比较 普通的实时计算优先考虑时效性,所以从数据源采集经过实时计算直接得到结果。如此做时效性更好,但是弊端是由于计算过程中的中间结果没有沉淀下来,所以当面对大量实时需求的时候,计算的复用性较差,开发成本随着需求增加直线上升

    2024年02月06日
    浏览(47)
  • 【大数据】Doris 构建实时数仓落地方案详解(三):Doris 实时数仓设计

    本系列包含: Doris 构建实时数仓落地方案详解(一):实时数据仓库概述 Doris 构建实时数仓落地方案详解(二):Doris 核心功能解读 Doris 构建实时数仓落地方案详解(三):Doris 实时数仓设计 前面已经解读实时数仓的背景、技术线路和应用场景,这里具体从实现的角度来介

    2024年02月07日
    浏览(42)
  • 【大数据】Doris 构建实时数仓落地方案详解(一):实时数据仓库概述

    本系列包含: Doris 构建实时数仓落地方案详解(一):实时数据仓库概述 Doris 构建实时数仓落地方案详解(二):Doris 核心功能解读 Doris 构建实时数仓落地方案详解(三):Doris 实时数仓设计 数据仓库的概念可以追溯到 20 世纪 80 年代,当时 IBM 的研究人员提出了商业数据

    2024年02月04日
    浏览(50)
  • 【大数据】Doris 构建实时数仓落地方案详解(二):Doris 核心功能解读

    本系列包含: Doris 构建实时数仓落地方案详解(一):实时数据仓库概述 Doris 构建实时数仓落地方案详解(二):Doris 核心功能解读 Doris 构建实时数仓落地方案详解(三):Doris 实时数仓设计 Apache Doris 是由 百度 研发并开源的数据库项目。 Doris 2008 年开始在百度内部立项,

    2024年02月07日
    浏览(47)
  • Flink电商实时数仓(四)

    业务数据:数据都是MySQL中的表格数据, 使用Flink SQL 处理 日志数据:分为page页面日志(页面信息,曝光信息,动作信息,报错信息)和启动日志(启动信息,报错信息),使用Flink Stream API处理 五种日志数据: “start”; 启动信息 “err”; 错误信息 “display”; 曝光信息 “ac

    2024年01月17日
    浏览(46)
  • Flink电商实时数仓(三)

    维度层的重点和难点在于实时电商数仓需要的维度信息一般是动态的变化的,并且由于实时数仓一般需要一直运行,无法使用常规的配置文件重启加载方式来修改需要读取的ODS层数据,因此需要通过Flink-cdc实时监控MySql中的维度数据配置信息表,实时动态的发布广播信息。主

    2024年02月03日
    浏览(49)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包