《Apache Flink 案例集(2022版)》——2.数据分析——美团-Flink 的实时数仓平台建设(3)

本文涉及的产品
实时计算 Flink 版,1000CU*H 3个月
简介: 《Apache Flink 案例集(2022版)》——2.数据分析——美团-Flink 的实时数仓平台建设(3)

《Apache Flink 案例集(2022版)》——2.数据分析——美团-Flink 的实时数仓平台建设(2) https://developer.aliyun.com/article/1228306



对于上述问题,我们提出了冷热关联分离的解决方案。假设关联两天前的数据是相对低频的且状态回滚不会超过两天,那么可以定义两天前的数据为冷数据,两天之内的数据为热数据。


image.png

如上图所示,左侧的 SQL 作业通过设置状态保留时长,只保留 T+0 和 T+1 这两天的热数据,而 T+2 及更久以前的冷数据则通过批任务每天从 Hive 同步到外存 KV 中。关联时,若状态中的热数据不存在,则再通过访问外存 KV 来关联冷数据。右侧是另外一个 SQL 作业需要关联相同的数据源,它与左侧的 SQL 作业共享外层 KV 中的冷数据。  


对于第一个痛点,因为状态控制在了两天内,SQL 作业上线时,关联数据初始化的数据量得到了控制。对于第二个痛点,因为两天前的大部分数据都保存在外层KV中,不同的 SQL 作业都可以查询外存 KV,从而可以节省大量内存资源。  


第2个问题是有状态 SQL 逻辑变更后状态如何恢复?FlinkSQL 支持有状态的增量计算,状态是增量计算的历史累计,实际上业务需要修改逻辑的情况很多。


image.png


上图右侧列出了一些常见的 SQL 变更情况,比如新增聚合指标、修改原指标口径、增加过滤条件、新增数据流关联、增加聚合维度等。举例来说,如果业务增加了更多服务维度,在数据产品上就需要扩展分析的维度,因此也需要修改 FlinkSQL 增加聚合维度。但是上述 SQL 逻辑变化后却不能从之前的状态恢复,因为历史状态对于变更后的 SQL 不能保证其完整性,即使恢复后也不能百分百保证后续计算的正确性。这种情况下,业务为了保证数据的正确性,需要从历史回溯重新计算,回溯的过程会导致线上断流,但业务又不希望牺牲太多的时效性。  


针对这个问题,美团给出了三种解决方案:  


解法 1:双链路切换。此解法的关键是再搭建一条相同的实时链路作为备用链路,当变更有状态 SQL 时,可以在备用链路上做回溯,重新计算历史数据,回溯完成后先验证备用链路的结果数据,确保没问题后再在链路最下游的数据服务层切换读取的表,完成整个变更流程;


解法 2:旁路状态生成。与双链路切换不同点在于,这里变更的是链路上的单个作业,思路是临时启动一个旁路作业来回溯,构建出新逻辑的状态,验证数据完成后再重启线上作业,以此完成 SQL 和状态的同时切换;


解法 3:历史状态迁移,前两个方法的思路比较类似,都是基于历史数据重新计算,构建出新状态。但这个思路是基于历史状态迁移出新状态,这种方法构建出的新状态虽然不能保证完整性,但在某些情况下,业务也是可以接受的。  


上述三种方式各有优点,可以从普适性、资源成本、线上断流、等待时长四个维度来对以上三个解决方案进行横向比较。  


普适性是指在保证数据正确的前提下支持的 SQL 变更范围,前两个方法都是重新计算,状态是完整的,因此比方案 3 的普适性更高;


资源成本是指完成 SQL 变更所需要的额外 Flink 或 Kafka 资源,方法 1 需要构建整条链路,需要更多的 Flink 和 Kafka 资源,因此成本最高。


线上断流指的是在变更过程中导致下游数据延迟的时长,方法 1 是在数据服务层做切换,几乎没有断流;方法 2 的断流时长取决于作业从状态恢复的速度;方法 3 除了状态恢复,还需要考虑状态迁移的速度;


等待时长指的是完成整个变更流程需要的时间,前两个方法都需要重新计算,因此比方法 3 的等待时间更长。  



《Apache Flink 案例集(2022版)》——2.数据分析——美团-Flink 的实时数仓平台建设(4) https://developer.aliyun.com/article/1228303

