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

作者：王琛喜马拉雅数仓专家

小编导读：

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

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

喜马拉雅业务概述

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

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

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

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

直播数仓的建设

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

实时背景

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

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

直播数仓架构迭代和升级

架构存在不足

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

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

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

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

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

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

技术选型考虑因素

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

高稳定性：需要一个高度稳定的系统，确保可靠运行，减少宕机或故障的发生。
高扩展性：需要一个具备高扩展性的架构，以应对业务需求的频繁变化。无论是离线还是实时业务，需求可能会在系统上线后迅速变化，因此高扩展性能够帮助我们应对用户增长和业务扩展的需求。
高实时性：系统必须具备一定的实时处理和反馈能力，以满足对实时性的要求。
低开发门槛：由于团队刚开始接触实时处理，较低的开发门槛有助于快速上手，解决业务实时需求，从而提高团队的整体生产力。
合理的硬件成本：需要考虑性价比高的解决方案，而不是仅依靠大量资源来实现数据实时化。

数据湖选型对比

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

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

OLAP选型对比

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

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

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

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

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

实时湖仓架构

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

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

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

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

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

自研数据集成工具

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

Paimon 应用

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

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

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

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

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

遇到的问题

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

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

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

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

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