Vues matérialisées

1. Créer une table cible portant le nom du modèle
2. Créer une vue matérialisée ClickHouse nommée <model_name>_mv

-- models/events_mv.sql
{{
    config(
        materialized='materialized_view',
        engine='SummingMergeTree()',
        order_by='(event_date, event_type)'
    )
}}

SELECT
    toStartOfDay(event_time) AS event_date,
    event_type,
    count() AS total
FROM {{ source('raw', 'events') }}
GROUP BY event_date, event_type

--mv1:begin
select a,b,c from {{ source('raw', 'table_1') }}
--mv1:end
union all
--mv2:begin
select a,b,c from {{ source('raw', 'table_2') }}
--mv2:end

{{config(
    materialized='materialized_view',
    engine='MergeTree()',
    order_by='(id)',
    on_schema_change='fail'  # this setting
)}}

{{config(
    materialized='materialized_view',
    engine='MergeTree()',
    order_by='(id)',
    catchup=False  # this setting
)}}

• Toutes les ressources (table cible + MV) partagent la même configuration. Si plusieurs MV pointent vers la même table cible, elles doivent être définies ensemble à l’aide de la syntaxe UNION ALL.
• Aucune de ces ressources ne peut être gérée séparément ; elles doivent toutes être administrées à l’aide du même fichier de modèle.
• Vous ne pouvez pas facilement contrôler le nom de chaque MV.
• Tous les paramètres sont partagés entre la table cible et les MV, ce qui complique la configuration individuelle de chaque ressource et l’identification de la configuration associée à chacune.

• Ressources entièrement séparées : chaque ressource peut désormais être définie séparément, ce qui améliore la lisibilité
• Ressources 1:1 entre dbt et CH : vous pouvez désormais utiliser les outils dbt pour les gérer et les faire évoluer séparément.
• Différentes configurations désormais disponibles : une configuration différente peut désormais être appliquée à chacune.
• Plus besoin de respecter les conventions de nommage : toutes les ressources sont désormais créées avec le nom que vous leur donnez, et non avec un nom personnalisé suffixé par _mv pour les MV.

