# SchemaVortex

> A SchemaVortex egy data lakehouse platform: kinyeri az adatot az operatív adatbázisokból, verziózott adattörténetet vezet róla, és jogosultsághoz kötött SQL-view-kként szolgálja ki. Az ügyfél saját Azure-előfizetésén belül fut, nem olyan szolgáltatásként, amelyhez az adatot el kellene küldeni.

A platformot a budapesti Fizzcode Kft. szállítja. Böngészőből konfigurálható, nem pipeline-kód írásával, és az átadás után az ügyfél saját csapata üzemelteti: a szállítónak nem marad állandó hozzáférése az ügyfél tenantjához.

## Legfontosabb tények

- Tárolás: Apache Parquet-fájlok az ügyfél saját Azure Data Lake tárolójában. Ez a tár a Vault. Oszlopkészlete mindig csak bővül: a meglévő oszlopok soha nem módosulnak és nem tűnnek el. Ha egy forrás szerkezete megváltozik, egy munkatárs egyetlen módosítással frissíti a Vault táblát, és az új alak új, verziózott oszlopként tárolódik, így a riportok által már olvasott oszlopok nem változnak meg.
- Lekérdezési felület: Mart view-k, azaz az Azure Synapse Analytics serverless SQL view-jai a Vault fölött. Olvashatók Power BI-ból, Excelből, Tableau-ból, Qlikből, Pythonból vagy bármely SQL-kliensből. A serverless működés azt jelenti, hogy a számlázás lekérdezésenként történik, és nincs méretezendő cluster.
- Adattörténet: minden Vault tábla elérhető Latest táblaként, amely az aktuális állapotot tartja, és a mögötte álló History táblaként, amely az adott időpontra vonatkozó kérdéseket és az auditokat szolgálja ki. A verziók hozzáadódnak, nem írják felül egymást; azt, hogy az adattörténet meddig nyúlik vissza, az ügyfél kezében lévő megőrzési beállítás szabja meg.
- Megőrzés és adat-helyreállítás: az adattörténet csak a két végén változik, a kettő között az adat soha nem változik. A megőrzés törli a forrásonként beállított időnél régebbi töltéseket, ez alapértelmezés szerint 24 hónap. A másik végén egy hibás töltés után a forrás táblái visszaállíthatók egy korábbi időpontra. A platform az ügyfél tárolójában őrzött töltésmásolatokból építi újra őket, leállás nélkül és a forrás újraolvasása nélkül. A választott időpont utáni töltések véglegesen törlődnek, a teljes pillanatképként tárolt tábla pedig nem állítható vissza.
- Források: az SQL Server, a PostgreSQL, a MySQL, a MariaDB, az Oracle, az SAP HANA, az IBM i (DB2 for i, korábban AS/400) és az Infor Data Lake, valamint a rájuk épülő ERP-, CRM- és vállalati rendszerek közvetlenül kinyerhetők. A REST API-k és minden más forrás, amelyhez nincs beépített connector, a Producer SDK-n keresztül érkezik. Egy Origin regisztrálása után a platform magától feltérképezi a táblákat, az oszlopokat, a típusokat és a kulcsokat.
- Bring Your Own Data: Excel-, CSV- és Parquet-fájlok importálhatók táblaként, a Producer SDK (egy .NET-könyvtár) pedig bármely más rendszerből küld adatot. Az importált táblák ugyanazon a jóváhagyáson, maszkoláson és Vault-adattörténeten mennek át, mint az adatbázis-források.
- Governance: minden oszlop négy kapun halad át, ebben a sorrendben: AI kapu (oszlopok elrejtése az AI elől), Governance kapu (besorolások, amelyeket a Data Steward az adatokra tesz), Jóváhagyási kapu (a táblák és az oszlopok jóváhagyása) és Delivery kapu (második besoroláskészlet a Vault oszlopokon). A besorolás egy érzékeny adatfajtát jelöl, és az olvasónak egy oszlop minden besorolására jogosultnak kell lennie ahhoz, hogy az értékét olvashassa. Az AI kaput és a Governance kaput a Data Steward tartja, a Jóváhagyási kaput a Data Warden, aki mindazzal rendelkezik, amivel egy Data Steward, a Delivery kaput a Vault Manager. Minden AI-munkamenet NULL-t kap a besorolt és az AI elől elrejtett adatokból. A hozzáférés minden lekérdezés futásakor dől el: a lekérdezés azokat az értékeket adja vissza, amelyeket az olvasója olvashat, a többi helyén NULL-t vagy maszkolt értéket. Minden jóváhagyás, kapumódosítás és tagságváltozás auditált.
- Változáskezelés (négy szem elve): a Mart view-k, a Vault táblák és a Sandbox view-k javaslaton keresztül is változtathatók; a javaslat neve Mart terv, Vault tervezet vagy Sandbox tervezet. A platform a javaslatot az aktuális állapothoz képest ellenőrzi, majd a megfelelő jogosultságú személy a saját nevén élesíti vagy hagyja jóvá, és ezt az audit trail rögzíti. A felhasználók számára a javaslati folyamat opcionális: megfelelő jogosultságú személy közvetlenül is módosíthat Mart view-t vagy Vault táblát, és egy telepítésben előírható, hogy minden Mart változás Mart terven keresztül menjen. Az AI Assistant írhat javaslatot, de soha nem érvényesíthet.
- A Mart: a riportmodell SQL-view-kban, a Vault és más Mart view-k fölött, Mart adatbázisokba rendezve. A közvetlen változást a platform mentés előtt lefordítja a Synapse-on, a Mart tervet pedig élesítéskor egészében: ha egyetlen view nem fordul le, a teljes élesítés leáll, mielőtt bármi megváltozna. Minden változás a szerzőjével és az idejével együtt rögzül, és egy view korábbi változata, vagy az összes view egy választott pillanatbeli állapota Mart terven keresztül visszaállítható. Egy view vagy lekérdezéskor futtatja az SQL-jét, vagy Parquet-fájlként eltárolja az eredményét az ügyfél tárolójában, és ezt a platform újraépíti, amikor a mögötte álló adat megváltozik. Védett oszlopokból számolt view csak egy Data Warden jóváhagyása után tárolja el az eredményét. További Query endpointok ugyanazokat a view-kat szolgálják ki ugyanabból az adatból, így a nagy riportterhelés elkülöníthető.
- Sandbox: minden felhasználó kaphat egy személyes sémát SQL view-k számára a Vault és a Mart fölött. A Sandbox view-k élőben futnak, másolatot nem tárolnak, a lekérdezőnek csak azt adják vissza, amit olvashat, és Mart view soha nem olvassa őket. A kollégák Sandbox tervezetként javasolhatnak változtatást, amelyet a view tulajdonosa hagy jóvá.
- Lineage: view- és oszlopszintű, és a platform azokból a view-kból oldja fel, amelyek ténylegesen futnak, nem kézzel karbantartott dokumentációból. Visszafelé a forrásoszlopokig követ, előrefelé a hatáselemzést szolgálja.
- Katalógus: a platform része, átfogja a Vaultot és a Martot, SQL-szerkesztővel, valamint megjegyzésekkel és címkékkel a táblákon, a view-kon és a Vault oszlopain. Nincs mit a lake mellé telepíteni vagy ütemezetten újraszkennelni.
- AI: az AI Chat a katalógusról válaszol és SQL-t ír, csak metaadatot olvas, és az ügyfél saját Azure OpenAI-ján fut. Az AI Assistant egy személy saját gépén futó coding agentet (Claude Code, Codex, Gemini CLI, GitHub Copilot) enged személyes kulccsal kapcsolódni és az adott személy jogosultságaival dolgozni: olvassa a katalógust, Mart terveket, Vault tervezeteket, Sandbox tervezeteket és fejlesztői jegyzeteket javasol, amelyeket egy személy hagy jóvá, és ahol az adathozzáférés be van kapcsolva, ideiglenes, egyórás bejelentkezésen át olvas adatot, amelyen minden maszkolt és minden AI elől rejtett oszlop üresen érkezik. Minden lépés az AI Assistant naplóban rögzül.
- Kilépés: a Parquet-fájlok az ügyfél tulajdonában lévő tárolóban maradnak, nyílt formátumban, bármely Parquet-olvasó motorral olvashatóan. Nincs zárt katalógus, amelyből exportálni kellene.

