Szia, üdvözöllek a blogomon!

Az egyik leggyakoribb kérdés, amit látok: Lakehouse vagy Warehouse? De a való életben ez ritkán elméleti vita. Inkább döntési helyzet.

Képzelj el egy szervezetet, ahol folyamatosan új adatforrások érkeznek. Marketing, CRM, webshop, kampányadatok. Sok a változó, sok a kísérletezés. Ilyenkor a rugalmasság kulcsfontosságú. A Lakehouse ilyen környezetben jól működik, mert nem zárja be túl korán a struktúrát.

Most nézzünk egy másik helyzetet. Egy stabil, jól definiált pénzügyi riporting rendszer, havi zárásokkal, audit elvárásokkal. Itt a strukturáltság, a kiszámíthatóság és az egységes definíció fontosabb, mint a rugalmasság. Itt a Warehouse lehet a jobb döntés.

A kérdés tehát nem az, hogy melyik a modernebb. Hanem az, hogy mire van szükség.

A Fabric egyik erőssége szerintem pont az, hogy nem kényszerít egyetlen útra. De felelősséget ad a döntésben. Elemzőként ez azt jelenti, hogy nem csak számokat nézek, hanem rendszert tervezek fejben.

És talán itt kezdődik az igazi szakmai szintlépés.

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 hallottam a „pipeline” szót, az jutott eszembe: adat A-ból adat B-be. Kész. Technikai részlet. De egy céges környezetben a pipeline sokkal több ennél.

Vegyünk egy gyakorlati példát. Van egy napi frissülésű értékesítési riport. Egy reggel az üzlet azt látja, hogy a számok nem változtak. A riport „rossz”. De valójában mi történt? Lehet, hogy a forrásrendszer nem adott adatot. Lehet, hogy a betöltés hibára futott. Lehet, hogy a transzformációs lépés nem zárult le.

A pipeline nem csupán adatmozgatás. A pipeline egy folyamat, ami meghatározza:
– mikor frissül az adat,
– milyen lépésekben,
– mi számít sikeres futásnak,
– és mi történik hiba esetén.

Ha ezek nincsenek átláthatóan kezelve, az üzlet csak annyit lát: „nem jó a riport”. A háttérben viszont folyamatprobléma van.

A Fabric pipeline szemlélete számomra azért érdekes, mert nem csak adatot mozgat, hanem folyamatot strukturál. Láthatóvá teszi a lépéseket. És ez megint csak a bizalomról szól.

Ha értem az adat útját, nem csak a végeredményt látom. És ez elemzőként óriási különbség.

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

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

Szia, üdvözöllek a blogomon!

Az első napokban sokat beszéltünk arról, hogy a Microsoft Fabric egy keretrendszer, ami rendet próbál tenni az adat körül. Most viszont nézzük meg az egyik legfontosabb alapját: a OneLake-et, de nem elméletben, hanem egy tipikus céges helyzeten keresztül.

Képzelj el egy szervezetet, ahol több csapat dolgozik ugyanazzal az adattal. A pénzügy készít egy riportot, az értékesítés egy másikat, az operáció egy harmadikat. Mindenki ugyanarra az adatforrásra hivatkozik, mégis eltérő számok jönnek ki. Mi történik ilyenkor? Elkezdődik a „számháború”. Nem az üzleti döntésről beszélünk, hanem arról, hogy melyik Excel a helyes.

A OneLake mögötti gondolat az, hogy legyen egy közös, egységes adattárolási alap. Ne legyen öt külön adatmásolat, ne kelljen manuálisan másolgatni, ne éljen párhuzamos valóság ugyanarról a KPI-ról. Egy adat – több felhasználás.

Ez nem azt jelenti, hogy nem lehet hibázni. Azt jelenti, hogy a hiba lokalizálható. Tudjuk, hol keletkezett. Tudjuk, ki felel érte. És ez már hatalmas előrelépés.

