Paimon x StarRocks 助力喜马拉雅直播实时湖仓构建

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: 本文由喜马拉雅直播业务与仓库建设负责人王琛撰写,介绍了喜马拉雅直播业务的数据仓库架构迭代升级。文章重点分享了基于 Flink + Paimon + StarRocks 实现实时湖仓的架构及其成效,通过分钟级别的收入监控、实时榜单生成、流量监测和盈亏预警,大幅提升了运营效率与决策质量,并为未来的业务扩展和 AI 项目打下坚实基础。

作者:王琛 喜马拉雅直播业务与仓库的建设负责人/数仓专家。

本文将介绍喜马拉雅直播的业务现状及数据仓库架构的迭代升级,重点分享基于 Flink + Paimon + StarRocks 实现实时湖仓的架构及其成效。我们通过分钟级别的收入监控、实时榜单生成、流量监测和盈亏预警,大幅提升了运营效率与决策质量,并为未来的业务扩展和 AI 项目打下坚实基础。

一、喜马拉雅直播业务介绍与实时湖仓背景

1. 喜马拉雅业务概述

首先,简要介绍一下喜马拉雅的业务。我们的直播业务主要分为音频直播、视频直播以及多人娱乐厅三大类。

音频直播:由专业主播为用户提供有声书、知识讲座等内容。

视频直播:与市面上多数视频直播类似,包括主播表演和游戏直播等内容。

多人娱乐厅:为用户提供一个互动交流的平台,他们可以与主持人共同参与讨论或活动。

2. 直播数仓的建设

喜马拉雅的直播数仓建设与多数公司类似,分为 ODS 贴源层、DWD、DWS 公共层,以及 ADM 应用层。数据主要来源于中台的订单数据、业务数据和流量日志数据,核心围绕流量、互动和交易展开。下游数据则支持画像看板、主播后台、AB 平台以及自助取数等应用,提供数据支持。当前数据处理仍以离线模式为主。然而,面对信息量的爆炸式增长,单靠离线处理难以满足业务需求,因此公司迫切希望构建实时湖仓以应对挑战。

image

3. 实时背景

首先,公司需要一个实时的数据监控和分析系统,以便及时发现问题并迅速调整策略,以适应市场环境的变化。此外,在获得用户隐私授权下,获取用户的实时行为数据至关重要,这不仅有助于进行个性化推荐,还能及时获取用户的互动反馈,并基于这些反馈调整策略和活动。整体目标是提升用户体验和满意度,增强用户粘性。

尽管我们之前已经做了许多尝试,但实时数据系统的建设依然是一个巨大的挑战。

二、直播数仓架构迭代和升级

1. 架构存在不足

在直播数仓的架构迭代与升级过程中,目前主要依赖 Spark 跑批 T+1 任务,通过 Hive 来执行数据处理。对于部分实时性要求较高的场景,通常通过 Spark 的小时任务或分钟任务来执行。然而,这些方式依然无法真正实现实时效果。

为满足部分实时场景的需求,我们开始尝试使用 Flink 加 Kafka 的组合,或者 Flink 加 StarRocks 的组合来实现更高的实时性。那么,为什么我们没有将所有需要高实时性的数据切换到这两种模式呢?

在尝试 Flink + Kafka 模式时,我们发现其开发和运维的复杂度较高。对于直播数据来说,我们需要跟踪用户的行为,从用户充值到最终产生公司收入的整个链路都需要进行监控。因此,当涉及大量流式数据的 join 操作时,如果这些数据与离线数据出现不一致的情况,排查问题会变得极其困难。

此外,Kafka 的数据生命周期相对较短,这使得在需要进行数据回溯时变得更加困难。这些因素往往导致排查问题的周期延长,增加了运维的复杂性。

流处理中存在大量的流式 Join 操作。如果仅使用 Flink + Kafka,需要持续保留各个流之间的状态信息,这可能导致状态膨胀问题。当任务需要重启时,这些大状态会导致重启失败。如果这种情况发生在活动期间,可能会影响对数据的实时感知。

至于为什么不使用 Flink + StarRocks,是因为如果将所有数据(包括明细数据)都导入 StarRocks,整体成本将会非常高。

2. 技术选型考虑因素

为了满足当前的实时需求,我们主要从以下五个方面进行考虑:

  1. 高稳定性:需要一个高度稳定的系统,确保可靠运行,减少宕机或故障的发生。

  2. 高扩展性:需要一个具备高扩展性的架构,以应对业务需求的频繁变化。无论是离线还是实时业务,需求可能会在系统上线后迅速变化,因此高扩展性能够帮助我们应对用户增长和业务扩展的需求。

  3. 高实时性:系统必须具备一定的实时处理和反馈能力,以满足对实时性的要求。

  4. 低开发门槛:由于团队刚开始接触实时处理,较低的开发门槛有助于快速上手,解决业务实时需求,从而提高团队的整体生产力。

  5. 合理的硬件成本:需要考虑性价比高的解决方案,而不是仅依靠大量资源来实现数据实时化。

