Modernizando ETL de SQL no Lakehouse com padrões declarativos

A Databricks está trazendo ETL declarativo para fluxos de trabalho de data warehousing no Lakehouse, facilitando para os profissionais de SQL a simplificação de lógicas de transformação complexas nos ambientes familiares em que já trabalham.

Isso faz parte de uma estratégia mais ampla para trazer o modelo de execução declarativo por trás do Apache Spark™ Declarative Pipelines para mais experiências de criação na Databricks. Em vez de precisar trabalhar em um ambiente dedicado e orientado a pipelines, os usuários de SQL agora podem definir padrões comuns de ETL diretamente em suas consultas SQL no Databricks Lakehouse.

Simplificando padrões recorrentes de ETL no Lakehouse

O ETL SQL declarativo na Databricks não é novidade. Hoje, milhares de usuários focados em SQL já contam com primitivas declarativas como Materialized Views e Streaming Tables para simplificar transformações recorrentes, manter as tabelas downstream atualizadas e acelerar as cargas de trabalho de BI.

Muitos padrões recorrentes de ETL são fáceis de descrever, mas difíceis de operar, exigindo lógica SQL personalizada, agendamento manual e integrações de orquestração. Esses padrões incluem a anexação de novos registros, a aplicação de alterações de CDC e a atualização apenas dos dados que foram alterados.

As primitivas declarativas funcionam porque permitem que os usuários descrevam a tabela ou visualização que desejam, em vez de programar manualmente cada etapa necessária para mantê-la atualizada. A Databricks cuida do agendamento, da atualização e do processamento incremental onde aplicável, para que os usuários não precisem programar manualmente a lógica necessária para manter as tabelas atualizadas.

Agora estamos estendendo essa mesma abordagem declarativa além do Lakeflow Pipelines Editor para mais padrões recorrentes de ETL para profissionais de data warehouse e SQL. Agora, os usuários do Lakehouse podem definir o padrão de ETL que desejam — diretamente no SQL Editor, por exemplo —, enquanto a Databricks cuida do processamento incremental, da lógica de atualização, do agendamento e da orquestração necessários para executá-lo de forma confiável.

As primeiras primitivas declarativas disponíveis no Lakehouse

As primeiras operações declarativas disponíveis no editor SQL do Lakehouse mapeiam três padrões recorrentes comuns de ETL: atualizações do tipo append-only (somente anexação), change data capture (CDC) e substituições em lote (batch overwrites).

Muitos desses padrões já estão disponíveis por meio de APIs declarativas, como o AUTO CDC no Lakeflow; a mudança aqui é torná-los acessíveis diretamente no Lakehouse para analistas de SQL.

Esses fluxos podem ser atualizados de acordo com um cronograma, acionados por atualizações upstream, executados sob demanda ou orquestrados por meio de tarefas SQL em Jobs.

Atualizações Append-Only

As atualizações append-only são o padrão por trás de muitas tabelas de streaming hoje, usadas para anexar de forma incremental novos registros de uma origem em uma tabela de destino. Elas são comumente usadas para cargas de trabalho de ingestão, como o carregamento de novos registros do armazenamento de objetos em nuvem com o Auto Loader.

Em vez de escrever e agendar lógicas de inserção repetidas, os usuários de SQL podem definir um fluxo APPEND simples que rastreia automaticamente os dados novos em relação aos processados anteriormente na origem. A Databricks cuida do rastreamento de estado e anexa de forma incremental novos registros à medida que eles chegam, gerenciando o pipeline serverless subjacente de forma automática.

Isso oferece aos usuários de SQL uma maneira simples de operacionalizar a ingestão no estilo append sem precisar criar, agendar ou gerenciar manualmente um pipeline separado.

Veja como definir fluxos APPEND no Lakehouse.

Change Data Capture

Os pipelines de CDC estão entre os padrões mais comuns — e mais complexos — no ETL SQL. As equipes costumam usar MERGE INTO para processar inserções, atualizações e exclusões, mas os dados de CDC podem chegar fora de ordem, exigindo lógica adicional para evitar resultados incorretos.

O AUTO CDC permite que os usuários de SQL definam a lógica de CDC com poucas linhas de código declarativo no Lakehouse. Com o AUTO CDC, é fácil especificar chaves, sequenciamento, tratamento de exclusões e se os resultados devem ser armazenados como SCD Tipo 1 ou SCD Tipo 2 — sem a necessidade de escrever manualmente pipelines de merge complexos.

“Na bsport, o SQL AUTO CDC nos deu uma maneira muito mais simples e modular de gerenciar a ingestão de dados na Databricks. Ao desacoplar os carregamentos de tabelas de um único pipeline, melhoramos a disponibilidade e a atualização dos dados em nossa plataforma. Isso nos permite processar dados de terceiros de forma independente, o que nos dá uma melhor gestão de falhas, reduz a complexidade da orquestração e torna a configuração geral mais fácil de operar e dimensionar. Para a nossa equipe, isso criou um fluxo de trabalho baseado em SQL mais limpo e flexível, com maior confiabilidade em produção.”—Adrien Marteau, Head of Data, bsport

