数据仓库的数据处理架构Lambda和Kappa

 

1.数据仓库

数据仓库(Data Warehouse),简写DW。顾名思义,数据仓库是一个很大的数据存储集合,为企业分析性报告和决策支持而创建,是对多元业务数据的筛选与整合,具备一定的BI能力,主要用于企业的数据分析、数据挖掘、数据报表等方向,指导业务流程改进、监视时间、成本、质量以及控制。

3ce8680b7c204926b7db3121e52698bb.jpeg

2.数据仓库架构

了解完数仓之后,我们再来谈数仓架构。“架构”是什么?到目前为止,还没有出现公认的标准答案。引⽤软件⾏业的一段话:“⼀种被普遍接受的架构定义是指系统的⼀个或多个结构,结构中包括软件的构建(构建是指软件的设计与实现),构建的外部可以看到属性以及它们之间的相互关系”。这⾥参考此定义,把数据仓库架构理解成构成数据仓库的组件及其之间的关系,画出下⾯的数仓架构图:

8c084c1ac90c4e1088e5fc178e8dfb8f.jpeg

  1. 实时数据仓库架构

在某些场景中,数据的价值随着时间的推移⽽逐渐减少。所以在传统⼤数据离线数仓的基础上,逐渐对数据的实时性提出了更⾼的要求。于是诞⽣了⼤数据实时数仓,并且衍⽣出了两种技术架构Lambda和Kappa。

3.1 Lambda架构

先来看下Lambda架构图:

84c9db5acb0c4476a7dd81394578f614.jpeg

从底层的数据源开始,经过Kafka、Flume等数据组件进⾏收集,然后分成两条线进⾏计算:⼀条线是进⼊流式计算平台(例如 Storm、Flink或者SparkStreaming),去计算实时的⼀些指标;另⼀条线进⼊批量数据处理离线计算平台(例如Mapreduce、Hive,Spark SQL),去计算T+1的相关业务指标,这些指标需要隔⽇才能看见。

3.1.1为什么Lambda架构要分成两条线计算?

假如整个系统只有⼀个批处理层,会导致⽤户必须等待很久才能获取计算结果,⼀般有⼏个⼩时的延迟。电商数据分析部门只能查看前⼀天的统计分析结果,⽆法获取当前的结果,这对于实时决策来说有⼀个巨⼤的时间鸿沟,很可能导致管理者错过最佳决策时机

Lambda架构属于较早的⼀种架构⽅式,早期的流处理不如现在这样成熟,在准确性、扩展性和容错性上,流处理层⽆法直接取代批处理层,只能给⽤户提供⼀个近似结果,还不能为⽤户提供⼀个⼀致准确的结果。因此Lambda架构中,出现了批处理和流处理并存的现象。

在 Lambda 架构中,每层都有⾃⼰所肩负的任务。批处理层存储管理主数据集(不可变的数据集)和预先批处理计算好的视图:批处理层使⽤可处理⼤量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的,能够修复任何错误,然后更新现有的数据视图。输出通常存储在只读数据库中,更新则完全取代现有的预先计算好的视图。

流处理层会实时处理新来的⼤数据:流处理层通过提供最新数据的实时视图来最⼩化延迟。流处理层所⽣成的数据视图可能不如批处理层最终⽣成的视图那样准确或完整,但它们⼏乎在收到数据后⽴即可⽤。⽽当同样的数据在批处理层处理完成后,在速度层的数据就可以被替代掉了。

3.1.2那Lambda架构有没有缺点呢?

Lambda架构经历多年的发展,其优点是稳定,对于实时计算部分的计算成本可控,批量处理可以⽤晚上的时间来整体批量计算,这样把实时计算和离线计算⾼峰分开,这种架构⽀撑了数据⾏业的早期发展,但是它也有⼀些致命缺点,并在⼤数据3.0时代越来越不适应数据分析业务的需求。缺点如下:使⽤两套⼤数据处理引擎:维护两个复杂的分布式系统,成本⾮常⾼

批量计算在计算窗⼝内⽆法完成:在IOT时代,数据量级越来越⼤,经常发现夜间只有4、5个⼩时的时间窗⼝,已经⽆法完成⽩天20多个⼩时累计的数据,保证早上上班前准时出数据已成为每个⼤数据团队头疼的问题。

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

导致 Lambda 架构的缺点根本原因是要同时维护两套系统架构:批处理层和速度层。我们已经知道,在架构中加⼊批处理层是因为从批处理层得到的结果具有⾼准确性,⽽加⼊速度层是因为它在处理⼤规模数据时具有低延时性。

那我们能不能改进其中某⼀层的架构,让它具有另外⼀层架构的特性呢?例如,改进批处理层的系统让它具有更低的延时性,⼜或者是改进速度层的系统,让它产⽣的数据视图更具准确性和更加接近历史数据呢?另外⼀种在⼤规模数据处理中常⽤的架构——Kappa 架构,便是在这样的思考下诞⽣的。

3.2 Kappa架构

Kafka的创始⼈Jay Kreps认为在很多场景下,维护⼀套Lambda架构的⼤数据处理平台耗时耗⼒,于是提出在某些场景下,没有必要维护⼀个批处理层,直接使⽤⼀个流处理层即可满⾜需求,即下图所⽰的Kappa架构:

bfb8b60b59124d37a6cbbc7c140d39c9.jpeg这种架构只关注流式计算,数据以流的⽅式被采集过来,实时计算引擎将计算结果放⼊数据服务层以供查询。可以认为Kappa架构是Lambda架构的⼀个简化版本,只是去除掉了Lambda架构中的离线批处理部分;

Kappa架构的兴起主要有两个原因:Kafka不仅起到消息队列的作⽤,也可以保存更长时间的历史数据,以替代Lambda架构中批处理层数据仓库部分。流处理引擎以⼀个更早的时间作为起点开始消费,起到了批处理的作⽤。

Flink流处理引擎解决了事件乱序下计算结果的准确性问题。Kappa架构相对更简单,实时性更好,所需的计算资源远⼩于Lambda架构,随着实时处理的需求在不断增长,更多的企业开始使⽤Kappa架构。但这不意味着kappa架构能够取代Lambda架构。

4.总结

Lambda和kappa架构都有各⾃的适⽤领域;例如流处理与批处理分析流程⽐较统⼀,且允许⼀定的容错,⽤Kappa⽐较合适,少量关键指标(例如交易⾦额、业绩统计等)使⽤Lambda架构进⾏批量计算,增加⼀次校对过程。还有⼀些⽐较复杂的场景,批处理与流处理产⽣不同的结果(使⽤不同的机器学习模型,专家系统,或者实时计算难以处理的复杂计算,可能更适合Lambda架构。

 

 

 

  • 41
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

shangjg3

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值