2. SQL Server数据仓库架构设计

数据仓库架构设计不是画一张漂亮的框图，而是决定数据从源系统进入平台后，在哪些层停留、以什么形态存储、被谁消费、如何保证可追溯。在 SQL Server 技术栈中，这一决策直接影响 ETL 复杂度、查询性能、存储成本和后续扩展能力。本节围绕分层架构、建模选型、数据流设计和技术版本对比四个核心问题展开。

一、分层架构：ODS、DW、DM 的职责边界

SQL Server 数据仓库通常采用三层结构：ODS（Operational Data Store，操作数据存储层）、DW（Data Warehouse，数据仓库层）和 DM（Data Mart，数据集市层）。三层的核心区别不在于物理数据库数量，而在于数据形态和服务对象。

ODS 层贴近源系统，保留原始或轻度清洗后的数据。它的表结构通常与源系统表一一对应，字段类型尽量不做有损转换，加载方式以批量抽取为主。ODS 的价值在于“可重放”：当 DW 层逻辑变更时，可以从 ODS 重新加工，而不必反复回源。在 SQL Server 中，ODS 常放在独立数据库（如 ODS_Sales）中，使用 BULK INSERT 或 SSIS 快速加载，并保留 ETL_BatchID、LoadTime 等审计字段。

DW 层是整合后的企业级数据视图，承担一致性维度、事实表和缓慢变化维的处理。它面向主题域组织，例如销售、库存、财务，而不是照搬源系统结构。DW 层通常采用维度建模，强调可查询性和业务可理解性。

DM 层面向具体部门或分析场景，从 DW 层裁剪、聚合或透视而来。例如销售部门需要“按区域、按月的销售额”，DM 层可以预聚合为 DM_Sales_Monthly，减少报表查询扫描的数据量。DM 层不是必须独立成库，也可以在同一数据库中用 Schema 隔离，如 dm.SalesMonthly。

二、维度建模与范式建模的选型

维度建模（Kimball 风格）和范式建模（Inmon 风格）是两种主流路线。维度建模以星型或雪花模型为核心，事实表存储度量值，维度表存储描述性属性，适合 BI 查询和聚合分析。范式建模以第三范式（3NF）为目标，强调数据一致性和最小冗余，适合作为企业级集成层。

在 SQL Server 数据仓库中，常见做法是“DW 层用维度建模，ODS 层用准范式”。原因在于：ODS 层需要快速加载和保留源结构，范式化可以减少写入冲突；DW 层需要支撑多维分析，星型模型让查询计划更简单，SQL Server 的列存储索引（Columnstore Index）在星型模型上压缩率和扫描性能都更优。

选型判断可以看三个维度：查询模式——如果以聚合、切片、钻取为主，选维度建模；数据变更频率——如果源系统频繁更新且需要保留历史，维度建模的 SCD 机制更成熟；团队能力——维度建模对业务理解要求高，范式建模对数据建模功底要求高。实际项目中，两者并非互斥，可以在 DW 层用维度建模，在 ODS 层用范式化暂存。

三、数据流设计：从抽取到消费的链路

数据流设计的核心是确定“谁在什么时候、以什么方式、把什么数据、写到哪里”。在 SQL Server 中，典型链路为：源系统 → SSIS/存储过程抽取 → ODS 暂存 → 清洗转换 → DW 加载 → DM 聚合 → 消费端。

以销售主题为例，假设源系统每天凌晨 1:00 完成日结。数据流可以设计为：

-- ODS 层增量抽取示例（按日期增量）
INSERT INTO ODS_Sales.OrderDetail
SELECT OrderID, ProductID, Qty, Amount, OrderDate, GETDATE() AS LoadTime, @BatchID AS ETL_BatchID
FROM SourceDB.dbo.OrderDetail
WHERE OrderDate = @BusinessDate;

-- DW 层事实表加载（先查维度代理键，再插入事实）
INSERT INTO DW.FactSales (DateKey, ProductKey, CustomerKey, Qty, Amount)
SELECT d.DateKey, p.ProductKey, c.CustomerKey, o.Qty, o.Amount
FROM ODS_Sales.OrderDetail o
JOIN DW.DimDate d ON o.OrderDate = d.FullDate
JOIN DW.DimProduct p ON o.ProductID = p.ProductID AND p.IsCurrent = 1
JOIN DW.DimCustomer c ON o.CustomerID = c.CustomerID AND c.IsCurrent = 1
WHERE o.ETL_BatchID = @BatchID;

数据流设计需要明确三个关键点：增量策略——按时间戳、按自增 ID 还是按 CDC（变更数据捕获）；加载顺序——维度表先于事实表，避免事实表外键找不到对应维度；失败恢复——每个批次用 ETL_BatchID 标记，失败时可按批次回滚或重跑，而不是全量重做。

四、技术选型与版本对比

SQL Server 不同版本对数据仓库的支持差异明显。企业版支持列存储索引、分区表、AlwaysOn 可用性组、内存优化表等关键特性；标准版在数据量较大时可能成为瓶颈。以下对比基于常见版本能力，具体以实际授权版本为准。

选型建议：如果数据量在 TB 级以内、并发查询不高，标准版配合列存储索引可以满足；如果事实表超过数亿行、需要分区切换和 AlwaysOn 只读副本，企业版是必要选择。SQL Server 2022 在智能查询处理和外部数据虚拟化方面提升明显，适合已有 Azure 或混合云场景。对于纯本地部署且预算有限的项目，2019 企业版仍是成熟稳定的选择。

综合来看，SQL Server 数据仓库架构设计的关键决策顺序是：先确定 ODS/DW/DM 的职责边界和部署方式，再根据查询模式选择维度建模或范式建模，然后设计增量抽取、维度加载和事实加载的数据流，最后结合数据量、并发和预算选择版本。四个环节相互制约，任何一层设计不当都会在后续 ETL 或查询阶段放大为性能问题。