Pular para o conteúdo principal
Última atualização em

Configurar o Auto Loader para cargas de trabalho de produção

Databricks recomenda que o senhor siga as práticas recomendadas de transmissão para executar o Auto Loader na produção.

Databricks recomenda o uso Auto Loader no pipeline declarativo LakeFlow Spark para aquisição incremental de dados. O pipeline declarativo LakeFlow Spark estende a funcionalidade do Apache Spark e permite que você escreva apenas algumas linhas de Python ou SQL declarativo para implantar um pipeline de dados de qualidade de produção com:

  • Dimensionamento automático da infraestrutura de computação para redução de custos
  • Verificações de qualidade de dados com expectativas
  • Tratamento automático da evolução do esquema
  • monitoramento via métricas no evento log

monitoramento Auto Loader​

Consulta de arquivos descobertos pelo Auto Loader​

nota

A função cloud_files_state está disponível em Databricks Runtime 11.3 LTS e acima.

Auto Loader fornece um SQL API para inspecionar o estado de uma transmissão. Usando a função cloud_files_state, o senhor pode encontrar metadados sobre arquivos que foram descobertos por uma transmissão Auto Loader. Basta consultar a partir de cloud_files_state, fornecendo o local do ponto de controle associado a uma transmissão Auto Loader.

SQL
SELECT * FROM cloud_files_state('path/to/checkpoint');

Ouça as atualizações da transmissão​

Para monitorar ainda mais Auto Loader a transmissão, Databricks o site recomenda Apache Spark o uso da interface Query Listener da transmissão.

Auto Loader informa métricas para o Query Listener de transmissão a cada lote. O senhor pode view quantos arquivos existem no backlog e qual o tamanho do backlog nas métricas numFilesOutstanding e numBytesOutstanding sob os dados brutos tab no painel de progresso da consulta de transmissão:

JSON
{
  "sources": [
    {
      "description": "CloudFilesSource[/path/to/source]",
      "metrics": {
        "numFilesOutstanding": "238",
        "numBytesOutstanding": "163939124006"
      }
    }
  ]
}

No Databricks Runtime 10.4 LTS e superior, ao usar o modo de notificação de arquivo, as métricas também incluem o número aproximado de eventos de arquivo em uma fila cloud como approximateQueueSize para AWS e Azure.

Considerações de custo​

Ao executar Auto Loader, suas principais fontes de custo são recursos compute e descoberta de arquivos.

Para reduzir os custos compute , Databricks recomenda o uso de LakeFlow Jobs para programar Auto Loader como trabalho em lote usando Trigger.AvailableNow em vez de executá-lo continuamente, a menos que você tenha requisitos de baixa latência. Consulte Configurar intervalos de disparo de transmissão estruturada. Esses trabalhos em lote podem ser acionados usando gatilhos de chegada de arquivos para reduzir ainda mais a latência entre a chegada do arquivo e o processamento.

Os custos de descoberta de arquivos podem vir na forma de operações LIST em sua conta de armazenamento no modo de listagem de diretório e solicitações API no serviço de inscrição e serviço de fila no modo de notificação de arquivos. Para reduzir os custos de descoberta de arquivos, a Databricks recomenda:

Arquive os arquivos no diretório de origem para reduzir custos.​

nota

Disponível no Databricks Runtime 16.4 LTS e versões superiores.

atenção
  • A configuração cloudFiles.cleanSource excluirá ou moverá arquivos no diretório de origem.
  • Se você usar foreachBatch para o processamento de seus dados, seus arquivos se tornarão candidatos a mover ou excluir assim que suas operações foreachBatch retornarem com sucesso, mesmo que suas operações tenham consumido apenas um subconjunto dos arquivos nos lotes.

Recomendamos o uso do Auto Loader com eventos de arquivo para reduzir os custos de descoberta. Isso também reduz os custos compute , pois a descoberta é incremental.

Se você não puder usar eventos de arquivo e precisar usar a listagem de diretório para descobrir arquivos, poderá usar a opção cloudFiles.cleanSource para arquivar ou excluir arquivos automaticamente após o Auto Loader processá-los para reduzir os custos de descoberta. Como o Auto Loader limpa os arquivos do diretório de origem após o processamento, menos arquivos precisam ser listados durante a descoberta.

Ao usar cloudFiles.cleanSource com a opção MOVE , considere os seguintes requisitos:

  • Tanto o diretório de origem quanto o diretório de destino devem estar localizados no mesmo local externo ou volume.
  • Se o diretório de origem e o diretório de destino estiverem no mesmo local externo, eles não devem ter diretórios irmãos que contenham armazenamento de gerenciamento (por exemplo, um volume ou catálogo de gerenciamento). Nesses casos, o Auto Loader não consegue obter as permissões necessárias para gravar no diretório de destino.

A Databricks recomenda o uso desta opção quando:

  • Seu diretório de origem acumula um grande número de arquivos ao longo do tempo.
  • Você deve reter os arquivos processados para compliance ou auditoria (defina cloudFiles.cleanSource para MOVE).
  • Você deseja reduzir os custos de armazenamento removendo arquivos após a ingestão (defina cloudFiles.cleanSource para DELETE). Ao usar o modo DELETE , a Databricks recomenda ativar o versionamento no bucket para que as exclusões do Auto Loader atuem como exclusões lógicas e estejam disponíveis em caso de configuração incorreta. Além disso, Databricks recomenda configurar políticas de ciclo de vida cloud para eliminar versões antigas e excluídas temporariamente após um período de tolerância específico (como 60 ou 90 dias), com base nos seus requisitos de recuperação.