3. 数据湖选型对比

image

喜马拉雅曾调研过市面上的多款数据库产品,主要考察了 Delta Lake 和 Hudi。此前,他们主要使用 Delta Lake,但发现它与 Flink 的集成体验不佳,尤其是在处理 Flink CDC时表现较差。相比之下,Hudi 虽然在集成上稍有改善,但运维复杂度较高,且在大数据场景下的入库和查询耗费了大量资源。

尽管 Paimon 是一款较新的产品,生态系统和社区支持尚未完全成熟,但它在性能和开发成本上都更具优势。而且,遇到问题时,社区的反馈和解决速度也很及时。最终,喜马拉雅选择了 Paimon 作为数据湖解决方案。

4. OLAP选型对比

在解决了数据实时入湖的问题后,公司还重点关注了如何提升用户查询速度。喜马拉雅曾深度使用 ClickHouse,并对 ClickHouse 和 阿里云EMR StarRocks 进行了全面对比。

在使用 ClickHouse 的过程中,我们遇到了几个比较棘手的问题。首先,ClickHouse 缺乏对高频率、低延迟的修改或删除已存在数据的能力。它只支持更新,但不支持删除操作。此外,它无法自动化更新视图。

更关键的是,ClickHouse 不支持多表关联,因此我们不得不建立大宽表来存储数据。但对于我们来说,无论是自助取数还是构建看板模型,通常都需要多表关联才能实现展示和分析。相比之下,使用 阿里云EMR StarRocks 时,这些场景都能得到很好地支持和兼容。

image

首先,StarRocks 在基表变动时,物化视图能够自动更新和维护。此外,它支持多种格式的 Join 方式,对于新型雪花模型的关联性能表现更加优越。同时,StarRocks 对多并发查询的支持也非常出色。

StarRocks 提供了四种模型:明细、聚合、组件和更新模型,这些模型已经很好地满足了日常的数据需求。我们在对比了多种方案后,包括传统的离线 Hive、Spark 的分钟和小时级处理,Flink + Kafka、Flink 直接连接 StarRocks 以及 Flink + 数据湖方案,最终选择了 Flink + Paimon + StarRocks 组合。这种架构在性能、成本等方面对我们来说更加友好。

image

5. 实时湖仓架构

针对数据选型,我们设计了一个全新的湖仓架构。对于数据源,如 MySQL 和埋点流量日志,我们通过 Flink CDC 直接将数据写入 Paimon,Paimon 作为 ODS 层,为离线和实时处理提供数据支持。

在实时处理部分,我们使用 Flink 进行数据清洗后,再写入 Paimon,Paimon 进行表间关联,最终将结果写入 StarRocks。StarRocks 利用物化视图和 OLAP 功能,为下游应用提供快速查询支持。

在离线部分,Paimon 同样作为 ODS 层,凭借其组件化更新特性,解决了传统离线处理中的数据延迟问题。例如,订单数据可能延迟多日甚至数周才更新,但通过 Paimon 的主键更新机制,我们无需额外回传处理,离线数据的准确性也因此得到了提升。

image

最终,无论是离线还是实时数据,都通过 StarRocks 对外导出。得益于 StarRocks 出色的查询性能,确保了数据输出的一致性。这种架构不仅稳定性高、实时性强,开发也更加简单。

最初,我们使用的是自研的 Binlog 链进行数据落盘,后来替换为 Flink CDC。这一替换实现了全量和增量数据的无缝衔接,且增量数据部分支持自动扩容。这样极大简化了架构,提高了稳定性,确保数据的精准性与横向扩展能力,同时也提升了数据同步能力。Flink CDC 还支持 schema 字段变更的自动透传至下游,并且不同任务间相互独立运行,保证了数据同步的隔离性。

6. 自研数据集成工具

为了简化操作,平台团队还为我们开发了一款数据集成工具。只需简单配置数据来源和去向,工具就能自动生成 Flink CDC 代码并完成字段级别的映射。这大大提升了我们的开发效率。

image

7. Paimon 应用

原先从数据源同步到数据库可能需要半天到一天的时间才能完成一张表的同步。但自从使用了平台的数据集成工具后,第一次仅用一周时间就完成了50多张表的实时同步,速度显著提升。

我们的架构主要有三大应用:

Paimon 的流读功能:大大提升了实时数据处理的效率。

Paimon 的永久日志保存:不仅支撑了实时库的建设,还作为离线数据存储的 ODS 层基石。

基于组件的更新机制:例如订单状态频繁变更时,Paimon 能够通过组件进行自动更新,避免重复刷新过去半个月的数据。即使主从同步出现延迟,昨天的数据也会通过 T+1 的机制确保次日更新到表中。

