数据架构师学习路线 - L2 架构基础#

[!abstract] 定位数据架构师是数据领域的高级岗位，负责设计数据系统的整体架构。L2 阶段是架构师的入门，重点是建立架构思维，掌握数据建模和数仓设计的核心能力。

为什么从 L2 开始？#

数据架构师需要扎实的数据开发基础。如果你还没有这个基础，建议先完成：

数据开发 L1 ↗
数据开发 L2 ↗（至少部分完成）

这份指南适合谁？#

2-3 年数据开发经验，想往架构方向发展
对系统设计有兴趣，喜欢思考”为什么这样设计”
已经在参与数仓建设，想系统学习架构知识
目标是数据架构师、数仓架构师

常见困惑：我适合做架构师吗？#

“架构师是不是要技术特别牛？”#

澄清一个误区：架构师不是技术最强的人，而是平衡能力最强的人。

能力	开发工程师	架构师
编码能力	核心能力	够用就行
系统设计	了解即可	核心能力
业务理解	不是重点	非常重要
沟通协调	一般要求	高要求
技术选型	使用技术	决定用什么技术

”开发和架构的区别是什么？“#

视角	开发工程师	架构师
关注点	怎么实现	为什么这样设计
范围	单个模块/任务	整个系统/平台
决策	执行决策	做出决策
周期	短期交付	长期演进

[!tip] 判断标准如果你经常思考”这个设计有什么问题”、“有没有更好的方案”，而不只是”怎么把需求做完”，那你有架构师潜质。

阶段目标#

建立架构思维：从”怎么做”转变为”为什么这样做”
掌握数据建模：理解并能应用维度建模方法论
理解数仓架构：掌握分层设计、主题域划分等核心概念
具备技术选型能力：能评估不同技术方案的优劣

核心技能#

1. 数据建模方法论#

数据建模是架构师的核心技能，决定了数据如何组织和使用

两大建模流派：

流派	代表	特点	适用场景
范式建模	Bill Inmon	先建企业模型，强调规范化	企业级数仓，金融行业
维度建模	Ralph Kimball	业务驱动，以事实和维度为核心	分析型应用，互联网行业

维度建模核心概念：

┌──────────────────────────────────────────────┐
│                  星型模型                      │
│                                              │
│         dim_user    dim_product              │
│             ↑            ↑                   │
│             │            │                   │
│    dim_time → fact_orders ← dim_channel      │
│             │            │                   │
│             ↓            ↓                   │
│        dim_region  dim_promotion             │
│                                              │
└──────────────────────────────────────────────┘

plaintext

概念	说明	举例
事实表 (Fact)	记录业务事件，包含度量值	订单表、点击表
维度表 (Dimension)	描述事实的上下文	用户表、商品表、时间表
度量 (Measure)	可聚合的数值	金额、数量、次数
粒度 (Grain)	事实表每行代表什么	每个订单、每次点击

相关知识：维度建模 ↗、星型模型 ↗、雪花模型 ↗、数据建模方法论 ↗

2. 数仓分层架构#

分层是数仓架构的基础，解决的是数据复用和管理问题

经典分层架构：

┌─────────────────────────────────────────────────┐
│  ADS层 (Application Data Store)                  │
│  面向应用的数据：报表、指标、标签                    │
├─────────────────────────────────────────────────┤
│  DWS层 (Data Warehouse Summary)                  │
│  汇总数据：轻度聚合，公共维度                        │
├─────────────────────────────────────────────────┤
│  DWD层 (Data Warehouse Detail)                   │
│  明细数据：清洗后的业务事实，统一格式                 │
├─────────────────────────────────────────────────┤
│  DIM层 (Dimension)                               │
│  维度数据：公共维度表                              │
├─────────────────────────────────────────────────┤
│  ODS层 (Operational Data Store)                  │
│  原始数据：业务系统原样抽取                         │
└─────────────────────────────────────────────────┘

plaintext

分层设计原则：

