一、引言
事务库、分析库、数据仓库、数据湖、数据集市和湖仓一体经常出现在同一张架构图里，却不属于同一个分类维度：
- 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 ，定义为面向某一业务线或部门的数据子集。
企业级数据仓库
│
├── 财务数据集市：收入、成本、利润、预算
├── 营销数据集市：渠道、活动、线索、转化
├── 用户数据集市：画像、留存、复购、价值分层
└── 供应链数据集市：采购、库存、履约、周转
数据集市解决的是 服务边界 问题：
- 财务只需要可信的财务指标；
- 市场部门希望按活动和渠道分析；
- 供应链团队关注库存周转和履约效率。
数据集市可以有不同实现方式：
-
物理数据集市 ：数据复制或加工到独立表、独立库；
-
逻辑数据集市 ：通过视图、语义层或权限构造业务视角；
-
依赖型数据集市 ：从企业数据仓库派生；
-
独立型数据集市 ：直接从业务系统构建；
-
混合型数据集市 ：同时使用仓库数据和业务源数据。
其中，多个部门分别建设独立数据集市虽然交付快，却容易产生重复加工和口径冲突：
订单库 ──> 财务集市：支付金额 = 退款前金额
└────> 运营集市：支付金额 = 扣除退款后金额
如果双方都把自己的定义称为“公司支付金额”，管理报表就会出现同名不同值。企业级数仓通常会先统一明细事实和公共指标，再向各数据集市交付。
所以，数据集市并非小型数据湖，也不是 OLAP 的同义词。它强调的是 数据服务对象和主题范围 。
六、数据湖：先接住多样数据，再按用途处理
数据湖定义为一种集中式存储库，可以按任意规模保存结构化和非结构化数据，并允许在数据进入时不先强制整理为统一结构。数据湖常见的数据包括：
- 数据库增量日志；
- 应用埋点；
- JSON、CSV、Parquet、Avro 文件；
- 图片、音频、文档；
- IoT 设备数据；
- 算法训练样本。
数据湖
+---------------------------------------------------------+
| Raw / Landing |
| 原始日志、CDC、JSON、CSV、图片、外部文件 |
+---------------------------------------------------------+
| Clean / Curated |
| 清洗数据、标准格式、质量规则、统一元数据 |
+---------------------------------------------------------+
| Serving / Consumption |
| 分析表、特征数据、训练集、共享数据集 |
+---------------------------------------------------------+
│ │ │
▼ ▼ ▼
SQL 分析 机器学习 数据科学
数据湖带来的核心价值是：
-
以较低成本保存大规模数据；
-
支持结构化、半结构化和非结构化数据；
-
允许 Spark、Flink、Trino 和机器学习框架等多种计算引擎访问；
-
为尚未确定用途的数据保留原始信息。
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 事务。
