Pipelines Declarativos do Spark: por que a engenharia de dados precisa se tornar declarativa de ponta a ponta

As equipes de engenharia de dados estão sob pressão para entregar dados de maior qualidade mais rapidamente, mas o trabalho de criar e operar pipelines está se tornando mais difícil, não mais fácil. Entrevistamos centenas de engenheiros de dados e estudamos milhões de cargas de trabalho do mundo real e descobrimos algo surpreendente: os engenheiros de dados gastam a maior parte do tempo não escrevendo código, mas na carga operacional gerada pela integração de ferramentas. O motivo é simples: os frameworks de engenharia de dados existentes forçam os engenheiros de dados a lidar manualmente com orquestração, processamento de dados incremental, qualidade de dados e preenchimentos retroativos (backfills) — todas tarefas comuns para pipelines de produção. À medida que os volumes de dados e os casos de uso crescem, essa carga operacional se agrava, transformando a engenharia de dados em um gargalo para o negócio em vez de um acelerador.

Esta não é a primeira vez que o setor bate nessa parede. O processamento de dados inicial exigia a criação de um novo programa para cada consulta, o que não tinha escala. O SQL mudou isso tornando as queries individuais declarativas: você especifica qual resultado deseja, e o mecanismo descobre como computá-lo. Bancos de dados SQL agora sustentam todos os negócios.

Mas a engenharia de dados não se resume a executar uma única query. Pipelines atualizam repetidamente múltiplos datasets interdependentes ao longo do tempo. Como os mecanismos SQL param no limite da query, tudo o que está além dele (processamento incremental, gerenciamento de dependências, backfills, qualidade dos dados, repetições) ainda precisa ser montado manualmente. Em grande escala, o raciocínio sobre a ordem de execução, o paralelismo e os modos de falha rapidamente se torna a principal fonte de complexidade.

O que falta é uma maneira de declarar o pipeline como um todo. Pipelines Declarativos do Spark (SDP) estendem o processamento de dados declarativo de consultas individuais para pipelines inteiros, permitindo que o Apache Spark os planeje e execute de ponta a ponta. Em vez de mover dados manualmente entre os passos, você declara quais conjuntos de dados deseja que existam, e o SDP é responsável por como mantê-los corretos ao longo do tempo. Por exemplo, em um pipeline que calcula as vendas semanais, o SDP infere dependências entre os datasets, cria um único plano de execução e atualiza os resultados na ordem correta. Ele processa automaticamente apenas dados novos ou alterados, expressa regras de qualidade de dados em linha (inline) e lida com preenchimentos retroativos (backfills) e dados que chegam com atraso sem intervenção manual. Como o SDP entende a semântica das consultas, ele pode validar pipelines antecipadamente, executar com segurança em paralelo e se recuperar corretamente de falhas — recursos que exigem APIs declarativas de primeira classe, cientes do pipeline e integradas diretamente ao Apache Spark.

A engenharia de dados declarativa de ponta a ponta no SDP traz benefícios poderosos:

• Maior produtividade: os engenheiros de dados podem se concentrar em escrever a lógica de negócios em vez de código de integração.
• Custos mais baixos: o framework lida automaticamente com a orquestração e o processamento incremental de dados, tornando-o mais econômico do que pipelines escritos manualmente.
• Menor carga operacional: casos de uso comuns, como backfills, qualidade de dados e novas tentativas, são integrados e automatizados.

Para ilustrar os benefícios da engenharia de dados declarativa de ponta a ponta, vamos começar com um pipeline de ventas semanal escrito em PySpark. Como o PySpark não é declarativo de ponta a ponta, devemos codificar manualmente a ordem de execução, o processamento incremental e a lógica de qualidade de dados e contar com um orquestrador externo como o Airflow para novas tentativas, alertas e monitoramento (omitido aqui por questões de brevidade).

Este pipeline, expresso como um projeto SQL dbt, sofre de muitas das mesmas limitações: ainda precisamos codificar manualmente o processamento de dados incremental, a qualidade dos dados é tratada separadamente e ainda temos que depender de um orquestrador como o Airflow para novas tentativas e tratamento de falhas:

Vamos reescrever este pipeline em SDP para explorar seus benefícios. Primeiro, vamos instalar o SDP e criar um novo pipeline:

A seguir, defina seu pipeline com o seguinte código. Observe que comentamos a API de expectativa de qualidade de dados expect_or_drop, pois estamos trabalhando com a comunidade para torná-la de código aberto:

Para executar o pipeline, digite o seguinte comando no seu terminal:

Podemos até validar nosso pipeline antecipadamente, sem executá-lo primeiro, com este comando. É útil para encontrar erros de sintaxe e incompatibilidades de esquema:

Os backfills se tornam muito mais simples: para fazer o backfill da tabela raw_sales, execute este comando:

O código é muito mais simples: apenas 20 linhas que entregam tudo o que as versões do PySpark e do dbt exigem que ferramentas externas forneçam. Também obtemos estes benefícios poderosos:

• Processamento incremental e automático de dados. O framework rastreia quais dados foram processados e lê apenas os registros novos ou alterados. Não são necessárias queries MAX, arquivos de checkpoint nem lógica condicional.
• Qualidade de dados integrada. O decorador @dp.expect_or_drop coloca registros inválidos em quarentena automaticamente. No PySpark, dividíamos e gravávamos manualmente os registros bons/inválidos em tabelas separadas. No dbt, precisávamos de um modelo separado e de tratamento manual.
• Acompanhamento automático de dependências. O framework detecta que weekly_sales depende de raw_sales e orquestra a ordem de execução automaticamente. Nenhum orquestrador externo é necessário.
• Novas tentativas e monitoramento integrados. O framework lida com falhas e oferece observabilidade por meio de uma UI integrada. Nenhuma ferramenta externa é necessária.

O SDP no Apache Spark 4.1 tem os seguintes recursos que o tornam uma ótima opção para pipelines de dados:

• APIs em Python e SQL para definir datasets
• Suporte para consultas em lotes e de transmissão
• Acompanhamento automático de dependências entre datasets e atualizações paralelas eficientes
• CLI para estruturar, validar e executar pipelines localmente ou em produção

Estamos entusiasmados com o roteiro do SDP, que está sendo desenvolvido abertamente com a comunidade Spark. As próximas versões do Spark se basearão nesta fundação com suporte para execução contínua e processamento incremental mais eficiente. Também planejamos trazer recursos essenciais, como captura de dados de alterações (CDC), para o SDP, moldados por casos de uso do mundo real e pelo feedback da comunidade. Nosso objetivo é tornar o SDP uma base compartilhada e extensível para a criação de pipelines de lotes e transmissão confiáveis em todo o ecossistema Spark.

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