产品经理要了解的lambda和Kappa

在现在做产品经理中，有一个分支是数据产品经理。

因为这类产品经理的工作和数据工程师相似，需要进行数据建设、数据可视化、数据抽取等工作。所以市面上数据产品经理岗位相对少，但是招聘的薪资待遇都不低。

而普通的产品经理往往只是将需求翻译为数据产品功能，不涉及到底层的数据指标实现。而要想成为一个高阶的数据产品经理，则必须要了解基础的数据原理和数据相关技术，今天这篇文章来自小chris分享的，详细介绍了数据仓库中的数据架构lambda和kappa，深度了解数据处理中的2个低层技术原理。

下面为原文

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

1.认识数据仓库架构

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

2.实时架构

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

（1）Lambda架构

先来看下Lambda架构图：

从底层的数据源开始，经过Kafka、Flume等数据组件进?收集，然后分成两条线进?计算：?条线是进?流式计算平台（例如 Storm、Flink或者SparkStreaming），去计算实时的?些指标；

另?条线进?批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔?才能看见。

①为什么Lambda架构要分成两条线计算？

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

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

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

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

②那Lambda架构有没有缺点呢？

Lambda架构经历多年的发展，其优点是稳定，对于实时计算部分的计算成本可控，批量处理可以?晚上的时间来整体批量计算，这样把实时计算和离线计算?峰分开，这种架构?撑了数据?业的早期发展，但是它也有?些致命缺点，并在?数据3.0时代越来越不适应数据分析业务的需求。

缺点如下：使?两套?数据处理引擎：维护两个复杂的分布式系统，成本?常?。

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

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

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

那我们能不能改进其中某?层的架构，让它具有另外?层架构的特性呢？

例如，改进批处理层的系统让它具有更低的延时性，?或者是改进速度层的系统，让它产?的数据视图更具准确性和更加接近历史数据呢？另外?种在?规模数据处理中常?的架构——Kappa 架构，便是在这样的思考下诞?的。

（2）Kappa架构Kafka的创始?Jay Kreps认为在很多场景下，维护?套Lambda架构的?数据处理平台耗时耗?，于是提出在某些场景下，没有必要维护?个批处理层，直接使??个流处理层即可满?需求，即下图所?的Kappa架构：

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

Kappa架构的兴起主要有两个原因：

1.Kafka不仅起到消息队列的作?，也可以保存更长时间的历史数据，以替代Lambda架构中批处理层数据仓库部分。流处理引擎以?个更早的时间作为起点开始消费，起到了批处理的作?。

2.Flink流处理引擎解决了事件乱序下计算结果的准确性问题。

Kappa架构相对更简单，实时性更好，所需的计算资源远?于Lambda架构，随着实时处理的需求在不断增长，更多的企业开始使?Kappa架构。但这不意味着kappa架构能够取代Lambda架构。

3.Lambda和kappa架构都有各?的适?领域；

例如流处理与批处理分析流程?较统?，且允许?定的容错，?Kappa?较合适，少量关键指标（例如交易?额、业绩统计等）使?Lambda架构进?批量计算，增加?次校对过程。

还有?些?较复杂的场景，批处理与流处理产?不同的结果（使?不同的机器学习模型，专家系统，或者实时计算难以处理的复杂计算，可能更适合Lambda架构。

今天的分享就在这里。

若有侵权或商业转载，请联系pmkevin001，进行删除。