Zasady partycjonowania

Dotyczy: ✅Microsoft Fabric✅Azure Data Explorer

Zasady partycjonowania określają, czy zakresy (fragmenty danych) powinny być partycjonowane dla określonej tabeli lub zmaterializowanego widoku.

Zasady wyzwalają dodatkowy proces w tle, który odbywa się po utworzeniu zakresów po pozyskiwaniu danych. Ten proces obejmuje pozyskiwanie danych z zakresów źródłowych i tworzenie jednorodnych zakresów, w których wszystkie wartości kolumny wyznaczonej jako klucz partycji znajdują się w jednej partycji.

Głównym celem zasad partycjonowania jest zwiększenie wydajności zapytań w określonych obsługiwanych scenariuszach.

Uwaga

Domyślnie, gdy zasady partycjonowania danych nie są zdefiniowane (to null), zakresy są partycjonowane według czasu utworzenia (pozyskiwania). W większości przypadków nie trzeba ustawiać zasad partycjonowania danych.

Obsługiwane scenariusze

Poniżej przedstawiono jedyne scenariusze, w których zalecane jest ustawienie zasad partycjonowania danych. We wszystkich innych scenariuszach ustawienie zasad nie jest zalecane.

• Częste filtry w średniej lub wysokiej kardynalności string lub guid kolumnie:
  • Na przykład: rozwiązania wielodostępne lub tabela metryk, w której większość lub wszystkie zapytania filtruje według kolumny typu string lub guid, takich jak TenantId lub MetricId.
  • Średnia kardynalność wynosi co najmniej 10 000 odrębnych wartości.
  • Ustaw klucz partycji skrótu uniform
• Częste agregacje lub sprzężenia w wysokiej kardynalności string lub guid kolumnie:
  • Na przykład informacje IoT z wielu różnych czujników lub zapisy akademickie wielu różnych studentów.
  • Wysoka kardynalność wynosi co najmniej 1000 000 odrębnych wartości, gdzie rozkład wartości w kolumnie jest w przybliżeniu równy.
  • W takim przypadku ustaw klucz partycji skrótu ByPartition
• Pozyskiwanie danych poza kolejnością:
  • Dane pozyskane do tabeli mogą nie być uporządkowane i podzielone na zakresy (fragmenty) zgodnie z określoną datetime kolumną reprezentującą czas tworzenia danych i jest często używany do filtrowania danych. Może to być spowodowane wypełnieniem z heterogenicznych plików źródłowych, które zawierają wartości daty/godziny w dużym przedziale czasu.
  • W tym przypadku ustaw dla kolumny datetime klucz partycji data/godzina jednolitego zakresu.
  • Jeśli potrzebujesz zasad przechowywania i buforowania, aby dopasować je do wartości daty/godziny w kolumnie, zamiast dopasowywać do czasu pozyskiwania, ustaw OverrideCreationTime właściwość na truewartość .

Uwaga

• Nie ma ustalonych limitów ustawionych dla liczby tabel ze zdefiniowanymi zasadami partycjonowania. Jednak każda dodatkowa tabela dodaje obciążenie do procesu partycjonowania danych w tle. Ustawienie zasad dla większej liczby tabel spowoduje, że będzie używana większa ilość zasobów i wyższe koszty z powodu bazowych transakcji magazynu. Aby uzyskać więcej informacji, zobacz pojemność.
• Nie zaleca się ustawiania zasad partycjonowania, jeśli skompresowany rozmiar danych na partycję powinien być mniejszy niż 1 GB.
• Proces partycjonowania powoduje resztowe artefakty magazynu dla wszystkich zakresów zastąpionych podczas procesu partycjonowania i podczas procesu scalania. Oczekuje się, że większość artefaktów magazynu reszt zostanie usunięta podczas procesu automatycznego oczyszczania. Zwiększenie wartości MaxPartitionCount właściwości zwiększa liczbę artefaktów magazynu reszt i może zmniejszyć wydajność oczyszczania.
• Przed zastosowaniem zasad partycjonowania w zmaterializowanym widoku zapoznaj się z zaleceniami dotyczącymi zmaterializowanych zasad partycjonowania widoków.

Klucze partycji

Obsługiwane są następujące rodzaje kluczy partycji.

