计算机科学中有一个 CAP 定理,分布式数据存储不可能同时提供以下三个保证中的两个以上。
2011年,内森·马兹(Nathan Marz)在他的博客中提出了一种解决 CAP 定理局限性的重要方法,即 Lambda 架构。
让我们仔细看看 Lambda 架构。Lambda 架构分为三层: 批处理层(batch layer),加速层(speed layer),和服务层(serving layer)。
它结合了对同一数据的实时(real-time)和批量(batches)处理。
首先,传入的实时数据流在批处理层(batch layer)存储在主数据集中,并在加速层(speed layer)存储在内存缓存中。然后对批处理层中的数据建索引,且通过批处理视图使之可用。加速层(speed layer)中的实时数据通过实时视图(real-time views)暴露出来。最后,批处理视图和实时视图都可以独立查询,也可以一起查询,以回答任何历史的或实时的问题。
该层负责管理主数据集。主数据集中的数据必须具有以下三个属性。
主数据集是正确性的保证(source of truth)。即使丢失所有服务层数据集和加速层数据集,也可以从主数据集中重建应用程序。
批处理层还将主数据集预计算到批处理视图(batch views)中,以便能进行低延迟查询。
由于我们的主数据集在不断增长,因此我们必须制定一种策略,以便在有新数据可用时管理批处理视图(batch views)。
加速层批处理视图建立索引便于能快速的即席查询(Ad hoc queries),它存储实时视图并处理传入的数据流,以便更新这些视图。基础存储层必须满足以下场景。
该层提供了主数据集上执行的计算结果的低延迟访问。读取速度可以通过数据附加的索引来加速。与加速层类似,该层也必须满足以下要求,例如随机读取,批量写入,可伸缩性和容错能力。
Lambda 体系结构基于几个假定:容错、即席查询、可伸缩性、可扩展性。
解决此问题的方法之一是通过使用通用库或引入流之间共享的某种抽象来为各层提供通用代码库。譬如 Summingbird or Lambdoop,Casado 这些框架
是的,在许多应用程序中都不需要速度层(speed layer)。如果我们缩短批处理周期,则可以减少数据可用性中的延迟。另一方面,用于访问存储在 Hadoop 上的数据的新的更快的工具(例如 Impala , Drill 或 Tez 的新版本等),使在合理时间内对数据执行某些操作成为可能。
是的,一个例子是 Kappa Kreps 架构,它的示例建议在流中处理传入的数据,并且每当需要更大的历史记录时,它将从 Kafka 缓冲区中重新流化,或者如果我们必须进一步追溯到历史数据集群。
我们可以使用 Hadoop 数据湖在现实世界中实现此架构,在该数据湖中,HDFS 用于存储主数据集, Spark(或 Storm)可构成速度层(speed layer), HBase(或 Cassandra)作为服务层,由 Hive 创建可查询的视图。
为了在广告数据仓库上进行分析,雅虎采取了类似的方法,也使用了 Apache Storm,Apache Hadoop 和 Druid²。
Netflix Suro 项目是 Netflix 数据管道的主干,该管道有独立的数据处理路径,但不严格遵循 lambda 体系结构,因为这些路径可能用于不同的目的,不一定提供相同类型的视图(views)。
使用 Apache Calcite 来桥接离线和近线计算。
请记住: batch view = function (all data) realtime view = function (real-time view new data) and query = function (batch view real-time view).
很容易,对吧?