Typowe pytania dotyczące pozyskiwania w usłudze Azure Data Explorer

Menedżer przetwarzania wsadowego buforuje i wsaduje dane przychodzące na podstawie ustawień pozyskiwania w zasadach dzielenia na partie. Zasady dzielenia na partie pozyskiwania ustawiają limity partii zgodnie z trzema czynnikami ograniczającymi, w zależności od tego, co zostanie osiągnięte po raz pierwszy: czas, który upłynął od momentu utworzenia partii, skumulowanej liczby elementów (obiektów blob) lub całkowitego rozmiaru partii. Domyślne ustawienia przetwarzania wsadowego to 5 minut / 1 GB / 1000 obiektów blob, co oznacza, że podczas kolejkowania przykładowych danych do pozyskiwania będzie co najmniej 5 minut opóźnienia.

Pozyskiwanie w kolejce jest zoptymalizowane pod kątem wysokiej przepływności pozyskiwania i jest preferowanym i najbardziej wydajnym typem pozyskiwania. Natomiast pozyskiwanie przesyłania strumieniowego jest zoptymalizowane pod kątem małych opóźnień pozyskiwania. Dowiedz się więcej na temat pozyskiwania danych przesyłanych w kolejce i przesyłanych strumieniowo.

Jeśli domyślne ustawienia zasad dzielenia na partie pozyskiwania nie odpowiadają Twoim potrzebom, możesz spróbować obniżyć zasady timedzielenia na partie. Zobacz Optymalizowanie pod kątem przepływności. Ustawienia należy również aktualizować podczas skalowania pozyskiwania w górę. Zmiana ustawień zasad wsadowych może potrwać do 5 minut.

Opóźnienie pozyskiwania może wynikać z ustawień zasad dzielenia na partie pozyskiwania lub tworzenia listy prac danych. Aby rozwiązać ten problem, dostosuj ustawienia zasad dzielenia na partie. Opóźnienia, które są częścią procesu pozyskiwania, można monitorować.

Aby wyświetlić metryki opóźnienia pozyskiwania w kolejce, zobacz Monitorowanie opóźnienia pozyskiwania. Metryki Stage Latency i Discovery Latency pokazują opóźnienia w procesie pozyskiwania i ujawniają, czy występują jakieś długie opóźnienia.

Możesz dowiedzieć się więcej o opóźnieniach i dostosować ustawienia w zasadach dzielenia na partie w celu rozwiązywania problemów, które powodują opóźnienia, takie jak zaległości danych, nieefektywne przetwarzanie wsadowe, dzielenie dużych ilości nieskompresowanych danych lub pozyskiwanie bardzo małych ilości danych.

Rozmiar danych zasad dzielenia na partie jest ustawiany dla danych nieskompresowanych. Podczas pozyskiwania skompresowanych danych rozmiar nieskompresowanych danych jest obliczany na podstawie parametrów wsadowych pozyskiwania, metadanych plików ZIP lub współczynnika rozmiaru skompresowanego pliku.

Pozyskiwanie można monitorować przy użyciu metryk oraz konfigurować i używać dzienników diagnostycznych pozyskiwania w celu szczegółowego monitorowania na poziomie tabeli, wyświetlania szczegółowych kodów błędów pozyskiwania itd. Możesz wybrać określone metryki do śledzenia, wybrać sposób agregowania wyników i utworzyć wykresy metryk do wyświetlenia na pulpicie nawigacyjnym. Zobacz więcej na temat metryk przesyłania strumieniowego i sposobu monitorowania pozyskiwania w kolejce.

Możesz użyć usługi Azure Monitor Insights w portalu, aby dowiedzieć się, jak działa usługa Azure Data Explorer i jak jest używana. Widok szczegółowych informacji jest oparty na metrykach i dziennikach diagnostycznych, które można przesyłać strumieniowo do obszaru roboczego usługi Log Analytics. Użyj polecenia dup-next-ingest, aby zduplikować następne pozyskiwanie do kontenera magazynu i przejrzeć szczegóły i metadane pozyskiwania.

Pełny proces pozyskiwania danych można monitorować przy użyciu metryk pozyskiwania danych i dzienników diagnostycznych. Błędy pozyskiwania można monitorować przy użyciu IngestionResult metryki lub dziennika diagnostycznego FailedIngestion . Polecenie .show ingestion failures wyświetla błędy pozyskiwania skojarzone z poleceniami zarządzania pozyskiwaniem danych i nie jest zalecane w przypadku błędów monitorowania. Polecenie .dup-next-failed-ingest zawiera informacje na temat następnego nieudanego pozyskiwania przez przekazanie plików pozyskiwania i metadanych do kontenera magazynu. Może to być przydatne do sprawdzania przepływu pozyskiwania, choć nie zaleca się stałego monitorowania.

Metryki zawierające RetryAttemptsExceeded stan metryki wiele razy wskazują, że pozyskiwanie przekroczyło limit próby ponawiania próby lub limit czasu po powtarzającym się błędzie przejściowym. Jeśli ten błąd pojawia się również w dzienniku diagnostycznym z kodem General_RetryAttemptsExceeded błędu i szczegółami "Nie można uzyskać dostępu do magazynu i uzyskać informacje dla obiektu blob", oznacza to problem z dostępem do magazynu o dużym obciążeniu. Podczas pozyskiwania usługi Event Grid usługa Azure Data Explorer żąda szczegółów obiektu blob z konta magazynu. Gdy obciążenie jest zbyt wysokie na koncie magazynu, dostęp do magazynu może zakończyć się niepowodzeniem i nie można pobrać informacji potrzebnych do pozyskiwania. Jeśli próby przejdą maksymalną liczbę ponownych prób zdefiniowanych, usługa Azure Data Explorer przestanie podejmować próby pozyskiwania nieudanego obiektu blob. Aby zapobiec problemowi z obciążeniem, użyj konta magazynu w warstwie Premium lub podziel pozyskane dane na więcej kont magazynu. Aby odnaleźć powiązane błędy, sprawdź FailedIngestion dzienniki diagnostyczne pod kątem kodów błędów i ścieżki wszystkich nieudanych obiektów blob.

Aby efektywnie pozyskiwać duże ilości danych historycznych, użyj lightingest. Aby uzyskać więcej informacji, zobacz pozyskiwanie danych historycznych. Aby zwiększyć wydajność wielu małych plików, dostosuj zasady dzielenia na partie, zmień warunki wsadowe i opóźnienia adresów. Aby zwiększyć wydajność pozyskiwania podczas pozyskiwania bardzo dużych plików danych, użyj usługi Azure Data Factory (ADF), usługi integracji danych w chmurze.

Źle sformułowane dane, zbyt duże lub niezgodne ze schematem, mogą nie być prawidłowo pozyskiwane. Aby uzyskać więcej informacji, zobacz Pozyskiwanie nieprawidłowych danych.

Podczas pozyskiwania za pomocą zestawu SDK można użyć ustawień zasad dzielenia na partie pozyskiwania , aby zwiększyć wydajność. Spróbuj przyrostowo zmniejszyć rozmiar danych pozyskanych w tabeli lub zasady dzielenia na partie bazy danych w dół do 250 MB. Sprawdź, czy wystąpiła poprawa.

Użytkownicy ujścia platformy Kafka powinni dostosować łącznik do współpracy z zasadami wsadowymi pozyskiwania, dostrajając czas wsadowania, rozmiar i numer elementu.