摘要：本文整理自喜马拉雅数仓专家王琛老师在8月3日 Streaming Lakehouse Meetup Online（Paimon x StarRocks，共话实时湖仓架构）上的分享。将介绍喜马拉雅直播的业务现状及数据仓库架构的迭代升级，重点分享基于 Flink + Paimon + StarRocks 实现实时湖仓的架构及其成效。我们通过分钟级别的收入监控、实时榜单生成、流量监测和盈亏预警，大幅提升了运营效率与决策质量，并为未来的业务扩展和 AI 项目打下坚实基础。
喜马拉雅直播业务介绍与实时湖仓背景
1.1 喜马拉雅业务概述
多人娱乐厅：为用户提供一个互动交流的平台，他们可以与主持人共同参与讨论或活动。
1.2 直播数仓的建设
1.3 实时背景
直播数仓架构迭代和升级
2.1 架构存在不足
为满足部分实时场景的需求，我们开始尝试使用 Flink 加 Kafka 的组合，或者 Flink 加 StarRocks 的组合来实现更高的实时性。那么，为什么我们没有将所有需要高实时性的数据切换到这两种模式呢？
在尝试 Flink + Kafka 模式时，我们发现其开发和运维的复杂度较高。对于直播数据来说，我们需要跟踪用户的行为，从用户充值到最终产生公司收入的整个链路都需要进行监控。因此，当涉及大量流式数据的 join 操作时，如果这些数据与离线数据出现不一致的情况，排查问题会变得极其困难。
此外，Kafka 的数据生命周期相对较短，这使得在需要进行数据回溯时变得更加困难。这些因素往往导致排查问题的周期延长，增加了运维的复杂性。
流处理中存在大量的流式 Join 操作。如果仅使用 Flink + Kafka，需要持续保留各个流之间的状态信息，这可能导致状态膨胀问题。当任务需要重启时，这些大状态会导致重启失败。如果这种情况发生在活动期间，可能会影响对数据的实时感知。
至于为什么不使用 Flink + StarRocks，是因为如果将所有数据（包括明细数据）都导入 StarRocks，整体成本将会非常高。
2.2 技术选型考虑因素
高稳定性：需要一个高度稳定的系统，确保可靠运行，减少宕机或故障的发生。 高扩展性：需要一个具备高扩展性的架构，以应对业务需求的频繁变化。无论是离线还是实时业务，需求可能会在系统上线后迅速变化，因此高扩展性能够帮助我们应对用户增长和业务扩展的需求。 高实时性：系统必须具备一定的实时处理和反馈能力，以满足对实时性的要求。 低开发门槛：由于团队刚开始接触实时处理，较低的开发门槛有助于快速上手，解决业务实时需求，从而提高团队的整体生产力。 合理的硬件成本：需要考虑性价比高的解决方案，而不是仅依靠大量资源来实现数据实时化。
2.3 数据湖选型对比
喜马拉雅曾调研过市面上的多款数据库产品，主要考察了 Delta Lake 和 Hudi。此前，他们主要使用 Delta Lake，但发现它与 Flink 的集成体验不佳，尤其是在处理 Flink CDC 时表现较差。相比之下，Hudi 虽然在集成上稍有改善，但运维复杂度较高，且在大数据场景下的入库和查询耗费了大量资源。
尽管 Paimon 是一款较新的产品，生态系统和社区支持尚未完全成熟，但它在性能和开发成本上都更具优势。而且，遇到问题时，社区的反馈和解决速度也很及时。最终，喜马拉雅选择了 Paimon 作为数据湖解决方案。
2.4 OLAP 选型对比
在使用 ClickHouse 的过程中，我们遇到了几个比较棘手的问题。首先，ClickHouse 缺乏对高频率、低延迟的修改或删除已存在数据的能力。它只支持更新，但不支持删除操作。此外，它无法自动化更新视图。
更关键的是，ClickHouse 不支持多表关联，因此我们不得不建立大宽表来存储数据。但对于我们来说，无论是自助取数还是构建看板模型，通常都需要多表关联才能实现展示和分析。相比之下，使用阿里云 EMR StarRocks 时，这些场景都能得到很好地支持和兼容。
首先，StarRocks 在基表变动时，物化视图能够自动更新和维护。此外，它支持多种格式的 Join 方式，对于新型雪花模型的关联性能表现更加优越。同时，StarRocks 对多并发查询的支持也非常出色。
StarRocks 提供了四种模型：明细、聚合、组件和更新模型，这些模型已经很好地满足了日常的数据需求。我们在对比了多种方案后，包括传统的离线 Hive、Spark 的分钟和小时级处理，Flink + Kafka、Flink 直接连接 StarRocks 以及 Flink + 数据湖方案，最终选择了 Flink + Paimon + StarRocks 组合。这种架构在性能、成本等方面对我们来说更加友好。
2.5 实时湖仓架构
最初，我们使用的是自研的 Binlog 链进行数据落盘，后来替换为 Flink CDC。这一替换实现了全量和增量数据的无缝衔接，且增量数据部分支持自动扩容。这样极大简化了架构，提高了稳定性，确保数据的精准性与横向扩展能力，同时也提升了数据同步能力。Flink CDC 还支持 schema 字段变更的自动透传至下游，并且不同任务间相互独立运行，保证了数据同步的隔离性。
2.6 自动数据集成工具
2.7 Paimon 应用
2.8 遇到的问题
在差不多两个月的时间里，我们完成了湖仓架构的建设，过程中也遇到了一些问题。
首先，Paimon 的流与流 Join 加载速度慢，尤其是在活动上线时需要更改逻辑。重启任务后，数据无法正常刷新。最初我们怀疑是资源不足，进行了资源倾斜和小文件合并，但问题依然存在。最后发现是没有限定增量读或指定日期读，导致任务每次重启都会从历史分区开始读取。加上参数后问题得以解决，数据刷新速度大大提升。
其次，在 Paimon 表 Join 维度表时，刚开始运行稳定，但几天后出现丢数据的情况。经过排查，发现维度表未持久化，导致过期而丢失数据。通过参考官方文档，使用 Lookup 格式解决了这个问题。
另外，在直播场景中，我们需要对五张不同类型的业务表进行 Union，生成用户打赏主播的明细数据。整体运行稳定，但在夜晚 23:59 后偶尔会丢失少量数据，虽然影响不大，但我们与社区沟通后确认是已知 Bug，并在版本更新后解决了该问题。
实时湖仓的效果和收益
收益主要体现在以下四个方面：
榜单实时化： 实时生成主播流水榜和用户消耗榜，帮助运营团队精准执行点对点的运营策略。
流量实时化： 实时监测 DAU 和 eDAU，掌握直播间的活跃度情况，便于分析和调整运营。
未来展望
其次，我们将继续与 Paimon 和 StarRocks 社区紧密交流，深入挖掘其特性，以推动业务的快速增长。
最后，借助实时湖仓的能力，我们计划进一步支持 AI 项目建设。随着 AI 在各行业的普及，对实时数据的高要求也越来越明显。我们希望通过这一方案，助力公司构建强大的 AI 体系。
