Lambda架构Kappa架构

Lambda架构

Lambda 是用Nathan Marz（实时处理框架storm的作者）提出的用于同时处理离线和实时的数据的，可容错的，可扩展的分布式系统。它具备强鲁棒性，提供低延迟和持续更新。它通过批量MapReduce作业提供了虽有些延迟但是结果准确的计算，同时通过Strom等实时计算引擎将最新数据的计算结果初步展示出来

缺点：

1、实时与批量计算结果不一致引起的数据口径问题；基于MapReduce和HDFS的Lambda系统有一个长达数小时的市价窗口，在这个窗口内，由于是是是任务事变二产生的不准确的结果一直存在

2、Lamdba架构需要在两个不同的API中对同样的业务逻辑进行两次编程，一次为批量计算的系统，一次为流失计算的系统，针对同一的业务问题产生了两个代码库，各有不同的漏洞，系统维护成本大大提高。

3、批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。

4、数据源变化都要重新开发，开发周期长：每次数据源的格式变化，业务的逻辑变化都需要针对ETL和Streaming做开发修改，整体开发周期很长，业务反应不够迅速。

5、服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。

Kappa架构

Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题，使得实时计算和批处理过程使用了同一套代码。Kappa架构认为只有在有必要的时候才会对历史数据进行重复计算

Kappa架构的核心思想包括以下三点（我看大家基本上都这么写，我就直接复制过来了，捂脸）

用Kafka或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天。
当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。

缺点：

1、流式处理对于历史数据的高吞吐量力不从心：所有的数据都通过流式计算，即便通过加大并发实例数亦很难适应IOT时代对数据查询响应的即时性要求。

2、开发周期长：此外Kappa架构下由于采集的数据格式的不统一，每次都需要开发不同的Streaming程序，导致开发周期长。

3、服务器成本浪费：Kappa架构的核心原理依赖于外部高性能存储redis,hbase服务。但是这2种系统组件，又并非设计来满足全量数据存储设计，对服务器成本严重浪费。

Lambda和Kappa优缺点：

选择

1、业务需求

所需的历史数据规模比较大，并且达到TB以上，那么选择Lamdba架构可能较为合适；如果历史数据相对较较小，比如电商网站仅30天的数据，可选择Kappa；

如果项目中需频繁的对算法模型进行调优，比如在实际应用中，需要机器学习，需要有批量处理生成预测模型，在交由实时计算进行是是是分析，这种情况下，批处理和实时处理系统不能合并，因此应选择Lambda架构

2、开发和运维成本

Kappa批量和实时计算共用同一套代码，开发和运维成本较低。