共用方式為

資料分割原則

  • 發行項

適用於： ✅Microsoft網狀架構✅Azure 數據總管

數據分割原則會定義特定數據表或具體化檢視應分割範圍（數據分區）的是否和方式。

原則會觸發在建立範圍之後發生的其他背景程式，並遵循數據擷取。 此程式包括從來源範圍重新擷取數據，併產生 同質 範圍，其中指定為 數據分割索引鍵 的數據行的所有值都位於單一數據分割內。

數據分割原則的主要目標是在特定支援的案例中增強查詢效能。

注意

根據預設，如果未定義數據分割原則（是 null），範圍會依建立時間進行分割（擷取）。 在大部分情況下，不需要設定數據分割原則。

支援的案例

以下是建議設定數據分割原則的唯一案例。 在所有其他案例中，不建議設定原則。

  • 中高基數 string 或 guid 數據行的常用篩選：
    • 例如：多租使用者解決方案，或計量數據表，其中大部分或所有查詢都會篩選類型stringguid或的數據行，例如 TenantId 或 MetricId。
    • 中基數至少為 10,000 個相異值。
    • 將哈希分割區索引鍵設定為 string 或 guid 資料行，並將 屬性設定PartitionAssignmentMode為 uniform。
  • 高基數string或數據行上的頻繁匯總或guid聯結：
    • 例如，來自許多不同的感測器的IoT資訊，或許多不同學生的學術記錄。
    • 高基數至少為1,000,000個相異值，其中數據行中的值分佈大約是偶數。
    • 在這裡情況下，請將哈希分割區索引鍵設定為經常分組或聯結的數據行，並將 屬性設定PartitionAssignmentMode為 ByPartition。
  • 順序不依序的數據擷取：
    • 根據代表數據建立時間的特定 datetime 數據行，數據擷取到數據表中可能不會排序並分割成範圍（分區），而且通常用來篩選數據。 這可能是因為異質來源檔案的回填，其中包含大型時間範圍中的日期時間值。
    • 在此情況下，請將統一範圍 datetime 數據 分割索引鍵 設定為 datetime 數據行。
    • 如果您需要保留和快取原則以配合數據行中的 datetime 值，而不是與擷取的時間對齊，請將 OverrideCreationTime 屬性設定為 true。

警告

  • 定義數據分割原則的數據表數目上沒有硬式編碼的限制。 但是，每個額外的數據表都會增加背景數據分割程序的額外負荷。 在更多數據表上設定原則會導致使用更多資源，以及基礎記憶體交易的成本較高。 如需詳細資訊，請參閱 容量。
  • 如果每個分割區的數據壓縮大小預期小於 1 GB，則不建議設定數據分割原則。
  • 數據分割程式會導致分割處理期間和合併程序期間所取代之所有範圍的剩餘儲存成品。 大部分剩餘的記憶體成品預期會在自動清除程式期間刪除。 增加 屬性的值 MaxPartitionCount 會增加剩餘儲存成品的數目，並減少清除效能。
  • 在具體化檢視上套用數據分割原則之前，請先檢閱具體化檢視分割原則的建議。

分割區索引鍵

支援下列類型的分割區索引鍵。

種類 資料行類型 數據分割屬性 數據分割值
雜湊 string 或 guid Function、 、 MaxPartitionCount、 SeedPartitionAssignmentMode Function（ColumnName、 、 SeedMaxPartitionCount）
統一範圍 datetime RangeSize、 、 ReferenceOverrideCreationTime bin_at（ColumnName、 、 ReferenceRangeSize）

哈希分割區索引鍵

如果原則包含哈希分割區索引鍵，則屬於相同數據分割的所有同質範圍都會指派給相同的數據節點。

注意