• La définition de la table cible n’est pas naturelle pour dbt : il ne s’agit pas d’une requête SQL qui lira depuis une table source, vous perdez donc ici les validations dbt. Le SQL de la MV sera tout de même validé à l’aide des utilitaires dbt, et sa compatibilité avec les colonnes de la table cible sera validée au niveau de CH.
• Nous avons identifié quelques problèmes liés aux limitations de la fonction ref() : nous devons l’utiliser pour référencer les modèles entre eux, mais elle ne peut servir qu’à référencer des modèles upstream, pas downstream. Cela pose certains problèmes pour cette implémentation. Nous avons créé une issue dans le dépôt dbt-core et échangeons actuellement avec eux pour chercher des solutions possibles (dbt-labs/dbt-core#12319) :
  • Lorsque ref() est appelé depuis l’intérieur du bloc config, il renvoie le modèle courant, et non celui partagé. Cela nous empêche de le définir dans la section config(), et nous oblige à utiliser un commentaire pour ajouter cette dépendance. Nous suivons le même modèle que celui défini dans la documentation dbt avec l’approche “—depends_on:”.
  • ref() fonctionne dans notre cas car il force la création de la table cible en premier, mais dans le graphe des dépendances de la documentation générée, la table cible sera représentée comme une autre dépendance upstream, et non downstream, ce qui le rend un peu plus difficile à comprendre.
  • unit-test nous oblige également à définir des données pour la table cible, même si l’idée n’est pas de la lire. Le contournement consiste simplement à laisser les données de cette table vides.

{{
    config(
        materialized='table',
        engine='SummingMergeTree()',
        order_by='(event_date, event_type)',
        partition_by='toYYYYMM(event_date)'
    )
}}

SELECT
    toDate(now()) AS event_date,
    '' AS event_type,
    toUInt64(0) AS total
WHERE 0  -- Creates empty table with correct schema

{{ config(materialized='materialized_view') }}
{{ materialization_target_table(ref('events_daily')) }}

SELECT
    toStartOfDay(event_time) AS event_date,
    event_type,
    count() AS total
FROM {{ source('raw', 'page_events') }}
GROUP BY event_date, event_type

{{ config(materialized='materialized_view') }}
{{ materialization_target_table(ref('events_daily')) }}

SELECT
    toStartOfDay(event_time) AS event_date,
    event_type,
    count() AS total
FROM {{ source('raw', 'mobile_events') }}
GROUP BY event_date, event_type

-- models/page_events_aggregator.sql
{{ config(
    materialized='materialized_view',
    catchup=True  -- this is the default value so you don't need to actually set it.
) }}
{{ materialization_target_table(ref('events_daily')) }}
...

1. Créer une nouvelle table temporaire
2. Exécuter INSERT-SELECT en utilisant le SQL de chaque MV
3. Permuter les tables de manière atomique

-- models/events_daily.sql
{{
    config(
        materialized='table',
        engine='SummingMergeTree()',
        order_by='(event_date, event_type)',
        repopulate_from_mvs_on_full_refresh=True
    )
}}
...

1. Mettez à jour l’appel à materialization_target_table()
2. Exécutez dbt run --full-refresh -s your_mv_model

• Les vues matérialisées peuvent être configurées avec catchup=False, ou la table cible avec repopulate_from_mvs_on_full_refresh=False ; dans ce cas, aucun backfill n’est effectué lors de la création des vues matérialisées ou de la recréation de la table cible. C’est le comportement attendu. Si vous souhaitez réinsérer les données à l’aide du SQL des vues matérialisées, assurez-vous de définir catchup=True dans la vue matérialisée (c’est la valeur par défaut) ou repopulate_from_mvs_on_full_refresh=True dans la table cible. Veillez à ne pas activer les deux en même temps afin d’éviter les doublons. Consultez la section de configuration pour plus de détails.
• Lors de l’exécution de dbt run --full-refresh, si les vues matérialisées utilisent la valeur par défaut catchup=True, la cible sera recréée et les MV réinséreront les données de manière séquentielle. Pour éviter cette situation, consultez la section Full refresh with explicit targets.

• catchup=True sur les vues matérialisées et repopulate_from_mvs_on_full_refresh=True sur la table cible peuvent être activés tous les deux : n’en gardez qu’un seul, selon les opérations que vous souhaitez exécuter. Consultez la section de configuration pour plus de détails.
• La table cible n’est pas définie avec WHERE 0 : elle doit être créée vide, mais la requête interne peut insérer des données si WHERE 0 n’est pas inclus. Assurez-vous que la clause est bien présente.

SELECT
    name as mv_name,
    replaceRegexpOne(
        create_table_query,
        '.*TO\\s+`?([^`\\s(]+)`?\\.`?([^`\\s(]+)`?.*',
        '\\1.\\2'
    ) AS target_table
FROM system.tables
WHERE database = 'your_schema'
  AND engine = 'MaterializedView'

La table <table_name> est utilisée comme table cible par une vue matérialisée gérée par dbt. La valeur par défaut de mv_on_schema_change est définie sur “fail” afin d’éviter toute perte de données.

• Le modèle de vue matérialisée définit correctement {{ materialization_target_table(ref('your_target')) }}
• Le modèle de vue matérialisée a materialized='materialized_view' dans sa config
• La vue matérialisée et la table cible ont toutes deux été exécutées au moins une fois

-- models/events_daily.sql
{{
    config(
        materialized='table',
        engine='MergeTree()',
        order_by='(event_date, event_type)'
    )
}}

SELECT
    toDate(now()) AS event_date,
    '' AS event_type,
    toUInt64(0) AS total
WHERE 0

• si une seule MV était définie, elle portera le nom : <old_model_name>_mv
• si plusieurs MV étaient définies, chacune portera le nom : <old_model_name>_mv_<name_in_comments>

--mv1:begin
select a, b, c from {{ source('raw', 'table_1') }}
--mv1:end
union all
--mv2:begin
select a, b, c from {{ source('raw', 'table_2') }}
--mv2:end

-- models/my_model_mv_mv1.sql
{{ config(materialized='materialized_view') }}
{{ materialization_target_table(ref('events_daily')) }}

select a, b, c from {{ source('raw', 'table_1') }}

-- models/my_model_mv_mv2.sql
{{ config(materialized='materialized_view') }}
{{ materialization_target_table(ref('events_daily')) }}

select a, b, c from {{ source('raw', 'table_2') }}

• Comme les vues matérialisées de ClickHouse agissent comme des déclencheurs d’insertion, elles ne capturent les données que tant qu’elles existent. Si une vue matérialisée est supprimée puis recréée (par exemple lors d’un --full-refresh), les lignes insérées dans la table source pendant cet intervalle ne seront pas traitées par la vue matérialisée. On dit alors que la vue matérialisée est « aveugle ».
• Les différents processus de catchup reposent tous sur des opérations INSERT INTO ... SELECT qui utilisent le SQL des vues matérialisées et sont indépendants de leur fonctionnement. Une fois l’INSERT démarré, les nouvelles données ne sont pas capturées par celui-ci, mais elles le seront par la vue matérialisée attachée.

{{
    config(
        materialized='materialized_view',
        engine='MergeTree()',
        order_by='(event_date)',
        refreshable={
            "interval": "EVERY 5 MINUTE",
            "randomize": "1 MINUTE",
            "append": True,
            "depends_on": ['schema.depend_on_model'],
            "depends_on_validation": True
        }
    )
}}

SELECT
    toStartOfDay(event_time) AS event_date,
    count() AS total
FROM {{ source('raw', 'events') }}
GROUP BY event_date

{{
    config(
        materialized='materialized_view',
        refreshable={
            "interval": "EVERY 1 HOUR",
            "append": False
        }
    )
}}
{{ materialization_target_table(ref('events_daily')) }}

SELECT
    toStartOfDay(event_time) AS event_date,
    event_type,
    count() AS total
FROM {{ source('raw', 'events') }}
GROUP BY event_date, event_type

• Lors de la création d’une vue matérialisée actualisable (MV) dans ClickHouse avec une dépendance, ClickHouse ne renvoie pas d’erreur si la dépendance spécifiée n’existe pas au moment de la création. À la place, la MV actualisable reste dans un état inactif, en attendant que la dépendance soit disponible avant de commencer à traiter les mises à jour ou à s’actualiser. Ce comportement est intentionnel, mais il peut retarder la disponibilité des données si la dépendance requise n’est pas mise en place rapidement. Assurez-vous que toutes les dépendances sont correctement définies et existent avant de créer une vue matérialisée actualisable.
• À ce jour, il n’existe pas de véritable « liaison dbt » entre la vue matérialisée et ses dépendances, de sorte que l’ordre de création n’est pas garanti.
• La fonctionnalité d’actualisation n’a pas été testée avec plusieurs vues matérialisées pointant vers le même modèle cible.