数据库系列（十）：数据存储全景 — OLTP / OLAP / HTAP / 数仓 / Lakehouse 一图看懂

Mon, 15 Jun 2026 08:00:00 +0800

写在前面

经过 9 篇深入关系数据库的底层原理，本文作为系列收官，跳出 RDBMS，俯瞰整个数据存储生态。

本文要回答：

OLTP、OLAP、HTAP、数仓、Lakehouse、NoSQL 都是干什么的？怎么选？Snowflake / BigQuery / TiDB / Iceberg / Doris / ClickHouse 在生态中各处于什么位置？

一、数据存储的分类全景

1.1 一张总图

                          数据存储生态
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
   关系数据库               NoSQL                  大数据生态
   (RDBMS)                  (非关系)               (数据湖/数仓)
       │                      │                      │
   ┌───┴───┐            ┌─────┴─────┐          ┌────┴─────┐
   │       │            │           │          │          │
  OLTP   OLAP          键值/列族  文档/图形   数据仓库   数据湖
  MySQL  Doris         Redis     MongoDB    Snowflake  S3/HDFS
  PG     ClickHouse    Cassandra Neo4j      BigQuery
  Oracle StarRocks     DynamoDB
        Snowflake

   横切维度：
   ───────────────────────────────
   HTAP       TiDB / CockroachDB / SingleStore
   Lakehouse  Iceberg / Hudi / Delta / Paimon
   时序       InfluxDB / TimescaleDB / Prometheus
   图         Neo4j / JanusGraph / NebulaGraph

1.2 分类维度

按数据模型：
  - 关系：MySQL / PG / Oracle
  - 键值：Redis / DynamoDB
  - 列族：Cassandra / HBase / Bigtable
  - 文档：MongoDB / CouchDB
  - 图：Neo4j / Dgraph
  - 时序：InfluxDB / TimescaleDB
  - 全文：Elasticsearch

按负载类型：
  - OLTP（联机事务处理）：高并发短事务
  - OLAP（联机分析处理）：长查询聚合
  - HTAP（混合）：两者兼顾

按部署形态：
  - 单机：传统 RDBMS
  - 分布式：Cassandra / HBase / Spanner
  - 云原生：Snowflake / BigQuery / Aurora
  - 一体机：Oracle Exadata / Teradata

二、OLTP（联机事务处理）

2.1 特征

OLTP 工作负载：
  - 大量短事务（毫秒级）
  - 高并发（数千 QPS）
  - 按主键点查、按索引范围查
  - 严格 ACID
  - 行存为主

典型业务：
  - 电商交易
  - 银行账户
  - 用户登录
  - 在线游戏

2.2 代表产品

产品	特点
MySQL	互联网首选，简单稳定
PostgreSQL	复杂查询强，扩展丰富
Oracle	企业级标杆，商用
SQL Server	微软生态首选
Aurora	AWS 的"云原生 MySQL/PG"，存算分离
TiDB	兼容 MySQL 协议的 HTAP
CockroachDB	兼容 PG 协议的全球分布式

2.3 OLTP 的边界

OLTP 不擅长：
  - 跨表大规模聚合（数据分析）
  - 千万行以上的范围扫描
  - 复杂的窗口函数
  - 海量历史数据存储

→ 这些场景交给 OLAP / 数据仓库

三、OLAP（联机分析处理）

3.1 特征

OLAP 工作负载：
  - 少量长查询（秒~分钟级）
  - 大范围扫描
  - 多维聚合（GROUP BY 多列）
  - 容忍弱一致性
  - 列存为主

典型业务：
  - BI 报表
  - 实时大屏
  - 用户行为分析
  - 日志检索

3.2 代表产品

传统 OLAP（MPP）：
  - Teradata（一体机）
  - Greenplum（PG 衍生）
  - Vertica（列存）
  - Neteeza（IBM，已停）

新一代 OLAP：
  - ClickHouse：极致单表性能
  - Apache Doris：开箱即用的实时数仓（详见本博客 Doris 系列）
  - StarRocks：Doris 商业升级，联邦查询强
  - Apache Druid：时序 + 实时分析
  - Apache Pinot：LinkedIn 出品，类似 Druid

3.3 OLAP 引擎坐标

                高并发查询
                    ↑
                    │
            Doris   │   Druid
                    │   Pinot
   ─────────────────┼──────────────→  实时性
                    │
            ClickHouse
                    │
                    │   Greenplum
                    │   Vertica
                    ↓
                海量批处理

本博客已发布的 OLAP 笔记（坐标定位，不再展开）：
  - Elasticsearch 系列：搜索引擎 + 实时分析
  - Doris 系列：实时数仓 / OLAP
  - Redis 系列：缓存（KV，不是 OLAP 但常配合）