相关实践学习
基于Hologres轻量实时的高性能OLAP分析
本教程基于GitHub Archive公开数据集,通过DataWorks将GitHub中的项⽬、行为等20多种事件类型数据实时采集至Hologres进行分析,同时使用DataV内置模板,快速搭建实时可视化数据大屏,从开发者、项⽬、编程语⾔等多个维度了解GitHub实时数据变化情况。
相关文章
|
10天前
|
消息中间件 监控 Java
Apache Kafka 分布式流处理平台技术详解与实践指南
本文档全面介绍 Apache Kafka 分布式流处理平台的核心概念、架构设计和实践应用。作为高吞吐量、低延迟的分布式消息系统,Kafka 已成为现代数据管道和流处理应用的事实标准。本文将深入探讨其生产者-消费者模型、主题分区机制、副本复制、流处理API等核心机制,帮助开发者构建可靠、可扩展的实时数据流处理系统。
144 4
|
2月前
|
SQL DataWorks 关系型数据库
DataWorks+Hologres:打造企业级实时数仓与高效OLAP分析平台
本方案基于阿里云DataWorks与实时数仓Hologres,实现数据库RDS数据实时同步至Hologres,并通过Hologres高性能OLAP分析能力,完成一站式实时数据分析。DataWorks提供全链路数据集成与治理,Hologres支持实时写入与极速查询,二者深度融合构建离在线一体化数仓,助力企业加速数字化升级。
|
7月前
|
SQL 消息中间件 Kafka
Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
本文介绍了阿里云实时数仓Hologres负责人姜伟华在Flink Forward Asia 2024上的分享,涵盖实时数仓的发展历程、从实时数仓到实时湖仓的演进,以及总结。文章通过三代实时数仓架构的演变,详细解析了Lambda架构、Kafka实时数仓分层+OLAP、Hologres实时数仓分层复用等方案,并探讨了未来从实时数仓到实时湖仓的演进方向。最后,结合实际案例和Demo展示了Hologres + Flink + Paimon在实时湖仓中的应用,帮助用户根据业务需求选择合适的方案。
1197 20
Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
|
6月前
|
SQL 分布式计算 数据处理
【重磅发布】AllData数据中台核心功能:湖仓平台中心
杭州奥零数据科技有限公司成立于2023年,专注于数据中台业务,维护开源项目AllData并提供商业版解决方案。AllData提供数据集成、存储、开发、治理及BI展示等一站式服务,支持AI大模型应用,助力企业高效利用数据价值。
|
7月前
|
存储 SQL 大数据
【重磅发布】AllData数据中台核心功能:湖仓一体化平台
杭州奥零数据科技有限公司成立于2023年,专注于数据中台业务,维护开源项目AllData并提供商业版解决方案。AllData提供数据集成、存储、开发、治理及BI展示等一站式服务,支持AI大模型应用,助力企业高效利用数据价值。
【重磅发布】AllData数据中台核心功能:湖仓一体化平台
|
7月前
|
SQL 存储 HIVE
鹰角基于 Flink + Paimon + Trino 构建湖仓一体化平台实践项目
本文整理自鹰角网络大数据开发工程师朱正军在Flink Forward Asia 2024上的分享,主要涵盖四个方面:鹰角数据平台架构、数据湖选型、湖仓一体建设及未来展望。文章详细介绍了鹰角如何构建基于Paimon的数据湖,解决了Hudi入湖的痛点,并通过Trino引擎和Ranger权限管理实现高效的数据查询与管控。此外,还探讨了湖仓一体平台的落地效果及未来技术发展方向,包括Trino与Paimon的集成增强、StarRocks的应用以及Paimon全面替换Hive的计划。
707 1
鹰角基于 Flink + Paimon + Trino 构建湖仓一体化平台实践项目
|
8月前
|
SQL 监控 关系型数据库
用友畅捷通在Flink上构建实时数仓、挑战与最佳实践
本文整理自用友畅捷通数据架构师王龙强在FFA2024上的分享,介绍了公司在Flink上构建实时数仓的经验。内容涵盖业务背景、数仓建设、当前挑战、最佳实践和未来展望。随着数据量增长,公司面临数据库性能瓶颈及实时数据处理需求,通过引入Flink技术逐步解决了数据同步、链路稳定性和表结构差异等问题,并计划在未来进一步优化链路稳定性、探索湖仓一体架构以及结合AI技术推进数据资源高效利用。
649 25
用友畅捷通在Flink上构建实时数仓、挑战与最佳实践
|
6月前
|
SQL 消息中间件 Serverless
​Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
​Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
179 4
|
6月前
|
SQL 存储 HIVE
鹰角基于 Flink + Paimon + Trino 构建湖仓一体化平台实践项目
鹰角基于 Flink + Paimon + Trino 构建湖仓一体化平台实践项目
398 2
|
8月前
|
存储 运维 监控
金融场景 PB 级大规模日志平台:中信银行信用卡中心从 Elasticsearch 到 Apache Doris 的先进实践
中信银行信用卡中心每日新增日志数据 140 亿条(80TB),全量归档日志量超 40PB,早期基于 Elasticsearch 构建的日志云平台,面临存储成本高、实时写入性能差、文本检索慢以及日志分析能力不足等问题。因此使用 Apache Doris 替换 Elasticsearch,实现资源投入降低 50%、查询速度提升 2~4 倍,同时显著提高了运维效率。
373 3
金融场景 PB 级大规模日志平台:中信银行信用卡中心从 Elasticsearch 到 Apache Doris 的先进实践

相关产品

  • 实时计算 Flink版
  • 推荐镜像

    更多