OLTP、OLAP、数据湖、数据集市、湖仓一体到底是什么关系？

一、引言

事务库、分析库、数据仓库、数据湖、数据集市和湖仓一体经常出现在同一张架构图里，却不属于同一个分类维度：

• OLTP、OLAP 描述的是工作负载与处理模式；
• 事务库、分析库 是针对这些工作负载优化的数据库系统；
• 数据仓库、数据湖 是组织、存储和治理分析数据的不同架构；
• 数据集市 是面向特定业务主题或部门的数据交付范围；
• 湖仓一体 尝试在数据湖的开放存储上补齐事务、治理和查询能力。

它们并非简单的前后代替关系。企业同时建设多种系统，是因为下单、支付、历史分析、实时监控、机器学习等场景，对延迟、并发、数据结构和成本提出了不同要求。

二、OLTP 和 OLAP：先分清"工作负载"

2.1.OLTP：让业务正确运行

OLTP 是 Online Transaction Processing（联机事务处理 ），由大量用户实时执行大量数据库事务的处理方式，常见于 ATM、网上银行、收银和电子商务系统。典型操作包括：

• 新增订单；
• 修改库存；
• 查询账户余额；
• 更新支付状态；
• 删除购物车记录。

一个 OLTP 事务通常只影响少量记录，但系统需要承载大量并发事务。例如，用户购买最后一件商品时，系统需要确保扣减库存和创建订单之间满足业务一致性。如果订单创建成功而库存扣减失败，系统就可能超卖。因此，事务库通常强调 ACID、约束、索引以及高并发控制。

OLTP 的常见特征如下：

维度	OLTP 特征
主要目标	支撑业务操作
数据范围	当前、细粒度业务数据
查询方式	主键点查、小范围查询、增删改
单次访问量	少量记录
并发度	通常较高
响应要求	常见为毫秒级
数据模型	常采用规范化关系模型，减少更新异常
典型系统	订单库、账户库、库存库、支付库

OLTP 是工作负载类型，不等于某个固定产品，也不等于关系型数据库本身 。MySQL、PostgreSQL、Oracle Database 等关系数据库可以承载 OLTP，但数据库名称和工作负载类型不是同一个概念。

2.2.OLAP：让数据支持分析与决策

OLAP 是 Online Analytical Processing（联机分析处理 ），是组织大型业务数据库并支持复杂分析的技术，其价值之一是避免复杂分析查询影响事务系统。

典型分析包括：

• 按地区、渠道、品类统计销售额；
• 比较同比和环比；
• 计算用户留存和复购率；
• 分析近三年利润趋势；
• 对不同维度进行上卷、下钻和切片。

OLAP 的常见特征如下：

维度	OLAP 特征
主要目标	分析、决策与探索
数据范围	多源、历史、经过整合的数据
查询方式	大范围扫描、关联、聚合、排序
单次访问量	大量记录
并发度	取决于 BI、即席查询和服务模式
响应要求	从亚秒级到分钟级不等
数据模型	常采用事实表、维度表、宽表或语义模型
典型系统	经营分析、用户画像、指标平台、实时监控

OLAP 也不等于某一种物理实现。它可以运行在：

• 传统数据仓库；
• MPP 分析数据库；
• 列式分析数据库；
• 数据湖查询引擎；
• 湖仓一体平台；
• 预计算的 Cube 或语义模型上。

因此，"OLAP 就是数据仓库"并不准确。 OLAP 描述分析处理方式，数据仓库则描述分析数据如何被整合、组织和管理。

2.3.OLTP 与 OLAP 的核心差异

