Projektowanie i implementowanie tabeli czasowej (historii) w celu rejestrowania zmian w czasie

Potoki danych często wymagają śledzenia nie tylko bieżących wartości, ale każdej zmiany występującej w czasie. Tabele czasowe zapewniają mechanizm automatycznego rejestrowania zmian na poziomie wiersza, umożliwiając zapytania w konkretnym momencie czasu oraz pełne śledzenie inspekcji. W przeciwieństwie do wolno zmieniających się wymiarów, które koncentrują się na historii danych biznesowych, tabele czasowe przechwytują historię techniczną na potrzeby śledzenia operacyjnego i debugowania.

Zrozumienie tabel temporalnych w porównaniu do typu SCD 2

Tabele czasowe i wymiary typu SCD 2 służą różnym celom, chociaż oba te wymiary śledzą zmiany historyczne. Zrozumienie, kiedy należy używać każdego podejścia, pomaga zaprojektować odpowiednie rozwiązania.

Typ SCD 2 śledzi zmiany jednostek biznesowych w czasie na potrzeby raportowania analitycznego. Gdy klient przenosi się z Seattle do Portland, chcesz przypisać sprzedaż historyczną do lokalizacji klienta w momencie każdej transakcji. Typ SCD 2 obsługuje wersje biznesowe z jawnymi datami rozpoczęcia i zakończenia.

Tabele czasowe (historia) przechwytują zmiany techniczne dla potrzeb operacyjnych. Podczas rozwiązywania problemów z przyczyną nieprawidłowego ładowania danych należy zobaczyć dokładnie, jakie wartości istniały w każdym momencie w czasie, które pliki zostały przetworzone i kiedy wystąpiły zmiany. Tabele czasowe zapewniają tę funkcję kryminalistyczną automatycznie.

Rozważ użycie tabel czasowych, gdy musisz:

• Debugowanie problemów z pozyskiwaniem danych przez sprawdzenie stanu tabeli w określonych znacznikach czasu
• Przeprowadź inspekcję wszystkich zmian pod kątem zgodności lub wymagań prawnych
• Odtwarzanie analiz lub raportów z określonego punktu w czasie
• Śledzenie metadanych operacyjnych, takich jak czas ładowania i informacje o pliku źródłowym

Włączanie zestawienia danych zmian na potrzeby śledzenia na poziomie wiersza

Strumień danych zmian usługi Delta Lake automatycznie przechwytuje każdą zmianę na poziomie wiersza. Po włączeniu środowisko uruchomieniowe rejestruje zmiany zdarzeń z metadanymi wskazującymi, czy każdy wiersz został wstawiony, usunięty lub zaktualizowany. Przechwytywanie zmian w danych jest domyślnie wyłączone, więc należy je jawnie włączyć w tabelach, w których ta funkcjonalność jest potrzebna.

Aby włączyć strumień danych o zmianach w nowej tabeli:

CREATE TABLE bronze.sales_transactions (
    transaction_id STRING,
    customer_id STRING,
    amount DECIMAL(10,2),
    transaction_date TIMESTAMP,
    source_file STRING,
    load_timestamp TIMESTAMP
)
USING DELTA
TBLPROPERTIES (delta.enableChangeDataFeed = true);

W przypadku istniejących tabel włącz kanał danych zmian za pomocą instrukcji ALTER TABLE:

ALTER TABLE bronze.sales_transactions 
SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

Historia tabeli zapytań

Po włączeniu zestawienia zmian możesz wykonać zapytanie dotyczące historii zmian, aby zobaczyć dokładnie, jakie modyfikacje wystąpiły. Źródło danych zmian dodaje do danych trzy kolumny metadanych:

Kwerenda zmienia się w określonym zakresie czasu:

SELECT 
    transaction_id,
    amount,
    _change_type,
    _commit_version,
    _commit_timestamp
