Pipelines
Uma pipeline é o desenho completo de uma integração: de onde o dado sai, o que acontece com ele e onde ele chega.
O desenho é um grafo — as peças se conectam numa direção só, do início para o fim, e nunca voltam para trás. Isso torna o caminho do dado sempre previsível: dá para olhar o desenho e saber exatamente por onde cada mensagem passou.
As peças da pipeline
Cada peça de uma pipeline é chamada de node. Existem três famílias:
| Família | Papel | O que existe hoje |
|---|---|---|
| Input | Traz o dado para dentro | HTTP, Cron, Kafka, SQL Server CDC |
| Transform | Transforma o dado no meio do caminho | Go Function |
| Output | Entrega no sistema final | HTTP, Kafka, SFTP, SMB, Elasticsearch, GCS, Snowflake, PostgreSQL |
Toda pipeline precisa de pelo menos um Input e um Output. Transform é opcional, e você pode encadear quantos quiser.
Ninguém fala direto com ninguém
Duas peças nunca se conectam uma na outra. Entre elas sempre existe um tópico: uma fila persistente onde a peça de trás deixa as mensagens e a peça da frente vai buscar.
[Input] → tópico → [Transform] → tópico → [Output]
Isso parece um detalhe técnico, mas muda o comportamento da integração no dia a dia:
- Uma peça lenta não trava a anterior. O Input continua produzindo; as mensagens se acumulam na fila até o Output dar conta.
- Uma peça que cai não perde dado. Enquanto ela está fora do ar, as mensagens ficam esperando no tópico. Quando volta, ela retoma exatamente de onde parou.
- Dá para medir o gargalo. A quantidade de mensagens acumuladas em cada tópico mostra qual peça está segurando o fluxo.
Quem cria os tópicos
Você não cria tópico na mão. Toda peça capaz de produzir dado — Input ou Transform — ganha automaticamente o seu tópico de saída quando é criada, e ele é removido quando a peça é removida.
Peças de Output não têm tópico de saída: elas são a ponta final, só consomem.
Os tópicos criados seguem o padrão {pipeline}-n{número-do-node}-{sufixo} e ficam visíveis em
Platform → Tópicos.
Um Input, vários tópicos
Uma peça pode ter mais de um tópico de saída. É o caso do Input de SQL Server CDC, que cria um tópico por tabela.
Quantas conexões cada peça aceita
- Um Input não consome de ninguém. Ele pode até ficar sem ligação nenhuma enquanto você monta o desenho.
- Um Transform e um Output consomem sempre de pelo menos um tópico. Sem isso, a publicação é recusada.
- Um mesmo tópico pode alimentar várias peças ao mesmo tempo. É assim que você manda o mesmo dado para dois Outputs diferentes sem lê-lo duas vezes da origem.
Grupos de consumo
Cada peça que consome de um tópico tem o seu próprio marcador de posição — o grupo de consumo. É ele que guarda "até onde eu já li".
O nome do grupo é montado pela plataforma a partir da pipeline e do node. Você só controla um sufixo, e ele tem um uso prático importante: mudar o sufixo faz a peça reler o tópico desde o começo. É assim que se refaz uma carga inicial completa em Outputs como PostgreSQL e Snowflake.
Rascunho e publicada
Uma pipeline tem dois estados:
- Rascunho — você monta e ajusta o desenho à vontade. Nada roda ainda.
- Publicada — o desenho virou infraestrutura de verdade. Cada peça está rodando, consumindo e produzindo dados.
Enquanto está em rascunho, alterar a pipeline não afeta ninguém. Depois de publicada, cada nova publicação atualiza as peças que mudaram.
Cada publicação cria uma versão do desenho, e uma versão anterior pode ser publicada de novo — é assim que se volta atrás. O processo completo está em Publicar uma pipeline.
Validação antes de publicar
A plataforma confere o desenho antes de publicar e bloqueia casos que não funcionariam:
- um Transform ou um Output que não recebe dado de ninguém;
- campos obrigatórios de configuração em branco;
- um secret referenciado que não existe mais.
Corrigir o apontamento e publicar de novo é o caminho.
Escala
Cada peça publicada escala sozinha conforme a carga: se o volume de mensagens sobe, mais cópias daquela peça entram em operação; quando o volume cai, elas saem.
Duas exceções importantes:
- SQL Server CDC roda sempre com uma cópia só. A leitura de mudanças precisa de um leitor único para não duplicar nem embaralhar a ordem dos eventos.
- PostgreSQL e Snowflake também devem rodar com uma cópia só, pelo motivo explicado na página de cada um.
Nomes
O nome da pipeline aparece em todo lugar: nos tópicos criados automaticamente, nas métricas, nos logs e nos nomes das cargas de trabalho. Escolha um nome estável — renomear depois é mais trabalhoso do que acertar na criação.