实时数仓之kappa架构与lambda架构（建议收藏！）(代码片段)

关键词：

数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。
数据仓库概念是 Inmon 于 1990 年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用 大数据工具 来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构
后来随着业务实时性要求的不断提高，人们开始在 离线大数据架构 基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是 Lambda 架构。
再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的 Kappa 架构。
数据源通过离线的方式导入到离线数仓中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务，比如 MySQL 或 Redis。数据仓库从模型层面分为三层：
ODS，操作数据层，保存原始数据；
DWD，数据仓库明细层，根据主题定义好事实与维度表，保存最细粒度的事实数据；
DM，数据集市/轻度汇总层，在 DWD 层的基础之上根据不同的业务需求做轻度汇总；
如果要细分，分为五层：
ODS 层
ODS 层: Operation Data Store，数据准备区，贴源层。直接接入源数据的：业务库、埋点日志、消息队列等。ODS 层数数据仓库的准备区
DW数仓
DWD 层:Data Warehouse Details,数据明细层，属于业务层和数据仓库层的隔离层，把持和 ODS 层相同颗粒度。进行数据清洗和规范化操作，去空值/脏数据、离群值等。
DWM 层:Data Warehouse middle,数据中间层，在 DWD 的基础上进行轻微的聚合操作，算出相应的统计指标
DWS 层:Data warehouse service,数据服务层，在 DWM 的基础上，整合汇总一个主题的数据服务层。汇总结果一般为宽表，用于 OLAP、数据分发等。
ADS层
ADS 层:Application data service, 数据应用层，存放在 ES,Redis、PostgreSql 等系统中，供数据分析和挖掘使用。
典型的数仓存储是 HDFS/Hive，ETL 可以是 MapReduce 脚本或 HiveSQL。
数仓分层的优点：
划清层次结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
数据血缘追踪：简单来讲可以这样理解，我们最终给下游是直接能使用的业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
把复杂问题简单化。将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
屏蔽原始数据的异常。屏蔽业务的影响，不必改一次业务就需要重新接入数据。
随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。
Lambda 架构（Lambda Architecture）是由 Twitter 工程师南森·马茨（Nathan Marz）提出的大数据处理架构。这一架构的提出基于马茨在 BackType 和 Twitter 上的分布式数据处理系统的经验。
Lambda 架构使开发人员能够构建大规模分布式数据处理系统。它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。
Lambda 架构总共由三层系统组成：批处理层（Batch Layer），速度处理层（Speed Layer），以及用于响应查询的服务层（Serving Layer）。
在 Lambda 架构中，每层都有自己所肩负的任务。
批处理层 存储管理主数据集（不可变的数据集）和预先批处理计算好的视图。
批处理层 使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有的预先计算好的视图。
速度处理层 会实时处理新来的大数据。
速度层 通过提供最新数据的实时视图来最小化延迟。速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。
Lambda 架构问题：
虽然 Lambda 架构使用起来十分灵活，并且可以适用于很多的应用场景，但在实际应用的时候，Lambda 架构也存在着一些不足，主要表现在它的维护很复杂。
（1）同样的需求需要开发两套一样的代码：这是 Lambda 架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。
（2）资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）
Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。
Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）。
在 Kappa 架构中，需求修改或历史数据重新处理都通过上游重放完成。
Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。
Kappa 架构的重新处理过程：
重新处理是人们对 Kappa 架构最担心的点，但实际上并不复杂：
（1）选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，比如 Kafka，可以保存全部历史数据。
（2）当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消费，把结果写到一个新的下游表中。
（3）当新作业赶上进度后，应用切换数据源，读取 2 中产生的新结果表。
（4）停止老的作业，删除老的结果表。
如下图所示：
在真实的场景中，很多时候并不是完全规范的 Lambda 架构或 Kappa 架构，可以是两者的混合，比如大部分实时指标使用 Kappa 架构完成计算，少量关键指标（比如金额相关）使用 Lambda 架构用批处理重新计算，增加一次校对过程。
Kappa 架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。
End
实时数仓方案如何选型和构建(代码片段)
目录一、为何需要实时数仓架构二、数仓如何分层&各层用途三、数仓分层的必要性四、从Lambda架构说起五、Kappa架构解决哪些问题六、深入实时数仓架构方案1：Kappa架构方案２：基于标准分层+流计算方案3：...  查看详情  
                
数仓第一篇：基础架构
...仓规范06.数据治理07.数仓理念01.架构演进离线数据仓库到实时数据仓库，从lambda架构到kappa架构、再到混合架构。02.逻辑分层数仓分层，一般按ods->dw->dm整体架构。不同的企业，不同的业务场景，有衍生出不同...  查看详情  
                
数仓第一篇：基础架构
...仓规范06.数据治理07.数仓理念01.架构演进离线数据仓库到实时数据仓库，从lambda架构到kappa架构、再到混合架构。02.逻辑分层数仓分层，一般按ods->dw->dm整体架构。不同的企业，不同的业务场景，有衍生出不同...  查看详情  
                
