</> dbt Analytics Engineering

A dbt projekt struktúra a konvenciókra épül: minden könyvtár egy jól definiált szerepet tölt be. A models/ könyvtár a legfontosabb — ide kerülnek az SQL transzformációs fájlok, amelyeket a dbt futtat. A tests/ könyvtár egyedi SQL teszteket tartalmaz, a macros/ újrahasználható Jinja sablonokat, a snapshots/ SCD Type 2 időutazó históriát, a seeds/ pedig CSV fájlokat, amelyek referenciatáblákként (pl. országkódok, kategória-mapping) tölthetők be.

A dbt_project.yml a projekt központi konfigurációs fájlja. Itt adjuk meg a projekt nevét, verzióját, a használni kívánt profilt (ami a profiles.yml-hez kapcsolódik), és a különböző könyvtárak elérési útját. A legfontosabb rész a models szekció, ahol rétegenként (staging, intermediate, marts) beállíthatjuk az alapértelmezett materializációt. A materializáció határozza meg, hogyan tárolja a dbt a modellt: view (virtuális nézet, nem foglal helyet), table (fizikai tábla, minden futáskor újraépül), vagy incremental (csak az új adatokat adja hozzá).

A példában a staging és intermediate rétegek view-ként, a marts pedig table-ként van materializálva. Ez egy bevált minta: a finomítási lépések (ahol gyakran változik a logika) view-ként működnek, míg a végső business-ready táblák fizikai táblaként, gyorsabb lekérdezhetőség érdekében. A +materialized jelölés azt jelenti, hogy az adott könyvtár összes modelljére érvényes a beállítás, hacsak egy adott modell felül nem írja.

Tip: Tartsd a projekt struktúrát konzisztensen — minden rétegnek saját alkönyvtára legyen a models/ alatt. Ne keverd a staging és mart modelleket egy mappában, mert a későbbi karbantartás és az új csapattagok onboarding-ja sokkal nehezebb lesz.

A staging réteg a nyers adatok első érintkezése a dbt modellezési folyamattal. Itt történik a forrásadatok tisztítása, átnevezése és alapvető szűrése — de semmilyen üzleti logika vagy aggregáció nem. A staging modellek a Medallion architektúra Bronze rétegének felelnek meg: egy-az-egyhez kapcsolatban állnak a forrástáblákkal, de a oszlopnevek már konzisztensek, az adattípusok helyesek, és az érvénytelen sorok kiszűrésre kerültek.

A példa kód egy klasszikus staging modellt mutat be. A CTE (Common Table Expression) struktúra két lépésre van osztva: először a source() függvénnyel olvassuk be a nyers adatokat (a source definíciót a következő szekcióban részletezzük), majd egy renamed CTE-ben végezzük a tisztítást. Az order_date oszlopot timestamp-é konvertáljuk és átnevezzük ordered_at-ra, a total_amount-ot amount-ra egyszerűsítjük, és létrehozunk egy is_cancelled boolean mezőt a status alapján. A where feltétel kiszűri a null státuszú sorokat.

Miért fontos, hogy a staging réteg „buta" legyen? Mert ha a nyers adatok strukturálása és az üzleti logika összekeveredik, akkor bármelyik réteg változása megbonthatja a másikat. A staging legyen egy megbízható, stabil alap, amelyre az intermediate és mart modellek épülhetnek. Ideális esetben egy staging modell módosítása ritka — a változások az üzleti logikát érintik, ami a magasabb rétegekben történik.

Tip: Használd konzisztensen a CTE struktúrát minden staging modellben (source, renamed, filtered). A konvenció követése miatt a csapattagok azonnal tudják, hol keresgéljenek. Kerüld a join-ok és aggregációkat a staging rétegben — azok az intermediate vagy mart szintre valók.

A source() és ref() függvények a dbt DAG (Directed Acyclic Graph) rendszerének alapkövei. A source() a külső forrástáblákra hivatkozik — azokra a nyers adatokra, amelyeket nem a dbt hoz létre, hanem egy külső ETL eszköz tölt be. A ref() pedig a projektben lévő más dbt modellekre hivatkozik, automatikusan felépítve a függőségi láncot. Amikor egy modell ref('stg_orders') hivatkozást tartalmaz, a dbt tudja, hogy előbb a stg_orders modellt kell lefuttatnia.

