Lambda架构的前提：可以对所有数据运行ac-hoc查询来获得结果，但是这样做资源开销很大。

ac-hoc查询：即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。

从技术上讲，现在对大数据运行ac-hoc查询(Cloudera Impala)是可行的，但在每次需要计算URL的页面访问量时查询pb级数据可能不是最有效的方法。因此，Lambda将结果预计算为一组视图，然后查询这些视图。

二、Lambda架构分为三个层次

1.批处理层(Apache Hadoop)

存储、计算

批处理层负责两件事。第一个是存储不可变的、不断增长的主数据集(HDFS)，第二个是从这个数据集计算任意视图(MapReduce)。

迭代计算

计算视图是一个持续的操作，当新数据到达时，它将在下一次MapReduce迭代的重计算过程中聚合到视图中。
视图计算整个数据集，因此批处理层不需要频繁地更新视图。根据数据集和集群的大小，每次迭代可能需要几个小时。

2.服务层(Cloudera Impala)

索引、Impala公开视图

批处理层的输出是一组包含预计算视图的平面文件。服务层负责索引和公开视图，以便查询。
由于批处理视图是静态的，所以服务层只需要提供批量更新和随机读取功能，为此服务层使用Cloudera Impala。要使用Impala公开视图，服务层需要做的就是在Hive Metastore中创建一个指向HDFS文件的表（索引？）。用户将能够使用Impala立即查询视图。

• Impala是Cloudera公司主导开发的新型查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。
• Impala的定位是OLAP

引出速度层

Hadoop和Impala是批处理和服务层的完美工具。Hadoop可以存储和处理pb级的数据，Impala可以快速、交互式地查询这些数据。尽管如此，批处理和服务层本身并不满足任何实时需求，因为MapReduce(按设计)是高延迟的，可能需要几个小时才能在视图中表示新数据并将其传播到服务层。这就是为什么需要速度层。

3.速度层

增量，对应批处理层的迭代计算

本质上，速度层与批处理层相同，它也使用接收到的数据计算视图。但速度层需要补偿批处理层的高延迟，它通过在Storm中计算实时视图来达到这个目的。实时视图只包含对批处理视图进行补充的增量结果。
批处理层从头开始不断地重新计算批处理视图，而速度层使用增量模型，当接收到新数据时，递增实时视图。

临时性，批处理层处理后即删除

临时性：speed层的聪明之处在于实时视图是瞬态的，一旦数据通过了批处理和服务层的处理，实时视图中的相应结果就可以丢弃。在书中，这被称为“复杂性隔离”，这意味着架构中最复杂的部分被推到结果是临时存在的层中。

Storm计算实时视图、HBase存储实时视图、Impala查询合并视图

最后一个难题是公开实时视图，以便对他们进行查询并与批处理视图合并，以获得完整的结果。由于实时视图是增量的，所以speed层需要随机读写，为此Lambda使用Apache HBase。HBase为Storm提供了持续increment实时视图的能力，同时可以通过Impala查询与批处理视图的合并结果。
Impala既可以查询存储在HDFS中的批处理视图，又可以查询存储在HBase中的实时视图，这使得它成为完成这项任务的完美工具。

三、思考

Hadoop使得我们更方便地查询和更新数据。

不可变记录的意义

不可变记录（record）是一个记录在某一时刻的版本。可以添加记录的较新版本，但不能覆盖特定的版本，这意味着始终可以恢复到以前的状态。在Lambda架构中，这意味着如果您不小心添加了一些坏的记录，可以通过简单地删除这些记录，然后重新计算视图以修复问题。这本书把这个称为“human fault-tolerance”