目录

一、各阶段的架构简介

二、各个架构的详细解释

1. 传统离线架构

2.1. Lambda架构-离线数仓分析+实时链路分析

2.2. Lambda架构-离线数仓+实时数仓

3. Kappa/流批一体架构

4. 湖仓一体架构

三、总结

一、各阶段的架构简介

技术架构		核心驱动(核心需求)	‌关键技术	特点
传统离线架构		海量存储需求	Hadoop生态	1.仅支持离线数据分析 2.不支持实时场景
Lambda架构	离线数仓分析 +实时链路分析	实时分析需求	批流双引擎	1.支持离线、实时数据分析 2.实时数据分析不分层，数据无法复用
	离线数仓 +实时数仓			1.支持离线、实时数据分析 2.离线、实时两套代码，开发、维护成本高 3.离线、实时两套数仓，存储成本、计算成本开销大
Kappa/流批一体架构		开发效率与一致性	Flink/Spark 统一API	1.以实时数据分析为主，适用于离线分析少的场景 2.离线、实时一套代码，消除代码冗余 3.KafKa无法存储海量数据 4.KafKa不支持OLAP分析(SQL分析)，临时性需求无法快速满足 5.数据重播时资源消耗大，故障恢复复杂
湖仓一体架构		存储治理与灵活性平衡	Delta Lake /Iceberg	1.存储中的小文件问题 2.实时数据分析效率不高

二、各个架构的详细解释

1. 传统离线架构

核心特点‌

1. 批处理主导‌

数据通过周期性ETL（如每日全量同步）导入HDFS等分布式存储，计算依赖MapReduce、Hive等离线引擎。

2. 高存储性价比‌

基于HDFS的廉价存储适合PB级历史数据，但时效性仅为T+1。

技术栈‌

Hadoop生态（HDFS/Hive）为主，结合关系型数据库作数据源。

2.1. Lambda架构-离线数仓分析+实时链路分析

核心特点

1.支持离线、实时两种数据分析

离线数据、实时数据各有一套处理逻辑，能够对关键性指标进行实时数据分析处理。

2.实时数据分析不分层，数据无法复用

实时分析中仅仅是通过Kafka分发消息后通过Flink进行流处理，没有分层的结构，导致每个需求都要单独开发，数据几乎无法复用。

技术栈‌

Hadoop生态（HDFS/Hive）+ 实时相关生态技术(Kafka + Flink + Sparkstreaming ... ...)。

2.2. Lambda架构-离线数仓+实时数仓

核心特点

1.开发、维护成本高

离线、实时各有一套代码，开发时要开发两套，维护时也要维护两套，成本翻倍。

2.存储成本、计算成本开销大

离线、实时各有一套数仓，数据冗余度高，存储成本、计算成本翻倍。‌

技术栈‌

Hadoop生态（HDFS/Hive）+ 实时相关生态技术(Kafka + Flink + Sparkstreaming ... ...)。

注：2.2相较于2.1其实就是引入了数仓的概念到实时链路中。

3. Kappa/流批一体架构

核心特点‌

1. 以实时分析为主，离线分析少‌

2. 放弃离线批处理，直接通过实时数据分析进行数据处理。

2. Kafka在流批一体场景下存在一定的缺陷‌

• Kafka 无法存储海量数据
• 数据治理平台无法迁移使用
• Kafka 不支持数据的更新操作

技术栈‌

Flink/Spark统一API

流批一体架构的思想

• 架构角度：一套架构既能完成流处理也能完成批处理
• 计算框架：一个框架既可以处理批数据也可以处理流数据
• SQL 层面：一套 SQL 可以处理批也可以处理流数据
• 存储层面：离线数据和实时数据只需要存储一份

4. 湖仓一体架构

核心特点‌

1. 数据孤岛与整合难题‌

统一存储结构化、半结构化和非结构化数据，消除传统架构中数据仓库与数据湖的割裂，减少数据冗余和迁移成本。

2. 小文件问题

传统离线数仓，HDFS中其实也会存在类似的问题。

3. 实时数据处理慢

索引机制（如Bloom索引假阳性）和写入模式（COW小文件问题）可能导致实时数据处理延迟。

技术栈‌

HDFS、Delta Lake 、Iceberg

三、总结