分区策略

适用于：✅Azure 数据资源管理器

分区策略定义了是否应对特定表或具体化视图的范围（数据分片）进行分区以及如何进行分区。

策略会触发一个额外的后台过程，该过程在创建盘区之后，在数据引入之后执行。 此过程包括从源盘区重新引入数据并生成同类盘区，其中指定为分区键的列的所有值都驻留在单个分区内。

分区策略的主要目标是在支持的特定场景中增强查询性能。

支持的方案

下面是建议设置数据分区策略的唯一方案。 在所有其他情况下，不建议设置此策略。

• 中等或高基数 string 或 guid 列的常用筛选器：
  • 例如，多租户解决方案或指标表，其中的大多数查询或所有查询都会针对类型为 string 或 guid 的列（如 TenantId 或 MetricId）进行筛选。
  • 中等基数至少为 10,000 个非重复值。
  • 将哈希分区键设置为 string 或 guid 列，并将 PartitionAssignmentMode 属性设置为 uniform。
• 在高基数 string 或 guid 列上频繁聚合或联接：
  • 例如，来自许多不同传感器的 IoT 信息，或许多不同学生的学业记录。
  • 高基数是至少 1,000,000 个不同的值，其中，列中值的分布大致均匀。
  • 在这种情况下，请将哈希分区键设置为分组依据列或联接依据列，并将 PartitionAssignmentMode 属性设置为 ByPartition。
• 顺序外数据引入：
  • 引入到表中的数据可能不会按照特定的 datetime 列（表示数据创建时间，通常用于筛选数据）排序并划分成区（分片）。 这可能是由于来自异类源文件的回填，这些文件包含时间跨度很大的日期/时间值。
  • 在这种情况下，请将统一范围日期/时间分区键设置为 datetime 列。
  • 如果需要让保留和缓存策略与列中的日期/时间值一致，而不是与引入时间一致，请将 OverrideCreationTime 属性设置为 true。

分区键

支持以下类型的分区键。

哈希分区键

如果策略包括“哈希分区键”，属于同一分区的所有同类盘区将被分配到同一数据节点。

• 哈希取模函数用于对数据进行分区。
• 同类（已分区）盘区中的数据按哈希分区键排序。
  • 如果表上定义了哈希分区键，则不需要在行顺序策略中包含哈希分区键。
• 如果查询使用无序策略，并且按照此策略，join、summarize 或 make-series 中使用的 shuffle key 是表的哈希分区键，那么查询的性能将会更好，因为需要跨节点移动的数据量减少。

分区属性

哈希分区键示例

名为 tenant_id 的 string 类型列的哈希分区键。 它使用 XxHash64 哈希函数，并将 MaxPartitionCount 设置为建议的值 128，将默认值 Seed 设置为 1。

{
  "ColumnName": "tenant_id",
  "Kind": "Hash",
  "Properties": {
    "Function": "XxHash64",
    "MaxPartitionCount": 128,
    "Seed": 1,
    "PartitionAssignmentMode": "Uniform"
  }
}

统一范围日期/时间分区键

在这些情况下，你可以在区之间重新组织数据，以便每个区都包括有限时间范围的记录。 此过程会使 datetime 列上的筛选器在查询时更有效。

使用的分区函数是 bin_at()，该函数不可自定义。

分区属性

统一范围日期/时间分区示例

以下代码片段显示了针对名为 timestamp 的 datetime 类型列的统一日期/时间范围分区键。 它使用 datetime(2021-01-01) 作为其参考点，每个分区的大小为 7d，并且它不会替代区的创建时间。

{
  "ColumnName": "timestamp",
  "Kind": "UniformRange",
  "Properties": {
    "Reference": "2021-01-01T00:00:00",
    "RangeSize": "7.00:00:00",
    "OverrideCreationTime": false
  }
}

策略对象

表的数据分区策略默认为 null，在这种情况下，将不会在引入数据后对表中的数据进行分区。

数据分区策略具有以下主要属性：