+----------------+------------------------+--------------------------+
| 比较维度       | OLTP                   | OLAP                     |
+----------------+------------------------+--------------------------+
| 核心问题       | 一笔业务如何正确完成   | 一段时间内业务表现如何   |
| 主要用户       | 业务系统、在线用户     | 分析师、运营、管理者     |
| 典型操作       | INSERT/UPDATE/点查     | JOIN/GROUP BY/聚合       |
| 数据规模       | 单次访问少量记录       | 单次扫描大量记录         |
| 数据状态       | 当前业务状态           | 历史与综合状态           |
| 优化重点       | 事务、并发、低延迟     | 扫描、聚合、压缩、并行   |
| 常见存储布局   | 行式存储较常见         | 列式存储较常见           |
| 主要数据来源   | 业务直接写入           | 从多个数据源汇集而来     |
+----------------+------------------------+--------------------------+

表中的"行式"和"列式"只是常见倾向，不是绝对界限。现代数据库可能同时提供行存、列存、内存计算或混合能力。

三、事务库和分析库：数据库系统的工程分工

OLTP 和 OLAP 是工作负载，事务库和分析库则是针对相应工作负载优化的系统。

3.1.事务库保存业务事实

事务库负责记录业务事件和当前状态，例如：

订单表：
order_id | user_id | amount | status | created_at
--------------------------------------------------
10001    | 501     | 299.00 | PAID   | 10:01:23

它要回答的问题通常是：

• 订单 10001 是否支付？
• 用户 501 有哪些未完成订单？
• 商品 A 还有多少库存？

事务库中的表围绕业务操作设计。为保证数据更新的一致性，系统通常会拆分用户、订单、商品、支付等实体，并通过主外键或业务标识关联。

3.2.分析库保存可计算的历史数据

分析库围绕大规模查询和聚合设计。它可能将订单明细组织为事实表，并关联日期、商品、用户、地区等维度：

                    dim_date
                       |
dim_user ---- fact_order_sales ---- dim_product
                       |
                   dim_region

它要回答的问题通常是：

• 华东地区最近 12 个月各品类销售额是多少？
• 新客和老客的复购率有何差异？
• 促销活动对毛利率造成了什么影响？

这里的"分析库"是一个宽泛称呼。数据仓库、MPP 数据库、实时分析数据库和湖上查询系统，都可能承担分析库角色。

四、数据仓库：从"存数据"转向"组织企业分析数据"

数据仓库可以概括为四个特征：

• 面向主题 ：围绕客户、商品、订单等分析主题组织数据；
• 集成 ：统一来自不同系统的编码、口径和结构；
• 随时间变化 ：保留历史状态，用于趋势分析；
• 相对稳定 ：数据主要用于查询，不像事务库那样持续进行高频单行修改。

因此，数据仓库不是"把数据库里的表复制一份"这么简单。它至少包含三类工作：

• 汇集多个数据源；
• 统一业务语义和指标口径；
• 按分析需求组织历史数据。

典型离线数仓链路如下：

业务数据库      日志系统       外部数据
    │              │              │
    └───────┬──────┴──────┬───────┘
            ▼
       数据采集与同步
            │
            ▼
     ODS：原始数据层
            │
            ▼
     DWD：明细数据层
            │
            ▼
     DWS：汇总/主题层
            │
            ▼
     ADS：应用数据层
            │
       ┌────┼────────┐
       ▼    ▼        ▼
      BI   报表     数据服务

其中：

• ODS 尽量保留源系统数据；
• DWD 完成清洗、标准化和明细建模；
• DWS 围绕分析主题进行汇总；
• ADS 面向具体报表、指标或应用交付数据。

这些分层名称是国内数仓项目中的常见约定，不属于国际标准。不同企业可能使用 Bronze、Silver、Gold，或者 Staging、Core、Mart 等名称。名称可以变化，分层解决的问题大体相似：隔离原始数据、统一明细口径、沉淀公共能力、面向应用交付。

五、数据集市：面向业务消费的数据子集

数据集市是 Data Mart ，定义为面向某一业务线或部门的数据子集。

