# Vistas materializadas en ClickHouse: Escenarios de pérdida de datos
Las vistas materializadas (MVs) en ClickHouse funcionan como disparadores en operaciones INSERT en un entorno solo de inserción. Capturan los cambios de datos sin soporte para UPDATE o DELETE. Las MVs son fiables cuando se siguen las reglas, pero los cambios en el esquema de las tablas pueden provocar pérdida de datos.
Principal riesgo: ClickHouse permite modificar las tablas de origen y destino de forma independiente de las MVs activas. Esto lo diferencia de los SGBD tradicionales.
Flujo de trabajo clásico
Crear tablas de prueba y una MV para demostración:
-- Source table
DROP TABLE IF EXISTS test_orders;
CREATE TABLE test_orders (
order_id String,
order_dt Datetime
)
ENGINE = MergeTree
ORDER BY order_id;
-- Target table
DROP TABLE IF EXISTS final_test_orders;
CREATE TABLE final_test_orders (
order_id String,
order_dt Datetime
)
ENGINE = MergeTree
ORDER BY order_id;
-- MV to redirect data
DROP VIEW IF EXISTS mv_final_test_orders;
CREATE MATERIALIZED VIEW mv_final_test_orders
TO default.final_test_orders (
order_id String,
order_dt Datetime
)
AS SELECT order_id, order_dt FROM test_orders;
Insertar datos:
INSERT INTO test_orders VALUES
('QWE123', '2025-03-01 12:00:00'),
('RTY456', '2025-03-01 13:00:00'),
('XYZ789', '2025-03-01 14:00:00');
La consulta SELECT * FROM final_test_orders devolverá todos los registros correctamente.
Alterando el esquema de la tabla destino
Cambiar el tipo de columna en final_test_orders:
DROP TABLE IF EXISTS final_test_orders;
CREATE TABLE final_test_orders (
order_id UInt64,
order_dt Datetime
)
ENGINE = MergeTree
ORDER BY order_id;
Repetir la inserción en test_orders. La MV generará un error de conversión de String a UInt64. Los datos se escribirán en la tabla de origen pero no en la de destino. La INSERT fallará debido a la atomicidad de bloques.
ClickHouse inserta datos en bloques. Un error en la MV interrumpe toda la INSERT, pero bloques parciales pueden persistir.
Ignorando errores de MV
La configuración materialized_views_ignore_errors=true suprime los errores de MV:
INSERT INTO test_orders SETTINGS materialized_views_ignore_errors = true VALUES
('QWE123', '2025-03-01 12:00:00'),
('RTY456', '2025-03-01 13:00:00'),
('XYZ789', '2025-03-01 14:00:00');
Los datos se confirman en test_orders, pero nada aparece en final_test_orders. Esta es una pérdida controlada en la tabla destino.
Monitoreo de errores a través de los registros del sistema
Usar system.query_views_log para rastrear fallos de MV:
SELECT event_time, view_name, exception
FROM system.query_views_log
WHERE event_date = today() AND exception_code != 0
ORDER BY event_time DESC
LIMIT 1000;
La consulta devuelve la marca de tiempo del error, nombre de la MV y texto de la excepción. Configurar alertas para estos eventos en entornos de producción.
Combinar materialized_views_ignore_errors=true con monitoreo minimiza los riesgos.
Pérdidas no controladas por desajustes de columnas
Las MVs usan nombres de columnas, no posiciones. Las columnas faltantes se rellenan con valores predeterminados sin errores.
Renombrar la columna:
DROP TABLE IF EXISTS final_test_orders;
CREATE TABLE final_test_orders (
orders String,
order_dt Datetime
)
ENGINE = MergeTree
ORDER BY orders;
La inserción en test_orders tendrá éxito. En final_test_orders, la columna orders se rellenará con cadenas vacías — datos perdidos silenciosamente.
Recomendaciones para operar MVs
- Verificar las columnas en la tabla destino al crear una MV.
- Probar las MVs después del despliegue.
- Evitar cambios de esquema en tablas con MVs activas.
- Implementar alertas en
system.query_views_log.
Puntos clave:
- Las MVs son ETL no controlados sin garantías transaccionales.
- Las inserciones en bloques crean un riesgo de pérdidas parciales ante errores.
materialized_views_ignore_errors=truepreserva los datos de origen pero requiere monitoreo.- Los desajustes en nombres de columnas llevan a fallos silenciosos.
- La documentación de ClickHouse advierte sobre los riesgos de las MVs.
— Editorial Team
Aún no hay comentarios.