实时与离线统计应按场景选型：实时适合低延迟场景但运维复杂，离线适合高准确要求但存在延迟，混合架构通过分层协同兼顾时效与准确。
实时统计和离线统计不是“选哪个更好”，而是“在什么场景用哪个更合适”。关键看业务对数据延迟、准确性、计算资源和维护成本的容忍度。
实时统计：快但有代价
依赖流式计算引擎（如 Flink、Spark Streaming、Kafka + ksqlDB），数据写入后秒级甚至毫秒级产出指标。适合监控告警、实时推荐、风控拦截等对时效性敏感的场景。
- 数据源通常是消息队列（Kafka/Pulsar）或数据库变更日志（CDC）
- 状态管理需谨慎——窗口划分、乱序处理、Exactly-Once 保障都会增加复杂度
- 指标口径易漂移：逻辑变更需重启作业，上线风险高；聚合粒度难灵活调整（比如临时想加一个按小时 + 地域的交叉维度）
- 运维压力大：作业延迟、背压、Checkpoint 失败等问题需要持续盯控
离线统计：稳但有延迟
基于批处理（如 Spark SQL、Hive、Trino）按天 / 小时调度执行，数据经 ETL 清洗后写入数仓分层表（DWD→DWS→ADS）。适合报表分析、经营决策、模型训练等对一致性与可解释性要求高的场景。
- SQL 表达清晰，口径统一，历史可追溯，支持复杂 Join 和多维下钻
- 计算资源可错峰调度，任务失败重跑成本低，容错性强
- 缺点是 T+1 或小时级延迟，无法响应瞬时变化；小文件、数据倾斜、调度依赖链长可能拖慢整体产出
混合架构：不是二选一，而是分层协同
成熟的数据平台通常采用 Lambda 或 Kappa 架构演进后的务实方案：用离线链路保底准确，用实时链路补短时效，再通过统一语义层（如指标平台）对齐口径。
- 核心指标（如日活、GMV）双跑：实时出初版（带标注“预估”），离线跑完后自动覆盖
- 明细层统一：ODS 层同时接入 CDC 日志和批量同步数据，避免实时 / 离线两套原始数据源
- 聚合层分离但对齐：DWS 实时表（Flink 持久化到 Doris/StarRocks）和 DWS 离线表（Hive/ClickHouse）字段、单位、空值处理逻辑完全一致
- 查询层收口：BI 工具或 API 层根据时间范围自动路由——查今天用实时表，查上周用离线表
选型建议：从问题出发，而非技术出发
别一上来就定“我们要上 Flink”，先问清楚：
- 业务能接受的最长延迟是多少？5 分钟？2 小时？还是必须“现在”？
- 指标是否需要回溯修正？比如订单取消后要扣减当日成交额——实时流很难撤回已输出结果，离线重跑更自然
- 当前团队是否有流式作业调优经验？有没有能力快速定位 watermark 偏移或 state backend 故障？
- 存储是否支持高效点查 + 范围扫描？实时结果若存在 Kafka，BI 直接查不现实；得落地到 OLAP 引擎，这又引入新组件和同步成本
架构设计的核心不是堆技术，而是让数据在正确的时间、以正确的精度、被正确的人用上。实时和离线不是对立面，是同一张数据价值地图上的不同图层。
