Configurar o Carregador Automático para cargas de trabalho de produção

O Databricks recomenda que você siga as práticas recomendadas de streaming para executar o Carregador Automático em produção.

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

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

Carregador automático de monitoramento

Consulta de arquivos descobertos pelo Carregador Automático

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

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

Escutar atualizações de fluxo

Para monitorar ainda mais os fluxos do Carregador Automático, o Databricks recomenda usar a interface do Ouvinte de Consulta de Streaming do Apache Spark.

O carregador automático relata as métricas para o Ouvinte de consulta de streaming em cada lote. Você pode visualizar quantos arquivos existem na lista de pendências e o tamanho dela nas métricas numFilesOutstanding e numBytesOutstanding da guia Dados Brutos do painel de controle do progresso da consulta de streaming:

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

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

Considerações de custo

Ao executar o Carregador Automático, suas principais fontes de custo são recursos de computação e descoberta de arquivos.

Para reduzir os custos de computação, o Databricks recomenda usar Trabalhos do Lakeflow para agendar o Carregador Automático como trabalhos em lote usando o Trigger.AvailableNow em vez de mantê-lo em execução contínua, desde que você não tenha requisitos de baixa latência. Veja Configurar intervalos de gatilho do Streaming Estruturado. Esses jobs em lote podem ser acionados usando gatilhos de chegada de arquivo 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 suas contas de armazenamento no modo de listagem de diretórios e solicitações de API no serviço de assinatura e serviço de fila no modo de notificação de arquivo. Para reduzir os custos da descoberta de arquivos, o Databricks recomenda:

• Não usar os gatilhos ProcessingTime ou Continuous ao executar o Carregador Automático continuamente no modo de listagem de diretório. Em vez disso, use o Carregador Automático com eventos de arquivo . Para obter detalhes sobre como o Carregador Automático com eventos de arquivo funciona, consulte o Carregador Automático com visão geral de eventos de arquivo.
• Usar o modo de notificação de arquivo herdado caso não seja possível usar o Auto Loader com eventos de arquivo. Nesse modo, você pode marcar recursos criados pelo Carregador Automático para acompanhar seus custos usando marcas de recurso.

Arquivar arquivos no diretório de origem para reduzir custos

É recomendável usar o Carregador Automático com eventos de arquivo para reduzir os custos de descoberta. Isso também reduz os custos de computação porque a descoberta é incremental.

Se você não puder usar eventos de arquivo e precisar usar a listagem de diretórios para descobrir arquivos, poderá usar a opção cloudFiles.cleanSource para arquivar ou excluir arquivos automaticamente após o Carregador Automático processá-los para reduzir os custos de descoberta. Como o Carregador Automático limpa 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:

• O diretório de origem e o diretório de movimentação de destino devem estar localizados no mesmo local ou volume externo.
• Se o diretório de origem e destino estiver no mesmo local externo, eles não deverão ter diretórios irmãos que contenham armazenamento gerenciado (por exemplo, um volume ou catálogo gerenciado). Nesses casos, o Carregador Automático não consegue obter as permissões necessárias para gravar no diretório de destino.

O Databricks recomenda usar essa opção quando:

• Seu diretório de origem acumula um grande número de arquivos ao longo do tempo.
• Você deve reter arquivos processados para conformidade ou auditoria (definido cloudFiles.cleanSource como MOVE).
• Você deseja reduzir os custos de armazenamento removendo arquivos após a ingestão (definido cloudFiles.cleanSource como DELETE). Ao usar o modo DELETE, a Databricks recomenda habilitar o versionamento no bucket para que as exclusões do Carregador Automático atuem como exclusões suaves e estejam disponíveis no caso de uma configuração incorreta. Além disso, o Databricks recomenda a configuração de políticas de ciclo de vida da nuvem para limpar versões antigas e com exclusão suave após um período de carência especificado (como 60 ou 90 dias), conforme seus requisitos de recuperação.

Usar o Trigger.AvailableNow e a limitação de taxa