FROM table_changes('bronze.sales_transactions', '2026-01-01', '2026-01-31')
WHERE _change_type IN ('insert', 'update_postimage')
ORDER BY _commit_timestamp;

To zapytanie pomaga określić, kiedy określone rekordy zostały zmodyfikowane, co jest przydatne podczas debugowania problemów z jakością danych.

Używanie podróży czasowej dla zapytań dotyczących punktu w czasie

Usługa Delta Lake obsługuje dziennik transakcji, który umożliwia wykonywanie zapytań dotyczących danych w dowolnym momencie w historii. Ta funkcja obsługuje scenariusze debugowania, w których należy porównać bieżące dane z poprzednim stanem.

Wykonywanie zapytań o dane w określonym znaczniku czasu:

SELECT * FROM bronze.sales_transactions
TIMESTAMP AS OF '2026-01-15 14:30:00';

Wykonywanie zapytań o dane w określonej wersji:

SELECT * FROM bronze.sales_transactions
VERSION AS OF 42;

Aby wyświetlić pełną historię operacji wykonywanych w tabeli:

DESCRIBE HISTORY bronze.sales_transactions;

Dane wyjściowe historii obejmują typ operacji, znacznik czasu, użytkownika i szczegółowe metryki dla każdej zmiany.

Utrwalanie historii zmian na potrzeby długoterminowej inspekcji

Ponieważ wbudowana funkcja podróży w czasie usługi Delta Lake ma limity przechowywania, należy zachować dane zmian w oddzielnej tabeli historii w celu spełnienia długoterminowych wymogów audytowych. Podejście to tworzy trwały zapis wszystkich zmian.

Użyj przesyłania strumieniowego ze strukturą, aby stale przechwytywać zmiany:

(spark.readStream
    .option("readChangeFeed", "true")
    .option("ignoreDeletes", "false")
    .table("bronze.sales_transactions")
    .writeStream
    .option("checkpointLocation", "/checkpoints/sales_history")
    .trigger(availableNow=True)
    .toTable("audit.sales_transactions_history")
)

Opcja readChangeFeed powoduje, że platforma Spark odczytuje zestawienie danych zmian, które zwraca zdarzenia zmiany na poziomie wiersza, w tym wstawki, aktualizacje i usunięcia. Opcja ignoreDeletes określa, czy operacje usuwania są uwzględniane w strumieniu. Ustawienie false zapewnia, że rekordy skasowania są przechwytywane w tabeli historii, zapewniając pełny ślad audytu wszystkich zmian danych.

Tabela historii zawiera każde zdarzenie zmiany z pełnymi metadanymi, umożliwiając wykonywanie zapytań w całym okresie istnienia danych — nie tylko w oknie przechowywania.

Konfigurowanie przechowywania pod kątem wymagań dotyczących zgodności

W przypadku tabel czasowych obsługujących wymagania dotyczące zgodności lub wymagań prawnych skonfiguruj ustawienia przechowywania, aby spełniały twoje wymagania:

ALTER TABLE bronze.sales_transactions 
SET TBLPROPERTIES (
    delta.logRetentionDuration = 'interval 90 days',
    delta.deletedFileRetentionDuration = 'interval 90 days'
);

Obie właściwości muszą być ustawione razem. Kontrolka logRetentionDuration określa czas przechowywania metadanych historii, a jednocześnie deletedFileRetentionDuration określa, jak długo usuwane pliki danych są zachowywane przed VACUUM ich usunięciem.

Dłuższe okresy przechowywania zwiększają koszty magazynowania, ale zapewniają rozszerzony dostęp do danych historycznych i dostępność przepływu danych dotyczących zmian na potrzeby inspekcji.

Dzięki prawidłowo skonfigurowanym tabelom czasowym można śledzić wszystkie zmiany danych od momentu wprowadzenia do ich transformacji, spełniając wymagania związane zarówno z debugowaniem operacyjnym, jak i zgodnością z przepisami.