Indexerare i Azure Cognitive Search

En indexerare i Azure Cognitive Search är en crawler som extraherar sökbar text och metadata från en extern Azure-datakälla och fyller i ett sökindex med fält-till-fält-mappningar mellan källdata och ditt index. Den här metoden kallas ibland för en "pull-modell" eftersom tjänsten hämtar data utan att du behöver skriva någon kod som lägger till data i ett index. Indexerare driver också AI-berikningsfunktioner i Cognitive Search, integrerar extern bearbetning av innehåll på väg till ett index.

Indexerare är endast Azure, med enskilda indexerare för Azure SQL, Azure Cosmos DB, Azure Table Storage och Blob Storage. När du konfigurerar en indexerare anger du en datakälla (ursprung) samt ett index (mål). Flera källor, till exempel Blob Storage, har ytterligare konfigurationsegenskaper som är specifika för den innehållstypen.

Du kan köra indexerare på begäran eller enligt ett återkommande datauppdateringsschema som körs så ofta som var femte minut. Mer frekventa uppdateringar kräver en push-modell som uppdaterar data i både Azure Cognitive Search och din externa datakälla.

Användningsscenarier

Du kan använda en indexerare som enda metod för datainmatning, eller som en del av en kombination av tekniker som läser in och eventuellt transformerar eller utökar innehåll på vägen. I följande tabell sammanfattas de viktigaste scenarierna.

Scenario Strategi
Enskild datakälla Det här mönstret är det enklaste: en datakälla är den enda innehållsleverantören för ett sökindex. Från källan identifierar du ett fält som innehåller unika värden som fungerar som dokumentnyckel i sökindexet. Det unika värdet används som en identifierare. Alla andra källfält mappas implicit eller explicit till motsvarande fält i ett index.

Det är viktigt att komma ihåg att värdet för en dokumentnyckel kommer från källdata. En söktjänst genererar inte nyckelvärden. Vid efterföljande körningar läggs inkommande dokument med nya nycklar till, medan inkommande dokument med befintliga nycklar antingen sammanfogas eller skrivs över, beroende på om indexfält är null eller ifyllda.
Flera datakällor Ett index kan acceptera innehåll från flera källor, där varje körning hämtar nytt innehåll från en annan källa.

Ett resultat kan vara ett index som får dokument när varje indexerare har körts, där hela dokument har skapats i sin helhet från varje källa. Dokument 1–100 kommer till exempel från Blob Storage, dokument 101–200 kommer från Azure SQL och så vidare. Utmaningen för det här scenariot är att utforma ett indexschema som fungerar för alla inkommande data och en dokumentnyckelstruktur som är enhetlig i sökindexet. Inbyggt anges de värden som unikt identifierar ett dokument metadata_storage_path i en blobcontainer och en primärnyckel i en SQL tabell. Du kan föreställa dig att en eller båda källorna måste ändras för att tillhandahålla nyckelvärden i ett gemensamt format, oavsett innehållets ursprung. I det här scenariot bör du förvänta dig att utföra någon nivå av förbearbetning för att homogenisera data så att de kan hämtas till ett enda index.

Ett alternativt resultat kan vara sökdokument som fylls i delvis vid den första körningen och sedan fylls i ytterligare av efterföljande körningar för att hämta värden från andra källor. Till exempel kommer fälten 1–10 från Blob Storage, 11–20 från Azure SQL och så vidare. Utmaningen med det här mönstret är att se till att varje indexeringskörning har samma dokument som mål. Sammanslagning av fält i ett befintligt dokument kräver en matchning av dokumentnyckeln. En demonstration av det här scenariot finns i Självstudie: Indexera från flera datakällor.
Flera indexerare Om du använder flera datakällor kan du också behöva flera indexerare om du behöver variera körningstidsparametrar, schemat eller fältmappningar. Även om flera indexeringsdatakälluppsättningar kan ha samma index som mål bör du vara försiktig med indexeringskörningar som kan skriva över befintliga värden i indexet. Om en andra indexerare-datakälla har samma dokument och fält som mål skrivs alla värden från den första körningen över. Fältvärden ersätts i sin helhet. en indexerare kan inte sammanfoga värden från flera körningar i samma fält.

