Lambda 与 Kappa 架构，不可变数据的计算探索

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

1.Lambda架构

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

• 一、数据的不可变性，任何对于数据的操做是没有反作用。
• 二、数据的无依赖性，即对函数提供一样的输入，那么函数老是返回一样的结果。
• 三、函数是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可以经过一个计算框架同时解决批处理计算与流计算的问题，是很值得开发与运维人员所关注的.........