Die Ent­wick­lung von State-of-the-Art Daten­platt­for­men fin­det kaum mehr einen Weg vor­bei an Data­lakes. Doch einen Über­blick zu behal­ten, wel­che Daten im Data­lake ver­wal­tet wer­den, wohin diese flie­ßen und wer Zugriff auf wel­che Tabel­len hat, bleibt eine Mam­mut­auf­gabe. In einer typi­schen Enter­prise-Daten­ar­chi­tek­tur gibt es dut­zende Daten­ban­ken, ver­teilt ent­we­der On-premises oder auf ver­schie­denste Cloud­platt­for­men und auf diver­sen Daten­bank­sys­te­men. Wie sol­len Teams in die­sen Struk­tu­ren einen Über­blick behal­ten, wel­che Daten vor­han­den sind, wer Zugriff dar­auf hat und wohin diese flie­ßen?
Der von Dat­ab­ricks ange­bo­tene Unity Cata­log lie­fert eine zen­tra­li­sierte Gover­nan­ce­lö­sung, die Abhilfe schaf­fen soll. Der Unity Cata­log ist jedoch kein klas­si­scher Daten­ka­ta­log, wie der Name ver­mu­ten las­sen könnte. Viel­mehr ist er eine Data-Gover­nance-Lösung, die Anwen­dern ermög­licht, den Zugriff auf den Data­lake von einer zen­tra­len Stelle aus zu steu­ern. Er bie­tet die lösung um alle Daten­ty­pen und ‑quel­len in einem ein­zi­gen Kata­log registrieren.

Zusam­men mit dem Release des Unity Cata­logs erwei­tert Dat­ab­ricks sein Ange­bot außer­dem um zahl­rei­che neue Funk­tio­nen. Diese ent­hal­ten unter ande­rem Data Lineage, um Daten­her­kunft nach­zu­ver­fol­gen, Delta Sha­ring, das das Tei­len von Daten ver­ein­facht und Query Fede­ra­tion, was es ermög­licht, externe Daten­ban­ken an den Unity Cata­log anzubinden.

Die­ser Bei­trag gibt einen Ein­blick in die Funk­tio­nen und zeigt auf, wie mit­hilfe des Unity Cata­logs die Data Gover­nance in einer Umge­bung mit Dat­ab­ricks gehand­habt wird. 

Daten­bank­ob­jekte im Unity Cata­log  

Das Zen­trum, um das sich alles im Unity Cata­log dreht, sind Daten. Diese gilt es zu struk­tu­rie­ren, auf­find­bar zu machen und den Zugriff zu ver­wal­ten. Damit das belie­big genau getan wer­den kann, bedarf es diver­ser Daten­bank­ob­jekte, die ver­schie­dene Funk­tio­nen erfül­len. Die­ser Para­graf wid­met sich zunächst den ver­schie­de­nen Objek­ten und ihrer Funk­tion im Unity Catalog.

Der Metastore im Unity Catalog

Als zen­trale Ver­wal­tungs­ein­heit fun­giert der Unity Cata­log Metastore. Hier wer­den Meta­da­ten zu Daten­bank­ob­jek­ten wie Tabel­len, Volu­mes, File Shares und Exter­nal Loca­ti­ons sowie die Berech­ti­gun­gen auf diese Objekte verwaltet. 

Unter einem Metastore wer­den die Daten­bank­ob­jekte in einer drei­stu­fi­gen Hier­ar­chie ver­wal­tet. Kata­loge befin­den sich auf der obers­ten Ebene, dar­un­ter sind Sche­mas ange­ord­net und auf der unters­ten Ebene die eigent­li­chen Daten­ob­jekte, wie in Abbil­dung 1 zu sehen ist. 

In der Regel wird pro Betriebs­re­gion ein Metastore bereit­ge­stellt, wel­cher wie­derum dem Dat­ab­ricks Account zuge­ord­net ist. Der Grund, wieso genau ein Metastore ver­wen­det wird, ist, dass hier die Zugriffs­ver­wal­tung der ein­zel­nen Workspaces zusam­men­läuft und mit dem RBAC-Rol­len (role-based access con­trol) – z.B. des Clou­dan­bie­ters – zusam­men­ge­bracht wird. Des Wei­te­ren kann der Zugriff auf Workspaces im sel­ben Metastore ein­fach frei­ge­schal­tet wer­den. Auf den Metastore kön­nen belie­big viele Dat­ab­ricks Workspaces zugrei­fen. Aller­dings muss der Workspace, in dem gear­bei­tet wird, mit einem Unity Cata­log Metastore ver­bun­den sein, um den Unity Cata­log ver­wen­den zu können.

Kata­log 

