Indeksowanie dużych zestawów danych w usłudze Azure AI Search

  • Artykuł

Jeśli wymagania dotyczące rozwiązania wyszukiwania obejmują indeksowanie danych big data lub złożonych danych, ten artykuł zawiera strategie obsługi długotrwałych procesów w usłudze Azure AI Search.

W tym artykule przyjęto założenie, że znasz dwa podstawowe podejścia do importowania danych: wypychanie danych do indeksu lub ściąganie danych z obsługiwanego źródła danych przy użyciu indeksatora wyszukiwania. Jeśli scenariusz obejmuje wzbogacenie sztucznej inteligencji intensywnie wykorzystujące obliczenia, indeksatory są wymagane, biorąc pod uwagę zależność zestawu umiejętności od indeksatorów.

Ten artykuł uzupełnia Wskazówki w celu uzyskania lepszej wydajności, która oferuje najlepsze rozwiązania dotyczące projektowania indeksów i zapytań. Dobrze zaprojektowany indeks zawierający tylko wymagane pola i atrybuty jest ważnym wymaganiem wstępnym dla indeksowania na dużą skalę.

Zalecamy użycie nowszej usługi wyszukiwania utworzonej po 3 kwietnia 2024 r., aby uzyskać wyższy magazyn na partycję.

Uwaga

Strategie opisane w tym artykule zakładają pojedyncze duże źródło danych. Jeśli rozwiązanie wymaga indeksowania z wielu źródeł danych, zobacz Indeksowanie wielu źródeł danych w usłudze Azure AI Search , aby zapoznać się z zalecanym podejściem.

Indeksowanie dużych danych przy użyciu interfejsów API wypychania

Interfejsy API wypychania, takie jak interfejs API REST indeksu dokumentów lub metoda IndexDocuments (Zestaw Azure SDK dla platformy .NET), są najbardziej rozpowszechnianą formą indeksowania w usłudze Azure AI Search. W przypadku rozwiązań korzystających z interfejsu API wypychania strategia długotrwałego indeksowania będzie miała jeden lub oba następujące składniki:

  • Przetwarzanie wsadowe dokumentów
  • Zarządzanie wątkami

Wsadowe wiele dokumentów na żądanie

Prostym mechanizmem indeksowania dużej ilości danych jest przesłanie wielu dokumentów lub rekordów w jednym żądaniu. Jeśli cały ładunek wynosi poniżej 16 MB, żądanie może obsłużyć maksymalnie 1000 dokumentów w operacji przekazywania zbiorczego. Te limity mają zastosowanie niezależnie od tego, czy używasz interfejsu API REST indeksu dokumentów, czy metody IndexDocuments w zestawie SDK platformy .NET. W przypadku dowolnego interfejsu API spakujesz 1000 dokumentów w treści każdego żądania.

Przetwarzanie wsadowe dokumentów znacznie skróci czas potrzebny do pracy z dużą ilością danych. Określenie optymalnego rozmiaru partii danych jest kluczowym składnikiem optymalizacji szybkości indeksowania. Dwa podstawowe czynniki wpływające na optymalny rozmiar partii to:

  • Schemat indeksu
  • Rozmiar danych

Ponieważ optymalny rozmiar partii zależy od indeksu i danych, najlepszym rozwiązaniem jest przetestowanie różnych rozmiarów partii w celu określenia, która z nich daje najszybszą szybkość indeksowania dla danego scenariusza. Samouczek: optymalizowanie indeksowania przy użyciu interfejsu API wypychania udostępnia przykładowy kod do testowania rozmiarów partii przy użyciu zestawu .NET SDK.

Dodawanie wątków i strategii ponawiania prób

Indeksatory mają wbudowane zarządzanie wątkami, ale w przypadku korzystania z interfejsów API wypychania kod aplikacji będzie musiał zarządzać wątkami. Upewnij się, że istnieją wystarczające wątki, aby w pełni korzystać z dostępnej pojemności, zwłaszcza jeśli ostatnio zwiększono partycje lub uaktualniono do usługi wyszukiwania w wyższej warstwie.

  1. Zwiększ liczbę współbieżnych wątków w kodzie klienta.

  2. Podczas zwiększania liczby żądań osiąganych przez usługę wyszukiwania mogą wystąpić kody stanu HTTP wskazujące, że żądanie nie powiodło się w pełni. Podczas indeksowania dwa typowe kody stanu HTTP to:

    • 503 Usługa niedostępna — ten błąd oznacza, że system jest obciążony dużym obciążeniem i nie można w tej chwili przetworzyć żądania.

    • 207 — ten błąd oznacza, że niektóre dokumenty zakończyły się pomyślnie, ale co najmniej jeden błąd.

  3. Aby obsłużyć błędy, żądania powinny zostać ponowione przy użyciu strategii ponawiania prób wykładniczego wycofywania.

