【发布时间】：2017-06-17 11:06:52
【问题描述】：
如果 Kappa-Architecture 直接对流进行分析，而不是将数据分成两个流，那么在 Kafka 这样的消息系统中，数据存储在哪里？还是可以在数据库中重新计算？
单独的批处理层是否比使用流处理引擎重新计算进行批处理分析更快？
【问题讨论】：
标签： apache-kafka batch-processing stream-processing lambda-architecture bigdata
【发布时间】：2017-06-17 11:06:52
【问题描述】：
“要考虑的一个非常简单的情况是，当算法应用于 实时数据和历史数据是一致的。然后就是 使用相同的代码库进行处理显然非常有益 历史和实时数据，因此实现用例 使用 Kappa 架构”。“现在，用于处理的算法 历史数据和实时数据并不总是相同的。在一些 在这种情况下，批处理算法可以优化，因为它 可以访问完整的历史数据集，然后优于 实时算法的实现。在这里，选择 Lambda 和 Kappa 成为支持批处理执行之间的选择 性能优于代码库的简单性”。“最后，还有更多 复杂的用例，其中甚至是实时和 批处理算法不同。例如，机器学习 批处理模型的生成需要大量时间的应用程序 和资源，可实时实现的最佳结果是 该模型的计算和近似更新。在这种情况下， 批处理层和实时层不能合并，而 Lambda 必须使用架构”。
- 单独的批处理和流层
- 更高的代码复杂度
- 通过单独的批处理/流实现更快的性能
- 更适合批量和流中的不同算法
- 使用用于批量计算的数据存储而不是数据库更便宜
- 只有一个蒸汽处理层
- 更易于维护，复杂度更低，单个算法用于批处理和 流
- 如果从数据库重新计算以进行批处理，太多的数据会很昂贵
- 如果从数据库或从 kafka 进行批处理重新计算，处理过多的数据会变慢
【讨论】：
您可能还想阅读讨论这两个here的原始文章
引用原博文
“这两种方法之间的效率和资源权衡有点过分。Lambda 架构需要一直运行重新处理和实时处理，而我提出的只需要在以下情况下运行作业的第二个副本你需要重新处理。但是，我的建议需要在输出数据库中临时拥有 2 倍的存储空间，并且需要一个支持大容量写入的数据库来重新加载。在这两种情况下，重新处理的额外负载可能会平均下来。如果您有许多此类作业，它们不会一次全部重新处理，因此在具有数十个此类作业的共享集群上，您可能会为在任何给定时间将积极重新处理的少数作业预算额外百分之几的容量。
真正的优势根本不在于效率，而在于 允许人们开发、测试、调试和操作他们的系统 单一处理框架的顶部。所以，在简单的情况下 重要的是，将此方法视为 Lambda 的替代方法 建筑。”
【讨论】：