Rodzaj	Typ kolumny	Właściwości partycji	Wartość partycji
Skrót	string lub guid	Function, , MaxPartitionCount, , SeedPartitionAssignmentMode	Function(ColumnName, MaxPartitionCount, Seed)
Zakres jednolity	datetime	RangeSize, , ReferenceOverrideCreationTime	bin_at(ColumnName, RangeSize, Reference)

Klucz partycji skrótu

Jeśli zasady zawierają klucz partycji skrótu, wszystkie jednorodne zakresy należące do tej samej partycji zostaną przypisane do tego samego węzła danych.

Uwaga

Operacja partycjonowania danych dodaje znaczne obciążenie przetwarzania. Zalecamy zastosowanie klucza partycji skrótu w tabeli tylko w następujących warunkach:

• Jeśli większość zapytań używa filtrów równości (==, in()).
• Większość zapytań agreguje/sprzężenia w określonej kolumnie typu string lub guid jest to duży wymiar (kardynalność 10M lub wyższa), na przykład device_ID, lub user_ID.
• Wzorzec użycia tabel partycjonowanych jest w dużym obciążeniu zapytań współbieżności, na przykład w aplikacjach do monitorowania lub pulpitów nawigacyjnych.

• Funkcja hash-modulo służy do partycjonowania danych.
• Dane w jednorodnych (partycjonowanych) zakresach są uporządkowane za pomocą klucza partycji skrótu.
  • Nie musisz uwzględniać klucza partycji skrótu w zasadach kolejności wierszy, jeśli jest on zdefiniowany w tabeli.
• Zapytania korzystające ze strategii mieszania, w których shuffle key używany w joinsummarize elememencie lub make-series jest kluczem partycji skrótu tabeli, powinny działać lepiej, ponieważ ilość danych wymaganych do przenoszenia między węzłami jest ograniczona.

Właściwości partycji

Właściwości	opis	Obsługiwane wartości	Zalecana wartość
Function	Nazwa funkcji hash-modulo do użycia.	XxHash64
MaxPartitionCount	Maksymalna liczba partycji do utworzenia (argument modulo funkcji hash-modulo) na okres.	W zakresie (1,2048].	Wyższe wartości prowadzą do większego obciążenia związanego z procesem partycjonowania danych i większą liczbą zakresów dla każdego okresu. Zalecaną wartością jest 128. Wyższe wartości znacznie zwiększają obciążenie związane z partycjonowaniem danych po pozyskaniu danych i rozmiarem metadanych — dlatego nie są zalecane.
Seed	Służy do losowania wartości skrótu.	Dodatnia liczba całkowita.	1, która jest również wartością domyślną.
PartitionAssignmentMode	Tryb używany do przypisywania partycji do węzłów.	ByPartition: wszystkie jednorodne (partycjonowane) zakresy należące do tej samej partycji są przypisywane do tego samego węzła. Uniform: Wartości partycji zakresów są ignorowane. Zakresy są przypisywane równomiernie do węzłów.	Jeśli zapytania nie sprzężą ani nie agregują klucza partycji skrótu, użyj polecenia Uniform. W przeciwnym razie użyj polecenia ByPartition.

Przykład klucza partycji skrótu

Klucz partycji skrótu stringdla kolumny typu -typed o nazwie tenant_id. Używa funkcji skrótu XxHash64 z ustawioną wartością zalecaną MaxPartitionCounti wartością domyślną 128Seed.1

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

Jednolity klucz partycji daty/godziny zakresu

Uwaga

Zastosuj tylko jednolity klucz datetimepartycji daty/godziny w kolumnie typu -typed w tabeli, gdy dane pozyskane do tabeli są mało prawdopodobne, aby zostały uporządkowane zgodnie z tą kolumną.

W takich przypadkach można przetasować dane między zakresami, aby każdy zakres zawierał rekordy z ograniczonego zakresu czasu. Ten proces powoduje, że filtry datetime w kolumnie są bardziej efektywne w czasie wykonywania zapytania.

Używana funkcja partycji jest bin_at() i nie jest dostosowywalna.

Właściwości partycji