A sources.yml fájl nemcsak a forrástáblák elérhetőségét definiálja, hanem a freshness (frissesség) ellenőrzést is. A loaded_at_field megadja, melyik oszlop alapján mérjük az adatok frissességét, a warn_after és error_after pedig a küszöbértékeket. Ha a raw_orders tábla utolsó betöltése 12 órával ezelőtt történt, a dbt warningot ad; ha 24 órával, akkor hibát. Ez kritikus monitoring eszköz éles rendszerekben.

A forrásdefiníció és a ref rendszer együtt teszi lehetővé a dbt docs generate parancs által generált lineage diagramot. A DAG vizualizációban láthatóvá válik, hogy melyik modell melyikből származik, hol vannak szűk keresztmetszetek, és mi történik, ha egy forrástábla nem frissül. Ez a transzparencia az egyik legnagyobb előny a hagyományos SQL scriptekkel szemben.

Tip: Mindig definiáld a forrásokat sources.yml-ben ahelyett, hogy közvetlenül táblaneveket használnál a modellben. Így a dbt tudja követni a források frissességét, és ha a forrástábla neve vagy sémája változik, csak egy helyen (a sources.yml-ben) kell módosítanod.

Az intermediate réteg a staging és a mart közötti híd: itt történik az adatok dúsítása join-okkal, az üzleti logika bevezetése és a komplex transzformációk. A Medallion architektúra Silver rétegének megfelelően az intermediate modellek már tisztított adatokkal dolgoznak (a staging-ből származókkal), és több forrásból vonják össze az információt. Ez az a szint, ahol a rendelések összekapcsolódnak az ügyfelekkel és termékekkel.

A példában az int_orders_enriched modell három staging modellt (stg_orders, stg_customers, stg_products) joinol össze. A ref() hivatkozások miatt a dbt automatikusan tudja, hogy előbb ezt a három modellt kell lefuttatnia. A where not o.is_cancelled feltétel kiszűri a visszamondott rendeléseket — ez már üzleti döntés, ami a staging-ben nem szerepelt. Az eredmény egy „széles" tábla, amely rendelésenként tartalmazza az ügyfél és termék adatait is.

Miért nem csináljuk ezt a mart rétegben? Mert az intermediate modell egy újrahasználható építőelem. Több mart modell is épülhet ugyanerre a dúsított adathalmazra: a havi bevételi riport éppúgy használja, mint az ügyfélszegmentációs modell. Ha a join-logika csak a mart-ban lenne, minden mart modellben duplikálva lenne, ami karbantartási rémálommá válna.

Tip: Ne légy mohó — ne hozz létre túl sok intermediate modellt. A jó Intermediate réteg a gyakran ismétlődő join-mintákat foglalja össze. Ha egy join csak egyetlen mart-ban használjuk, érdemes azt közvetlenül a mart modellbe tenni, külön intermediate fájl helyett.

A mart réteg az analytics architektúra csúcsa: itt találhatók a business-ready aggregációk, dimenziók és fact táblák, amelyeket az elemzők, BI eszközök és döntéshozók közvetlenül használnak. A Medallion architektúra Gold rétegének megfelelően ezek a modellek fizikai táblákként (materialized: table) jönnek létre, biztosítva a gyors lekérdezhetőséget. A mart modellek nevükben gyakran követik a dim_ (dimenzió) és fct_ (fact) előtag konvenciót.

A példa egy klasszikus fact táblát mutat be: fct_monthly_revenue, amely az int_orders_enriched intermediate modellből épül. A date_trunc havi szintre aggregál, a count distinct egyedi rendeléseket és ügyfeleket számol, a sum a teljes bevételt, az avg pedig az átlagos rendelési értéket. A group by 1, 2, 3 a pozíció alapján hivatkozik a select oszlopokra — ez SQL-ben egy átlátható rövidítés.

