Lambda架构概述：工作原理、优点、缺点和适用场景。而我们的业务系统每天都需要接收各种大数据，完成各种处理任务。因此，在每天处理这些不断增长的数据时，数据系统将面临延迟和准确性的挑战。Lambda架构介绍针对上述挑战，NathanMarz和JamesWarren于2015年首次推出Lambda架构，将数据系统在逻辑上分为三个层次，即：批处理层、速度层和服务层。作为大数据的一个例子，它允许用户构建数据系统来克服上述数据延迟和准确性的问题。因为Lambda架构可以水平扩展，如果你的数据集太大，或者你需要的数据视图太多，你可以添加更多的主机参与处理。然而，Lambda将系统中最复杂的部分限制在速度层。由于图层的输出是临时的，如果您需要对数据进行改进或更正，可以每隔几个小时清除一次。Lambda架构的工作原理Lambda架构的第一层——批处理层，不仅可以存储整个数据集，还可以计算批处理视图。由于这里存储的数据集不能更改，只能追加。也就是说，新的数据会不断的引入，而旧的数据会一直保持不变。同时，批处理层会通过对整个数据集的查询或函数计算得到各种视图。在查询这些视图时，虽然我们可以在整个数据集中找到低延迟的答案，但缺点是系统需要花费大量时间来计算。Lambda架构的第二层——服务层，可以批量加载视图。与传统数据库类似，它通过对视图的只读查询操作提供低延迟响应。一旦批处理层准备了一组新的视图，服务层就会替换当前过时的批处理视图。流向批处理层的数据也会流入Lambda架构的第三层，即速度层。主要区别在于批处理层从一开始就保留所有数据，而速度层只关心自上一批视图完成以来到达的数据。也就是说，速度层通过处理对批处理视图尚未考虑的最近数据的查询来补偿计算视图中的高延迟。具体原理如下图所示：举例说明三个层次为了更好地理解上述概念，我们打个比方：在一座老人的宅邸里，每个房间都有一个时钟。但是，除了厨房里的钟，其他的钟都不准。他需要根据厨房里的时钟校准其他时钟。但是，由于记性不好，他不得不在一张纸上记下厨房时钟上的当前时间（上午9点04分）。然后，慢慢地穿过房间，他把所有的时钟都调到早上9点04分。而当他终于抵达东厢房时，实际时间已经是上午九点五十一分。显然，他在每个房间的时钟上设置的上午9:04是错误的。同理，如果数据系统只有一个批处理层，那么我们就会遇到类似的问题——因为一个问题的答案需要一段时间才能得到，随着数据的不断涌入，答案不是最新的.让我们回到前面的例子。幸运的是，老人手里拿着秒表。第二天早上9点04分，他也从厨房开始，在一张纸上记下时间并启动秒表（他的“速度层”）。当他终于到达东翼时，他的秒表显示为“47分16秒”。通过基础数学，他可以判断出当前时钟应设置为上午9:51。在上面的类比中，老人就是服务层，他府邸各个房间的时钟，处处可以显示当前时间的批量视图。当然，他会触发秒表，以便批处理视图与速度层同步以获得最准确的答案。为什么使用Lambda架构？在Marz和Warren关于Lambda架构的开创性著作——《大数据》中，他们列出了大数据系统中的八个理想属性，并描述了Lambda架构如何满足每个属性：健壮性和容错性。由于批处理层被设计为追加方式，即包含自启动以来的整个数据集，因此该系统具有一定的容错性。如果任何数据损坏，该体系结构可以从损坏点删除所有数据，并用正确的数据替换它。此外，批处理视图可以换成完全重新计算的视图。并且可以丢弃速度层。此外，在生成一组新的批处理视图的同时，该体系结构可以重置整个系统以再次运行。可扩展性。Lambda架构的设计层构建为分布式系统。因此，最终用户可以通过简单地添加更多主机来轻松地水平扩展系统。多功能性。由于Lambda架构是一种通用范例，因此用户不会被锁定在计算批处理视图的特定方式中。此外，可以设计批处理视图和速度层的计算以满足数据系统的特定需求。延展性。随着新数据类型的导入，数据系统也会生成新视图。数据系统没有锁定到某个类别或批处理视图的数量。系统会在编码后加入新的视图，其对应的资源也很容易扩展。按需查询。如有必要，批处理层可以在没有批处理视图的情况下支持临时查询。如果用户可以接受即席查询的高延迟，那么批处理层的用处将超出生成的批处理视图。最少的维护。Lambda架构的典型模式是：批处理层使用ApacheHadoop，服务层使用ElephantDB。显然，两者都易于维护。可调试性。Lambda架构通过每一层的输入和输出，大大简化了计算和查询的调试。低延迟读取和更新。在Lambda架构中，速度层为大数据系统提供对最新数据集的实时查询。Lambda架构的缺点任何事物都有两个方面。除了以上优点，Lambda架构还存在以下缺点：由于所有数据都是附加的，批处理层中的任何数据都不会被丢弃，因此系统的Scaling成本势必会随着时间的推移而增长。如前所述，批处理层可以使用Hadoop或Snowflake，而速度层可以使用Storm或Spark。显然，这两个层运行在同一组数据上，但它们建立在完全不同的系统上。因此，用户需要维护两套独立的系统代码。这不仅复杂，而且极具挑战性。机器学习中的Lambda架构在机器学习领域，数据越多越好。但是对于应用算法和检测模式的机器学习，它们需要以有意义的方式接收数据。因此，机器学习可以受益于Lambda架构构建的数据系统，处理各种类型的数据。由此，机器学习算法可以提出各种问题并逐渐识别输入系统的数据中的模式。物联网的Lambda架构如果说机器学习使用的是Lambda架构的输出，那么物联网更多的是使用来自数据系统的输入。想象一个拥有数百万辆汽车的城市，每辆汽车都配备了传感器，能够发送有关天气、空气质量、交通状况、位置信息和驾驶员驾驶习惯的数据。这些海量的数据流会被实时馈送到Lambda架构的批处理层和速度层进行后续处理。可以说，物联网设备是明智地使用大数据源的很好的例子。流处理和Lambda架构挑战速度层也称为“流处理层”。其目标是提供最新数据的低延迟实时视图。虽然，速度层只关心自上次批处理视图完成后导入的数据，但实际上并不存储这些小块数据。这些数据一进来就被处理，一完成就被丢弃。因此，我们可以认为这个数据是尚未被batchview统计过的数据。在其最初的理论中，Lambda架构提到了“最终准确性”的概念。也就是说：批处理层更关注精确计算，而速度层更关注近似计算。随着系统向“最终精度”迈进，这种近似计算最终将被下一组视图所取代。在实际应用中，用于更新视图的数据流是由毫秒级的实时处理流不断产生的，这是一个非常复杂的过程。在这里，我建议大家结合使用基于文档的数据库、索引和查询系统。Lambda架构和Kappa架构的区别上文提到，由于Lambda架构的batch层和speed层属于不同的分布式系统，类似的处理方式我们需要维护两个独立的代码库。Kappa架构通过完全移除批处理层解决了这个问题。具体来说，Kappa使用单个流处理层来计算最新数据以生成实时视图，并计算所有数据以生成批处理视图。就整个数据集而言，以附加日志的形式保持原始数据不变，保证数据能够快速流经系统，产生计算准确的视图。同时，原先来自Lambda架构的“速度层”任务也将保留在Kappa架构中，继续为低延迟视图提供近似计算。因此，这种为单个系统生成视图的方式极大地简化了系统的代码库。在Heroku上通过容器实现Lambda架构通过使用Docker，我们可以轻松完成Lambda架构在启动和试用阶段所需的各种工具的协调和部署。例如，我们可以使用基于容器的云平台即服务(PaaS)Heroku来部署和扩展应用程序。对于批处理层，可以使用ApacheHadoop部署一个Docker容器；对于速度层，可以考虑部署ApacheStorm或者ApacheSpark；而对于服务层，你可以为ApacheCassandra或MongoDB部署一个Docker容器，并使用Elasticsearch来进行索引和查询。结论总而言之，像Lambda架构这样的范例在一定程度上具有可扩展性和健壮性。由于大量数据流不断被输入数据系统，批处理层提供高延迟精度，而速度层提供低延迟近似值。同时，速度层通过协调两个视图来提供对查询的最佳响应。当然，使用Lambda架构实现一个数据系统并不容易，我们往往需要借助合适的工具来实现部署和构建。原标题：Lambda架构概述，作者：MichaelBogan
