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 Delta Live Tables para ingestão incremental de dados. O Delta Live Tables estende a funcionalidade no Fluxo Estruturado do Apache Spark e permite que você escreva apenas algumas linhas de SQL ou Python declarativo para implantar um pipeline de dados com 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

Observação

A função cloud_files_state está disponível no Databricks Runtime 11.3 LTS e versões superiores.

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 fluxos do Carregador Automático, o Databricks recomenda usar a interface do Ouvinte de consulta de streamingdo 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 versões superiores, ao usar o modo de notificação de arquivo, as métricas também incluirão o número aproximado de eventos de arquivo que estão na fila de nuvem como approximateQueueSize para a AWS e o Azure.

Considerações de custo

Ao executar o Carregador automático, a fonte principal de custos será o custo dos recursos de computação e da descoberta de arquivos.

Para reduzir os custos de computação, o Databricks recomenda utilizar Trabalhos do Databricks para agendar o Carregador Automático como trabalhos em lote usando Trigger.AvailableNow em vez de executá-lo continuamente, desde que você não tenha uma exigência de baixa latência. Confira Configurar intervalos de gatilho do Fluxo Estruturado.

Os custos da descoberta de arquivos podem vir na forma de operações de LISTA das contas de armazenamento no modo de listagem de diretório e nas solicitações de API no serviço de assinatura, e no serviço de fila no modo de notificação de arquivo. Para reduzir os custos da descoberta de arquivos, o Databricks recomenda:

• fornecer um gatilho ProcessingTime ao executar o Carregador automático continuamente no modo de listagem de diretório
• Arquitetar os carregamentos de arquivos para a conta de armazenamento em ordem lexical para aproveitar a Listagem Incremental (preterido), quando possível
• Aproveitar as notificações de arquivo quando a listagem incremental não é possível
• Utilizar as tags de recurso para marcar os recursos criados pelo Carregador automático e, assim, controlar os custos

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

Observação

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

O Carregador automático pode ser agendado para ser executado em trabalhos do Databricks como um trabalho em lotes 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.

Localização do ponto de verificação

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, você deve reiniciar o fluxo do zero.

Retenção de eventos

O Carregador automático monitora os arquivos descobertos no local do ponto de verificação usando o RocksDB para fornecer garantias de ingestão apenas uma vez. O Databricks recomenda fortemente usar a opção cloudFiles.maxFileAge em todos os fluxos de ingestão de alto volume ou de longa duração. Essa opção expira os eventos do local do ponto de verificação, o que acelera o tempo de inicialização do Carregador Automático. O tempo de inicialização pode aumentar em minutos por execução do Carregador Automático, o que adiciona custos desnecessários quando você tem um limite superior na idade máxima dos arquivos que serão armazenados no diretório de origem. O valor mínimo que pode ser definido para cloudFiles.maxFileAge é "14 days". As exclusões no RocksDB aparecem como entradas de marcas de exclusão, portanto, o uso do armazenamento aumentará temporariamente conforme os eventos expiram antes que ele comece a nivelar.

Aviso

cloudFiles.maxFileAge é fornecido como um mecanismo de controle de custos para os conjuntos de dados de alto volume. O ajuste cloudFiles.maxFileAge muito agressivo pode causar problemas de qualidade de dados, como ingestão duplicada ou arquivos ausentes. Por isso, o 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.

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

O Carregador Automático pode disparar provisionamentos assíncronos em um determinado intervalo; por exemplo, um dia para fazer o backup uma vez por dia ou uma semana para fazer o backup uma vez por semana. Os sistemas de notificação de eventos de arquivo não garantem 100% de entrega de todos os arquivos que foram carregados e não fornecem SLAs estritas sobre a latência dos eventos de arquivo. O Databricks recomenda disparar os provisionamentos regulares com o Carregador automático ao usar a opção cloudFiles.backfillInterval para garantir que todos os arquivos sejam descobertos em um determinado SLA, se a conclusão dos dados for um requisito. O disparo de provisionamentos regulares não causa duplicações.