數據分割作業會增加大量的處理負載。 我們建議只在下列情況下，才在數據表上套用哈希分割區索引鍵：

  • 如果大部分的查詢都使用相等篩選條件 （==， ， 。 in()
  • 類型或大型維度（基數為10M或更高版本）的特定數據行string guid 上，大部分查詢會匯總/聯結，例如 device_ID或。user_ID
  • 數據分割數據表的使用模式處於高並行查詢負載，例如監視或儀錶板應用程式中。
  • 哈希模數函式可用來分割數據。
  • 同質 （分割） 範圍中的數據會依哈希分割索引鍵排序。
  • 使用隨機策略的查詢，以及 shuffle key 中 summarize join所使用的 ，或 make-series 是數據表的哈希分割索引鍵，預期會執行得更好，因為減少跨節點移動所需的數據量。

數據分割屬性

屬性 說明 支援的值（秒） 建議值
Function 要使用的hash-modulo函式名稱。 XxHash64
MaxPartitionCount 要建立的數據分割數目上限（哈希模數函式的模數自變數）。 在範圍 (1,2048]中。 較高的值會導致數據分割程序的額外負荷，以及每個時間週期的較高範圍數目。 建議值是 128。 較高的值會大幅增加分割數據后擷取數據的額外負荷，以及元數據的大小，因此不建議使用。
Seed 用於隨機化哈希值。 正整數。 1，這也是預設值。
PartitionAssignmentMode 用於將分割區指派給節點的模式。 ByPartition：屬於相同分割區的所有同質（分割）範圍都會指派給相同的節點。
Uniform：忽略範圍的數據分割值。 範圍會統一指派給節點。		 如果查詢未聯結或匯總哈希分割索引鍵，請使用 Uniform。 否則，請使用 ByPartition。

哈希分割區索引鍵範例

在名為tenant_id的型別數據行上string哈希分割索引鍵。 它會使用XxHash64哈希函式，並將 MaxPartitionCount 設定為建議的值128，以及的預設值Seed1。

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

統一範圍日期時間分割索引鍵

注意

只有在將數據擷取到數據表的數據不太可能根據此數據行排序時，才會對 datetime數據表中具類型的數據行套用統一範圍 datetime 數據分割索引鍵。

在這些情況下，您可以重新調整範圍之間的數據，讓每個範圍都包含來自有限時間範圍的記錄。 此程式會導致數據行的 datetime 篩選在查詢時更有效率。

所使用的分割區函式bin_at （） 且無法自定義。

數據分割屬性

屬性 說明 建議值
RangeSize timespan純量常數，表示每個日期時間分割區的大小。 從值 1.00:00:00 （一天） 開始。 請勿設定較短的值，因為它可能會導致數據表具有無法合併的大量小範圍。
Reference datetime純量常數，表示固定時間點，根據日期時間數據分割的對齊方式。 請從 1970-01-01 00:00:00 開始。 如果有記錄顯示 datetime 數據分割索引鍵具有 null 值，其數據分割值會設定為的值 Reference。
OverrideCreationTime ， bool 指出是否應該由分割區索引鍵中的值範圍覆寫結果範圍的最小值和最大建立時間。 預設為 false。 true如果資料未依抵達時間順序內嵌，則設定為 。 例如，單一來源檔案可能包含遙遠的日期時間值，而且/或您可能想要根據日期時間值強制執行保留或快取，而不是擷取時間。

當 設定為 true時OverrideCreationTime，合併程式中可能會遺漏範圍。 如果建立時間早於 Lookback 數據表 的 Extents 合併原則期間，就會遺漏範圍。 若要確定可探索範圍，請將 屬性設定 Lookback 為 HotCache。

統一範圍日期時間分割範例

代碼段會在名為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 區索引鍵，且有下列其中一個選項：
    • 每個分割區索引鍵都有下列屬性：
      • ColumnName： string - 資料分割依據的數據行名稱。
      • Kind： string - 要套用的數據分割種類（Hash 或 UniformRange）。
      • Properties： property bag - 根據資料分割的完成方式定義參數。

  • EffectiveDateTime：

    • 原則生效的 UTC 日期時間。
    • 這個屬性為選擇性。 如果未指定，原則將會在套用原則之後，對內嵌的數據生效。

