接前一篇文章：软考 系统架构设计师系列知识点之大数据设计理论与实践（13）

所属章节：

第19章. 大数据架构设计理论与实践

          第4节 Kappa架构

19.4.3 Kappa架构的实现

下面以Apache Kafka为例来讲述整个全新架构的过程。

部署Apache Kafka，并设置数日志的保留期（Retention Period）。这里的保留期指的是希望能够重新处理的历史数据的时间区间。例如，如果你希望重新处理最多一年的历史数据，那就可以把Apache Kafka中的保留期设置为365天；如果你希望能够处理所有的历史数据，那就可以把Apache Kafka中的保留期设置为“永久（Forever）”。

如果我们需要改进现有的逻辑方法，那就意味着我们需要对历史数据进行重新处理。需要做的就是重新启动一个Apache Kafka作业实例（Instance）。此作业实例将从头开始，重新计算保留好的历史数据，并将结果输出到一个新的数据视图中。我们知道，Apache Kafka的底层是使用Log Offset来判断现在已经处理到哪个数据块了，所以只需要将Log Offset设置为0，新的作业实例就会从头开始处理历史数据。

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

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

19.4.4 Kappa架构的优缺点

• 优点

Kappa架构的优点在于将实时和离线代码统一起来，方便维护而且统一了数据口径的问题，避免了Lambda架构中与离线数据合并的问题。查询历史数据的时候只需要重放存储的历史数据即可。

• 缺点

Kappa的缺点也很明显：

（1）消息中间件缓存的数量和回溯数据有性能瓶颈。通常算法需要过去180天的数据，如果都存在消息中间件，无疑有非常大的压力。同时，一次性回溯订正180天级别的数据，对实时计算的资源消耗也非常大。

（2）在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序问题，导致数据丢失。

（3）Kappa在抛弃了离线数据处理模块的时候，同时抛弃了离线计算更加稳定可靠的特点。Lambda虽然保证了离线计算的稳定性，但双系统的维护成本高，且两套代码会导致后期运维困难。

对于以上Kappa框架存在的几个问题，目前也存在一些解决方案。对于消息队列缓存数据性能的问题，Kappa+框架提出使用HDFS来存储中间数据。针对Kappa框架展示层能力不足的问题，也有人提出了混合分析系统的解决方案。

至此，“19.4.3 Kappa架构的实现”和“19.4.4 Kappa架构的优缺点”的全部内容就讲解完了。更多内容请看下回。