Lambda架构 VS Kappa架构

一、 Lambda架构

     Storm的创始人Nathan Marz提出的Lambda架构是现在进行实时处理的常见架构。它设计的目的是以低延迟处理和更新数据、支持线性扩展和容错机制。速度层可以直接消费kafka中的数据，也可以对数据进行分层再消费都可以。如下图：

 

 

 优点：
       稳定，对于实时计算部分的计算成本可控，批量处理可以用晚上的时间来整体批量计算，这样把实时计算和离线计算高峰
分开，这种架构支撑了数据行业的早期发展，但是它也有一些致命缺点，并在大数据3.0时代越来越不适应数据分析业务的需求
缺点：
● 实时与批量计算结果不一致引起的数据口径问题：因为批量和实时计算走的是两个计算框架和计算程序，算出的结果往往
不同，经常看到一个数字当天看是一个数据，第二天看昨天的数据反而发生了变化。
● 批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成
白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
●数据源变化都要重新开发，开发周期长：每次数据源的格式变化，业务的逻辑变化都需要针对ETL和Streaming做开发修改，
整体开发周期很长，业务反应不够迅速。
● 服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。
● 离线和实时数据计算结果的merge成本比较大，比如离线的数据在数据仓库Hive，就算是通过sqoop导进了mysql，
实时的在hbase、redis等，两个数据打通融合展示，都是问题。

二、 Kappa架构

     LinkedIn的Jay Kreps结合实际经验和个人体会提出了Kappa架构。Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题，使得实时计算和批处理过程使用同一套代码。此外Kappa架构认为只有在有必要的时候才会对历史数据进行重复计算，而如果需要重复计算时，Kappa架构下可以启动很多个实例进行重复计算。

  如下图：

 

 Kappa架构只关注流式计算，并不是取代Lambda架构，除非完全满足你的使用案例。对于这种架构，数据以流的方式
被采集过来，实时层(Real-time Layer)将计算结果放入服务层(Serving Layer)以供查询。
核心思想，主要包括以下三点：
1.用Kafka或者类似MQ队列系统收集各种各样的数据，你需要几天的数据量就保存几天。
2.当需要全量重新计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
3.当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。

优点：
      将实时和离线代码统一起来，方便维护而且统一了数据口径的问题。
缺点：
● 流式处理对于历史数据的高吞吐量力不从心：所有的数据都通过流式计算，即便通过加大并发实例数亦很难适应IOT时代
对数据查询响应的即时性要求。
● 开发周期长：此外Kappa架构下由于采集的数据格式的不统一，每次都需要开发不同的Streaming程序，导致开发周期长。
● 服务器成本浪费：Kappa架构的核心原理依赖于外部高性能存储redis,hbase服务。但是这2种系统组件，又并非设计来满足
全量数据存储设计，对服务器成本严重浪费。

三、对比总结

      许多实时案例适用于Lambda架构，同样kappa也有适用领域。如果流处理与批处理分析流程比较统一，用Kappa比较合适。然而在其他一些场景中，需要对整个数据集进行批量处理而且优化空间较低，使用Lambda架构性能会更好，实现也更简单。
      还有一些比较复杂的场景，批处理与流处理产生不同的结果（使用不同的机器学习模型，专家系统，或者实时计算难以处理的复杂计算），可能更适合Lambda架构。