Lambda 架构的问题

  • Seth Cousins
  • 王振峰

2014 年 9 月 10 日

话题:大数据架构AI

Jay Kreps 在其博文中揭示了 Lambda 架构可用性和适用性的限制,他认为虽然 Lambda 思想充满了价值,但终究是一个临时解决方案,原因是其工具不成熟而非大数据的前景。他提供了一个替代架构,该架构基于他在 Linkedin 构建 Kafka 和 Samza 的经验,他还声称该架构在具有相同性能特性的同时还具有更好的开发和运维特性。

Lambda 架构是一种面向大规模流式处理的解决方案,它结合批处理与实时处理以实现可扩展性和容错。该模式通常通过基于 Apache Hadoop 的 MapReduce 和 Apache Storm 分别实现。Nathan Marz 基于他在 Twitter 的经验设计了该方案,并发表在一篇题为如何打破 CAP 定律的博文中,还有对应网站以及与此架构相关的即将出版的书籍

Kreps 承认了 Lambda 的两条重要原则:数据输入是不可变的和原始数据输入可以被再处理用以重新输出结果。保留原始输入允许我们处理数据,即使以前所未有的方式也无所谓,还能在因不明原因保存损坏数据的情况下提供恢复机制。当需要新的输出域时,或前一个版本的处理代码有 bug 导致输出不正确时,都需要再处理数据输入。

同时 Kreps 认为 Lambda 包含固有的开发和运维的复杂性。Lambda 需要将所有的算法实现两次,一次是为批处理系统,另一次是为实时系统,还要求查询得到的是两个系统结果的合并。考虑到将复杂算法正确地实现一次都是一个挑战,执行两次这样的任务以及调试不可避免的问题显然是难上加难。除此之外,运维两个分布式多节点的服务肯定比运维一个更难。

Kreps 概括其高层指南说道:

近来,我的建议是如果你对延迟不敏感,那就使用批处理框架如 MapReduce,如果敏感就使用流处理框架,但是不要尝试同时使用这两种系统,除非有绝对需要。

那么为什么大家对 Lambda 架构如此兴奋呢?我想原因是人们越来越需要构建复杂和低延迟的处理系统。他们所能使用的两个工具都不能完全解决问题:用于处理历史数据的可扩展的高延迟批处理系统,和无法再处理结果的低延迟流式处理系统。但将这两个工具连在一起,就可以构建可用的解决方案。

对于那些同时需要低延迟和处理巨大历史数据集的应用场景,Kreps 建议实时流式处理系统够用了。当需要再处理数据时,增加并行处理数量和快速重放历史就是解决方案。Linkedin 目前使用的就是该方案,使用 Kafka 和 Samza 实现。Kreps 说相同的方案使用 Storm 或其他流式处理系统也照样能工作。他确信,这两种架构的运行时效率大致一样,但是单系统显然更易开发和调试。

社区对 Kreps 博文的反馈是几乎普遍支持,有几个人同意 Krep 的观点与他们的经验相符。@jcsalterego说“非常棒的博文,谢谢。与我所见一样,虽然比 Linkedin 的规模小不少”,@jijoejv说“好文。我们在 @Nextag 使用”Kappa”架构已经一年半,使用 Storm+Kafka(90 天统计图)。修复 Bug 非常容易”。Nathan Marz 目前尚未作出回应。

查看英文原文:Questions About the Lambda Architecture


感谢曹知渊对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

大数据架构AI