1. 课程导入与Azure数据平台全景
欢迎进入《Azure云端数据仓库与商业分析工程》。在动手写第一行SQL、创建第一个存储账户之前，我们需要先建立一张"地图"：数据从业务系统产生，到最终变成管理层看到的报表和指标，中间要经过哪些环节？Azure提供了哪些服务来承担这些环节？团队里谁负责哪一段？只有把这张全景图看清楚，后面的学习才不会变成零散工具的堆砌。
一、这门课要解决什么问题
企业做数据分析，通常面临三类典型困境。第一类是"数据散"：订单在MySQL、用户行为在日志文件、财务数据在Excel、CRM在SaaS系统里，想做一个跨域分析，得先花两周做数据搬运。第二类是"口径乱"：同一个"活跃用户"，市场部、运营部、财务部各有一套算法，开会时数字对不上。第三类是"跑不动"：数据量从GB涨到TB后，原来在单机上跑得飞快的报表，现在要跑几个小时甚至直接失败。
Azure数据平台的价值，就是用云上的托管服务，把"采集—存储—加工—建模—服务—可视化"这条链路标准化、可扩展化。本课程的目标不是让你记住每个服务的按钮位置，而是让你具备三种能力：能设计——面对一个业务需求，能画出合理的数据架构；能实现——用Azure Synapse、Data Factory、Databricks等工具把链路搭起来；能治理——让数据可发现、可信任、可审计、成本可控。
二、核心概念：先分清四个层次
很多初学者会把"数据仓库""数据湖""湖仓一体""数据集市"混为一谈。我们用一句话区分：数据湖存原始、多样、未加工的数据，成本低、schema-on-read；数据仓库存经过清洗、建模、面向分析的结构化数据，schema-on-write，查询性能强；湖仓一体（Lakehouse）试图在数据湖的廉价存储上叠加事务、schema演进和性能优化，让一份数据同时服务BI和机器学习；数据集市则是面向某个部门或主题的、从仓库中裁剪出来的子集，比如"销售数据集市"。
在Azure上，这四层并不是四个孤立产品，而是可以由同一套存储（ADLS Gen2）加不同计算引擎组合出来的形态。理解这一点，是理解整个平台的关键。
三、Azure数据平台全景
下面这张图展示了从数据源到消费端的完整链路，以及各环节对应的Azure服务。请重点观察三个特征：数据是分层流动的（Bronze/Silver/Gold），计算是按需分离的（存储与计算解耦），治理是横切的（Purview贯穿始终）。
图中最值得注意的是"存储与分层"这一列。Bronze层保留原始格式，不做任何修改，目的是可追溯、可重放；Silver层做清洗、去重、类型转换、标准化，是"可信数据"的起点；Gold层按维度建模（星型或雪花），直接面向BI和指标计算。这种分层不是Azure的强制要求，而是数据工程领域经过大量实践总结出的最佳模式，它让每一层职责单一，出问题时能快速定位是"采集错了"还是"转换错了"还是"建模错了"。
四、典型应用场景
Azure数据平台能覆盖的场景很广，但入门阶段建议先理解三类最典型的：
- 企业级BI报表：把ERP、CRM、财务系统的数据每天批量同步到Synapse，建模后供Power BI做管理驾驶舱。特点是数据量大、时效性要求T+1、口径必须统一。
- 实时运营监控：通过Event Hubs接收订单流或设备遥测，Stream Analytics做窗口聚合，结果写入Power BI实时数据集，运营人员看到分钟级延迟的看板。特点是低延迟、高吞吐、允许近似结果。
- 数据科学与机器学习：在Databricks里用Spark读取Silver层数据做特征工程，训练模型后把评分结果写回Gold层，供业务系统调用。特点是需要探索性分析、对schema灵活性要求高。
这三类场景对架构的要求不同：BI报表重建模和一致性，实时监控重吞吐和延迟，机器学习重灵活性和计算密度。但它们的底层存储可以共用同一套ADLS Gen2，只是目录结构和文件格式不同。这就是"一份存储、多种计算"的价值。
五、角色分工：谁做什么
一个完整的数据平台团队通常包含以下角色，理解分工有助于你在实际项目中找到自己的位置：
| 角色 | 核心职责 | 常用工具 |
|---|---|---|
| 数据工程师 | 搭建采集管道、维护分层存储、编写转换逻辑、保障数据按时产出 | Data Factory、Synapse、Databricks、SQL |
| 数据分析师 | 理解业务口径、设计指标、建模、制作报表和仪表板 | Power BI、DAX、Synapse SQL |
| 数据科学家 | 特征工程、模型训练、评估、部署推理 | Databricks、Azure ML、Python |
| 数据治理/管理员 | 数据目录、血缘、权限、安全策略、成本监控 | Purview、Azure RBAC、Cost Management |