Indexar grandes conjuntos de dados no Pesquisa de IA do Azure

Se você precisar indexar conjuntos de dados grandes ou complexos em sua solução de pesquisa, este artigo explora estratégias para acomodar processos de longa execução no Pesquisa de IA do Azure.

Essas estratégias pressupõem familiaridade com as duas abordagens básicas para importar dados: enviar dados para um índice ou extrair dados de uma fonte de dados suportada usando um indexador de pesquisa. Se o seu cenário envolve enriquecimento de IA intensivo em computação, então os indexadores são necessários, devido à dependência nas habilidades dos indexadores.

Este artigo complementa Dicas para um melhor desempenho, que oferece práticas recomendadas sobre design de índice e consulta. Um índice bem projetado que inclua apenas os campos e atributos necessários é um pré-requisito importante para a indexação em larga escala.

Use um serviço de pesquisa criado após 3 de abril de 2024 para maior armazenamento por partição. Também pode atualizar serviços antigos para beneficiar de maior armazenamento de partições.

Indexar dados com as APIs de push

As APIs push, como a API REST do Índice de Documentos ou o método IndexDocuments (SDK do Azure para .NET), são a forma mais prevalente de indexação no Pesquisa de IA do Azure. Para soluções que usam uma API push, a estratégia para indexação de longa execução tem um ou ambos os seguintes componentes:

• Envio de documentos em lote
• Gerenciando threads

Lote de vários documentos por solicitação

Um mecanismo simples para indexar uma grande quantidade de dados é enviar vários documentos ou registros em uma única solicitação. Desde que toda a carga útil esteja abaixo de 16 MB, uma solicitação pode lidar com até 1.000 documentos em uma operação de upload em massa. Esses limites se aplicam se você estiver usando a API REST do Índice de Documentos ou o método IndexDocuments no SDK do .NET. Usando qualquer uma das APIs, você pode empacotar 1.000 documentos no corpo de cada solicitação.

O envio de documentos em lote reduz significativamente o tempo necessário para trabalhar em um grande volume de dados. Determinar o tamanho de lote ideal para seus dados é um componente fundamental para otimizar as velocidades de indexação. Os dois principais fatores que influenciam o tamanho ideal do lote são:

• O esquema do seu índice
• O tamanho dos seus dados

Como o tamanho de lote ideal depende do seu índice e dos seus dados, a melhor abordagem é testar diferentes tamanhos de lote para determinar qual deles resulta nas velocidades de indexação mais rápidas para o seu cenário. Para obter código de exemplo para testar tamanhos de lote usando o SDK do .NET, consulte Tutorial: Otimizar a indexação com a API push.

Gerenciar threads e uma estratégia de repetição

Os indexadores têm gerenciamento de threads interno, mas quando você está usando as APIs push, o código do aplicativo precisa gerenciar threads. Certifique-se de que há threads suficientes para fazer pleno uso da capacidade disponível, especialmente se você atualizou recentemente seu serviço, mudou para um nível de preço mais alto ou aumentou partições.

1. Aumente o número de threads simultâneos no código do cliente.

2. À medida que você aumenta as solicitações que chegam ao serviço de pesquisa, você pode encontrar códigos de status HTTP indicando que a solicitação não foi totalmente bem-sucedida. Durante a indexação, dois códigos de status HTTP comuns são:

   • 503 Serviço indisponível: Este erro significa que o sistema está sob carga pesada e o seu pedido não pode ser processado neste momento.

   • 207 Multi-Status: Este erro significa que alguns documentos foram bem-sucedidos, mas pelo menos um falhou.

3. Para lidar com falhas, as solicitações devem ser repetidas usando uma estratégia de repetição de backoff exponencial.

O SDK do Azure .NET faz automaticamente a nova tentativa de processar as solicitações 503 e outras falhas, mas é necessário implementar a sua própria lógica para novas tentativas de processar as solicitações 207. Ferramentas de código aberto como Polly também podem ser usadas para implementar uma estratégia de repetição.

Usar indexadores e APIs de extração

Os indexadores oferecem várias capacidades úteis para processos de longa duração:

• Envio de documentos em lote
• Indexação paralela sobre dados particionados
• Agendamento e deteção de alterações para indexar apenas documentos novos e alterados ao longo do tempo

As agendas do indexador podem retomar o processamento no último ponto de parada conhecido. Se os dados não estiverem totalmente indexados dentro da janela de processamento, o indexador retoma onde ficou na execução seguinte, assumindo que está a usar uma fonte de dados que fornece deteção de alterações.

O particionamento de dados em fontes de dados individuais menores permite o processamento paralelo. Você pode dividir os dados de origem, como em vários contêineres no Armazenamento de Blobs do Azure, criar uma fonte de dados para cada partição e, em seguida , executar os indexadores em paralelo, sujeito ao número de unidades de pesquisa do seu serviço de pesquisa.

Verificar o tamanho do lote do indexador

Assim como acontece com a API push, os indexadores permitem configurar o número de itens por lote. Para indexadores baseados na API Create Indexer REST, defina o batchSize argumento para personalizar esta definição de forma a corresponder melhor às características dos seus dados.

Os tamanhos de lote padrão são específicos da fonte de dados. O Banco de Dados SQL do Azure e o Azure Cosmos DB têm um tamanho de lote padrão de 1.000. Em contraste, a indexação do Azure Blob e do SharePoint (pré-visualização) definem o tamanho do lote em 10 documentos, tendo em conta a maior dimensão média dos documentos.

