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 Delta Live Tables para ingestão incremental de dados. O Delta Live Tables 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
• Tratamento automático da evolução do esquema
• Monitoramento por meio de métricas no log de eventos

Monitoramento Auto Loader

Consultando arquivos descobertos pelo Auto Loader

Nota

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 , fornecendo o local do ponto de verificação associado a um fluxo do cloud_files_stateAuto 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 relata métricas para o Streaming Query Listener em cada lote. Você pode visualizar quantos arquivos existem na lista de pendências e qual é o tamanho da numFilesOutstanding lista de pendências nas métricas e numBytesOutstanding na guia 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 superior, 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 da nuvem como approximateQueueSize para AWS e Azure.

Considerações de custos

Ao executar o Auto Loader, sua principal fonte de custos seria o custo de recursos de computação e descoberta de arquivos.

Para reduzir os custos de computação, o Databricks recomenda o uso de trabalhos do Databricks para agendar o Auto Loader como trabalhos Trigger.AvailableNow em lote, em vez de executá-lo continuamente, desde que você não tenha requisitos de baixa latência. Consulte Configurar intervalos de gatilho de Streaming Estruturado.

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ório 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 de descoberta de arquivos, o Databricks recomenda:

• Fornecendo um gatilho ProcessingTime ao executar o Auto Loader continuamente no modo de listagem de diretórios
• Arquitetar carregamentos de arquivos para sua conta de armazenamento em ordem lexical para aproveitar a Listagem Incremental (preterida) quando possível
• Aproveitando as notificações de arquivos quando a listagem incremental não é possível
• Usando tags de recursos para marcar recursos criados pelo Auto Loader para acompanhar seus custos

Usando Trigger.AvailableNow e limitação de taxa

Nota

Disponível em Databricks Runtime 10.4 LTS e superior.

O Auto Loader pode ser agendado para ser executado em Databricks 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.AvailableNowo , a descoberta de arquivos acontece 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 quantos cloudFiles.maxBytesPerTrigger 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 fornecido maxBytesPerTrigger. 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.

Retenção de eventos

O Auto Loader mantém o controle dos arquivos descobertos no local do ponto de verificação usando o RocksDB para fornecer garantias de ingestão exatas uma vez. A Databricks recomenda vivamente a utilização da cloudFiles.maxFileAge opção para todos os fluxos de ingestão de grande volume ou de longa duração. Esta opção expira eventos do local do ponto de verificação, o que acelera o tempo de inicialização do Auto Loader. O tempo de inicialização pode aumentar para os minutos por execução do Auto Loader, o que adiciona um custo desnecessário 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 você pode definir é cloudFiles.maxFileAge"14 days". As exclusões no RocksDB aparecem como entradas de lápide, portanto, você deve esperar que o uso de armazenamento aumente temporariamente à medida que os eventos expiram antes de começar a se nivelar.

Aviso

cloudFiles.maxFileAge é fornecido como um mecanismo de controlo de custos para conjuntos de dados de grande volume. Ajustar de forma muito agressiva pode causar problemas de qualidade de cloudFiles.maxFileAge dados, como ingestão duplicada ou arquivos ausentes. Portanto, a Databricks recomenda uma configuração conservadora para cloudFiles.maxFileAgeo , 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, registre os eventos de notificação retirados da fila que são mais antigos do que cloudFiles.maxFileAge são ignorados. Da mesma forma, se você usar a listagem de diretórios, os arquivos que podem ter aparecido durante o tempo de inatividade que são mais antigos do cloudFiles.maxFileAge que são ignorados.
• Se você usar o modo de listagem de diretório e usar cloudFiles.maxFileAge, por exemplo, definido como "1 month", interromperá o fluxo e reiniciará o fluxo com cloudFiles.maxFileAge os arquivos definidos como "2 months", com mais de 1 mês, mas mais recentes que 2 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 quiser ingerir dados antigos, não deve definir essa opção ao iniciar o fluxo pela primeira vez. No entanto, você deve definir essa opção em execuções subsequentes.

Acione preenchimentos regulares usando cloudFiles.backfillInterval

O Auto Loader pode acionar backfills assíncronos em um determinado intervalo, por exemplo, um dia para backfill uma vez por dia, ou uma semana para backfill 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 rigorosos sobre a latência dos eventos de arquivo. O Databricks recomenda que você acione backfills regulares com o Auto Loader usando a opção para garantir que todos os arquivos sejam descobertos dentro de um determinado SLA se a cloudFiles.backfillInterval integridade dos dados for um requisito. Acionar preenchimentos regulares não causa duplicatas.