Szia, üdvözöllek a blogomon!

Amikor eljutunk a Gold rétegig, előbb-utóbb szembejön a kérdés: hogyan modellezzük az adatot? Klasszikus csillagséma (star schema), külön dimenziókkal és fact táblával? Vagy inkább egy széles, „lapos” tábla, ahol minden egy helyen van?

Elsőre a star schema tűnik a szakmailag „helyes” válasznak. Külön dimenziók (pl. termék, ügyfél, dátum), és egy fact tábla, amely a mért adatokat tartalmazza. Ez jól skálázható, tiszta logikájú, és BI eszközökben optimalizált működést ad. A dimenziók újrahasználhatók, a definíciók konzisztenssé válnak.

De nézzünk egy másik helyzetet. Egy kisebb csapat, kevés riport, viszonylag egyszerű adatszerkezet. Itt a csillagséma néha túltervezés. Egy jól strukturált, lapos tábla gyorsabb fejlesztést tesz lehetővé, és a riportkészítés is egyszerűbb lehet.

A lapos modell viszont könnyen redundanciát hoz be. Ha ugyanaz a dimenzió több fact jellegű adat mellett is ismétlődik, a változtatás nehezebb lesz. Ráadásul nagyobb adatmennyiségnél teljesítményproblémák jelenhetnek meg.

A star schema előnyei:
– tiszta üzleti entitások
– jobb újrahasznosíthatóság
– konzisztens KPI logika
– skálázhatóság

A lapos modell előnyei:
– gyorsabb indulás
– kevesebb join
– egyszerűbb mentális modell kisebb csapatnál

Fejlesztői szemmel a döntés gyakran teljesítmény- és karbantarthatósági kérdés. BA szemmel viszont az a fontos, hogy a modell mennyire támogatja az üzleti gondolkodást. Ha a felhasználó nem érti, mi a dimenzió és mi a fact, a „szép” modell is zavaró lehet.

Én azt tanultam, hogy nincs univerzális válasz. A modellnek a használati módhoz kell illeszkednie. Ha a rendszer növekedni fog, érdemes előre gondolkodni. Ha viszont gyors validáció a cél, nem biztos, hogy azonnal enterprise-szintű modellt kell építeni.

A 38. nap tanulsága számomra az, hogy az adatmodell nem esztétikai kérdés. Ez az a réteg, ahol a technikai struktúra és az üzleti értelmezhetőség találkozik.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Van egy pont, amikor egy adatplatform elkezd „szétesni”: amikor ugyanazt a logikát sokszor lemásoljuk, csak azért, mert gyorsabb, mint szépen megcsinálni. Itt jön képbe a paraméterezés – és meglepően sok rendszert pont ez emel át a hobbiszintből a fenntartható működésbe.

Képzelj el egy tipikus helyzetet. Be kell tölteni 10 hasonló forrást: országonként más fájl, de a struktúra szinte ugyanaz. A leggyorsabb megoldás: csinálunk 10 pipeline-t. Működik. Aztán változik a fájlnév, vagy jön egy új oszlop, és 10 helyen kell módosítani. Ilyenkor minden apró változás kockázat és rengeteg idő.

A paraméterezés lényege, hogy egy pipeline legyen, ami többféle helyzetben is használható. Például paraméterként megadod:
– forrás útvonal / fájlnév minta
– országkód vagy környezet (dev/test/prod)
– feldolgozandó dátum (batch date)
– target tábla neve
– „full reload” vagy „incremental” mód

Ezzel nem csak időt spórolsz, hanem csökkented a hibalehetőséget is. Ha egy változás jön, egy helyen javítod. Ráadásul az üzemeltetés is könnyebb: egy folyamatot figyelsz, nem tízet. A futások pedig összehasonlíthatóbbak lesznek, mert ugyanaz a logika fut különböző paraméterekkel.

A paraméterezésnél viszont van egy fontos határ: ne paraméterezd túl. Ha egy pipeline már 20 kapcsolótól függ, nehéz lesz átlátni, és a hibakeresés is bonyolultabb. Én szeretem azt a gondolkodást, hogy paraméterezünk mindent, ami valóban „változó”, de a fő logika marad stabil és egyszerű.

