Indexar grandes conjuntos de dados no Azure AI Search

Artigo
04/01/2024

Se os requisitos da sua solução de pesquisa incluírem indexação de big data ou dados complexos, este artigo articula estratégias para acomodar processos de longa execução no Azure AI Search.

Este artigo pressupõe familiaridade com as duas abordagens básicas para importar dados: enviar dados por push para um índice ou extrair dados de uma fonte de dados suportada usando um indexador de pesquisa. Se o seu cenário envolve enriquecimento computacionalmente intensivo de IA, então os indexadores são necessários, dada a dependência do conjunto de 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.

Recomendamos o uso de um serviço de pesquisa mais recente, criado após 3 de abril de 2024, para maior armazenamento por partição.

Nota

As estratégias descritas neste artigo assumem uma única fonte de dados grande. Se sua solução exigir indexação de várias fontes de dados, consulte Indexar várias fontes de dados na Pesquisa de IA do Azure para obter uma abordagem recomendada.

Indexar dados grandes usando 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 Azure AI Search. Para soluções que usam uma API push, a estratégia para indexação de longa execução terá 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é 1000 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. Para qualquer API, você empacotaria 1000 documentos no corpo de cada solicitação.

A distribuição de documentos em lote reduzirá 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. Tutorial: Otimizar a indexação com a API push fornece código de exemplo para testar tamanhos de lote usando o SDK do .NET.

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

Os indexadores têm gerenciamento de threads integrado, mas quando você estiver usando as APIs push, o código do aplicativo terá que gerenciar threads. Certifique-se de que há threads suficientes para fazer pleno uso da capacidade disponível, especialmente se você aumentou partições recentemente ou atualizou para um serviço de pesquisa de camada mais alta.

Aumente o número de threads simultâneos no código do cliente.
À 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.
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 tenta automaticamente 503s e outras solicitações com falha, mas você precisará implementar sua própria lógica para repetir 207s. Ferramentas de código aberto como Polly também podem ser usadas para implementar uma estratégia de repetição.

Índice com indexadores e APIs "pull"

Os indexadores têm vários recursos que são úteis para processos de longa execuçã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 alterar 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 na janela de processamento, o indexador será retomado de onde parou na próxima execução, supondo que você esteja usando uma fonte de dados que forneça 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 REST do Indexador de Criação, você pode definir o batchSize argumento para personalizar essa configuração para 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 1000. Por outro lado, a indexação de Blob do Azure define o tamanho do lote em 10 documentos em reconhecimento ao tamanho médio maior do documento.

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 2 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 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.

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

Quando não houver mais documentos novos ou atualizados na fonte de dados, o histórico de execução do indexador relatará 0/0 os documentos processados e nenhum processamento ocorrerá.

Para obter mais informações sobre como definir agendas, consulte Criar API REST do indexador ou Como agendar indexadores para o Azure AI Search.

Nota

Alguns indexadores que são executados em uma arquitetura de tempo de execução mais antiga têm uma janela de processamento máxima de 24 horas em vez de 2 horas. O limite de 2 horas é para processadores de conteúdo mais recentes executados em um ambiente multilocatário gerenciado internamente. Sempre que possível, o Azure AI Search tenta descarregar o indexador e o processamento do conjunto de competências para o ambiente multilocatário. Se o indexador não puder ser migrado, ele será executado no ambiente privado e poderá ser executado por até 24 horas. Se você estiver agendando um indexador que exiba essas características, suponha uma janela de processamento de 24 horas.

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, você pode executá-los ao mesmo tempo, preenchendo 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. Isso fará com que a contagem de documentos bem-sucedidos do indexador não seja aumentada durante esse tempo e pode parecer que não está progredindo, quando está. Se você quiser que o processamento de documentos seja mais rápido para um grande número de blobs, considere particionar seus dados em vários contêineres e criar indexadores paralelos apontando para um único índice.

Entre no portal do Azure e verifique o número de unidades de pesquisa usadas 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 serão executados em paralelo é aproximadamente igual ao número de unidades de pesquisa.
Particione dados de origem entre vários contêineres ou várias pastas virtuais dentro do mesmo contêiner.
Crie várias fontes de dados, uma para cada partição, emparelhadas com seu próprio indexador.
Especifique o mesmo índice de pesquisa de destino em cada indexador.
Agende os indexadores.
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 de que a indexação não é executada em segundo plano, aumentando a probabilidade de que as consultas sejam limitadas ou descartadas.

Em segundo lugar, o Azure AI Search não bloqueia o índice para atualizações. As gravações simultâneas são gerenciadas, invocando uma nova tentativa se uma determinada gravação não for bem-sucedida na primeira tentativa, mas você pode notar um aumento nas 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 você tiver uma arquitetura de big data e seus dados estiverem em um cluster do Spark, recomendamos o SynapseML para carregar e indexar dados. O tutorial inclui etapas para chamar serviços de IA do Azure para enriquecimento de IA, mas você também pode usar a API AzureSearchWriter para indexação de texto.