22、Lambda架构：实时Hadoop应用的高效解决方案

Lambda架构：实时Hadoop应用的高效解决方案

1. Lambda架构简介

Lambda架构简化了众多任务。添加新特性变得轻而易举，因为这可能只需添加处理（查询），最多也就是增加新视图（对批处理层进行增强）。从人为错误中恢复也很容易，你可以根据需要从批处理层或速度层重建视图。性能优化同样轻松实现，可通过调整批处理层或对视图进行索引来达成。此外，该架构具有通用性，适用于任何数据处理环境。

Lambda架构的目标如下：
- 处理过程应保持（基础）数据不变，并构建一个访问层（针对用户查询进行优化），以便从人为错误中轻松恢复。
- 处理应提前异步进行，且采用批处理模式。
- 增量计算应减至最少（如有可能则消除）。

2. Lambda架构层的定义与使用

Lambda架构的各层属于逻辑层面或概念层面。在实现时，所使用的NoSQL数据库是物理的，单独使用时存在自身缺点。因此，在实现过程中，了解它们的优缺点至关重要。例如，像Cassandra这样的列式数据库，虽能提供高吞吐量，但数据模型相对有限（与关系型数据库管理系统RDBMS相比）。所以，将关系型模式适配到这种数据库需要做一些工作。

下面将详细探讨Lambda架构的各层，以及如何利用它构建出色的实时系统。首先从批处理层开始。

2.1 批处理层

在处理海量数据集时，延迟是常见问题。像MapReduce或YARN这样的分布式处理机制虽试图降低延迟，但考虑到这些海量数据集用于分析以及涉及的复杂处理，处理总时间往往难以接受。因此，要么将处理拆分为更小的单元（并非总能实现），要么限制用户查询的范围。

Lambda架构通过基于预期查询对数据（即主数据）进行预计算来解决这一问题。该技术包括构建视图（并对其进行索引），这些视图可能支持大多数用户查询或对数据的读取访问。由于这些视图是从大型数据集中计算得出的，构建过程需要时间，因此该操作以异步或批处理模式进行。这些预计算视图构成了Lambda架构的批处理层，即第一层。

2.2 主数据集的设计

考虑所有可能的情况，你可能需要将现有的基于RDBMS的应用重新架构（或迁移）到NoSQL（如果需要近实时查询），或者设计一个全新的基于NoSQL的系统并需要近实时查询。遵循的步骤类似，都从逻辑模型开始。

为NoSQL实现构建逻辑数据模型看似奇怪，但有几个令人信服的理由。一是缺乏用于NoSQL建模的工具和技术，二是分析业务流程并建立捕获其生成数据的模型的过程基本不变，只是模型的最终表示和存储方式有所不同。Nathan Marz提出了一种“基于事实”的模型来保存主数据集。

2.3 基于事实的模型

首先，将数据定义为无法从其他信息推导得出的信息。对于基于事实的模型，数据被分解为称为“事实”的基本单元。事实数据是不可变的，即不可更新。因此，对数据的任何更新都会添加一个新的数据行（或单元），并使用时间戳进行区分，以确保信息（或传统意义上的历史记录）不会丢失。数据不可变性有两个重要优点：
- 人为错误容错性 ：在可变数据模型中，任何错误或不期望的数据修改可能会永久覆盖良好的数据且无法恢复。而在不可变模型中，不良数据可直接删除，不会产生任何不利影响。
- 简单性 ：可变数据模型需要对数据进行索引，以实现快速检索和更新。而在不可变数据模型中，由于只需将新数据追加到主数据集，因此无需索引，这简化了主数据的存储。

下面通过一个例子来说明“事实”是如何从数据中生成并变得不可变的。DataScourerNinjas.com有一个有趣的商业模式，它采购并跟踪数千家公司的信息，并将其出售给软件开发公司。这些信息对软件制造商针对特定公司开发软件很有帮助。以下是DataScourerNinjas收集的数据示例：
| Corporation | Business category | Business details | IT strength | Customer support strength | Yearly revenue | Profit last year | Payroll software or vendor | Helpdesk software or vendor |
| — | — | — | — | — | — | — | — | — |
| Toyota motors | Automobile | Sedans, SUVs, Minivans | 5000 | 2000 | $70 Billion | $3 Billion | ADP | Zendesk |
| Accenture | Consulting | Management and Technical consulting | 3000 | 500 | $32 Billion | $3 Billion | Custom | Salesforce |
| General Electric | Energy | Electrical distribution, Electric motors | 10,000 | 2000 | $148 Billion | $15 Billion | ADP | SAP – CRM |

