选实时还是离线聚合，取决于业务能否等待：能等t+1的优先离线；需秒级响应且可容忍微小误差的才上实时。flink sql负责流式预聚合（如5秒窗口统计），clickhouse适合即席查询或补漏重算，不替代flink的低延迟窗口语义。
选实时还是离线聚合，不看技术炫不炫，只看业务能不能等——能等T+1的，一律优先离线；要求秒级响应、且能容忍微小误差的，才上实时。
实时聚合用 Flink SQL 还是 ClickHouse？
不是“哪个更好”，而是“谁更贴合链路位置”。Flink SQL 做的是流式预聚合（比如每5秒窗口统计订单数），输出结果到下游存储；ClickHouse 适合接聚合结果做即席查询或补漏重算，但它本身不承担原始流的持续聚合任务。
-
Flink SQL的GROUP BY TUMBLING WINDOW或HOPPING WINDOW是实时聚合主力，但必须配水位线（WATERMARK）防乱序，否则迟到数据会丢或触发 retract -
ClickHouse的MATERIALIZED VIEW虽支持实时物化，但底层仍是批量写入（默认 100ms 合并一次），无法替代 Flink 的低延迟窗口语义 - 常见错误：把 ClickHouse 当流引擎直连 Kafka 拉数据做 GROUP BY —— 会因无状态、无 watermark 导致统计漂移，尤其在分区重平衡或网络抖动时
离线聚合为什么不能简单“加个定时任务”就变实时？
离线聚合本质是快照计算，每次跑的是截至某时刻的全量或增量快照。强行缩短调度周期（比如从每天改成每分钟跑一次），只会放大三个问题：
- 小文件爆炸：
Hive或Spark每分钟生成一个分区，元数据压力陡增，MSCK REPAIR TABLE频繁失败 - 中间态不可靠：上游数据还没写完就触发调度，查到的是截断数据，报表数字跳变
- 资源争抢：多个“准实时”任务同时拉取同一张源表，IO 打满，反拖慢真正需要 T+1 的核心报表
真要提升离线时效，应走增量路径：用 binlog + Kafka 捕获变更，再用 Spark Structured Streaming 做微批合并，而非硬调调度频率。
JOIN 在实时和离线场景下的行为差异
离线 JOIN 是确定性操作，跑完就定型；实时 JOIN 是持续过程，结果随时间推移动态更新——这点直接决定你能否信任中间指标。
- 事实流
LEFT JOIN维度表（如订单JOIN用户信息）：Flink 默认用Temporal JOIN，依赖维度表的PROCTIME或EVENT TIME，查不到时返回 NULL，不会阻塞主流程 - 事实流
JOIN事实流（如曝光JOIN点击）：必须用INTERVAL JOIN设定时间范围（如BETWEEN 0 SECOND AND 300 SECOND），否则REGULAR JOIN会产生 retract，导致下游指标反复增减 - 离线中常见的
MAP JOIN或广播维表，在实时里对应LOOKUP JOIN，但要注意维度表更新频率——若维度每小时更新一次，cache过期策略设成ALL就会查到陈旧数据
真正的难点不在语法怎么写，而在“什么时候该让数据等一等”——实时链路里所有 timeout、watermark、cache ttl 的取值，本质上都是在用可控延迟换数据一致性。没人能绕开这个权衡，只能根据业务对“错多少能接受”来填参数。
