Configurar o Auto Loader para cargas de trabalho de produção
Databricks recomenda que o senhor siga as práticas recomendadas de transmissão para executar o Auto Loader na produção.
Databricks recomenda o uso do site Auto Loader em LakeFlow Declarative pipeline para ingestão incremental de dados. LakeFlow O pipeline declarativo amplia a funcionalidade da Apache Spark transmissão estruturada e permite que o senhor escreva apenas algumas linhas declarativas Python ou SQL para implantar um pipeline de dados com qualidade de produção:
- Dimensionamento automático da infraestrutura de computação para redução de custos
- Verificações de qualidade de dados com expectativas
- Tratamento automático da evolução do esquema
- monitoramento via métricas no evento log
monitoramento Auto Loader
Consulta de arquivos descobertos pelo Auto Loader
A função cloud_files_state
está disponível em Databricks Runtime 11.3 LTS e acima.
Auto Loader fornece um SQL API para inspecionar o estado de uma transmissão. Usando a função cloud_files_state
, o senhor pode encontrar metadados sobre arquivos que foram descobertos por uma transmissão Auto Loader. Basta consultar a partir de cloud_files_state
, fornecendo o local do ponto de controle 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 Auto Loader a transmissão, Databricks o site recomenda Apache Spark o uso da interface Query Listener da transmissão.
Auto Loader informa métricas para o Query Listener de transmissão a cada lote. O senhor pode view quantos arquivos existem no backlog e qual o tamanho do backlog nas métricas numFilesOutstanding
e numBytesOutstanding
sob os dados brutos tab no painel de progresso da consulta 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 do compute recurso e da descoberta de arquivos.
Para reduzir os custos do compute, o Databricks recomenda usar o LakeFlow Jobs para programar Auto Loader o trabalho em lote usando o Trigger.AvailableNow
em vez de executá-lo continuamente, desde que o senhor não tenha requisitos de baixa latência. Consulte Configurar intervalos de acionamento da transmissão estruturada.
Os custos de descoberta de arquivos podem vir na forma de LIST operações em sua conta de armazenamento no modo de listagem de diretórios e API solicitações no serviço de inscrição e no serviço de fila no modo de notificação de arquivos. Para reduzir os custos de descoberta de arquivos, a Databricks recomenda:
- Fornecimento de um acionador
ProcessingTime
ao executar o Auto Loader continuamente no modo de listagem de diretórios - Arquitetar o upload de arquivos para seu armazenamento account em ordem léxica para aproveitar a Incremental Listing (obsoleta) quando possível
- Aproveitando as notificações de arquivos quando a listagem incremental não é possível
- Usar as tags de recurso para marcar o recurso criado por Auto Loader para rastrear seus custos
Usando trigger.availableNow e limitação de taxa
Disponível em Databricks Runtime 10.4 LTS e acima.
Auto Loader pode ser agendado para execução em LakeFlow Jobs como um trabalho em lote, usando Trigger.AvailableNow
. O acionador AvailableNow
instruirá o Auto Loader a processar todos os arquivos que chegaram antes do horário de início da consulta. Os novos arquivos que forem carregados após o início da transmissão serão ignorados até o próximo acionamento.
Com o Trigger.AvailableNow
, a descoberta de arquivos ocorre de forma assíncrona com o processamento de dados e os dados podem ser processados em vários microlotes com limitação de taxa. Auto Loader por default processa no máximo 1.000 arquivos a cada micro-lote. O senhor pode configurar cloudFiles.maxFilesPerTrigger
e cloudFiles.maxBytesPerTrigger
para configurar quantos arquivos ou quantos bytes devem ser processados em um micro-lote. O limite de arquivos é rígido, mas o limite de bytes é flexível, o que significa que mais bytes podem ser processados do que o maxBytesPerTrigger
fornecido. Quando as opções são fornecidas juntas, o Auto Loader processa quantos arquivos forem necessários para atingir um dos limites.
Localização do ponto de verificação
O local do ponto de verificação é usado para armazenar o estado e as informações de progresso da transmissão. A Databricks recomenda definir o local do ponto de verificação em um local sem uma política de ciclo de vida de objeto de nuvem. Se os arquivos no local do ponto de verificação forem limpos de acordo com a política, o estado de transmissão será corrompido. Se isso acontecer, o senhor deverá reiniciar a transmissão do zero.
Acompanhamento de evento de arquivo
O Auto Loader mantém o controle dos arquivos descobertos no local do ponto de verificação usando o RocksDB para oferecer garantias de ingestão exatamente uma vez. Para transmissão de ingestão de grande volume ou de longa duração, o site Databricks recomenda a atualização para Databricks Runtime 15.4 LTS ou acima. Nessas versões, o Auto Loader não espera que todo o estado do RocksDB seja baixado antes da transmissão começar, o que pode acelerar o tempo de transmissão do startup.
Se quiser evitar que os estados dos arquivos 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 certa idade. O valor mínimo que você pode definir para cloudFiles.maxFileAge
é "14 days"
. As exclusões no RocksDB aparecem como entradas de lápide. Portanto, o senhor pode ver o uso do armazenamento aumentar temporariamente à medida que os eventos expiram antes de começar a se estabilizar.
cloudFiles.maxFileAge
é fornecido como um mecanismo de controle de custos para conjuntos de dados de alto volume. Ajustar cloudFiles.maxFileAge
de forma muito agressiva pode causar problemas de qualidade de dados, como ingestão duplicada ou perda de arquivos. Portanto, a 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.
A tentativa de ajustar a opção cloudFiles.maxFileAge
pode fazer com que os arquivos não processados sejam ignorados pelo Auto Loader ou que os arquivos já processados expirem e sejam reprocessados, causando a duplicação de dados. Aqui estão algumas coisas a considerar ao escolher um cloudFiles.maxFileAge
:
- Se a transmissão for reiniciada depois de um longo período, os eventos de notificação de arquivo mais antigos do que
cloudFiles.maxFileAge
que forem retirados da fila 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 mais antigos quecloudFiles.maxFileAge
serão ignorados. - Se o senhor usar o modo de listagem de diretórios e usar
cloudFiles.maxFileAge
, por exemplo, definido como"1 month"
, interromper a transmissão e reiniciá-la comcloudFiles.maxFileAge
definido como"2 months"
, os arquivos mais antigos que 1 mês, mas mais recentes que 2 meses, serão reprocessados.
Se definir essa opção na primeira vez que iniciar a transmissão, os dados mais antigos que cloudFiles.maxFileAge
não serão ingeridos; portanto, se quiser ingerir dados antigos, não defina essa opção ao iniciar a transmissão pela primeira vez. No entanto, o senhor deve definir essa opção na execução subsequente.
Acione preenchimentos regulares usando cloudfiles.backfillInterval
Em casos raros, os arquivos podem ser perdidos ou atrasados quando dependem exclusivamente dos sistemas de notificação, como quando os limites de retenção de mensagens de notificação são atingidos. Se o senhor tiver requisitos rigorosos de integridade de dados e SLA, considere a possibilidade de configurar o site cloudFiles.backfillInterval
para acionar backfills assíncronos em um intervalo específico. Por exemplo, defina-o como um dia para preenchimentos diários ou uma semana para preenchimentos semanais. Ativar preenchimentos regulares não causa duplicatas.