Zestaw Azure .NET SDK automatycznie ponawia próby 503 i inne żądania, które zakończyły się niepowodzeniem, ale musisz zaimplementować własną logikę, aby ponowić próbę 207s. Narzędzia typu open source, takie jak Polly , mogą również służyć do implementowania strategii ponawiania prób.

Indeksowanie za pomocą indeksatorów i interfejsów API "ściągania"

Indeksatory mają kilka możliwości, które są przydatne w przypadku długotrwałych procesów:

  • Przetwarzanie wsadowe dokumentów
  • Równoległe indeksowanie danych partycjonowanych
  • Planowanie i wykrywanie zmian na potrzeby indeksowania tylko nowych i zmienianych dokumentów w czasie

Harmonogramy indeksatora mogą wznowić przetwarzanie w ostatnim znanym punkcie zatrzymania. Jeśli dane nie są w pełni indeksowane w oknie przetwarzania, indeksator pobiera wszędzie tam, gdzie po lewej stronie na następnym uruchomieniu, przy założeniu, że używasz źródła danych, które zapewnia wykrywanie zmian.

Partycjonowanie danych na mniejsze pojedyncze źródła danych umożliwia przetwarzanie równoległe. Możesz podzielić dane źródłowe, takie jak na wiele kontenerów w usłudze Azure Blob Storage, utworzyć źródło danych dla każdej partycji, a następnie uruchomić indeksatory równolegle, pod kątem liczby jednostek wyszukiwania usługi wyszukiwania.

Sprawdzanie rozmiaru partii indeksatora

Podobnie jak w przypadku interfejsu API wypychania indeksatory umożliwiają skonfigurowanie liczby elementów na partię. W przypadku indeksatorów opartych na interfejsie API REST tworzenia indeksatora można ustawić batchSize argument, aby dostosować to ustawienie, aby lepiej dopasować cechy danych.

Domyślne rozmiary partii są specyficzne dla źródła danych. Usługi Azure SQL Database i Azure Cosmos DB mają domyślny rozmiar partii 1000. Natomiast indeksowanie obiektów blob platformy Azure ustawia rozmiar partii na 10 dokumentów w rozpoznawaniu większego średniego rozmiaru dokumentu.

Planowanie indeksatorów dla długotrwałych procesów

Planowanie indeksatora to ważny mechanizm przetwarzania dużych zestawów danych i obsługi wolno działających procesów, takich jak analiza obrazu w potoku wzbogacania.

Zazwyczaj przetwarzanie indeksatora jest uruchamiane w ciągu 2-godzinnego okna. Jeśli obciążenie indeksowania trwa kilka dni, a nie godzin, można umieścić indeksator na kolejnych, cyklicznych harmonogramach uruchamianych co dwie godziny. Zakładając, że źródło danych ma włączone śledzenie zmian, indeksator wznowi przetwarzanie, w którym ostatnio zostało przerwane. W tym tempie indeksator może przechodzić przez listę prac dokumentów w ciągu kilku dni do momentu przetworzenia wszystkich nieprzetworzonych dokumentów.

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Jeśli w źródle danych nie ma już żadnych nowych ani zaktualizowanych dokumentów, historia wykonywania indeksatora będzie raportów 0/0 o przetworzonych dokumentach i nie ma żadnego przetwarzania.

Aby uzyskać więcej informacji na temat ustawiania harmonogramów, zobacz Create Indexer REST API (Tworzenie interfejsu API REST indeksatora) lub zobacz How to schedule indexers for Azure AI Search (Jak zaplanować indeksatory dla usługi Azure AI Search).

Uwaga