假设发现其中一个条目（所有公司的“去年利润”）以及另一家公司的所有条目存在数据问题，数据不可靠，需要部分或全部重新收集。或者，需要记录某家公司过去六个月的值（因为从那时起它“符合”DataScourerNinjas跟踪信息的条件）。在这些情况下，该数据存在以下问题：
- 无法知道数据是在不同时间分部分收集的。
- 无法知道过去或历史值是什么（因为部分数据被覆盖）。

这是一个可变模式的例子。当数据发生变化时，会覆盖现有数据。而且，由于部分数据可能比其他数据更具动态性（经常变化），理想情况下应能分别维护数据各部分的历史记录，但可变模式无法实现这一点。Lambda架构提供了一个解决方案：基于事实的模式。

将上述可变模式表示为不可变的基于事实的模式的思路很简单。首先，分离可以独立变化的“事实”，然后分别跟踪它们。例如，对于一家公司，客户支持强度可能会因某个引发大量客户反应的问题而暂时增加，但这可能不会影响他们使用的 payroll 软件或 IT 强度。因此，分离这些事实并维护单独的历史记录很重要。

实现不可变性的方法是，每次值发生变化时，添加一个新行，并附带时间戳（对应值变化发生的日期/时间）。值可能在不同时间变化，但可以知道每个变化的发生时间。

以下是转换后的不可变基于事实的模式示例：
| Corporation | CorpBusDetails | CorpHelpDeskDetails | CorpFinDetails | CorpPayrollDetails | CorpITDetails | CorpCustSupDetails | Business category | Business details | Timestamp |
| — | — | — | — | — | — | — | — | — | — |
| Toyota motors | | | | | | | Automobile | Sedans, SUVs, Minivans | 8/1/2015 09:30:13 |
| Accenture | | | | | | | Consulting | Management and Technical consulting | 9/2/2015 10:00:23 |
| General Electric | | | | | | | Energy | Electrical distribution, Electric motors | 9/13/2015 10:05:11 |
| Toyota motors | | Zendesk | | ADP | 5000 | 2000 | | | 8/1/2015 09:30:13 |
| Accenture | | Salesforce | | Custom | 3000 | 500 | | | 9/2/2015 10:00:23 |
| General Electric | | SAP – CRM | | ADP | 10,000 | 2000 | | | 9/13/2015 10:05:11 |
| Toyota motors | | | $4 Billion, $70 Billion | | | | | | 1/1/2015 0:00:01 |
| Accenture | | | $3 Billion, $32 Billion | | | | | | 1/1/2015 00:00:01 |
| General Electric | | | $15 Billion, $148 Billion | | | | | | 1/1/2015 00:00:01 |

在这个模式中，“Corporation”列包含在所有数据集中，用于唯一标识数据（跨事实），但它不是唯一标识符，因为新增记录仅时间戳不同，所以唯一标识符是“Corporation”和“Timestamp”。

与关系型数据库不同，在关系型数据库中需要考虑底层关系、数据互连性和更新性能，而在基于事实的模型中，可以不断添加数百万个带时间戳的事实，进行有效的批处理，无需担心更新问题。而且，由于不涉及增量处理，也无需担心性能问题。

2.4 将基于事实的模型应用于关系型应用

虽然Lambda将“事实”定义为数据的基本单元，但在具有结构化数据的现实世界系统中，事实可以是由特定列组构成的原子数据单元，并可使用唯一标识符（主键）进行识别，因为非键列仅依赖键列进行识别。因此，从关系角度看，事实可以是第三范式的表。

以一个简单的销售管理系统为例。零售商销售多种产品，并将销售记录在一个表中，如下所示：
| SalesID | SalesDate | TotalSales | Product | Ptype | PLocation | PPrice | Customer Name | Customer Address | Customer Type |
| — | — | — | — | — | — | — | — | — | — |
| 102525525 | 8/1/2015 09:30:13 | $3,450 | Men’s Striped Cotton shirt (large) | Men’s cotton garment | 1234 Lemont road Darien IL 60561 | $23 | JCPenney | 1 Oak St. Darien IL 60561 | Corporate |
| 126262666 | 9/2/2015 10:00:23 | $7,740 | Men’s Denim shorts (Medium) | Men’s denim garment | 1649 Halstead St. Chicago, IL 60604 | $18 | Kohls | 21 Maple St. Naperville IL 60563 | Corporate |
| 137737373 | 9/13/2015 10:05:11 | $9,966 | Women’s solid cotton skirt (black) | Women’s cotton garment | 1234 Lemont road Darien IL 60561 | $33 | Kohls | 21 Maple St. Naperville IL 60563 | Corporate |