四、HTAP（混合负载）

4.1 HTAP 的动机

传统架构：
  OLTP（MySQL）→ CDC / ETL → OLAP（ClickHouse / Hive）
  问题：
  - 数据延迟（T+1 或分钟级）
  - 数据冗余（多套存储）
  - ETL 维护复杂
  - 一致性难保证

HTAP 目标：
  一个数据库同时扛 OLTP + OLAP
  - 实时（无 ETL）
  - 单一数据源
  - 简化架构

4.2 HTAP 的实现思路

思路 1：行列双存（Oracle IMCS / TiDB TiFlash）
  - 行存（用于 OLTP）+ 列存（用于 OLAP）
  - 后台同步两份

思路 2：单存优化（SingleStore）
  - 一种"通用"存储同时支持两种负载

思路 3：存算分离 + 多引擎（Snowflake / BigQuery）
  - 计算层动态选择执行引擎

4.3 代表产品

产品	特点
TiDB	MySQL 兼容，TiKV（行）+ TiFlash（列）
CockroachDB	PG 兼容，全球分布式
SingleStore	MemSQL 改名，统一存储
Oracle 12c+	In-Memory 选项
SQL Server	Columnstore + 行存
OceanBase	阿里，金融级 HTAP

4.4 HTAP 的代价

代价：
  - 写入放大（双存）
  - 资源占用高
  - 调优复杂（两套优化）
  - 不可能同时极致优化两种负载

适用场景：
  - 中等规模（TB 级）
  - 实时分析需求强
  - 不想维护 ETL 链路

不适用：
  - 超大规模 OLAP（PB 级）→ 单独的 OLAP 引擎
  - 极致 OLTP 性能 → 单纯的 OLTP

五、数据仓库（Data Warehouse）

5.1 数仓的定义

数据仓库（Inmon 定义）：
  - 面向主题
  - 集成
  - 时变
  - 非易失

特点：
  - 来自多个源系统的统一数据存储
  - 用于决策支持、报表、分析
  - 历史 ETL 数据沉淀

5.2 数仓的演进

第一代：单机数据库 + OLAP 工具（90s）
  - Oracle / SQL Server + Hyperion / BO

第二代：MPP 数据仓库（2000s）
  - Teradata / Greenplum / Vertica
  - Shared-Nothing 架构
  - 性能远超单机

第三代：Hadoop / Hive（2010s）
  - 基于 HDFS
  - 便宜但慢
  - 离线数仓 T+1

第四代：云原生数仓（2015+）
  - Snowflake / BigQuery / Redshift
  - 存算分离
  - 弹性扩展
  - 按用量付费

第五代：实时数仓 / Lakehouse（2020+）
  - Doris / StarRocks
  - Iceberg / Hudi / Delta
  - 实时 + 离线一体

5.3 数仓的经典分层

数据分层（Kimball 模型）：

  ODS（原始数据层）：源系统原始数据
       │
       │ 清洗、转换
       ▼
  DWD（明细数据层）：标准化的事实明细
       │
       │ 轻度聚合
       ▼
  DWS（汇总数据层）：按主题汇总
       │
       │ 业务加工
       ▼
  ADS（应用数据层）：报表、大屏、API 数据

ETL 工具：Hive / Spark / Flink / dbt

5.4 云原生数仓

Snowflake（2015）：
  - 完全 SaaS，无运维
  - 存算分离（S3 + 计算）
  - 多云（AWS / Azure / GCP）
  - 按用量付费
  - 自动扩展

BigQuery（2010）：
  - Google 内部 Dremel 开源
  - Serverless
  - PB 级查询
  - 标准 SQL

Redshift（2013）：
  - AWS 的 MPP 数仓
  - ParAccel 改造
  - 性价比好

Azure Synapse：
  - 微软的云数仓
  - 整合 Power BI / ADF

六、Lakehouse（湖仓一体）

6.1 Lakehouse 的诞生

传统架构痛点：
  数据湖（HDFS/S3 + 文件）：
  - 便宜，能存所有数据
  - 但没有事务、没有 schema 强制
  - "数据沼泽"

  数据仓库：
  - 强 schema、ACID
  - 但贵、闭环

Lakehouse：把数据仓库的特性（ACID、schema、查询）带到数据湖上

6.2 Lakehouse 表格式

开源三剑客 + 一匹黑马：

Apache Iceberg（Netflix）：
  - 表格式
  - ACID 事务（基于快照）
  - 时间旅行
  - Schema 演化
  - 分区演化
  - Spark / Flink / Trino / Doris / StarRocks 都支持

Apache Hudi（Uber）：
  - 表格式 + 数据管理
  - 支持 Upsert（更新插入）
  - 增量查询
  - CDC 友好

