聊聊Lambda架构

定义

在数据分析场景中，咱们可能会遇到这样的问题。例如，咱们要作一个推荐系统，若是咱们用批处理任务去作，一天或者一小时的推荐频次明显延迟太大。若是用流处理任务，虽然延迟的问题解决了，然而只用实时数据而没有历史数据，那么准确性就没法保证。所以须要结合批处理的历史数据和流处理的实时数据进行处理，既能保证准确性，又能保证明时性。再好比反做弊系统，实时识别做弊用户的时候同时须要用到用户的历史行为。

针对上述问题，Storm 的做者 Nathan Marz 提出了 Lambda 架构。根据维基百科的定义，Lambda 架构的设计是为了在处理大规模数据时，同时发挥流处理和批处理的优点。经过批处理提供全面、准确的数据，经过流处理提供低延迟的数据，从而达到平衡延迟、吞吐量和容错性的目的。为了知足下游的即席查询，批处理和流处理的结果会进行合并。

从上面定义能够看出，Lambda 架构包含三层，Batch Layer、Speed Layer 和 Serving Layer。架构图以下：

下面分别介绍这三层架构的做用。

• Batch Layer：批处理层，对离线的历史数据进行预计算，为了下游可以快速查询想要的结果。因为批处理基于完整的历史数据集，所以准确性能够获得保证。批处理层能够用 Hadoop、Spark 和 Flink 等框架计算
• Speed Layer：加速处理层，处理实时的增量数据，这一层重点在于低延迟。加速层的数据不如批处理层那样完整和准确，可是能够填补批处理高延迟致使的数据空白。加速层能够用 Storm、Spark streaming 和 Flink 等框架计算
• Serving Layer：合并层，计算历史数据和实时数据都有了， 合并层的工做天然就是将二者数据合并，输出到数据库或者其余介质，供下游分析。

Amazon AWS 的 Lambda 架构

这里，我将用 AWS 做为例子来介绍 Lambda 架构，AWS Lambda 架构图以下

Batch Layer：使用 S3 bucket 从各类数据源收集数据，使用 AWS Glue 进行 ETL，输出到 Amazon S3。数据也能够输出到 Amazon Athena （交互式查询工具）

Speed Layer： 从上图看加速层有三个过程

• Kinesis Stream 从实时数据流中处理增量的数据，这部分数据数据输出到 Serving Layer 的 Amazon EMR，也能够输出到 Kinesis Firehose 对增量数据进行后续处理
• Kinesis Firehose 处理增量数据并写入 Amazone S3 中
• Kinesis Analytics 提供 SQL 的能力对增量的数据进行分析

其实只有上面第一个组件与咱们今天讨论的 Lambda 架构有关，其余两个组件只是针对实时处理的。

Serving Layer：合并层使用基于 Amazon EMR 的 Spark SQL 来合并 Batch Layer 和 Speed Layer 的数据。批处理数据能够从 Amazon S3 加载批处理数据，实时数据能够从 Kinesis Stream 直接加载，合并的数据能够写到 Amazone S3。下面是一段合并数据代码

以上即是 Amazon AWS 实现 Lambda 架构的简单介绍。

个人经历

接下来分享下我以前的项目经历。其实，咱们的项目跟上面的 Lambda 架构并非特别贴合，可是我以为思想是一致的。本质上都是批处理和流处理相关补充，同时发挥两者的优点。

咱们的业务是处理用户的定位数据，最开始主要使用 Spark Streaming 进行增量处理，处理后的数据实时写入 MongoDB。数据读写以用户 id 为粒度，因为粒度比较细，所以天天的数据量比较大。前端若是查询时间跨度较大的数据，每次都需按照用户粒度数据作聚合，致使查询响应比较慢且容易影响实时写入。所以，咱们用批处理任务对历史的离线数据进行预计算，再存储到 MongoDB。同时咱们开发了基于 gRPC 实现的一套 Service 来充当 Serving Layer，将历史的数据与实时的数据合并返回给前端，避免前端直接链接数据库。在这个项目中咱们的 Batch Layer 和 Speed Layer 都是用的 Spark 框架，所以维护相对容易。

以前介绍 Lambda 都是用加速层弥补批处理层的空白，可是上面的例子中是用批处理层弥补加速层的不足。所以，架构设计只是一个思想，具体的实施仍是要根据业务进行灵活变通，不能生搬硬套。

小结

本篇文章简单介绍了 Lambda 架构的内容，同时介绍了 Amazon AWS 实现 Lambda 架构的例子。最后举了一个我本身项目中的一个例子。通过整篇内容咱们了解了 Lambda 架构的优点，可是它有没有缺点呢。显然也是有的，我能想到的有如下几点：

• 批处理层、加速层和合并层用到的框架可能不同，所以会增长了开发的成本
• 批处理层和加速层处理的结果有可能不一致，若是用户看到的数据会变，这个体验不太好
• 若是某一层的逻辑变了，是否是其余两层或者一层的逻辑也要跟着变，所以层与层处理逻辑耦合度较大

你还能想到其余的问题吗， 以及有没有更好的架构能解决这个问题？欢迎交流

欢迎关注公众号「渡码」