Usando trigger.availableNow e limitação de taxa​

nota

Disponível em Databricks Runtime 10.4 LTS e acima.

Auto Loader pode ser agendado para execução em LakeFlow Jobs como um trabalho em lote, usando Trigger.AvailableNow. O acionador AvailableNow instruirá o Auto Loader a processar todos os arquivos que chegaram antes do horário de início da consulta. Os novos arquivos que forem carregados após o início da transmissão serão ignorados até o próximo acionamento.

Com o Trigger.AvailableNow, a descoberta de arquivos ocorre de forma assíncrona com o processamento de dados e os dados podem ser processados em vários microlotes com limitação de taxa. Auto Loader por default processa no máximo 1.000 arquivos a cada micro-lote. O senhor pode configurar cloudFiles.maxFilesPerTrigger e cloudFiles.maxBytesPerTrigger para configurar quantos arquivos ou quantos bytes devem ser processados em um micro-lote. O limite de arquivos é rígido, mas o limite de bytes é flexível, o que significa que mais bytes podem ser processados do que o maxBytesPerTrigger fornecido. Quando as opções são fornecidas juntas, o Auto Loader processa quantos arquivos forem necessários para atingir um dos limites.

Localização do ponto de verificação​

O local do ponto de verificação é usado para armazenar o estado e as informações de progresso da transmissão. A Databricks recomenda definir o local do ponto de verificação em um local sem uma política de ciclo de vida de objeto de nuvem. Se os arquivos no local do ponto de verificação forem limpos de acordo com a política, o estado de transmissão será corrompido. Se isso acontecer, o senhor deverá reiniciar a transmissão do zero.

Acompanhamento de evento de arquivo​

O Auto Loader mantém o controle dos arquivos descobertos no local do ponto de verificação usando o RocksDB para oferecer garantias de ingestão exatamente uma vez. Para transmissão de ingestão de grande volume ou de longa duração, o site Databricks recomenda a atualização para Databricks Runtime 15.4 LTS ou acima. Nessas versões, o Auto Loader não espera que todo o estado do RocksDB seja baixado antes da transmissão começar, o que pode acelerar o tempo de transmissão do startup. Se quiser evitar que os estados dos arquivos cresçam sem limites, você também pode considerar o uso da opção cloudFiles.maxFileAge para expirar eventos de arquivo com mais de uma certa idade. O valor mínimo que você pode definir para cloudFiles.maxFileAge é "14 days". As exclusões no RocksDB aparecem como entradas de lápide. Portanto, o senhor pode ver o uso do armazenamento aumentar temporariamente à medida que os eventos expiram antes de começar a se estabilizar.

atenção

cloudFiles.maxFileAge é fornecido como um mecanismo de controle de custos para conjuntos de dados de alto volume. Ajustar cloudFiles.maxFileAge de forma muito agressiva pode causar problemas de qualidade de dados, como ingestão duplicada ou perda de arquivos. Portanto, a Databricks recomenda uma configuração conservadora para cloudFiles.maxFileAge, como 90 dias, que é semelhante ao que as soluções de ingestão de dados comparáveis recomendam.

A tentativa de ajustar a opção cloudFiles.maxFileAge pode fazer com que os arquivos não processados sejam ignorados pelo Auto Loader ou que os arquivos já processados expirem e sejam reprocessados, causando a duplicação de dados. Aqui estão algumas coisas a considerar ao escolher um cloudFiles.maxFileAge:

  • Se a transmissão for reiniciada depois de um longo período, os eventos de notificação de arquivo mais antigos do que cloudFiles.maxFileAge que forem retirados da fila serão ignorados. Da mesma forma, se você usar a listagem de diretórios, os arquivos que possam ter aparecido durante o tempo de inatividade mais antigos que cloudFiles.maxFileAge serão ignorados.
  • Se o senhor usar o modo de listagem de diretórios e usar cloudFiles.maxFileAge, por exemplo, definido como "1 month", interromper a transmissão e reiniciá-la com cloudFiles.maxFileAge definido como "2 months", os arquivos mais antigos que 1 mês, mas mais recentes que 2 meses, serão reprocessados.

Se definir essa opção na primeira vez que iniciar a transmissão, os dados mais antigos que cloudFiles.maxFileAge não serão ingeridos; portanto, se quiser ingerir dados antigos, não defina essa opção ao iniciar a transmissão pela primeira vez. No entanto, o senhor deve definir essa opção na execução subsequente.

Acione preenchimentos regulares usando cloudfiles.backfillInterval​

Em casos raros, os arquivos podem ser perdidos ou atrasados quando dependem exclusivamente dos sistemas de notificação, como quando os limites de retenção de mensagens de notificação são atingidos. Se o senhor tiver requisitos rigorosos de integridade de dados e SLA, considere a possibilidade de configurar o site cloudFiles.backfillInterval para acionar backfills assíncronos em um intervalo específico. Por exemplo, defina-o como um dia para preenchimentos diários ou uma semana para preenchimentos semanais. Ativar preenchimentos regulares não causa duplicatas.

Ao usar eventos de arquivo, execute sua transmissão pelo menos uma vez a cada 7 dias​

Ao usar eventos de arquivo, execute seu Auto Loader pelo menos uma vez a cada 7 dias para evitar uma listagem completa do diretório. Executar o Auto Loader com essa frequência garantirá que a descoberta de arquivos seja incremental.

Para obter informações completas sobre as melhores práticas de gerenciamento de eventos de arquivo, consulte Melhores práticas para Auto Loader com eventos de arquivo.