原则	说明	反例
高内聚	同层数据逻辑相近	DWD层混入汇总逻辑
低耦合	层间依赖清晰	上层直接访问ODS
可追溯	数据来源可追踪	不知道数据从哪来
可复用	避免重复建设	每个需求都从ODS开始

相关知识：数仓分层架构 ↗、ODS层设计 ↗、DWD层设计 ↗

3. 主题域与数据域划分#

主题域是数仓的组织方式，决定了数据如何被发现和理解

主题域划分方法：

方法	说明	适用场景
按业务流程	交易、物流、支付	流程型业务
按分析主题	用户、商品、订单	分析型应用
按组织架构	销售域、财务域	大型企业

电商数仓主题域示例：

主题域	核心实体	核心事实
用户域	用户、会员	注册、登录、行为
商品域	商品、类目、品牌	上下架、价格变更
交易域	订单、支付	下单、支付、退款
物流域	物流单、仓库	发货、签收
营销域	活动、优惠券	领券、核销

4. 技术选型基础#

架构师需要知道什么场景用什么技术

存储技术选型：

场景	技术选择	原因
海量历史数据	Hive/Spark + HDFS	成本低，批处理
实时分析	ClickHouse/Doris	列存，快速聚合
即席查询	Presto/Trino	联邦查询，交互式
高并发点查	MySQL/Redis	低延迟，高 QPS

计算引擎选型：

场景	技术选择	原因
离线批处理	Spark/Hive	成熟稳定
实时处理	Flink	低延迟，精确一次
流批一体	Flink SQL	统一开发体验

[!warning] 选型建议不要追求技术的”先进性”，要根据团队能力、业务需求、运维成本综合考虑。小团队用成熟稳定的技术。

相关知识：数据存储选型 ↗、计算引擎对比 ↗、OLAP引擎选型 ↗

5. 架构文档编写#

架构师的产出不只是代码，更重要的是文档

架构文档核心内容：

文档类型	核心内容	受众
架构设计文档	整体架构、技术选型、设计决策	技术团队
数据字典	表结构、字段含义、口径定义	开发和分析
数据流图	数据从哪来、到哪去、怎么处理	全团队
接口文档	数据服务的输入输出	下游使用方

好的架构文档特点：

写清楚”为什么”，而不只是”是什么”
有图有表，不是纯文字
及时更新，和实际一致
易于理解，新人能看懂

学习资源#

实践建议#

重新审视你现在项目的数仓设计，找出问题
尝试用维度建模方法重新设计一个业务主题
写一份数仓架构设计文档

这个阶段的难点#

难点	原因	突破方法
建模思维转变	习惯了面向需求开发	多看经典案例，思考设计原因
业务理解不够	只关注技术	主动了解业务，参与需求评审
技术选型困难	不了解各技术特点	实际对比测试，看官方文档
没有全局视角	之前只做局部	画出完整的数据流图

可胜任的岗位#

岗位名称	核心要求	薪资范围（参考）
数仓开发工程师（高级）	数仓设计、建模能力	20-35K
数据架构师（初级）	架构设计、技术选型	25-40K
数据平台工程师	平台架构、技术规划	25-40K

给这个阶段同学的建议#

做的事情#

多问为什么：每个设计决策背后都有原因
画架构图：用图来思考和表达
参与架构评审：学习他人如何做设计决策
阅读经典：Kimball 的书虽然老但很有价值

避免的事情#

只关注技术实现，忽略业务需求
追求复杂架构，忽略团队实际能力
不写文档，设计只在脑子里
不做取舍，想要所有优点

[!quote] 关键心态架构没有标准答案，只有在约束条件下的最优解。好的架构师是在各种权衡中找到平衡点。

下一阶段预告#

完成 L2 后，你可以进入 L3 架构设计 ↗，学习：

复杂数据架构设计
数据湖与湖仓一体
实时数仓架构
数据治理架构

数据架构师 L2:架构基础