Praca z danymi historycznymi

1) Cel i zasady

Cel: Przechowywanie i przetwarzanie przeszłych stanów, tak aby raporty, modele i badania były powtarzalne, dokładne i zgodne.

• Czas-świadomy przez design-Explicit modeli czasu w schematach i zapytaniach.
• Odtwarzalność: Ten sam raport dla daty D zawsze daje ten sam wynik.
• Dźwięk: linia, warstwy niezmienne, WORM w razie potrzeby.
• Świadomość kosztów: warstwy archiwalne, kompresja, chłodnia z zrozumiałymi SLA.
• Privacy-by-design: PII management for retrospective transactions and legal requests.

2) Modele czasu

Czas zdarzenia: czas rzeczywistego zdarzenia (stawka, depozyt).
Czas przetwarzania, kiedy system przetworzył rekord (może się różnić).
Bitemporal: przechowywanie zarówno zdarzenia- i przetwarzania-czas dla edycji wstecznych.
Przedziały ważności: 'valid _ from', 'valid _ to', 'is _ current'.
Zapytania: pobieranie próbek danych „jak wiedzieli w czasie T”.

sql event_time TIMESTAMP, -- event time processed_at TIMESTAMP, -- TIMESTAMP valid_from processing time, -- start of version validity valid_to TIMESTAMP, -- end of validity (NULL if current)
is_current   BOOLEAN

3) Warstwy i formaty składowania

Lakehouse: Brąz (tylko surowy dodatek) → Srebrny (czysty/SCD/normalizacja) → Złoto (prezentacje).
ACID-морката: Delta/Iceberg/Hudi (MERGE/Upsert, podróże w czasie, snapshots).
Magazyn wielopoziomowy: gorący/ciepły/zimny + WORM do artefaktów regulacyjnych.
Podział: „event _ date”, „market”, „najemca”; clustering/Z-order przez częste predykaty (użytkownik/gra/dostawca).

4) Historia pomiarów (SCD)

SCD I: nadpisanie - dla edycji innych niż krytyczne.
SCD II: pełna historia; zalecane dla RG/KYC/kanałów ruchu/atrybutów gry.
SCD III: „przed/po” - rzadkie przypadki porównania.

sql
MERGE INTO dim. users_scd t
USING stage. users u
ON t. user_pseudo_id = u. user_pseudo_id AND t. is_current = TRUE
WHEN MATCHED AND (t. rg_status <> u. rg_status OR t. country <> u. country) THEN
UPDATE SET is_current = FALSE, valid_to = CURRENT_TIMESTAMP
WHEN NOT MATCHED THEN
INSERT (user_pseudo_id, country, rg_status, valid_from, valid_to, is_current)
VALUES (u. user_pseudo_id, u. country, u. rg_status, CURRENT_TIMESTAMP, NULL, TRUE);

5) Historia faktów: migawki i bitemporalne

Migawki: migawka agregatów koniec dnia/miesiąc (takich jak bilans portfela) - przyspieszenie ponownego tworzenia raportów historycznych.
Fakty bitemporalne: naprawić czas zdarzeń i czas przetwarzania, aby odróżnić późne poprawki od obliczeń retrospektywnych.
Dokładnie raz historia: dedup przez 'event _ id' + idempotent MERGE.

6) Podróż w czasie i odtwarzalność

Podróże w czasie: czytanie tabel „w czasie T” do debugowania, incydentów, pojednań.
Wersioning logiczny: artefakty transformacyjne (wersje SQL/DBT, kontenery) i etykiety „logic_version” w tabelach wyjściowych.
Zamrożone wyjścia: Złote artefakty raportujące są przechwytywane i nie są przepisywane, dostępne są hash i dziennik eksportu.

sql
SELECT
FROM silver. fact_bets VERSION AS OF 1678901234567
WHERE event_date = DATE '2025-10-31';

7) Backfill, Reprocessying

Zasypka: Podstawowy/preload historyczny zakres.
Ponowne przetwarzanie: ponowne obliczenie po ustaleniu błędów lub zmianie zasad biznesowych.