Elemzőként számomra ez a legfontosabb: a bizalom. Ha nincs közös alap, nincs közös valóság sem. A OneLake nem csak technikai megoldás, hanem szervezeti fegyelem.

És talán ez az a pont, ahol a Fabric igazán több lesz, mint egy új platform.

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

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

Szia, üdvözöllek a blogomon!

A következő lépés elkerülhetetlen. Meg kell érteni, miből áll ez a rendszer. Nem technikai leírásként, hanem úgy, hogy dönteni tudjak, amikor majd választani kell.

Mit jelent az, hogy „építőkocka” a Microsoft Fabricben?

Amikor a Microsoft Fabric elemeiről beszélünk, könnyű elveszni a fogalmakban:

• Lakehouse
• Warehouse
• Notebook
• Pipeline
• Semantic model

De számomra az igazi felismerés az volt, hogy ezek nem önálló eszközök, hanem funkcionális építőkockák, amelyek együtt alkotnak egy adatutat. Nem az a kérdés, hogy mit tudnak, hanem hogy milyen szerepet töltenek be a rendszerben.

Lakehouse – a szabadság és a rend közötti kompromisszum

A Lakehouse elsőre marketinges fogalomnak hangzik, de mögötte egy nagyon is valós probléma áll:

• a data lake túl rugalmas → könnyen kaotikus
• a data warehouse túl kötött → nehéz vele kísérletezni

A Lakehouse erre próbál válasz lenni. Elemzői szemmel ez azért fontos, mert nem zárja el túl korán az adatot, teret ad a felfedezésnek, de mégis keretet biztosít. Nem tökéletes megoldás, de nagyon jó irány, ha az elemzés és a tanulás fontos.

Warehouse – stabilitás érett problémákra

A Warehouse sokszor „régi iskolás” címkét kap, pedig strukturált, üzleti logikára épül, kiszámítható, jól skálázható. Ez nem hátrány. Ez biztonság.

Ha az adatok már tiszták, ritkán változik a struktúra, és sok felhasználó dolgozik rajtuk, akkor a Warehouse nem korlát, hanem megbízható alap.

Lakehouse vs Warehouse

Nagyon gyakran így merül fel a kérdés: „Melyik a jobb?”

Pedig a valós kérdés inkább ez: „Melyik illik jobban az adott helyzethez?”

• Lakehouse → rugalmasság, felfedezés, elemzés
• Warehouse → stabilitás, egységes logika, riportolás

Nem egymás ellenfelei, hanem inkább különböző problémákra adott válaszok.

Miért fontos ez elemzőként?

Mert itt történik meg a váltás: nem csak adatot elemzünk, hanem rendszerben gondolkodunk. Ez már nem technológiai döntés. Ez üzleti, szervezeti és elemzői döntés egyszerre.

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

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

Szia, üdvözöllek a blogomon!

Őszintén szólva, elsőre a workspace-t fejben így címkéztem fel: „Oké, ez az a hely, ahová dolgokat pakolunk.” Ez részben igaz is, de csak nagyon leegyszerűsítve.

A workspace nem elsősorban technikai egység, hanem szervezési és felelősségi határ. Azt mondja meg, hogy kik dolgoznak együtt, min, és milyen céllal. Nem az a kérdés, hogy „mit teszünk ide?”, hanem az, hogy „kik és miért dolgoznak itt?”

A legtöbb adatkáosz ott indul, hogy minden mindennel egy helyen van, mindenki mindent lát, és senki nem érzi igazán a felelősséget. A workspace leválaszt, keretez, és megmutat dolgokat helyettünk.

Elemzői szemmel ez mit jelent?

Azt, hogy nem csak adatot látok, hanem kontextust, és értem, hogy egy riport hol él a rendszerben. Ez már nem „Power BI logika”, hanem adatplatform gondolkodás.

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

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

Szia, üdvözöllek a blogomon!

Egy kifejezés, amit mindenhol látok: „end-to-end analytics” Szinte minden Fabric anyagban ott van, de sokáig őszintén szólva nem volt kézzelfogható, mit is jelent ez a gyakorlatban. Ma próbáltam ezt magamnak lefordítani.

