Partilhar via


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

A Databricks recomenda que você siga as práticas recomendadas de streaming para executar o Auto Loader em produção.

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

  • Dimensionamento automático da infraestrutura de computação para economia de custos
  • Verificações de qualidade de dados com expectativas
  • Manipulação automática da evolução do esquema
  • Monitoramento por meio de métricas no log de eventos

Monitorização Auto Loader

Consultando arquivos descobertos pelo Auto Loader

Note

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

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

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

Ouvir atualizações de streaming

Para monitorar ainda mais os fluxos do Auto Loader, o Databricks recomenda o uso da interface Streaming Query Listener do Apache Spark.

O Auto Loader reporta métricas ao Streaming Query Listener em cada lote. Você pode visualizar quantos arquivos existem nas pendências e qual é o tamanho das pendências nas métricas numFilesOutstanding e numBytesOutstanding na guia de Dados Brutos no painel de progresso da consulta de streaming.

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

No Databricks Runtime 10.4 LTS e superiores, ao usar o modo de notificação de ficheiros, as métricas incluem também o número aproximado de eventos de ficheiro na fila na cloud, indicados como approximateQueueSize para AWS e Azure.

Considerações de custo

Ao executar o Auto Loader, as suas principais fontes de custo são os recursos computacionais e a descoberta de ficheiros.

Para reduzir os custos de computação, a Databricks recomenda o uso do Lakeflow Jobs para agendar o Auto Loader como trabalhos em lote em vez de executá-lo de forma contínua, desde que não se tenha requisitos de baixa latência. Consulte Configurar intervalos de ativação do Streaming Estruturado. Estes trabalhos em lote podem ser acionados usando disparadores de chegada de ficheiros para reduzir ainda mais a latência entre a chegada e o processamento dos ficheiros.

Os custos de descoberta de ficheiros podem surgir na forma de operações LIST nas suas contas de armazenamento no modo de listagem de diretório, bem como de solicitações de API no serviço de subscrição e no serviço de fila no modo de notificação de ficheiros. Para reduzir os custos de descoberta de arquivos, o Databricks recomenda:

Arquiva ficheiros no diretório de origem para reduzir custos

Note

Disponível em Databricks Runtime 16.4 LTS e superiores.

Warning

  • A configuração cloudFiles.cleanSource apaga ou move ficheiros no diretório de origem.
  • Se usares foreachBatch para o processamento de dados, os teus ficheiros tornam-se candidatos a mover ou eliminar assim que a operação foreachBatch regressa com sucesso, mesmo que a tua operação tenha consumido apenas um subconjunto dos ficheiros do lote.

Recomendamos usar o Auto Loader com eventos de ficheiro para reduzir os custos de descoberta. Isto também reduz os custos de computação porque a descoberta é incremental.

Se não puder usar eventos de ficheiros e tiver de usar a listagem de diretórios para descobrir ficheiros, pode usar a cloudFiles.cleanSource opção de arquivar ou eliminar automaticamente os ficheiros após o Auto Loader processá-los para reduzir os custos de descoberta. Como o Auto Loader limpa ficheiros do seu diretório de origem após o processamento, é necessário listar menos ficheiros durante a descoberta.

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

  • Tanto o diretório de origem como o diretório de movimento de destino devem estar localizados na mesma localização externa ou volume.
  • Se o seu diretório de origem e destino estiverem na mesma localização externa, não devem ter diretórios irmãos que contenham armazenamento gerido (por exemplo, um volume ou catálogo gerido). Nestes casos, o Auto Loader não consegue obter as permissões necessárias para escrever no diretório de destino.

O Databricks recomenda usar esta opção quando:

  • O seu diretório fonte acumula um grande número de ficheiros ao longo do tempo.
  • Deve manter os ficheiros processados para conformidade ou auditoria (defina cloudFiles.cleanSource como MOVE).
  • Quer reduzir os custos de armazenamento removendo ficheiros após a ingestão (definido cloudFiles.cleanSource para DELETE). Ao usar o DELETE modo, a Databricks recomenda ativar a versão no bucket para que as eliminações do Auto Loader funcionem como eliminações suaves e estejam disponíveis em caso de má configuração. Além disso, a Databricks recomenda configurar políticas de ciclo de vida na cloud para eliminar versões antigas e apagadas suavemente após um período de carência especificado (como 60 ou 90 dias), com base nas suas necessidades de recuperação.

Usando Trigger.AvailableNow e limitação de velocidade

