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 流实现了对广告上的计费。