0


湖仓一体架构解析:数仓架构选择(第48天)

系列文章目录

1、Lambda 架构
2、Kappa 架构
3、混合架构
4、架构选择
5、实时数仓现状
6、湖仓一体架构
7、流批一体架构


文章目录


前言

本文解析了Lambda 架构,Kappa 架构,湖仓一体架构,流批一体架构,以及在大数据场景中,如何选择架构。

1、Lambda 架构

在Lambda架构中,为了计算一些实时指标,就在原来的离线数仓基础之上增加了一个实时处理的链路,并对数据源做流式改造:把消息发送到消息队列中(大数据中常用Kafka),实时计算去消费消息队列中的数据,完成实时指标计算,推送到下游的数据服务中去,由数据服务层完成离线与实时结果的合并。

在这里插入图片描述

Lambda架构总结
优点: Lambda架构使开发人员能够构建大规模分布式数据处理系统,它具备很好的灵活性和可扩展性。也对硬件故障和人为失误有很好的容错性

缺点:
    1- Lambda架构最大的问题是需要维护两套计算链路,开发和维护成本
    2- 计算资源占用增多,服务器存储大

2、Kappa 架构

Kappa 架构可以认为是 Lambda 架构的简化版(只要移除 lambda 架构中的批处理部分即可)。

Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题,使得实时计算和批处理过程使用同一套代码

在这里插入图片描述

Kappa 架构的重新处理过程:

(1)选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列,根据需求设置历史数据保存的时长,比如 Kafka,可以保存全部历史数据。

(2)当某个或某些指标有重新处理的需求时,按照新逻辑写一个新作业,然后从上游消息队列的最开始重新消费,把结果写到一个新的下游表中。

(3)当新作业赶上进度后,应用切换结果表,读取 2 中产生的新结果表。

(4)停止老的作业,删除老的结果表。

在这里插入图片描述

Kappa架构总结
优点: 使用一条计算链路完成离线计算和实时计算,节约成本

缺点:
    1- Kappa架构最大的问题是需要重新处理历史数据,程序处理数据的吞吐量会降低
    2- 数据可能丢失
    3- 不适用于离线计算和实时计算代码逻辑不一致的情况。举例: 全局去重
    4- 消息中间件临时存储的数据量和回溯的数据量有性能瓶颈
    5- 无法复用目前已经非常成熟的基于离线计算的数据质量管理体系(数据治理)

3、混合架构

Lambda 架构与 Kappa 架构的对比:

在这里插入图片描述

4、架构选择

5、实时数仓现状

在这里插入图片描述

在这里插入图片描述

总结:
1- Lambda架构的最大缺点是需要维护两条链路,维护和计算成本高
2- Kappa架构最大的缺点是数据处理的吞吐量低
3- Kappa架构可以称之为真正的实时数仓,目前企业中实时数仓最常使用的计算框架Flink

6、湖仓一体架构

在这里插入图片描述

湖仓一体架构总结
优点:
    1- 可以存储海量数据
    2- 可以对中间结果进行查询
    3- 可以复用离线计算中形成的数据质量管理体系(数据治理)
    4- 数据可以进行update更新操作
    
缺点:
    1- 相对Flink实时数仓来说,数据湖对数据的处理延迟相对比较高。数据的分析查询耗时基本在10秒及以上
    2- 如果基于数据湖搭建Lambda架构,这也是相当于需要维护两条线路

7、流批一体架构

在这里插入图片描述

理念:使用同一套API、同一套开发范式来实现大数据的流式计算和批量计算,进而保证处理过程和结果数据的一致性。

  1. 数据集成流批一体:离线与实时是否使用统一数据采集方式;如统一通过 CDC 或者 OGG 将数据实时捕获推送到 kafka,批与流在从 kafka 中消费数据,载入明细层。
  2. 数据存储流批一体:离线与实时数据是否统一分层、统一存储;兼容数据的一致性和实时性。
  3. 处理逻辑流批一体:流与批处理是否使用统一 SQL 语法或者 ETL 组件,再通过底层分别适配流与批计算引擎,保证数据口径的一致性。
  4. 计算引擎流批一体:流与批使用同一套计算引擎,从根本上避免同一个处理逻辑流批两套代码 问题。
  5. 元数据流批一体:流与批使用同一套元数据管理系统,一方面方便管理,另一方面可以相互访问。
标签: 架构 大数据 flink

本文转载自: https://blog.csdn.net/syhiiu/article/details/140697692
版权归原作者 大数据飞总 所有, 如有侵权,请联系我们删除。

“湖仓一体架构解析:数仓架构选择(第48天)”的评论:

还没有评论