该销售数据是非规范化的，“事实”（产品、客户和位置元数据）是可变的。例如，当客户JCPenney决定搬到另一个位置，或者零售商决定将“Men’s Striped Cotton shirt”存放在不同仓库时，首先，更新所有行的相应元数据会很困难且缓慢；其次，更新后信息或历史记录会丢失，因为无法指定修改的日期/时间。

要将这个模式转换为不可变的基于事实的模式，可以按照以下步骤进行：
1. 提取原子逻辑分组。
2. 为每个分组添加时间戳。

转换后的不可变数据如下所示：
| Sales | | | Location | | | Product | | | Customer | | |
| — | — | — | — | — | — | — | — | — | — | — | — |
| SalesID | SalesDate | Total Sales | Location ID | Street Address | City | Product ID | PName | PCategory | Customer ID | CName | CType |
| 102525525 | 8/1/2015 09:30:13 | $3,450 | 1 | 1234 Lemont road | Darien | 1 | Men’s Striped Cotton shirt (large) | Men’s cotton garment | 1 | JCPenney | Corporate |
| 126262666 | 9/2/2015 10:00:23 | $7,740 | 2 | 1649 Halstead St. | Chicago | 2 | Men’s Denim shorts (Medium) | Men’s denim garment | 2 | Kohls | Corporate |
| 137737373 | 9/13/2015 10:05:11 | $9,966 | 2 | 1649 Halstead St. | Chicago | 3 | Women’s solid cotton skirt (black) | Women’s cotton garment | 2 | Kohls | Corporate |

在这个新的模式中，销售表不再包含元数据，元数据被移到单独的表中，并添加了时间戳列，以确保信息不会丢失。每个数据行提供了包含信息在关联时间戳日期/时间的真实版本。

事实具有原子性，因为它们不能再进一步划分为有意义的组件。例如，“JC Penney是客户”这一事实不能再细分，因为该事实的部分在销售管理系统上下文中（甚至在其他情况下）都没有意义。原子性的一个重要结果是不同事实之间信息的非冗余性。时间戳提供了时间上下文，因为事实在特定时间变得真实（或开始存在），之后永远保持真实。这两个属性使基于事实的模型对于数据集来说既简单又具有表现力。

需要注意的是，这个销售管理系统示例使用的是复杂事实，而非Lambda架构建议的列式事实。列式事实（为列添加时间戳以维护列的更改历史记录）可能适用于数据组件较少的系统，但对于复杂的关系型应用则难以实现。

基于事实的模式具有以下优点：
- 特定时间查询 ：可以查询数据集支持的任何特定时间的历史值。例如，如果你想知道Kohl’s在2015年9月1日至10月30日期间的总销售额，或者2015年9月15日可用的产品，都可以轻松实现。
- 人为错误容错性 ：通过简单地删除错误事实，有效事实不受影响。

下面是一个mermaid格式的流程图，展示了将可变模式转换为不可变基于事实的模式的过程：

graph LR
    A[可变关系型模式] --> B[提取原子逻辑分组]
    B --> C[为每个分组添加时间戳]
    C --> D[不可变基于事实的模式]

综上所述，Lambda架构的批处理层和基于事实的模型为实时Hadoop应用提供了一种高效、可靠且易于维护的解决方案，尤其适用于需要处理海量数据和复杂查询的场景。在后续内容中，我们将继续探讨Lambda架构的其他层以及如何进一步优化和应用该架构。

3. Lambda架构其他层及综合应用

3.1 速度层与服务层简介

除了批处理层，Lambda架构还包含速度层和服务层。速度层用于处理实时数据，它能够快速响应最新的数据变化，弥补批处理层在处理实时数据时的延迟问题。服务层则负责将批处理层和速度层的结果进行整合，为用户提供统一的查询接口。

3.2 速度层的作用与实现

当新的数据到来时，批处理层由于处理时间较长，无法及时反映这些最新数据的情况。速度层则可以对这些实时数据进行快速处理，生成临时视图。这些临时视图可以在批处理层的视图更新之前，为用户提供最新的数据信息。

速度层通常采用流式处理框架，如Apache Storm、Apache Flink等。这些框架能够实时处理数据流，快速计算出结果。例如，在一个电商系统中，当有新的订单产生时，速度层可以立即统计出当前的订单数量、销售额等信息，供运营人员实时监控。