实时数仓方案如何选型和构建(代码片段)
目录一、为何需要实时数仓架构二、数仓如何分层&各层用途三、数仓分层的必要性四、从Lambda架构说起五、Kappa架构解决哪些问题六、深入实时数仓架构方案1：Kappa架构方案２：基于标准分层+流计算方案3：...  查看详情  
                
实时数仓演进&方案对比选型落地(代码片段)
实时数仓演进&方案对比选型落地大数据小江Akin 大数据阶梯之路 2022-07-0423:14 发表于广东收录于合集#实时数仓2个#大数据36个#数据仓库6个#数据湖2个实时数仓好文分享，文章来源：公众号：五分钟学大数据实时数仓...  查看详情  
                
大数据架构(代码片段)
Lambda架构架构中含有离线处理与实时处理两条链路，两条链路处理数据导致数据不一致等Kappa 架构Kappa架构真正的实时数仓，目前在业界最常用实现就是Flink+KafkaKappa存在问题Kafka无法支持海量数据存储。对于海量数据...  查看详情  
                
作业帮实时数仓架构中的doris是如何发挥神威的，一文玩儿透（建议收藏）
...更多技术好文~摘要：今天分享的内容是Doris在作业帮实时数仓架构中的应用及实践分享时间：2021年6月05日内容分享：利敏摘要整理：皮卡丘主要内容：  1、作业帮业务与背景    2、基于Doris的实时查询系统...  查看详情  
                
美团实时数仓架构演进与建设实践
...美团数据平台中心的计算平台团队，当前主要工作内容是实时数仓平台的研发。今天和大家分享一下实时数据在美团的典型应用场景，实时数仓建设中的挑战和解决方案，包括一些关键的设计细节。主要介绍以下几方面内容：建...  查看详情  
                
干货|携程酒店实时数仓架构和案例
...数据治理；魁伟，携程资深数据工程师，关注实时&离线大数据产品及技术。一、实时数仓当前，企业对于数据实时性的需求越来越迫切，因此需要实时数仓来满足这些需求。传统的离线数仓的数据时效性通...  查看详情  
                
汤楚熙：美团实时数仓架构演进与建设实践
...美团数据平台中心的计算平台团队，当前主要工作内容是实时数仓平台的研发。今天和大家分享一下实时数据在美团的典型应用场景，实时数仓建设中的挑战和解决方案，包括一些关键的设计细节。主要介绍以下几方面内容：建...  查看详情  
                
汤楚熙：美团实时数仓架构演进与建设实践
...美团数据平台中心的计算平台团队，当前主要工作内容是实时数仓平台的研发。今天和大家分享一下实时数据在美团的典型应用场景，实时数仓建设中的挑战和解决方案，包括一些关键的设计细节。主要介绍以下几方面内容：建...  查看详情  
                
聊聊实时数仓架构设计
什么是实时数仓首先需要明确什么是实时数仓，百度百科与维基百科都没有给出具体说明，哪究竟什么才是实时数仓呢？是不是可以通过实时流实时获取数据就是实时数仓？或者说流批一体就是实时数仓？在...  查看详情  
                
基于apachehudi和apachesparksql的近实时数仓架构之宽表建设(代码片段)
前言无论是在lamda架构还是kappa架构中，实时计算通常是使用flink+mq来实现的，而在这些场景中涉及到多张表join时，一般我们的使用方法是多张流表join如：RegularJoin、IntervalJoin，或者流表+维表的方式join如...  查看详情  
                
数仓架构演进(代码片段)
...erwrite整张表或整个分区，成本比较高。在线分析处理实时数据，使用Flink/SparkStreaming处理流式数据，分析处理秒级或分钟级流式数据，数据保存在Kafka或定期（分钟级）保存到HDFS中。​该套方案存在以下缺...  查看详情  
                
实时数仓与离线数仓架构对比flink消费流程
实时数仓架构图：离线数仓：与离线数仓区别：MySQL业务数据采集改用FlinkCDC;FlinkCDC与Maxwell处理方式和Cannal一样通过监控binlog方式（行级别），而Sqoop是通过MR方式处理数据，这种方式太慢日志数据，...  查看详情  
                
apacheflinkxapachedoris构建极速易用的实时数仓架构
...给大家带来的分享是《ApacheFlinkXApacheDoris构建极速易用的实时数仓架构》。下面是我们的个人介绍：我是ApacheDorisContributor和阿里云MVP。同时著有《图解Spark大数据快速分析实战》等书籍。接下来咱们进入本次演讲的正题。本...  查看详情  
                
大数据数仓项目架构
...数仓特点基于Serverless的云上数据仓库解决方案架构特点实时数仓架构[图片上传失败...(image-ec3d9a-1629814266849)]实时数仓架构特点秒级延迟，实时构建数据仓库，架构简单，传统数仓平滑升级架构特点数据仓库的输入数据源和输出...  查看详情  
                
基于apachehudi和apachesparksql的近实时数仓架构之宽表建设(代码片段)
前言无论是在lamda架构还是kappa架构中，实时计算通常是使用flink+mq来实现的，而在这些场景中涉及到多张表join时，一般我们的使用方法是多张流表join如：RegularJoin、IntervalJoin，或者流表+维表的方式join如...  查看详情