Lambda架构

1. Lambda的组成

Lambda组成如下图：

query = function(alldata)

在该架构中，被读取的数据是不可变的，在并行处理过程中数据会依次进入批处理系统（batch system）与流处理系统。从逻辑上看，传输过程发生了两次，一次是在批处理中，一次是在流处理中。在查询时，当这两者都返回结果后，才算是完成一次完整的查询。

Lambda架构的目的是为应用程序提供一个低延迟的复合异步数据传输环境，例如新闻类应用，经常需要进行大规模信息处理，包括输入，归类，索引，存储等操作。

2. Lambda架构

Lambda基于下列原则：
(1).人为容错性human fault-tolerance – 系统易数据丢失或数据损坏，大规模时可能是不可挽回的。
(2).数据不可变性data immutability – 数据存储在它的最原始的形式不变的，永久的。
(3).重新计算recomputation – 因为上面两个原则，运行函数重新计算结果是可能的。

Lambda架构由三层组成：批处理层，服务层和速度层：

自底向上依次介绍如下，

批处理层Batch Layer：主要进行批量处理，其特点是延时较高、高吞吐量，并且是append-only（没有delete和update的概念）的。

Hadoop 是理想的批处理层工具，包括HDFS和MapReduce。

服务层Serving Layer：主要进行批量更新，其特点是延时相对较低，一般数小时更新一次。用于加载和实现数据库中的批处理视图，以便用户能够查询，不一定需要随机写，但是支持批更新和随机读，推荐：ElephantDB or Voldemort或者HBase和Cassandra。

速度层Speed Layer：主要处理新数据和服务层更新造成的高延迟补偿，进行低延时更新；利用流处理系统如 (Storm, S4, Spark) 和随机read/write数据存储库来计算实时视图(HBase)，采用各种复杂的增量算法实现。 这些视图有效期一直到它们已经能通过批处理和服务层获得时为止。

为了获得一个完整结果，批处理和实时视图都必须被同时查询和融合(实时代表新数据)。

3. Lambda优缺点

所谓优点其实就是它的适用场景或者说上面提出的3大原则，或者它能够成立的基础，这包括两个方面，也是对CAP纠正的两个地方：
数据的不可变性，在事务场景下，需要维护数据的一致性和可用性，操作包括CRUD，首先是与批处理背道而驰的，因此保持数据的不可变性则相应的打破了CAP的束缚从而可以导向Lambda架构。hadoop中append-only的模式非常适合数据的这一特性。
强调数据的可重新计算。

所谓缺点，也是业界有人提出的如何打败Lambda的初衷，首先，代码的维护需要在两个复杂的分布式系统中进行。例如说在基于分布式框架上如Storm或Hadoop中进行编程，使用不同的框架就需要进行不同的处理。虽然目前有解决方案尝试从实时和批处理框架中进行抽象综合，从而使得既能在高阶框架中进行编程而后又能在流处理或MapReduce中完成降阶处理操作；Summingbird采用的就是这种方法。不过这样虽然在某程度上能减少编码的复杂度，但是仍然没有根本性地解决问题。
即使能解决二次编码问题，分别在两个系统中运行和维护应用程序仍然是个艰巨的任务。所以，基于不同系统而抽象得到的新系统，都只能是从两者的功能交集中来进行。类似地，在跨数据库系统中进行ORM(对象关系映射)也是个困难的工作。

4. Lambda改进的方案

一、将批处理和流处理合并，利用kafka保留指定日期范围的数据，如果需要重复计算则再次读取数据，利用流处理一种编程范式。个人感觉还是比较欠妥，利用流式计算莱尼完成批处理计算。如图：

(1).  使用Kafka或其它系统来对需要重新计算的数据进行日志记录，以及提供给多个订阅者使用。例如需要重新计算30天内的数据，我们可以在Kafka中设置30天的数据保留值。

(2).  当需要进行重新计算时，启动流处理作业的第二个实例对之前获得的数据进行处理，之后直接把结果数据放入新的数据输出表中。

(3).  当作业完成时，让应用程序直接读取新的数据记录表。

(4).  停止历史作业，删除旧的数据输出表。

二、Twitter Summingbird，Twitter实时消息处理基础平台。

Summingbird中的Summing有两层含义，一是同一份代码可以运行在多个计算平台上，不同平台（批处理和流处理）的运算结果相加，得到一个聚合的结果。二是很多数据的Reduce操作如加法一样满足结合律，这里称之为可加性，它是数据并行的基础，能表达复杂的聚合逻辑。

Summingbird实现了一个好的数据分析系统，即能在给定的时间内完成查询：query=function（all data）。首先要用全量数据，因为更多的数据优于更优的算法；其次要即时给出查询结果，因为越实时的数据往往越有价值。Summingbird就是这种解决方案，兼顾大数据分析的实时性和准确性，并且简单、易维护和可扩展。

如上介绍的Lambda计算流程如下图所示：

实时处理层数据流为1->2->3->7，

批处理数据流为1->4->5->6->7。

Summingbird架构如下图所示：

三、Spark

参考文献

【1】http://www.csdn.net/article/2014-07-08/2820562-Lambda-Linkedln

【2】http://www.jdon.com/45211