首发于公众号【KAMI说】(kami-said)，原文：《Flink 并不适合实时指标计算》Flink 通过提供 ANSI 标准 SQL 和 Retract 特性，保证聚合计算的精确一致性。 使用 Flink SQL 计算分析指标，例如 PV/UV 等，在语义和功能上是没有问题的。 然而，从代价和效果来讲，Flink 并不适合进行实时指标计算。
IO 和计算的代价太大
进行指标计算，几乎都会涉及聚合统计。Flink 的 Retract 特性，会使得上游一条数据，触发下游生成两条数据，一条 Upsert，一条 Delete。 如果下游有多个聚合统计的级联、有多组 Grouping、以及 JOIN 等操作，衍生的数据量更会成倍成倍地翻。 数据量少还好说。数据量稍微大点，先不说计算量，单是 IO 压力就难承受。瞬时变化指标的分析价值不足
Flink 的流式机制，来一条输入就马上更新输出。算上延迟，实时指标可以做到秒级更新。 然而，这样瞬时变化的指标，既没法校对验证，也没法做定量分析。 做成曲线，做成大盘，看起来很有 feel。说白了，就是能看下趋势，做下定性分析。 能用于定量分析的，还是分钟级、小时级定点准实时更新的指标值。这样的指标，跑批的效率会更高。 消耗了大资源算出来的实时指标，只用于定性分析，有时候并不是那么划算。好的生产实践应该是怎么样的？
- 使用窗口统计和一些 trick，代替聚合统计完成指标计算，避免回撤，可大大减少 IO 和计算量
- 输出指标的一系列曲线点，而不是单值。不要盲目追求更新速度，够用就行，这样可以启用 Flink 的 Local Aggregation 特性减少 IO
- Flink 更适合用于 ETL、推荐、事件等场景。实时/准实时指标可以考虑实时 OLAP 方案