8. 遇到的问题

image

在差不多两个月的时间里,我们完成了湖仓架构的建设,过程中也遇到了一些问题。

首先,Paimon 的流与流 Join 加载速度慢,尤其是在活动上线时需要更改逻辑。重启任务后,数据无法正常刷新。最初我们怀疑是资源不足,进行了资源倾斜和小文件合并,但问题依然存在。最后发现是没有限定增量读或指定日期读,导致任务每次重启都会从历史分区开始读取。加上参数后问题得以解决,数据刷新速度大大提升。

其次,在 Paimon 表 Join 维度表时,刚开始运行稳定,但几天后出现丢数据的情况。经过排查,发现维度表未持久化,导致过期而丢失数据。通过参考官方文档,使用 Lookup 格式解决了这个问题。

另外,在直播场景中,我们需要对五张不同类型的业务表进行 Union,生成用户打赏主播的明细数据。整体运行稳定,但在夜晚 23:59 后偶尔会丢失少量数据,虽然影响不大,但我们与社区沟通后确认是已知 Bug,并在版本更新后解决了该问题。

总体来看,我们最大的挑战是用离线思维去开发实时数据,这确实有所不同。另外,Paimon 和 StarRocks 的表结构和参数设置上我们最初也没有完全摸清楚。尽管如此,整体搭建过程中的卡点不多,进展顺利。到 Q2 底,我们已成功完成整个架构的建设,并在直播周年庆活动中正式投入使用,取得了显著的效果和收益。

三、实时湖仓的效果和收益

收益主要体现在以下四个方面:

收入实时化: 通过分钟级别的收入监控,实时感知数据变化,提升业务分析效率和决策质量。

榜单实时化: 实时生成主播流水榜和用户消耗榜,帮助运营团队精准执行点对点的运营策略。

流量实时化: 实时监测 DAU 和 eDAU,掌握直播间的活跃度情况,便于分析和调整运营。

监控实时化: 实时盈亏监控与预警,通过指标关系图快速定位问题,避免未知损失。

四、未来的展望和规划

首先,我们的项目在直播业务场景下已经取得了显著成效。接下来,我们将进一步扩展实时湖仓的应用到其他业务领域,例如广告业务和喜马拉雅的订单管理,逐步推动更多业务接入这一方案。

其次,我们将继续与 Paimon 和 StarRocks 社区紧密交流,深入挖掘其特性,以推动业务的快速增长。

