大数据Lambda架构

「爱情、让人受尽委屈。」 2022-10-01 00:37 217阅读 0赞

## 1 Lambda架构介绍 ##

Lambda[架构][Link 1]划分为三层，分别是批处理层，服务层，和加速层。最终实现的效果，可以使用下面的表达式来说明。

**query = function(alldata)**

**![SouthEast][]**

### 1.1 批处理层(Batch Layer, Apache Hadoop) ###

批处理层主用由[Hadoop][]来实现，负责数据的存储和产生任意的视图数据。计算视图数据是一个连续的操作，因此，当新数据到达时，使用MapReduce迭代地将数据聚集到视图中。 将数据集中计算得到的视图，这使得它不会被频繁地更新。根据你的数据集的大小和集群的规模，任何迭代转换计算的时间大约需要几小时。

### 1.2 服务层(Serving layer ,Cloudera Impala) ###

服务层是由[Cloudera Impala][]框架来实现的，整体而言，使用了Impala的主要特性。从批处理输出的是一系列包含预计算视图的原始文件，服务层负责建立索引和呈现视图，以便于它们能够被很好被查询到。

由于批处理视图是静态的，服务层仅仅需要提供批量地更新和随机读，而Cloudera Impala正好符合我们的要求。为了使用Impala呈现视图，所有的服务层就是在[Hive][]元数据中创建一个表，这些元数据都指向HDFS中的文件。随后，用户立刻能够使用Impala查询到视图。

Hadoop和Impala是批处理层和服务层极好的工具。Hadoop能够存储和处理千兆字节（petabytes）数据，而Impala能够查询快速且交互地查询到这个数据。可是，批处理和服务层单独存在，无法满足实时性需求。原因是MapReduce在设计上存在很高的延迟，它需要花费几小时的时间来将新数据展现给视图，然后通过媒介传递给服务层。这就是为什么我们需要加速层的原因。

### 1.3 加速层 (Speed layer, Storm, Apache HBase) ###

在本质上，加速层与批处理层是一样的，都是从它接受到的数据上计算而得到视图。加速层就是为了弥补批处理层的高延迟性问题，它通过Strom框架计算实时视图来解决这个问题。实时视图仅仅包含数据结果去供应批处理视图。同时，批处理的设计就是连续重复从获取的数据中计算批处理视图，而加速层使用的是增量模型，这是鉴于实时视图是增量的。加速层的高明之处在于实时视图作为临时量，只要数据传播到批处理中，服务层中相应的实时视图结果就会被丢掉。这个被称作为“完全隔离”，意味着架构中的复杂部分被推送到结构层次中，而结构层的结果为临时的，大大方便了连续处理视图。

令人疑惑的那部分就是呈现实时视图，以便于它们能够被查询到，以及使用批处理视图合并来获得全部的结果。由于实时视图是增量的，加速层需要同时随机的读和写。为此，我将使用Apache [Hbase][][数据库][Link 2]。HBase提供了对Storm连续地增量化实时视图的能力，同时，为Impala提供查询经批处理视图合并后得到的结果。Impala查询存储在HDFS中批处理视图和存储在HBase中的实时视图，这使得Impala成为相当完美的工具。

![SouthEast 1][]

Lambda抽象架构也可以这样来描述：

![SouthEast 2][]

[Link 1]: http://lib.csdn.net/base/architecture
[SouthEast]: /images/20220705/81fbe85fa712474bbc085c7e45b21b42.png
[Hadoop]: http://lib.csdn.net/base/hadoop
[Cloudera Impala]: http://impala.io/
[Hive]: http://lib.csdn.net/base/hive
[Hbase]: http://lib.csdn.net/base/hbase
[Link 2]: http://lib.csdn.net/base/mysql
[SouthEast 1]: /images/20220705/dddaf931c1924e6792a24427933cbc67.png
[SouthEast 2]: /images/20220705/387f49db71254bb1879d55ba1a6c5b0f.png