Condividi tramite

Criterio partitioning

  • Articolo

Si applica a: ✅Microsoft Fabric✅Azure Esplora dati

I criteri di partizionamento definiscono se e come devono essere partizionati gli extent (partizioni di dati) per una tabella specifica o una vista materializzata.

Il criterio attiva un processo in background aggiuntivo che viene eseguito dopo la creazione di extent, dopo l'inserimento dei dati. Questo processo include la ripetizione dei dati dagli extent di origine e la produzione di extent omogenei , in cui tutti i valori della colonna designata come chiave di partizione si trovano all'interno di una singola partizione.

L'obiettivo principale dei criteri di partizionamento è migliorare le prestazioni delle query in scenari supportati specifici.

Nota

Per impostazione predefinita, quando un criterio di partizionamento dei dati non è definito (è null), gli extent vengono partizionati in base al momento della creazione (inserimento). Nella maggior parte dei casi non è necessario impostare un criterio di partizionamento dei dati.

Scenari supportati

Di seguito sono riportati gli unici scenari in cui è consigliabile impostare un criterio di partizionamento dei dati. In tutti gli altri scenari, l'impostazione del criterio non è consigliata.

  • Filtri frequenti su una colonna o una cardinalità string media oguid alta:
  • Aggregazioni frequenti o join in una colonna o guid cardinalità string elevata:
  • Inserimento dati non ordinato:
    • I dati inseriti in una tabella potrebbero non essere ordinati e partizionati in extent (partizioni) in base a una colonna specifica datetime che rappresenta l'ora di creazione dei dati e viene comunemente usata per filtrare i dati. Ciò potrebbe essere dovuto a un backfill da file di origine eterogenei che includono valori datetime in un intervallo di tempo elevato.
    • In questo caso, impostare la chiave di partizione datetime dell'intervallo uniforme come datetime colonna.
    • Se sono necessari criteri di conservazione e memorizzazione nella cache per allinearli ai valori datetime nella colonna, anziché allinearli al tempo di inserimento, impostare la OverrideCreationTime proprietà su true.

Attenzione

  • Non sono previsti limiti hardcoded impostati sul numero di tabelle con i criteri di partizionamento definiti. Tuttavia, ogni tabella aggiuntiva aggiunge sovraccarico al processo di partizionamento dei dati in background. L'impostazione di un criterio in più tabelle comporterà l'uso di più risorse e un costo maggiore a causa delle transazioni di archiviazione sottostanti. Per altre informazioni, vedere Capacità.
  • Non è consigliabile impostare criteri di partizionamento se le dimensioni compresse dei dati per partizione devono essere inferiori a 1 GB.
  • Il processo di partizionamento comporta artefatti di archiviazione residui per tutti gli extent sostituiti durante il processo di partizionamento e durante il processo di unione. La maggior parte degli artefatti di archiviazione residui dovrebbe essere eliminata durante il processo di pulizia automatica. L'aumento del valore della MaxPartitionCount proprietà aumenta il numero di artefatti di archiviazione residui e può ridurre le prestazioni di pulizia.
  • Prima di applicare un criterio di partizionamento in una vista materializzata, esaminare le raccomandazioni per i criteri di partizionamento delle viste materializzate.

Chiavi di partizione

Sono supportati i tipi di chiavi di partizione seguenti.

Tipologia Tipo colonna Proprietà della partizione Valore della partizione
Hash string oppure guid Function, MaxPartitionCount, SeedPartitionAssignmentMode Function(ColumnName, MaxPartitionCount, Seed)
Intervallo uniforme datetime RangeSize, Reference, OverrideCreationTime bin_at(ColumnName, RangeSize, Reference)

Chiave di partizione hash

Se i criteri includono una chiave di partizione hash, tutti gli extent omogenei che appartengono alla stessa partizione verranno assegnati allo stesso nodo dati.

Nota

L'operazione di partizionamento dei dati aggiunge un carico di elaborazione significativo. È consigliabile applicare una chiave di partizione hash in una tabella solo nelle condizioni seguenti:

  • Se la maggior parte delle query usa filtri di uguaglianza (==, in()).
  • La maggior parte delle query aggrega/join su una colonna specifica di tipo string o guid che è di dimensione di grandi dimensioni (cardinalità di 10M o superiore), ad esempio un device_IDoggetto o user_ID.
  • Il modello di utilizzo delle tabelle partizionate è in un carico elevato di query di concorrenza, ad esempio nelle applicazioni di monitoraggio o dashboard.
  • Una funzione hash-modulo viene usata per partizionare i dati.
  • I dati in extent omogenei (partizionati) vengono ordinati in base alla chiave di partizione hash.
    • Non è necessario includere la chiave di partizione hash nei criteri dell'ordine di riga, se ne è definita una nella tabella.
  • Le query che usano la strategia casuale e in cui l'oggetto shuffle key usato in joinsummarize o make-series è la chiave di partizione hash della tabella, dovrebbero ottenere prestazioni migliori perché la quantità di dati necessari per spostarsi tra i nodi viene ridotta.