• Idempotencja (MERGE/upsert), zakresy, kwoty, suchy bieg z porównaniem metrycznym.
• Oznaczanie wyniku: 'recalc _ reason', 'logic _ version', 'reprocessed _ at'.

1. Zamrozić obecne złoto; 2) weryfikacja DLQ/DQ; 3) Silver run; 4) porównanie mierników; 5) Przebudowa złota; 6) publikacja i podpis.

8) Pojednanie

Checksums: uzgodnienie wielkości sprzedaży/ilości z OLTP, PSP/dostawcami.
Kontrola pętli: niezależny rurociąg na próbce (porównanie A/B).
Tolerancje takie jak rozbieżność GGR ≤ 0. 2% za dzień.

sql
-- Duplicates
SELECT transaction_id, COUNT() c
FROM silver. payments
GROUP BY transaction_id
HAVING COUNT() > 1;

-- Unknown Currencies/Markets
SELECT p. currency
FROM silver. payments p
LEFT JOIN ref. currencies r ON r. code = p. currency
WHERE r. code IS NULL;

9) Waluty, czas, kalendarz: historyczna poprawność

FX w dniu zdarzenia: naprawić 'fx _ rate _ used' i 'fx _ source'.
Czas rynku lokalnego: DST/Timezones za pośrednictwem katalogu kalendarza.
Wakacje/sezonowość: oddzielna tabela kalendarzowa, stosowana w modelach i raportach.

sql
SELECT p. transaction_id,
p. amount_orig,
r. rate AS fx_rate_used,
p. amount_orig r. rate AS amount_base,
r. fx_source
FROM bronze. payment_events p
JOIN dim. fx_rates r
ON r. date = DATE(p. event_time) AND r. ccy_from = p. currency AND r. ccy_to = 'EUR';

10) PII, Zgodność i Posiadanie Prawa

Minimalizacja PII: pseudonimizacja, oddzielne mapowanie chronione.
DSAR/RTBF: obliczeniowe projekcje i selektywne edycje warstw historycznych; udokumentowano prawne wyjątki w zakresie przechowywania.
Legal Hold: flagi „zamrozić” usunięcia na zakresach/obiektach, WORM dla artefaktów raportowanych.
Audyt: niezmienne dzienniki dostępu i eksportu.

11) DQ i rodowód do historii

yaml table: silver. fact_bets slo:
completeness_percent: 99. 5 freshness_minutes: 60 rules:
- name: unique_bet type: unique columns: [bet_id]
severity: critical
- name: market_known type: in_set column: market set_ref: ref. markets
- name: ts_in_range type: temporal expression: "event_time BETWEEN date_sub(now(), interval 5 year) AND now()"

Rodowód: naprawić wersje wejść/transformacji/wyjść; wykres zależności jest wymagany dla retroformacji.

12) Wydajność i koszt

Podział: według daty/rynku/najemcy; agresywne klastrowanie przez 'user _ pseudo _ id'/' game _ id', jeśli często filtrujemy.
Formaty: Parkiet + statystyki/kompresja; regularne ODKURZANIE/OPTYMALIZACJA.
Materializacja: prekomput do „drogich” agregacji historycznych; migawki do sprawozdawczości kwartalnej/rocznej.
Archiwizacja: konwersja starych partii do chłodni (SLA do odzysku są udokumentowane).
Pobieranie próbek: wyłącznie w odniesieniu do zadań badawczych, a nie do regulacji/finansowania.

13) Historyczne cechy dla ML

Rejestr funkcji: każda funkcja posiada formułę, właściciela, SLO, 'model _ version'.
Spójność online/offline: jedna baza kodowa transformacji, testy powtarzalności.
Charakterystyczny dryf: PSI/KS według okresu, przechowywanie historycznych dystrybucji.

14) Wzory zapytań

Odtwarzalność raportów.
Analiza kohort: kohorty rejestracji/pierwsze depozyty, okna toczenia.
Powoli zmieniające się fakty: корректна ("event _ time BETWEEN valid_from AND COALESCE (valid_to,' 9999-12-31") ").

