共用方式為

在 Azure AI 搜尋服務中為大型資料集編製索引

  • 發行項

如果您需要在搜尋解決方案中編製大型或複雜數據集的索引，本文會探索在 Azure AI 搜尋服務上容納長時間執行程式的策略。

這些策略假設熟悉匯入數據的兩種基本方法：將數據推送至索引，或使用搜尋索引器從支持的數據源提取數據。 如果您的案例牽涉到需要大量計算的 AI 擴充，由於技能組相依於索引子，因此必須使用索引子。

本文會補充改善效能的秘訣，該文章提供索引和查詢設計的最佳做法。 設計完善的索引只會包含您需要的欄位和屬性，這是大規模索引編製的重要先決條件。

建議您使用在 2024 年 4 月 3 日之後建立的較新搜尋服務，以獲得每個磁碟分割較高的儲存體。

注意

本文所述的策略是以單一大型資料來源為前提。 如果您的解決方案需要編製來自多個資料來源的索引，請參閱在 Azure AI 搜尋服務中為多個資料來源編製索引以了解建議的方法。

使用推送 API 編製數據索引

推送 API，例如 文件索引 REST API 或 IndexDocuments 方法 （Azure SDK for .NET），是 Azure AI 搜尋服務中最常見的索引編製形式。 對於使用推送 API 的解決方案，長時間執行索引的策略有下列其中一個或兩個元件：

  • 批次處理文件
  • 管理執行緒

每個要求批次處理多份文件

編製大量資料索引的一個簡單機制，便是在單一要求中提交多個文件或記錄。 只要整個承載低於 16 MB，要求就可以在大量上傳作業中處理最多 1,000 份檔。 無論您是使用文件編製索引 REST API 還是使用 .NET SDK 中的 IndexDocuments 方法，這些限制都適用。 使用任一 API，您可以在每個要求的本文中封裝 1,000 份檔。

批處理檔可大幅縮短處理大量數據所需的時間。 為您的資料決定最佳批次大小是將索引編製速度最佳化的關鍵要素。 影響最佳批次大小的兩個主要因素如下：

  • 索引的結構描述
  • 資料的大小

由於最佳批次大小取決於索引和資料，因此最好的方法是測試不同批次大小，以判斷在您所處的情況下，能達到最快編製索引速度的批次大小。 如需使用 .NET SDK 測試批次大小的範例程式代碼，請參閱 教學課程：使用推送 API 優化索引編製。

管理線程和重試策略

索引器具有內建線程管理，但當您使用推送 API 時，應用程式程式代碼必須管理線程。 請確定有足夠的線程可以充分利用可用的容量，特別是如果您最近已增加數據分割或升級至較高層級的搜尋服務。

  1. 在您的用戶端程式碼中增加並行執行緒數目。

  2. 當您增加點擊搜尋服務的要求時，您可能會遇到 HTTP 狀態碼，指出要求並未完全成功。 在索引編製期間，兩個常見的 HTTP 狀態碼如下：

    • 503 服務無法使用：此錯誤表示系統負載過重，目前無法處理您的要求。

    • 207 多重狀態：此錯誤表示某些檔成功，但至少一個失敗。

  3. 若要處理失敗，應該使用指數輪詢重試策略來重試要求。

Azure .NET SDK 會自動重試 503 和其他失敗的要求，但您需要實作自己的邏輯來重試 207s。 您也可以使用 Polly 等開放原始碼工具來實作重試策略。

使用索引器和提取 API

索引子有數個功能，適用於長時間執行的處理序：

  • 批次處理文件
  • 分割資料的平行編製索引
  • 排程和變更偵測，只針對一段時間的新增和變更文件編製索引

索引子排程可從上一個已知停止點繼續處理。 假如使用提供變更偵測的資料來源，當資料未在處理視窗中完整編製索引時，索引子在下次執行時會從離開的位置繼續處理。

將資料分割成較小的個別資料來源可實現平行處理作業。 您可以將來源資料分割成 Azure Blob 記憶體中的多個容器、為每個分割區建立資料來源，然後平行執行索引子，但會受限於搜尋服務的搜尋單位數目。

檢查索引子批次大小

如同推送 API 一樣，索引子可讓您設定每個批次的項目數目。 針對以建立索引子 REST API 為基礎的索引子，您可以設定 batchSize 引數以自訂此設定，以便更加符合資料的特性。

