第3章Lambda架构：一种数据湖实现模式
在前一章中介绍数据湖的一系列概念时，粗略地提到了Lambda架构。在本章中，我们将介绍Lambda架构的一些细节，并解释该架构模式在本书的数据湖实现方案中的重要意义。
本章虽然会尽量涵盖Lambda架构范式的全部细节，但是并不会给出任何技术实现。这是为了保证读者能够首先理解这些模式的概念。我们在后续的章节中将详细介绍该模式的技术支撑。
本章中，读者将详细学习Lambda架构模式。了解了该模式之后，读者将会看到它是如何成为构建数据湖的一个不可或缺的组成部分的。
3.1 什么是Lambda架构
Lambda架构不依赖于技术，不关心具体的技术实现，而是定义了一系列实用而完善的原则来处理大数据。Lambda架构是一种非常通用的模式，它试图满足大多数大数据应用程序的共性需求。这一模式允许我们同时处理历史数据和实时数据。过去，我们使用两种完全不同的应用程序来分别处理事务类——联机事务处理（OnLine Transaction Processing，OLTP）数据和分析类——联机分析处理（OnLine Analytical Processing，OLAP）数据，但这两类程序不能混合在一起；它们独立运行，且相互之间不通信。
下列要素说明了什么是Lambda架构：
- 一套模式和准则。Lambda架构定义了一套面向大数据应用的模式和准则。更重要的是，它允许同时查询历史数据和实时新增的数据，并且获得期望的分析视图。
- 处理历史数据（批处理）和实时数据。
- 技术无关和通用性。Lambda架构是一种通用的模式，完全不依赖于任何技术，而且任何技术只要能满足需求，都可以在Lambda架构中应用。
- Lambda架构清楚地把责任划分到不同的功能模块/层中。它按照层来划分职责，完美地遵循了设计模式中的关注点分离原则。
- 领域无关。作为一种通用的模式，Lambda架构可以应用于不同的业务领域。
3.2 Lambda 架构简史
Nathan Marz创造了Lambda Achitecture（LA）这个术语，用来描述一种通用的、可扩展的、容错的数据处理模式。他在BackType和Twitter上收集了大量关于大数据技术的专业知识。该模式是一种概念：通过使用两个重要组件来处理海量数据，这两个组件分别是批处理层和快速处理层。Nathan把他的发现和经验概括为Lambda架构，该架构需要满足一些重要的架构设计原则，例如：
- 线性可扩展原则：它应该支持水平扩展（scale out）而不是垂直扩展（scale up），并且应该适用于不同类型的用例。
- 容错原则：它能够承担弹性较大的工作负载，还应能保护系统，免于受硬件故障、软件故障以及人为错误的影响。
- Backtype：读取和更新。
- 可扩展原则：易于管理，易于扩展，易于添加新特性和数据元素。
在网址http://lambda-architecture.net/上有很多详细的文档。随着大数据的出现和企业对实时分析和数字化转型的关注，这一架构模式变得愈发重要。不过，为什么这一模式被命名为Lambda（符号λ）尚无明确的说法。
然而，我们一直认为这个希腊字母与这一模式相关联是因为数据来自两个地方。批量数据和快速的流式数据代表Lambda符号的弯曲部分，然后通过服务层（线段与曲线部分合并）合并，如图3-1所示。
图3-1 Lambda符号
3.3 Lambda架构的原则
Nathan Marz在《Big Data：Principles and best practices of scalable realtime data systems》一书中详细地介绍了Lambda架构模式。他提出来的架构模式主要基于以下3个原则，其中部分原则已经在上一节简要介绍过：
- 容错原则
- 硬件
- 软件
- 人为
- 不可变数据（immutable data）原则
- 重新计算（re-computation）原则
下面将详细说明每一个原则。
3.3.1 容错原则
Lambda架构模式中包括了容错能力，即处理硬件错误、软件错误或人工引起的错误的能力。大数据应用对容错有特殊的要求，而该模式迎合了大数据的要求，能保证系统不受数据丢失或数据损坏的影响。如果达不到这一要求，在大多数案例中，系统在遇到故障时是不可恢复的。因此该原则非常重要。
人工引起的错误是一种常见的错误。典型的就是日常操作中触发的操作性错误。另外一些常见的错误是引入生产系统的bug，在系统长期运行以后会引发各种问题。因此系统需要经过精心设计，解决这些问题。
3.3.2 不可变数据原则
从各个源系统导入的数据应该按它们的原始数据格式来存储。更加重要的是，这些数据本质上是不可改变的。由于数据不可改变，那么就不会增加因人工而导致的错误，也在某种程度上减少了数据的丢失与损坏。该原则允许选择和插入，但是不允许更新和删除。为了保障数据处理速度和性能，数据是以非规范化范式来存储的。数据不可变性使系统变得简洁，更易于管理。
3.3.3 重新计算原则
由于数据湖中的原始数据一直处于可访问的状态，系统始终可以通过对原始数据进行重新计算来满足新的需求。此外，因为将数据绑定到特定模式会给重新计算带来问题，所以数据更倾向于无模式（schema-less）的存储。并且，将数据绑定到特定模式还会带来开发和维护方面的开销。
在以Lambda架构模式实现数据湖时，我们将看到这些原则是如何实现的。
3.4 Lambda架构的组件
本书前面已经提及Lambda架构的各种组件，阅读这些章节之后，读者肯定对它们有所了解了。本节及后续小节将会详细介绍Lambda架构的各种组件。这里的介绍竭力避免涉及任何具体的技术，因为当讨论至具体的功能模块时，只要能满足模式的要求，就可以使用市面上任何合适的技术框架。理解每个功能模块及其担负的主要功能是非常有必要的，只有深刻理解这些，才能更有效地阅读后续章节。在数据湖背景中，Lambda架构的组件只构成了其中的一个功能模块，即Lambda层。下面将带领读者逐一了解Lambda层的各个模块。Lambda层的主要模块如下：
- 批处理层
- 快速处理层
- 服务层
Lambda架构的示意图如图3-2所示，其中显示了该模式中的重要功能模块。
图3-2 Lambda架构中的组件
正如读者从图3-2中清晰地看到的那样，新到达的数据被同时发送到批处理层和快速处理层。批处理层持续地对每个时间间隔内的批量数据重新计算并生成视图。快速处理层同时也创建相应的实时视图/快速视图（speed view）。而服务层则对外部查询的处理做了精心编排，查询会同时被分发到批处理层及快速处理层，然后对结果进行合并，最后将查询结果返回给请求端。
一旦批处理视图被创建，则该视图不再考虑之后到达的新数据，这些新数据被用于构建新的实时视图。旧的批处理视图会一直保存和存档，何时被抛弃则依赖应用案例和技术实现。
处理大数据的新方法是按照图3-3所示的数据流水线的方式，其中数据是从真实来源以最原始的格式获取的。然后，我们基于原始数据创建适当的视图来适配业务需求；同时根据需要来使用这些视图。Lambda架构的核心工作是通过批处理层和快速处理层产生适当的视图，然后服务层登场，充当用户查询与视图之间的桥梁。
图3-3 大数据流水线
3.4.1 批处理层
批处理层尽可能地按数据最原始的格式来存储数据。由于在存储的过程中不存在遗漏或转换，因此，可以在不同的阶段从不同的维度衍生出许多不同的用例。在批处理层中，主数据以不可变状态存储，可以被访问也可以被用于各种分析。因为数据是不可变的，更改和删除是被禁止的操作。数据总是被附加上一个时间戳，以便在需要某些数据时，可以用版本最新的时间戳查询以获取最新记录。删除操作也是禁止的，因为很多分析都依赖这些被删除记录的细节。
在原始数据上执行查询会消耗大量的处理时间。为了避免因查询细节处理导致的延迟，系统按照一种周期性方式来处理数据，视图经过调校尽量接近所需结果的生成和存储格式，这种视图称为批处理视图（batch view）。当批处理视图需要重新生成时（上一次批处理之后，又有新数据进入了），那么旧的批处理视图会被抛弃掉。前面提到过，容错能力是Lambda架构的核心原则之一。批处理视图的每次重新生成，尽管是非常耗时的，也要能应对各种可能错误，保持系统的鲁棒性。有多种不同的数据处理方法可以缩减处理时间，相比之下传统的批处理一般要消耗几个小时或者几天的时间。如图3-4所示即为Lambda架构的批处理层示意。
图3-4 Lambda架构——批处理层
批处理层的持久化存储需要适应大数据量，同时应该支持大规模的随机读取。然而，它不需要支持随机写入，因为数据是按给定的频率批量加载的。
对于单一客户视图用例，图3-5显示了如何通过从客户的主数据集生成所谓的批处理视图（中间视图）来实现批处理层。
图3-5 单 一客户视图——批处理层
对于单一客户视图的用例，客户数据流入批处理层，并在批处理层中维护主数据集；然后以设定的批处理时间间隔来创建批处理视图。在需要时，服务层会查询这些视图，与快速视图合并，并将结果发送给用户。
3.4.2 快速处理层
快速处理层也称为实时层，是为了满足实时分析的需要。批处理层以指定的时间间隔运行，而在一个批处理运行完成和另一个批处理开始之间，业务用户仍然希望对数据进行分析。快速处理层负责合并批处理视图和实时数据。现在，批处理窗口可以减小，但是由于批量处理大量数据，批处理层的处理通常较为耗时，但业务不能因等待批处理层的延迟而滞后。为了实现近实时数据分析，增量数据以低延迟的方式进入快速处理层。一旦批处理层某次执行完毕，并覆盖了快速处理层中的数据，那么实时视图就会被抛弃，然后系统进入下一轮处理。
用户提交查询时，会同时向批处理层和快速处理层进行查询，然后将结果合并，并以用户期望的方式将查询结果发送给用户。
为了实现容错性和能够从错误中恢复，批处理层和快速处理层在任何时刻都可以重新计算（从原始数据恢复批处理层），回滚（恢复到批处理层的前一个状态）或刷新（为快速处理层重新生成视图）。
快速处理层有几个非常重要的概念，为了实现该层的基本目标，必须了解它们：
- 增量计算（incremental computation）：使用现有的实时视图和新增数据来创建新的实时视图。如前文所述，这样做是为了减少时间开销，使得数据可以接近实时地分析。
- 最终一致性（eventual consistency）：某些实时计算任务非常复杂，而且很耗时。此时系统应该追求快速得到问题的近似解（接近正确答案）。之后在某个时间点（通常不会延迟很久），结果变得完全正确。
快速处理层的存储需要支持随机读取和写入，以满足增量更新的需要。快速处理层确实允许数据快速变化，但与批处理层处理的大量数据（时间跨度为数月或数年）相比，快速处理层处理的数据集非常小（比如每次处理一天的数据）。
按照上一节所述的通用方法，这里还创建了一个所谓的快速视图（中间视图）来满足要求，如图3-6所示。
图3-6 Lambda架构——快速处理层
就单一客户视图而言，快速处理层的实现方式如图3-7所示。
图3-7 单一客户视图——快速处理层
当新数据流入快速处理层，新增的数据在这里被处理并构建出合适的快速视图。当服务层有需求时，快速视图会与批处理视图合并，然后结果被返回给用户。
1. CAP 定理
前面我们确实探讨了一些非常重要的方面（比如最终一致性，下面将深入探讨） ，也简要介绍了其他方面。在更详细地解释最终一致性之前，需要解释一个非常重要的定理——CAP定理（见图3-8）。
图3-8 CAP定理
CAP（Consistency，Availability，Partition Tolerance，即一致性、可用性、分区容错性）定理，也因计算机科学家Eric Brewer而称为布鲁尔定理，指出在分布式系统中三者（一致性、可用性、分区容错性）不能同时满足。
——维基百科
在3个特性中，分布式系统在数据分块时只能满足C（一致性）或A（可用性）其中之一。分布式系统必然会出现网络故障，在这种情况下，只能接受网络分区。表3-1中会简要说明这3个重要方面。
**
在数据湖背景中，Lambda架构的实现也采用了CAP定理。通常在这样的环境中，可用性与一致性难以兼顾。基于这方面的原因，数据的一致性最终会得以实现，不过通常情况下，数据是近似一致的。这就是所谓的最终一致性。我们将在接下来的部分中详细介绍这方面的内容。
传统的满足ACID（Atomicity，Consistency，Isolation，Durability，即原子性、一致性、隔离性、持久性）要求的存储系统，比如RDBMS，选择了一致性和可用性。而NoSQL存储系统，由于它们的特征更适合数据湖，遵循了BASE（Basically Available，Soft State，Eventual Consistency，即基本可用、软状态、最终一致性）思想，并选择了可用性而不是一致性。
2.最终一致性
最终一致性是分布式计算中使用的一致性模型，用来实现高可用性，基本保证如果对给定数据项不做任何更新，则最终对该数据项的所有访问都将返回最后更新的值。
——维基百科
至此，读者可以清楚地了解该保证背后的意义，即一致性与可用性之间的较量。
分布式系统中的数据期望最终保持一致，并随时保持可用状态。对于数据湖来说，保证可用性比保证一致性更重要，但这完全取决于用例。我们不能向最终用户展示或使用不良数据，因为这会对公司品牌产生巨大冲击。所以，用例需要经过仔细的验证，读者需要将这一条作为数据湖实践的通用原则。
在数据湖（Lambda层）背景中，即使快速处理层受损（数据丢失或数据损坏），最终批处理层和服务层也将纠正这些错误，并通过服务层正常响应查询并返回结果。Lambda架构中的快速处理层只会将数据保留一段时间，这样批处理层和服务层可以重新开始处理数据并确保一致性，一旦完成，快速处理层的视图将被丢弃。
3.4.3 服务层
服务层的核心任务是响应查询，将批处理层和快速处理层创建的视图展示给用户或其他系统。
除此之外，这一层还有很多精细的工作需要进行。快速处理层需要一直关注批处理层，以观察是否完成了必要的批处理操作。这样一来，在批处理视图中进行批处理操作后，需要立即更新批处理层的存储。紧接着，当前的快速处理层视图将被丢弃，这是一种簿记行为，用以保持快速处理层存储大小在控制范围内。
观察图3-9，可以看到批处理层和服务层是如何工作的。
图3-9 Lambda架构——服务层
当查询到达服务层时，服务层分别向批处理层和快速处理层分发查询。查询执行时会查看记录的时间戳，并根据提供的参数获取结果。一旦从这两层获得查询结果，服务层合并这些记录并使用各种业务逻辑进行计算，然后以系统或用户需要的格式产生最终输出。基于数据质量的因素，批处理层更加可靠（每个批处理操作完成后会进行下一轮重新计算），如果发生冲突，批处理层的视图会覆盖快速处理层的视图。
3.5 Lambda架构的完整工作原理
图3-10中显示了Lambda 架构的完整工作原理。
正如前文中简要描述的那样，主数据集在批处理层中进行维护和管理。新数据到达时，会被同时分派到批处理层和快速处理层。一旦数据到达批处理层，按照常规批处理时间间隔，每次都从头开始重新计算并生成批处理视图。类似地，只要新数据到达快速处理层，快速处理层就会使用新数据生成快速视图。在查询到达服务层时，它会合并快速视图和批处理视图来生成适当的查询结果。
生成批处理视图后，快速视图将被丢弃，除非有新数据抵达，否则只需要查询批处理视图，因为此时批处理层中拥有所有的数据。
表3-2中列出了Lambda 架构中批处理层、快速处理层和服务层的作用及特点。
图3-10 Lambda 架构的完整工作机制
表3-2 批处理层、快速处理层、服务层的作用及特点
3.6 Lambda架构的优势
因为Lambda架构有很多优势，所以我们选择使用它来为企业构建数据湖。Lambda架构的典型优势如下：
- 数据以原始格式存储。因此，只需要创建新的批处理视图和快速视图，就可以随时将新的算法、分析方法或者业务用例应用于数据湖。传统数据仓库最大的优点之一是数据会被清洗和存储。正因为这一点，新的用例需要更改数据模式，这通常很耗费时间和精力。
- Lambda架构的重要原则中包括了重新计算，这有助于纠正错误，而不会有太大的额外开销。随着越来越多的数据进入数据湖，数据丢失和损坏的代价难以承受。因为可以重新计算，所以可以在任何时候重算、回滚或刷新数据来纠正这些错误。
- Lambda架构将不同的职能划分为定义明确、边界清晰的功能模块/层。这样各层就可以使用不同的技术，并且可以采用不同的方法来优化这些功能，同时对其他层没有任何影响。这些层中使用的技术，包括存储技术，都可以随时替换为更好的解决方案，而不会有太多的麻烦。
- Lambda架构是一个可插拔的架构。当需要添加一个新的源数据类型或者已经接入已有类型源系统时，该架构可以接入这些源系统而无须做太多改变。
3.7 Lambda架构的劣势
选择Lambda架构来构建企业级数据湖，如果在某些方面没有考虑充分，确实会引入一些该架构的先天劣势。下面列举部分劣势：
- 由于包含几个不同的层，Lambda架构通常被认为很复杂。必须经过充分的思考和操作以及付出一定的代价来保持各层之间的数据同步。
- 由于批处理层和快速处理层都是分布式的，且实现机制截然不同，维护和支持起来相当困难。
- 要构建基于Lambda架构的数据湖，必须掌握大量的技术。招聘掌握这些技术的人并非易事。
- 用开源的技术来实现Lambda架构并部署在云环境中并不容易。为了避免这种情况，使用云计算技术可以很好地实现Lambda架构，但是这样做，企业等于是把自己和某个云计算供应商绑定到一起，这被认为是一种先天的不足。
- 尽管这种架构模式已经存在了相当长的一段时间，所用到的这些工具仍处于快速发展和演化中，还不够成熟。不过，随着云计算的加速发展和创新，很快就会出现成熟的解决方案和工具。
- 目前，持续集成（CI）/持续交付（CD）已经是一种平常的要求。跟该领域的其他工具类似，持续集成/持续交付的工具也不成熟，所以很难支持太多自动化操作。
- 系统假设可能需要大量的硬件组件。从技术上讲，可以使用低端硬件组件，但是对于企业级用户来说，供应商通常会提供高端产品，这是企业和供应商之间长期以来约定成俗的供应模式。
- 相同的工作要实现两次（在批处理层和快速处理层），这也是Lambda架构模式一直被诟病的一点。
3.8 Lambda架构技术概览
如同前文简要介绍的那样，Lambda架构是有定义良好的原则的模式，而且是与技术无关的。具体到各个组件/层，我们可以引入任何技术来完成所需工作。
随着各种云计算供应商的出现，甚至可以在云环境中获得现成的组件（许多是依赖云环境的），更甚者，这些组件已经实现了Lambda架构。在本书中，我们将创建一个实际的数据湖，其中Lambda模式只包含一个层，叫作Lambda层。
由于有非常多的技术可供选择，后面每章中技术框架的选择会让人感觉比较主观。在每层中选择一种新技术时，我们都会给出选择的理由，同时也对其他框架保持开放。我们还将简略介绍类似技术框架，以便在需要时读者可以自行进行替换。话虽如此，但实际上我们使用选定的技术框架来实现数据湖。本书的第二部分将详细介绍每一项技术，然后在第三部分中，这些技术会被配套使用，用于构建数据湖。
3.9 应用Lambda
企业级数据湖是Lambda架构模式的应用案例之一。本书将更为详细地讨论这个话题。事实上，也有其他用例应用该模式，本节也会尝试尽量涵盖这些案例。
3.9.1 企业级日志分析
该模式的一个非常常见的用例是日志的获取及分析。ELK（Elasticsearch，Logstash，Kibana）技术栈在该领域比较领先，但是Lambda模式也可以很好地胜任该任务。日志可以是传统的应用程序日志，也可以是各种软件或硬件组件生成的各种日志。当需要企业级的日志管理和分析能力时，Lambda模式的确是一个不错的选择。这些日志的量很大，生成速度也很快。同时，这些日志都是不可变的，而且确实需要提供命令以便分析师（应用程序开发人员和安全数据科学家可以利用这些数据来发现安全威胁）使用这些日志。
使用Lambda层中重要的层（接下来的内容中将详细介绍批处理层和快速处理层）来校验这些实时日志，同时也可以帮助理解过去的日志，以提供实时的洞察力。研发团队可以根据分析结果采取主动的行为。例如，应用程序的开发人员可以发现程序错误，而安全分析人员可以评估安全方面的威胁。
除了用日志分析来检测某些异常情况之处，还可以使用这些数据来做分析和审计。例如，在网站运营的场景中，Google Analytics的数据会导入数据湖中，并用来发现一些趋势，这将有助于改善网站运营状况。
3.9.2 获取和分析传感器数据
随着物联网（Internet of Things，IoT）应用的日益增加，企业使用的传感器也越来越多。这些日渐增多的传感器产生了海量的数据，要从中提取出有用的信息却非常棘手。使用具有Lambda层的数据湖可以为用户提供一个可扩展的解决方案，以便对这些海量的传感器数据进行实时分析。
3.9.3 电子邮件平台实时统计
对企业来说，电子邮件平台现在起着非常重要的作用。因拥有大量来自业务应用和社交平台的数据，电子邮件营销（E-Mail marketing）平台的作用也举足轻重。很多电子邮件平台都可以跟踪每一封邮件的状态，比如打开、链接点击等。利用这些海量的跟踪数据，将其作为实时统计数据提炼出来，会有助于营销团队更好地选择目标客户并提供差异化的邮件内容。目前，主流电子邮件平台已经具备了对内容进行A/B测试的功能，这部分测试数据非常重要，营销团队可以根据它更好地准备营销邮件的内容。
3.9.4 实时赛事分析
很多比赛中可以利用历史的批处理视图和当前比赛的实时数据向观众呈现多维度的统计和分析。
批处理层可以持续进行批量数据处理，准备好各种批处理视图，将这些视图与当前的比赛结合起来，可以推测和展示当前比赛中运动员取得的成绩。以板球为例，在比赛进行时，球员可能取得不同的成绩。比如在测试中取得了1000分，这个成绩就可以在比赛时呈现给观众。
3.9.5 推荐引擎
各种商业推荐引擎同时使用了来自各种业务应用的历史数据及当前的实时数据，大多数时候是终端用户在网站上的行为数据。
3.9.6 安全威胁分析
日志可以从各种硬件和软件的组件中（包括业务应用）收集，把这些日志与过去的数据集进行对比可以用来分析安全方面的威胁。例如，根据分析的情况，可以采取不同的认证机制。比如说，可以把认证机制加强到双因子认证；如果在几分钟内反复收到来自某地的请求，就可阻塞这些请求并提交给人工审查，以决定是否授权执行当前事务。
3.9.7 多渠道用户行为分析
Lambda架构也可以用来进行多渠道用户行为分析。比如分析用户的购物行为、过去的消费情况、社交行为等，然后用这些数据来进行精准营销。同时，基于对各种A/B测试的结果进行分析，营销团队就能采取恰当的方式来投放广告邮件。
3.10 Lambda架构运行范例
Lambda架构已经在业界取得很多成功的应用，下面是其中一些案例：
- Twitter：例如采用改良版的Lambda架构对推文进行情感分析。
- Groupon：多类企业应用。
- Crashlytics：使用Lambda架构的批处理层和快速处理层进行有效的移动端数据分析，产生有意义的分析结论。
- Stack Overflow：一个知名的问答论坛，拥有庞大的用户社区和丰富的活动。Lambda架构被用来创建一个向登录用户推荐问题的板块。还有很多其他的数据分析，比如用批处理视图来分析投票数据。
- Flickr Magic View：修订版的Lambda架构通过结合批量计算和实时计算来创建一个神奇的视图（可参考code.flickr.com）。
3.11 Kappa架构
在本书中使用Lambda架构来构建数据湖的一个主要层（即Lambda层）。然而，读者也需要了解另一个简化版的Lambda架构，这个被热议的架构叫作Kappa架构。它和Lambda架构有着或多或少的相似之处，只是出于简化考虑，去掉了批处理层，只保留了快速处理层。其主要思想是避免从头开始进行批处理层计算，尝试把这些计算完全放在实时计算或快速处理层。如前文所述，Lambda架构的一个缺点是必须编码并运行同样的逻辑两次，但Kappa架构避免了这个问题。
一图胜千言，图3-11中将Kappa架构和Lambda架构放在一起进行比较，读者可以清楚地看到在Kappa架构中唯一缺失的部分是非常重要的批处理层。
图3-11 Kappa架构（左）与Lambda架构（右）比较
我们认为，即使非常复杂，Lambda架构仍然是构建数据湖的必经之路。同时也希望通过图3-11为读者提供另一个视角，让读者能够深入到实现方案中去，这就是为什么要简单地介绍Kappa架构。
Lambda架构中存在一个批量处理层是有原因的，为了解决这方面的问题，Kappa引入了新的技术框架，这些技术框架能够对大量数据进行相关处理。我们认为，在Kappa架构中，Lambda架构中的批量处理层和快速处理层被融合在了一起。实际上，我们也可以在Lambda架构中使用这些新技术，并仍然保持层次分离和责任清晰划分。
3.12 总结
在本章中，详细介绍了Lambda架构。在本书的数据湖实现方案中，Lambda层（Lambda架构的一种实现）是不可或缺的一部分。
本章只介绍了理论层面的Lambda架构，并未涉及具体技术。希望读者能明白，在该模式中，任何技术都能用来实现该架构各个层的功能。下一章开始介绍各种技术以及这些技术的适用场景。
本章前几节对Lambda架构进行了简要介绍，后几节详细介绍了构成Lambda架构的多个功能模块/层。同时，还阐述了该模式的优缺点，并全面而详尽地描述了这个模式。
希望读者现在已经对数据、数据湖和Lambda架构的背景知识有了充分的了解。读者在下一章将会了解如何为企业实现数据湖。