Mit jelent számomra most?

Az „end-to-end” nekem ma ezt jelenti: végig tudom követni az adat útját, a forrástól egészen addig, amit a riportban látok és közben tudom, hol történt transzformáció, ki a felelős érte, mi az üzleti jelentése. Nem fekete doboz, hanem egy értelmezhető lánc.

Miért ennyire fontos ez?

Mert a legtöbb adatprobléma nem a végén derül ki, hanem valahol útközben keletkezik. Ha csak a riportot látom, tünetet kezelek. Ha látom az egész utat, akkor megértem az okot és ez óriási különbség.

Hol jön ebbe képbe a Fabric?

A Fabric pont ezt próbálja támogatni: közös alap, egységes gondolkodás, átlátható adatút. Nem azt mondja, hogy nem lehet hibázni, hanem azt, hogy lásd, hol történt.

Tehát az „end-to-end analytics” nem technológia, hanem láthatóság és felelősség. És ha ez megvan, a technikai döntések is könnyebbé válnak.

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

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

Szia, üdvözöllek a blogomon!

A kérdés, amit ma már nem tudtam kikerülni, miután ismét végigültem egy másfél órás sessiont, pipeline-okat fürkészve :-)

Ahogy haladok előre, egyre erősebben érzem a Microsoft Fabric nem mindenkinek szól. És ezt nem kritikaként mondom. Sőt!

Kinek NEM szól a Fabric?

Kezdjük ezzel, mert ritkán lehet olvasni erről... Nem ideális választás, ha csak néhány egyszerű riportod van, ha egy ember dolgozik az adatokkal, ha nincs valódi adatút (csak Excel → Power BI), ha gyors, ad-hoc megoldásokat keresel, és ha nincs igény hosszú távú skálázásra. Ilyenkor a Fabric túl sok, túl komplex, és nem ad arányos értéket. Ez teljesen rendben van.

Akkor kinek szól igazán?

A mai tudásom szerint a Fabric akkor válik érdekessé, ha:

• több adatforrásod van

• több szereplő dolgozik az adaton

• fontos, hogy ki mit csinál és miért

• nem csak riportot akarsz, hanem adat­rendszert

• előbb-utóbb governance, jogosultság, üzemeltetés is számít

Ez már nem egyéni elemzői játszótér. Ez szervezeti szint.

Hol van ebben az elemző / BA szerepe?

Ez az a pont, ami engem igazán megfogott. A Fabric nem csak IT-eszköz, de nem is „business toy”. Pont ott van, ahol az elemző kérdez, összeköt, értelmez, és segít dönteni. Nem a gombok ismerete a kulcs, hanem az, hogy értsük az összefüggéseket.

A mai nap tanulsága, hogy a Microsoft Fabric nem „mindenkinek kell”, de akinek kell, annak nagyon.

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

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

Szia, üdvözöllek a blogomon!

A kérdés, amit ma feltettem magamnak: Ha már volt Azure Synapse, akkor miért nem azt fejlesztették tovább? Miért kellett egy új név, egy új platform, egy új koncepció?

Az első benyomás

Az Azure Synapse Analytics számomra mindig nagyon erős, nagyon rugalmas, de nagyon döntésigényes volt. Sok mindent lehetett vele csinálni. Cserébe sok mindent neked kellett kitalálni. A Fabric első benyomásra kevesebb döntést kér, kevesebb infrastruktúra-kérdést dob fel, viszont határozottabb véleménye van arról, hogyan „illik” adatplatformot építeni.

Miért fontos ez?

Mert a legtöbb szervezet nem adatplatform-specialistákból áll, hanem üzleti elemzőkből, riportkészítőkből, BA-kból. És nekik nem még több opcióra van szükségük, hanem kevesebb rossz döntési lehetőségre.