Właściwości	opis	Zalecana wartość
RangeSize	timespan Stała skalarna wskazująca rozmiar każdej partycji daty/godziny.	Zacznij od wartości 1.00:00:00 (jeden dzień). Nie ustawiaj krótszej wartości, ponieważ może to spowodować, że tabela ma dużą liczbę małych zakresów, których nie można scalić.
Reference	datetime Stała skalarna wskazująca stały punkt w czasie, zgodnie z którym partycje daty/godziny są wyrównane.	1970-01-01 00:00:00Zacznij od . Jeśli istnieją rekordy, w których klucz partycji daty/godziny ma null wartości, ich wartość partycji jest ustawiona Referencena wartość .
OverrideCreationTime	Wartość wskazująca bool , czy minimalny i maksymalny czas tworzenia zakresu wyników powinien zostać zastąpiony przez zakres wartości w kluczu partycji.	Wartość domyślna to false. Ustaw wartość na true , jeśli dane nie są pozyskiwane w kolejności od czasu przybycia. Na przykład pojedynczy plik źródłowy może zawierać wartości daty/godziny, które są odległe i/lub można wymusić przechowywanie lub buforowanie na podstawie wartości daty/godziny, a nie godziny pozyskiwania. Gdy OverrideCreationTime parametr ma wartość true, zakresy mogą zostać pominięte w procesie scalania. Zakresy są pomijane, jeśli ich czas tworzenia jest starszy niż Lookback okres zasad scalania Zakresy tabeli. Aby upewnić się, że zakresy są wykrywalne, ustaw Lookback właściwość na HotCachewartość .

Przykład partycji data/godzina munduru

Fragment kodu przedstawia jednolity klucz partycji zakresu dat/godziny dla kolumny typizowanej datetime o nazwie timestamp. Używa datetime(2021-01-01) jako punktu odniesienia, z rozmiarem 7d dla każdej partycji i nie zastępuje czasów tworzenia zakresów.

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

Obiekt zasad

Domyślnie zasady partycjonowania danych tabeli to null, w którym przypadku dane w tabeli nie będą ponownie partycjonowane po ich pozyskiwaniu.

Zasady partycjonowania danych mają następujące główne właściwości:

• PartitionKeys:

  • Kolekcja kluczy partycji definiujących sposób partycjonowania danych w tabeli.
  • Tabela może mieć maksymalnie 2 klucze partycji z jedną z następujących opcji:
    • Jeden klucz partycji skrótu.
    • Jeden jednolity klucz partycji datetime zakresu.
    • Jeden klucz partycji skrótu i jeden jednolity klucz partycji datetime zakresu.
  • Każdy klucz partycji ma następujące właściwości:
    • ColumnName: string — nazwa kolumny, zgodnie z którą dane będą partycjonowane.
    • Kind: string — Rodzaj partycjonowania danych do zastosowania (Hash lub UniformRange).
    • Properties: property bag — definiuje parametry zgodnie z tym, które partycjonowanie jest wykonywane.

• EffectiveDateTime:

  • Data/godzina UTC, z której obowiązują zasady.
  • Ta właściwość jest opcjonalna. Jeśli nie zostanie określony, zasady zostaną zastosowane dla danych pozyskanych po zastosowaniu zasad.

Uwaga

• Możesz ustawić wartość daty/godziny w przeszłości i partycjonować już pozyskane dane. Jednak ta praktyka może znacznie zwiększyć ilość zasobów używanych w procesie partycjonowania.
• W większości przypadków zaleca się tylko partycjonowanie nowo pozyskanych danych i uniknięcie partycjonowania dużych ilości danych historycznych.
• Jeśli zdecydujesz się na partycjonowanie danych historycznych, rozważ to stopniowo, ustawiając wartość EffectiveDateTime na poprzednią datetime część kroków do kilku dni za każdym razem, gdy zmienisz zasady.

Przykład partycjonowania danych

Obiekt zasad partycjonowania danych z dwoma kluczami partycji.

1. Klucz partycji skrótu stringdla kolumny typu -typed o nazwie tenant_id.
   • Używa funkcji skrótu XxHash64 z ustawioną wartością zalecaną MaxPartitionCounti wartością domyślną 128Seed.1
2. Jednolity klucz partycji zakresu daty/godziny dla datetime kolumny typu o nazwie timestamp.
   • Używa datetime(2021-01-01) jako punktu odniesienia o rozmiarze 7d dla każdej partycji.

{
  "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
      }
    }
  ]
}

Dodatkowe właściwości

Następujące właściwości można zdefiniować jako część zasad. Te właściwości są opcjonalne i nie zalecamy ich zmieniania.

