如果 Kappa-Architecture 直接对流进行分析,而不是将数据分成两个流,那么在 Kafka 这样的消息系统中,数据存储在哪里?还是可以在数据库中进行重新计算?
单独的批处理层是否比使用流处理引擎重新计算进行批处理分析更快?
如果 Kappa-Architecture 直接对流进行分析,而不是将数据分成两个流,那么在 Kafka 这样的消息系统中,数据存储在哪里?还是可以在数据库中进行重新计算?
单独的批处理层是否比使用流处理引擎重新计算进行批处理分析更快?
“要考虑的一个非常简单的情况是,当应用于实时数据和历史数据的算法相同时。那么使用相同的代码库来处理历史数据和实时数据显然是非常有利的,因此使用 Kappa 架构实现用例”。“现在,用于处理历史数据和实时数据的算法并不总是相同的。在某些情况下,批处理算法可以优化,因为它可以访问完整的历史数据集,然后优于执行实时算法。在这里,在 Lambda 和 Kappa 之间进行选择变成了在支持批处理执行性能而不是代码库简单性之间的选择”。“最后,还有更复杂的用例,其中甚至实时和批处理算法的输出也不同。例如,在机器学习应用程序中,批量模型的生成需要大量时间和资源,以至于实时可实现的最佳结果是计算和近似更新该模型。在这种情况下,批处理层和实时层无法合并,必须使用 Lambda 架构”。
您可能还想在这里阅读讨论两者的原始文章
引用原始博客文章
“这两种方法之间的效率和资源权衡有点过分了。Lambda 架构需要一直运行重新处理和实时处理,而我提出的只需要在需要重新处理时运行作业的第二个副本. 但是,我的建议需要在输出数据库中临时拥有 2 倍的存储空间,并且需要一个支持大容量写入的数据库来重新加载。在这两种情况下,重新处理的额外负载很可能会平均下来。如果你有许多此类作业,它们不会一次全部重新处理,因此在具有数十个此类作业的共享集群上,您可能会为在任何给定时间主动重新处理的少数作业预算额外的百分之几的容量。
真正的优势根本不在于效率,而在于允许人们在单个处理框架之上开发、测试、调试和操作他们的系统。因此,在简单性很重要的情况下,可以考虑将此方法作为 Lambda 架构的替代方案。”