O Auto Loader pode ser agendado para ser executado em Jobs do Lakeflow como um trabalho em lote usando Trigger.AvailableNow. O gatilho AvailableNow instrui o Carregador automático a processar todos os arquivos que chegam antes da hora de início da consulta. Novos arquivos carregados depois que o fluxo é iniciado serão ignorados até o próximo gatilho.

Com o Trigger.AvailableNow, a descoberta de arquivos ocorrerá de forma assíncrona com o processamento de dados, e os dados poderão ser processados em vários microlotes com limitação de taxa. O Carregador automático, por padrão, processa um máximo de 1.000 arquivos em 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 arquivos é um limite rígido, mas o limite de bytes é um limite flexível, ou seja, mais bytes podem ser processados do que o maxBytesPerTrigger fornecido. Quando as opções são fornecidas juntas, o Carregador Automático processará quantos arquivos forem necessários para atingir um dos limites.

Local 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 como um local sem uma política de ciclo de vida do objeto de nuvem. Se os arquivos no local do ponto de verificação forem limpos de acordo com a política, o estado do fluxo estará corrompido. Se isso acontecer, será necessário reiniciar o fluxo do zero.

Acompanhamento de eventos de arquivo

O Carregador Automático 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 de longa duração, o Databricks recomenda a atualização para o Databricks Runtime 15.4 LTS ou superior. Nessas versões, o Carregador Automático não espera que todo o estado do RocksDB seja baixado antes do início do fluxo, o que pode acelerar o tempo de inicialização do fluxo. Se você quiser impedir que os estados de arquivo 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 determinada idade. O valor mínimo que pode ser definido para cloudFiles.maxFileAge é "14 days". As exclusões no RocksDB aparecem como entradas de marca de exclusão. Portanto, é possível que você veja o uso do armazenamento aumentar temporariamente à medida que os eventos expirarem, antes de o uso se estabilizar.

Tentar ajustar a opção cloudFiles.maxFileAge pode fazer com que os arquivos não processados sejam ignorados pelo Carregador Automático ou com que os arquivos já processados expirem e, em seguida, sejam reprocessados, causando dados duplicados. Aqui estão alguns pontos a serem considerados ao escolher um cloudFiles.maxFileAge:

• Se o fluxo for reiniciado após muito tempo, os eventos de notificação de arquivos que são retirados da fila e que são mais antigos do que cloudFiles.maxFileAge serão ignorados. Da mesma forma, se você usar a listagem de diretórios, os arquivos que podem ter aparecido durante o tempo de inatividade e que são mais antigos do 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", você interromperá seu fluxo e o reiniciará com cloudFiles.maxFileAge definido como "2 months", os arquivos com mais de um mês, mas mais recentes que dois meses, serão reprocessados.

Se você definir essa opção na primeira vez que iniciar o fluxo, não ingerirá dados mais antigos do que cloudFiles.maxFileAge, portanto, se você quiser ingerir dados antigos, não deverá definir essa opção ao iniciar o fluxo. Entretanto, você deve definir essa opção em execuções subsequentes.

Disparar provisionamentos regulares usando cloudFiles.backfillInterval

Em instâncias raras, os arquivos podem ser perdidos ou atrasados, dependendo apenas de sistemas de notificação, como quando os limites de retenção de mensagens de notificação são atingidos. Se você tiver requisitos estritos de integridade de dados e SLA, considere definir cloudFiles.backfillInterval para disparar backfills assíncronos em um intervalo especificado. Por exemplo, defina-o como um dia para provisionamentos diários ou uma semana para provisionamentos semanais. O disparo de provisionamentos regulares não causa duplicações.

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 Carregador Automático pelo menos uma vez a cada 7 dias para evitar uma listagem completa de diretórios. Executar os fluxos do Carregador Automático com frequência garantirá que a descoberta de arquivos seja incremental.

Para obter práticas recomendadas abrangentes de eventos de arquivo gerenciado, consulte As práticas recomendadas para o Carregador Automático com eventos de arquivo.