Planilha 1: seleção do mecanismo MergeTree

Tempo estimado: 15–20 minutos Referência: Mecanismos MergeTree

Conceito

No Snowflake, você cria uma tabela e o Snowflake decide como armazená-la. No ClickHouse, você escolhe um mecanismo de armazenamento — e essa escolha determina a correção, não apenas o desempenho.

Os três mecanismos necessários neste laboratório:

MergeTree — o mecanismo básico. Os dados são armazenados em arquivos colunares ordenados. Não há deduplicação. Use-o quando a tabela só recebe inserções ou quando seu pipeline gerencia as atualizações externamente (por exemplo, uma recarga completa em cada execução do dbt).

ReplacingMergeTree(version_col) — amplia o MergeTree com deduplicação em segundo plano. Quando existem linhas com a mesma chave ORDER BY em partes diferentes, somente a linha com o maior valor de version_col é mantida após uma mesclagem. Use-o quando as linhas podem ser atualizadas e há uma coluna que aumenta monotonicamente a cada atualização (por exemplo, o carimbo de data e hora updated_at).

Armadilha crítica: a deduplicação é assíncrona. Até que o ClickHouse execute uma mesclagem em segundo plano, as versões antiga e nova de uma linha coexistem. Sempre use SELECT ... FINAL em tabelas ReplacingMergeTree para forçar a deduplicação durante a consulta.

AggregatingMergeTree — amplia o MergeTree com a mesclagem de estados de agregação parciais. Use-o quando a tabela armazena estados de agregação combináveis (por exemplo, esboços HyperLogLog ou resumos de quantis) e você precisa de agregação em segundo plano. Ele não é necessário no laboratório de táxis de NYC: as tabelas de agregação são reconstruídas pelo dbt, não acumuladas.

Árvore de decisão

Does the table receive UPDATE or DELETE operations?
│
├── No (insert-only)
│   └─► MergeTree()
│
└── Yes
    ├── Is there a timestamp/version column that increases on every update?
    │   ├── Yes → ReplacingMergeTree(version_col)
    │   └── No (e.g., full-reload dimension tables)
    │       └─► MergeTree()  — dbt handles upsert via atomic table swap (full rebuild)
    │
    └── Does the table store partial aggregate states (AggregateFunction types)?
        └── Yes → AggregatingMergeTree()

Modelos de preparação são sempre views

No dbt com ClickHouse, os modelos de preparação devem ser materializados como views, não como tabelas. Views não têm custo de armazenamento e estão sempre atualizadas: são apenas SQL salvo, não objetos físicos.

O exercício de seleção de mecanismo abaixo abrange modelos dbt da camada analítica (tabelas de fatos, agregados e dimensões) e a view materializada do ClickHouse. Ele não inclui trips_raw nem os modelos de preparação:

• trips_raw é uma tabela básica do ClickHouse criada diretamente pelo script de migração (scripts/02_migrate_trips.py), não um modelo dbt. Ela usa ReplacingMergeTree(_synced_at) porque o script de migração pode tentar um lote novamente e reinserir o mesmo trip_id. Após a virada, o produtor em tempo real também pode repetir uma operação após falhas transitórias; _synced_at DateTime DEFAULT now() garante que a gravação mais recente prevaleça.
• stg_trips é uma view dbt sobre trips_raw. Ela aplica SELECT ... FROM trips_raw FINAL para resolver duplicatas ainda não mescladas antes que os dados cheguem aos modelos analíticos posteriores. A responsabilidade pela deduplicação fica aqui, não em uma tabela de preparação ReplacingMergeTree.

Exercício: seleção de mecanismo para as tabelas de táxis de NYC

Para cada tabela abaixo, determine o padrão de atualização, identifique a coluna de versão (se houver) e escolha o mecanismo que mantém a tabela correta. Depois, responda às questões de raciocínio quando todas as linhas estiverem preenchidas.

Loading worksheet...

Transferência para migration-plan.md

Depois de preencher esta planilha, copie suas decisões sobre mecanismos para a seção 3 de migration-plan.md e marque:

- [ ] Engine selection: completed