Veja como criar fluxos AUTO CDC para SCD Tipo 1 e Tipo 2.

Substituições em Lote

Algumas cargas de trabalho de ETL em lote precisam apenas atualizar um subconjunto específico de dados, como um intervalo de datas, partição ou segmento de negócios. Tradicionalmente, as equipes costumam lidar com isso por meio de recalculos completos caros ou lógicas de substituição personalizadas.

Os fluxos REPLACE WHERE trazem um padrão declarativo para recalculo em lote incremental direcionado para o Lakehouse. Os usuários definem um predicado na tabela de destino, e a Databricks atualiza essa região automaticamente. Com o Enzyme, o mecanismo de incrementalização automática da Databricks, a Databricks pode identificar e processar apenas os dados que foram alterados dentro do predicado especificado, sempre que possível, em vez de recalcular toda a tabela de destino ou regravar toda a fatia correspondente.

Em testes de benchmark do Lakehouse, o REPLACE WHERE alimentado pelo Enzyme foi executado 3,4 vezes mais rápido e custou 2,5 vezes menos do que o REPLACE WHERE tradicional. Isso é útil para reprocessamento seletivo, evolução de esquema, backfills e iteração em uma pequena janela de dados antes de processar um intervalo histórico maior.

Veja como usar fluxos REPLACE WHERE para atualizar um subconjunto direcionado de uma tabela (e leia o blog da comunidade aqui).

Resumo: Por que isso é importante para profissionais de SQL

Modernizar seu ETL não exige uma reescrita total ou um compromisso de "tudo ou nada" com frameworks de pipeline complexos. Trazer semânticas declarativas para suas operações SQL existentes no Lakehouse permite que você combine seu código existente com SQL declarativo modernizado onde fizer mais sentido.

Você pode manter suas consultas SQL procedurais existentes e ajustadas para tarefas personalizadas, enquanto conecta perfeitamente operações declarativas como ingestão append-only, AUTO CDC ou substituições em lote direcionadas para padrões recorrentes e de alta manutenção. Isso oferece o melhor dos dois mundos: controle total sobre sua lógica SQL tradicional junto com gerenciamento de estado automatizado, tratamento de dependências e evolução de esquema onde você desejar, tudo diretamente no Lakehouse.

De primitivas declarativas a pipelines declarativos completos

Misturar primitivas declarativas em seus fluxos de trabalho SQL diários oferece um ponto de partida prático e de baixo atrito para gerenciar tabelas individuais e lógica incremental. À medida que seu projeto cresce em escala e complexidade, seu fluxo de trabalho de desenvolvimento pode evoluir naturalmente junto com ele.

Para equipes que gerenciam várias transformações relacionadas, dependências compartilhadas e fluxos de trabalho de produção, o Lakeflow Pipelines Editor oferece uma experiência de desenvolvimento mais rica e orientada a projetos para ETL declarativo, com suporte para desenvolvimento de múltiplos arquivos, gerenciamento de dependências, visualização de pipelines, validação integrada e implantação em produção.

Isso é especialmente útil para equipes que gerenciam muitas transformações relacionadas em domínios, produtos de dados ou unidades de negócios. Em vez de manter scripts desconectados ou centralizar toda a lógica em um único grande projeto, as equipes podem organizar fluxos declarativos em pipelines governados e de propriedade da equipe na Databricks. Com o Unity Catalog, cada equipe pode criar com base em ativos de dados compartilhados, gerenciar permissões de forma consistente e entender a linhagem entre pipelines e consumidores downstream.

Os profissionais de SQL podem começar com fluxos declarativos no familiar SQL Editor e, em seguida, migrar para o Pipelines Editor quando precisarem de um ambiente mais estruturado para projetos maiores, gerenciamento de pipelines mais profundo e desenvolvimento em equipe.

Saiba mais sobre a criação de fluxos de trabalho de ETL declarativos com o Lakeflow Pipelines Editor.

Use o Genie Code para começar mais rápido

Genie Code facilita para os profissionais de SQL a descoberta e a aplicação desses padrões declarativos de ETL nos fluxos de trabalho que eles já utilizam. Em vez de começar do zero ou traduzir manualmente o SQL existente em um padrão pronto para produção, os usuários podem pedir ao Genie Code para ajudar a gerar, explicar e refinar fluxos declarativos.

Por exemplo, um usuário que trabalha com dados de CDC pode pedir ao Genie Code para ajudar a criar um fluxo AUTO CDC, incluindo as chaves apropriadas, coluna de sequência, tratamento de exclusão e comportamento de SCD Tipo 1 ou Tipo 2. Um usuário que trabalha com lógica de lote recorrente pode pedir ao Genie Code para ajudar a converter a lógica de overwrite existente em um fluxo incremental REPLACE WHERE.

À medida que o ETL declarativo se torna disponível em mais experiências de criação, o Genie Code pode ajudar a guiar os usuários em direção ao padrão declarativo correto para a tarefa em questão.

Para começar, explore a documentação vinculada em cada seção acima — e use o Genie Code no Editor SQL para identificar onde fluxos APPEND, fluxos AUTO CDC ou fluxos REPLACE WHERE podem simplificar sua lógica de ETL existente.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original