背景介绍

业务背景

抖音集团的部分网站型业务以内容推动领域，主要依靠短视频和直播为载体提供内容。对游戏玩家而言，目标是实现从“看游戏”到“玩游戏”的完整产品链；对游戏达人，则是激发其创作丰富多元的游戏内容并获得相应回报；对游戏厂商，则提供一站式经营能力方法。

数仓建设

实时数仓采用领域通用分层架构：

• ODS 层：客户端埋点、服务端日志、业务 Binlog 等原始数据。
• DWD 层：按内容供给、消费、使用者转化、互动等维度划分业务域。
• APP 层：多种存储满足批式与流式购买需求，支持实时大盘、分析、特征与预警。

架构实现 & 痛点梳理

传统 Flink + MQ 架构实现如下图所示：从 ODS → DWD → APP。DWD 通过 ETL 与维表关联。但面临以下痛点：

1. K/V 存储稳定性压力：高流量场景下 Lookup Join 对外部 KV 的访问频繁，导致外部存储瓶颈与稳定性挑战。
2. Mq 无 Exactly‑Once 语义：DWD 需要手动去重，增加复杂度。
3. Keyed State 泡沫增长：DWS 层需要消费 DWD 的 Changelog。但由于 MQ 不支持此类型，需要在 Flink 中使用 Last_Value 等手段构造 Retract 消息，导致大量 Keyed State 与任务不稳定。
4. DWS 层测试需将每层 MQ 数据同步至 Hive。再进行比对，耗时且成本高。

Paimon 介绍与湖仓一体架构

Paimon 是一个低延迟、高吞吐的数据湖引擎。可同时支持流式订阅与批式查询，并与 Flink 集成最为紧密。其实，基于 Paimon 的湖仓一体架构可简化为：ODS → DWD→ DWS。无须外部 KV 与 Hive。说到主要有，

• No external KV required: DWD 直接使用 Paimon 表做 Lookup Join。大幅降低外部依赖与成本，
• No deduplication needed: DWS 可直接消费 DWD 的 Changelog，无需人工去重。
• Simplified testing:Paimon 支持批读/写。无需 Hive，同步更快且新鲜度可达分钟级。
• Caching & state reduction:Paimon 内置 LSM‑Tree 支持高并发点查，Keyed State 大幅下降。

落地实践

长周期指标聚合计算场景 – 背景介绍

主播直播后希望快速查看举报人数指标，以调整直播间内容。举报信息先写入业务库并提交审核队列，审核完成后状态更新。实时数仓直播间维度的举报指标，并通过指标服务提供查询。目前查询 QPS 在 xkzQPS ≈ 300 左右,高并发会导致状态膨胀与任务不稳定。怎么说呢，

痛点汇总 – Flink+MQ 原方案难题

1. Mq 不支持 Changelog 类型。需要手动转换为 Retract 消息；这在高并发下会产生大量 Keyed State，导致内存使用爆炸甚至任务崩溃。2.由于审核时间不固定，状态生命周期难以确定，使得状态线性膨胀。 不过，3.Doris 集群限流：当查询 QPS 接近上限时经常触发限流。对使用者体验产生负面影响。4.DWS 测试流程仍需 Hive 同步，新鲜度受限且测试成本高。5.KV 存储稳定性风险：Lookup Join 对外部 KV 的频繁访问容易出现瓶颈或故障。6.Mq 无 Exactly‑Once 语义导致去重逻辑冗余。7.Flink 作业结构复杂，需要整合多组件。9.CPU 与磁盘 IO 压力大，多层缓存 & 状态管理消耗资源。10.整体维护运维成本偏高。7条痛点汇总

方案演进 – 从 Flink+MQ 到 Doris 再到 Piamn

Piamn 方案 – 简化流程与显著收益

大流量端到端场景 – 业务背景

运营想要及时查看短视频内容的消费指标，以调整经营策略。只是原始短视频指标未携带游戏相关信息，需要全量短视频数据并关联游戏属性才能得到完整指标。在峰值 RPS 可达万级别时维度关联成为瓶颈挑战。

痛点汇总 – Flink+MQ 原方案难题

1.Mq 不支持 Changelog 类型。在 DWS 聚合前需要再一次转换为 Retract 消息，大量 Keyed State 占用内存；2.DW 阻塞：KV 缓存命中率 %30%,cache ttl 设置 T_minute = xx 分钟;当峰值 RPS 时仍需访问外部 KV，每秒上万请求带来网络延迟与压力；3.PK 大小爆炸：分钟指标持续变化且在 Changelog 中产生大量变更记录；DWS 聚合过程中必须保持历史变更，使得状态极其庞大；4.Flink 作业不稳定：持续增大的 Keyed State 导致资源泄露或任务崩溃；5.Mq 重复消息导致重复计数错误；6.Lag 延迟高：由于多次 Kafka 转换导致总体延迟达到秒级以上，不满足实时需求。7.测试流程繁琐且新鲜度低。8.KV 存储网络瓶颈，9.SLA 与 SLA 未达成，高并发时无法满足请求。10.运维人员需要维护多个组件。11.CPU/IO 成本高。12.Slack/监控不足。14 条痛点

展开更多细节

详细说明

**详细拆解

*... *

END?，

最终结论

Scrolling ...