哪个是针对Lambda架构的纯粹基于流的架构的缺点？

Question

免责声明:我不是一名实时架构专家,我只想抛出一些个人考虑因素并评估其他人的建议或指出.

让我们想象一下,我们想要设计一个实时分析系统.下面,Lambda架构Nathan Marz的定义,为了服务数据,我们需要一个批处理层(即Hadoop),从所有数据的数据集连续重新计算视图,以及所谓的速度层(即Storm)不断处理视图的子集(由批处理层的最后一次完全重新计算后进入的事件产生).您可以通过将两者的结果合并在一起来查询系统.

这种选择背后的基本原理对我来说非常有意义,它结合了软件工程和系统工程观察.拥有不断增长的不可变时间戳事实的主数据集使得系统在计算视图时可以抵御人为错误(如果您执行了错误,只需修复它并在批处理层中重新计算它们)并使系统能够回答几乎任何问题.查询将来会出现.此外,此类数据存储区仅需要支持随机读取和批量插入,而速度/实时部分的数据存储区则需要有效支持随机读取和随机写入,从而增加其复杂性.

我对此讨论的反对/触发因素是,在某些情况下,这种方法可能过度.为了便于讨论,假设我们做了几个简化:

• 让我们假设在我们的分析系统中,我们可以事先定义一小组系统需要能够提供的不可变的用例\查询,并且它们将来不会改变.
• 让我们假设我们拥有有限的资源(工程能力,基础设施等)来实现它.存储到我们系统的整套基本事件,而不是已经预先计算了视图\聚合,可能只是太昂贵了.
• 让我们假设我们成功地将人类错误的影响降到最低(...).

系统仍然需要可扩展,并处理不断增加的流量和数据.鉴于这些观察结果,我想知道是什么阻止我们设计一个完全面向流的架构.我想象的是一个体系结构,其中事件(即页面视图)被推入流中,可能是RabbitMQ + Storm或Amazon Kinesis,并且这些流的消费者将通过随机写入/更新来直接更新所需的视图. NoSQL数据库(即MongoDB).

在第一次近似中,我认为这种架构可以水平扩展.Storm可以集群化,而Kinesis预计QoS也可以预先保留.更多的传入事件将意味着更多的流消费者,并且因为它们是完全独立的,所以没有什 关于数据库,使用适当的策略对其进行分片将使我们将越来越多的写入分发给越来越多的分片.为了避免读取受到影响,每个分片可以有一个或多个只读副本.在可靠性方面,Kinesis承诺可靠地存储您的消息长达24小时,并且正确使用确认机制的分布式RabbitMQ(或您选择的任何队列系统)可能满足相同的要求.

故意(我相信)亚马逊关于Kinesis的文档避免将您锁定在特定的架构解决方案中,但我的总体印象是,他们希望推动开发人员简化Lambda架构并获得类似于我的完全基于流的解决方案.暴露了.为了更加符合Lambda体系结构的要求,没有什么能阻止我们与消费者不断更新我们的视图并行,一组处理传入事件并将它们作为原子不可变单元存储在不同数据存储区中的消费者.在将来用于生成新视图(例如通过Hadoop)或重新计算错误数据.

你对这个推理有什么看法？我想知道在哪些场景中纯粹基于流的架构无法扩展,如果你有任何其他观察,那么Lambda架构的vs\cons与基于流的架构相比.