## Kérdések és válaszok

A Gyakori kérdések oldal kérdései és válaszai, azonos szöveggel.

### A platform

**Mi a SchemaVortex?**

A SchemaVortex egy data lakehouse platform: kinyeri az adatot az operatív adatbázisokból, verziózott adattörténetet vezet róla, és jogosultsághoz kötött SQL-view-kként szolgálja ki. Az ügyfél saját Azure-előfizetésén belül fut, nem olyan szolgáltatásként, amelyhez az adatot el kellene küldeni, és böngészőből konfigurálható, nem pipeline-kód írásával.

**Mi nem a SchemaVortex?**

Nem riportkészítő vagy vizualizációs eszköz, és nem váltja ki azokat a forrásrendszereket, amelyekből olvas. Ellenőrzött, historizált adatot állít elő, és szabványos SQL-en keresztül szolgálja ki: a diagramok és a dashboardok továbbra is a Power BI-ban, az Excelben vagy abban készülnek, amit a szervezet már használ.

**Ki üzemelteti a SchemaVortexet a bevezetés után?**

Az ügyfél saját csapata. A platform önműködő, és az ügyfél saját Azure-előfizetésén belül fut; az átadás után a szállítónak nincs állandó hozzáférése a tenanthoz. Ha egy support mérnöknek mégis bele kell néznie, azt az ügyfél által létrehozott és bármikor visszavonható, korlátozott jogosultságú, ideiglenes fiókon keresztül teszi.

