数据架构师 L3:架构设计
资深数据架构师成长路线,掌握复杂架构设计、系统优化和架构演进策略。
views
| comments
数据架构师学习路线 - L3 架构设计#
[!abstract] 定位 L3 阶段的核心是能够独立完成复杂数据架构设计。你需要掌握数据湖、实时数仓、湖仓一体等现代架构模式，并能根据业务需求做出合适的架构选择。
这份指南适合谁？#
- 3-5 年数据相关经验，已有架构设计基础
- 正在负责或即将负责数据平台架构
- 需要做技术选型和架构规划决策
- 目标是资深数据架构师
常见困惑：现代数据架构怎么选？#
“数据湖、数据仓库、湖仓一体，到底用哪个？“#
| 架构 | 适用场景 | 不适用场景 |
|---|---|---|
| 传统数仓 | 结构化数据，BI报表，成熟业务 | 非结构化数据多，需求变化快 |
| 数据湖 | 非结构化数据多，ML场景多 | 需要高性能OLAP查询 |
| 湖仓一体 | 结构化+非结构化都有，想统一管理 | 团队能力不足以驾驭 |
选择建议：
| 团队规模 | 建议架构 | 原因 |
|---|---|---|
| 小团队(3-5人) | 成熟数仓方案 | 简单可控，运维成本低 |
| 中等团队(5-15人) | 数仓为主+数据湖补充 | 兼顾效率和灵活性 |
| 大团队(15人+) | 湖仓一体 | 有能力驾驭复杂架构 |
”实时数仓和离线数仓怎么选？“#
| 维度 | 离线数仓 | 实时数仓 |
|---|---|---|
| 时效性 | T+1 | 秒级/分钟级 |
| 成本 | 低 | 高（3-5倍） |
| 复杂度 | 低 | 高 |
| 数据质量 | 更易保证 | 挑战更大 |
[!tip] 务实建议 不要为了”实时”而实时。先问清楚业务真正需要的时效性是什么，T+1 能满足的就不要做实时。
阶段目标#
- 掌握现代数据架构：数据湖、湖仓一体、实时数仓
- 具备复杂系统设计能力：能设计 PB 级数据平台
- 深入技术选型：能评估并选择合适的技术栈
- 建立成本意识：在性能、成本、复杂度之间权衡
核心技能#
1. 数据湖架构#
数据湖解决的是”先存后用”的问题，支持非结构化数据和探索式分析
数据湖核心组件：
┌─────────────────────────────────────────────────┐
│ 数据湖架构 │
├─────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 数据接入 │ │ 元数据管理 │ │ 数据治理 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ ↓ ↓ ↓ │
│ ┌───────────────────────────────────────┐ │
│ │ 统一存储层 (Object Storage) │ │
│ │ S3 / HDFS / OSS / MinIO │ │
│ └───────────────────────────────────────┘ │
│ │ │ │ │
│ ↓ ↓ ↓ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Raw │ │ Processed │ │ Curated │ │
│ │ 原始数据 │ │ 加工数据 │ │ 可用数据 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────┘数据湖分区设计：
| 分区方式 | 适用场景 | 注意事项 |
|---|---|---|
| 按时间分区 | 日志类、事件类数据 | 选择合适的粒度（天/小时） |
| 按业务分区 | 多租户、多业务线 | 避免数据倾斜 |
| 混合分区 | 复杂场景 | 注意分区数量不要过多 |
数据湖 vs 数据沼泽：
| 数据湖 | 数据沼泽 |
|---|---|
| 有元数据管理 | 数据进去就找不到了 |
| 有数据质量控制 | 不知道数据是否可信 |
| 有权限管理 | 谁都能访问 |
| 有数据生命周期 | 数据只进不出 |
2. 湖仓一体架构#
湖仓一体是数据湖和数据仓库的融合，“存算分离 + 开放格式”
湖仓一体核心技术：
| 技术 | 定位 | 核心能力 |
|---|---|---|
| Delta Lake | 事务层 | ACID事务、时间旅行、Schema演进 |
| Apache Iceberg | 表格式 | 隐藏分区、Schema演进、快照 |
| Apache Hudi | 增量处理 | 增量更新、流批一体 |
湖仓一体架构示例：
┌─────────────────────────────────────────────────┐
│ 查询/分析层 │
│ Spark SQL | Presto | Dremio | Snowflake │
├─────────────────────────────────────────────────┤
│ 表格式层 │
│ Delta Lake | Iceberg | Hudi │
├─────────────────────────────────────────────────┤
│ 存储层 │
│ S3 / HDFS / OSS │
└─────────────────────────────────────────────────┘选型建议：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| Spark 生态为主 | Delta Lake | 集成最好 |
| 多引擎查询 | Iceberg | 兼容性最好 |
| 需要增量更新 | Hudi | 增量处理能力强 |
相关知识：湖仓一体 ↗、[Delta Lake](https://pro.ss-data.cc/knowledge/Delta ↗ Lake)、[Apache Iceberg](https://pro.ss-data.cc/knowledge/Apache ↗ Iceberg)
3. 实时数仓架构#
实时数仓解决的是数据时效性问题，代价是复杂度和成本上升
实时数仓架构演进：
| 架构 | 特点 | 问题 |
|---|---|---|
| Lambda | 批处理+实时两条链路 | 两套代码，维护成本高 |
| Kappa | 只有实时链路 | 历史数据回溯困难 |
| 流批一体 | 同一套代码，流批两种模式 | 技术复杂度高 |
Lambda 架构：
┌─────────────┐
│ 数据源 │
└──────┬──────┘
│
┌────────────┴────────────┐
↓ ↓
┌────────────────┐ ┌────────────────┐
│ 批处理层 │ │ 速度层 │
│ Spark/Hive │ │ Flink │
└────────┬───────┘ └────────┬───────┘
│ │
↓ ↓
┌────────────────┐ ┌────────────────┐
│ 离线数仓 │ │ 实时数仓 │
│ (全量精确) │ │ (增量近似) │
└────────┬───────┘ └────────┬───────┘
│ │
└────────────┬───────────┘
↓
┌─────────────┐
│ 服务层 │
└─────────────┘实时数仓分层：
| 层级 | 实时数仓 | 处理逻辑 |
|---|---|---|
| ODS | Kafka Topic | 原始消息流 |
| DWD | Kafka Topic | 清洗、关联维度 |
| DWS | Kafka/OLAP | 轻度聚合 |
| ADS | Redis/OLAP | 应用数据 |
[!warning] 实时数仓挑战
- 数据质量保证困难
- 维度关联复杂（维度变化怎么办）
- 数据回溯困难
- 运维复杂度高
相关知识：实时数仓架构 ↗、Lambda架构 ↗、Kappa架构 ↗
4. 数据服务架构#
数据最终要以服务的形式提供给业务使用
数据服务分类：
| 服务类型 | 特点 | 典型场景 |
|---|---|---|
| 报表服务 | 批量、定时 | BI报表、周报月报 |
| 查询服务 | 交互式、灵活 | 即席查询、自助分析 |
| 接口服务 | 高并发、低延迟 | 业务系统调用 |
| 推送服务 | 主动推送 | 实时大屏、告警 |
数据接口设计原则：
| 原则 | 说明 | 反例 |
|---|---|---|
| 单一职责 | 每个接口做一件事 | 一个接口返回所有数据 |
| 合理粒度 | 不要太细也不要太粗 | 每个字段一个接口 |
| 有效缓存 | 高频接口要有缓存 | 每次都查数仓 |
| 版本管理 | 接口变更要有版本 | 直接改线上接口 |
5. 大规模数据架构设计#
数据量级上去后，很多小规模的方案就不适用了
PB级数据架构要点：
| 挑战 | 解决方案 |
|---|---|
| 存储成本 | 冷热分层、数据压缩、生命周期管理 |
| 计算效率 | 分区裁剪、索引优化、物化视图 |
| 元数据膨胀 | 元数据服务、分布式catalog |
| 数据倾斜 | 预处理、分桶、动态调整并行度 |
存储成本优化：
| 策略 | 效果 | 实施难度 |
|---|---|---|
| 数据压缩 | 节省 50-80% 存储 | 低 |
| 冷热分层 | 热数据 SSD，冷数据 HDD/对象存储 | 中 |
| 生命周期 | 自动清理过期数据 | 中 |
| 数据去重 | 减少冗余存储 | 高 |
架构决策框架#
架构决策不是拍脑袋，需要系统性的评估方法
架构决策评估维度：
| 维度 | 评估问题 |
|---|---|
| 功能性 | 能满足业务需求吗？ |
| 性能 | 能支撑目标数据量和并发吗？ |
| 可扩展性 | 未来增长能支持吗？ |
| 可运维性 | 团队能运维吗？ |
| 成本 | 总拥有成本(TCO)是多少？ |
| 风险 | 技术成熟度？供应商依赖？ |
架构文档模板：
# 架构设计文档
## 1. 背景与目标
- 业务背景
- 设计目标
- 约束条件
## 2. 需求分析
- 功能需求
- 非功能需求（性能、可用性等）
## 3. 架构设计
- 整体架构
- 各模块设计
- 技术选型
## 4. 决策记录
- 考虑过的方案
- 为什么选择当前方案
- 取舍和权衡
## 5. 实施计划
- 分阶段实施方案
- 风险和应对
## 6. 附录
- 架构图
- 数据流图
- 参考资料这个阶段的难点#
| 难点 | 原因 | 突破方法 |
|---|---|---|
| 新技术太多 | 技术迭代快 | 抓住核心原理，技术只是实现 |
| 没有大规模实践机会 | 公司业务体量有限 | 关注开源社区案例，参与技术分享 |
| 成本估算困难 | 不了解运维成本 | 和运维团队多交流，了解真实成本 |
| 架构决策压力大 | 决策影响深远 | 多方案对比，做好文档记录 |
可胜任的岗位#
| 岗位名称 | 核心要求 | 薪资范围（参考） |
|---|---|---|
| 数据架构师 | 复杂架构设计能力 | 40-60K |
| 大数据平台架构师 | 平台架构设计 | 40-70K |
| 技术专家（数据方向） | 深度技术能力 | 45-70K |
给这个阶段同学的建议#
做的事情#
- 深入学习一两个技术：比如深入理解 Flink 或 Iceberg
- 关注架构演进历史：为什么从 A 演进到 B
- 多画架构图：用图来表达和验证你的思考
- 建立技术判断力：区分哪些是噱头，哪些是真需求
避免的事情#
- 追逐每一个新技术热点
- 过度设计，为未来预留太多
- 忽略运维成本和团队能力
- 决策后不复盘、不总结
[!quote] 关键心态 架构设计的本质是在约束条件下做选择。没有完美的架构，只有合适的架构。
下一阶段预告#
完成 L3 后，你可以进入 L4 技术领导力 ↗，学习：
- 企业级数据架构规划
- 技术团队管理
- 技术战略与业务对齐
- 技术影响力建设