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

附註

Azure AI 搜尋服務 可透過 Azure 入口網站、REST API 及 Azure SDK 取得。 它同時也是 Foundry IQ 的基礎，這是一個管理式知識層，能將企業內容轉化為可重複使用、權限感知的知識庫，供 Microsoft Foundry 入口網站中的代理使用。

如果您需要在搜尋解決方案中編製大型或複雜資料集的索引，本文會探索在 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 和其他失敗的要求，但您必須實作自己的邏輯才能重試 207。 您也可以使用 Polly 等開放原始碼工具來實作重試策略。

使用索引子和提取 API

索引器 提供多項對長時間執行程序有用的功能：

  • 批次處理文件
  • 分割資料的平行編製索引
  • 排程和變更偵測，僅對新增和已變更的文件逐步編製索引

索引子排程可從上一個已知停止點繼續處理。 如果資料在處理視窗內沒有完全索引，索引器會在下一次執行時從中斷的地方繼續，前提是你使用的是提供變更偵測的資料來源。

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

檢查索引子批次大小

如同推送 API 一樣，索引子可讓您設定每個批次的項目數目。 對於基於 Create Indexer REST API 的索引器，請設定 batchSize 參數以自訂此設定，以更符合你資料的特性。

預設批次大小是資料來源特定的。 Azure SQL Database 和 Azure Cosmos DB 的預設批次大小為 1,000。 相較之下，Azure Blob 和 SharePoint（預覽版）索引將批次大小設為 10 份文件，以反映平均文件大小較大。

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

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

一般而言，索引子處理時間在 2 小時內。 如果編製索引工作負載無法在數小時完成，而需要數天時間，您可以將索引子放在每隔兩小時啟動的連續週期性排程上。 假設資料來源已啟用變更追蹤，索引子會從上次離開的位置繼續處理。 依此步調，索引子可在數天內陸續處理待處理項目，直到所有未處理的文件都完成為止。 此模式在初始執行期間或為大型 Blob 容器編製索引時特別重要，其中 Blob 清單階段本身可能需要數小時或數天的時間。 在此期間，索引子會顯示未處理任何 Blob；但除非系統回報錯誤，否則索引子可能仍在逐一檢查 Blob 清單。 只有在此階段完成之後，文件處理和擴充才會開始，而且此行為是預期的。

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

當資料來源中已無任何新增或更新的文件時，索引子執行歷程記錄會報告已處理 0/0 個文件，且不會進行任何處理。

如需設定排程的詳細資訊，請參閱建立索引子 REST API，或參閱針對 Azure AI 搜尋服務排程索引子。

附註

最大處理時間窗口取決於索引者是否具備相關技能。 具備技能的索引員在 內部管理的多租戶環境中 運作，最多工作時間為2小時。 設定為共用 私有連結 的索引器最多可運行 24 小時。 未使用技能的索引子執行時間上限為 24 小時。

如果索引子使用具備擴充快取的技能，請先檢閱下列資訊，再針對大規模工作負載啟用快取。

注意事項

若工作負載包含長時間執行的技能、重複中斷或頻繁失敗，擴充快取可能會增加初始擷取或復原期間的總重新處理量。 擴充快取不是備份，也不會追蹤哪些文件已完成處理。

平行執行索引子

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

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

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

如果您的資料來源是 Azure Blob 儲存體容器或 Azure Data Lake Storage Gen 2，列舉大量 Blob 可能需要很長的時間 (甚至數小時)，直到此作業完成為止。 因此，在這段期間，你的索引器的成功處理文件計數似乎不會增加，而且可能看起來像是毫無進展，但實際上並非如此。 如果你想讓大量 blob 的文件處理更快，可以考慮將資料分割成多個容器，並建立指向單一索引的平行索引器。

  1. 在 Azure 入口網站中移至您的搜尋服務。

  2. 查看您的搜尋服務所使用的搜尋單位數量。 選取 [設定]>[調整] 以檢視頁面頂端的數字。 將平行執行的索引子數目大約等於搜尋單位的數目。

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

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

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

  6. 排程索引子。

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

有一些與平行編制索引相關聯的風險。 首先，請記得索引不會在背景執行，這增加了查詢被限速或丟棄的機率。

其次，Azure AI 搜尋服務不會鎖定更新的索引。 並行寫入是透過在某次寫入首次嘗試未成功時觸發重試機制來處理，但你可能會注意到索引失敗次數增加。

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

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

如果你有大數據架構，且資料在 Spark 叢集上，使用 SynapseML 來載入和索引資料。 教學包含呼叫 Foundry 工具以進行 AI 豐富化的步驟，但你也可以使用 AzureSearchWriter API 來進行文字索引。

相關內容

  • Last updated on