其他分享
首页 > 其他分享> > Lambda架构 VS Kappa架构

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架构。

 

标签:Kappa,实时,VS,计算,架构,数据,Lambda
来源: https://www.cnblogs.com/xuzhujack/p/15770957.html