Kata­loge sind die oberste Ebene der Daten­hier­ar­chie, die vom Unity Cata­log Metastore ver­wal­tet wird. Sie sind als erste Stufe zur Daten­iso­lie­rung im Data Gover­nance-Modell vor­ge­se­hen. Kata­loge bie­ten eine Mög­lich­keit, Sche­mas logisch zu grup­pie­ren. So kann bei­spiels­weise die Tren­nung von Ent­wick­lungs- und Pro­duk­ti­ons­da­ten durch Kata­loge wider­ge­spie­gelt wer­den oder es kön­nen Pro­dukte in eigene Kata­loge iso­liert werden.

Schema  

Sche­mas sind logi­sche Grup­pie­run­gen von tabel­la­ri­schen Daten (Tabel­len und Views), nicht tabel­la­ri­schen Daten (Volu­mes), Funk­tio­nen und Model­len für maschi­nel­les Ler­nen. Sie bie­ten eine Mög­lich­keit, den Zugriff auf Daten auf einer wei­te­ren Ebene zu steu­ern, die gra­nu­la­rer ist als Kata­loge. Oft reprä­sen­tie­ren sie einen ein­zel­nen Anwen­dungs­fall, etwa eine Grup­pie­rung meh­re­rer Tabel­len aus einem Quell­sys­tem. Wei­ter denk­bare Bei­spiele wären etwa die Iso­la­tion der Views für ein Team oder eine Zielanwendung.

Tabel­len und Views 

Tabel­len befin­den sich in der drit­ten Ebene des drei­stu­fi­gen Name-Spaces von Unity Cata­log. Sie ent­hal­ten die eigent­li­chen Daten. Mit dem Unity Cata­log kön­nen Tabel­len ent­we­der ver­wal­tet – Dat­ab­ricks nennt diese Tabel­len „mana­ged” – oder als „externe“ Tabel­len erstellt werden. 

Für ver­wal­tete Tabel­len über­nimmt der Unity Cata­log die Ver­wal­tung des Lebens­zy­klus und das Lay­out der Dateien auf dem Spei­cher voll­stän­dig. Das heißt, dass Dat­ab­ricks nicht mehr gebrauchte Daten (bei­spiels­weise nach einem DROP TABLE) selbst­stän­dig löscht. Stan­dard­mä­ßig wer­den ver­wal­tete Tabel­len in dem Spei­cher­ort abge­legt, der beim Erstel­len eines Metasto­res kon­fi­gu­riert wurde, etwa Azure Sto­rage oder AWS Buckets. Der Spei­cher­ort kann statt­des­sen auch auf der Kata­log- oder Sche­mae­bene gesetzt werden. 

Externe Tabel­len sind Tabel­len, deren Lebens­zy­klus und Datei­lay­out vom Clou­dan­bie­ter oder ande­ren Daten­platt­for­men ver­wal­tet wer­den, anstatt von Unity Cata­log. Dafür muss wäh­rend dem Erstel­len der Tabelle zusätz­lich ein Spei­cher­ort mit dem Key­word LOCATION ange­ge­ben wer­den. Typi­scher­weise wer­den externe Tabel­len ver­wen­det, um große Men­gen von bestehen­den Daten zu regis­trie­ren oder um den Zugriff auf die Daten mit Tools außer­halb von Dat­ab­ricks zu ermög­li­chen. Externe Tabel­len unter­stüt­zen eine Viel­zahl von Daten­for­ma­ten wie zum Bei­spiel Par­quet, CSV und JSON. 

Sobald eine externe Tabelle in einem Unity Cata­log-Metastore regis­triert ist, kann der Zugriff auf sie über Dat­ab­ricks genauso ver­wal­tet wer­den, wie bei nati­ven Databrickstabellen. 

Volu­mes

Volu­mes befin­den sich eben­falls auf der drit­ten Ebene des drei­stu­fi­gen Namens­rau­mes von Unity Cata­log.  Sie kön­nen ver­wen­det wer­den, um struk­tu­rierte, semi­struk­tu­rierte und unstruk­tu­rierte Daten abzu­le­gen. So kön­nen bei­spiels­weise Bil­der, Audio oder Text­da­teien für maschi­nel­les Ler­nen ver­wal­tet werden. 

Modelle und Funk­tio­nen 

Obwohl sie streng genom­men keine Daten­be­stände sind, kön­nen regis­trierte (Machine Lear­ning) Modelle und benut­zer­de­fi­nierte Funk­tio­nen (UDF) eben­falls im Unity Cata­log ver­wal­tet wer­den und befin­den sich auf der unters­ten Ebene der Objekthierarchie. 

Data Gover­nance und Access Con­trol 

