Vistas materializadas

1. Crear una tabla de destino con el nombre del modelo
2. Crear una vista materializada de ClickHouse con el nombre <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'  # esta configuración
)}}

{{config(
    materialized='materialized_view',
    engine='MergeTree()',
    order_by='(id)',
    catchup=False  # esta configuración
)}}

• Todos los recursos (tabla de destino + MVs) comparten la misma configuración. Si varias MVs apuntan a la misma tabla de destino, deben definirse juntas mediante la sintaxis UNION ALL.
• Ninguno de estos recursos puede procesarse por separado; todos deben administrarse mediante el mismo archivo de modelo.
• No es fácil controlar el nombre de cada MV.
• Toda la configuración se comparte entre la tabla de destino y las MVs, lo que dificulta configurar cada recurso individualmente y determinar qué configuración corresponde a cada uno.

• Recursos totalmente separados: Ahora cada recurso puede definirse por separado, lo que mejora la legibilidad.
• Recursos 1:1 entre dbt y CH: Ahora puedes usar las herramientas de dbt para gestionarlos y modificarlos por separado.
• Ahora hay distintas configuraciones disponibles: Ahora se puede aplicar una configuración diferente a cada uno.
• Ya no es necesario mantener convenciones de nomenclatura: Ahora todos los recursos se crean con el nombre que les des, no con el nombre personalizado añadido con _mv para las MV.

• La definición de la tabla de destino no es natural en dbt: no es un SQL que lea de una tabla de origen, por lo que aquí se pierden las validaciones de dbt. El SQL de la MV se seguirá validando mediante las utilidades de dbt, y su compatibilidad con las columnas de la tabla de destino se validará a nivel de CH.
• Hemos encontrado algunos problemas relacionados con las limitaciones de la función ref(): Necesitamos usarla para referenciar modelos entre sí, pero solo puede usarse para referenciar modelos upstream, no downstream. Esto genera algunos problemas en esta implementación. Hemos creado una incidencia en el repositorio de dbt-core y actualmente estamos hablando con ellos para buscar posibles soluciones (dbt-labs/dbt-core#12319):
  • Cuando se llama a ref() desde dentro del bloque de configuración, devuelve el modelo actual, no el compartido. Esto nos impide definirlo en la sección config(), por lo que nos obliga a usar un comentario para añadir esta dependencia. Estamos siguiendo el mismo patrón definido en la documentación de dbt con el enfoque “—depends_on:”.
  • ref() nos funciona porque fuerza que la tabla de destino se cree primero, pero en el gráfico de dependencias de la documentación generada, la tabla de destino aparecerá como otra dependencia upstream, no downstream, lo que hace que sea algo difícil de entender.
  • unit-test también nos obliga a definir algunos datos para la tabla de destino, incluso cuando la idea no es leer de ella. La solución alternativa es simplemente dejar vacíos los datos de esta tabla.

{{
    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  -- Crea una tabla vacía con el esquema correcto

{{ 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  -- este es el valor predeterminado, por lo que no necesitas configurarlo explícitamente.
) }}
{{ materialization_target_table(ref('events_daily')) }}
...

1. Crear una nueva tabla temporal
2. Ejecutar INSERT-SELECT usando el SQL de cada MV
3. Intercambiar atómicamente las tablas

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

1. Actualiza la llamada a materialization_target_table()
2. Ejecuta dbt run --full-refresh -s your_mv_model

• Las vistas materializadas pueden estar configuradas con catchup=False o la tabla de destino puede estar configurada con repopulate_from_mvs_on_full_refresh=False, por lo que no se realizará ningún relleno de datos históricos cuando se creen las vistas materializadas o cuando se vuelva a crear la tabla de destino. Este es el comportamiento esperado, así que, si quiere volver a insertar los datos usando el SQL de las vistas materializadas, asegúrese de establecer catchup=True en la vista materializada (este es el valor predeterminado) o repopulate_from_mvs_on_full_refresh=True en la tabla de destino. Asegúrese de no activar ambas opciones al mismo tiempo para evitar duplicados. Consulte la sección de configuración para obtener más detalles.
• Mientras se ejecuta dbt run --full-refresh, si las vistas materializadas usan el valor predeterminado catchup=True, el destino se volverá a crear y las MV volverán a insertar los datos de forma secuencial. Para evitar esta situación, consulte Full refresh con destinos explícitos.

• Tanto catchup=True en las vistas materializadas como repopulate_from_mvs_on_full_refresh=True en la tabla de destino pueden estar habilitados: mantén solo uno de ellos, según las operaciones que quieras ejecutar. Consulta la sección de configuración para obtener más detalles.
• La tabla de destino no está definida con WHERE 0: la tabla de destino debe crearse vacía, pero la consulta interna puede insertar datos si no se incluye WHERE 0. Asegúrate de que la cláusula esté incluida.

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 tabla <table_name> se usa como destino de una vista materializada gestionada por dbt. Se establece mv_on_schema_change en “fail” de forma predeterminada para evitar la pérdida de datos.

• El modelo de vista materializada define {{ materialization_target_table(ref('your_target')) }} correctamente
• El modelo de vista materializada tiene materialized='materialized_view' en su configuración
• Tanto la vista materializada como la tabla de destino se han ejecutado al menos una vez

-- 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 solo se definió una MV, tendrá este nombre: <old_model_name>_mv
• si se definieron varias MV, cada una tendrá este nombre: <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') }}

• Como las vistas materializadas de ClickHouse actúan como triggers de inserción, solo capturan datos mientras existen. Si una vista materializada se elimina y se vuelve a crear (p. ej., durante un --full-refresh), cualquier fila insertada en la tabla de origen durante ese intervalo no será procesada por la vista materializada. A esto se le llama que la vista materializada está “ciega”.
• Los distintos procesos de catchup se basan en operaciones INSERT INTO ... SELECT que usan el SQL de las vistas materializadas y son independientes de cómo funcionan estas. Una vez que comienza el INSERT, los datos nuevos no se capturan por esa operación, pero sí los capturará la vista materializada adjunta.

{{
    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

• Al crear una vista materializada actualizable (MV) en ClickHouse que tiene una dependencia, ClickHouse no devuelve un error si la dependencia especificada no existe en el momento de la creación. En su lugar, la MV actualizable permanece en un estado inactivo, a la espera de que se cumpla la dependencia antes de empezar a procesar actualizaciones o a refrescarse. Este comportamiento es intencional, pero puede provocar retrasos en la disponibilidad de los datos si la dependencia requerida no se resuelve con prontitud. Debe asegurarse de que todas las dependencias estén correctamente definidas y existan antes de crear una vista materializada actualizable.
• A día de hoy, no existe una “vinculación con dbt” real entre la mv y sus dependencias, por lo que el orden de creación no está garantizado.
• La funcionalidad de actualización no se ha probado con varias mvs dirigidas al mismo modelo de destino.