本文共 4132 字，大约阅读时间需要 13 分钟。
本章将深入技术细节，介绍如何实现数据湖及 Lambda 架构。在前一章中介绍数据湖的一系列概念时，粗略地提到了 Lambda 架构。本章中，我们将介绍 Lambda 架构的一些细节，并解释该架构模式在本书的数据湖实现方案中的重要意义。本章虽然会尽量涵盖 Lambda 架构范式的全部细节，但却不会给出任何技术实现。这是为了保证读者能够首先理解这些模式的概念。我们在后续的章节中将详细介绍该模式的技术支撑。本章中，读者将详细学习 Lambda 架构模式。了解了该模式之后，读者将会看到它是如何成为构建数据湖的一个不可或缺的组成部分的。
Lambda 架构不依赖于技术，不关心具体的技术实现，而是定义了一系列实用而完善的原则来处理大数据。Lambda 架构是一种非常通用的模式，它试图满足大多数大数据应用程序的共性需求。这一模式允许我们同时处理历史数据和实时数据。过去，我们使用两种完全不同的应用程序来分别处理事务类——联机事务处理（OLTP）数据和分析类——联机分析处理（OLAP）数据，但这两类程序不能混合在一起；它们独立运行，且相互之间不通信。
以下要素说明了什么是 Lambda 架构：
一套模式和准则。Lambda 架构定义了一套面向大数据应用的模式和准则。更重要的是，它允许同时查询历史数据和实时新增的数据，并且获得期望的分析视图。
处理历史数据（批处理）和实时数据。
技术无关和通用性。Lambda 架构是一种通用的模式，完全不依赖于任何技术，而且任何技术只要能满足需求，都可以在 Lambda 架构中应用。
Lambda 架构清楚地把责任划分到不同的功能模块/层中。它按照层来划分职责，完美地遵循了设计模式中的关注点分离原则。
领域无关。作为一种通用的模式，Lambda 架构可以应用于不同的业务领域。
Nathan Marz 创造了 Lambda Achitecture（LA）这个术语，用来描述一种通用的、可扩展的、容错的数据处理模式。他在 BackType 和 Twitter 上积累了大量关于大数据技术的专业知识。该模式是一种概念：通过使用两个重要组件来处理海量数据，这两个组件分别是批处理层和快速处理层。Nathan 把他的发现和经验概括为 Lambda 架构，该架构需要满足一些重要的架构设计原则，例如：
线性可扩展原则：它应该支持水平扩展（scale out）而不是垂直扩展（scale up），并且应该适用于不同类型的用例。
容错原则：它能够承担弹性较大的工作负载，还应能保护系统，免于受硬件故障、软件故障以及人为错误的影响。
Backtype：读取和更新。
可扩展原则：易于管理，易于扩展，易于添加新特性和数据元素。
为什么这一模式被命名为 Lambda（符号 λ）尚无明确的说法。然而，我们一直认为这个希腊字母与这一模式相关联是因为数据来自两个地方。批量数据和快速的流式数据代表 Lambda 符号的弯曲部分，然后通过服务层（线段与曲线部分合并）合并，如图3-1所示。
Nathan Marz 在《Big Data：Principles and best practices of scalable realtime data systems》一书中详细地介绍了 Lambda 架构模式。他提出来的架构模式主要基于以下 3 个原则，其中部分原则已经在上一节简要介绍过：
硬件容错、软件容错、人为容错。
不可变数据（immutable data）原则。
重新计算（re-computation）原则。
Lambda 架构模式中包括了容错能力，即处理硬件错误、软件错误或人工引起的错误的能力。大数据应用对容错有特殊的要求，而该模式迎合了大数据的要求，能保证系统不受数据丢失或数据损坏的影响。
从各个源系统导入的数据应该按它们的原始数据格式来存储。更加重要的是，这些数据本质上是不可改变的。由于数据不可改变，那么就不会增加因人工而导致的错误，也在某种程度上减少了数据的丢失与损坏。
由于数据湖中的原始数据一直处于可访问的状态，系统始终可以通过对原始数据进行重新计算来满足新的需求。此外，因为将数据绑定到特定模式会给重新计算带来问题，所以数据更倾向于无模式（schema-less）的存储。
在以 Lambda 架构模式实现数据湖时，我们将看到这些原则是如何实现的。
本书前面已经提及 Lambda 架构的各种组件，阅读这些章节之后，读者肯定对它们有所了解了。本节及后续小节将会详细介绍 Lambda 架构的各种组件，也就是 Lambda 层。Lambda 层的主要模块如下：
批处理层。
快速处理层。
服务层。
Lambda 架构的示意图如图3-2所示，其中显示了该模式中的重要功能模块。
图3-10中显示了 Lambda 架构的完整工作原理。在主数据集中，新数据同时被发送到批处理层和快速处理层。一旦批处理层完成计算，并生成批处理视图后，旧的快速处理层视图会被丢弃，等待新数据的到来。如果需要查询数据，可以向批处理层和快速处理层同时发起请求，合并结果并返回用户。
生成批处理视图后，快速处理层视图会被丢弃。
由于 Lambda 架构有很多优势，所以我们选择使用它来为企业构建数据湖。Lambda 架构的典型优势如下：
数据以原始格式存储。因此，只需要创建新的批处理视图和快速视图，就可以随时将新的算法、分析方法或者业务用例应用于数据湖。
Lambda 架构的重要原则中包括了重新计算，这有助于纠正错误，而不会有太大的额外开销。
将职能划分为明确的层。
可插拔架构。
选择 Lambda 架构来构建企业级数据湖，如果在某些方面没有考虑充分，确实会引入一些该架构的先天劣势。下面列举部分劣势：
需要维护多个层，数据同步复杂。
批处理层和快速处理层的实现机制截然不同，维护和支持起来相当困难。
需要掌握大量的技术。
用开源技术实现在云环境中并不容易。
工具尚未成熟。
硬件组件需求大。
实施同一功能需要多次工作。
Lambda 架构是有定义良好的原则的模式，而且是与技术无关的。具体到各个组件/层，我们可以引入任何技术来完成所需工作。随着各种云计算供应商的出现，甚至可以在云环境中获得现成的组件（许多是依赖云环境的）。
企业级数据湖是 Lambda 架构模式的应用案例。本书将更为详细地讨论这个话题。事实上，也有其他用例应用该模式，本节也会尽量涵盖这些案例。
Lambda 架构已经在业界取得很多成功的应用，下面是其中一些案例：
在本书中使用 Lambda 架构来构建数据湖的一个主要层（即 Lambda 层）。然而，读者也需要了解另一个简化版的 Lambda 架构，这个被热议的架构叫作 Kappa 架构。它和 Lambda 架构有着或多或少的相似之处，只是出于简化考虑，去掉了批处理层，只保留了快速处理层。其主要思想是避免从头开始进行批处理层计算，尝试把这些计算完全放在实时计算或快速处理层。
(图3-11：Kappa 架构（左）与 Lambda 架构（右）比较)
转载地址：http://wavhz.baihongyu.com/