Der Zugriff auf von Dat­ab­ricks ver­wal­tete Daten ist stan­dard­mä­ßig beschränkt. In ande­ren Wor­ten: Zugriff hat erst ein­mal nur der Besit­zer des Daten­bank­ob­jekts. Damit ein ande­rer Benut­zer auf Daten zugrei­fen kann, muss ihm expli­zit Zugriff erteilt wer­den.  
 
Die Berech­ti­gun­gen kön­nen belie­big gra­nu­lar auf den oben beschrie­be­nen Ebe­nen gesetzt wer­den, wobei Berech­ti­gun­gen im Unity Cata­log nach der Hier­ar­chie von oben nach unten ver­erbt wer­den. Berech­ti­gun­gen kön­nen von Objekt­be­sit­zern und Admi­nis­tra­to­ren gewährt wer­den. Ent­we­der in der UI, mit­hilfe von ANSI SQL-Befeh­len oder mit der von Dat­ab­ricks ange­bo­te­nen REST-API kön­nen die Rechte an ein­zelne Benut­zer und Grup­pen bezie­hungs­weise RBAC-Rol­len zuge­wie­sen werden. 

In Abbil­dung 2 ist zu sehen, wie die Zugriffs­kon­trolle in Dat­ab­ricks abläuft. Im Fall von mana­ged Tabel­len läuft die Kon­trolle rein über den Unity Cata­log, wäh­rend für Daten auf Exter­nal Loca­ti­ons zusätz­lich Cre­den­ti­als für den jewei­li­gen Cloud­s­to­rage benö­tigt wer­den. Diese sind wie­derum im Unity Cata­log hin­ter­legt. Alle Benut­zer­ak­ti­vi­tä­ten wer­den in Audit Logs gespei­chert. Wie in Abbil­dung 2 zu sehen ist, wird auf der ers­ten Ebene geprüft, ob der Benut­zer die Berech­ti­gung für die im Unity Cata­log hin­ter­legte Tabelle hat. Im zwei­ten Schritt folgt dann der Abgleich der Berech­ti­gung auf die exter­nen Ressourcen. 

Moni­to­ring und Audit Logs in Dat­ab­ricks 

Das Moni­to­ring aller Akti­vi­tä­ten von Benut­zern auf Dat­ab­ricks Workspaces spielt in vie­len Unter­neh­men eine große Rolle. Um alle Akti­vi­tä­ten rund um Benut­zer, Rechte, Clus­ter und Daten­zu­griffe zu über­wa­chen, bie­tet Dat­ab­ricks zahl­rei­che Event Logs an. In den Audit Logs für Benut­ze­r­e­vents wird bei­spiels­weise fest­ge­hal­ten, wann sich ein Benut­zer ein­loggt, wenn sich Zugriffs­rechte ändern oder wenn er ein Token ver­wen­det. So kann detail­liert nach­voll­zo­gen wer­den, wel­che Aktio­nen aus­ge­führt wur­den.  Wie in Abbil­dung 2 zu sehen, wird jeg­li­cher Zugriff in den Audit Logs gespei­chert. Die fol­gende Abfrage gibt bei­spiels­weise alle Audit Logs für den betref­fen­den Nut­zer aus.

SELECT * FROM system.access.audit
WHERE user_identity.email = "user.name@abc.com" 

Eine wei­tere Kom­po­nente für das Moni­to­ring sind die Views, die im Infor­ma­tion Schema ent­hal­ten sind. Das Infor­ma­tion Schema ist ein Stan­dard­schema, das Meta­in­for­ma­tio­nen über Objekte ent­hält, die der zuge­hö­rige Kata­log ver­wal­tet. Sie zei­gen Daten wie etwa Beschrei­bungs­texte, Tags und Cons­traints (z.B. für Pri­mary und For­eign Key). Abfra­gen auf diese Tabel­len ermög­li­chen es, Daten ein­fach aus­fin­dig zu machen. So lässt sich zum Bei­spiel ein­fach mit fol­gen­der Abfrage erhe­ben, wie viele Tabel­len in wel­chem Schema sind. Des Wei­te­ren sind hier auch Pri­vi­le­gien der Benut­zer abgelegt.

SELECT table_schema, count(table_schema) 
    FROM system.information_schema.tables
    GROUP BY table_schema

Data Lineage 

Ein wei­te­res Fea­ture, das Dat­ab­ricks mit dem Unity Cata­log ein­ge­führt hat, ist die auto­ma­ti­sierte Erfas­sung von Data Lineage. Dabei wird zur Lauf­zeit der Daten­fluss von Anfang bis Ende der Ver­ar­bei­tung auf Zei­len- und Spal­ten­ebene ana­ly­siert und zur Aus­wer­tung auf­ge­ar­bei­tet. In die Lineage Daten flie­ßen alle Ope­ra­tio­nen ein, die in den von Dat­ab­ricks unter­stütz­ten Spra­chen aus­ge­führt wer­den. Wie in Abbil­dung 3 ersicht­lich, wird auch das Schrei­ben und Lesen von Exter­nal Loca­ti­ons sowie die Ver­wen­dung in Machine Lear­ning Model­len in der Data Lineage auf­ge­fasst. So erhält man ein voll­stän­di­ges Bild der Daten­ab­folge von Anfang bis Ende. 