BA szemmel ez azért érdekes, mert a paraméterezés valójában szervezeti értéket ad: gyorsabban tudunk reagálni új igényekre, és kevesebb „kézi tűzoltás” kell. Fejlesztői szemmel pedig ez az egyik legjobb eszköz arra, hogy újrahasználható, skálázható megoldásokat építsünk.

A 37. nap tanulsága számomra az, hogy a paraméterezés nem extra finomítás. Ez az a lépés, amikor egy egyszeri megoldásból valódi platform-komponens lesz.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

A Fabricben (és úgy általában az adatplatformokon) az egyik leggyakoribb kérdés: Notebookban csináljuk, vagy Pipeline-ban? Elsőre ez olyan, mintha eszközök között választanánk. A valóságban viszont ez sokkal inkább működési döntés, ami hosszú távon meghatározza, mennyire lesz fenntartható a rendszer.

Képzelj el egy helyzetet: egy adatforrásból érkező fájlok néha hibásak, néha hiányosak, és van néhány üzleti szabály, amit rugalmasan kell kezelni. Notebookban gyorsan tudsz kísérletezni: betöltöd, megnézed a mintát, kipróbálsz egy tisztítást, ránézel a kimenetre. Ez a notebook igazi ereje: iteratív gondolkodás, gyors visszacsatolás.

Csakhogy jön a következő lépés: ezt a megoldást üzemeltetni kell. Minden hajnalban fusson le. Hibánál legyen jelzés. Újrafuttatáskor ne okozzon kárt. Legyen log, legyen futástörténet. Itt kezd el a pipeline „otthon lenni”, mert a pipeline egy folyamat-orientált keret: jobban látszik az adatút, könnyebb verziózni, és általában jobban illeszkedik az üzemeltetési gondolkodáshoz.

A döntés sokszor így hangzik fejben:
– Kísérletezem (notebook), vagy rendszert építek (pipeline)?
– Egyedi logika kell, vagy standardizált lépések?
– Ki fogja ezt 3 hónap múlva karbantartani: én, vagy egy másik csapat?

Fejlesztői oldalról is van egy tipikus csapda: notebookokkal nagyon könnyű „láthatatlan rendszert” építeni. Működik, de a logika elbújik kódcellákban, és ha nincs rendes struktúra, akkor a tudás egy ember fejében marad. Pipeline-nál a folyamat sokszor olvashatóbb – cserébe kevésbé rugalmas a kísérletezés.

BA szemmel pedig a legfontosabb kérdés: mikor válik egy ötlet üzleti szempontból kritikussá? Amíg kísérlet, addig a notebook tökéletes. De amikor már döntések épülnek rá, akkor stabilitást kell adni neki. Én ezért szeretem azt a megközelítést, hogy notebookban gyorsan validálok, majd a stabil logikát „átültetem” egy üzemeltethetőbb keretbe.

A 36. nap tanulsága számomra az, hogy a notebook vs pipeline esetén a jó választás az, ami a célhoz illeszkedik: kísérletezéshez notebook, stabil kontrollált folyamathoz pipeline.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Minél több adatot és riportot látok a valóságban, annál biztosabb vagyok benne, hogy az adatplatform-tervezés egyik legfontosabb kérdése nem technológiai, hanem döntési: teljesítményt akarunk, vagy rugalmasságot? És ami még fontosabb: mikor melyiket?

Képzelj el két helyzetet. Az egyikben a vezetői riport reggel 8-kor nyílik meg, és ha 10 másodpercnél tovább tölt, jön a panasz. Itt a gyorsaság üzleti elvárás, nem kényelmi extra. A másik helyzetben egy elemzői csapat új kérdéseket tesztel hetente, változnak a dimenziók, új számítások jelennek meg, és a legfontosabb a kísérletezés. Itt a rugalmasság érték, még akkor is, ha a riport nem „villámgyors”.

A gond ott kezdődik, amikor ugyanazzal a megoldással akarjuk kiszolgálni mindkét világot. Ha mindent a maximális teljesítményre optimalizálunk, akkor a változtatás drága és lassú lesz. Ha mindent rugalmasan hagyunk, akkor a végfelhasználói élmény és a stabilitás sérülhet.

A Fabricben számomra az a lényeg, hogy nem egyetlen út van, viszont a döntést nem spórolhatjuk meg. Tipikus kompromisszumok:
– előre számolunk és tárolunk (gyorsabb fogyasztás), vagy futásidőben számolunk (rugalmasabb)?
– közös, egységes réteget használunk (stabil), vagy csapatonként gyors megoldásokat engedünk (gyors indulás, nagyobb szórás)?
– a business logic hol éljen (definíciók egysége vs gyors iteráció)?

