关闭。这个问题是基于意见的。它目前不接受答案。
**想改进这个问题吗？**更新这个问题，这样就可以通过编辑这篇文章用事实和引文来回答。

6年前关门了。
改进这个问题
免责声明：我不是一个实时架构Maven，我只想抛出一些个人考虑，并评估其他人会建议或指出什么。
假设我们想设计一个实时分析系统。根据lambda架构nathan marz的定义，为了服务于数据，我们需要一个批处理层（即hadoop），从所有数据的数据集中不断地重新计算视图，以及所谓的速度层（即storm），它不断地处理视图的一个子集（由批处理层最后一次完全重新计算之后出现的事件生成）。通过将两者的结果合并在一起，可以查询系统。
这个选择背后的基本原理对我来说非常有意义，它是软件工程和系统工程观察的结合。拥有一个不断增长的不可变时间戳事实的主数据集，使系统能够在计算视图时抵御人为错误（如果发生错误，只需修复错误并在批处理层重新计算），并使系统能够回答将来可能出现的几乎任何查询。此外，这样的数据存储将要求仅支持随机读取和批插入，而用于速度/实时部分的数据存储将要求有效地支持随机读取和随机写入，从而增加其复杂性。
我的反对意见/引发讨论的原因是，在某些情况下，这种方法可能有点过头了。为了便于讨论，假设我们做了几个简化：
让我们假设在我们的分析系统中，我们可以预先定义一组不可变的用例\查询，这些用例\查询是小时系统需要能够提供的，并且它们在将来不会改变。
假设我们有有限的资源（工程能力、基础设施等）来实现它。存储进入我们系统的整个基本事件集，而不是预先计算视图\聚合，可能太贵了。
假设我们成功地将人为错误的影响最小化（…）。
该系统仍然需要具有可扩展性，并处理不断增加的流量和数据。鉴于这些观察，我想知道什么会阻止我们设计一个完全面向流的体系结构。我想象的是这样一种体系结构：事件（即页面视图）被推送到流中，流可以是rabbitmq+storm或amazon kinesis，并且这些流的使用者将通过随机写入/更新nosql数据库（即mongodb）来直接更新所需的视图。
在第一个近似值中，我认为这样的架构可以水平扩展。storm可以被集群化，而且也可以预先预留qos。更多的传入事件将意味着更多的流消费者，由于它们是完全独立的，没有什么能阻止我们添加更多的流消费者。关于数据库，使用适当的策略对其进行分片将使我们能够将不断增加的写入数分配给不断增加的分片数。为了避免读操作受到影响，每个碎片可以有一个或多个读副本。在可靠性方面，kinesis承诺可以可靠地存储您的消息长达24小时，而一个分布式rabbitmq（或您选择的任何队列系统）以及正确使用acknowledges机制可能可以满足相同的要求。
amazon关于kinesis的文档故意（我相信）避免将您锁定到特定的体系结构解决方案中，但我的总体印象是，他们希望推动开发人员简化lambda体系结构，并获得一个完全基于流的解决方案，类似于我公开的解决方案。为了更好地满足lambda体系结构的要求，没有什么能阻止我们在消费者不断更新我们的视图的同时，处理传入事件并将其作为原子不可变单元存储在不同的数据存储中的一组使用者，这些数据存储将来可用于生成新视图（例如通过hadoop）或重新计算错误数据。
你对这个推理有什么看法？我想知道在哪些情况下纯基于流的体系结构无法扩展，如果您有任何其他观察，lambda体系结构与基于流的体系结构的优缺点。