**Miben más ez, mint ha magunk építenénk meg a pipeline-okat?**

A kézzel épített betöltés azt jelenti, hogy az extraction, a historizálás, a sémaváltozások kezelése, a jogosultságkezelés, a lineage és a katalógus külön-külön megírandó és karbantartandó feladat, jellemzően szakértő mérnökökkel. A SchemaVortex ezeket egyetlen platformként adja: az Origin regisztrálása után a táblákat magától feltérképezi, és ami kijön belőle, az már historizált, ellenőrzött és visszakövethető.

### Adat és tárolás

**Hol van fizikailag az adatunk?**

Az ügyfél saját Azure-előfizetésén belül. Az extraction helyben olvassa a forrásokat, a Vault az ügyfél saját Azure Data Lake tárolójába íródik, és a kiszolgálás is ugyanabban az előfizetésben fut, amelyet a Microsoft közvetlenül az ügyfélnek számláz. Nincs szolgáltatói felhő, ahová az adatot el kellene küldeni.

**Milyen formátumban tárolódik az adat?**

Apache Parquet formátumban. A Vault Parquet-fájlok halmaza az ügyfél saját Azure Data Lake tárolójában, amelyet a Power BI, az Excel, a Spark és bármely más Parquet-olvasó motor közvetlenül olvas, akár a SchemaVortexszel együtt, akár nélküle.

**Hogyan lehet lekérdezni az adatot?**

Mart view-kon keresztül, amelyek az Azure Synapse Analytics serverless SQL view-jai a Vault fölött. Bármi olvassa őket, ami SQL-t beszél: Power BI, Excel, Tableau, Qlik, Python vagy bármilyen SQL-kliens. A serverless működés azt jelenti, hogy a lekérdező motor lekérdezésenként számlázódik, és nincs méretezendő vagy folyamatosan futó cluster.

**Megmarad a historikus adat, és lekérdezhető a múlt?**

