【Flink】基于Flink构建全场景实时数仓

本文介绍了基于Flink构建实时数仓的过程,从实时计算初期的烟囱式开发问题,到实时数仓的Lambda和Kappa架构,再到流批结合的解决方案。详细讨论了各架构的优缺点,如Lambda的双路生产问题,Kappa的局限性和流批结合对实时OLAP与数据湖技术的利用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录:
一. 实时计算初期
二. 实时数仓建设
三. Lambda架构的实时数仓
四. Kappa架构的实时数仓
五. 流批结合的实时数仓

实时计算初期

虽然实时计算在最近几年才火起来,但是在早期也有部分公司有实时计算的需求,但是数据量比较少,所以在实时方面形成不了完整的体系,基本所有的开发都是具体问题具体分析,来一个需求做一个,基本不考虑它们之间的关系,开发形式如下:

早期实时计算早期实时计算

如上图所示,拿到数据源后,会经过数据清洗,扩维,通过Flink进行业务逻辑处理,最后直接进行业务输出。把这个环节拆开来看,数据源端会重复引用相同的数据源,后面进行清洗、过滤、扩维等操作,都要重复做一遍,唯一不同的是业务的代码逻辑是不一样的。

随着产品和业务人员对实时数据需求的不断增多,这种开发模式出现的问题越来越多:

  1. 数据指标越来越多,“烟囱式”的开发导致代码耦合问题严重。

  2. 需求越来越多,有的需要明细数据,有的需要 OLAP 分析。单一的开发模式难以应付多种需求。

  3. 每个需求都要申请资源,导致资源成本急速膨胀,资源不能集约有效利用。

  4. 缺少完善的监控系统,无法在对业务产生影响之前发现并修复问题。

大家看实时数仓的发展和出现的问

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

菜鸟蜀黍

你的鼓励是我最大的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值