默認批次大小是數據源特定的。 Azure SQL 資料庫 和 Azure Cosmos DB 的預設批次大小為 1,000。 相較之下，Azure Blob 索引編製作業會在發現平均文件大小較大時，將批次大小設定為 10 個文件。

排程長時間執行流程的索引子

索引子排程是一種重要機制，用於處理大型資料集以及容納緩慢執行的流程 (例如，擴充管線中的影像分析)。

一般而言，索引器處理會在兩小時內執行。 如果編製索引工作負載無法在數小時完成，而需要數天時間，您可以將索引子放在每隔兩小時啟動的連續週期性排程上。 假設數據源 已啟用變更追蹤，索引器會繼續處理上次離開的位置。 依此步調，索引子可在數天內陸續處理待處理項目，直到所有未處理的文件都完成為止。

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

當數據源中不再有任何新的或更新的檔時，索引器執行歷程記錄會報告 0/0 已處理的檔，而且不會進行任何處理。

如需設定排程的詳細資訊，請參閱 建立索引器 REST API ，或參閱 為 Azure AI 搜尋排程索引器。

注意

在舊版執行階段結構上執行的部分索引子的處理時間範圍上限為 24 小時，而不是 2 小時。 兩小時的限制適用於在 內部管理的多租用戶環境中執行的較新內容處理器。 在可能的情況下，Azure AI 搜尋服務會嘗試將索引子和技能集處理卸除至多租用戶環境。 如果索引器無法移轉，它會在私人環境中執行，而且可以執行長達 24 小時。 如果您要排程顯示這些特性的索引器，請假設 24 小時處理視窗。

平行執行索引子

如果您分割資料，則可以建立多個索引子-資料-來源組合，從每個資料來源提取資料並寫入至相同的搜尋索引。 因為每個索引子都不同，所以您可以同時執行，這比依序執行搜尋索引更快填入搜尋索引。

確定您有足夠的容量。 服務中的單一搜尋單位一次只能執行一個索引子。 只有在多個索引子能以平行的方式執行時，建立多個索引子才會很有用。

可以同時執行的編製索引作業數目會由於文字型和技能型索引而有所不同。 如需詳細資訊，請參閱索引子執行。

如果您的資料來源是 Azure Blob 儲存體容器或 Azure Data Lake Storage Gen 2，列舉大量 Blob 可能需要很長的時間 (甚至數小時)，直到此作業完成為止。 因此，索引器 的檔成功 計數似乎不會在那個時間增加，而且它似乎不會有任何進展，當它。 如果您想要針對大量 Blob 進行更快的文件處理，請考慮將資料分割成多個容器，並建立指向單一索引的平行索引子。

  1. 登入 Azure 入口網站，並檢查搜尋服務所使用的搜尋單位數目。 選取 [設定]>[調整] 以檢視頁面頂端的數字。 平行執行的索引器數目大致等於搜尋單位的數目。

  2. 在多個容器之間或在相同容器內多個虛擬資料夾之間分割資料。

  3. 建立多個資料來源 (每個分割區各一個)，與其自己的索引子配對。

  4. 在每個索引子中指定相同的目標搜尋索引。

  5. 排程索引子。

  6. 檢閱索引子狀態和執行歷程記錄以進行確認。

有一些與平行編制索引相關聯的風險。 首先，請記得索引編製不會在背景執行，增加查詢節流或卸除的可能性。

其次，Azure AI 搜尋服務不會鎖定更新的索引。 並行寫入會加以管理，如果特定寫入在第一次嘗試時未成功，則會叫用重試，但您可能會注意到編製索引失敗的次數增加。

雖然多個索引子-資源-來源集合可以將相同的索引設為目標，但請小心可能覆寫索引中現有值的索引子執行。 如果第二個索引器-數據源以相同的檔和欄位為目標，則會覆寫第一次執行中的任何值。 欄位值會以完整方式取代；索引子無法將多個執行中的值合併到相同的欄位。

在 Spark 上編製巨量資料的索引

如果您有巨量資料架構，且資料位於 Spark 叢集上，建議使用 SynapseML 來載入和編製資料索引。 本教學課程包含呼叫 Azure AI 服務以進行 AI 擴充的步驟，但您也可以使用 AzureSearchWriter API 進行文字索引編製。

相關內容