实时计算的技术难点

曾经天真的认为只要把 Storm 安装好之后，简单学习一下 Storm 的编程概念就可以把实时统计的工作完成了。毕竟实时统计无非就是加减乘除，并不牵涉到什么高深的机器学习算法。然后在实践中发现 Storm 根本没有提供实时统计所必需的很多基础设施和编程抽象，更不要说进行更复杂的通用实时计算了（比如关联两个事件流进行登陆时长统计之类的）。其实坑非常多：

1、如何实现按窗口统计。实时统计本质上就是micro batch，把 batch 计算的窗口从一天缩小到分钟级别甚至秒级。所以实时计算的核心是窗口。而 Storm 的编程模型里没有窗口，如何在上层实现滚动窗口，滑动窗口，累积窗口，甚至是更复杂的基于业务逻辑的时间窗口模型。如何用远小于数据量（5w/s级别）的内存（700多m）实现实时计算。

2、大数据量的处理，合并多partition的数据为统一的汇总结果。统计不但是时间维度的聚合，还包括空间维度的。不同机器的数据，一级级汇总到最后的一行结果。如何处理单机无法统计的数据量？传统的做法是按业务维度分片，分片聚合。新兴的做法是一些hyperloglog之类的概率统计数据结构来做到无需业务逻辑支撑的数据分片。

3、Storm的性能问题：来自于两个方面。逐条处理的模型导致消息处理的overhead 在总消耗中占比非常高，而且逐条处理非常不便于与外部系统做批量读取和存储。spout/bolt 同是承担物理上的分布模型又是编程的逻辑抽象，由于不了解 spout/bolt 的真实开销开发者很容易引入无谓的cpu消耗和网络消耗。如何在Storm上构建高效率的执行框架同时又保持简单的逐条处理模型？

4、高可用的实时计算：Storm内建的ack机制用在实时统计上就是一个笑话。无论是百度的实时计算平台，还是唯品会，拉卡拉的Storm集群，没有一家是把ack机制打开了的。为什么ack不适用于实时统计？如何基于 kafka low-level api实现基于消息重放的高可用机制？（特别是 Spark 1.3 的高可用设计和这个实现不谋而合）

5、Batch 计算和实时计算共享代码，甚至直接用 Storm 进行数据补录之类的 Batch 计算会引入哪些问题。特别是如何处理多 partition 数据处理同步问题？这个方向有很多公司都在尝试，不过敢直接拿实时计算平台算batch作业的，还真没有听说过。

6、很多实时计算平台都限于处理单流数据。如何在流式计算中实现多个数据流的 join？这种 join 的场景是计费。比如 Google 的广告平台 join 了 impression 流 和 click 流实现了对广告上的计费。