Materialisierte Ansichten in ClickHouse: Szenarien für Datenverlust
Materialisierte Ansichten (MVs) in ClickHouse fungieren wie Trigger bei INSERT-Operationen in einer append-only Umgebung. Sie erfassen Datenänderungen ohne Unterstützung für UPDATE oder DELETE. MVs sind zuverlässig, solange die Regeln eingehalten werden, aber Änderungen am Tabellenschema können zu Datenverlust führen.
Hauptrisiko: ClickHouse erlaubt die Modifikation von Quell- und Zieltabelle unabhängig von aktiven MVs. Das unterscheidet es von traditionellen DBMS.
Klassischer Workflow
Testtabellen und eine MV zur Demonstration erstellen:
-- 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;
Daten einfügen:
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');
Die Abfrage SELECT * FROM final_test_orders liefert alle Datensätze korrekt zurück.
Schema der Zieltabelle brechen
Spaltentyp in final_test_orders ändern:
DROP TABLE IF EXISTS final_test_orders;
CREATE TABLE final_test_orders (
order_id UInt64,
order_dt Datetime
)
ENGINE = MergeTree
ORDER BY order_id;
Einfügen in test_orders wiederholen. Die MV löst einen Konvertierungsfehler von String zu UInt64 aus. Daten werden in die Quelltabelle geschrieben, aber nicht in die Zieltabelle. Das INSERT schlägt wegen der Blockatomarität fehl.
ClickHouse fügt Daten in Blöcken ein. Ein Fehler in der MV unterbricht das gesamte INSERT, aber partielle Blöcke können erhalten bleiben.
MV-Fehler ignorieren
Die Einstellung materialized_views_ignore_errors=true unterdrückt MV-Fehler:
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');
Daten werden in test_orders übernommen, aber in final_test_orders erscheint nichts. Dies ist ein kontrollierter Verlust in der Zieltabelle.
Fehler über Systemprotokolle überwachen
system.query_views_log zur Nachverfolgung von MV-Fehlern nutzen:
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;
Die Abfrage liefert Zeitstempel des Fehlers, MV-Name und Ausnahmetext. Richten Sie in Produktionsumgebungen Alarme für diese Ereignisse ein.
Die Kombination aus materialized_views_ignore_errors=true und Überwachung minimiert Risiken.
Unkontrollierte Verluste durch Spaltenkonflikte
MVs verwenden Spaltennamen, nicht Positionen. Fehlende Spalten werden mit Standardwerten gefüllt, ohne Fehler.
Spalte umbenennen:
DROP TABLE IF EXISTS final_test_orders;
CREATE TABLE final_test_orders (
orders String,
order_dt Datetime
)
ENGINE = MergeTree
ORDER BY orders;
Das Einfügen in test_orders gelingt. In final_test_orders wird die Spalte orders mit leeren Strings gefüllt – Datenverlust bleibt unbemerkt.
Empfehlungen zum Betrieb von MVs
- Prüfen Sie Spalten in der Zieltabelle beim Erstellen einer MV.
- Testen Sie MVs nach der Bereitstellung.
- Vermeiden Sie Schemaänderungen an Tabellen mit aktiven MVs.
- Richten Sie Alarme auf
system.query_views_logein.
Wichtige Punkte:
- MVs sind unkontrolliertes ETL ohne transaktionale Garantien.
- Blockeinfügungen bergen ein Risiko für partielle Verluste bei Fehlern.
materialized_views_ignore_errors=trueschont Quelldaten, erfordert aber Überwachung.- Spaltennamenskonflikte führen zu stillen Fehlern.
- Die ClickHouse-Dokumentation warnt vor MV-Risiken.
— Editorial Team
Noch keine Kommentare.