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_state
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 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.AvailableNow
o , 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.
Localização do ponto de verificação
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 será corrompido. Se isso acontecer, você deve reiniciar o fluxo do zero.
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.maxFileAge
o , 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 docloudFiles.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 comcloudFiles.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.