数据层

DeeLMind2026年1月31日大约 3 分钟

数据层

定位：
数据层是大型架构中最核心、最昂贵、最难扩展的一层，负责数据持久化、一致性、可靠性、可扩展性、合规与安全。
对 CTO 来说，这一层的设计直接决定了 系统上限、故障半径、成本曲线。

一、数据层的核心职责

1️⃣ 数据持久化

业务数据不因进程、节点、机房故障而丢失
支持长期存储、审计、回溯

2️⃣ 数据一致性管理

处理分布式系统中的：
- 强一致
- 最终一致
- 因果一致

3️⃣ 高可用 & 容灾

单点故障不可接受
支持跨 AZ / 跨 Region

4️⃣ 性能与扩展性

高并发读写
水平扩展优先于垂直扩展

二、数据层的逻辑分层（非常重要）

┌─────────────────────────────┐
│ 数据访问抽象层 │ ← DAO / Repository
├─────────────────────────────┤
│ 在线数据存储层 │ ← DB / KV / Cache
├─────────────────────────────┤
│ 分析型数据层 │ ← OLAP / 数仓
├─────────────────────────────┤
│ 数据流与消息层 │ ← Stream / Log
├─────────────────────────────┤
│ 备份 / 冷存储层 │ ← Archive / Backup
└─────────────────────────────┘

三、在线事务数据（OLTP）

1️⃣ 关系型数据库（RDBMS）

常见选型

MySQL / PostgreSQL
Aurora / TiDB / CockroachDB

使用场景

强事务
金融、订单、账户系统

关键设计点（CTO 关注）

主从复制
读写分离
分库分表（Sharding）
全局 ID（Snowflake / Segment ID）

App
├─ Write → Primary
└─ Read → Replica

⚠️ 风险：

跨分片事务复杂
Schema 变更成本高

2️⃣ NoSQL 数据库

分类与用途

类型	示例	场景
KV	Redis / DynamoDB	会话、计数
文档	MongoDB	灵活 Schema
列存	Cassandra / HBase	海量写入
图	Neo4j	关系密集

CTO 设计原则

NoSQL ≠ 万能
明确牺牲的是：
- 一致性？
- 事务？
- 查询能力？

四、缓存系统（极其关键）

1️⃣ 缓存层位置

Client
↓
CDN
↓
Gateway
↓
Service
↓
Redis / Memcached
↓
Database

2️⃣ 常见缓存模式

Cache Aside（最常见）
Read Through
Write Through
Write Back

3️⃣ CTO 必须解决的问题

缓存击穿
缓存雪崩
热点 Key
数据一致性

五、分析型数据（OLAP / 数仓）

1️⃣ 为什么一定要独立？

OLTP 和 OLAP 放一起 = 灾难

查询模型完全不同
扫描量巨大
资源争抢

2️⃣ 常见技术栈

层级	技术
数据仓库	ClickHouse / BigQuery
数据湖	S3 + Iceberg / Delta
查询引擎	Presto / Trino
BI	Superset / Metabase

3️⃣ 数据流向

OLTP
↓
CDC / MQ
↓
ODS
↓
DW（明细）
↓
DM（指标）

六、数据流与消息系统（数据神经系统）

1️⃣ 核心组件

Kafka / Pulsar / Kinesis

2️⃣ 作用

解耦服务
削峰填谷
数据复制
实时分析

3️⃣ CTO 必须关注

至少一次 / 至多一次 / 恰好一次
顺序性
消费堆积
数据回放能力

七、备份、冷存储与合规

1️⃣ 冷数据存储

S3 / OSS / GCS
Glacier / Archive

2️⃣ 备份策略

全量 + 增量
跨 Region
定期恢复演练（非常重要）

3️⃣ 合规要求

GDPR
等保
数据可删除性
审计日志不可篡改

八、数据安全（CTO 红线）

1️⃣ 访问控制

最小权限
数据库账号不复用

2️⃣ 加密

At Rest（磁盘加密）
In Transit（TLS）
字段级加密（PII）

3️⃣ 审计

谁在什么时间访问了什么数据
是否可追责

九、CTO 视角的设计总结

数据层不是“选一个数据库”那么简单

CTO 真正在意的是：

❓ 数据增长 10 倍怎么办？
❓ 单 Region 挂了能不能活？
❓ 出现脏数据如何回溯？
❓ 成本曲线是否可控？
❓ 是否被某个厂商锁死？

十、典型大型公司数据层示意

[ Service ]
↓
[ Redis Cluster ]
↓
[ Sharded MySQL / NewSQL ]
↓
[ Kafka ]
↓
[ Data Lake / Warehouse ]
↓
[ BI / AI / 风控 ]

数据层

# 数据层

# 一、数据层的核心职责

# 1️⃣ 数据持久化

# 2️⃣ 数据一致性管理

# 3️⃣ 高可用 & 容灾

# 4️⃣ 性能与扩展性

# 二、数据层的逻辑分层（非常重要）

# 三、在线事务数据（OLTP）

# 1️⃣ 关系型数据库（RDBMS）

# 常见选型

# 使用场景

# 关键设计点（CTO 关注）

# 2️⃣ NoSQL 数据库

# 分类与用途

# CTO 设计原则

# 四、缓存系统（极其关键）

# 1️⃣ 缓存层位置

# 2️⃣ 常见缓存模式

# 3️⃣ CTO 必须解决的问题

# 五、分析型数据（OLAP / 数仓）

# 1️⃣ 为什么一定要独立？

# 2️⃣ 常见技术栈

# 3️⃣ 数据流向

# 六、数据流与消息系统（数据神经系统）

# 1️⃣ 核心组件

# 2️⃣ 作用

# 3️⃣ CTO 必须关注

# 七、备份、冷存储与合规

# 1️⃣ 冷数据存储

# 2️⃣ 备份策略

# 3️⃣ 合规要求

# 八、数据安全（CTO 红线）

# 1️⃣ 访问控制

# 2️⃣ 加密

# 3️⃣ 审计

# 九、CTO 视角的设计总结

# 十、典型大型公司数据层示意

数据层

一、数据层的核心职责

1️⃣ 数据持久化

2️⃣ 数据一致性管理

3️⃣ 高可用 & 容灾

4️⃣ 性能与扩展性

二、数据层的逻辑分层（非常重要）

三、在线事务数据（OLTP）

1️⃣ 关系型数据库（RDBMS）

常见选型

使用场景

关键设计点（CTO 关注）

2️⃣ NoSQL 数据库

分类与用途

CTO 设计原则

四、缓存系统（极其关键）

1️⃣ 缓存层位置

2️⃣ 常见缓存模式

3️⃣ CTO 必须解决的问题

五、分析型数据（OLAP / 数仓）

1️⃣ 为什么一定要独立？

2️⃣ 常见技术栈

3️⃣ 数据流向

六、数据流与消息系统（数据神经系统）

1️⃣ 核心组件

2️⃣ 作用

3️⃣ CTO 必须关注

七、备份、冷存储与合规

1️⃣ 冷数据存储

2️⃣ 备份策略

3️⃣ 合规要求

八、数据安全（CTO 红线）

1️⃣ 访问控制

2️⃣ 加密

3️⃣ 审计

九、CTO 视角的设计总结

十、典型大型公司数据层示意