O dataholic Fabiano Lira escreveu um artigo para compartilhar conhecimento sobre o Databricks. Bora conferir?
E se você não tivesse que ler milhares de arquivos toda vez que rodasse seu pipeline de dados?
Imagine que você tenha o seguinte fluxo no Databricks:
Milhares de arquivos JSON pousam no seu Data Lake, de forma constante e ininterrupta, na landing zone.
Você precisa ler esses arquivos a cada 10 minutos e inserir os dados em uma tabela bronze, já em formato delta.
A cada execução, você precisa desconsiderar os arquivos já lidos, ou seja, realizar uma leitura incremental dos arquivos na landing/transient zone.
Esse é um fluxo de ingestão incremental muito comum, mas com diferentes formas de se implementar, dentre elas:
Gerenciamento de arquivos através de catálogo de metadados, onde podemos realizar o controle dos arquivos já lidos.
Gerenciamento através de eventos, onde ao receber o arquivo, o Object Storage gera um evento, que é recebido por algum outro serviço, como uma Azure Function ou AWS Lambda, e dispara o notebook passando uma série de parâmetros para processamento daquele(s) arquivo(s) em específico.
Não entrarei nos detalhes de cada abordagem explicando os prós e contras de cada um. Mas algo que é comum entre as duas é que ambas vão requerer algum tipo de implementação e manutenção. No caso da segunda abordagem ela ainda tem o problema de não ser repetível. Isto significa que precisarei gerenciar o caso de eventualmente um arquivo não ser corretamente processado e/ou precisar reprocessá-lo. Enfim, teríamos uma certa dor de cabeça.
O Databricks possui algumas features que resolvem este problema de forma elegante, para dizer o mínimo. Uma delas é o Auto Loader. Caso você tenha um cenário onde precise processar arquivos assim que eles chegam no Data Lake, você passa o diretório que será “observado” e os arquivos podem ser processados assim que chegam. Caso não precise de um SLA muito baixo, basta executá-lo em modo batch, como veremos mais abaixo. O Auto Loader magicamente controla quais arquivos já foram processados, utilizando alguns serviços automaticamente gerenciados, fazendo com que sua implantação seja fácil e rápida.
Neste exemplo, para facilitar, vamos utilizar o Azure Event Hub Capture. Essa funcionalidade nos permite despejar eventos do Azure Event Hub, em intervalos pré-configurados, direto em uma storage account. Os eventos são gerados em formato AVRO, em pastas organizadas por partição e data, conforme imagem abaixo.
Percebam que para fazer uso da funcionalidade, basta utilizarmos o formato cloudFiles como source do Structured Streaming.
O método trigger com o parâmetro “once=True” define que os novos arquivos serão processados e a execução do código será finalizada. Essa trigger pode ser modificada caso precisemos de um SLA menor de processamento, fazendo com que essa execução seja contínua. Dessa forma, se novos arquivos caem no Data Lake logo são processados.
Uma abordagem similar para batch, caso queira utilizar SQL, é o comando COPY INTO. Como destino especificamos uma tabela delta. No nosso exemplo ficaria desta forma:
Lembrando que ambas as abordagens são idempotentes, ou seja, podem ser executadas novamente em caso de falhas e terão o mesmo resultado, a não ser que você modifique este comportamento, fazendo uso de parâmetros específicos, como por exemplo para reprocessar todos os arquivos.
Caso tenha curiosidade, uma série desses parâmetros estão disponíveis na documentação do Databricks, COPY INTO (Delta Lake on Databricks).
A Databricks mais uma vez mostra que é uma plataforma diferenciada e sem dúvidas facilita muito a ingestão de dados com esse recurso. E você, já utiliza nos seus pipelines? Dúvidas, críticas, elogios, sugestões? Deixe seu comentário!