最后,借助实时湖仓的能力,我们计划进一步支持 AI 项目建设。随着 AI 在各行业的普及,对实时数据的高要求也越来越明显。我们希望通过这一方案,助力公司构建强大的 AI 体系。

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
28天前
|
存储 缓存 数据挖掘
StarRocks 原理详解:探索高效 OLAP 的奥秘
StarRocks 是一款高性能分析型数据仓库,采用向量化、MPP架构、CBO等技术,实现多维、实时、高并发的数据分析。它支持从各类数据源高效导入数据,兼容MySQL协议,并具备水平扩展、高可用等特性,广泛应用于实时数仓、OLAP报表等场景。StarRocks 解决了传统数仓在查询性能、数据导入、扩展性和灵活性等方面的挑战,助力企业实现数据驱动的决策。其分布式架构和智能物化视图等功能显著提升了查询效率,适用于大数据生态中的各种复杂需求。
211 15
|
4天前
|
SQL 消息中间件 Kafka
Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
本文介绍了阿里云实时数仓Hologres负责人姜伟华在Flink Forward Asia 2024上的分享,涵盖实时数仓的发展历程、从实时数仓到实时湖仓的演进,以及总结。文章通过三代实时数仓架构的演变,详细解析了Lambda架构、Kafka实时数仓分层+OLAP、Hologres实时数仓分层复用等方案,并探讨了未来从实时数仓到实时湖仓的演进方向。最后,结合实际案例和Demo展示了Hologres + Flink + Paimon在实时湖仓中的应用,帮助用户根据业务需求选择合适的方案。
331 20
Flink+Paimon+Hologres,面向未来的一体化实时湖仓平台架构设计
|
3天前
|
SQL 运维 BI
湖仓分析|浙江霖梓基于 Doris + Paimon 打造实时/离线一体化湖仓架构
浙江霖梓早期基于 Apache Doris 进行整体架构与表结构的重构,并基于湖仓一体和查询加速展开深度探索与实践,打造了 Doris + Paimon 的实时/离线一体化湖仓架构,实现查询提速 30 倍、资源成本节省 67% 等显著成效。
湖仓分析|浙江霖梓基于 Doris + Paimon 打造实时/离线一体化湖仓架构
|
25天前
|
存储 人工智能 分布式计算
湖仓实时化升级 :Uniflow 构建流批一体实时湖仓
本文整理自阿里云产品经理李昊哲在Flink Forward Asia 2024流批一体专场的分享,涵盖实时湖仓发展趋势、基于Flink搭建流批一体实时湖仓及Materialized Table优化三方面。首先探讨了实时湖仓的发展趋势和背景,特别是阿里云在该领域的领导地位。接着介绍了Uniflow解决方案,通过Flink CDC、Paimon存储等技术实现低成本、高性能的流批一体处理。最后,重点讲解了Materialized Table如何简化用户操作,提升数据查询和补数体验,助力企业高效应对不同业务需求。
414 18
湖仓实时化升级 :Uniflow 构建流批一体实时湖仓
|
1月前
|
SQL 监控 关系型数据库
用友畅捷通在Flink上构建实时数仓、挑战与最佳实践
本文整理自用友畅捷通数据架构师王龙强在FFA2024上的分享,介绍了公司在Flink上构建实时数仓的经验。内容涵盖业务背景、数仓建设、当前挑战、最佳实践和未来展望。随着数据量增长,公司面临数据库性能瓶颈及实时数据处理需求,通过引入Flink技术逐步解决了数据同步、链路稳定性和表结构差异等问题,并计划在未来进一步优化链路稳定性、探索湖仓一体架构以及结合AI技术推进数据资源高效利用。
404 25
用友畅捷通在Flink上构建实时数仓、挑战与最佳实践
|
2月前
|
SQL 存储 缓存
EMR Serverless StarRocks 全面升级:重新定义实时湖仓分析
本文介绍了EMR Serverless StarRocks的发展路径及其架构演进。首先回顾了Serverless Spark在EMR中的发展,并指出2021年9月StarRocks开源后,OLAP引擎迅速向其靠拢。随后,EMR引入StarRocks并推出全托管产品,至2023年8月商业化,已有500家客户使用,覆盖20多个行业。 文章重点阐述了EMR Serverless StarRocks 1.0的存算一体架构,包括健康诊断、SQL调优和物化视图等核心功能。接着分析了存算一体架构的挑战,如湖访问不优雅、资源隔离不足及冷热数据分层困难等。
|
2月前
|
存储 关系型数据库 BI
实时计算UniFlow:Flink+Paimon构建流批一体实时湖仓
实时计算架构中,传统湖仓架构在数据流量管控和应用场景支持上表现良好,但在实际运营中常忽略细节,导致新问题。为解决这些问题,提出了流批一体的实时计算湖仓架构——UniFlow。该架构通过统一的流批计算引擎、存储格式(如Paimon)和Flink CDC工具,简化开发流程,降低成本,并确保数据一致性和实时性。UniFlow还引入了Flink Materialized Table,实现了声明式ETL,优化了调度和执行模式,使用户能灵活调整新鲜度与成本。最终,UniFlow不仅提高了开发和运维效率,还提供了更实时的数据支持,满足业务决策需求。
|
2月前
|
SQL 存储 分布式计算
Hologres+Paimon构建一体化实时湖仓
Hologres 3.0全新升级,面向未来的一体化实时湖仓。它支持多种Table Format,提供湖仓存储、多模式计算、分析服务和Data+AI一体的能力。Hologres与Paimon结合,实现统一元数据管理、极速查询性能、增量消费及ETL功能。Dynamic Table支持流式、增量和全量三种刷新模式,满足不同业务需求,实现一份数据、一份SQL、一份计算的多模式刷新。该架构适用于高时效性要求的场景,也可用于成本敏感的数据共享场景。
|
2月前
|
DataWorks 数据挖掘 大数据
方案实践测评 | DataWorks集成Hologres构建一站式高性能的OLAP数据分析
DataWorks在任务开发便捷性、任务运行速度、产品使用门槛等方面都表现出色。在数据处理场景方面仍有改进和扩展的空间,通过引入更多的智能技术、扩展数据源支持、优化任务调度和可视化功能以及提升团队协作效率,DataWorks将能够为企业提供更全面、更高效的数据处理解决方案。
|
3月前
|
SQL 流计算 关系型数据库
基于OpenLake的Flink+Paimon+EMR StarRocks流式湖仓分析
阿里云OpenLake解决方案建立在开放可控的OpenLake湖仓之上,提供大数据搜索与AI一体化服务。通过元数据管理平台DLF管理结构化、半结构化和非结构化数据,提供湖仓数据表和文件的安全访问及IO加速,并支持大数据、搜索和AI多引擎对接。本文为您介绍以Flink作为Openlake方案的核心计算引擎,通过流式数据湖仓Paimon(使用DLF 2.0存储)和EMR StarRocks搭建流式湖仓。
629 5
基于OpenLake的Flink+Paimon+EMR StarRocks流式湖仓分析