In diesem Beitrag geht es darum, wie man Data Lineage mit dem ODI 12c umsetzen kann. Der Beitrag richtet sich u. a. an diejenigen, die den Ursprung ihrer Daten im DWH nicht mehr nachvollziehen können und vielleicht auch das Vertrauen in die Kennzahlen verloren haben.
Data Lineage beschreibt das Zurückverfolgen der Daten vom Ziel bis zur Quelle. Da ein DWH in den meisten Fällen aus mehreren komplexen ETL-Prozessen besteht, ist oft schwer nachzuvollziehen, aus welchen Quelldaten, Daten aus dem Frontend abgeleitet wurden. Bei der Umsetzung von Data Lineage profitiert man u. a. von einem erhöhten Vertrauen der Endanwender in die Daten im DWH. Weitere Vorteile, die sich aus einer Umsetzung ergeben, finden sich z. B. hier: Lineage tracing for general data warehouse transformations.
Für ein Kunden-DWH, das aus diversen komplexen ETL-Strecken besteht, wurde ein Prototyp zur Visualisierung, der Herkunft der Daten erstellt. Da die ETL-Strecken mithilfe des Oracle Data Integrator 12c entwickelt worden sind, wurde auch zum Abgreifen der Metadaten und zur Entwicklung des Prototyps die von Oracle zur Verfügung gestellte Java SDK genutzt.
Mithilfe der SDK wird eine Schnittstelle zum ODI entwickelt, welche die Metadaten ausliest und diese so aufbereitet, dass diese sinnvoll in einer Graphendatenbank, in diesem Fall Neo4J, gespeichert werden können. Dabei ist die Schnittstelle so implementiert, dass diese universell für jedes Projekt, das mit dem ODI entwickelt wird, verwendet werden kann. Die Daten werden einmal aus dem ODI geladen und bereitgestellt. Nach Ü„nderungen sollen die Daten aus dem ODI neu geladen werden.
Die Daten in der Graphendatenbank werden mithilfe von D3js im Browser visualisiert. Dabei wird dem Nutzer eine Suchoption geboten, um sich nur die gewünschten Objekte darstellen zu lassen. Komponenten, die sich im selben Mapping befinden, werden „gehighlightet“, somit wird der Fluss der Daten transparent. (Für eine Defintion der ODI typischen Begriffe sei hier auf den Developers Guide für den Oracle© Data Integrator verwiesen.) Außerdem werden detaillierte Informationen zu den Komponenten visualisiert, wobei zwischen verschiedenen Typen unterschieden wird. So wird z. B. zwischen Join- und Expression-Komponenten differenziert. Ferner wird bei Join-Komponenten der Jointyp dargestellt. Die Transformationen lassen sich daher besser nachvollziehen.
Diese Lösung bietet im Gegensatz zum OEMM 12c eine leichte Anpassbarkeit und Erweiterbarkeit sowie eine moderne Visualisierung.