Ett annat användningsfall med flera indexerare är skalning mellan regioner utanför Cognitive Search. Du kan ha kopior av samma sökindex i olika regioner. Om du vill synkronisera sökindexinnehåll kan flera indexerare hämta från samma datakälla, där varje indexerare har ett annat sökindex.

Parallell indexering av mycket stora datamängder kräver också en strategi för flera indexerare. Varje indexerare har en delmängd av data som mål.
Innehållstransformering Cognitive Search har stöd för valfria AI-berikningsbeteenden som lägger till bildanalys och bearbetning av naturligt språk för att skapa nytt sökbart innehåll och struktur. AI-berikning är indexerardriven, via en bifogad kompetensuppsättning. För att utföra AI-berikning behöver indexeraren fortfarande ett index och en Azure-datakälla, men i det här scenariot lägger den till kompetensuppsättningsbearbetning i indexerarkörningen.

Datakällor som stöds

Indexerare crawlar datalager i Azure och utanför Azure.

Indexeraranslutningar till fjärranslutna datakällor kan göras med hjälp av vanliga Internetanslutningar (offentliga) eller krypterade privata anslutningar när du använder virtuella Azure-nätverk för klientappar. Du kan också konfigurera anslutningar för autentisering med hjälp av en betrodd tjänstidentitet. Mer information om säkra anslutningar finns i Bevilja åtkomst via privata slutpunkter och Anslut till en datakälla med hjälp av en hanterad identitet.

Steg för indexering

När indexet är tomt vid en första körning läser indexeraren alla data som anges i tabellen eller containern. Vid efterföljande körningar kan indexeraren vanligtvis identifiera och hämta bara de data som har ändrats. För blobdata är ändringsidentifiering automatisk. För andra datakällor som Azure SQL eller Cosmos DB måste ändringsidentifiering vara aktiverat.

För varje dokument som den tar emot implementerar eller koordinerar en indexerare flera steg, från dokumenthämtning till en slutlig "handoff"-sökmotor för indexering. En indexerare kan också köra och mata ut färdigheter, förutsatt att en kompetensuppsättning har definierats.

Indexerarfaser

Steg 1: Dokumentknrickning

Dokumentknrickning är processen att öppna filer och extrahera innehåll. Textbaserat innehåll kan extraheras från filer på en tjänst, rader i en tabell eller objekt i container eller samling. Om du lägger till en kompetensuppsättning och bildfärdigheter i en indexerare kan dokumentknrickning också extrahera bilder och köa dem för bearbetning.

Beroende på datakällan kommer indexeraren att prova olika åtgärder för att extrahera potentiellt indexerbart innehåll:

  • När dokumentet är en fil, till exempel en PDF-fil eller ett annat filformat som stöds i Azure Blob Storage, öppnar indexeraren filen och extraherar text, bilder och metadata. Indexerare kan också öppna filer från SharePoint och Azure Data Lake Storage Gen2.

  • När dokumentet är en post i Azure SQL, extraherar indexeraren icke-binärt innehåll från varje fält i varje post.

  • När dokumentet är en post i Cosmos DB, extraherar indexeraren icke-binärt innehåll från fält och underfält från Cosmos DB dokumentet.

Steg 2: Fältmappningar

En indexerare extraherar text från ett källfält och skickar den till ett målfält i ett index eller kunskapslager. När fältnamn och fälttyper sammanträffar är sökvägen tydlig. Men du kanske vill ha olika namn eller typer i utdata, i så fall måste du berätta för indexeraren hur fältet ska mappa.

Det här steget inträffar efter dokumentknrickning, men före transformeringen, när indexeraren läser från källdokumenten. När du definierar en fältmappningskickas värdet för källfältet som det är till målfältet utan ändringar.

Steg 3: Körning av kunskapsuppsättning