企业级数据仓库
      │
      ├── 财务数据集市：收入、成本、利润、预算
      ├── 营销数据集市：渠道、活动、线索、转化
      ├── 用户数据集市：画像、留存、复购、价值分层
      └── 供应链数据集市：采购、库存、履约、周转

数据集市解决的是 服务边界 问题：

• 财务只需要可信的财务指标；
• 市场部门希望按活动和渠道分析；
• 供应链团队关注库存周转和履约效率。

数据集市可以有不同实现方式：

1. 物理数据集市 ：数据复制或加工到独立表、独立库；

2. 逻辑数据集市 ：通过视图、语义层或权限构造业务视角；

3. 依赖型数据集市 ：从企业数据仓库派生；

4. 独立型数据集市 ：直接从业务系统构建；

5. 混合型数据集市 ：同时使用仓库数据和业务源数据。

其中，多个部门分别建设独立数据集市虽然交付快，却容易产生重复加工和口径冲突：

订单库 ──> 财务集市：支付金额 = 退款前金额
   └────> 运营集市：支付金额 = 扣除退款后金额

如果双方都把自己的定义称为"公司支付金额"，管理报表就会出现同名不同值。企业级数仓通常会先统一明细事实和公共指标，再向各数据集市交付。

所以，数据集市并非小型数据湖，也不是 OLAP 的同义词。它强调的是 数据服务对象和主题范围 。

六、数据湖：先接住多样数据，再按用途处理

数据湖定义为一种集中式存储库，可以按任意规模保存结构化和非结构化数据，并允许在数据进入时不先强制整理为统一结构。数据湖常见的数据包括：

• 数据库增量日志；
• 应用埋点；
• JSON、CSV、Parquet、Avro 文件；
• 图片、音频、文档；
• IoT 设备数据；
• 算法训练样本。

                         数据湖
+---------------------------------------------------------+
| Raw / Landing                                           |
| 原始日志、CDC、JSON、CSV、图片、外部文件                |
+---------------------------------------------------------+
| Clean / Curated                                         |
| 清洗数据、标准格式、质量规则、统一元数据                 |
+---------------------------------------------------------+
| Serving / Consumption                                   |
| 分析表、特征数据、训练集、共享数据集                     |
+---------------------------------------------------------+
       │                    │                    │
       ▼                    ▼                    ▼
   SQL 分析             机器学习             数据科学

数据湖带来的核心价值是：

1. 以较低成本保存大规模数据；

2. 支持结构化、半结构化和非结构化数据；

3. 允许 Spark、Flink、Trino 和机器学习框架等多种计算引擎访问；

4. 为尚未确定用途的数据保留原始信息。

6.1."Schema on Read"不能理解成"没有模式"

人们常用下面这组词区分数据仓库和数据湖：

• 数据仓库：Schema on Write，写入时确定模式；
• 数据湖：Schema on Read，读取时解释模式。

这个说法便于入门，但容易造成误解。数据湖应支持 Schema on Read，同时也需要模式演进和模式约束来保证质量。原始区可以接受较宽松的数据结构，但当数据进入生产级明细表和服务表后，团队仍然需要管理字段类型、主键语义、分区、质量规则和版本。

一个完全缺少元数据、质量控制和权限治理的数据湖，很容易退化为"数据沼泽"：

有治理的数据湖                         数据沼泽
─────────────                         ────────
数据有负责人                          不知道谁生产
字段有定义                            不知道字段含义
血缘可追踪                            不知道从哪里来
质量可监控                            不知道能否使用
权限可管理                            文件权限混乱

因此，数据湖并不等于"把文件扔进对象存储"。

七、数据仓库与数据湖为什么会同时存在？

传统架构往往采用"湖负责留存，仓负责服务"的分工：

             ┌─────────────────────────────┐
             │          数据湖             │
             │ 原始数据、多格式、低成本留存 │
             └──────────────┬──────────────┘
                            │ 清洗、转换、装载
                            ▼
             ┌─────────────────────────────┐
             │          数据仓库           │
             │ 结构化建模、治理、SQL 分析   │
             └──────────────┬──────────────┘
                            ▼
                  BI / 报表 / 数据集市

