Indexar grandes conjuntos de dados no Azure Search

Se os requisitos da solução de pesquisa incluem a indexação de Big Data ou de dados complexos, este artigo articula estratégias para acomodar os processos de execução longa na Pesquisa de IA do Azure.

Este artigo pressupõe familiaridade com as duas abordagens básicas para importar dados: enviar dados por push para um índice ou efetuar pull de dados de uma fonte de dados com suporte usando um indexador de pesquisa. Se o cenário envolver o enriquecimento de IA com uso intensivo de computação, serão necessários indexadores, considerando a dependência do conjunto de habilidades neles.

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

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

Observação

As estratégias descritas neste artigo pressupõem uma única fonte de dados grande. Se sua solução exigir indexação de várias fontes de dados, confira Indexar várias fontes de dados no Azure Cognitive Search para obter uma abordagem recomendada.

Indexar grandes volumes de dados usando as APIs de push

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

  • Envio em lote de documentos
  • Como gerenciar threads

Vários documentos em lote por solicitação

Um mecanismo simples para indexar uma grande quantidade de dados é enviar vários documentos ou registros em uma solicitação. Como a carga inteira é menor que 16 MB, uma solicitação pode manipular até 1000 documentos em uma operação de upload em massa. Esses limites se aplicam se você está usando a API REST Índice de Documentos ou o método IndexDocuments no SDK do .NET. Para qualquer uma das APIs, você deve empacotar 1000 documentos no corpo de cada solicitação.

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

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

Como o tamanho de lote ideal depende do índice e dos dados, a melhor abordagem é testar diferentes tamanhos de lote para determinar o que resulta nas velocidades de indexação mais rápidas no seu cenário. O Tutorial: otimizar a indexação com a API de push fornece um código de exemplo para testar os tamanhos de lotes usando o SDK do .NET.

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

Os indexadores têm gerenciamento de thread interno; porém, quando você estiver usando as APIs push, o código do aplicativo deverá gerenciar threads. Verifique se há threads suficientes para fazer uso total da capacidade disponível, especialmente se você aumentou as partições recentemente ou atualizou para um serviço de pesquisa de camadas mais altas.

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

  2. Conforme você aumenta as solicitações que chegam ao serviço de pesquisa, pode encontrar códigos de status HTTP indicando que a solicitação não foi totalmente concluída com sucesso. Durante a indexação, dois códigos de status HTTP comuns são:

    • 503 Serviço Não Disponível – Esse erro significa que o sistema está sob carga pesada e sua solicitação não pode ser processada no momento.

    • 207 Status Múltiplo – esse erro significa que alguns documentos foram bem-sucedidos, mas pelo menos um deles falhou.

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

O SDK do .NET do Azure recupera automaticamente solicitações com o erro 503 e outras falha, mas você precisará implementar a sua lógica de repetição em caso de erros 207. Ferramentas de software livre, como Polly, também podem ser usadas para implementar uma estratégia de repetição.

Indexar com os indexadores e as APIs de pull

Os indexadores têm várias funcionalidades que são úteis para processos de execução prolongada:

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

Os agendamentos do indexador podem retomar o processamento no último ponto de interrupção conhecido. Se os dados não estiverem totalmente indexados na janela de processamento, o indexador continuará de onde parou na próxima execução, supondo que você esteja usando uma fonte de dados que fornece detecção de alterações.

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

Verificar o tamanho do lote do indexador

Assim como na API push, os indexadores permitem que você configure o número de itens por lote. Para indexadores com base em Criar o indexador do API REST, pode-se definir o batchSize argumento para personalizar essa configuração para corresponder melhor as características de 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. Em contraste, a indexação de Blobs do Azure define o tamanho do lote em 10 documentos ao reconhecer o maior tamanho médio do documento.

Agendar indexadores para processos de execução prolongada

O agendamento do indexador é um mecanismo importante para processar conjuntos de dados grandes e acomodar processos de execução lenta, como a análise de imagem em um pipeline de enriquecimento.

Normalmente, o processamento do indexador é executado em 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 um agendamento consecutivo 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. Nesse ritmo, um indexador pode percorrer uma lista de pendências de documentos em 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 documentos processados e nenhum processamento ocorrerá.

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

Observação

Alguns indexadores executados em uma arquitetura de runtime mais antiga têm uma janela de processamento máximo de 24 horas, em vez de duas horas. O limite de duas horas é para processadores de conteúdo mais recentes que são executados em um ambiente multilocatário gerenciado internamente. Sempre que possível, o Azure AI Search tenta descarregar o processamento do indexador e do conjunto de habilidades 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 atenda a essas características, suponha uma janela de processamento de 24 horas.

Executar indexadores em paralelo

Se você particionar os dados, poderá criar várias combinações do tipo “indexador-fonte de dados” que façam extrações de cada fonte de dados e gravações no mesmo índice de pesquisa. Como cada indexador é distinto, é possível executá-los ao mesmo tempo, o que preenche um índice de pesquisa mais rapidamente do que se você os tivesse executado sequencialmente.

Verifique se você 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ó será útil se eles puderem ser executados em paralelo.

O número de trabalhos de indexação que podem ser executados simultaneamente varia de acordo com a indexação baseada em texto e em habilidades. Para saber mais, confira Execução do indexador.

Se sua fonte de dados for um Contêiner de Armazenamento de Blobs do Azure ou Azure Data Lake Storage Gen 2, a enumeração de um grande número de blobs pode levar muito tempo (até horas) até que essa operação seja concluída. Isso fará com que a contagem de documentos bem-sucedidos do seu indexador não seja aumentada durante esse período e pode parecer que não está fazendo nenhum progresso, quando na verdade 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 crie indexadores paralelos apontando para apenas um índice.

  1. Entre no portal do Azure e verifique o número de unidades de pesquisa usadas pelo serviço de pesquisa. Selecione Configurações>Dimensionar para ver 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.

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

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

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

  5. Agende os indexadores.

  6. Examine o histórico de execução e o status do indexador para confirmação.

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

Segundo, o Azure AI Search não bloqueia o índice para atualizações. As gravações simultâneas são gerenciadas invocando uma nova tentativa quando uma gravação específica não é bem-sucedida na primeira tentativa, mas é possível observar um aumento nas falhas de indexação.

Embora vários conjuntos de fontes de dados de 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 de indexador tiver como destino os mesmos documentos e campos, todos os valores da primeira execução serão substituídos. Os valores de campo são substituídos por completo; 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 os serviços de IA do Azure para enriquecimento de IA, mas você também pode usar a API AzureSearchWriter para indexação de texto.

Confira também