你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Tip
Microsoft Fabric Data Warehouse是数据湖基础上的企业规模关系仓库，具有未来就绪的体系结构、内置 AI 和新功能。 如果不熟悉数据仓库，请从Fabric Data Warehouse开始。 现有的指定 SQL 池工作负荷可以升级到 Fabric，以跨数据科学、实时分析和报告访问新功能。
此备忘单提供了有关生成专用 SQL 池（前 SQL DW）解决方案的有用提示和最佳做法。
下图显示了使用专用 SQL 池（以前为 SQL DW）设计数据仓库的过程：
跨表的查询和操作
提前知道要在数据仓库中运行的主要操作和查询时，可以为这些操作确定数据仓库体系结构的优先级。 这些查询和操作可能包括：
- 将一个或两个事实表与维度表联接，筛选出组合表的结果，然后将其追加到数据集市中。
- 对您的销售数据进行大规模或小规模的更新。
- 仅向表追加数据。
提前了解操作类型有助于优化表的设计。
数据迁移
首先，将数据加载到 Azure Data Lake Storage 或 Azure Blob 存储。 接下来，使用 COPY 语句 将数据加载到临时表中。 使用以下配置：
| 设计 | 建议 |
|---|---|
| 分发 | 循环 |
| 索引 | 堆 |
| 分区 | None |
| 资源类 | largerc 或 xlargerc |
详细了解 数据迁移、 数据加载以及 提取、加载和转换（ELT）过程。
分布式表或复制表
根据表属性，使用以下策略：
| 类型 | 非常适合... | 注意... |
|---|---|---|
| 复制备份 | * 压缩后存储小于 2 GB 的星型架构中的小型维度表（约 5 倍压缩） | * 许多写入事务都在表上（例如插入、更新插入、删除、更新） * 经常更改数据仓库单位（DWU）的预配 * 仅使用 2-3 列，但表包含许多列 * 为复制的表编制索引 |
| 轮循机制 （默认值） | * 临时/中间表 * 没有明显的联接键或良好的候选列 |
* 由于数据移动，性能缓慢 |
| 哈希 | * 事实数据表 * 大型维度表 |
* 无法更新分发密钥 |
提示：
- 从轮循分配开始，然后寻求通过哈希分布策略来实现大规模并行体系结构的优势。
- 确保通用哈希键具有相同的数据格式。
- 不要在 varchar 格式上分发。
- 具有公共哈希键的维度表可以进行哈希分布，以便与事实表高效地进行频繁的联接操作。
- 使用 sys.dm_pdw_nodes_db_partition_stats 分析数据中的任何偏差。
- 使用 sys.dm_pdw_request_steps 来分析查询背后的数据移动，监视广播所用时间以及洗牌操作所需的时间。 这有助于审查您的分发策略。
为表编制索引
索引有助于快速读取表。 可以根据需求使用一组独特的技术：
| 类型 | 非常适合... | 注意... |
|---|---|---|
| 堆 | * 暂存/临时表 * 具有小型查找的小型表 |
任何查找操作都涉及扫描完整的表。 |
| 聚集索引 | * 最多包含 1 亿行的表 * 大型表（超过 1 亿行），主要使用 1-2 列 |
* 在复制的表上使用 * 有复杂查询，涉及多个联接和分组操作 * 对索引列进行更新：它占用内存 |
| 聚集列存储索引 （CCI） （默认值） | * 大型表（超过 1 亿行） | * 在复制的表上使用 * 对表执行大规模更新操作 * 对表进行过度分区：行组不会跨越不同的分布节点和分区 |
提示：
- 在聚集索引之上，你可能想要将一个非聚集索引添加到经常用于筛选的列。
- 请注意如何使用 CCI 管理表上的内存。 加载数据时，希望用户（或查询）受益于大型资源类。 请确保避免剪裁和创建许多小型压缩行组。
- 在 Gen2 上，CCI 表在本地缓存在计算节点上，以最大程度地提高性能。
- 对于 CCI，由于行组的压缩效率不佳，性能可能会变慢。 如果发生这种情况，请重新构建或重新组织您的 CCI。 每个压缩行组至少需要 100,000 行。 理想情况是每个行组中有 100 万行。
- 根据增量加载的频率和大小，您希望在需要重新组织或重建索引时，实现自动化操作。 春天的清洁总是有帮助的。
- 如果要剪裁行组，请保持战略性。 这些开放的行组有多大？ 预计在未来几天内加载多少数据？
详细了解 索引。
分区
如果拥有大型事实数据表（超过 10 亿行），则可以对表进行分区。 在 99% 的情况下，分区键应基于日期。
使用需要 ELT 的暂存表，可以通过分区获益。 它有助于进行数据生命周期管理。 请注意不要过度分区事实表或暂存表，尤其是在聚集列存储索引上。
详细了解 分区。
增量加载
如果要以增量方式加载数据，请先确保分配更大的资源类来加载数据。 当加载到具有聚集列存储索引的表中时，这一点尤其重要。 有关更多详细信息 ，请参阅资源类 。
建议使用 PolyBase 和 ADF V2 将 ELT 管道自动化到数据仓库。
对于历史数据中的大量更新，请考虑使用 CTAS 写入要保留在表中的数据，而不是使用 INSERT、UPDATE 和 DELETE。
维护统计信息
更新统计信息非常重要，因为数据发生了 重大 更改。 请参阅 更新统计信息 以确定是否发生了 重大 更改。 更新的统计信息优化了查询计划。 如果发现维护所有统计信息需要很长时间，请更选择性地选择哪些列具有统计信息。
还可以定义更新的频率。 例如，你可能想要更新每天可能会添加新值的日期列。 通过收集联接中涉及的列、WHERE 子句中使用的列以及 GROUP BY 中找到的列的统计信息，可以获得最大的好处。
详细了解 统计信息。
资源类
资源组用作将内存分配给查询的方法。 如果需要更多内存来提高查询或加载速度，则应分配更高的资源类。 另一方面，使用更大的资源类别会影响并发。 在将所有用户移动到大型资源类之前，需要考虑到这一点。
如果发现查询耗时太长，请检查用户是否未在大型资源类中运行。 大规模资源类消耗许多并发插槽。 它们可能会导致其他查询排队。
最后，通过使用 专用 SQL 池（以前为 SQL DW）的 Gen2，每个资源类的内存比 Gen1 多 2.5 倍。
详细了解如何使用 资源类和并发。
降低成本
Azure Synapse的主要功能是能够管理计算资源。 如果不使用它，则可以暂停专用 SQL 池（以前为 SQL DW），这会停止计算资源的计费。 可以缩放资源以满足性能需求。 若要暂停，请使用 Azure 门户或 PowerShell。 若要缩放，请使用 Azure portal、PowerShell、T-SQL 或 REST API。
现在您可以在想要的时间使用 Azure Functions 进行自动缩放。
优化您的架构以提升性能
建议在中心辐射型体系结构中考虑使用 SQL 数据库和 Azure Analysis Services。 此解决方案可以在不同的用户组之间提供工作负荷隔离，同时使用 SQL 数据库和Azure Analysis Services的高级安全功能。 这也是向用户提供无限并发的一种方法。
详细了解典型体系结构，这些体系结构利用 Azure Synapse Analytics 中的专用 SQL 池（以前为 SQL DW）。
从专用 SQL 池（以前为 SQL DW）在 SQL 数据库中部署分支：