Lambda架构需求

Lambda架构的设计初衷是为了应对MapReduce（MR）架构的延迟问题。尽管MapReduce实现了分布式和可扩展的数据处理系统，但在处理数据时存在显著的延迟。实际上，如果内存和CPU足够强大，MapReduce也能实现接近实时的数据处理，然而在实际业务环境中并非总是如此。因此，我们需要在实时处理和批处理之间做出权衡，选择合适的处理量和资源。

2012年，Storm的作者Nathan Marz提出了Lambda数据处理框架。该框架旨在设计一种能够满足实时大数据系统关键特性（如高容错性、低延迟和可扩展性）的架构。Lambda架构结合了离线计算和实时计算，融合了一系列架构原则，包括不可变性、读写分离和复杂性隔离。这一架构可以集成Hadoop、Kafka、Storm、Spark、HBase等多种大数据组件。

Lambda架构的关键特性

横向扩展

可扩展性意味着系统能够应对不断增长的服务需求，而无需对底层架构或代码进行大幅修改。可以通过增加内存或磁盘资源（垂直扩展）或增加更多机器（水平扩展）来实现。无论是实时处理还是批处理，系统应该能够在不停止服务的情况下进行水平扩展。

缺陷容错

系统需要具备良好的容错机制，确保即使某些组件出现故障，整个系统仍能正常运行。单点故障可能导致集群中的部分节点宕机，从而影响整体的服务质量，因此系统必须避免单点故障。

低延迟

许多应用对于读写操作的延迟要求很高，需要对更新和查询操作保持低延迟。

可扩展性

系统应具有足够的灵活性，以便在不重写整个系统的情况下处理新增或修改的需求。实时处理和批处理应当独立，以方便灵活地调整需求。

易于维护

开发和部署过程不应过于复杂，以确保系统的可维护性。

Lambda架构的分层

在Lambda架构中，新数据到达时会被同时分配给批处理层和快速处理层。一旦数据到达批处理层，就会按照预定的时间间隔重新计算并生成批处理视图。同样，当新数据到达快速处理层时，快速处理层会使用这些数据生成快速视图。当查询到达服务层时，它会将快速视图和批处理视图合并，生成最终的查询结果。生成批处理视图后，快速视图将被丢弃，除非有新数据到达，否则只需查询批处理视图，因为此时批处理层中包含了所有数据。

Lambda架构定义了主要的层次及其组件之间的集成。具体分为以下几个层次：

• 数据源：包括外部数据库、消息队列和文件等，负责提供原始数据。开发数据消费层可以隐藏数据访问的复杂性，并定义统一的数据格式。
• 数据消费层：负责封装从不同数据源获取数据的复杂性，并将其转换成批处理或流处理所需的统一格式。
• 批处理层：作为Lambda架构的核心层之一，负责接收数据，持久化到用户定义的数据结构中，并维护主数据。通常会做一些ETL操作，如统计数据，并将结果保存在Hive表或数据库中。
• 实时层：另一个核心层，用于处理实时数据。在很多情况下，批处理已经能满足需求，但为了实现实时数据展示，引入了实时处理。实时层只存储最近的数据，以提高处理效率。
• 服务层：负责获取批处理和实时处理的结果，并向用户提供统一的查询视图服务。

Lambda架构总结

Lambda数据架构已经成为每个公司大数据平台的必备架构，解决了大数据批量离线处理和实时数据处理的需求。数据从底层的数据源开始，经过各种格式进入大数据平台，通过Kafka、Flume等组件进行收集，然后分成两条线进行处理。一条线进入流式计算平台（如Storm、Flink或Spark Streaming），用于计算实时目标；另一条线进入批量数据处理的离线计算平台（如MapReduce、Hive或Spark SQL），用于计算次日的相关业务目标。

Lambda架构经过多年的发展，已经非常稳定，但仍然存在一些问题：

• 实时与批量计算结果不一致：由于实时和批处理使用不同的计算框架和程序，导致结果不一致，同一数据可能在不同时间有不同的结果。
• 批处理的健壮性：随着数据量的增长，夜间计算窗口有限，难以在短时间内处理大量数据，导致数据发布时间延误，对集群的稳定性提出挑战。
• 开发和维护复杂：Lambda架构需要为相同的业务逻辑编写两套代码：一套用于批处理ETL系统，另一套用于流处理系统。这导致了重复工作和维护困难。
• 存储快速增长：数据仓库设计不合理会导致中间结果表激增，增加服务器存储压力。

尽管Lambda架构存在缺陷，但它在许多公司中仍然适用。对于数据量较小且实时需求不高的情况，Lambda架构依然能够很好地支持。而对于大数据量或实时需求较高的情况，可以考虑改进或采用其他架构，如Kappa架构。