Igen. A verziók hozzáadódnak, nem írják felül egymást, így egy rekord korábbi állapotai addig maradnak elérhetők, ameddig Ön meg kívánja őrizni őket. Minden Vault tábla két alakban érhető el: a Latest tábla az aktuális állapotot tartja a napi riportoláshoz, a History tábla pedig az auditokhoz és az adott időpontra vonatkozó kérdésekhez. Egy hibás töltés visszavonható: a forrás táblái visszaállnak egy előtte lévő időpontra, és az addigi adattörténet megmarad.

**Meddig őrzi meg a rendszer az adatokat?**

Addig, ameddig Ön meg kívánja őrizni őket. Minden tábla aktuális állapota elérhető marad; azt, hogy a mögötte álló adattörténet meddig nyúlik vissza, megőrzési beállítás szabja meg, amely az Ön kezében van. A GDPR előírja, hogy személyes adat nem őrizhető a szükségesnél tovább, ezért az adattörténet mélysége beállítás, nem rögzített ígéret.

**Mi történik az adatunkkal, ha abbahagyjuk a SchemaVortex használatát?**

Ott marad, ahol eddig is volt. A Parquet-fájlok az ügyfél tulajdonában lévő tárolóban, nyílt formátumban állnak, és bármely Parquet-olvasó eszközzel olvashatók maradnak. Nincs zárt katalógus, amely magánál tartaná az adatot, és nincs mit exportálni vagy kiköltöztetni.

### Források csatlakoztatása

**Milyen forrásrendszerek csatlakoztathatók?**

A beépített connectorok lefedik az SQL Servert, a PostgreSQL-t, a MySQL-t, a MariaDB-t, az Oracle-t, az SAP HANA-t, az IBM i-t és az Infor Data Lake-et, valamint a rájuk épülő ERP-, CRM- és vállalati rendszereket, és a lista folyamatosan bővül. Az Excel-, CSV- és Parquet-fájlok táblaként importálhatók. A REST API-k és minden más forrás, amelyhez nincs beépített connector, a Producer SDK-n keresztül tölthető be.

**Kézzel kell megfeleltetni a sémát?**

Nem. Az Origin regisztrálása után a SchemaVortex maga térképezi fel: a táblákat, az oszlopokat, azok típusait és kulcsait magából a forrásból olvassa ki. Innentől annyi a teendő, hogy ki kell választani a követendő Forrás táblákat, és mindegyikhez extraction stratégiát kell választani.

**Mi történik, ha egy forrás tábla szerkezete megváltozik?**

A Vault oszlopkészlete mindig csak bővül. Ha egy forrás új oszlopot vesz fel vagy megváltoztatja egy oszlop típusát, a Vault táblát egyetlen módosítással frissíteni kell, és az új alak új, verziózott oszlopként tárolódik. Az eredeti úgy marad, ahogy volt, és nem töltődik tovább. Az új oszlop megjelenése előtti rekordokban az oszlop üresen látszik. Mivel a meglévő oszlopok soha nem módosulnak és nem tűnnek el, a riportok által olvasott oszlopok nem változnak meg alattuk.

### Governance és visszakövethetőség

**Hogyan szabályozható az érzékeny adatokhoz való hozzáférés?**

A besorolást igénylő adatokat a Data Steward sorolja be. A besorolás egy érzékeny adatfajtát jelöl, és személyek, csoportok kaphatnak rá jogosultságot. Egy lekérdezés a besorolt adatot csak annak adja vissza, aki az adat minden besorolására jogosult, valamint annak, aki az adat forrásrendszerére Data Steward vagy Data Warden jogosultsággal rendelkezik. Mindenki másnak a lekérdezés NULL-t vagy maszkolt értéket ad vissza. A hozzáférés minden lekérdezés futásakor dől el, így az adatokról nem kell maszkolt másolatot építeni és szinkronban tartani. Egyetlen tábla sem kerül be a Vaultba, amíg egy Data Warden jóvá nem hagyja, a Vault Manager pedig egy második besoroláskészletet tehet a Vault által kiadott adatokra. Minden jóváhagyás, kapumódosítás és tagságváltozás rögzül, azzal együtt, hogy ki és mikor végezte.