Delta Lake（Databricks）：
  - Databricks 出品
  - ACID 事务
  - 与 Spark 深度集成
  - 商业版有优化

Apache Paimon（Flink 表格）：
  - 流批一体
  - Flink 主推
  - 中国社区活跃（阿里主导）

6.3 四种格式对比

维度	Iceberg	Hudi	Delta	Paimon
出身	Netflix	Uber	Databricks	Flink
主推场景	分析	CDC / 增量	Spark 生态	流批一体
Schema 演化	✅ 强	✅	✅	✅
时间旅行	✅	✅	✅	✅
ACID	✅	✅	✅	✅
Upsert 性能	中	强	中	强
生态支持	最广	中	Spark 强	Flink 强

6.4 Lakehouse 架构

       ┌────────────────────────────────────────┐
       │         查询引擎（计算层）              │
       │   Spark / Flink / Trino / Doris        │
       └──────────────────┬─────────────────────┘
                          │
                          │ 读 / 写表格式
                          ▼
       ┌────────────────────────────────────────┐
       │       表格式（元数据 + 事务）           │
       │   Iceberg / Hudi / Delta / Paimon      │
       └──────────────────┬─────────────────────┘
                          │
                          │ 元数据指向数据文件
                          ▼
       ┌────────────────────────────────────────┐
       │         对象存储（存储层）              │
       │   S3 / OSS / HDFS / Azure Blob         │
       └────────────────────────────────────────┘

特点：
  - 存储、表格式、计算解耦
  - 每层可独立选择
  - 多引擎共享同一份数据
  - 弹性扩展

七、NoSQL 速览

7.1 NoSQL 的"非"关系

NoSQL = Not Only SQL
不同 NoSQL 解决不同问题：

KV（键值）：
  - Redis / Memcached（内存）
  - DynamoDB / etcd（持久）
  特点：极致性能，简单数据模型

列族（Wide Column）：
  - Cassandra / HBase / ScyllaDB
  特点：超高写入吞吐，海量稀疏数据

文档（Document）：
  - MongoDB / CouchDB
  特点：JSON 数据，灵活 schema

图（Graph）：
  - Neo4j / Dgraph / NebulaGraph
  特点：关系密集数据（社交、推荐）

时序（Time Series）：
  - InfluxDB / TimescaleDB / Prometheus
  特点：时间戳索引，写入密集

全文检索：
  - Elasticsearch / OpenSearch / Solr
  特点：倒排索引，文本搜索（详见本博客 ES 系列）

7.2 CAP 定理

CAP 定理（Brewer）：
  - C（Consistency）：一致性
  - A（Availability）：可用性
  - P（Partition tolerance）：分区容忍

只能选两个（实际上 P 必选，所以是 C vs A）：

CP：Cassandra（默认）/ HBase / MongoDB
AP：CouchDB / DynamoDB（默认）

不同选择对应不同业务场景：
  - 银行 / 关键业务：CP（保证一致）
  - 社交 / 推荐：AP（容忍最终一致）

7.3 BASE 与最终一致性

BASE = Basically Available + Soft state + Eventually consistent
对应 ACID 的对立面

最终一致性的典型场景：
  - 微信朋友圈：你刚发的动态，朋友可能延迟 1 秒看到
  - 电商库存：超卖允许（事后对账）
  - 用户画像：分钟级同步

八、选型决策树

8.1 按场景选型

Q1：你的负载是 OLTP 还是 OLAP？
  → OLTP：看 Q2
  → OLAP：看 Q4
  → 两者都有：看 Q6（HTAP）

Q2：数据规模？
  → 单库 < 5TB：MySQL / PostgreSQL
  → 单库 > 5TB 但可控：分库分表（ShardingSphere / Vitess）
  → 单库压不下：分布式数据库（TiDB / CockroachDB）

Q3：业务复杂度？
  → 简单 CRUD：MySQL
  → 复杂查询 / JSON / GIS：PostgreSQL
  → 微软生态：SQL Server
  → 预算充足 / 关键业务：Oracle

Q4：查询模式？
  → 实时多维分析：Doris / StarRocks
  → 单表极致性能：ClickHouse
  → 时序 + 分析：Druid / Pinot
  → 文本搜索：Elasticsearch

Q5：数据规模 + 实时性？
  → PB 级 + 离线：Hive / Spark on S3
  → PB 级 + 实时：Lakehouse（Iceberg / Hudi）
  → TB 级 + Serverless：Snowflake / BigQuery

Q6：HTAP 评估？
  → 数据规模 TB 级 + 不想维护 ETL：TiDB / CockroachDB
  → 关键业务 + 预算充足：Oracle IMCS / OceanBase

8.2 实战决策