Programar indexadores para processos de longa execução

O agendamento de indexadores é um mecanismo importante para processar grandes conjuntos de dados e acomodar processos lentos, como análise de imagem, em um pipeline de enriquecimento.

Normalmente, o processamento do indexador é executado dentro de uma janela de duas horas. Se a carga de trabalho de indexação levar dias em vez de horas para ser concluída, você poderá colocar o indexador em uma agenda consecutiva e recorrente que começa a cada duas horas. Supondo que a fonte de dados tenha o controle de alterações habilitado, o indexador retomará o processamento de onde parou pela última vez. Nessa cadência, um indexador pode percorrer uma lista de pendências de documentos durante uma série de dias até que todos os documentos não processados sejam processados. Esse padrão é especialmente importante durante a execução inicial ou ao indexar grandes contentores de blob, onde a fase de listagem de blob pode, sozinha, levar várias horas ou dias. Durante este tempo, o indexador não mostra quaisquer blobs a serem processados, mas, a menos que seja comunicado um erro, é provável que ainda esteja a percorrer a lista de blobs. O processamento e o enriquecimento de documentos começam somente após a conclusão dessa fase, e esse comportamento é esperado.

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

Quando já não há documentos novos ou atualizados na fonte de dados, o histórico de execução do indexador relata 0/0 os documentos processados e nenhum processamento é realizado.

Para obter mais informações sobre como definir agendas, consulte Criar API REST do indexador ou consulte Agendar indexadores para o Pesquisa de IA do Azure.

Se o seu indexador utilizar um conjunto de competências com cache de enriquecimento, consulte as informações seguintes antes de ativar a cache para cargas de trabalho em grande escala.

Executar indexadores em paralelo

Se você particionar seus dados, poderá criar várias combinações de indexador-fonte de dados que extraem de cada fonte de dados e gravem no mesmo índice de pesquisa. Como cada indexador é distinto, pode executá-los ao mesmo tempo, por isso preenche um índice de pesquisa mais rapidamente do que se os executasse sequencialmente.

Certifique-se de que tem capacidade suficiente. Uma unidade de pesquisa em seu serviço pode executar um indexador a qualquer momento. A criação de vários indexadores só é útil se eles puderem ser executados em paralelo.

O número de trabalhos de indexação que podem ser executados simultaneamente varia para indexação baseada em texto e em habilidades. Para obter mais informações, consulte Execução do indexador.

Se sua fonte de dados for um contêiner do Armazenamento de Blobs do Azure ou o Azure Data Lake Storage Gen 2, enumerar um grande número de blobs pode levar muito tempo (até mesmo horas) até que essa operação seja concluída. Como resultado, a contagem de documentos processados com êxito do seu indexador não parece aumentar durante esse período e pode dar a impressão de que não está a fazer progressos, quando, na realidade, está. Se quiser que o processamento de documentos seja mais rápido para um grande número de blobs, considere particionar os seus dados em vários contentores e criar indexadores paralelos que apontem para um único índice.

1. Vá para o seu serviço de pesquisa no portal do Azure.

2. Verifique o número de unidades de pesquisa utilizadas pelo seu serviço de pesquisa. Selecione Escala de configurações>para visualizar o número na parte superior da página. O número de indexadores que são executados em paralelo é aproximadamente igual ao número de unidades de pesquisa.

3. Particione dados de origem entre vários contêineres ou várias pastas virtuais dentro do mesmo contêiner.

4. Crie várias fontes de dados, uma para cada partição, emparelhadas com seu próprio indexador.

5. Especifique o mesmo índice de pesquisa de destino em cada indexador.

6. Agende os indexadores.

7. Revise o status do indexador e o histórico de execução para confirmação.

Existem alguns riscos associados à indexação paralela. Primeiro, lembre-se que a indexação não é executada em segundo plano, o que aumenta a probabilidade de as consultas serem limitadas ou eliminadas.

Em segundo lugar, o Pesquisa de IA do Azure não bloqueia o índice para atualizações. As escritas concorrentes são geridas efetuando uma nova tentativa se uma determinada operação de escrita falhar à primeira tentativa, mas poderá verificar-se um aumento das falhas de indexação.

Embora vários conjuntos de fontes de dados do indexador possam ter como destino o mesmo índice, tenha cuidado com as execuções do indexador que podem substituir os valores existentes no índice. Se uma segunda fonte de dados indexadora tiver como destino os mesmos documentos e campos, todos os valores da primeira execução serão substituídos. Os valores dos campos são substituídos na íntegra; Um indexador não pode mesclar valores de várias execuções no mesmo campo.

Indexar big data no Spark

Se tem uma arquitetura de big data e os seus dados estão num cluster Spark, use o SynapseML para carregar e indexar dados. O tutorial inclui passos para chamar Foundry Tools para enriquecimento de IA, mas também pode usar a API AzureSearchWriter para indexação de texto.

Conteúdos relacionados

• Tutorial: Otimize a indexação usando a API push
• Tutorial: Indexar dados grandes do Apache Spark usando SynapseML e Pesquisa de IA do Azure
• Dicas para um melhor desempenho na Pesquisa de IA do Azure
• Analisar o desempenho na Pesquisa de IA do Azure
• Indexadores na Pesquisa de IA do Azure
• Monitorar o status e os resultados do indexador na Pesquisa de IA do Azure