Niektóre indeksatory działające w starszej architekturze środowiska uruchomieniowego mają 24-godzinne, a nie 2-godzinne maksymalne okno przetwarzania. Limit 2-godzinny dotyczy nowszych procesorów zawartości, które działają w zarządzanym wewnętrznie środowisku wielodostępnym. Jeśli to możliwe, usługa Azure AI Search próbuje odciążyć indeksator i przetwarzanie zestawu umiejętności do środowiska wielodostępnego. Jeśli nie można zmigrować indeksatora, zostanie on uruchomiony w środowisku prywatnym i może działać tak długo, jak 24 godziny. Jeśli planujesz indeksator, który wykazuje te cechy, przyjmij 24-godzinne okno przetwarzania.

Równoległe uruchamianie indeksatorów

W przypadku partycjonowania danych można utworzyć wiele kombinacji indeksatora-źródła danych, które ściągają z każdego źródła danych i zapisują je w tym samym indeksie wyszukiwania. Ponieważ każdy indeksator jest odrębny, można uruchomić je w tym samym czasie, wypełnianie indeksu wyszukiwania szybciej niż w przypadku sekwencyjnie uruchomionych.

Upewnij się, że masz wystarczającą pojemność. Jedna jednostka wyszukiwania w usłudze może uruchamiać jeden indeksator w danym momencie. Tworzenie wielu indeksatorów jest przydatne tylko wtedy, gdy mogą działać równolegle.

Liczba zadań indeksowania, które mogą być uruchamiane jednocześnie, różni się w przypadku indeksowania opartego na tekście i umiejętnościach. Aby uzyskać więcej informacji, zobacz Wykonywanie indeksatora.

Jeśli źródło danych jest kontenerem usługi Azure Blob Storage lub usługą Azure Data Lake Storage Gen 2, wyliczanie dużej liczby obiektów blob może zająć dużo czasu (nawet godzin), dopóki ta operacja nie zostanie ukończona. Spowoduje to, że liczba dokumentów indeksatora zakończonych powodzeniem nie zostanie zwiększona w tym czasie i może się wydawać, że nie poczyni żadnych postępów, gdy tak jest. Jeśli chcesz, aby przetwarzanie dokumentów przebiegało szybciej w przypadku dużej liczby obiektów blob, rozważ podzielenie danych na wiele kontenerów i utworzenie równoległych indeksatorów wskazujących pojedynczy indeks.

  1. Zaloguj się do witryny Azure Portal i sprawdź liczbę jednostek wyszukiwania używanych przez usługę wyszukiwania. Wybierz pozycję Ustawienia> Scale, aby wyświetlić liczbę w górnej części strony. Liczba indeksatorów, które będą uruchamiane równolegle, jest w przybliżeniu równa liczbie jednostek wyszukiwania.

  2. Partycjonowanie danych źródłowych między wieloma kontenerami lub wieloma folderami wirtualnymi wewnątrz tego samego kontenera.

  3. Utwórz wiele źródeł danych, po jednym dla każdej partycji, sparowanych z własnym indeksatorem.

  4. Określ ten sam docelowy indeks wyszukiwania w każdym indeksatorze.

  5. Zaplanuj indeksatory.

  6. Przejrzyj stan indeksatora i historię wykonywania w celu potwierdzenia.

Istnieje pewne ryzyko związane z indeksowaniem równoległym. Najpierw pamiętaj, że indeksowanie nie działa w tle, zwiększając prawdopodobieństwo ograniczenia lub usunięcia zapytań.

Po drugie usługa Azure AI Search nie blokuje indeksu aktualizacji. Równoczesne zapisy są zarządzane, wywołując ponowienie próby, jeśli określony zapis nie powiedzie się podczas pierwszej próby, ale może wystąpić wzrost liczby błędów indeksowania.

Mimo że wiele zestawów indeksatora-źródła danych może być przeznaczonych dla tego samego indeksu, należy zachować ostrożność podczas uruchamiania indeksatora, który może zastąpić istniejące wartości w indeksie. Jeśli drugi indeksator-źródło danych jest przeznaczony dla tych samych dokumentów i pól, wszystkie wartości z pierwszego uruchomienia zostaną zastąpione. Wartości pól są zastępowane w całości; indeksator nie może scalić wartości z wielu przebiegów w tym samym polu.

Indeksowanie danych big data na platformie Spark

Jeśli masz architekturę danych big data i dane są w klastrze Spark, zalecamy użycie usługi SynapseML do ładowania i indeksowania danych. Ten samouczek zawiera kroki wywoływania usług Azure AI na potrzeby wzbogacania sztucznej inteligencji, ale można również użyć interfejsu API AzureSearchWriter do indeksowania tekstu.

Zobacz też