Moderne Plattformen zur analytischen Verarbeitung von Daten vereinen eine Vielzahl von Komponenten in den Bereichen Datenhaltung, Analyse, Services und Prozesse. Eine zentrale Rolle kann und sollte dabei ein moderner, gut integrierter Datenkatalog einnehmen, der sowohl das klassische Reporting, das explorative Arbeiten als auch die datengetriebene Unterstützung und Optimierung operativer Prozesse unterstützen kann. Auch wenn häufig der Begriff Datenkatalog verwendet wird (und wir das der Einfachheit halber hier auch tun) haben diese Tools häufig einen weit größeren Funktionsumfang. Die Hersteller verwenden oft die Bezeichnung Data Intelligence.
In diesem Artikel wollen wir einen Blick auf die Herausforderungen und Möglichkeiten beim Einsatz eines Datenkataloges in einer Analytics Plattform werfen und dabei auch auf Stolpersteine hinweisen, die im Laufe eines Roll Out Programmes auftauchen können. Vor allem soll auf zu erwartende Fragestellungen und Probleme hingewiesen werden – die Antworten und Lösungen sind branchen- und unternehmensspezifisch.
Welche Systeme sollen angebunden werden?
Die grundlegende und namensgebende Funktion eines Datenkataloges ist es, den Bestand von Datenbanken zu erfassen und diese technischen Metadaten leicht auffindbar und durchsuchbar zu machen. Zudem sollen sie mit bestehenden und neuen fachlichen Metadaten integriert werden. Analytics Plattformen setzen öfter auf verschiedene Ebenen (Staging, Data Marts etc.), die die Daten aus Quellsystemen verfügbar machen. Diese setzen üblicherweise auf verschiedenen Datenbanktechnologien auf, für die unterschiedliche Konnektoren im Katalog genutzt werden, was oft zusätzliche Lizenzkosten generiert. Hier muss überlegt werden, ob man im Katalog eine komplette technische Sicht auf die Daten der Plattform bieten will oder nur den Teil darstellt, den man für den Endnutzer relevant hält. Auch innerhalb einer Datenbank will man oft nicht sämtliche Objekte in den Katalog holen. Rein technische Systemtabellen werden oft ausgeblendet, ebenso ist es denkbar, die eigentlichen Tabellen zu verstecken und nur die Views aufzunehmen, mit denen der Datenzugriff erfolgt. Je nach eingesetztem Katalog gibt es verschiedene Methoden, diese Aufnahme zu steuern, sei es grafisch über das UI oder selbst erstellte SQLs mit Steuertabellen, die durch einen weiteren Prozess gepflegt werden. Man sollte sich vor der erstmaligen Beladung Gedanken dazu machen, um später nicht unnötige Objekte wieder entfernen zu müssen. Bei Katalogen mit einem granularen Berechtigungskonzept ist es auch möglich, für unterschiedliche Benutzergruppen verschiedene Sichten anzubieten – der Data Engineer sieht die zu Grunde liegenden Tabellen, der Analyst nur die von ihm genutzten Views.
Ein weiterer Punkt, der bedacht werden sollte: Die Datenbanken der Analytics Plattform beziehen ihre Daten üblicherweise aus operativen Systemen oder anderen externen Quellen, die auch in separater Verantwortung liegen – sie werden aber nicht vollständig, sondern vielleicht nur auf Anforderung übernommen. Ein unternehmensweiter Datenkatalog würde die Quellsysteme natürlich betrachten. Aber auch im Analytics Bereich kann es die Anforderung geben, eine Sicht auf die Daten zu bieten, die noch nicht Teil der Plattform sind, aber für eine Fragestellung eines Analysten oder Data Scientist von Interesse. Die genaue Art der Einbindung sollte dann aber gut geplant sein, da sich die eingebundene Menge an Metadaten vervielfachen wird.
Man kann diesen Gedanken noch weiterspinnen und auch externe Datenmarktplätze einbinden, wie es sie zum Beispiel von Snowflake und den großen Cloudanbietern gibt. Der Katalog von Alation bietet hier mittlerweile eine vorgefertigte Anbindung.
Wie werden die Daten beschrieben?
Neben den technischen Metadaten wie der Objektbezeichnung oder dem Datentyp bieten Datenkataloge auch Felder für fachliche Titel, Beschreibungen und weitere selbstdefinierte Attribute. Diese werden üblicherweise nicht von der Datenbank abgerufen, sondern müssen auf anderem Wege eingepflegt werden. In einem Data Governance Konzept mag es für diese Aufgabe zum Beispiel die Rolle des Business Data Stewards für das Quellsystem geben. Wie sieht es aber aus, wenn Daten aus den Quellsystemen in die Plattform repliziert werden? Sollen die Beschreibungen mitübernommen werden? Oft liegen diese in Wikis, verstreuten Exceldateien oder in Architekturtools. Sind diese dann im Datenkatalog editierbar oder gilt die Beschreibung des Quellsystems als „Golden Record“?
Vielleicht sollen die fachlichen Metadaten auch regelmäßig synchronisiert werden. Ebenso muss geklärt werden, wie fachliche Beschreibungen für Daten gepflegt werden, die auf der Plattform neu erzeugt werden. Hier ist sowohl die Data Governance als auch die technische Implementierung von Bedeutung. Die meisten Kataloge bieten APIs, über die geforderte Synchronisierungen vorgenommen werden können – die Art und Richtung sollte aber vorab geklärt sein.
Wie werden Prozesse abgebildet und unterstützt?
Bei der Einbindung von Prozessen der Analytics Plattform unterscheiden wir zwischen bestehenden Prozessen, meist technischer Natur, die im Katalog dokumentiert werden, und Prozessen des organisatorischen Ablaufs der Plattform, die der Katalog aktiv unterstützen kann.
Auf der Seite der Technik ist zunächst das Thema Lineage und Impact zu betrachten – die Darstellung, woher die Daten kommen und wohin sie transportiert werden. Die automatisierte Einbindung mittels Konnektoren ist oft mit großen Herausforderungen verbunden. Es sollte genau geprüft werden, ob der angedachte Datenkatalog eine Schnittstelle zum eingesetzten ETL/ELT Werkzeug bietet. Für die Replizierung aus den Quellsystemen und für den Transport innerhalb der Plattform sind oft unterschiedliche Tools im Einsatz. Meist ist es nötig, über API Schnittstellen selbst die entsprechenden Metadaten bereitzustellen. Neben diesen technischen Überlegungen sollte auch geplant werden, wie weit und auf welche Weise der Datentransport dargestellt werden sollt. Wie soll zum Beispiel die Herkunft aus den Quellsystemen verdeutlicht werden, wenn diese nicht direkt an den Katalog angeschlossen sind? Erfahrungsgemäß ist die Einbindung der Lineage deutlich aufwendiger als das initiale Anbinde der Datenbanken.
Hat man die Quellsysteme in irgendeiner Form angebunden, so ergibt sich die Option, einen Prozess zu implementieren, der die Aufnahme von Daten von der Quelle in die Analytics Plattform antriggert. Hier bieten zum Beispiel die Kataloge von Collibra und Alation gute Möglichkeiten. Auch Aspekte des Datenschutzes könnten und sollten im Katalog präsent sein. So kann die Schutzbedürftigkeit von Datensätzen als zusätzliches Attribut angegeben werden und entsprechende Daten im Sampling maskiert werden. Hierzu sind dann aber wahrscheinlich weitere, separat gepflegte Metadaten nötig.
Auf welche Art verwenden die Nutzenden den Katalog?
Das Nutzungsverhalten der User ist sicherlich eine schwer planbare Größe. Dennoch sollte sich das Team für die Toolauswahl und ‑einführung mit dieser Frage beschäftigen und zum Beispiel über Interviews, Umfragen und Nutzertests Daten sammeln. Stellt man sich einen Katalog als reines Nachschlagewerk vor, das von einer Gruppe dezidierter Stewards befüllt wird oder setzt man auf starke Nutzerinteraktion? Soll eine fachliche oder technische Sicht auf die Daten im Vordergrund stehen? Wie wichtig und umfangreich soll ein Business Glossar sein? Unterschiedliche Toolanbieter haben hier sehr unterschiedliche Stärken und man kann kein „one size fits all“ Tool benennen. Bei einem Katalog für Fachanwender mit weniger technischen Background sind auch weiche Kriterien wie das Look-and-Feel der Oberfläche von Bedeutung. Speziell bei einer Analytics Plattform mag es ausreichend sein, den Katalog als Nachschlagewerk für die auf der Plattform vorhandenen Daten zu betreiben. In diesem Fall sollte aber bedacht werden, ob es auch einen unternehmensweiten Katalog gibt oder der Plattform Katalog langfristig dahin wachsen könnte. Auch die Einbindung des Kataloges in die unternehmensweite Governance muss mitgedacht werden. Inwieweit sollen zum Beispiel existierende Rollen wie Data Owner oder Steward in der Plattform und im Katalog abgebildet werden, ohne dabei den Fokus auf den Analytics Bereich zu verlieren?
Fazit
Wir haben gesehen, dass sich bei der Einführung eines Datenkatalogs (oder genauer einer Data Intelligence Plattform) eine Vielzahl von Fragen ergeben. Dies ergibt sich daraus, das ein Datenkatalog oft eine Vielzahl von Tools, Datenspeicherorten und Prozessen zusammenführen soll. Wir haben uns hier auf den Einsatz innerhalb einer Analytics Plattform konzentriert, aber auch bei eine umternehmensweiten Katalog stellen sich ähnliche, teilweise sogar größere, Herausforderungen. Hier ist es oft ratsam, mit einem kleinen Auschnitt der Datenwelt des Unternehmens, zum Beispiel einem Fachbereich oder einer Produktkategorie, zu beginnen und den Blick dann schrittweise zu weiten. Wir wollen hier kurz zusammenfassen, was in einer Analytics Plattform zu beachten ist:
- Welche (technischen) Metadaten sollen wie dargestellt werden?
- Woher kommen die fachlichen Beschreibungen und wie werden sie im Weiteren gepflegt?
- Wie soll die Data Lineage eingebunden werden?
- Welche weiteren Prozesse sollen im Katalog dargestellt oder unterstützt sein?
Zu diesen Fragen sollte man sich zu Beginn eines Datenkatalogprojektes Gedanken machen und zumindest vorläufige Entscheidungen treffen. Gerade bei einer agilen Herangehensweise kann und wird es aber immer nötige Anpassungen geben – auch das sollte immer immer im Hinterkopf behalten werden.
Erfahren Sie hier mehr über Lösungen im Bereich Data Management oder besuchen Sie eines unserer kostenlosen Webinare.
