📚 课程目录第2章 Azure数据仓库架构设计

2. Azure数据仓库架构设计

在Azure上做数据仓库，最容易犯的错误是“先选服务，再想需求”。很多团队一上来就问“用Dedicated SQL Pool还是Serverless SQL Pool”，但真正决定架构的，是数据规模、查询模式、并发要求、延迟容忍度和成本约束这五个业务变量。Synapse Analytics并不是一个单一产品，而是一个把Dedicated SQL Pool、Serverless SQL Pool、Spark Pool和Data Lake打通的统一工作区。理解它们各自的定位与组合方式，才是架构设计的核心。

四个核心组件的定位差异

先明确每个组件“擅长什么、不擅长什么”。Dedicated SQL Pool是预置的MPP（大规模并行处理）关系型引擎，数据以60个分布（Distribution）为单位物理存储，计算与存储分离但计算资源常驻。它适合高并发、低延迟、可预测的BI报表和维度建模场景，代价是即使空闲也按DWU计费。Serverless SQL Pool没有常驻计算资源，直接对Data Lake中的Parquet、CSV、JSON文件执行T-SQL查询，按扫描的数据量计费。它适合探索性分析、一次性ETL、数据探查和低频查询，但不适合高并发和复杂多表关联。Data Lake Storage Gen2是分层命名空间的廉价对象存储，承担原始数据、清洗后数据和归档数据的持久化。Spark Pool负责大规模数据转换、复杂清洗和非结构化处理，通常与Data Lake配合完成从原始层到精炼层的加工。

关键判断逻辑是：如果查询需要秒级响应、并发用户超过几十个、且数据模型相对稳定，选Dedicated SQL Pool；如果只是偶尔查一批Parquet文件、或者做数据质量探查，Serverless SQL Pool更经济；如果转换逻辑复杂、涉及嵌套JSON或机器学习特征工程，用Spark Pool。

从业务需求推导架构的决策路径

假设一个零售企业要建设销售分析平台，日均新增订单数据约200GB，历史数据累计50TB，业务方要求：管理层看板刷新延迟不超过5分钟，区域经理可自助查询近3年明细，数据科学团队需要做客户流失预测。这个场景不能只用一种引擎解决。

合理的组合是：Data Lake Gen2作为统一存储底座，Raw层存放从POS系统和电商平台抽取的原始JSON和CSV；Spark Pool每天凌晨执行清洗作业，把Raw层数据转换为Parquet格式写入Curated层，同时完成去重、空值填充、维度关联和缓慢变化维处理；Dedicated SQL Pool从Curated层加载事实表和维度表，建立星型模型，支撑Power BI看板的秒级查询；Serverless SQL Pool则面向数据科学团队，直接用OPENROWSET查询Curated层的Parquet文件，做特征探索和样本抽取，避免把探索性负载压到Dedicated SQL Pool上。

这里有一个重要的成本判断：如果区域经理的自助查询频率不高（比如每天几十次），完全可以用Serverless SQL Pool替代Dedicated SQL Pool来服务这部分需求，按扫描量计费可能比常驻DWU便宜一个数量级。但如果并发查询超过50个且要求亚秒级响应，Serverless的排队和冷启动就会成为瓶颈。

分布策略与分区设计

Dedicated SQL Pool的性能很大程度上取决于分布键的选择。Synapse提供三种分布方式：HASH按指定列哈希到60个分布，适合大事实表；ROUND_ROBIN轮询均匀分布，适合无明确关联键的中间表；REPLICATE在每个计算节点保留完整副本，适合小维度表。选择HASH分布键的原则是：优先选参与JOIN最多的列、基数高且分布均匀的列。例如订单事实表用CustomerID做HASH分布，客户维度表用REPLICATE，这样订单与客户的关联可以在本地完成，避免数据移动。

分区方面，按日期对事实表做分区可以显著提升查询性能并简化数据管理。例如按OrderDate做RANGE RIGHT分区，每月一个分区，配合分区切换（Partition Switching）实现快速数据加载和归档。需要注意的是，分区列应与常用过滤条件一致，否则分区裁剪无法生效。

在Synapse中，Dedicated SQL Pool的分布键一旦选定，修改需要重建表。建议在架构设计阶段就用真实数据分布做验证，而不是等到上线后才发现数据倾斜。

一个可参考的架构决策表

业务需求特征	推荐引擎	关键理由
高并发BI看板，响应<3秒	Dedicated SQL Pool	预置MPP资源，并发隔离好
低频探索性查询，数据在Data Lake	Serverless SQL Pool	按扫描量计费，无需预置
复杂JSON清洗、ML特征工程	Spark Pool	分布式内存计算，支持嵌套结构
原始数据持久化与分层存储	Data Lake Gen2	低成本、分层命名空间、多引擎共享
跨源数据集成与调度	Synapse Pipelines	与工作区原生集成，支持参数化

架构落地时的三个实操要点

第一，存储格式统一为Parquet。Serverless SQL Pool和Spark Pool对Parquet的读取效率远高于CSV，且Parquet自带列式压缩和Schema信息，能减少扫描量和类型推断错误。Raw层可以保留原始格式，但Curated层和Serving层应统一为Parquet或Delta Lake格式。

第二，用外部表打通引擎边界。在Serverless SQL Pool中创建指向Curated层Parquet文件的外部表，Dedicated SQL Pool通过PolyBase或COPY INTO从同一位置加载数据。这样Data Lake成为单一事实来源，避免数据在多个引擎间重复拷贝。

第三，监控数据倾斜和查询等待。Dedicated SQL Pool中可以用sys.dm_pdw_nodes_db_partition_stats查看各分布的行数差异，如果最大分布与最小分布行数比超过2:1，说明分布键选择有问题。Serverless SQL Pool则要关注扫描数据量，避免全表扫描导致费用失控。

-- 检查Dedicated SQL Pool分布倾斜（示例查询）
SELECT
    distribution_id,
    COUNT(*) AS row_count
FROM sys.dm_pdw_nodes_db_partition_stats
WHERE object_id = OBJECT_ID('dbo.FactSales')
GROUP BY distribution_id
ORDER BY row_count DESC;

-- Serverless SQL Pool读取Parquet示例
SELECT TOP 100 *
FROM OPENROWSET(
    BULK 'https://mydatalake.dfs.core.windows.net/curated/sales/*.parquet',
    FORMAT = 'PARQUET'
) AS sales
WHERE OrderDate >= '2024-01-01';

架构设计不是一次性的选择题，而是随着数据量、并发量和业务需求变化持续调整的过程。初期可以用Serverless SQL Pool快速验证，数据量和并发上来后再迁移到Dedicated SQL Pool；Spark Pool的作业可以按需启停，不必常驻。理解每个组件的计费模型和性能边界，才能在成本与体验之间找到平衡点。