Elemzőként ebben az a tanulság, hogy a „mi a helyes megoldás?” kérdés helyett a „mi a helyes kompromisszum?” kérdést kell feltennem. És ezt csak úgy lehet, ha értem az üzleti prioritásokat: kinek fontos a gyorsaság, kinek fontos a kísérletezés, és hol kritikus a konzisztencia.

A 25. nap tanulsága számomra az, hogy a jó architektúra nem tökéletes, hanem tudatosan vállalt trade-offok sorozata és ettől lesz profi.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Az adatplatformok elején ritkán beszélünk költségről. Az első hetekben a fókusz inkább azon van, hogy „működjön”: legyen adat, legyen riport, legyen válasz a kérdésekre. Aztán a rendszer nő: több csapat, több adatforrás, több frissítés, több riport. És egyszer csak megjelenik a kérdés: mennyibe kerül mindez – és arányban van-e azzal, amit kapunk?

A Microsoft Fabric kapacitásalapú működésében számomra az a fontos, hogy az erőforrás-felhasználás egy ponton túl nem marad láthatatlan. A futó pipeline-ok, a számítások, a lekérdezések mind terhelést jelentenek. Ez önmagában nem baj. A baj akkor kezdődik, amikor a terhelés mögött nincs üzleti érték – csak megszokás, duplikáció vagy rossz döntések.

Képzelj el egy tipikus helyzetet: egy KPI-t több csapat is használ, de mindenki „csinál magának egy verziót”. Ugyanaz az adat három helyen van betöltve, ugyanaz a transzformáció háromszor fut le, és a riportok mégsem egyeznek mindig. Ilyenkor nem csak a bizalom sérül, hanem a költség is nő, és észrevétlenül fizetjük a rendszer széttöredezettségét.

A cost thinking nem azt jelenti, hogy „spóroljunk”. Inkább azt, hogy legyen tudatos:
– Hol történjen a számítás?
– Mit érdemes egyszer előállítani és újrahasználni?
– Mi az, amit tényleg minden frissítésnél újra kell számolni?
– Hol van duplikáció, és miért?

Elemzőként ez nekem egy új szint, mert eddig a helyes szám volt a cél, most viszont már az is, hogy fenntartható legyen az út, amin előáll. Ha egy riport csak úgy működik, hogy naponta kézzel ellenőrzünk mindent és közben felesleges futások mennek, az hosszú távon drága – akár pénzben, akár emberi energiában.

A 24. nap tanulsága számomra az, hogy a költség nem „pénzügyes téma”, hanem architektúra- és fegyelmi kérdés. A jó döntések nem csak stabilabb rendszert adnak, hanem hatékonyabbat is.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

A legtöbb adatplatform nem egyik napról a másikra omlik össze. A szétesés ritkán látványos, inkább lassú, apró jelekből áll össze.

Először csak egy plusz tábla kerül be „ideiglenesen”. Aztán egy számítás duplikálódik, mert gyorsabb így, mint egységesíteni. Később ugyanaz a KPI több helyen él, kissé eltérő definícióval. Technikailag minden működik, de a rendszer elkezd repedezni.

Képzelj el egy Fabric környezetet, ahol:
– nincs egységes névkonvenció
– nincs dokumentált definíció
– nincs világos rétegzés
– a változtatások közvetlenül élesben történnek.

Egy darabig ez nem tűnik problémának. A riportok jönnek, a számok látszólag rendben vannak. Aztán megjelennek az első kérdések: „Miért más nálam?” „Ez a szám honnan jön?” „Melyik verzió az aktuális?”

A szétesés első jele nem technikai hiba, hanem a bizalom csökkenése, a kérdések számának növekedése.

A Microsoft Fabric eszköztára lehetőséget ad a strukturáltságra: workspace-ek, jogosultságok, rétegzés, deployment. De ezek csak lehetőségek. Ha nem élünk velük tudatosan, a rendszer ugyanúgy fragmentálódhat, mint bármely más platformon.

Elemzőként fontos felismerni a korai jeleket. Amikor egyre több manuális ellenőrzés történik. Amikor egyre több párhuzamos riport jelenik meg. Amikor a számok körül több a vita, mint a döntés.

