湖仓一体架构解析：数仓架构选择（第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. 元数据流批一体：流与批使用同一套元数据管理系统，一方面方便管理，另一方面可以相互访问。