Configurar Auto Loader para cargas de trabalho de produção
Databricks recomenda que você siga as melhores práticas de transmissão 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. Delta Live Tables estende a funcionalidade do Apache Spark transmissão estruturada e permite que você escreva apenas algumas linhas de Python ou SQL declarativo para implantar um pipeline de dados de qualidade de produção com:
infraestrutura compute autoscale para economia de custos
Verificações de qualidade de dados com expectativas
Tratamento automático da evolução do esquema
monitoramento via métricas nos logsde eventos
monitoramento Auto Loader
Consultando arquivos descobertos pelo Auto Loader
Observação
A função cloud_files_state
está disponível em Databricks Runtime 11.3 LTS e acima.
O Auto Loader fornece uma API SQL para inspecionar o estado de uma transmissão. Usando a função cloud_files_state
, você pode encontrar metadados sobre arquivos que foram descobertos por uma transmissão Auto Loader . Basta query em cloud_files_state
, fornecendo a localização do ponto de verificação associado a uma transmissão Auto Loader .
SELECT * FROM cloud_files_state('path/to/checkpoint');
Ouça as atualizações da transmissão
Para monitorar ainda mais a transmissão do Auto Loader, o Databricks recomenda o uso da interface de ouvinte query de transmissão do Apache Spark.
O Auto Loader reporta as métricas para o Listener query transmitidas a cada lote. Você pode view quantos arquivos existem no backlog e numFilesOutstanding
numBytesOutstanding
o tamanho do backlog nas métricas e na tab dados brutos no painel de progresso query de transmissão:
{
"sources" : [
{
"description" : "CloudFilesSource[/path/to/source]",
"metrics" : {
"numFilesOutstanding" : "238",
"numBytesOutstanding" : "163939124006"
}
}
]
}
Em Databricks Runtime 10.4 LTS e acima, 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 custo
Ao executar o Auto Loader, sua principal fonte de custos seria o custo de recursos compute e descoberta de arquivos.
Para reduzir os custos compute , o Databricks recomenda o uso de Databricks Jobs para programar o Auto Loader como trabalho em lote usando Trigger.AvailableNow
em vez de executá-lo continuamente, desde que você não tenha requisitos de baixa latência. Consulte Configurar intervalos de acionamento estruturados de transmissão.
Os custos de descoberta de arquivo podem vir na forma de operações LIST em sua account de armazenamento no modo de listagem de diretório e solicitações de API no serviço de inscrição 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órioArquitetar upload de arquivos para sua account de armazenamento em ordem lexical para aproveitar a listagem incremental (obsoleta) quando possível
Aproveitando as notificações de arquivo quando a listagem incremental não é possível
Usando tags de recursos para marcar recursos criados pelo Auto Loader para rastrear seus custos
Usando Trigger.AvailableNow e limitação de taxa
Observação
Disponível em Databricks Runtime 10.4 LTS e acima.
O Auto Loader pode ser programado para ser executado em trabalhos do Databricks como um Job de lotes usando Trigger.AvailableNow
. O gatilho AvailableNow
instruirá o Auto Loader a processar todos os arquivos que chegaram antes do horário de início query . Novos arquivos que são upload após o início da transmissão são ignorados até o próximo acionador.
Com Trigger.AvailableNow
, 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 default processa no máximo 1000 arquivos a cada microlote. Você pode configurar cloudFiles.maxFilesPerTrigger
e cloudFiles.maxBytesPerTrigger
para configurar 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 maxBytesPerTrigger
fornecido. Quando as duas opções são fornecidas juntas, o Auto Loader processa quantos arquivos forem necessários para atingir um dos limites.
Retenção de eventos
O Auto Loader rastreia os arquivos descobertos no local do ponto de verificação usando RocksDB para fornecer garantias de ingestão exatamente uma vez. A Databricks recomenda fortemente o uso da opção cloudFiles.maxFileAge
para todas as transmissões de ingestão de alto volume ou de longa duração. Esta opção expira eventos do local do ponto de verificação, o que acelera o tempo startup do Auto Loader. o tempo startup pode aumentar em minutos por execução do Auto Loader, 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 configurado para cloudFiles.maxFileAge
é "14 days"
. As exclusões no RocksDB aparecem como entradas de marca para exclusão, portanto, você deve esperar que o uso do armazenamento aumente temporariamente à medida que os eventos expiram antes de começar a se estabilizar.
Aviso
cloudFiles.maxFileAge
é fornecido como um mecanismo de controle de custos para dataset de alto volume. Ajustar cloudFiles.maxFileAge
de forma muito agressiva pode causar problemas de qualidade de 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 recomendado por soluções de ingestão de dados comparáveis.
Tentar ajustar a opção cloudFiles.maxFileAge
pode fazer com que arquivos não processados sejam ignorados pelo Auto Loader ou arquivos já processados expirem e sejam reprocessados, causando dados duplicados. Aqui estão algumas coisas a considerar ao escolher um cloudFiles.maxFileAge
:
Se sua transmissão for reiniciada após um longo período de tempo, os eventos de notificação de arquivo extraídos da fila com mais de
cloudFiles.maxFileAge
serão ignorados. Da mesma forma, se você usar a listagem de diretórios, os arquivos que possam ter aparecido durante o tempo de inatividade e que sejam anteriores acloudFiles.maxFileAge
serão ignorados.Se você usar o modo de listagem de diretórios e usar
cloudFiles.maxFileAge
, por exemplo definido como"1 month"
, você interrompe sua transmissão e reinicia a transmissão comcloudFiles.maxFileAge
definido como"2 months"
, arquivos com mais de 1 mês, mas mais recentes que 2 meses são reprocessados.
Se você definir esta opção na primeira vez que iniciar a transmissão, você não ingerirá dados anteriores a cloudFiles.maxFileAge
, portanto, se quiser ingerir dados antigos você não deve definir esta opção ao iniciar sua transmissão pela primeira vez. No entanto, você deve definir esta opção na execução subsequente.
Acione preenchimentos regulares usando cloudFiles.backfillInterval
O Auto Loader pode acionar preenchimentos assíncronos em um determinado intervalo, por exemplo, um dia para preenchimento uma vez por dia ou uma semana para preenchimento uma vez por semana. Os sistemas de notificação de eventos de arquivos não garantem 100% de entrega de todos os arquivos que foram upload e não fornecem SLAs rígidos sobre a latência dos eventos de arquivos. A Databricks recomenda que você acione preenchimentos regulares com o Auto Loader usando a opção cloudFiles.backfillInterval
para garantir que todos os arquivos sejam descobertos dentro de um determinado SLA se a integridade dos dados for um requisito. O acionamento de preenchimentos regulares não causa duplicatas.