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 szabályozott SQL nézetekké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. Szabályozott, 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 önmenedzselő, é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 támogató 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, szabályozott é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 adatnak utaznia kellene.

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 nézeteken keresztül, amelyek az Azure Synapse Analytics serverless SQL nézetei a Vault fölött. Bármi olvassa őket, ami SQL-t beszél: Power BI, Excel, Tableau, Qlik, Python vagy egy egyszerű 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 extraction visszagörgethető anélkül, hogy a megőrzött adattörténet elveszne.

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.

Pontosan 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 fogva tartaná az adatot, és nincs mit exportálni vagy kiköltöztetni.

Az SQL adatbázisokat a platform közvetlenül olvassa, köztük az SQL Servert, a PostgreSQL-t és az IBM AS/400-at (DB2 for i), valamint a rájuk épülő ERP-, CRM- és vállalati rendszereket. A fájlok, a REST API-k és minden olyan 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, az új alak új, verziózott oszlopként tárolódik, az eredeti pedig pontosan úgy marad, ahogy volt, csak 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.

Minden oszlop öt kapun megy át, mielőtt bárki láthatná, és három adatgazda tart külön kulcsot fölöttük, így egyetlen szerepkör sem lát szabályozatlan adatot. A maszkolás lekérdezéskor érvényesül: aki lekérdez, a rá maszkolt nézetet kapja, és nincs külön letisztított másolat, amelyet építeni és szinkronban tartani kellene. Minden jóváhagyás, besorolás és maszkváltoztatás rögzül, azzal együtt, hogy ki, mit és mikor módosított.

A nézetekre és az oszlopokra. Egy Mart nézet bármely oszlopa visszakövethető minden nézeten á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 nézeteket érintené. Mivel a platform maga oldja fel az összes nézetet, 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 nézetek írására és módosítására, a lineage bármely tábláról vagy oszlopról megnyitható, és bármely objektum ellátható megjegyzéssel és címkével. Nincs mit a lake mellé telepíteni vagy ütemezetten újraszkennelni.

Nem. Szerkezetet olvas, nem tartalmat: a sémát és a metaadatokat, magukat a rekordokat soha. Az ügyfél saját Azure-előfizetésén belül fut, semmi nem kerül külső szolgáltatáshoz, és minden interakció ugyanabba az audit trailbe kerül, mint a platform többi művelete.