Fabric | dbt – Slowly changing dimension (SCD 2) – Snapshots a Check Strategie v dbt s příkladem

Slowly Changing Dimensions (SCD) představují způsob, jak v datovém skladu uchovávat a spravovat historické změny dimenzí v čase. Pro zopakování teorie co jsou to fakta a dimenze doporučuju před dalším pokračováním prolítnout článek – Fakta a dimenze – Tabulky v datovém skladu.

V kontextu medailonové architektury, ve které pracujeme ve Fabricu, spadá generování SCD do Silver vrstvy s tím, že v Gold vrstvě ještě ošetřujeme krajní hodnoty intervalů platnosti. Budeme používat dimenze typ 2 (víz dále – Teorie). Cílem je zajistit úplnou historii změn pro všechny klíčové dimenze tak, aby bylo možné zpětně analyzovat stav dat k jakémukoli okamžiku (time travel). V rámci ve Fabricu máme SCD implementován v prostředí dbt (Data Build Tool), které umožňuje řídit transformace dat deklarativním způsobem – tedy, často nemusíme pro správné sestavení dimenzí vynaložit příliš velké úsilí a dbt to vyřeší za nás. Ale postupně…

Teorie – Co je Slowly Changing Dimension (SCD) a její cíle

Koncept Slowly Changing Dimensions byl poprvé systematicky popsán Ralphem Kimballlem v knize The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses”, která vyšla v roce 1996. ¹

Zjednodušeně řečeno SCD popisuje soubor technik a strategií, jak zachycovat a spravovat změny v datech dimenzí. Historicky se vyvinula celá řada typů Slowly changing dimensions s tím, že v praxi se používá u datových řešení zdaleka nejvíce typ 1 a 2. Volba konkrétní SCD v rámci datového řešení má dopady ve 2 základních rovinách:

• Hlavním cílem SCD je zajistit přesnou interpretaci historických a aktuálních dat ve vztahu k analytickým faktům a aktuálním i budoucím reporting potřebám podnikových stakeholderů – a to s ohledem na vedlejší cíl:
• Vedlejším cílem ve smyslu volby typu SCD je ohled na výkonovou náročnost řešení a technické aspekty a udržitelnost datového řešení. SCD 2 je technicky náročnější jak z pohledu vývoje, tak z pohledu režijních nákladů na strojový čas, protože SCD 2 generuje více záznamů. Navíc to pochopitelně prodražuje celý datový model a může to mít nemalé finanční dopady zejména v případě, kdy datové prostředí provozujeme v Pay as You Go prostředích (Azure, Snowfake, AWS, atp.).

Typy Slowly changing dimensions – Význam a časová validita záznamů

Rozlišujeme několik typů SCD:

• SCD Typ 0 – Žádná změna není uchovávána >> data jsou statická.
• SCD Typ 1 –  Změna přepíše původní hodnotu >> historie se nezachovává a držíme pouze poslední známý stav
• SCD Typ 2 – Každá změna vytváří nový záznam >> zachovává se úplná historie změn. Tohle je náš přístup k silver/stage vrstvě ve Fabricu)
• SCD Typ 3 – Uchovává se omezená historie, např. předchozí a aktuální hodnota >> méně časté.
• Ostatní – Některé zdroje popisují ještě další typy SCD (4-7), ale tady to řešit nebudu vzhledem k tomu, že ty se hodí spíše pro specifické scénáře jako jsou například obrovské dimenzní tabulky, kde se řeší performance optimalizace atp. ²

V praxi je SCD Typ 2 nejčastěji používaný, protože umožňuje udržovat kompletní historii změn dimenzí, včetně časového vymezení platnosti jednotlivých záznamů – typicky je označujeme jako

• valid_from – od kdy daná historická verze záznamu platí
• valid_to – do kdy daná historická verze záznamu platí

Platí, že valid_from a valid_to by přes společné business klíče (primární klíč zdrojové tabulky) měla být diskrétní (musí na sebe navazovat bez časových mezer).

SCD 2 a krajní hodnoty validity – Strážná hodnota (Sentinel value)

V praxi v datové architektuře musíme často řešit otázku krajních intervalů platnosti. Na obrázku níže vidíme tabulku s adresami zafiltrovanou na AddressId=659 a vybrany jsou pouze určité atributy.

• První historická verze adresy platí od 2025-01-01 do 2025-10-19
• Druhá historická verze platí do 2025-10-19 do NULL (nekonečno) – aktuální záznam

