如何在 Azure SQL 数据仓库中根据月份和年份进行分区答案

【问题标题】：How to partition based on the month and year in Azure SQL Data Warehouse如何在 Azure SQL 数据仓库中根据月份和年份进行分区
【发布时间】：2018-12-31 22:45:23
【问题描述】：

我将使用 ADF 将 50 亿行复制到 Azure SQL 数据仓库。默认情况下，Azure SQL DWH 会将表分配到 60 个分布中，但我想根据月份和年份再添加 50 个分区，如下所示：

PARTITION ( DateP  RANGE RIGHT FOR VALUES   
      (  
        '2015-01-01', 2015-02-01', ......2018-01-01','2018-02-01','2018-03-01','2018-04-01','2018-5-01',.......
        ))

但是，我用来对表进行分区的列包括日期和时间：

2015-01-01 00:30:00 您认为我的分区方法正确吗？

【问题讨论】：

标签： azure-sql-database azure-sqldw

【解决方案1】：

5B 行/（50 个分区 x 60 个分布）= 平均 170 万行/分区

这可能是太多的分区，但如果您有很多单月查询，那可能是值得的。加载后你肯定想defragment your columnstores。

【讨论】：

在我提出你的建议之前，我开始加载数据，我注意到加载 50 亿行可能需要几天的时间，但是，当我运行 select count(*) 时，它会向我显示例如，当前加载的数据现在是 56622406，但是当尝试查看每个分区中的行数时，它显示 56 个分区和每个分区 20 行，这有意义吗？
另外，仅供参考，我们的数据是一个时序表数据，我们希望每 30 分钟对其进行一次可视化，所以您还觉得 50 个分区太多了吗？

【解决方案2】：

我倾向于同意 David 的观点，即这对于分区的数量来说可能是多余的。您需要确保数据分布非常均匀，并且有 170 万行左右，您将处于较低的位置。您可能会迁移到基于季度的分区（例如，“2017-12-31”、“2018-03-01”、“2018-06-30”）以获得良好的查询性能结果。自 2015 年以来，这将为您每年提供 4 个分区（或总共 20 个）。所以数学是：

5B 行/（20 个分区 * 60 个分布）= 4.167M 行/分区。

虽然分区数量对于分区消除方案确实很重要，但这是一个带有列存储索引的事实表，它将在查询期间执行额外级别的索引段消除。过度分区会使情况变得更糟而不是更好。

【讨论】：

【解决方案3】：

Microsoft 的指南规定，在调整分区大小时，尤其是 Azure DW 中的列存储索引表，每个分区的最小卷必须是 6000 万行。任何更低的东西都可能不会提供最佳性能。其逻辑是，每个分区的每个分布必须至少有 1 M 行。由于创建的每个分区都会在内部创建 60 个额外的发行版，因此建议创建的每个分区的最小值为 60M

【讨论】：

欢迎。这是有用的指导。既然您将其归因于 Microsoft，您能否包含指向他们提供它的位置的链接？这将有助于使声明更具权威性。