**Mire terjed ki a lineage?**

A view-kra és az oszlopokra. Egy Mart view bármely oszlopa visszakövethető minden view-n át egészen a mögötte álló forrásoszlopig, és ugyanezek a kapcsolatok előrefelé is futnak, így egy változtatás előtt kilistázható, mely Mart view-kat érintené. Mivel a platform maga oldja fel az összes view-t, a lineage abból olvasható ki, ami ténylegesen fut, nem egy kézzel karbantartott dokumentációból.

**Kell hozzá külön adatkatalógus?**

Nem, a katalógus a platform része. Egyetlen sémaböngésző fogja át a Vaultot és a Martot, beépített SQL-szerkesztő szolgál a view-k írására és módosítására, a lineage bármely tábláról vagy oszlopról megnyitható, a táblák, a view-k és a Vault oszlopai pedig megjegyzéssel és címkékkel láthatók el. Nincs mit a lake mellé telepíteni vagy ütemezetten újraszkennelni.

**Látja az AI az adatainkat?**

Az AI Chat nem: a sémát és a metaadatokat olvassa, rekordot soha, és az Ön saját Azure OpenAI-ján fut. Az AI Assistanten keresztül egy felhasználó saját gépén futó coding agent olvashatja a katalógust és javasolhat változásokat. Ahol a telepítés bekapcsolja az adathozzáférést, az agent ideiglenes bejelentkezésen át olvas adatot. Ezen a bejelentkezésen minden maszkolt és minden AI elől elrejtett oszlop üresen érkezik, akkor is, ha a felhasználó olvashatja. A bejelentkezés egy óráig érvényes, és minden lépés az AI Assistant naplóban rögzül, a felhasználó neve alatt.

**Megváltoztathat egyetlen személy egyedül egy Mart view-t vagy egy Vault táblát?**

Igen, ha rendelkezik az érvényesítéshez szükséges jogosultsággal. Egy telepítés előírhatja, hogy minden Mart változás Mart terven keresztül menjen. A változtatás javaslatként is történhet. A Mart terv, a Vault tervezet vagy a Sandbox tervezet leírja a változást, a platform a Mart vagy a Vault aktuális állapotához képest ellenőrzi, majd az érvényesítésre jogosult személy a saját nevén élesíti vagy hagyja jóvá, és ezt az audit trail rögzíti. A Martban a szétválasztás beépített: a Mart Manager terveket ír, élesíteni pedig csak a Mart Publisher tud. Hogy a szerzőnek és a jóváhagyónak egyébként két különböző személynek kell-e lennie, azt a jogosultságok kiosztása dönti el az adott telepítésben.

**Mi történik, ha ketten ugyanazt a view-t módosítják?**

A Mart terv minden tétele megjegyzi, a view melyik verziójához képest íródott. Ha a view időközben megváltozott, a tétel konfliktusként jelenik meg, a terv a feloldásáig nem élesíthető, és az ellenőrzés az élesítés közben újra lefut, így egy változás sosem íródik felül észrevétlenül. Ugyanez a szabály védi a Vault tervezetet: ha a tábla oszlopai a tervezet megírása után megváltoztak, érvényesítés előtt újra meg kell nyitni és menteni.

**Végezhet az AI Assistant önállóan változtatást?**

Nem. Írhat Mart tervet, Vault tervezetet vagy Sandbox tervezetet, de élesíteni, jóváhagyni vagy elvetni sosem tud; ezt egy személy teszi, a saját nevén. Az asszisztens minden lépése az AI Assistant naplóba kerül, annak a személynek a neve alatt, aki használta.

## Oldalak