Nyní se dostáváme k jádru věci. Tento způsob vedení krajních hodnot není úplně vhodný do Gold vrstvy, protože se s tím pak špatně pracuje a museli bychom si dávat velký pozor při joinech

• NULL v každém joinu nahrazovat nějakým datumem
• počáteční hodnota se nám teoreticky nemusí potkat s driving datumem faktové tabulky (datum faktu může být starší než startovní datum dimenze)

Právě z těchto důvodů se v praxi velmi často zavádí obecné pravidlo implementace sentinel values (strážných hodnot).

• první výskyt dimenze dostává datum Technický start = 1900-01-01 (nebo prostě nějaké staré)
• aktuální hodnota dostává Technický konec = 3000-12-31 (nebo nějaký jiný starší)

Jak SCD řeším ve Fabric projektu – pomocí dbt vygenerujeme SCD 2 do silver vrstvy (příklad viz dále) jako full history a sentinel values nebo jiné úpravy řeším až o úroveň výše v Gold vrstvě při přípravě dimenzních a faktových tabulek.

Implementace SCD 2 v dbt pomocí snapshotů – ukázka

V prostředí dbt je SCD Typ 2 typicky realizován pomocí tzv. snapshotů. Snapshoty umožňují zachytit stav tabulky v čase a automaticky spravovat historické změny na základě definované strategie (strategy), typicky timestamp nebo check.

V tomto Fabric projektu je implementace založena na check strategii, která porovnává aktuální stav dat se stavem uloženým v předchozím snapshotu. Pokud se některý z definovaných sloupců (check_cols) změní (můžeme vydefinovat nebo napsat all), dbt vytvoří nový záznam a uzavře předchozí (pomocí polí dbt_valid_from a dbt_valid_to).

{% snapshot st_aw_address %}

{{
  config(
    target_schema='02_silver',
    strategy='check',
    check_cols='all',
    unique_key='source_businesskey',
    updated_at='ingestion_date',
    invalidate_hard_deletes=True,
    schema='02_silver',
    alias='st_aw_address'
  )
}}

WITH [ranked_source] AS (
    SELECT *,
           ROW_NUMBER() OVER (PARTITION BY [source_businesskey],[source_system] ORDER BY [ingestion_date] DESC,[source_updated_at] DESC) AS [dbt_row_num]
    FROM {{ source('bronze_data_source_fabricdatalake', 'bt_aw_address') }}
    
    /* DATA CLEANSING, FORMATING, DEDUPLICATION */
)
SELECT *
FROM [ranked_source]
WHERE [dbt_row_num] = 1

{% endsnapshot %}

Podobně jako v kódu nahoře máme připraveny všechn definice snapshot tabulek, u kterých chceme historizovat. Na screenshotu níže se můete podívat, jak to vypadá připravené v dbt. Spuštění je jednoduše přes příkaz v terminálu “dbt snapshot”.

Tento jednoduchý přístup umožňuje automaticky řídit vznik nových verzí dimenzí při každé změně hodnoty ve zdroji. Pomocí parametru invalidate_hard_deletes=True je zároveň zajištěno, že i fyzicky odstraněné záznamy ze zdroje budou v rámci snapshotu korektně uzavřeny. Výsledkem je plně historizovaná dimenze v Silver vrstvě, která poskytuje konzistentní zdroj dat pro Gold vrstvu a tedy finální přípravu dimenzí.

Nevýhodou dbt snapshot přístupu může být vyšší výpočetní náročnost, zejména v případě velkých dimenzních tabulek. Většinou však nejsou dimenzní tabulky (na rozdíl od faktových) příliš velké a tento přístup si z důvodu velké časové úspory můžeme dovolit.

Shrnutí SCD 2 přes dbt

Implementace SCD Typ 2 pomocí snapshotů v dbt poskytuje robustní a automatizovaný způsob správy historických změn dimenzí. V kombinaci s architekturou Fabric a medailonovým přístupem představuje efektivní nástroj pro tvorbu transparentních a auditovatelných datových modelů s úplnou historií.

1. Wikipedie, Ralph Kimball [on-line]. [cit. 2025-10-31]. Dostupné z WWW: https://en.wikipedia.org/wiki/Ralph_Kimball
2. hevodata.com, Slowly Changing Dimensions: 5 Key Types and Examples [on-line]. [cit. 2025-10-31]. Dostupné z WWW:  https://hevodata.com/learn/slowly-changing-dimensions/