这种架构并非设计失误，数据湖(ELT)和数据仓库(ETL)解决了不同问题：

维度	数据仓库	数据湖
主要目标	提供稳定、可信的分析数据	低成本接入和保留多样数据
数据形态	以结构化、建模数据为主	结构化、半结构化、非结构化
数据处理时机	通常先治理、建模，再服务	可以先落地，再按用途处理
典型用户	BI、分析师、管理人员	数据工程师、数据科学家、算法工程师
查询方式	SQL、报表、语义模型	SQL、Spark、流计算、机器学习
治理成熟度	传统上较强	取决于目录、权限、质量与表格式建设
成本结构	为稳定查询性能付出较高成本	对象存储成本低，但计算与治理仍有成本

问题在于，当湖和仓分别维护一份数据时，团队需要处理：

• 数据复制；
• 增量同步；
• 两端口径一致性；
• 权限重复配置；
• 数据延迟；
• 存储冗余。

湖仓一体正是针对这些工程问题提出的架构方向。

八、湖仓一体：在数据湖上补齐"表"的能力

湖仓一体不是把"湖"和"仓"两个名称拼起来，而是尝试在对象存储之上增加一组数据库表能力：

                 湖仓一体的逻辑结构

+------------------------------------------------------+
| 服务层：BI、即席分析、实时分析、机器学习、数据服务   |
+------------------------------------------------------+
| 计算层：SQL Engine / Spark / Flink / Trino / ML      |
+------------------------------------------------------+
| 表与治理层：                                        |
| ACID、Schema、Catalog、权限、血缘、版本、统计信息    |
+------------------------------------------------------+
| 开放表格式：Iceberg / Delta Lake / Hudi 等           |
+------------------------------------------------------+
| 对象存储：S3 / OSS / COS / HDFS 等                   |
+------------------------------------------------------+

8.1.为什么只有 Parquet 文件还不够？

Parquet 解决的是列式文件存储问题，但一张分析表往往包含成千上万个文件。系统还要知道：

• 哪些文件属于当前表版本；
• 一次写入是否完整提交；
• 两个任务同时修改时如何处理冲突；
• 删除或更新了哪些记录；
• 表结构如何演进；
• 如何查询历史版本；
• 如何避免扫描无关文件。

Iceberg 将自己定义为面向超大规模分析数据集的开放表格式，并提供模式演进、隐藏分区等能力。开放表格式可以把一组对象存储文件组织成可管理、可演进、可提交的"表"。

8.2.湖仓一体希望减少哪些重复链路？

传统湖仓分离：

数据源 -> 数据湖 -> 转换/复制 -> 数据仓库 -> BI
                 └-----------> 机器学习

湖仓一体的目标形态：

数据源 -> 开放表格式 + 统一治理
                     ├-------> SQL / BI
                     ├-------> 流式分析
                     └-------> 机器学习

目标是让多个计算引擎基于同一份受治理的数据工作，减少湖仓之间的复制与同步。

"统一存储"不代表"没有任何数据副本"，为了提升查询性能，实际系统仍可能创建：

• 缓存；
• 物化视图；
• 聚合表；
• 搜索索引；
• 特征表；
• 面向服务的导出数据。

湖仓一体主要减少因系统边界造成的强制复制，并不消灭所有冗余。

九、湖仓一体会取代 OLTP 事务库吗？

在多数常规架构中不会，传统湖仓系统主要服务分析负载。对象存储、分析型表格式和批量优化机制适合大规模扫描，却不天然适合高并发、小事务和基于索引的单行更新。

因此，常见架构仍然是：

用户请求
   │
   ▼
