大数据小视角4：小议Lambda 与 Kappa 架构，不可变数据的计算探索

这个系列文章之前因为私事荒废了很久，继续更新～～之前与老大谈论架构时，老大和我聊了聊分布式数据处理之中的Lambda结构，之前在《Designing Data-Intensive Applications》这本书之中，作者 Martin Kleppmann也在文中涉及到了通过重型批处理与灵活的流处理相结合的方式来构建分布式计算系统。所以这次也是借这个机会重新梳理Lambda架构与后续由Jay Kreps提出改进的Kappa架构，结合个人对于数据系统的思考，展开聊一聊分布式计算系统的一些设计思路。由不足之处，望多多指教........

1.Lambda架构

首先我们来看看什么是Lambda架构，Lambda演算在编程语言之中是一个编程范式，它遵循如下几个特点：

1、数据的不可变性，任何对于数据的操作是没有副作用。
2、数据的无依赖性，即对函数提供同样的输入，那么函数总是返回同样的结果。
3、函数是First Class，函数与其他数据类型一样，处于平等地位，可以赋值给其他变量，也可以作为参数，传入另一个函数，或者作为别的函数的返回值。

来自Twitter的Nathan Marz，Marz认为进行计算处理的大数据框架的本质逻辑与函数式编程的思路是不谋而合，所以Marz根据自己多年进行分布式数据系统开发的经验总结提出了Lambda架构。（Marz大神是AFS顶级项目Storm的作者，Storm作为一个优秀的分布式流处理系统）所以接下来我们来看看Marz所提出的Lambda架构是怎么样:

Lambda架构说起来也很简单，就是通过分布式系统的组件搭建，设计出一个具有鲁棒性，可扩展，低延时的分布式计算系统。之所以称之为Lambda架构，就是它最为核心的点就是理由了数据处理过程之中的不可变性与无依赖性。下图展现了一个典型的Lambda架构的分层逻辑：

由上图可以看到，一个典型的Lambda架构的核心分为三个层次：Batch Layer，Speed Layer和Serving Layer。

Batch Layer
Speed Layer
Serving Layer

我们来梳理一下他们是如何分工协助的：首先new data作为整个数据系统的数据源头，Batch Layer作为数据的批处理层次对原始数据进行加工与处理，并且将处理的数据结果的Batch View输入到Serving Layer。(这里对应的是全量数据)

Speed Layer对于实时增加的数据进行处理，生成对增量数据计算结果的Realtime Views。（这里对应的是增量数据）

最终用户查询是通过Batch View与Realtime View相结合的形式将最终结果呈现出来。

并且随着时间的推移，Batch View的计算结果会逐渐替代Realtime View,而业务层可以低延迟的访问由Serving Layer提供的Batch View，也可以通过Realtime View实时反馈业务结果。

我们可以看到在Lambda架构之中，所有的数据都需要满足满足不可变性与无依赖性，出现任何数据问题时，（如出错，丢失等）只需要重新跑一遍算法就可以恢复所需的数据了。

业务场景理解

下面笔者利用一个业务场景简单阐述一下Lambda模式，如下的业务场景只是基于笔者对电商推荐的理解所表述的，对应电商未必实际之中就是采取笔者所阐述的模式：

1：下图是笔者访问x宝网首页所展示的广告页面：

对于这个推荐数据，可以理解为通过Batch Layer对我个人历史数据进行处理之后得出的Batch View推荐。（例如跑Spark Mllib或是Hadoop Mahout对历史数据进行分析推荐的结果,跑这类算法通常费时费力，可以通过提前计算的方式存入MySQL等，后续用户访问时可以直接调用）

2：接下来笔者在x宝网搜索了MacBook pro和ThinkPad x207，对于实时搜索的数据，可以作为流数据实时的通过Speed Layer进行处理。（例如Storm这样的流处理器）

3: 笔者切换回到x宝网的首页，发现多了一个推荐广告项目：Dell 8代CPU专业级显卡，晒单还送爱奇艺半年卡。显然实时流的Realtime View与Batch View共同组成的x宝网的推荐首页内容，很好的反馈了用户的实时需求：

小结

Lambda架构结合了实时处理与批处理的结果，很好的反馈了查询需求，并且在速度和可靠性之间求取了平衡，具有足够的扩展性。在Lambda架构之中，所有的查询都可以定位成一个函数：

Query = Function（Data）

而Lambda架构将数据和计算系统进行细分：

Query = Batch（Old_Data） + RealTime（New_Data）

但是这种架构同样存在一些问题：需要运维两套不同的计算系统，并且合并查询结果，这一定程序上带来了复杂性的增加

2.Kappa架构

Lambda架构诞生之后，来自Linkedln的技术主管Jay Kreps提出了一些质疑，并在Lambda架构之上提出自己的改进版本，将其命名为Kappa架构。

Lambda架构最麻烦的问题就在于：新的逻辑需要两次编码，并且在两个系统中运行和调试代码，需要多运维一个额外的系统。所以Kreps认为Lambda架构试图在两个不同编程范式的顶部建立一个抽象层是非常难的。

而Kappa架构尝试通过一个流处理系统来处理上述两种逻辑，我们来看看Kappa架构是怎么样去设计的：

Kappa架构通过流处理系统的并行机制，来提高并行以实现重复处理。但是很多人会觉得流式处理对于历史数据的高吞吐量会力不从心，这里Kreps给出的解决方案是：仅仅重复处理的完整日志数据。加入需要重复处理30天数据，就利用Kafka保留到30天。

所以这里是开辟另个流式处理来处理新的数据，输出数据是直接输出到一个新的输出表。当这第二个流式处理完成之后，切换到新的表中进行读取，然后停止旧的流式处理，再删除旧的输出表。

同样的，笔者上文举的例子，同样也能通过Kappa架构来实现购物的广告展示。Kappa架构最为核心的是通过一个范式解决需要共同解决的问题。同时不需要引入额外计算系统进行运维。

3.小结

到此为止，笔者也大致聊完两种不同分布式计算系统的架构。笔者认为Lambda架构是一个优秀的解决分布式计算的架构，但需要处理运维不同的大数据系统，并且额外编码逻辑，对于开发者与运维人员都是一个较大的考验。而Kappa架构简化了这个模型，但是对于数据处理总归很难拿出重型的批处理做一个完整数据计算，所以计算结果的准确性是有所限缩的。（也就是对于业务场景是挑剔的，我想也没有一种架构是解决问题的银弹，之间的取舍需要我们开发人员进行完整的评估～～）

而Spark能够通过一个计算框架同时解决批处理计算与流计算的问题，是很值得开发与运维人员所关注的.........