Szerintem attól függ, hol tart a szervezet. A Fabric nem azért jött létre, mert a Synapse „rossz”!

Ha szeretnél többet tudni a Synapseról, írj egy igent kommentbe!

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

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

Szia, üdvözöllek a blogomon!

Miért kell erről külön beszélni?

Az egyik leggyakoribb reakció, amikor szóba kerül a Fabric: „Dehát mi eddig is Power BI-t használtunk…”

A félreértés ott kezdődik, amikor a Microsoft Fabric és a Power BI egymás alternatívájaként jelenik meg a fejekben. Pedig nem azok.

Mit csinál a Power BI valójában?

A Power BI középpontjában az adatmodell (semantic model), a vizualizáció, a dashboard, a riportfogyasztás áll. A Power BI a történet vége, ahol az adat értelmet nyer és ez önmagában sok esetben bőven elég.

És mit csinál ehhez képest a Fabric?

A Fabric nem a riportot akarja jobbá tenni, hanem azt akarja láthatóvá tenni, hogy honnan jön az adat, hogyan alakul át, hol történnek a döntések, ki miért felel.

A Power BI benne van a Fabricben, de a Fabric nem a Power BI kibővítése. Ez egy fontos váltás.

Mikor elég csak a Power BI?

Őszintén szólva, elég sokszor. Például, ha kevés adatforrásod van, egyszerű transzformációk kellenek, nincs komplex adatút, nincs több csapat az adaton, akkor a Power BI önmagában is tökéletes megoldás. És ez nem „lebutított” gondolkodás.

Mikor kezd el kevés lenni?

Akkor, amikor ezek a kérdések megjelennek:

• „Ez az adat pontosan honnan jön?”
• „Mi történik előtte?”
• „Ki változtatta meg?”
• „Miért mást lát ez a riport, mint a másik?”

Itt már nem riportproblémád van, hanem rendszerproblémád.

Tehát a mai nap tanulsága az, hogy a Power BI a megjelenítésről szól, a Fabric pedig a teljes adatút megértésé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 kérdés, ami tegnap óta motoszkál bennem: ha a Microsoftnak eddig is volt Power BI-ja, Azure Synapse-e, Data Factory-je, mindenféle adatplatformos megoldása…miért kellett még egy új?

Ez a poszt erről szól.

A kiinduló probléma

A legtöbb adatplatformos káosz nem abból fakad, hogy rossz technológiát használnak. Hanem abból, hogy túl sok eszköz van, túl sok döntési ponttal, túl sok „ezt most itt csináljuk” jellegű megoldással.

Az eredmény gyakran nehezen átlátható adatút, széttöredezett felelősségek, és az a mondat, amit minden elemző hallott már: „Ez a riport honnan jön pontosan?” :-)

Szerintem a Microsoft nem egy új eszközt akart létrehozni, hanem egyszerűsíteni akart egy túl komplex világot, így született meg a Microsoft Fabric gondolata.

Mit jelent ez a gyakorlatban?

A Fabric mögötti miért szerintem ezekre a kérdésekre válaszol:

• Mi lenne, ha az adat nem 5 helyen élne?

• Mi lenne, ha az elemző látná az adat útját, nem csak a végét?

• Mi lenne, ha kevesebb döntést kellene hozni infrastruktúráról?

• Mi lenne, ha a fókusz nem a technológián, hanem az adat értékén lenne?

Ha belegondolunk, ezek a problémák már 10–15 éve is léteztek. A különbség az, hogy ma már sokkal több adat van, sokkal több felhasználó dolgozik vele és az elemzés nem „nice to have” kategória, hanem alapelvárás. Nos, a Fabric erre egy rendrakási kísérlet :-)

Hol tartok most?

Ma először érzem azt, hogy igazából nem egy új toolt próbálok megérteni, hanem egy stratégiai irányt. Ez segít abban, hogy építőkockánként ismerjem meg a kísérlet szereplőit.

Ha része szeretnél lenni ennek a kísérletnek, nézz be holnap is.

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

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