sql
SELECT b. bet_id, u. rg_status
FROM silver. fact_bets b
JOIN dim. users_scd u
ON u. user_pseudo_id = b. user_pseudo_id
AND b. event_time >= u. valid_from
AND (u. valid_to IS NULL OR b. event_time < u. valid_to);

15) Procesy i RACI

R (odpowiedzialny): inżynieria danych (modele/SCD/backfill), platforma danych (ACID/archive), finanse/zgodność (uzgodnienia/wymagania dotyczące przechowywania).
A (Odpowiedzialność): szef danych/CDO.
C (skonsultowano się): Legal/DPO (DSAR/RTBF/Legal Hold), SRE (cost/SLA), Architektura.
I (Poinformowany): BI/Produkt/Marketing/Operacje.

16) Plan działania w zakresie wdrażania

1. KWASOWE tabele z podróżą w czasie (Delta/Góra Lodowa/Hudi) i przegrodą podstawową.

2. SCD II dla kluczowych wymiarów (użytkownicy/gry/dostawcy).

3. Codzienne migawki agregatów krytycznych (GGR Daily).

4. DQ-as-code (uniqueness/in_set/temporal) + wykres linii.

• Fakty bitemporalne, od szablonów API/SQL, runbooks backfill/reprocessing.
• FX/kalendarz/wzbogacanie DST, pojednania OLTP z DWH/provaydery.
• Archiwizacja chłodni, WORM do zgłaszania pakietów, Legal Hold.

• Kompletna automatyzacja „replay & what-if”, porównanie mierników i alertów regresyjnych.
• Historyczne cechy i sterowanie dryfem ML, obciążenie zwrotne kosztów przechowywania.
• Dokumentacja „od” mierników i powtarzalnych raportów.

17) Lista kontrolna przedsprzedaży

• Tabele wspierające podróże w czasie; POLITYKA PRÓŻNI/RETENCJI jest spójna.
• SCD II jest wdrażany do pomiarów krytycznych; Join jest przetestowany.
• Zdjęcia kluczowych jednostek na D/M są dostępne i sprawdzane za pomocą iskier.
• Zasady DQ są aktywne; lineage wyświetla wejścia/wyjścia i wersje logiczne.
• DSAR/RTBF/Legal Hold przetestowane na warstwach historycznych.
• Archiwizacja i odzyskiwanie chłodni udokumentowane i zweryfikowane.
• Koszt/GB, udział na zimno, odzyskiwanie SLA

18) Częste błędy i jak ich uniknąć

Brak wyraźnego modelu czasu: dodać zdarzenie/przetwarzanie/ważność.
FX „retroactive”: zawsze kurs w czasie zdarzenia, przechowywać 'fx _ source'.
Nieprawidłowe przyłączenie się do SCD: użyj przedziału ważności, a nie 'is _ current'.
Mutating Gold showcases: reportable outputs must be immutable (or versioned).
Brak lineage/DQ: brak sprawdzalności i punktów kontrolnych - wprowadź je od pierwszego dnia.
Niezagospodarowany koszt: wyłączyć gorące imprezy, próżnię, przeliczyć na zimno.

19) Słownik

As-of Query - żądanie danych „jak patrzyli na czas T”.
Bitemporal - jednoczesne utrwalenie zdarzenia i czas przetwarzania.
Migawka - zmaterializowana migawka stanu/agregatów na koniec okresu.
Podróże w czasie - czytanie historycznych wersji tabel.
WORM - Napisz raz przeczytać wiele.

20) Sedno sprawy

Praca z danymi historycznymi to nie tylko „długie przechowywanie”, ale dyscyplina czasu: wyraźne zdarzenie/przetwarzanie/bitemporalne, modele SCD i migawki, odtwarzalne jako żądania, rygorystyczne uzgodnienia i kontrole zgodności, obserwowalność i opłacalna architektura przechowywania. Wykonując ten przewodnik, będziesz mieć solidną historyczną podstawę do raportowania, analityki i ML, która jest odporna na audyt i zmiany w logice biznesowej.