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

阅读更多

扫码向博主提问

FeelTouch

非学,无以致疑;非问,无以广识
去开通我的Chat快问
换一批

没有更多推荐了,返回首页