Der Zugriff auf Lineage Daten ist durch das Data Gover­nance Kon­zept gesi­chert. So benö­tigt man etwa BROWSE oder SELECT Pri­vi­le­gien auf der Tabelle, deren Lineage man betrach­ten möchte.

Data Sha­ring 

Data Sha­ring in Dat­ab­ricks kann in zwei Berei­che ein­ge­teilt wer­den: Zum einen in das Ver­füg­bar-Machen von Daten über Workspace-Gren­zen hin­weg, wobei sich Nut­zer der Daten wei­ter­hin im glei­chen Metastore bewe­gen und zum ande­ren in das Tei­len von Daten über Metastore- und Unter­neh­mens­gren­zen hin­weg mit­hilfe des Delta Sha­ring Protokolls. 

In Dat­ab­ricks sind Kata­loge an einen oder meh­rere Workspaces gebun­den. Nur Benut­zer, die sowohl Zugriff auf den ent­spre­chen­den Workspace als auch auf die Tabelle haben, kön­nen auf diese zugrei­fen. Diese Bin­dung kann auf andere Workspaces des glei­chen Metasto­res aus­ge­wei­tet wer­den, sodass Daten effi­zi­ent geteilt wer­den kön­nen, ohne auf andere Sha­ring-Metho­den oder das Repli­zie­ren von Daten zurück­grei­fen zu müssen. 

Lake­house Fede­ra­tion 

Um den Zugriff auf Daten aus exter­nen Daten­ban­ken wie MySQL, Post­greSQL, Snow­flake oder Micro­soft SQL Ser­vern in einer Dat­ab­ricks Platt­form zu zen­tra­li­sie­ren, ohne diese Daten auf Dat­ab­ricks migrie­ren zu müs­sen, kön­nen diese Daten­ban­ken an den Unity Cata­log ange­bun­den wer­den. Dabei gibt es die Mög­lich­keit ein­zelne Ver­bin­dun­gen zu Daten­ban­ken anzu­le­gen, wel­che bei­spiels­weise JDBC-Ver­bin­dungs­in­for­ma­tio­nen zu einer Post­greSQL Daten­bank defi­nie­ren, die dann in exter­nen Kata­lo­gen Daten zwi­schen Quelle und dem Unity Cata­log syn­chro­ni­sie­ren und so eine Zugriffs­kon­trolle über die Unity Cata­log Gover­nance bieten. 

Lake­house Fede­ra­tion über­setzt Dat­ab­ricks-SQL in Anwei­sun­gen, die in die föde­rierte Daten­quelle abge­setzt wer­den kön­nen. Dies ermög­licht es den Benut­zern, SQL-Abfra­gen direkt auf den ver­bun­de­nen Daten­ban­ken aus­zu­füh­ren, als ob die Daten nativ in Dat­ab­ricks gespei­chert wären. Durch diese naht­lose Inte­gra­tion kön­nen Benut­zer Dat­ab­ricks als zen­trale Daten­platt­form nut­zen, wäh­rend sie auf diverse bestehende Quel­len zugrei­fen können.

Fazit 

Der Dat­ab­ricks Unity Cata­log stellt eine umfas­sende und zen­trale Lösung für die Ver­wal­tung und Gover­nance von Daten in moder­nen Daten­platt­for­men dar. Mit Funk­tio­nen wie Data Lineage, Delta Sha­ring und Query Fede­ra­tion bie­tet der Unity Cata­log zahl­rei­che Mög­lich­kei­ten, den Daten­zu­griff sicher und effek­tiv zu steu­ern. Die drei­stu­fige Hier­ar­chie des Daten­ka­ta­logs ermög­licht eine detail­lierte und fle­xi­ble Daten­or­ga­ni­sa­tion, wäh­rend die Audit Logs und Moni­to­ring-Tools eine trans­pa­rente Nach­ver­fol­gung aller Akti­vi­tä­ten gewähr­leis­ten. Die Inte­gra­tion von exter­nen Daten­quel­len und die Unter­stüt­zung ver­schie­de­ner Daten­for­mate ermög­licht es Data-Gover­nance mit Dat­ab­ricks Unity Cata­log zu optimieren.

Quel­len:

Azure Dat­ab­ricks docu­men­ta­tion | Micro­soft Learn
The Data and AI Com­pany — Databricks

Abbil­dun­gen:
Micro­soft Learn Abbil­dung 1
Databricks.com Abbil­dung 2