- [Gyakori kérdések](https://schemavortex.com/hu/faq.html): egyenes válaszok arra, hogy mi a platform és mi nem, hol van fizikailag az adat, milyen formátumban és milyen lekérdező motorral, milyen forrásrendszerek csatlakoztathatók, mi történik sémaváltozáskor, hogyan működik a governance és a lineage, és mi marad, ha az ügyfél abbahagyja a használatát.
- [Kezdőlap](https://schemavortex.com/hu/): áttekintés, a platform összefoglalása és az út a forrástól a lekérdezésig.
- [Storyboard](https://schemavortex.com/hu/storyboard.html): animált kártyák, mindegyik egy probléma és a megoldása, kilenc fejezetben a forrás csatlakoztatásától az audit trailig.
- [Governance](https://schemavortex.com/hu/governance.html): a besorolások, a négy kapu, a szerepkörök és az audit.
- [Négy szem elve](https://schemavortex.com/hu/four-eyes.html): Mart tervek, Vault tervezetek és Sandbox tervezetek: az aktuális állapothoz képest ellenőrzött javaslatok, amelyeket az arra jogosult személy a saját nevén érvényesít.
- [A Vault](https://schemavortex.com/hu/vault.html): hogyan marad meg az adattörténet, és hogyan kezeli a platform a forrás sémaváltozásait.
- [Lineage](https://schemavortex.com/hu/lineage.html): egy oszlop visszakövetése a forrásáig és hatáselemzés a változtatás előtt.
- [A Katalógus](https://schemavortex.com/hu/catalog.html): sémaböngésző, beépített SQL-szerkesztő, megjegyzések.
- [Alapból nyitott](https://schemavortex.com/hu/open-by-design.html): az ügyfél saját Azure-előfizetése, nyílt Parquet, az adat nem függ a platformtól.
- [Bármi csatlakoztatható](https://schemavortex.com/hu/connect.html): a támogatott források és az eszközök, amelyek az eredményt fogyasztják.
- [Bring Your Own Data](https://schemavortex.com/hu/bring-your-own-data.html): Excel-, CSV- és Parquet-fájlok importálása, és a Producer SDK adatküldéshez bármely rendszerből.
- [Megőrzés és adat-helyreállítás](https://schemavortex.com/hu/point-in-time-revert.html): az adattörténet két vége: a legrégebbi töltések megőrzése, és a forrás tábláinak visszaállítása egy korábbi időpontra hibás töltés után.
- [A Mart](https://schemavortex.com/hu/mart.html): a riportmodell SQL-view-kban a Vault fölött: élesítés előtti ellenőrzés, minden változás nyilvántartva, visszaállítás Mart terven keresztül, és eltárolt eredmények, amelyek adatváltozáskor újraépülnek.
- [A Sandbox](https://schemavortex.com/hu/sandbox.html): személyes SQL-tér minden felhasználónak az ellenőrzött adaton, és tervezetek, amelyeket a tulajdonos hagy jóvá.
- [AI](https://schemavortex.com/hu/ai.html): az AI Chat, csak metaadattal az ügyfél saját Azure OpenAI-ján, és az AI Assistant coding agentekhez, korlátozott adathozzáféréssel és az AI kapuval.

## Piacterek

- [Microsoft Marketplace](https://marketplace.microsoft.com/en-us/product/fizzcodekorlatoltfelelossegutarsasag1620904005110.schemavortex): a hivatalos, angol nyelvű listázás a Microsoft kereskedelmi piacterén. Az ajánlat kapcsolatfelvétel alapú, nem egy kattintással telepíthető.

## Más nyelvek

- [English](https://schemavortex.com/): a teljes oldal angolul.
- [English llms.txt](https://schemavortex.com/llms.txt): ez a fájl angolul, az angol nyelvű oldalakhoz.

## Jogi tudnivalók

- [Adatkezelési tájékoztató](https://schemavortex.com/hu/privacy.html): az adatkezelő adatai és a GDPR szerinti tájékoztatás.