DR阿福1. 长周期去重指标的业务挑战与技术痛点
在实时数据仓库建设中，长周期去重指标（如30天UV）一直是让数据工程师头疼的难题。最近在帮某电商平台优化他们的实时看板时，就遇到了一个典型场景：运营部门要求提供"最近30天商品详情页UV"的实时看板，要求每分钟更新一次，且误差率必须控制在1%以内。
1.1 传统方案的致命缺陷
我们首先尝试了两种常规方案，但都遇到了严重问题：
纯实时方案（Flink状态存储）
- 实现方式：使用Flink的KeyedState存储全量用户ID
- 实测数据：每天约1200万独立用户，30天需要存储3.6亿条记录
- 资源消耗：单任务需要配置32GB内存，checkpoint时间长达8分钟
- 致命问题：连续运行4天后发生OOM，导致看板数据中断6小时
纯离线方案（每日批处理）
- 实现方式：每天凌晨用Spark跑全量计算
- 时效性：数据延迟12-24小时
- 业务反馈：无法支持大促期间的实时决策需求
1.2 核心矛盾的本质分析
这个问题的本质在于"CAP理论"在实时数仓中的体现：
- 实时性（低延迟）与 准确性（精确去重）存在天然矛盾
- 计算资源 与 时间窗口长度 呈指数级关系
- 状态管理 成为系统稳定性的瓶颈
通过压力测试我们发现：当时间窗口超过7天时，纯实时方案的成本会呈非线性增长。这正是我们需要混合架构的根本原因。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 混合架构的技术方案设计
2.1 整体架构解析
我们的解决方案采用"实时增量+离线存量+统一服务层"的三层架构：
code复制[数据源]
│
├─[实时链路] Kafka → Flink → Paimon(DWD) → Flink(RBM聚合) → Doris
│
└─[离线链路] Paimon → Spark(RBM聚合) → Doris
│
└─[回溯补偿] 历史数据修正
2.1.1 关键设计原则
-
热冷数据分离：
- 热数据（当天）：实时精确计算
- 温数据（T-1）：准实时补偿
- 冷数据（T-2及以前）：离线全量计算
-
存储计算解耦：
- 使用Paimon作为流批统一存储层
- 计算层根据时效要求灵活选择引擎
-
去重算法分级：
- 实时路径：RBM（精确）
- 离线路径：RBM（精确）+ 可选Theta（近似）
2.2 核心组件选型对比
2.2.1 存储层选型
我们对主流数据湖组件进行了基准测试：
| 特性 | Paimon | Hudi | Icebe