Szia, üdvözöllek a blogomon!

Ha a Bronze réteg a bizalom alapja, akkor a Silver az a pont, ahol az adat használhatóvá válik. Itt történik az, amit sokan egyszerűen csak „transzformációnak” hívnak – de valójában ez az adatplatform egyik legkritikusabb része.

Képzelj el egy helyzetet. A forrásrendszerből érkező adatok technikailag rendben vannak, de üzletileg nem egységesek. Ugyanaz a státusz többféleképpen szerepel, dátumformátumok eltérnek, előfordulnak duplikált rekordok. A Bronze rétegben ez még nem probléma – ott az a cél, hogy hűen megőrizzük a forrást. A Silverben viszont már dönteni kell.

Az első kérdés: mit tekintünk „tiszta adatnak”?
Duplikáció esetén melyik rekord az érvényes? Az utolsó módosítás? A legfrissebb időbélyeg? Vagy a forrásrendszer státusza alapján döntünk?

Ez már nem pusztán technikai kérdés. Üzleti logika él a transzformációban.

A Silver rétegben gyakran jelenik meg az incremental load logika is. Nem töltünk be mindent újra minden nap, hanem csak a változásokat. Itt jön be az upsert (merge) szemlélet: ha létezik a rekord, frissítjük; ha nem, beszúrjuk. Ez hatékonyabb, de csak akkor működik jól, ha van stabil kulcsmezőnk és konzisztens változáskezelésünk.

Ha rosszul választjuk meg a kulcsot, vagy nem idempotens a pipeline, akkor egy hiba után a rendszer állapota torzulhat. Például egy újrafuttatás duplikációt okozhat. Az idempotencia azt jelenti: ugyanazt a futtatást többször végrehajtva is ugyanazt az eredményt kapjuk. Ez Silver szinten kritikus.

Egy másik fontos döntés a séma (schema) kezelése. Mi történik, ha a forrás új oszlopot küld? Automatikusan átengedjük? Megállítjuk a pipeline-t? Naplózzuk és jelzést küldünk? Ezek mind tervezési döntések.

Elemzőként számomra a Silver réteg az a hely, ahol az adat először válik üzleti értelemben konzisztenssé. Ha itt kompromisszumot kötünk, a Gold rétegben már csak „szépítgetni” tudunk.

A 32. nap tanulsága számomra az, hogy a Silver nem pusztán tisztítás. Ez az a réteg, ahol a technikai adatból üzletileg értelmezhető információ lesz – és itt dől el, mennyire stabil az alap.

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

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

Szia, üdvözöllek a blogomon!

Sokszor halljuk, hogy a Bronze réteg a „nyers adat”. De minél többet dolgozom adatplatformokon, annál inkább látom: a Bronze nem csak tároló. Döntés.

Képzelj el egy helyzetet. Van egy forrásrendszerünk, amely naponta egyszer exportál adatot. A legegyszerűbb megoldás: betöltjük a fájlt, felülírjuk az előző napi adatot, és kész. Gyors, tiszta, egyszerű.

De mi történik, ha a forrás hibás adatot küld? Mi történik, ha egy nap kimarad? Vagy ha később audit miatt vissza kell nézni egy konkrét nap állapotát?

Itt válik fontossá a Bronze valódi szerepe: a forrásadat változatlan, visszakövethető megőrzése.

Technikai értelemben ez gyakran append-only logikát jelent. Nem felülírunk, hanem hozzáfűzünk. Időbélyeggel. Verzióval. Így bármikor visszaállítható egy korábbi állapot.

És itt jön az első komoly döntés:
– Teljes snapshotot tárolunk minden nap?
– Csak változásokat (delta)?
– Mennyi ideig őrizzük meg a történetet?

Ha túl rövid ideig tárolunk, elveszítjük a visszakövethetőséget.
Ha mindent korlátlanul tárolunk, nő a költség és a komplexitás.

A Bronze réteg tehát nem „csak betöltés”. Hanem adatmegőrzési stratégia.

Elemzőként ez azért fontos, mert amikor egy szám megkérdőjeleződik, gyakran a forrásig kell visszamenni. Ha ott nincs strukturált, verziózott adat, akkor a vita megoldhatatlan.

A 31. nap tanulsága számomra az, hogy a Bronze réteg a bizalom alapja. Ha itt kompromisszumot kötünk, az később fájni fog.

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

Szia, üdvözöllek a blogomon!

Egy adatplatform egyik legnagyobb dilemmája: hol helyezzük el az üzleti logikát?

A forrásrendszerben?
A transzformáció során?
A semantic model rétegben?
Vagy a riportban?

Vegyünk egy példát. A „nettó árbevétel” számításába bizonyos kedvezmények beleszámítanak, mások nem. Ha ezt a logikát a riportban implementáljuk, minden riportban újra kell írni. Ha a semantic modelben, egységes lesz. Ha túl korán, a raw rétegben döntünk, elveszítjük a rugalmasságot.

Itt nem technikai kérdésről van szó, hanem architektúra döntésről.

A Fabric lehetőséget ad több réteg használatára. A kérdés az, hogy tudatosan használjuk-e őket.

Elemzőként ez az a pont, ahol valódi értéket tudunk hozzáadni. Nem csak számolunk, hanem döntünk a számítás helyéről.

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 szervezetben a monitoring addig nem téma, amíg minden működik. Aztán jön egy hiba, és mindenki a riportot hibáztatja.

Pedig a kérdés nem az, hogy van-e riport. Hanem az, hogy látjuk-e, mi történik a háttérben.

Egy pipeline futás sikeres volt? Mennyi ideig tartott? Volt-e figyelmeztetés? Elcsúszott-e az ütemezés?

