Pipelines

O Sparquet roda um JSON por vez. Uma carga real normalmente são vários: truncar, depois bronze, depois silver, depois um commit. A única coisa que um JSON sozinho não expressa é a ordem em que vários deles rodam — e é isso que um Pipeline é.

Um Pipeline é um conjunto ordenado de Jobs do mesmo Workflow. Ele não guarda JSON próprio: cada estágio guarda uma referência a um Job, e o JSON é compilado do canvas daquele Job na hora da execução. Assim um estágio nunca descola do arquivo que ele aponta, e um Job apagado deixa um estágio que se reporta como quebrado em vez de uma cópia velha que ainda roda.

Um Job é um JSON de pipeline

O framework mantém o vocabulário dele: um JSON é um pipeline — o arquivo que a classe Pipeline executa e reporta como PipelineResult. No Studio esse arquivo é um Job, e o nome Pipeline fica reservado para a sequência de vários deles. Um Pipeline com quatro estágios são quatro execuções do Pipeline do framework, em ordem, compartilhando uma sessão Spark.

Montando um

1. Crie. Dentro de um Workflow, clique em New pipeline e dê a ele o nome da carga que executa — Registro noturno, não sequência 2. Ele abre em /pipelines/:id.

2. Adicione os estágios. Os Jobs do Workflow ficam listados à esquerda. Clique num deles para anexá-lo ao fim da fila, ou arraste-o para o canvas para colocá-lo onde soltou. O mesmo Job pode aparecer mais de uma vez — rodar o mesmo arquivo duas vezes sobre dados diferentes é legítimo — então nada desaparece da lista depois de usado; ela mostra quantas vezes cada Job já está em cena.

3. Desenhe a ordem. Ligue o handle direito de uma caixa ao handle esquerdo da próxima. Nada é inferido de paths aqui, e isso é de propósito: dois estágios que não compartilham path nenhum ainda podem precisar rodar numa ordem fixa — um truncate antes de uma carga — então a ordem é a que você desenha.

4. Entre na caixa quando precisar. Abrir uma caixa leva ao canvas do próprio Job, com todos os painéis que ele normalmente tem: inspector, JSON, issues, IA. Volte e o estágio já reflete a edição, porque o estágio nunca foi uma cópia.

Cada caixa mostra o número do estágio na ordem de execução, o que o Job lê, o que escreve, quantas transformações aplica e se tem bloco de validations — o suficiente para reconhecer um estágio sem abri-lo.

Como a ordem é decidida

Os links que você desenha definem a ordem; empates são resolvidos alfabeticamente, então a numeração é estável entre renders e entre máquinas.

• Um ciclo é recusado na hora de desenhar: uma sequência com loop não tem primeiro estágio, logo não teria como rodar.
• Um estágio sem nenhum link ainda roda, no fim, e ganha um aviso — para que a posição dele na sequência seja deliberada, e não um acaso de quando você soltou a caixa.

Como um estágio entrega dados ao próximo

Estágios não passam DataFrame entre si. Eles compartilham uma sessão Spark, e um estágio simplesmente lê o que um anterior escreveu:

• Um path ou uma tabela. O estágio 1 grava bronze.pedidos; o estágio 2 lê bronze.pedidos.
• Uma temp view. O estágio 1 grava uma saída view; o estágio 2 lê essa view como input. Nada toca o armazenamento — a view vive na sessão que os dois compartilham.

Não existe fiação extra para isso, e nem é necessária: um Job que já lê o lugar certo já está conectado. Um link no canvas define quando um estágio roda, não o que ele recebe.

Dica

A aba Pipeline de um Workflow infere exatamente essas conexões pelos paths e views dos Jobs, somente leitura. É o jeito mais rápido de conferir se a ordem que você desenhou bate com o caminho real dos dados.

Executando

O mesmo runner local e o mesmo token de um Job único. O Pipeline posta todos os estágios em ordem em POST /run/flow/stream, que transmite Server-Sent Events, então o painel vai se preenchendo enquanto o Spark trabalha em vez de ficar congelado até o fim.

O que você recebe	Detalhe
Status por estágio	cada caixa vira running, succeeded, skipped ou failed conforme a sequência avança
Resultados por estágio	linhas lidas, linhas escritas, duração e validações, para cada estágio
Logs rotulados por estágio	cada linha carrega o estágio que a emitiu, incluindo stdout e linhas da JVM
Preview	até 50 linhas da saída do último estágio — o resultado do Pipeline

A execução para no primeiro estágio que falha: os seguintes nem começam, e o erro nomeia o estágio que quebrou. O Pipeline inteiro pega o mesmo lock único de execução de um Job, então uma segunda execução iniciada durante uma em andamento recebe 409.

O que bloqueia uma execução

Tudo ou nada, de propósito: uma sequência só faz sentido inteira, então um estágio quebrado impede a execução em vez de rodar o resto silenciosamente numa ordem encurtada.

Bloqueio	Correção
Um estágio aponta para um Job que não existe mais	apague o estágio, ou recrie o Job referenciado
O Job de um estágio ainda não compila	abra-o e resolva as issues bloqueantes no canvas dele
Um estágio está num loop	remova um dos links que fecha o loop

O que um Pipeline não é

É uma conveniência de desenvolvimento, como o próprio runner — sem agendamento, sem retry, sem alerta, sem janela de backfill. Em produção, entregue os mesmos arquivos JSON ao Airflow, Dagster, Databricks Workflows ou cron, na mesma ordem. O que um Pipeline te dá é poder rodar e ler essa ordem localmente, antes que ela vire o plantão das 3 da manhã de alguém.