• PartitionKeys：

  • 分区键的集合，用于定义如何对表中的数据进行分区。
  • 一个表最多可以有 2 个分区键，并有下列选项之一：
    • 一个哈希分区键。
    • 一个统一范围日期/时间分区键。
    • 一个哈希分区键和一个统一范围日期/时间分区键。
  • 每个分区键都具有以下属性：
    • ColumnName：string - 将根据其对数据进行分区的列的名称。
    • Kind：string - 要应用的数据分区类型（Hash 或 UniformRange）。
    • Properties：property bag -根据完成的分区定义参数。

• EffectiveDateTime：

  • 策略生效的 UTC 日期/时间。
  • 此属性是可选的。 如果未指定它，则策略将对应用了策略后引入的数据生效。

数据分区示例

具有两个分区键的数据分区策略对象。

1. 名为 tenant_id 的 string 类型列的哈希分区键。
   • 它使用 XxHash64 哈希函数，并将 MaxPartitionCount 设置为建议的值 128，将默认值 Seed 设置为 1。
2. 名为 timestamp 的 datetime 类型列的统一日期/时间范围分区键。
   • 它使用 datetime(2021-01-01) 作为参考点，每个分区的大小为 7d。

{
  "PartitionKeys": [
    {
      "ColumnName": "tenant_id",
      "Kind": "Hash",
      "Properties": {
        "Function": "XxHash64",
        "MaxPartitionCount": 128,
        "Seed": 1,
        "PartitionAssignmentMode": "Uniform"
      }
    },
    {
      "ColumnName": "timestamp",
      "Kind": "UniformRange",
      "Properties": {
        "Reference": "2021-01-01T00:00:00",
        "RangeSize": "7.00:00:00",
        "OverrideCreationTime": false
      }
    }
  ]
}

其他属性

可以将以下属性定义为策略的一部分。 这些属性是可选的，建议不要更改它们。

数据分区过程

• 数据分区作为引入后的后台进程运行。
  • 持续引入到的表应始终具有尚未分区的数据的“尾部”（非同类区）。
• 无论策略中 EffectiveDateTime 属性的值如何，数据分区只在热盘区上运行。
  • 如果需要对冷区进行分区，则需要临时调整缓存策略。

可以使用 .show database extents partitioning statistics 命令和分区指标监视数据库中具有已定义的策略的表的分区状态。

分区容量

• 数据分区过程会导致创建更多的盘区。 盘区合并容量可以逐渐增加，以便合并盘区的过程可以赶上进度。

• 如果有较高的引入吞吐量，或者有足够多的表定义了分区策略，则盘区分区容量可能会逐渐增加，以便分区盘区的过程可以保持。

::: moniker range = "azure-data-explorer"

• 为了避免消耗过多资源，对这些动态增加进行了限制。 如果它们全部耗尽，则可能需要逐渐线性地增加，以超过上限。
  • 如果增加容量会显著增加群集资源的使用，则可以手动或通过启用自动缩放来横向/纵向扩展群集。 ::: moniker-end

限制

• 在已具有 5,000,000 个以上区的数据库中对数据进行分区的尝试会受到限制。
  • 在这种情况下，数据库中表的分区策略的 EffectiveDateTime 属性将自动延迟几个小时，以便你可以重新评估配置和策略。

已分区列中的离群值

• 以下情况可能会导致节点上的数据分布不均衡，并降低查询性能：
  • 如果某个哈希分区键包含比其他值要普遍得多的值，例如，空字符串或泛型值（例如 null 或 N/A）。
  • 这些值表示在数据集中更为普遍的实体（例如 tenant_id）。
• 如果统一范围日期/时间分区键包含的大部分值与列中的大多数值“相差甚远”，则会增加数据分区进程的开销，并可能会导致需要跟踪多个盘区。 这种情况的一个示例是来自遥远的过去或未来的日期/时间值。

在这两种情况下，要么“修复”数据，要么在数据引入之前或引入时筛选掉数据中不相关的记录，以减少数据分区的开销。 例如，使用更新策略。

相关内容

• 分区策略管理命令