大数据篇：Lambda架构和Kappa架构（下）

大数据篇：Lambda架构和Kappa架构（下）

Lambda 架构的不足

虽然Lambda架构使用起来已经十分灵活，并且可以适用于很多的应用场景，但在实际应用的时候，Lambda架构也存在着一些不足，主要表现在它的维护很复杂。

使用Lambda架构时，工程师必须维护两个复杂的分布式系统，并且保证他们的逻辑产生输出到同一服务层中。

那么我们能不能改进其中某一层架构，让它具有另外一层架构的特性呢？

接下来我们讲讲这节的主角——Kappa架构（Kappa Architecture）,便是在这样的场景下思考诞生的。

Kappa 架构

简介：

Kappa架构是由Linkedln的前首席工程师杰伊·克雷普斯（Jay Kreps）提出的一种架构思想。克雷布斯是几个著名开源项目（Apache Kafka和Apache Samza）的作者之一，也是Confluent大数据公司的CEO。

克雷普斯提出了一个改进Lambda架构的观点：

我们能不能改进 Lambda 架构中速度层的系统性能，使得它也可以处理好数据的完整性和准确性问题呢？我们能不能改进 Lambda 架构中的速度层，使它既能够进行实时数据处理，同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据呢？

实现：

Apache Kafka这样的流处理平台是具有永久保存数据日志的功能的。通过平台这一特性，我们可以重新处理部署速度层架构的历史数据了。

第一步，部署Apache Kafka，并设置数据日志的保留期。这里的保留期指的是你希望能够重新处理的历史数据的时间区间。

例如，你希望重新处理最多一年的历史数据，那就可以把Apache Kafka中的保留期设置为365天。如果你希望能够处理所有的历史数据，那就可以把Apache Kafka中的保留期设置成“永久”。

第二步。如果我们需要改进现有的逻辑算法，那就表示我们需要对历史数据进行重新处理。

我们需要做的就是重新启动一个Apache Kafka作业实例。这个作业实例将重头开始，重新计算保留好的历史数据，并将结果输出到一个新的数据视图中，我们知道Apache Kafka的底层是使用Log Offset来判断现在已经处理到哪个数据块了，所以只需要把Log Offset参数设置成0，新的作业实例就会重头开始处理历史数据。

第三步，当这个新的数据视图处理过的数据进度赶上了旧的数据视图时，我们的应用便可以切换到新的数据视图中读取。

第四步，停止旧版本的作业实例，并删除旧的数据视图。

这个架构就如同下面所示。

与Lambda架构不同的是，Kappa架构去掉了批处理层这一体系结构，只保留速度层。你只需要在业务逻辑改变又或者是代码更改的时候进行数据的重新处理。

当然了，你也可以在我上面讲到的步骤做一些优化。

例如不执行第四步，也就是不删除旧的视图。这样的好处是当你发现代码逻辑出错时可以及时回滚（Roll Back）到上个版本的数据视图中去。又或者是你想在服务层提供A/B测试，保留多个数据视图版本有助于你进行A/B测试。

实例：

看看我们国内常见的新闻网站-中国新闻网

在这里你可以查看每日新闻、搜索新闻、查看实时新闻等

如果采用传统API的架构会是这样的

我们可以看到，这种架构有很多不足。我来给你一一举列子

• 不同的内容API可能由不能的团队开发，从而造成API有不同的语义，也有可能需要不同的参数。
• 调用不同API所得到的内容结果可能有不同的格式，在应用端重新进行规范化。
• 如果客户端上会实时推送一些新的热点新闻或者突发新闻，那么在上述基于 API 的架构中，想要实时获知新闻的话，就需要让客户端不停地做轮询操作。轮询操作在这里指的是客户端定期地重复调用系统 API 来查看是否有新的新闻内容，这无疑增加了系统的复杂性。
• 客户端很难翻阅以前发布过的内容。即便我们知道这些已发布过的新闻列表需要从哪里获取，进行 API 调用去检索每个单独的新闻列表还是需要花很长的时间。而过多的 API 调用又会给服务器产生很大的负荷。

现在我们将这个架构改成Kappa架构。如图：

首先，Kappa 架构在系统调度这个层面上统一了开发接口。

你可以看到，中间的Kappa架构规范好了输入数据和输出数据的格式后，任何需要传送到应用端的数据都必须按照这个接口输入给Kappa架构系统。而所有的应用端客户都只需要按照Kappa架构系统定义好的输出格式接受传输过来的数据。这样就解决了API规范问题。

接下来我们再看看增加中间层的Kappa架构后传输速度上的变化。

因为Apache Kafka是可以实时推送最新数据的，这样一来，任何传输进中间Kappa架构的数据都会被实时的传送到接收客户端中。这样就避免了在应用层面上做定期轮询，从而减少了延时。而对于访问或者处理发布过的新闻内容这一问题，还记得上面讲到的Kafka的特性吗？只需要把Log Offset为0就可以重新读取所有内容。

这里使用了Kappa架构的新闻网站，就可以改进很多的问题了。

不足

因为Kappa架构只保留了速度层而缺少批处理层，在速度层上处理大规模数据可能会有数据更新出错的i情况发生，这就需要我们花费更多的时间在处理这些错误异常上面了。

还有一点，Kappa架构的批处理和流处理都在速度层上，这导致了这架构是使用同一套代码来处理算法逻辑的，所以Kappa架构并不适用于批处理和流处理代码逻辑不一致的场景，例如上章讲到的车位推荐系统。

小结

在这两篇文章中，我们学到了Lambda架构和Kappa架构这两种大数据处理架构，他们都各自有着自身的优缺点。我们需要从实际情况来考虑利弊，看看具体业务到底需要使用哪种架构。

如果你面对的业务逻辑是设计一种稳健的机械学习模型来预测即将发生的事情，那么你应该优先考虑使用Lambda架构，因为它拥有批处理层和速度层来确保更少的错误。

如果你面对的业务逻辑希望实时性比较高，而且客户端又是根据运行时发生的实时时间来做出回应的，那么你就应该有限考虑使用Kappa架构。