Zasady dzielenia na partie pozyskiwania

  • Artykuł

Omówienie

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 zasoby zużywane przez proces pozyskiwania w kolejce i nie wymaga zasobów po pozyskiwaniu w celu zoptymalizowania małych fragmentów danych generowanych przez pozyskiwanie niesadowe.

Wadą wykonywania wsadowania 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 na partie małych obiektów blob razem. Aby dowiedzieć się więcej na temat używania poleceń zasad wsadowych i optymalizowania pod kątem przepływności, zobacz:

Uszczelnianie partii

Istnieje optymalny rozmiar około 1 GB nieskompresowanych danych w celu zbiorczego pozyskiwania. Pozyskiwanie obiektów blob z znacznie mniejszymi danymi jest nieoptymalne, więc w pozyskiwaniu w kolejce usługa będzie wsadować małe obiekty blob razem.

Na poniższej liście przedstawiono podstawowe wyzwalacze zasad przetwarzania wsadowego 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 przetwarzania wsadowego 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, 1000 elementów, całkowity rozmiar 1 GB.

Ważne

Wpływ na ustawienie tych zasad na bardzo małe wartości jest wzrostem coGS (koszt sprzedanych towarów) klastra i zmniejszeniem wydajności. Ponadto zmniejszenie wartości zasad wsadowych 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 danych równolegle.

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

  • SingleBlob_FlushImmediately: Pozyskiwanie pojedynczego obiektu blob z powodu ustawienia "FlushImmediately"
  • SingleBlob_IngestIfNotExists: Pozyskiwanie pojedynczego obiektu blob z powodu ustawienia "IngestIfNotExists"
  • SingleBlob_IngestByTag: Pozyskiwanie pojedynczego obiektu blob z powodu ustawienia "pozyskiwania według"
  • SingleBlob_SizeUnknown: Pozyskiwanie pojedynczego obiektu blob, ponieważ rozmiar obiektu blob jest nieznany

SystemFlush Jeśli warunek jest 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 klastra lub wewnętrzne resetowanie składników systemu.

Wartości domyślne i limity

Typ Właściwość Domyślny Ustawienie małego opóźnienia Wartość minimalna Wartość maksymalna
Liczba elementów MaximumNumberOfItems 500 500 1 25 000
Rozmiar danych (MB) MaximumRawDataSizeMB 1024 1024 100 4096
Czas (s) MaximumBatchingTimeSpan 300 20 - 30 10 1800

Najbardziej efektywnym sposobem kontrolowania kompleksowego opóźnienia przy użyciu zasad przetwarzania wsadowego pozyskiwania jest zmiana granicy czasu na poziomie tabeli lub bazy danych , zgodnie z wyższym ograniczeniem 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ę czasu zasad pozyskiwania partii zbyt mało w tabelach o niskim poziomie ruchu przychodzącego, możesz spowodować powstanie dodatkowych zasobów obliczeniowych i magazynu, ponieważ klaster 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 przetwarzania wsadowego jest ustawiany dla nieskompresowanych danych. W przypadku plików Parquet, AVRO i ORC szacowanie jest obliczane na podstawie rozmiaru pliku. W przypadku skompresowanych danych rozmiar danych nieskompresowanych jest obliczany w następujący sposób w kolejności malejącej dokładności:

  1. Jeśli rozmiar nieskompresowany zostanie 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 pierwotnego rozmiaru.
  3. Jeśli poprzednie opcje nie zapewniają rozmiaru danych, współczynnik jest stosowany do skompresowanego rozmiaru danych w celu oszacowania nieskompresowanego rozmiaru danych.

Opóźnienia wsadowe

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

Przyczyna Rozwiązanie
Opóźnienie danych jest zgodne z time ustawieniem z zbyt małą ilością size danych, aby osiągnąć 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 w fragmentach ok. 100 KB lub nowszych. Jeśli masz wiele małych plików, zwiększ wartość count (do 2000) w zasadach pozyskiwania bazy danych lub tabeli.
Przetwarzanie wsadowe dużej ilości danych nieskompresowanych Jest to powszechne podczas pozyskiwania plików Parquet. Przyrostowy spadek size dla zasad dzielenia na partie tabeli lub bazy danych w kierunku 250 MB i sprawdzanie poprawy.
Zaległości, ponieważ klaster jest skalowany Zaakceptuj wszelkie sugestie doradcy platformy Azure, aby skalować w górę lub skalować klaster w górę. Możesz też ręcznie skalować klaster, aby sprawdzić, czy zaległości są zamknięte. Jeśli te opcje nie działają, skontaktuj się z pomocą techniczną, aby uzyskać pomoc.