Udostępnij za pośrednictwem

Zasady dzielenia na partie pozyskiwania

  • Artykuł

Omówienie

Dotyczy: ✅Microsoft Fabric✅Azure Data Explorer

Podczas procesu pozyskiwania w kolejce usługa optymalizuje przepływność przez dzielenie małych fragmentów danych przychodzących na partie przed pozyskiwaniem. Przetwarzanie wsadowe zmniejsza ilość zasobów zużywanych przez proces pozyskiwania w kolejce i nie wymaga zasobów po pozyskiwaniu w celu zoptymalizowania małych fragmentów danych utworzonych przez pozyskiwanie niesadowane.

Wadą wykonywania partii przed pozyskiwaniem jest wymuszone opóźnienie. W związku z tym czas zakończenia od żądania pozyskiwania danych do momentu, aż dane gotowe do utworzenia zapytania będą większe.

Podczas definiowania IngestionBatching zasad należy znaleźć równowagę między optymalizacją przepływności a opóźnieniem czasu. Te zasady dotyczą pozyskiwania w kolejce. Definiuje maksymalne wymuszone opóźnienie dozwolone podczas dzielenia małych obiektów blob na partie. Aby dowiedzieć się więcej na temat używania poleceń zasad dzielenia na partie i optymalizowania pod kątem przepływności, zobacz:

Uszczelnianie partii

Istnieje optymalny rozmiar około 1 GB nieskompresowanych danych na potrzeby zbiorczego pozyskiwania danych. Pozyskiwanie obiektów blob z znacznie mniejszymi danymi jest nieoptymalne, więc w przypadku pozyskiwania w kolejce usługa wsaduje małe obiekty blob razem.

Na poniższej liście przedstawiono podstawowe wyzwalacze zasad dzielenia na partie w celu uszczelnienia partii. Partia jest zapieczętowana i pozyskiwana po spełnieniu pierwszego warunku:

  • Size: Osiągnięto lub przekroczono limit rozmiaru partii
  • Count: Osiągnięto limit liczby plików wsadowych
  • Time: Czas dzielenia na partie wygasł

Zasady IngestionBatching można ustawić w bazach danych lub tabelach. Wartości domyślne są następujące: 5 minut maksymalny czas opóźnienia, 500 elementów, całkowity rozmiar 1 GB.

Ważne

Wpływ ustalania tych zasad na bardzo małe wartości jest wzrostem COGS (koszt sprzedanych towarów) i obniżoną wydajnością. Ponadto zmniejszenie wartości zasad dzielenia na partie może faktycznie spowodować zwiększenie efektywnego opóźnienia pozyskiwania kompleksowego ze względu na obciążenie związane z zarządzaniem wieloma procesami pozyskiwania równolegle.

Na poniższej liście przedstawiono warunki uszczelniania partii związanych z pozyskiwaniem pojedynczych obiektów blob. Partia jest zapieczętowana i pozyskiwana po spełnieniu warunków:

SystemFlush Jeśli warunek zostanie ustawiony, partia zostanie zapieczętowana po wyzwoleniu opróżnienia systemu. Po ustawieniu parametrów SystemFlush system opróżnia dane, na przykład ze względu na skalowanie bazy danych lub wewnętrzne resetowanie składników systemu.

Wartości domyślne i limity

Typ Właściwości Domyślny Ustawienie małego opóźnienia Wartość minimalna Wartość maksymalna
Liczba towarów MaximumNumberOfItems 500 500 1 25,000
Rozmiar danych (MB) MaximumRawDataSizeMB 1024 1024 100 4096
Time (TimeSpan) MaximumBatchingTimeSpan 00:05:00 00:00:20 - 00:00:30 00:00:10 00:30:00

Najbardziej efektywnym sposobem kontrolowania kompleksowego opóźnienia przy użyciu zasad dzielenia na partie pozyskiwania jest zmiana granicy czasu na poziomie tabeli lub bazy danych , zgodnie z wyższymi wymaganiami dotyczącymi opóźnień. Zasady na poziomie bazy danych mają wpływ na wszystkie tabele w tej bazie danych, które nie mają zdefiniowanych zasad na poziomie tabeli i żadnej nowo utworzonej tabeli.

Ważne

Jeśli ustawisz granicę czasową zasad wsadowania pozyskiwania zbyt mało w tabelach ruchu przychodzącego, możesz spowodować naliczenie dodatkowej pracy obliczeniowej i magazynu, ponieważ baza danych próbuje zoptymalizować nowo utworzone fragmenty danych. Aby uzyskać więcej informacji na temat fragmentów danych, zobacz zakresy.

Rozmiar danych wsadowych

Rozmiar danych zasad dzielenia na partie jest ustawiany dla danych nieskompresowanych. W przypadku plików Parquet, AVRO i ORC szacowanie jest obliczane na podstawie rozmiaru pliku. W przypadku skompresowanych danych nieskompresowany rozmiar danych jest obliczany w następujący sposób w kolejności malejącej dokładności:

  1. Jeśli nieskompresowany rozmiar jest podany w opcjach źródła pozyskiwania, ta wartość jest używana.
  2. Podczas pozyskiwania plików lokalnych przy użyciu zestawów SDK sprawdzane są archiwa zip i strumienie gzip w celu oceny ich nieprzetworzonego rozmiaru.
  3. Jeśli poprzednie opcje nie udostępniają rozmiaru danych, współczynnik jest stosowany do skompresowanego rozmiaru danych w celu oszacowania rozmiaru nieskompresowanych danych.

Opóźnienia wsadowe

Opóźnienia mogą wynikać z wielu przyczyn, które można rozwiązać przy użyciu ustawień zasad dzielenia na partie.

Przyczyna Rozwiązanie
Opóźnienie danych jest zgodne z ustawieniem time z zbyt małą ilością danych, aby osiągnąć size limit lub count time Zmniejsz limit
Nieefektywne przetwarzanie wsadowe z powodu dużej liczby bardzo małych plików Zwiększ rozmiar plików źródłowych. Jeśli używasz ujścia platformy Kafka, skonfiguruj go do wysyłania danych we fragmentach o rozmiarze ok. 100 KB lub wyższym. Jeśli masz wiele małych plików, zwiększ count wartość (do 2000) w zasadach pozyskiwania bazy danych lub tabeli.
Przetwarzanie wsadowe dużej ilości nieskompresowanych danych Jest to typowe podczas pozyskiwania plików Parquet. Przyrostowy spadek size dla zasad dzielenia na partie tabeli lub bazy danych w kierunku 250 MB i sprawdzanie pod kątem poprawy.
Zaległości, ponieważ baza danych jest skalowana Zaakceptuj wszelkie sugestie doradcy platformy Azure dotyczące skalowania bazy danych na bok lub skalowania w górę. Możesz też ręcznie skalować bazę danych, aby sprawdzić, czy zaległości są zamknięte. Jeśli te opcje nie działają, skontaktuj się z pomocą techniczną, aby uzyskać pomoc.