Proprietà della partizione

Proprietà Descrizione Valori supportati Valore consigliato
Function Nome di una funzione hash-modulo da utilizzare. XxHash64
MaxPartitionCount Numero massimo di partizioni da creare (argomento modulo per la funzione hash-modulo) per periodo di tempo. Nell'intervallo (1,2048]. I valori più elevati comportano un sovraccarico maggiore del processo di partizionamento dei dati e un numero maggiore di extent per ogni periodo di tempo. Il valore consigliato è 128. I valori più elevati aumentano significativamente il sovraccarico del partizionamento dei dati dopo l'inserimento e le dimensioni dei metadati, pertanto non sono consigliati.
Seed Usare per la casualità del valore hash. Numero intero positivo. 1, che è anche il valore predefinito.
PartitionAssignmentMode Modalità utilizzata per l'assegnazione di partizioni ai nodi. ByPartition: tutti gli extent omogenei (partizionati) che appartengono alla stessa partizione vengono assegnati allo stesso nodo.
Uniform: i valori di partizione di un extent vengono ignorati. Gli extent vengono assegnati in modo uniforme ai nodi.		 Se le query non vengono unite o aggregate sulla chiave di partizione hash, usare Uniform. In caso contrario, usare ByPartition.

Esempio di chiave di partizione hash

Chiave di partizione hash su una stringcolonna tipizzata denominata tenant_id. Usa la XxHash64 funzione hash, con MaxPartitionCount impostato sul valore 128consigliato e l'impostazione predefinita Seed di 1.

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

Chiave di partizione datetime di intervallo uniforme

Nota

Applicare solo una chiave di partizione datetime di intervallo uniforme in una datetimecolonna tipizzata in una tabella quando è improbabile che i dati inseriti nella tabella vengano ordinati in base a questa colonna.

In questi casi, è possibile rimshuffare i dati tra extent in modo che ogni extent includa record da un intervallo di tempo limitato. Questo processo comporta l'efficacia dei filtri sulla datetime colonna in fase di query.

La funzione di partizione usata è bin_at() e non è personalizzabile.

Proprietà della partizione

Proprietà Descrizione Valore consigliato
RangeSize Costante timespan scalare che indica le dimensioni di ogni partizione datetime. Iniziare con il valore 1.00:00:00 (un giorno). Non impostare un valore più breve, perché può comportare l'unione di un numero elevato di extent di piccole dimensioni che non possono essere uniti.
Reference Costante datetime scalare che indica un punto fisso nel tempo, in base alle partizioni datetime allineate. Iniziare con 1970-01-01 00:00:00. Se sono presenti record in cui la chiave di partizione datetime ha null valori, il valore della partizione viene impostato sul valore di Reference.
OverrideCreationTime Oggetto bool che indica se i tempi minimi e massimi di creazione dell'extent del risultato devono essere sottoposti a override dall'intervallo dei valori nella chiave di partizione. Il valore predefinito è false. Impostare su true se i dati non vengono inseriti nell'ordine di arrivo. Ad esempio, un singolo file di origine può includere valori datetime distanti e/o può essere necessario applicare la conservazione o la memorizzazione nella cache in base ai valori datetime anziché all'ora di inserimento.

Quando OverrideCreationTime è impostato su true, gli extent potrebbero non essere visualizzati nel processo di merge. Gli extent non vengono rilevati se il tempo di creazione è precedente al Lookback periodo dei criteri di unione Extent della tabella. Per assicurarsi che gli extent siano individuabili, impostare la Lookback proprietà su HotCache.

Esempio di partizione datetime dell'intervallo uniforme

Il frammento di codice mostra una chiave di partizione di intervallo datetime uniforme su una datetime colonna tipizzata denominata timestamp. datetime(2021-01-01) Usa come punto di riferimento, con una dimensione di 7d per ogni partizione e non esegue l'override dei tempi di creazione degli extent.

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

Oggetto criteri

Per impostazione predefinita, i criteri di partizionamento dei dati di una tabella sono null, nel qual caso i dati nella tabella non verranno ripartizionati dopo l'inserimento.

I criteri di partizionamento dei dati hanno le proprietà principali seguenti:

  • PartitionKeys:

    • Raccolta di chiavi di partizione che definiscono come partizionare i dati nella tabella.
    • Una tabella può avere fino a chiavi di 2 partizione, con una delle opzioni seguenti:
      • Una chiave di partizione hash.
      • Una chiave di partizione datetime di intervallo uniforme.
      • Una chiave di partizione hash e una chiave di partizione datetime di intervallo uniforme.
    • Ogni chiave di partizione ha le proprietà seguenti:
      • ColumnName: string - Nome della colonna in base al quale verranno partizionati i dati.
      • Kind: - string Tipo di partizionamento dei dati da applicare (Hash o UniformRange).
      • Properties: property bag - Definisce i parametri in base al partizionamento eseguito.

  • EffectiveDateTime:

    • Datetime UTC da cui è effettivo il criterio.
    • Questa proprietà è facoltativa. Se non viene specificato, il criterio avrà effetto per i dati inseriti dopo l'applicazione del criterio.

