Planilha 5: projeto dos modelos dbt

Tempo estimado: 15–20 minutos Referência: dbt no ClickHouse

Conceito

As planilhas 1 a 4 produziram o quê: qual mecanismo, qual ORDER BY e quais tipos do ClickHouse. Esta planilha produz o como: como essas decisões são expressas na configuração do dbt antes de escrever qualquer SQL.

Um modelo dbt-clickhouse tem três camadas de configuração com as quais desenvolvedores do Snowflake não precisam se preocupar:

1. Materialização — qual objeto físico o dbt cria (view, tabela, incremental ou efêmero)?
2. Configuração do mecanismo — para tabelas e modelos incrementais, qual mecanismo do ClickHouse e qual coluna de versão?
3. Estratégia incremental — para modelos incrementais, como o dbt trata linhas novas ou atualizadas?

Há também uma preocupação de correção exclusiva do ReplacingMergeTree:

4. Posição de FINAL — onde FINAL deve aparecer no DAG do dbt para garantir leituras deduplicadas?

Use esta árvore de decisão para a materialização:

• Leitura somente de inserção a partir de uma origem, sem gravações no próprio modelo? → view
• Lógica de junção pura, não consultada diretamente? → ephemeral
• Reconstrução completa a cada execução do dbt, sem atualizações parciais? → table
• Somente linhas novas ou alteradas são processadas em cada execução? → incremental

Modelos de preparação são sempre views — a mesma regra da planilha 1. stg_trips e stg_taxi_zones são leituras de passagem sem gravações próprias; portanto, continuam sendo views, independentemente do comportamento dos dados de origem.

Exercício 1: seleção da materialização

Para cada modelo, escolha a materialização dbt correta e explique o motivo na pergunta abaixo da tabela.

Exercício 2: configuração do mecanismo

Somente modelos com materialização table ou incremental precisam de um mecanismo ClickHouse; views e modelos efêmeros não têm nenhum. Consulte suas respostas da planilha 1: a configuração do mecanismo dbt implementa as decisões que você já tomou ali.

Exercício 3: projeto da estratégia incremental

Para cada modelo incremental, projete a configuração completa: unique_key, incremental_strategy e o filtro SQL que fica dentro do bloco de proteção is_incremental():

{% if is_incremental() %}
  WHERE <your filter here>
{% endif %}

Exercício 4: posição de FINAL

A deduplicação do ReplacingMergeTree é assíncrona. FINAL a força durante a leitura, mas colocar FINAL no modelo errado afeta a correção ou o desempenho. Para cada modelo abaixo, informe se FINAL deve ficar na cláusula FROM do próprio modelo.

Loading worksheet...

Transferência para migration-plan.md

Depois de concluir esta planilha, preencha a seção 10 de migration-plan.md com suas respostas e marque:

- [ ] dbt model design: completed