Monitoring nélkül az adatplatform vakrepülés.

A Fabric egyik erőssége, hogy a futások, pipeline lépések, státuszok láthatók. De a láthatóság nem egyenlő a tudatossággal. Ha senki nem nézi, nem értelmezi, nem reagál rá, akkor csak egy dashboard marad.

Elemzőként számomra a monitoring nem IT-feladat. Ez a rendszer egészségi állapotának figyelése. És ha komolyan vesszük az adatvezérelt döntést, akkor a rendszer működését is komolyan kell venni.

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 egyik legkevésbé látványos, mégis legkritikusabb kérdése a verziózás. Nem az, hogy elmentjük-e a fájlt, hanem hogy tudjuk-e, mi változott, mikor és miért.

Képzelj el egy helyzetet: egy KPI számítás módosul. Valaki finomít a logikán, mert „így pontosabb”. A riport frissül, a számok változnak. Az üzlet észreveszi, de senki nem kommunikálta a változást. A bizalom meginog.

A probléma nem technikai. A probléma a kontroll hiánya.

Egy érett rendszerben a változás:
– dokumentált
– visszakövethető
– indokolt
– és kommunikált

A Fabric környezetben a workspace-ek, a deployment logika és az objektumstruktúra lehetővé teszi, hogy a változások ne „észrevétlenül” történjenek. De a technológia önmagában nem oldja meg a fegyelmet.

Elemzőként itt jön be a felelősség. Nem elég, hogy működik a számítás. Azt is tudni kell, mikor és miért változott.

A verziózás nem adminisztratív teher, hanem bizalmi mechanizmus.

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 egyik legkevésbé látványos, mégis legkritikusabb része a jogosultsági rendszer. Erről ritkán beszélünk, mert nem „szexi” téma. Pedig itt dől el, hogy egy rendszer hosszú távon fenntartható-e.

Képzelj el egy helyzetet, ahol mindenki mindenhez hozzáfér. Elsőre kényelmesnek tűnik. Gyors. Nincs akadály. De idővel elmosódik a felelősség. Ki módosította az adatot? Ki törölte a táblát? Ki változtatta meg a definíciót?

A másik véglet az, amikor túl szigorú a rendszer, és minden apró változtatáshoz IT-jegy szükséges. Itt a rugalmasság sérül.

A Fabric egyik fontos erőssége, hogy a workspace és a szerepkörök révén strukturált jogosultsági modellt kínál. Ez nem csak biztonsági kérdés. Ez felelősségi modell.

Elemzőként ez azt jelenti, hogy nem csak adatot használok, hanem rendszerben gondolkodom. Tudnom kell, ki fér hozzá, ki módosíthat, ki publikálhat.

A jogosultság nem adminisztrációs részlet, hanem az adatbizalom alapja.

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

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

Szia, üdvözöllek a blogomon!

Ha meg kellene neveznem azt a pontot, ahol a legtöbb riport „elromlik”, nem a storage-ot vagy a pipeline-t mondanám. Hanem a semantic model réteget.

Mi is történik itt valójában?

A semantic model az a réteg, ahol a technikai adat üzleti jelentést kap. Itt dől el, hogy mit jelent pontosan az „árbevétel”, hogyan számoljuk a „bruttó profitot”, mit értünk „aktív ügyfél” alatt.

Most nézzünk egy valós helyzetet. Az értékesítési riportban az „új ügyfelek száma” KPI szerepel. Az egyik csapat az első vásárlást tekinti új ügyfélnek. A másik a regisztráció dátumát. Technikai szinten mindkettő helyes lehet. Üzleti szinten viszont teljesen más eredményt ad.

Ha nincs egységes semantic model, a riportok látszólag működnek, de az üzleti döntések alapja instabil.

A Fabricben a semantic model nem csupán technikai objektum. Ez az a hely, ahol egységes definíciók születnek. Ha itt nincs rend, a legjobb architektúra sem ment meg minket.

Elemzőként számomra ez a legnagyobb felelősségi pont. Nem a vizualizáció, hanem a definíció.

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

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

Szia, üdvözöllek a blogomon!

Amikor először megláttam, hogy a Microsoft Fabricben notebookokat is használhatunk, felmerült bennem a kérdés: miért van szükség Pythonra egy olyan környezetben, ahol SQL és riportolás is elérhető?

Kezdőként könnyű azt gondolni, hogy a notebook csak az adattudósok játszótere. De a valóságban ennél árnyaltabb a kép.

Képzelj el egy olyan helyzetet, ahol egy marketing kampány hatékonyságát szeretnénk elemezni. Több forrásból érkeznek az adatok: webanalitika, CRM, hirdetési platformok. Az adatok struktúrája eltérő, időbélyegek nem teljesen egyeznek, és szükség van egyedi logikára a tisztításhoz és összekapcsoláshoz.

SQL-ben ez megoldható, de egy ponton túl nehézkessé válik. A notebook itt rugalmasságot ad: komplexebb adatmanipuláció, iteratív gondolkodás, vizuális ellenőrzés, gyors kísérletezés.

Fontos azonban látni, hogy a notebook nem az „alapértelmezett” megoldás. Ha minden problémát notebookkal oldunk meg, könnyen átláthatatlanná válik a rendszer. A notebook erőssége a kísérletezés és a speciális logika, nem a standardizált riportkiszolgálás.

Elemzőként ez azt jelenti, hogy nem az a kérdés, tudok-e Pythonban írni, hanem az, hogy felismerem-e, mikor indokolt a használata. Ez már nem technikai tudás kérdése, hanem döntési érettségé.

A Fabric ebben nem kényszerít. Lehetővé teszi, de nem teszi kötelezővé. És ez egy fontos különbség.

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

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