Partitioning ポリシー

適用対象: ✅Microsoft Fabric✅Azure データ エクスプローラー

パーティション分割ポリシーでは、特定のテーブルまたは具体化されたビューのエクステント (データ シャード) をパーティション分割するかどうか、およびその方法を定義します。

このポリシーは、データ インジェストに続いてエクステントの作成後に行われる追加のバックグラウンド プロセスをトリガーします。 このプロセスには、ソース・エクステントからのデータの再取り付けと、パーティション・キーとして指定された列のすべての値単一パーティション内に存在する同種エクステントの生成が含まれます。

パーティション分割ポリシーの主な目的は、特定の サポートされているシナリオでクエリのパフォーマンスを向上させることです。

サポートされるシナリオ

データ パーティション分割ポリシーを設定することが推奨されるのは次のシナリオだけです。 他のすべてのシナリオでは、このポリシーの設定は推奨されません。

• 中または高カーディナリティの string または guid 列に対する頻繁なフィルター:
  • たとえば、マルチテナント ソリューションや、ほとんどのクエリまたはすべてのクエリが string 型または guidの列 ( TenantId や MetricIdなど) でフィルター処理するメトリック テーブルです。
  • 中程度のカーディナリティは、少なくとも 10,000 個の異なる値です。
  • hash パーティション キーをstringまたはguid列に設定し、PartitionAssignmentMode プロパティをuniformに設定します。
• カーディナリティの高い string または guid 列での頻繁な集計または結合:
  • 例: さまざまなセンサーからの IoT 情報や、さまざまな学生の学業成績。
  • 高いカーディナリティは、少なくとも 1,000,000 個の異なる値であり、列の値の分布はほぼ均等です。
  • この場合、頻繁にグループ化または結合される列をハッシュ パーティション キーに設定し、PartitionAssignmentMode プロパティを ByPartition に設定します。
• 順序が誤ったデータ インジェスト:
  • データ作成時間を表し、データのフィルター処理によく使用される特定の datetime 列に基づいて、テーブルに取り込まれたデータが順序付けられてエクステント (シャード) に分割されない場合があります。 これは、長期間にわたる datetime 値を含む異種ソース ファイルからのバックフィルが原因である可能性があります。
  • この場合、datetime 列を均一範囲 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 パーティション キー

このような場合、各エクステントに限られた時間範囲のレコードが含まれるように、エクステント間でデータを再シャッフルすることができます。 このプロセスにより、クエリ時に datetime 列のフィルターがより効果的になります。

使用されるパーティション関数は bin_at() です。これはカスタマイズできません。

パーティションのプロパティ

均一範囲 datetime パーティションの例

このスニペットは、timestamp という名前 datetime 型の列に対する均一範囲 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 パーティション キーを持つことができます。
    • 1 つのハッシュ パーティション キー。
    • 1 つの均一範囲 datetime パーティション キー。
    • 1 つのハッシュ パーティション キーと 1 つの均一範囲 datetime パーティション キー。
  • 各パーティション キーには、次のプロパティがあります。
    • ColumnName: string - パーティション分割するデータに応じた列の名前。
    • Kind: string - 適用するデータ パーティション分割の種類 (Hash または UniformRange)。
    • Properties: property bag - 実行されるパーティション分割に応じてパラメーターを定義します。

• EffectiveDateTime:

  • ポリシーが有効になる UTC 日時。
  • このプロパティは省略可能です。 指定されていない場合は、ポリシーが適用された後に取り込まれたデータに対してポリシーが有効になります。

データ パーティション分割の例

2 つのパーティション キーを持つデータ パーティション分割ポリシー オブジェクト。

1. tenant_id という名前の string 型の列に対するハッシュ パーティション キー。
   • XxHash64 ハッシュ関数を使用し、MaxPartitionCount を推奨値の 128 に、Seed を既定値の 1 に設定しています。
2. timestamp という名前の datetime 型の列に対する均一範囲 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 データベース エクステントのパーティション分割統計コマンドとパーティション分割メトリックを使用して、データベース内のポリシーが定義されたテーブルのパーティション分割状態監視できます。

パーティション分割の容量

• データ パーティション分割プロセスにより、さらに多くのエクステントが作成されます。 マージ容量が徐々に増加する可能性があるため、エクステントをマージするプロセスが維持されます。

• インジェスト スループットが高い場合、またはパーティション分割ポリシーが定義されているテーブルの数が十分に多い場合は、 Extents パーティション容量 が徐々に増加する可能性があるため、エクステント パーティション分割のプロセス を維持できます。

::: モニカー範囲 = "azure-data-explorer"

• リソースが過剰に消費されるのを防ぐために、これらの動的な増加には上限が設定されています。 容量を完全に使い切った場合、上限を超えて徐々に直線的に増やすことが必要になる可能性があります。
  • 容量を増やしたことで、クラスターのリソースの使用量が大幅に増加した場合は、手動でまたは自動スケーリングを有効にして、クラスターをスケールアップ/アウトできます。 ::: moniker-end

制限事項

• エクステント数が既に 5,000,000 を超えているデータベースでは、データのパーティション分割の試行が抑制されます。
  • このような場合、データベース内のテーブルのパーティション 分割ポリシーの EffectiveDateTime プロパティは、構成とポリシーを再評価できるように、数時間の遅延が自動的に行われます。

パーティション分割された列の外れ値

• 次の状況は、ノード間でのデータの分散が不均衡になり、クエリのパフォーマンスが低下する可能性があります。
  • ハッシュ パーティション キーに、他の値よりもはるかに一般的な値 (たとえば、空の文字列や汎用値 (null や N/A など)) が含まれている場合。
  • 値は、データセットでより一般的なエンティティ ( tenant_id など) を表します。
• 均一範囲の datetime パーティション キーに、列の値の大部分から "遠い" 値が十分に大きい場合、データパーティション分割プロセスのオーバーヘッドが増加し、追跡するエクステントが多数になる可能性があります。 このような状況の例として、遠い過去または将来の datetime 値があります。

どちらの場合も、データを "修正" するか、インジェスト時またはインジェスト時にデータ内の無関係なレコードを除外して、データパーティション分割のオーバーヘッドを減らします。 たとえば、更新ポリシーを使用します。

関連するコンテンツ

• ポリシー管理コマンドのパーティション分割