OLTP 事务库
   │
   ├── CDC ──> 实时计算 ──> 实时明细/聚合表
   │
   └── 批量同步 ──────────> 离线明细/历史表
                                  │
                                  ▼
                         数据仓库或湖仓平台

湖仓一体可以统一离线分析、实时分析和机器学习所需的数据基础，但高并发订单写入、账户扣款和库存事务仍通常由专门的事务数据库承担。

目前业界也在探索 HTAP、LTAP、流批一体和湖上事务数据库。这些方向可能缩小 OLTP 与 OLAP 之间的数据同步距离，但不能据此得出"所有负载都应该放进一个引擎"的结论。不同实现的延迟、隔离级别、索引能力和成熟度差异很大，需要按产品和版本验证。

十、离线数仓与实时数仓处在什么位置？

离线数仓和实时数仓都属于分析体系。两者的主要区别是数据到达、计算和交付的时效要求。

10.1.离线数仓

离线数仓通常按小时或天调度：

T 日业务数据
     │
     ▼
批量采集
     │
     ▼
ODS -> DWD -> DWS -> ADS
                       │
                       ▼
                  T+1 报表

适合：

• 日报、月报；
• 财务结算；
• 历史经营分析；
• 大规模重算；
• 对分钟级时效没有要求的指标。

10.2.实时数仓

实时数仓通过日志、CDC 和消息队列持续处理数据：

业务库 ── CDC ──┐
应用日志 ───────┼──> 消息队列 ──> 流计算 ──> 实时明细/聚合
设备事件 ───────┘                          │
                                          ▼
                                  实时 OLAP / 数据服务

适合：

• 实时交易大盘；
• 分钟级活动监控；
• 实时风控；
• 实时推荐特征；
• 库存和履约监控。

10.3.湖仓一体与流批一体也不是同义词

• 湖仓一体 关注湖与仓在存储、表格式、治理和计算上的统一；
• 流批一体 关注流处理和批处理能否共享 API、逻辑或执行模型。

一个平台可以同时具备两者，也可以只具备其中之一。

十一、小结

                        企业数据系统全景

┌──────────────────────────────────────────────────────────────┐
│ 业务运行层                                                   │
│                                                              │
│ App / Web / ERP / CRM                                        │
│          │                                                   │
│          ▼                                                   │
│ 事务数据库：MySQL / PostgreSQL / Oracle 等                   │
│ 工作负载：OLTP                                               │
└──────────┬───────────────────────────────────────────────────┘
           │ CDC、日志、消息、批量同步
           ▼
┌──────────────────────────────────────────────────────────────┐
│ 数据接入与计算层                                             │
│                                                              │
│ 批处理：离线 ETL                 流处理：实时 ETL            │
└──────────┬───────────────────────────┬───────────────────────┘
           │                           │
           ▼                           ▼
┌──────────────────────────────────────────────────────────────┐
│ 分析数据平台                                                 │
│                                                              │
│ 数据湖：原始与多类型数据                                     │
│ 数据仓库：集成、建模、历史分析数据                           │
│ 湖仓一体：在湖存储上增加事务表、治理和高性能分析能力         │
│                                                              │
│ 工作负载：OLAP、数据科学、机器学习                           │
└────────────────────────────┬─────────────────────────────────┘
                             │
                             ▼
┌──────────────────────────────────────────────────────────────┐
│ 数据消费层                                                   │
│                                                              │
│ 财务集市  营销集市  用户集市  供应链集市                     │
│     │          │          │          │                       │
│    BI        指标平台     数据服务     算法应用               │
└──────────────────────────────────────────────────────────────┘

• OLTP 数据通常是分析数据的重要来源；
• OLAP 可以运行在数据仓库、数据湖或湖仓平台上；
• 数据集市位于面向业务消费的一侧；
• 数据湖和数据仓库可以并存；
• 湖仓一体尝试统一分析数据基础，但通常不直接承担核心 OLTP 事务。