Właściwości	opis	Zalecana wartość	Domyślna wartość
MinRowCountPerOperation	Minimalny element docelowy dla sumy liczby wierszy w zakresach źródłowych pojedynczej operacji partycjonowania danych.		0
MaxRowCountPerOperation	Maksymalna wartość docelowa dla sumy liczby wierszy w zakresach źródłowych operacji partycjonowania pojedynczych danych.	Ustaw wartość niższą niż 5 mln, jeśli zobaczysz, że operacje partycjonowania zużywają dużą ilość pamięci lub procesora CPU na operację.	0, z domyślnym celem 5000 000 rekordów.
MaxOriginalSizePerOperation	Maksymalna wartość docelowa dla sumy oryginalnego rozmiaru (w bajtach) w zakresach źródłowych pojedynczej operacji partycjonowania danych.	Jeśli operacje partycjonowania zużywają dużą ilość pamięci lub procesora CPU na operację, ustaw wartość niższą niż 5 GB.	0, z domyślnym celem 5368 709 120 bajtów (5 GB).

Proces partycjonowania danych

• Partycjonowanie danych jest uruchamiane jako proces w tle po pozyskiwaniu.
  • Oczekuje się, że tabela, która jest stale pozyskiwana do systemu, zawsze będzie miała "ogon" danych, które nie są jeszcze partycjonowane (nietypowe zakresy).
• Partycjonowanie danych jest uruchamiane tylko w gorących zakresach, niezależnie od wartości EffectiveDateTime właściwości w zasadach.
  • Jeśli wymagane jest partycjonowanie zimnych zakresów, należy tymczasowo dostosować zasady buforowania.

Stan partycjonowania tabel ze zdefiniowanymi zasadami w bazie danych można monitorować za pomocą polecenia .show zakresów bazy danych partycjonowania statystyk i metryk partycjonowania.

Pojemność partycjonowania

• Proces partycjonowania danych powoduje utworzenie większej liczby zakresów. Zakresy scalania mogą stopniowo rosnąć, dzięki czemu proces scalania zakresów może nadążyć.

• Jeśli istnieje duża przepływność pozyskiwania lub wystarczająco duża liczba tabel, które mają zdefiniowane zasady partycjonowania, pojemność partycji Extents może stopniowo wzrosnąć, aby proces partycjonowania zakresów mógł nadążyć.

• Aby uniknąć zbyt wielu zasobów, te dynamiczne wzrosty są ograniczone. Może być konieczne stopniowe i liniowe zwiększenie ich poza limitem, jeśli są one całkowicie używane.
  • Jeśli zwiększenie pojemności powoduje znaczny wzrost użycia zasobów klastra, można skalować klaster w górę w poziomie/, ręcznie lub włączając skalowanie automatyczne.

Ograniczenia

• Próby partycjonowania danych w bazie danych, która ma już ponad 5000 000 zakresów, zostaną ograniczone.
  • W takich przypadkach EffectiveDateTime właściwość zasad partycjonowania tabel w bazie danych będzie automatycznie opóźniona o kilka godzin, aby można było ponownie liczyć konfigurację i zasady.

Wartości odstające w kolumnach podzielonych na partycje

• Następujące sytuacje mogą przyczynić się do nierównowagowego rozkładu danych między węzłami i obniżyć wydajność zapytań:
  • Jeśli klucz partycji skrótu zawiera wartości, które są znacznie bardziej powszechne niż inne, na przykład pusty ciąg lub wartość ogólna (np null . lub N/A).
  • Wartości reprezentują jednostkę (na przykład tenant_id), która jest bardziej rozpowszechniona w zestawie danych.
• Jeśli klucz partycji daty/godziny o jednolitym zakresie ma wystarczająco duży procent wartości, które są "dalekie" od większości wartości w kolumnie, obciążenie związane z procesem partycjonowania danych jest zwiększane i może prowadzić do wielu małych zakresów w celu śledzenia. Przykładem takiej sytuacji są wartości daty/godziny z odległej przeszłości lub przyszłości.

W obu tych przypadkach "napraw" dane lub odfiltruj wszelkie nieistotne rekordy w danych przed lub w czasie pozyskiwania, aby zmniejszyć obciążenie partycjonowania danych. Na przykład użyj zasad aktualizacji.

Powiązana zawartość

• Polecenia zarządzania zasadami partycjonowania