lakehouse writer¶

destino

o nó mais importante da plataforma: grava o resultado do pipeline em qualquer lakehouse cadastrado no workspace, na camada escolhida (bronze, silver ou gold), com o modo de persistência e a compressão que fizerem sentido para o caso de uso. é o único ponto de escrita de dado da datablixt — e é isso que fecha o ciclo de governança descrito em destinos.

quando usar¶

ao final de todo pipeline — é o nó que efetivamente grava o resultado processado
para materializar cada etapa da arquitetura medallion (bronze → silver → gold), com um lakehouse writer ao final de cada uma
para sincronizar incrementalmente uma tabela por chave (upsert), quando o volume não permite reprocessar tudo a cada execução

configuração¶

campo	tipo	obrigatório	descrição
`table_name`	string	sim	nome da tabela no lakehouse de destino
`layer`	string	sim	slug do lakehouse de destino (ex: `lh_01_bronze`)
`lakehouse_id`	uuid	não	força um lakehouse específico do workspace, em vez de resolver por nome/slug
`format`	enum	não	`parquet` (padrão) ou `iceberg` — iceberg é exigido para `persist_mode: merge` e para time travel
`persist_mode`	enum	sim	`replace`, `insert` ou `merge` — ver abaixo · padrão: `replace`
`merge_keys`	lista	condicional	colunas-chave para identificar cada registro · obrigatório quando `persist_mode = merge`
`compression`	enum	sim	`snappy`, `zstd` ou `gzip` · padrão: `snappy`
`iceberg_namespace`	string	não	namespace iceberg, quando diferente do padrão do workspace · só aplicável a `format: iceberg`

modos de persistência¶

modo	comportamento	quando usar
`replace`	sobrescreve a tabela inteira a cada execução	snapshots completos — a fonte sempre entrega o dataset completo e atual
`insert`	acrescenta ao histórico, sem apagar o que já existe (append-only, particionado por mês)	séries históricas — cada execução representa um novo período (ex: vendas do dia)
`merge`	faz upsert por `merge_keys`: atualiza registros existentes e insere os novos	sincronização incremental — a fonte só entrega registros novos/alterados, mas a tabela de destino deve refletir o estado mais atual de cada chave

merge exige format: iceberg, porque upsert por chave depende do controle de versão do formato de tabela iceberg.

camadas (bronze / silver / gold)¶

o layer aponta para qual lakehouse do workspace o resultado será gravado — normalmente correspondente a uma camada da arquitetura medallion:

camada	papel típico
bronze	dado bruto, o mais próximo possível da fonte original, já tipificado (ver schema cast)
silver	dado limpo, deduplicado e validado — pronto para ser cruzado com outras entidades
gold	métricas e agregações de negócio, prontas para consumo direto por bi e relatórios

exemplos¶

snapshot completo na camada bronze¶

{
  "table_name": "clientes",
  "layer": "lh_01_bronze",
  "format": "parquet",
  "persist_mode": "replace",
  "compression": "snappy"
}

histórico acumulativo (append-only)¶

{
  "table_name": "vendas_diarias",
  "layer": "lh_01_bronze",
  "format": "parquet",
  "persist_mode": "insert",
  "compression": "zstd"
}

cada execução adiciona um novo arquivo ao histórico da tabela, particionado por mês — nada é sobrescrito.

upsert incremental por chave (iceberg)¶

{
  "table_name": "clientes",
  "layer": "lh_01_silver",
  "format": "iceberg",
  "persist_mode": "merge",
  "merge_keys": ["cliente_id"],
  "compression": "zstd"
}

registros com cliente_id já existente são atualizados; registros novos são inseridos — sem duplicar e sem precisar reprocessar a tabela inteira.

por que isso é uma vantagem de governança¶

concentrar toda escrita de dado neste único nó — em vez de permitir dezenas de destinos externos diferentes — significa que:

qualquer tabela do workspace tem uma origem rastreável: o pipeline e o nó exatos que a produziram
o formato, a compressão e o modo de persistência seguem sempre a mesma mecânica, então não há surpresas de schema entre tabelas diferentes
tabelas em formato iceberg ganham automaticamente snapshots versionados, habilitando time travel no lakehouse reader — você pode consultar exatamente como uma tabela estava em qualquer instante do passado
não existe caminho para um pipeline sobrescrever acidentalmente um sistema de terceiros — o único destino possível é o lakehouse que a sua própria organização controla

veja o racional completo dessa decisão em destinos.

encadeando camadas

depois de um lakehouse writer gravar a camada bronze, o próximo pipeline (camada silver) começa com um lakehouse reader apontando para essa mesma tabela — não é preciso conhecer caminhos de arquivo, apenas o nome da tabela e a camada.