MV w ClickHouse: utrata danych i kontrola

Materializowane widoki w ClickHouse: scenariusze utraty danych

Materializowane widoki (MV) w ClickHouse działają jak triggery na INSERT w środowisku append-only. Przechwytują zmiany danych bez obsługi UPDATE lub DELETE. MV są niezawodne przy przestrzeganiu reguł, ale zmiany schematów tabel prowadzą do utraty danych.

Kluczowe ryzyko: ClickHouse pozwala na modyfikację tabel źródłowych i docelowych niezależnie od aktywnych MV. To odróżnia system od tradycyjnych SGBD.

Klasyczny schemat działania

Utwórz testowe tabele i MV do demonstracji:

-- Iskhodnaya table
DROP TABLE IF EXISTS test_orders;
CREATE TABLE test_orders (
    order_id String,
    order_dt Datetime
)
ENGINE = MergeTree
ORDER BY order_id;

-- Tselevaya 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 for perenapravleniya 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;

Wstaw dane:

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');

Zapytanie SELECT * FROM final_test_orders zwróci wszystkie rekordy poprawnie.

Naruszenie schematu tabeli docelowej

Zmień typ kolumny w 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;

Powtórz wstawienie do test_orders. MV zgłosi błąd konwersji String na UInt64. Dane zapiszą się do tabeli źródłowej, ale nie do docelowej. INSERT zakończy się niepowodzeniem z powodu atomowości blokowej.

ClickHouse wstawia dane blokami. Błąd w MV przerywa cały INSERT, ale częściowe bloki mogą zostać zapisane.

Ignorowanie błędów MV

Ustawienie materialized_views_ignore_errors=true tłumi błędy 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');

Dane są zapisywane w test_orders, ale nie ma ich w final_test_orders. To kontrolowana utrata w tabeli docelowej.

Monitorowanie błędów za pomocą logów systemowych

Użyj system.query_views_log do śledzenia awarii 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;

Zapytanie zwraca znacznik czasu błędu, nazwę MV i tekst wyjątku. Skonfiguruj alerty na te zdarzenia w środowiskach produkcyjnych.

Połączenie materialized_views_ignore_errors=true z monitorowaniem minimalizuje ryzyka.

Niekontrolowane utraty przy desynchronizacji kolumn

MV używa nazw kolumn, a nie pozycji. Brakujące kolumny są wypełniane wartościami domyślnymi bez błędów.

Zmień nazwę kolumny:

DROP TABLE IF EXISTS final_test_orders;
CREATE TABLE final_test_orders (
    orders String,
    order_dt Datetime
)
ENGINE = MergeTree
ORDER BY orders;

Wstawienie do test_orders przebiegnie pomyślnie. W final_test_orders kolumna orders zostanie wypełniona pustymi ciągami — dane utracone bezobjawowo.

Zalecenia dotyczące eksploatacji MV

• Sprawdzaj obecność kolumn w tabeli docelowej przy tworzeniu MV.
• Testuj MV po wdrożeniu.
• Unikaj zmian schematów tabel z aktywnymi MV.
• Wdrażaj alerty na system.query_views_log.

Co ważne:

• MV to niekontrolowany ETL bez gwarancji transakcyjnych.
• Blkowa wstawka tworzy ryzyko częściowych utrat przy błędach.
• materialized_views_ignore_errors=true zachowuje dane źródłowe, ale wymaga monitorowania.
• Desynchronizacja nazw kolumn prowadzi do cichych awarii.
• Dokumentacja ClickHouse ostrzega przed ryzykami MV.

— Editorial Team