Gyakori kérdések

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.

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.

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.

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ő.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.