Note

Disponível em Databricks Runtime 10.4 LTS e superior.

O Auto Loader pode ser programado para ser executado nos Lakeflow Jobs como um trabalho em lote usando Trigger.AvailableNow. O AvailableNow gatilho instruirá o Auto Loader a processar todos os arquivos que chegaram antes da hora de início da consulta. Novos arquivos que são carregados após o fluxo ter iniciado são ignorados até o próximo disparador.

Com 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. O Auto Loader por padrão processa um máximo de 1000 arquivos a cada microlote. Você pode configurar cloudFiles.maxFilesPerTrigger e cloudFiles.maxBytesPerTrigger para definir quantos arquivos ou quantos bytes devem ser processados em um microlote. O limite de arquivo é um limite rígido, mas o limite de bytes é um limite flexível, o que significa que mais bytes podem ser processados do que o maxBytesPerTriggerfornecido. Quando as duas opções são fornecidas em conjunto, o Auto Loader processa quantos arquivos são necessários para atingir um dos limites.

Localização do ponto de verificação

O local do ponto de verificação é usado para armazenar as informações de estado e progresso do fluxo. O Databricks recomenda definir o local do ponto de verificação para um local sem uma política de ciclo de vida do objeto na nuvem. Se os arquivos no local do ponto de verificação forem limpos de acordo com a política, o estado do fluxo de dados ficará corrompido. Se isso acontecer, você deve reiniciar o fluxo do zero.

Monitorização de eventos de ficheiro

O Auto Loader acompanha os arquivos descobertos no local do ponto de verificação usando o RocksDB para fornecer garantias de ingestão exatamente uma vez. Para fluxos de ingestão de alto volume ou longa duração, o Databricks recomenda a atualização para o Databricks Runtime 15.4 LTS ou superior. Nessas versões, o Auto Loader não espera que todo o estado RocksDB seja baixado antes que o fluxo seja iniciado, o que pode acelerar o tempo de inicialização do fluxo. Se quiser impedir que os estados de arquivo cresçam sem limites, você também pode considerar usar a cloudFiles.maxFileAge opção para expirar eventos de arquivo com mais de uma determinada 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. Assim, poderá observar o uso do armazenamento aumentar temporariamente à medida que os eventos expiram antes de se estabilizar.

Warning

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

Tentar ajustar a cloudFiles.maxFileAge opção pode levar a arquivos não processados sendo ignorados pelo Auto Loader ou arquivos já processados expirando e, em seguida, sendo reprocessados causando dados duplicados. Aqui estão algumas coisas a considerar ao escolher um cloudFiles.maxFileAge:

  • Se o fluxo for reiniciado após um longo tempo, os eventos de notificação retirados da fila que são mais antigos do que cloudFiles.maxFileAge são ignorados. Da mesma forma, se utilizares a listagem de diretórios, os ficheiros que podem ter surgido durante o tempo de inatividade e que são mais antigos que cloudFiles.maxFileAge serão ignorados.
  • Se você usar o modo de listagem de diretório e usar cloudFiles.maxFileAge, por exemplo, definido como "1 month", interrompe o fluxo e reinicia o fluxo com cloudFiles.maxFileAge definido como "2 months", os arquivos com mais de 1 mês, mas mais recentes que 2 meses, são reprocessados.

Se você definir essa opção na primeira vez que iniciar o fluxo, você não ingerirá dados mais antigos do que cloudFiles.maxFileAge, portanto, se você quiser ingerir dados antigos, não deve definir essa opção ao iniciar o fluxo pela primeira vez. No entanto, deve definir essa opção em corridas subsequentes.

Acione preenchimentos automáticos regulares usando cloudFiles.backfillInterval

Em casos raros, os arquivos podem ser perdidos ou atrasados quando dependem exclusivamente de sistemas de notificação, como quando os limites de retenção de mensagens de notificação são atingidos. Se tiver exigências rigorosas de integridade de dados e SLA, considere definir cloudFiles.backfillInterval para acionar backfills assíncronos em um intervalo especificado. Por exemplo, defina-o como um dia para preenchimentos diários ou uma semana para preenchimentos semanais. Acionar preenchimentos regulares não causa duplicatas.

Ao usar eventos de arquivo, execute seu fluxo pelo menos uma vez a cada 7 dias

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

Para melhores práticas abrangentes para eventos de ficheiros geridos, consulte Melhores práticas para Auto Loader com eventos de ficheiro.