Körning av kunskapsuppsättning är ett valfritt steg som anropar inbyggd eller anpassad AI-bearbetning. Du kan behöva den för optisk teckenläsning (OCR) i form av bildanalys om källdata är en binär bild, eller om du behöver språköversättning om innehållet finns på olika språk.

Oavsett omvandling är kompetensuppsättningskörningen den plats där berikande sker. Om en indexerare är en pipeline kan du tänka på en kompetensuppsättning som en "pipeline i pipelinen".

Steg 4: Mappningar av utdatafält

Om du inkluderar en kunskapsuppsättning behöver du troligen inkludera mappningar för utdatafält. Utdata från en kunskapsuppsättning är egentligen ett träd med information som kallas för det berikade dokumentet. Med mappningar av utdatafält kan du välja vilka delar av det här trädet som ska mappa till fält i ditt index. Lär dig hur du definierar mappningar för utdatafält.

Medan fältmappningar associerar ordagranna värden från datakällan till målfälten talar utdatafältmappningar om för indexeraren hur transformerade värden i det berikade dokumentet ska associeras med målfälten i indexet. Till skillnad från fältmappningar, som anses valfria, måste du alltid definiera en utdatafältmappning för allt transformerat innehåll som måste finnas i ett index.

Nästa bild visar en exempelrepresentation av indexeringssessionen för indexeraren: dokumentknrickning, fältmappningar, körning av kunskapsuppsättning och mappningar av utdatafält.

exempel på felsökningssession

Grundläggande arbetsflöde

Indexerare kan erbjuda funktioner som är unika för datakällan. I detta avseende varierar vissa aspekter av indexerarna och datakällskonfigurationen kan variera efter indexerartyp. Alla indexerare delar dock samma grundläggande sammansättning och krav. De steg som är gemensamma för alla indexerare beskrivs nedan.

Steg 1: Skapa en datakälla

Indexerare kräver ett datakällobjekt som tillhandahåller en anslutningssträng och eventuellt autentiseringsuppgifter. Anropa klassen Create Data Source (REST) eller SearchIndexerDataSourceConnection för att skapa resursen.

Datakällor konfigureras och hanteras oberoende av indexerarna som använder dem, vilket innebär att en datakälla kan användas av flera indexerare för att läsa in mer än ett index i taget.

Steg 2: Skapa ett index

En indexerare automatiserar vissa uppgifter som rör datapåfyllning, men att skapa ett index är vanligtvis inte en av dem. Som krav måste du ha ett fördefinierat index med fält som matchar de i din externa datakälla. Fälten måste matcha efter namn och datatyp. Annars kan du definiera fältmappningar för att upprätta associationen. Mer information om hur du strukturerar ett index finns i Skapa ett index (REST) eller SearchIndex-klassen.

Tips

Indexerare kan inte generera ett index åt dig, men du kan få hjälp av guiden Importera data i portalen. I de flesta fall kan guiden härleda ett indexschema från befintliga metadata i källan, vilket skapar ett preliminärt indexschema som du kan redigera direkt när guiden är aktiv. När indexet har skapats i tjänsten är ytterligare redigeringar i portalen i huvudsak begränsade till tillägg av nya fält. Överväg att använda guiden för att skapa, men inte revidera, ett index. I steg-för-steg-beskrivningen för portalen kan du få en praktisk genomgång.

Steg 3: Skapa och kör (eller schemalägg) indexeraren

En indexerare körs när du först skapar en indexerare i söktjänsten. Det är bara när du skapar eller kör indexeraren som du får reda på om datakällan är tillgänglig eller om kunskapsuppsättningen är giltig. Efter den första körningen kan du köra den igen på begäran med hjälp av Kör indexeraren,eller så kan du definiera ett återkommande schema.

Du kan övervaka indexerarstatusen i portalen eller via API:et För indexeringsstatus. Du bör också köra frågor på indexet för att kontrollera att resultatet är det du förväntade dig.

Nästa steg

Nu när du har introducerats är ett nästa steg att granska indexeraregenskaper och parametrar, schemaläggning och övervakning av indexerare. Du kan också gå tillbaka till listan över datakällor som stöds för mer information om en specifik källa.