destinos¶
destino
a datablixt governa dados em um único lugar: o lakehouse do seu próprio workspace. não existe mais a opção de um pipeline escrever diretamente em um postgres, mongodb, bucket s3 externo, api ou arquivo de terceiros — esses conectores de destino foram removidos da plataforma.
todo pipeline termina em um nó lakehouse writer, documentado em detalhe na seção de controle.
por que essa mudança é uma vantagem, não uma limitação¶
plataformas de etl tradicionais tratam "destino" como qualquer lugar para onde os dados podem ser empurrados — o que multiplica pontos de risco: credenciais de escrita espalhadas, ddl divergente entre ambientes, dados duplicados em sistemas que ninguém audita, e nenhuma garantia de que duas equipes estão olhando para a mesma versão da verdade.
a datablixt inverte essa lógica: existe um único destino de dado governado — o lakehouse do workspace. isso significa:
- single source of truth — qualquer pessoa que consulta uma tabela do lakehouse sabe exatamente qual pipeline a produziu, com qual regra de qualidade e em qual camada (bronze, silver ou gold)
- sem escrita acidental em produção — não há como um pipeline mal configurado sobrescrever uma tabela operacional de um sistema de terceiros, porque essa opção simplesmente não existe mais
- catálogo sempre consistente — toda escrita passa pelo mesmo mecanismo de camadas, modos de persistência e compressão, então o schema e o histórico ficam previsíveis em qualquer tabela do workspace
- auditoria e time travel nativos — tabelas em formato iceberg guardam snapshots automaticamente, permitindo consultar o estado da tabela em qualquer instante do passado
na prática, isso concentra a plataforma no que ela faz de melhor: ingestão governada, qualidade de dados e um catálogo confiável — em vez de ser mais um cano de replicação de dados para sistemas externos que ninguém audita depois.
como persistir dados hoje¶
todo pipeline conecta seu resultado final a um nó lakehouse writer, que grava a tabela na camada escolhida (bronze, silver ou gold) do lakehouse do workspace, com o modo de persistência apropriado:
| modo de persistência | comportamento |
|---|---|
replace |
sobrescreve a tabela inteira a cada execução — ideal para snapshots completos |
insert |
acrescenta ao histórico sem apagar o que já existe — ideal para série histórica (append-only) |
merge |
faz upsert por chave (exige tabela em formato iceberg) — ideal para sincronizar mudanças incrementais |
veja a configuração completa em lakehouse writer.
a única "saída" que não é dado: notificação por e-mail¶
o único efeito colateral de um pipeline que não é persistência de dado é a notificação operacional por e-mail — usada para avisar uma equipe sobre o resultado de uma execução (sucesso, falha, métricas do run). ela não replica nenhum dado para fora da plataforma: envia apenas um resumo textual/html do que aconteceu no pipeline.
[fonte] → [transformação] → [quality gate] → [lakehouse writer]
↓
[notificação por e-mail] (opcional)
use a notificação para alertar times de dados sobre falhas de qualidade ou conclusão de execuções críticas — não para mover dados entre sistemas.