A mart modellek kulcsfontosságú szabálya: egy modell egy üzleti entitást vagy metrikát képvisel. A fct_monthly_revenue a bevételről szól, a dim_customers az ügyfelekről. Ne keverj össze több különböző granularitást egy modellben — ha a havi és napi aggregációkra is szükség van, hozz létre két külön modellt. A tiszta, egyértelmű granularitás biztosítja, hogy a BI eszközök helyesen tudjanak joinolni és szűrni.

Tip: Nevezd el a mart modelleket úgy, hogy az üzleti felhasználók is megértsék. A fct_monthly_revenue egyértelmű, de a fct_agg_01 nem mondd semmit. Az oszlopoknál is használj beszédes neveket (revenue, order_count), és dokumentáld őket a models YML fájlban.

A schema tesztek a dbt beépített adatminőségi ellenőrzései, amelyeket YAML fájlokban definiálunk. Négy alapvető teszttípus létezik: unique (az oszlop értékei egyediek), not_null (nincs hiányzó érték), accepted_values (az oszlop csak megadott értékeket vehet fel), és relationships (idegen kulcs integritás — az értéknek léteznie kell egy másik tábla megfelelő oszlopában). Ezek a tesztek SQL lekérdezésekké fordulnak, amelyek a hibás sorokat adják vissza — ha az eredményhalmaz üres, a teszt átment.

A példában az order_id oszlopra unique és not_null teszteket futtatunk (biztosítva, hogy minden rendelésnek legyen egyedi azonosítója), a customer_id-ra not_null és relationships tesztet (ellenőrzi, hogy minden ügyfél ID létezik a stg_customers táblában), a status-ra pedig accepted_values (csak a négy megengedett státuszérték egyike lehet). Ez a teszt-kombináció gyakorlatilag biztosítja az adatok referenciális integritását és az üzleti szabályok betartását.

A schema tesztek futtatása a dbt test paranccsal történik, amely a dbt run után érdemes lefuttatni. CI/CD pipeline-ban mindkettőt automatizálni kell: ha bármelyik teszt elbukik, a deployment nem folytatódhat. A teszteredmények a dbt docs-ban is megjelennek, így az adatok felhasználói láthatják, milyen minőségi garanciák vannak az adatokra nézve.

Tip: Definiálj teszteket minden kritikus oszlopra — legalább not_null az elsődleges kulcsokra és relationships az idegen kulcsokra. Ne várd meg, amíg egy üzleti felhasználó jelzi, hogy duplikált rendelésszámokat lát; a tesztek proaktívan védik az adatminőséget.

A custom tesztek olyan SQL lekérdezések, amelyeket a dbt beépített schema tesztek kiegészítésére írunk. Míg a schema tesztek általános adatintegritást vizsgálnak (unique, not_null), a custom tesztek üzleti specifikus szabályokat ellenőriznek. A teszt SQL fájlnak olyan lekérdezést kell tartalmaznia, amely a hibás sorokat adja vissza — ha a lekérdezés üres eredményt ad, a teszt sikeres.

A példa két custom tesztet mutat be. Az assert_positive_revenue teszt ellenőrzi, hogy nincs-e negatív összeget tartalmazó rendelés (az amount oszlop nem lehet kisebb nullánál). Az assert_recent_orders teszt pedig azt validálja, hogy az elmúlt 7 napban történt-e legalább egy rendelés — ez egy úgynevezett „volume anomaly" teszt, amely észleli, ha váratlanul megszakadt az adatbetöltés. Ezek olyan feltételek, amelyeket a beépített tesztek nem tudnak ellenőrizni.

A custom tesztek a tests/ könyvtárba kerülnek, és a dbt test paranccsal együtt futnak a schema tesztekkel. A teszt neve a fájl nevéből származik (assert_positive_revenue.sql leszz assert_positive_revenue teszt). A ref() függvénnyel hivatkozhatsz bármelyik modellre, így a tesztek a teljes DAG-ból származó adatokat is vizsgálhatják.

Tip: Írj custom tesztet minden kritikus üzleti szabályra — pl. „a szállítási dátum nem lehet korábbi, mint a rendelés dátuma" vagy „az engedmény nem lehet nagyobb, mint a rendelés összege". Ezek a tesztek az üzleti logika „élő dokumentációjaként" is szolgálnak.

Az incremental modellek a dbt teljesítményoptimalizálásának kulcsa: ahelyett, hogy minden futáskor az összes historikus adatot újra feldolgoznák, csak az új vagy módosított sorokat adják hozzá a már meglévő táblához. Ez különösen fontos nagy adatmennyiség esetén — ha millió soros rendeléstörténetünk van, felesleges minden nap újra feldolgozni az összes múltbeli rendelést, amikor csak a napi újak érkeztek.

A példában a config(materialized='incremental', unique_key='order_id') beállítás mondja meg a dbt-nek, hogy ez egy incremental modell, és az order_id alapján azonosítja az egyedi sorokat. Az is_incremental() Jinja függvény feltételes logikát biztosít: az első futáskor (amikor még nincs tábla) az összes adatot betölti, a későbbi futásokon pedig csak azokat, amelyek ordered_at értéke nagyobb, mint a táblában lévő maximum. A {{ this }} a jelenlegi modell táblanév-referenciáját helyettesíti.

A unique_key kritikus fontosságú: ha ugyanaz az order_id ismét megjelenik a forrásban (pl. frissített státusz), a dbt az insert helyett update műveletet hajt végre. Ez biztosítja az idempotenciát — bármennyiszer is futtatjuk a modellt, az eredmény mindig konzisztens. A merge stratégia (ami a háttérben történik) a forrásadatokat a cél táblával összehasonlítja, és csak a különbségeket alkalmazza.

Tip: Mindig adj meg unique_key-t incremental modellekhez! Enélkül a dbt nem tudja, mely sorokat kell frissíteni, és duplikációk keletkezhetnek. Ha nincs természetes egyedi kulcsod, generálj egyet surrogate key-ből (lásd a Macros szekciót).

A snapshot-ok a dbt SCD Type 2 (Slowly Changing Dimension) implementációi: automatikusan nyomon követik, hogyan változnak az adatok az idő múlásával. Amikor egy rendelés státusza „pending"-ről „shipped"-re változik, a snapshot nem csak felülírja az értéket, hanem megtartja a régit is, egy érvényességi időablakkal (valid_from, valid_to) ellátva. Ez lehetővé teszi, hogy bármely időpontra visszaállítsuk az adatok állapotát — „milyen volt a rendelés státusza múlt kedden?"

A példában a timestamp stratégia alapján működik a snapshot: az updated_at oszlop változását figyeli. Ha egy sor updated_at értéke megváltozik, a dbt a régi sort lezárja (valid_to beállítása) és egy új sort beszúr az új értékekkel. A target_schema='snapshots' külön sémába helyezi a históriai táblákat, elkülönítve őket az aktuális adatoktól. A unique_key biztosítja, hogy a megfelelő sor frissüljön.

A snapshot-ok különböznek az incremental modellektől: míg az incremental csak az új adatokat adja hozzá, a snapshot a meglévő sorok változásait is követi. Ezért a snapshotokat tipikusan dimenzió táblákon (ügyfelek, termékek, rendelések) használjuk, ahol a változások történetének megőrzése üzleti igény. Fact táblákon (tranzakciók, események) ritkábban van szükség rá.

Tip: Futtasd a snapshot-okat rendszeresen (pl. naponta), és ne felejtsd el, hogy a snapshot futtatás az addigi adatbázis-állapottól függ — ha kihagyol egy futtatást, a változások nem kerülnek rögzítésre. Automatizáld a dbt snapshot parancsot a CI/CD pipeline-ban vagy egy scheduler-ben.

A macro-k a dbt Jinja templating rendszerének legfontosabb elemei: újrahasználható SQL kódblokkok, amelyeket több modellben is meghívhatsz. A macro-k hasonlóak a függvényekhez a programozásban — definiálsz egy logikát egyszer, és aztán bárhonnan hivatkozhatsz rá. Ez kiküszöböli a kódduplikációt és biztosítja, hogy ha egy logikát módosítani kell, azt csak egy helyen kell megtenni.