警告

  • 您可以在過去設定日期時間值，並分割已內嵌的數據。 不過，這種做法可能會大幅增加數據分割程式中使用的資源。
  • 在大部分情況下，建議只分割新擷取的數據，並避免分割大量的歷程記錄數據。
  • 如果您選擇分割歷程記錄數據，請考慮逐步執行此動作，方法是將 EffectiveDateTime 設定為在每次變更原則時最多幾天的步驟中的先前datetime步驟。

數據分割範例

具有兩個數據分割索引鍵的數據分割原則物件。

  1. 在名為tenant_id的型別數據行上string哈希分割索引鍵。
    • 它會使用XxHash64哈希函式，並將 MaxPartitionCount 設定為建議的值128，以及的預設值Seed1。
  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
      }
    }
  ]
}

其他屬性

下列屬性可以定義為原則的一部分。 這些屬性是選擇性的，建議您不要變更它們。

屬性 說明 建議值 預設值
MinRowCountPerOperation 單一數據分割作業之來源範圍數據列計數總和的最低目標。 0
MaxRowCountPerOperation 單一數據分割作業之來源範圍數據列計數總和的最大目標。 如果您看到分割作業耗用大量記憶體或每個作業的CPU，請設定小於5M的值。 0，默認目標為 5,000,000 筆記錄。
MaxOriginalSizePerOperation 單一數據分割作業之來源範圍原始大小 （以位元組為單位） 總和的最大目標。 如果分割作業耗用大量記憶體或每個作業的CPU，請設定小於5 GB的值。 0，默認目標為 5,368,709,120 個字節（5 GB）。

數據分割程式

  • 數據分割會以擷取後背景進程的形式執行。
    • 持續擷取到的數據表，預期一律會有尚未分割的數據「尾端」（非同質範圍）。
  • 數據分割只會在經常性範圍上執行，不論 EffectiveDateTime 原則中的 屬性值為何。
    • 如果需要分割冷範圍，您必須暫時調整 快取原則。

您可以使用 .show 資料庫範圍分割統計數據命令和數據分割計量，來監視資料庫中已定義原則之數據表的數據分割狀態。

數據分割容量

  • 數據分割程式會導致建立更多範圍。 範圍合併容量可能會逐漸增加，以便合併範圍的程式可以跟上。

  • 如果有高擷取輸送量，或已定義數據分割原則的足夠數目數據表，則 Extents分割區容量 可能會逐漸增加，以便 分割範圍 的程式可以跟上。

：：： moniker range = “azure-data-explorer”

  • 為了避免耗用太多資源，系統會限制這些動態增加。 如果完全用盡，您可能需要逐漸且線性地增加超過上限。
    • 如果增加容量會導致使用叢集的資源大幅增加，您可以手動相應放大/叢集，或啟用自動調整。 ：：： moniker-end

限制

  • 嘗試分割資料庫中已經超過5,000,000個範圍的數據將會受到節流。
    • 在這種情況下， EffectiveDateTime 資料庫中數據表的數據分割原則屬性會自動延遲數小時，以便重新評估設定和原則。

分割數據行中的極端值

  • 下列情況有助於跨節點分佈數據不平衡，並降低查詢效能：
    • 如果哈希分割索引鍵包含的值比其他值更普遍，例如空字串或泛型值（例如 null 或 N/A）。
    • 這些值代表數據集中較普遍的實體（例如 tenant_id）。
  • 如果統一範圍 datetime 數據分割索引鍵具有與數據行中大部分值「很遠」的足夠百分比，數據分割程式的額外負荷就會增加，而且可能會導致許多小範圍追蹤。 這類情況的範例是來自遙遠過去或未來的日期時間值。

在這兩種情況下，請「修正」數據，或在擷取時間篩選出數據中的任何不相關記錄，以減少數據分割的額外負荷。 例如，使用 更新原則。

相關內容