大数据系统的Lambda架构

Posted 2022-12-04 Frank201608

本文是对大数据系统的Lambda架构的读后笔记。好记性不如烂笔头。

---

Labmda Architecture：
用于在大数据架构中，如何让real-time与batch job更好地结合起来，以达成对大数据的实时处理。

传统系统的问题
问题：传统数据库系统当用户访问量增加时，请求负荷超载，会导致超时，无法及时响应用户请求。
解决办法：
Web服务器与数据库之间增加一个异步处理的队列。如下图所示：

当Web Server收到页面请求时，会将消息添加到队列中。在DB端，创建一个Worker定期从队列中取出消息进行处理，例如每次读取100条消息。这相当于在两者之间建立了一个缓冲。比如：12306的买票系统。

但是，这一方案并没有从本质上解决数据库overload的问题。一个worker忙不过来，就需要增加多个worker并发执行，数据库还是会成为响应的瓶颈。然后需要对数据库进行水平分区和数据分片（horizontal partitioning / sharding）。
接下来会引起越来越复杂的问题：
1）寻找key所在的分区。
分区的方式通常以Hash值作为key，客户端需要知道如何去寻找key所在的分区。
2）对数据库进行reshard。
当之前的分区无法满足负载时，就需要增加更多分区，这时就需要对数据库进行reshard。resharding非常耗时又痛苦，会涉及数据的迁移、更新客户端访问的分区地址、还有线上正在运行的系统怎么办? 错误分区有会引起查询失败等等一系列的问题。
3）容错性（Fault-Tolerance）的问题。
即使分区能够解决数据库负载问题，却还存在容错性（Fault-Tolerance）的问题。
于是会使用数据库的replication功能，为每个分区增加slave。
但是，比如：在应用系统代码端不小心引入了一个bug，使得对页面的请求重复提交了一次，这就导致了重复的请求数据。糟糕的是， 此时对数据的破坏已经造成了。数据备份也无法解决此问题，因为它不知道到底是哪些数据受到了破坏。由于人为错误总是不可避免的，我们在架构时应该如何规避此问题？

现在，架构变得越来越复杂，增加了队列、分区、复制、重分区脚本（resharding scripts）。应用程序还需要了解数据库的schema，并能访问到正确的分区。最糟糕的问题是系统并没有为人为错误进行工程设计，仅靠备份是不能治本的。归根结底，系统还需要限制因为人为错误导致的破坏。

---

数据系统的概念

大数据处理技术需要解决这种可伸缩性与复杂性。
1）首先要认识到这种分布式的本质，要很好地处理分区与复制，不会导致错误分区引起查询失败，而是要将这些逻辑内化到数据库中。当需要扩展系统时，可以方便地增加节点，系统也能够针对新节点进行rebalance。

2）其次是要让数据成为不可变的。原始数据永远都不能被修改，这样即使犯了错误，写了错误数据，原来好的数据并不会受到破坏。

何谓“数据系统”？Nathan Marz认为：
如果数据系统通过查找过去的数据去回答问题，则通常需要访问整个数据
Query = function(all data)

---

Lambda架构

将大数据系统构建为多个层次:
1）Batch Layer 批处理层；
2）Serving Layer 服务层；
3）Speed Layer 速度层；

---

batch layer
任何数据访问都可以从表达式 Query = function(all data) 开始，但是，若数据达到相当大的一个级别（例如PB），且还需要支持实时查询时，就需要耗费非常庞大的资源。

解决方式是Batch View ，从Batch View中读取结果。预先运算好的View是可以建立索引的，因而可以支持随机读取。于是系统就变成：

batch view = function(all data)
query = function(batch view)
Batch Layer

batch layer 承担了两个职责：
1）存储Master Dataset，这是一个不变的持续增长的数据集
2）针对这个Master Dataset进行预运算
显然，Batch Layer执行的是批量处理，例如Hadoop或者Spark支持的Map-Reduce方式。

利用Batch Layer进行预运算的作用实际上就是将大数据变小，合并结果，从而有效地利用资源，改善实时查询的性能。但这里有一个前提：
1）需要预先知道查询需要的数据，才能在Batch Layer中安排执行计划，定期对数据进行批量处理。
2）还要求这些预运算的统计数据是支持合并（merge）的。

---

Serving Layer

Batch Layer通过对master dataset执行查询获得了batch view，而Serving Layer就要负责对batch view进行操作，从而为最终的实时查询提供支撑。

因此Serving Layer的职责包含：
1）对batch view的随机访问
2）更新batch view

Serving Layer也可以理解成：就是在Hive元数据中创建一个表，这些元数据都指向HDFS中的文件。随后，用户立刻能够使用Impala查询到视图。

但是批处理和服务层的单独存在，无法满足实时性需求。原因是MapReduce在设计上存在很高的延迟，它需要花费几小时的时间来将新数据展现给视图，然后通过媒介传递给服务层。这就是为什么需要下面加速层的原因。

---

Speed Layer

只要batch layer完成对batch view的预计算，serving layer就会对其进行更新。
在运行预计算时进入的数据不会马上呈现到batch view中。这对于要求完全实时的数据系统而言是不能接受的。要解决这个问题，就要通过speed layer。

从对数据的处理来看，speed layer与batch layer非常相似，它们之间区别：
1）前者只处理最近的数据，后者则要处理所有的数据。
2）speed layer为了满足最小的延迟，并不会在同一时间读取所有的新数据，仅接收新数据时，更新realtime view，而不会像batch layer那样重新运算整个view。

speed layer是一种增量的计算，而非重新运算（recomputation）。
它通过Strom框架计算实时视图来解决这个问题。
因而，Speed Layer的作用包括：

对更新到serving layer带来的高延迟的一种补充
快速、增量的算法
最终Batch Layer会覆盖speed layer
Speed Layer的等式表达如下所示：

---

Lambda架构就是如下的三个等式：

batch view = function(all data)
realtime view = function(realtime view, new data)
query = function(batch view . realtime view)

整个Lambda架构如下图所示：

基于Lambda架构，加速层的实时视图只是作为临时量，一旦数据通过batch layer进入到serving layer，在realtime view中的相应结果就不再需要了。

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