A 23. nap tanulsága számomra az, hogy az adatplatform stabilitása nem statikus állapot, hanem folyamatos karbantartást és tudatos döntéseket igényel.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Az adatplatformok fejlődése gyakran észrevétlenül történik. Először csak egy riport készül, aztán kettő, majd egyre több üzleti terület kezd el támaszkodni ugyanarra a rendszerre. Egy ponton viszont felmerül a kérdés: vajon elég-e egyetlen környezetben működni?

Sok kisebb szervezetnél minden egy helyen történik. Ugyanabban a workspace-ben fejlesztünk, tesztelünk és publikálunk. Gyors. Egyszerű. Kényelmes. Amíg nincs probléma.

Képzelj el egy konkrét helyzetet. Egy pipeline módosítás történik, mert optimalizálni szeretnénk a betöltési időt. A módosítás közvetlenül az éles környezetben történik. A következő frissítés után a riport számai eltérnek a megszokottól. Az üzlet azonnal reagál. A kérdés nem az, hogy a változtatás indokolt volt-e, hanem az, hogy miért nem látta senki előre a hatását.

A Dev–Test–Prod struktúra nem vállalati túlzás, hanem kontrollmechanizmus. A fejlesztői környezetben lehet kísérletezni. A teszt környezetben validálni lehet az üzleti logikát. Az éles környezet pedig stabil marad.

A Microsoft Fabric támogatja a deployment folyamatokat és a workspace-ek strukturált kezelését, de a több környezet használata nem automatikus, tudatos döntés szükséges hozzá.

Elemzőként számomra itt válik láthatóvá a rendszer érettsége. Nem attól lesz professzionális egy adatplatform, hogy hány komponense van, hanem attól, hogy a változtatás kontrolláltan történik-e.

A 22. nap tanulsága az, hogy a növekvő komplexitás növekvő fegyelmet igényel, illetve a több környezet nem lassítja a munkát, hanem hosszú távon biztonságot ad.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #Busin

Szia, üdvözöllek a blogomon!

Ahogy haladok előre a Microsoft Fabric világában, egyre inkább azt érzem, hogy a technológia mögött mindig szervezeti kérdések húzódnak meg. Az egyik legfontosabb ezek közül: ki a valódi adatgazda?

Elsőre könnyű rávágni, hogy az adat az üzleté. Vagy az IT-é. Vagy a riportkészítőé. De amikor konkrét helyzetbe kerülünk, a válasz már nem ennyire egyértelmű.

Képzelj el egy tipikus céges szituációt. Van egy KPI, amit minden terület használ: marketing kampányt optimalizál rá, pénzügy riportálja, operáció tervez vele. Egy idő után felmerül, hogy a számítás logikáját módosítani kellene. Ki dönt erről? Ki hagyja jóvá? Ki kommunikálja? És ha a változás miatt eltérnek a korábbi riportok, ki vállalja a felelősséget?

Ha nincs kijelölt adatgazda, akkor mindenki használja az adatot, de senki nem vállalja érte a végső felelősséget. Ilyenkor a vita nem a számról szól, hanem a hatáskörről.

A Fabric technikai értelemben támogatja a szerepkörök, workspace-ek és jogosultságok kezelését. De az eszköz nem fogja megmondani, hogy ki legyen a data owner. Ez szervezeti döntés.

Egy érettebb működésben legalább három külön szerepet érdemes tisztázni:
– Ki felel az adat forrásáért?
– Ki felel a definícióért?
– Ki felel a publikálásért és kommunikációért?

Ez a három szerep nem mindig ugyanaz a személy vagy csapat és ez így rendben is van.

Elemzőként számomra ez az a pont, ahol a technikai tudás már nem elég. Tudnom kell, kit kell bevonni, kivel kell egyeztetni, és kinek a döntése végleges. Az adatplatform nem csak adatút, hanem felelősségi térkép is.

A 21. nap tanulsága számomra az, hogy a stabil adatplatform nem ott kezdődik, hogy jól van-e felépítve a Lakehouse, hanem ott, hogy tiszták-e a felelősségi viszonyok.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Az elmúlt napokban külön-külön megnéztük az építőkockákat: OneLake, pipeline, rétegzés, semantic model. Ma viszont egy lépéssel hátrébb lépünk, és végigkövetünk egy teljes adatutat – forrástól egészen az üzleti döntésig.