A példa két gyakori macro-t mutat be. A cast_timestamp egy egyszerű típuskonverziós segédfüggvény, amely egy oszlopnevet vesz át és timestamp-é konvertálja. A generate_surrogate_key egy összetettebb macro: egy oszlopnév-listát vesz át, azokat egy separator-sal összekapcsolja, majd MD5 hash-t számít belőle. Ez egy gyakori minta a data warehouse-ban, ahol a természetes kulcsokból (pl. customer_id + product_id) mesterséges egyedi kulcsot generálunk.

A macro-k használatával a modellben csak ennyit kell írni: select generate_surrogate_key(['customer_id', 'product_id']) as order_sk — a dbt a futtatás előtt kifejti a Jinja sablont valódi SQL-lé. A macro-k paramétereket is fogadhatnak, tartalmazhatnak feltételes logikát (if/else), ciklusokat (for), és hivatkozhatnak más macro-kra is. Ez rendkívül rugalmas kód-újrahasznosítást tesz lehetővé.

Tip: Hozz létre egy macros/ mappán belül egy utils/ alkönyvtárat az általános segédfüggvényeknek (surrogate key, date formatting), és külön fájlokat az üzleti specifikus macro-knak. Ne használj macro-t olyan egyszerű logikára, amit egy sor SQL is megold — a macro-k a valóban ismétlődő mintákhoz valók.

A dokumentáció a dbt egyik legerősebb beépített funkciója. A models YML fájlokban leírt description mezőkből, oszlopleírásokból és a modell-kódból a dbt automatikusan generál egy interaktív weboldalt, amely tartalmazza a modellek leírását, a DAG lineage diagramot, az oszlopok dokumentációját és a teszteredményeket is. A dbt docs generate parancs létrehozza a dokumentációs fájlokat, a dbt docs serve pedig egy lokális weboldalon teszi elérhetővé.

A példában a fct_monthly_revenue modellhez írunk leírást: a month oszlop dokumentálja, hogy a hónap első napjára van csonkolva (date_trunc), a revenue pedig megjegyzi, hogy a visszamondott rendeléseket kizárja. Ezek a leírások a generált dokumentációban mindenki számára láthatóvá válnak — a data engineer-ek, az analitikusok és az üzleti felhasználók számára egyaránt.

A dokumentáció nem „utólagos kötelező" — hanem a fejlesztési folyamat szerves része. Amikor egy új modellt hozol létre, azonnal írd le, mit csinál és miért. Ha egy kolléga hetek múlva meg akarja érteni a modellt, a dokumentáció (és a kód) elég kell legyen — nem kellene elolvasnia egy régi Slack beszélgetést. A jó dokumentáció csökkenti a tudás-szigeteket és javítja a csapat termelékenységét.

Tip: Használd a dbt docs-ot a „knowledge base" építéséhez. A lineage diagram gyakran a leghasznosabb rész — az üzleti felhasználók vizuálisan látják, honnan származnak az adataik, és melyik modellre támaszkodhatnak. Ha a dokumentációt CI/CD-ben automatikusan generálod, mindig naprakész marad.

A tags és meta mezők a dbt modellek szervezésének és kezelésének eszközei. A tags egyszerű címkék, amelyekkel csoportosíthatod a modelleket — például 'mart', 'revenue', 'daily'. A meta mező strukturált metaadatokat tárol: tulajdonost (owner), SLA-t, frissítési gyakoriságot (refresh_frequency), vagy bármilyen egyedi kulcs-érték párt. Ezek az információk a dbt docs-ban megjelennek, és a parancssorból is lekérdezhetők.

A példában a fct_monthly_revenue modell owner-je az 'analytics-team', az SLA 4 óra (ennyi időn belül frissülnie kell), és napi frissítésű. A tags segítségével a dbt run --select tag:mart paranccsal lefuttathatod az összes mart modellt anélkül, hogy mindegyiket név szerint listáznád. Hasonlóan, a meta alapján is szűrhetsz: dbt run --select 'config.meta.owner:analytics-team' lefutja az összes modellt, amely az analytics team-hez tartozik.