3.3 服务层的整合功能

服务层的主要任务是将批处理层和速度层的结果进行合并。当用户发起查询时，服务层会同时从批处理层和速度层获取数据，并将它们整合在一起返回给用户。这样，用户既能得到历史数据的准确信息，又能获取到最新的实时数据。

服务层可以使用缓存技术来提高查询性能。例如，将常用的查询结果缓存起来，当再次收到相同的查询时，直接从缓存中返回结果，避免重复计算。

3.4 Lambda架构的综合优势

Lambda架构结合了批处理层、速度层和服务层的优势，为实时数据处理提供了全面的解决方案。它具有以下综合优势：
- 高效性 ：批处理层进行大规模数据的预计算，速度层处理实时数据，两者结合能够在保证数据准确性的同时，快速响应查询请求。
- 容错性 ：由于数据的不可变性和分层处理，即使某一层出现问题，也可以通过其他层的数据进行恢复，保证系统的稳定性。
- 可扩展性 ：可以根据业务需求，灵活调整各层的资源配置，适应不同规模的数据处理需求。

3.5 Lambda架构在不同场景的应用

3.5.1 金融领域

在金融领域，Lambda架构可以用于实时风险评估。批处理层可以对历史交易数据进行分析，建立风险模型；速度层则实时处理新的交易数据，根据风险模型进行实时评估。服务层将两者的结果整合，为金融机构提供实时的风险预警。

3.5.2 物联网领域

在物联网领域，大量的传感器会产生实时数据。Lambda架构的批处理层可以对历史传感器数据进行挖掘，发现设备的运行规律；速度层实时处理当前的传感器数据，监测设备的状态。服务层将这些信息整合，为设备维护和管理提供决策支持。

3.5.3 社交媒体领域

在社交媒体领域，Lambda架构可以用于实时分析用户行为。批处理层分析用户的历史行为数据，了解用户的兴趣偏好；速度层实时处理用户的最新动态，如点赞、评论等。服务层将这些信息整合，为用户提供个性化的推荐服务。

3.6 Lambda架构的实施步骤

以下是实施Lambda架构的一般步骤：
1. 需求分析 ：明确业务需求，确定需要处理的数据类型、查询类型以及对实时性的要求。
2. 架构设计 ：根据需求分析的结果，设计Lambda架构的各层结构，选择合适的技术框架和工具。
3. 数据准备 ：将原始数据进行清洗、转换，构建主数据集，并采用基于事实的模型进行存储。
4. 批处理层开发 ：使用MapReduce、Spark等工具，对主数据进行预计算，构建批处理视图。
5. 速度层开发 ：选择合适的流式处理框架，开发速度层的实时处理逻辑。
6. 服务层开发 ：开发服务层的接口，实现批处理层和速度层结果的整合。
7. 测试与优化 ：对系统进行测试，发现并解决性能、稳定性等方面的问题，进行优化调整。
8. 上线部署 ：将系统部署到生产环境，进行实时数据处理和查询服务。

3.7 Lambda架构与其他架构的比较

以下是Lambda架构与传统架构以及其他实时处理架构的比较表格：
| 架构类型 | 实时性 | 数据处理能力 | 维护难度 | 成本 |
| — | — | — | — | — |
| 传统架构 | 低 | 有限 | 高 | 高 |
| Lambda架构 | 高 | 强 | 适中 | 适中 |
| 其他实时架构 | 高 | 一般 | 高 | 高 |

从表格中可以看出，Lambda架构在实时性、数据处理能力、维护难度和成本之间取得了较好的平衡。

3.8 Lambda架构的未来发展趋势

随着数据量的不断增长和实时性要求的提高，Lambda架构也在不断发展和演进。未来，Lambda架构可能会与人工智能、机器学习等技术深度融合，实现更智能的数据分析和决策支持。同时，架构的自动化和智能化程度也会不断提高，降低运维成本和难度。

下面是一个mermaid格式的流程图，展示了Lambda架构的整体工作流程：

graph LR
    A[原始数据] --> B[批处理层]
    A --> C[速度层]
    B --> D[服务层]
    C --> D
    E[用户查询] --> D
    D --> F[返回结果]

综上所述，Lambda架构为实时Hadoop应用提供了一种强大而灵活的解决方案。通过合理设计和应用各层架构，结合基于事实的模型，可以有效地处理海量数据，满足不同业务场景的实时查询需求。在未来的大数据时代，Lambda架构将发挥越来越重要的作用。