Képzelj el egy webshopot. Beérkezik egy rendelés. Ez az esemény bekerül a forrásrendszerbe. Innen indul az adat útja.

Első lépésként a nyers adat (raw réteg) változatlanul betöltésre kerül. Itt még nem döntünk, nem tisztítunk, nem számolunk. Csak megőrizzük az eseményt úgy, ahogy történt. Ez azért fontos, mert ha később vita van, van mihez visszanyúlni.

A következő lépés a curated réteg. Itt már történik feldolgozás: kiszűrjük a tesztrendeléseket, egységesítjük a dátumformátumokat, összekapcsoljuk az ügyféladatokkal, kiszámoljuk az árrést. Itt jelenik meg az első üzleti logika.

Ezután jön a semantic model réteg. Itt dől el, mit nevezünk „bruttó profitnak”. Ide tartozik, hogy a szállítási költség beleszámít-e, hogyan kezeljük a visszárut, milyen árfolyamot használunk. Itt már nem technikai adatokról beszélünk, hanem definíciókról.

Végül a riport rétegben vizualizáljuk az eredményt. Az üzlet itt találkozik a számmal. Itt születik döntés: növeljük a marketingbüdzsét? Emeljük az árat? Leállítunk egy kampányt?

Ha a szám nem stimmel, hol keresünk hibát? A forrásrendszerben? A pipeline-ban? A transzformációban? A definícióban? Ha nem látjuk a teljes láncot, csak találgatunk.

Ez az „end-to-end” gondolkodás lényege. Nem egyetlen eszközről szól, hanem az összefüggésekről.

Számomra itt válik igazán érthetővé, mit jelent a Microsoft Fabric szemlélete. Nem attól erős, hogy sok komponenst tartalmaz, hanem attól, hogy lehetőséget ad az egész folyamat átlátására.

És amikor már nem csak riportot látunk, hanem adatutat, akkor kezdünk el valóban adatplatformban gondolkodni.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Az elmúlt napokban többször előkerült az adatút gondolata. Ma egy olyan témát hoztam, ami elsőre talán technikai részletnek tűnik, de valójában az egyik legfontosabb stabilitási tényező: az adatrétegzés.

Sok rendszer ott kezd el instabillá válni, hogy minden adat „egy helyen” él. A nyers forrásadat, az előkészített adat és a riportot kiszolgáló struktúra nincs elkülönítve. Elsőre ez gyorsabbnak tűnik. Kevesebb objektum, kevesebb táblanév, egyszerűbb struktúra. Aztán jön az első változtatás – és elkezd borulni a dominó.

Vegyünk egy konkrét példát. Egy webshop rendelési adatait betöltjük a rendszerbe. A nyers (raw) réteg célja az, hogy az adatot változatlan formában megőrizzük. Itt még nincsenek számítások, nincsenek szűrések. Ez az „igazság pillanatképe”.

A curated rétegben kezdődik az értelmezés. Itt tisztítjuk az adatot, kiszűrjük a tesztrendeléseket, egységesítjük a pénznemeket, összekapcsoljuk az ügyféladatokkal. Ez már üzleti logikát tartalmaz, de még nem riportoptimalizált.

A reporting rétegben történik az optimalizálás. Itt már a cél a gyors lekérdezhetőség és az egységes definíciók kiszolgálása. Nem kísérletezünk, hanem stabilan szolgáljuk ki a riportokat.

Mi történik, ha ez a három réteg összemosódik? Egy apró változtatás – például egy új szűrés – azonnal érinti a riportot. Nincs visszalépési pont. Nem tudjuk megmondani, mi volt az eredeti adat. A hibák láncreakcióként terjednek.

A Microsoft Fabric architektúrája lehetőséget ad a tudatos rétegzésre, de nem kényszeríti ki. A döntés a miénk és ez már nem technikai kérdés, hanem kockázatkezelési döntés.

Elemzőként számomra a rétegzés nem „szép architektúra”, hanem biztosíték arra, hogy ha változtatunk, kontrolláltan tesszük. Ha hibázunk, vissza tudjuk követni. Ha vitás a szám, meg tudjuk mutatni az útját.

A rétegzés nem luxus, hanem az adatbizalom egyik alapfeltétele.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan