Fiche 5 : conception des modèles dbt

Durée estimée : 15 à 20 minutes Référence : dbt sur ClickHouse

Concept

Les fiches 1 à 4 ont produit le quoi : quel moteur, quelle ORDER BY et quels types ClickHouse. Cette fiche produit le comment : comment exprimer ces décisions dans la configuration dbt avant d’écrire le moindre SQL.

Un modèle dbt-clickhouse comporte trois couches de configuration auxquelles les développeurs Snowflake n’ont pas à penser :

1. Matérialisation — quel objet physique dbt crée-t-il (vue, table, incrémentiel, éphémère) ?
2. Configuration du moteur — pour les tables et modèles incrémentiels, quel moteur ClickHouse et quelle colonne de version ?
3. Stratégie incrémentielle — pour les modèles incrémentiels, comment dbt traite-t-il les lignes nouvelles ou mises à jour ?

ReplacingMergeTree ajoute une autre question liée à l’exactitude :

4. Emplacement de FINAL — où faut-il placer FINAL dans le DAG dbt pour garantir des lectures dédupliquées ?

Utilisez l’arbre de décision suivant pour la matérialisation :

• Lecture d’une source sans écriture dans le modèle lui-même ? → view
• Logique de jointure pure, jamais interrogée directement ? → ephemeral
• Reconstruction complète à chaque exécution dbt, sans mise à jour partielle ? → table
• Seules les lignes nouvelles ou modifiées sont traitées à chaque exécution ? → incremental

Les modèles de préparation sont toujours des vues — la même règle que dans la fiche 1. Les modèles stg_trips et stg_taxi_zones ne font que transmettre des lectures, sans écriture propre ; ils restent donc des vues quel que soit le comportement de leurs données sources.

Exercice 1 : choix de la matérialisation

Pour chaque modèle, choisissez la bonne matérialisation dbt, puis justifiez votre réponse dans la question sous le tableau.

Exercice 2 : configuration du moteur

Seuls les modèles matérialisés sous forme de table ou de incremental ont besoin d’un moteur ClickHouse ; les vues et modèles éphémères n’en ont pas. Reprenez vos réponses de la fiche 1 : la configuration du moteur dbt met en œuvre les décisions déjà prises.

Exercice 3 : conception de la stratégie incrémentielle

Pour chaque modèle incrémentiel, concevez la configuration complète : unique_key, incremental_strategy et le filtre SQL placé dans le bloc de garde is_incremental() :

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

Exercice 4 : emplacement de FINAL

La déduplication ReplacingMergeTree est asynchrone. FINAL la force lors de la lecture, mais placer FINAL dans le mauvais modèle nuit à l’exactitude ou aux performances. Pour chaque modèle ci-dessous, indiquez si FINAL doit figurer dans sa propre clause FROM.

Loading worksheet...

Report dans migration-plan.md

Après avoir terminé cette fiche, reportez vos réponses dans la section 10 de migration-plan.md, puis cochez :

- [ ] dbt model design: completed