Attenzione

  • È possibile impostare un valore datetime nei dati già inseriti in passato e nella partizione. Tuttavia, questa procedura può aumentare significativamente le risorse usate nel processo di partizionamento.
  • Nella maggior parte dei casi, è consigliabile avere solo i dati appena inseriti partizionati ed evitare il partizionamento di grandi quantità di dati cronologici.
  • Se si sceglie di partizionare i dati cronologici, è consigliabile farlo gradualmente impostando EffectiveDateTime su un datetime precedente nei passaggi fino a pochi giorni ogni volta che si modifica il criterio.

Esempio di partizionamento dei dati

Oggetto criteri di partizionamento dei dati con due chiavi di partizione.

  1. Chiave di partizione hash su una stringcolonna tipizzata denominata tenant_id.
    • Usa la XxHash64 funzione hash, con MaxPartitionCount impostato sul valore 128consigliato e l'impostazione predefinita Seed di 1.
  2. Chiave di partizione dell'intervallo datetime uniforme su una datetime colonna di tipo denominata timestamp.
    • datetime(2021-01-01) Usa come punto di riferimento, con una dimensione di 7d per ogni partizione.
{
  "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
      }
    }
  ]
}

Proprietà aggiuntive

Le proprietà seguenti possono essere definite come parte dei criteri. Queste proprietà sono facoltative e è consigliabile non modificarle.

Proprietà Descrizione Valore consigliato Default value
MinRowCountPerOperation Destinazione minima per la somma del numero di righe degli extent di origine di una singola operazione di partizionamento dei dati. 0
MaxRowCountPerOperation Destinazione massima per la somma del numero di righe degli extent di origine di una singola operazione di partizionamento dei dati. Impostare un valore inferiore a 5M se si noterà che le operazioni di partizionamento utilizzano una grande quantità di memoria o CPU per operazione. 0, con una destinazione predefinita di 5.000.000 record.
MaxOriginalSizePerOperation Destinazione massima per la somma delle dimensioni originali (in byte) degli extent di origine di una singola operazione di partizionamento dei dati. Se le operazioni di partizionamento utilizzano una grande quantità di memoria o CPU per operazione, impostare un valore inferiore a 5 GB. 0, con una destinazione predefinita di 5.368.709.120 byte (5 GB).

Processo di partizionamento dei dati

  • Il partizionamento dei dati viene eseguito come processo in background post-inserimento.
    • Si prevede che una tabella inserita continuamente in abbia sempre una "coda" di dati che deve essere ancora partizionata (extent non omogenei).
  • Il partizionamento dei dati viene eseguito solo in extent ad accesso frequente, indipendentemente dal valore della EffectiveDateTime proprietà nei criteri.
    • Se è necessario partizionare extent ad accesso sporadico, è necessario modificare temporaneamente i criteri di memorizzazione nella cache.

È possibile monitorare lo stato di partizionamento delle tabelle con criteri definiti in un database usando il comando .show database extents partitioning statistics e le metriche di partizionamento.

Capacità di partizionamento

::: intervallo di moniker = "azure-data-explorer"

  • Per evitare di consumare troppe risorse, questi aumenti dinamici vengono limitati. Potrebbe essere necessario aumentarli gradualmente e linearmente oltre il limite, se vengono usati completamente.
    • Se l'aumento delle capacità comporta un aumento significativo dell'uso delle risorse del cluster, è possibile aumentare le prestazioni del cluster/, manualmente o abilitando la scalabilità automatica. ::: moniker-end

Limiti

  • I tentativi di partizionare i dati in un database con più di 5.000.000 extent verranno limitati.
    • In questi casi, la EffectiveDateTime proprietà dei criteri di partizionamento delle tabelle nel database verrà ritardata automaticamente di diverse ore, in modo da poter rivalutare la configurazione e i criteri.

Outlier nelle colonne partizionate

  • Le situazioni seguenti possono contribuire alla distribuzione sbilanciata dei dati tra i nodi e ridurre le prestazioni delle query:
    • Se una chiave di partizione hash include valori molto più diffusi di altri, ad esempio una stringa vuota o un valore generico (ad esempio null o N/A).
    • I valori rappresentano un'entità (ad esempio tenant_id) più diffusa nel set di dati.
  • Se una chiave di partizione datetime di intervallo uniforme ha una percentuale sufficientemente elevata di valori "lontani" dalla maggior parte dei valori nella colonna, l'overhead del processo di partizionamento dei dati viene aumentato e può portare a molte piccole dimensioni per tenere traccia. Un esempio di tale situazione è costituito dai valori datetime del passato o del futuro distanti.

In entrambi questi casi, "correggere" i dati o escludere eventuali record irrilevanti nei dati prima o in fase di inserimento, per ridurre il sovraccarico del partizionamento dei dati. Ad esempio, usare un criterio di aggiornamento.

Contenuto correlato