典型组合：

  小型 SaaS（百万级用户）：
    MySQL（OLTP）+ Redis（缓存）+ Elasticsearch（搜索）

  互联网公司（亿级用户）：
    MySQL 分片 + Redis 集群 + Doris（实时数仓）+ Hive（离线）

  传统企业（关键业务）：
    Oracle RAC（核心）+ SQL Server（部门）+ Power BI

  数据驱动公司：
    PostgreSQL（业务）+ Snowflake（数仓）+ dbt（ETL）

  IoT / 监控：
    TimescaleDB / InfluxDB（时序）+ Grafana（可视化）

  推荐系统：
    MySQL / TiDB（OLTP）+ Neo4j（图）+ ClickHouse（行为分析）

九、回顾与系列总结

9.1 本系列 10 篇回顾

篇	主题	核心知识
1	总览	一行 UPDATE 串联的 10 个原理子系统
2	存储引擎	物理页 + HEAP/IOT + 行存/列存
3	索引	B+ 树 + 聚集/非聚集 + 失效坑
4	事务 ACID	Undo（A）+ Redo（D）+ WAL
5	MVCC	多版本 + 可见性 + 隔离级别
6	锁	Record/Gap/Next-Key + 死锁检测
7	日志恢复	ARIES + Checkpoint + PITR
8	复制高可用	物理/逻辑复制 + MGR/AlwaysOn/ADG
9	SQL 优化器	CBO + 统计信息 + 执行计划
10	全景	OLTP/OLAP/HTAP/数仓/Lakehouse

9.2 关键认知

1. 关系数据库的"原理"是共通的
   - 四大家解决同一组问题
   - 只是命名和细节不同
   - 学透一个，迁移成本很低

2. 选型看场景
   - 没有最好的数据库
   - 只有最合适的数据库
   - 选错比"不会用"代价大

3. 底层原理决定上限
   - 性能调优必须懂底层
   - 排错必须懂底层
   - 升级迁移必须懂底层

9.3 后续学习路径

本系列是"原理地图"，深入某一项可看：

  存储引擎：
    《Database Internals》（Alex Petrov）
    《Designing Data-Intensive Applications》（Martin Kleppmann）

  事务：
    《Transaction Processing》（Jim Gray）
    《Database System Concepts》（Silberschatz）

  PostgreSQL：
    《The Internals of PostgreSQL》
    官方文档"Internals"章节

  MySQL：
    《MySQL 实战 45 讲》（林晓斌）
    《High Performance MySQL》

  分布式：
    《Designing Data-Intensive Applications》
    Raft Paper / Paxos Paper

  数仓 / Lakehouse：
    Kimball《数据仓库工具箱》
    Iceberg / Hudi / Delta 官方文档

9.4 系列正式完结

本系列 10 篇覆盖：

关系数据库的核心原理（存储、索引、事务、MVCC、锁、日志、复制、SQL）
四大数据库（Oracle / SQL Server / MySQL / PostgreSQL）的横向对比
数据存储生态全景（OLTP / OLAP / HTAP / 数仓 / Lakehouse / NoSQL）

希望这份笔记对你建立系统的数据库知识体系有所帮助。后续如需深入某个方向，欢迎继续探索。

记住三句话：
  1. 数据库原理是一张网，不是一条线
  2. 选型 = 场景 + 约束 + 经验，没有标准答案
  3. 学无止境——技术会过时，原理不会

完。

Lakehouse on 纪伟的个人博客

数据库系列（十）：数据存储全景 — OLTP / OLAP / HTAP / 数仓 / Lakehouse 一图看懂

写在前面

一、数据存储的分类全景

1.1 一张总图

1.2 分类维度

二、OLTP（联机事务处理）

2.1 特征

2.2 代表产品

2.3 OLTP 的边界

三、OLAP（联机分析处理）

3.1 特征

3.2 代表产品

3.3 OLAP 引擎坐标

四、HTAP（混合负载）

4.1 HTAP 的动机

4.2 HTAP 的实现思路

4.3 代表产品

4.4 HTAP 的代价

五、数据仓库（Data Warehouse）

5.1 数仓的定义

5.2 数仓的演进

5.3 数仓的经典分层

5.4 云原生数仓

六、Lakehouse（湖仓一体）

6.1 Lakehouse 的诞生

6.2 Lakehouse 表格式

6.3 四种格式对比

6.4 Lakehouse 架构

七、NoSQL 速览

7.1 NoSQL 的"非"关系

7.2 CAP 定理

7.3 BASE 与最终一致性

八、选型决策树

8.1 按场景选型

8.2 实战决策

九、回顾与系列总结

9.1 本系列 10 篇回顾

9.2 关键认知

9.3 后续学习路径

9.4 系列正式完结