Ezek a funkciók nagyobb projektekben válnak igazán hasznossá. Ha 50+ modell van a projektedben, nem praktikus minden futtatáskor az összeset újraépíteni. A tags és meta segítségével szelektíven futtathatod csak a szükséges modelleket — például csak a napi frissítésűeket, vagy csak egy adott csapat modelljeit. Ez jelentős idő- és költségmegtakarítást eredményez, különösen felhő adatbázisoknál.

Tip: Definiálj egy konvenciót a tags és meta használatára a csapatban. Kötelező mezők: owner (ki felel a modellért), SLA (milyen gyakran kell frissülnie), és refresh_frequency (napi, óránkénti, stb.). Ezek az információk nemcsak a futtatást segítik, hanem az üzemeltetési dokumentációt is gazdagítják.

Ez a szekció a teljes WebShop Pro analytics layer rendszerét foglalja össze. A projekt 8 modellt tartalmaz három rétegben: 3 staging modell (stg_orders, stg_products, stg_customers), amelyek a nyers adatokat tisztítják; 2 intermediate modell (int_orders_enriched, int_customer_segments), amelyek join-okkal dúsítják az adatokat; és 3 mart modell (fct_monthly_revenue, dim_customers, dim_products), amelyek az üzleti felhasználásra kész aggregációkat és dimenziókat szolgáltatják. Az egész rendszert 15 teszt védi (schema és custom tesztek együtt).

A dbt run parancs lefuttatja az összes modellt a megfelelő sorrendben — a DAG alapján a dbt automatikusan tudja, hogy a staging modelleket előbb kell lefuttatni, mint az intermediate-eket, és azokat előbb, mint a mart-okat. A dbt test ellenőrzi mind a 15 tesztet, a dbt docs generate pedig létrehozza a teljes dokumentációt, benne a lineage diagrammal. Ez a három parancs együttesen adja a dbt workflow gerincét.

Ez a projekt jó kiindulópont a valódi analytics projektekhez. A valóságban ehhez jönnek még: forrás-freshness monitoring, snapshot-ok a változáskövetésre, macro-k a kód-újrahasznosításra, és CI/CD automatizáció. A lépték is nagyobb lehet — egy valós e-kereskedelmi vállalatnál 50-200 modell is előfordulhat. De az alapelvek ugyanazok: réteges architektúra, tesztelés, dokumentáció, és automatizáció.

Tip: Használd ezt a projektet sablonként a saját munkádhóz. A struktúra (staging/intermediate/mart), a konvenciók (stg_, int_, fct_, dim_ prefixek), és a tesztelési megközelítés közvetlenül átemelhetők más projektekbe. Csak cseréld ki a forrásokat és az üzleti logikát a saját igényeidre.

Gratulálunk! Sikeresen felépítetted a WebShop Pro analytics layer-t — egy teljes, réteges adattranszformációs rendszert, amely a nyers adatoktól az üzleti döntéstámogatásig vezet. A kurzus során megismerted a dbt minden főbb funkcióját: a staging/intermediate/mart architektúrát, a schema és custom teszteket, az incremental modelleket, a snapshot-okat, a macro-kat, és a dokumentáció generálását.

A megtanult technikák közvetlenül alkalmazhatók a valódi munkában. A réteges modellstruktúra (Bronze/Silver/Gold) iparági standard, amelyet a legnagyobb technológiai vállalatok is használnak. A teszt-vezérelt adatfejlesztés (test-driven data development) biztosítja, hogy az adatok minősége ne romoljon a rendszer növekedésével. A dokumentáció és lineage pedig a csapatmunkát és a tudásmegosztást segíti.

A következő lépés a Databricks Lakehouse kurzus, ahol a dbt-ben tanult elveket egy managed felhői környezetben fogod alkalmazni. A Delta Live Tables, a Unity Catalog és az MLflow integrációkkal egy production-ready data platform-ot fogsz építeni. A dbt és a Databricks kiegészítik egymást — sok vállalat használja a kettőt együtt.

Tip: Gyakorolj! Hozz létre egy saját dbt projektet a saját adataiddal (akár egy nyilvános dataset-tel). Minél többet használod a dbt-t, annál természetesebbé válik a modellstruktúra, a tesztelés és a dokumentáció írása. A tapasztalat a legjobb tanár.