| von Alexandra Terwey

Relevanz historisierter und skalierbarer Datenarchitekturen für ML und KI

In einer Zeit, in der die Anzahl an Datenquellen und die Menge an gesammelten Daten stetig steigen, ist es wichtig diese Daten möglichst effizient zu verarbeiten. Unabhängig davon, ob die Daten später für Datenanalysen, künstliche Intelligenz oder maschinelles Lernen verwendet werden sollen, um den Wert der Daten unserer Kunden voll auszuschöpfen, bedarf es an robusten, höchst skalierbaren und historisierten Datenarchitekturen. Diese ermöglichen uns nicht nur tiefe Einblicke in die Daten selbst zu gewinnen, sondern liefern auch Flexibilität in der Datenhaltung für zukünftiges Wachstum und wechselnde Anforderungen.

Die beste Datengrundlage ist eine, welche nicht nur angepasst und erweitert werden kann, sondern zusätzlich noch ein eigenes Langzeitgedächtnis besitzt.

In diesem Beitrag möchte ich kurz auf einige Schlüsselkonzepte eingehen, welche im Kern für eine robuste und historisierte Datenarchitektur notwendig sind, auf der wir mit Machine Learning Anwendungen aufsetzen können und welche die die Grundlage für künstliche Intelligenz bildet.

Data Lakehouse Architektur
Figure 1: schematische Übersicht einer möglichen, skalierbaren Data Lakehouse Architektur.

Die Rolle eines Data Vault in Modernen Data Lakehouse Architekturen

Data Vault (wörtlich übersetzt „Daten Tresor“) ist eine Methodik, welche konzipiert wurde, um jedwede Datenänderung nachzuverfolgen. Sie dient, wie der Name schon impliziert, als das sichere Langzeitgedächtnis in einer Datenlandschaft. Die Designprinzipien der Data Vault Modellierung machen sie zu einem vielseitigen Werkzeug, mit der Option das Datenmodell zu skalieren und anzupassen, je nachdem, wie sich die Anforderungen an die Daten ändern. Die Data Vault Modellierung dekonstruiert komplexe Abhängigkeiten zwischen Daten und liefert dahingehend Flexibilität und Reduktion von Redundanz, welche in anderen Modellierungsformen so nicht gegeben ist. Data Vault kann als hybrider Ansatz zwischen einer Modellierung nach 3NF und Sternschema gesehen werden.[1]

Ein Data Vault besteht hauptsächlich aus einer Vielzahl der folgenden drei Kernkomponenten:

  1. Hubs – Ein Hub speichert eindeutige Business Schlüssel.
  2. Links – Verbinden verschiedene Hubs miteinander.
  3. Satelliten – Speichern deskriptive und historische Daten.

Obwohl das Konzept des Data Vault schon seit mehr als zwei Jahrzehnten existiert, fügt es sich immer noch sehr gut in die modernen Konzepte von Cloud basierten Datenarchitekturen und insbesondere Data Lakehouse Konzepte ein.

Anstatt Daten in einem traditionellen Data Warehouse zu speichern, ist ein Data Vault in einer Schicht eines cloud-nativen architektonischen Konzepts verortet, wo er direkt aus dem Data Lake befüllt wird und auf der anderen Seite als Grundlage für weitere semantische Schichten für Business Anwendungen dient.

Die Implementierung innerhalb einer cloud-basierten Architektur ermöglicht es ein hohes Volumen an Daten zu prozessieren und bietet nahezu endlosen Speicherplatz.

In der Regel wird ein Data Vault zweistufig mit einem Raw Vault und einem Business Vault implementiert. Die erste Stufe dekonstruiert die Daten ohne destruktive Transformationen und ohne Business Logik, in der zweiten Stufe ist die Modellierung und Aggregation anhand der Businessanforderungen und benötigten KPIs aufgebaut.

Bereitstellung von Business Daten – Data Marts

Mit dem Data Vault als Grundlage für die Business Logik, stellt ein Data Mart die Daten, normalerweise modelliert im Sternschema, historisch korrekt aufgearbeitet bereit. Ein Data Mart besteht aus einer Modellierung einer Vielzahl zweier Objekte[2]:

  1. Fakten – Speicher operationaler Daten, wie z.B. Verkaufstransaktionen.
  2. Dimensionen – Normalisierte und deskriptive Daten, historisiert.

Berichtsanwendungen für verschiedene Business Einheiten werden in der Regel auf Basis des Data Marts erstellt und ermöglichen Datenabfragen speziell nach dem Bedarf der entsprechenden Fachbereiche.

Historisierung

Der wichtigste Punkt im Hinblick darauf den Daten ein Langzeitgedächtnis zu ermöglichen und die Daten historisch akkurat zu halten, ist es, eine solide und einheitliche Historisierung über die verschiedenen Architekturschichten hinweg zu implementieren.

Wichtig hierbei ist es, beim Design der Architektur und Implementierung der Datentransformationen direkt von Anfang an Logging zu implementieren. Datenquellen, die bei der Erzeugung bereits Zeitstempel generieren sind das Beste, was einer Datenplattform passieren kann. Wenn Datenquellen keine Zeitstempel selbst erzeugen, dann müssen diese, sobald die Daten in der Datenplattform ankommen, direkt generiert werden. Wichtig ist es auch ein Konzept für die Speicherung von Metadaten zu implementieren, um jeden Schritt durch jede Schicht der Architektur nachverfolgen zu können.

Die Implementierung einer robusten change data capture (CDC, Verspeicherung nur bei Datenänderung) kann dabei helfen Datenredundanz zu reduzieren und nur echte Änderungen in die tabellarisch aufgebauten Schichten der Plattform weiterzuleiten.

Unwissenheit darüber, wann Daten erzeugt wurden, ist eines der häufigsten Probleme, die bei dem Aufbau und der Befüllung einer Datenplattform auftreten.

Eine Möglichkeit der Historisierung, welche innerhalb der oben genannten Modellierungstechniken (Data Vault und Data Mart) verwendet werden kann, ist die Historisierung nach dem sogenannten SCD2 Typ (slowly changing dimension type 2)[3].

SCD2 Historisierung bewahrt die komplette Historie einer Datenzeile über alle Zeitperioden, während ein Datensatz existiert, auf. An jeder Zeile gibt es zu einem eindeutigen Business Schlüssel einen Gültigkeitsmarker („is_current“) und eine Gültigkeitszeitspanne („valid_from“, „valid_to“).

Im untenstehenden Beispiel einer Produkt Tabelle ist jegliche Änderung zu einer gegebenen eindeutigen id (hier der eindeutige Business Schlüssel) abgebildet. Wird nun ein neuer Satz zu einer id für einen merge in die Tabelle bereitgehalten, prozessiert die SCD2 Historisierung den Satz auf folgende Art und Weise: Zunächst gibt es einen Abgleich, ob sich der Datensatz geändert hat. Wenn ja, dann wird der bestehende Satz in der Zieltabelle fachlich abgeschlossen und das Zeitintervall mit dem Zeitstempel des neu ankommenden Datensatzes beendet. Der Gültigkeitsmarker wird beim bereits in der Tabelle vorhandenen Satz invalidiert und der neue Satz eingefügt. Die Gültigkeitszeitspanne des neu eingefügten Satzes ist nun unendlich, bis der Satz entweder ein Update erhält, oder fachlich gelöscht wird. Im Falle einer Löschung erhält der Satz ein endliches „valid_to“ (Zeitpunkt der Löschung) und der Validitätsmarker wird auf „false“ gesetzt. Das Loggen der entsprechenden merge Operationen (insert/update/delete) an jeder Zeile kann zusätzlich sinnvoll sein.

SCD2 historisierte Tabelle
Figure 2: SCD2 historisierte Tabelle einer Produktauflistung mit Preisinformationen.

SCD2 historisierte Tabellen sind der Ausgangspunkt für weitere Analysen und point in time Sichten verschiedener verknüpfter Tabellen.

Befüllung von Point-In-Time Tabellen anhand des Unified Timeline Ansatzes

Da sich die Anforderungen an Daten für Machine Learning von denen für z.B. Berichtsanwendungen unterscheiden, müssen sie anders aufbereitet und bereitgestellt werden.

Wenn ein Machine Learning Algorithmus eine flache Tabelle an Trainingsdaten benötigt, sollte das Data Science Team in der Lage sein die Daten, historisch korrekt, aus der Datenplattform zu extrahieren. Hier soll es zunächst nicht relevant sein, ob dies schon im Raw Vault, Business Vault, oder erst im Data Mart geschieht.

Die einzelnen modellierten Business Objekte im Vault oder Mart können anders strukturiert und modelliert sein, als es für einen Machine Learning Algorithmus notwendig ist. Dies zeigt die Notwendigkeit einer Methodik einen Satz an Daten außerhalb dieser Business Logik und Aggregationen zusammenzuziehen. Die Möglichkeit sich Trainingsdatensätze zu erzeugen, welche zeitlich vor- und rückdatiert werden können ist von unschätzbarem Wert im Hinblick auf die Erzeugung von Trends und Vorhersagen, sowie das Nachtrainieren von Modellen mit variierenden Features und dahingehend einer akkuraten Modellversionierung.

Um nun Trainingsdaten aus multiplen SCD2 historisierten Tabellen zu erzeugen, müssen diese Tabellen über ihren vollständigen zeitlichen Kontext verknüpft werden. Effektiv wird dabei eine Point-In-Time Tabelle erzeugt. Solch eine Verknüpfung auf einem einheitlichen Zeitstrahl bedarf eines gemeinsamen Business Schlüssels, der den Satz eindeutig identifiziert.

Untenstehend ist ein SQL-Beispiel aufgezeigt, welches die oben beschriebene Produkttabelle (s. Fig2) mit einer Tabelle verknüpft, welche die Lagerstätten zu den entsprechenden Produkten zeigen (s. Fig3).

SQL-Beispiel
Figure 3: SCD2 historisierte Tabelle für die Lagerstätten der Produkte.

Der eindeutige Business Schlüssel für die Lagertabelle ist gleich dem für die Produkttabelle. Die resultierende Point-In-Time Tabelle muss die vollständige Historie der Produkte und ihrer Lagerstätte abbilden.

%sql
with
    unified_timeline as (
        select id, timestamp, valid_from from products
        union
        select id, timestamp, valid_from from warehouse
    ),
    unified_timeline_recalculate_valid_to as (
        select
            id,
            timestamp,
            valid_from,
            coalesce(
                lead(valid_from) over(partition by id order by valid_from),
                '9999-12-31 23:59:59'::timestamp
            ) as valid_to,
            valid_to = '9999-12-31 23:59:59'::timestamp AS is_current
        from unified_timeline
    ),

    joined as (
        select
            timeline.id,
            products.product_name,
            products.price,
            products.category,
            warehouse.location,
            warehouse.facility,
            timeline.timestamp,
            timeline.valid_from as valid_from,
            timeline.valid_to as valid_to,
            timeline.is_current
        from unified_timeline_recalculate_valid_to as timeline
        left join products
            on timeline.id = products.id 
            and products.valid_from <= timeline.valid_from 
            and products.valid_to >= timeline.valid_to
        left join warehouse
            on timeline.id = warehouse.id 
            and warehouse.valid_from <= timeline.valid_from 
            and warehouse.valid_to >= timeline.valid_to
    )
select * from joined order by id, timestamp asc

Das Erzeugen einer “Unified Timeline“ bedeutet, dass jede mögliche Zeitperiode, zu der der entsprechende Schlüssel existiert, notiert wird. Die Gültigkeitsintervalle werden entsprechend des Joins der beiden Tabellen, Produkt und Lager an den neuen Zeitstrahl, nachkalkuliert und entsprechen den einzelnen Zeitscheiben [4] zu denen die Sätze beider Tabellen gemeinsam existieren. Durch den join sind die beiden Tabellen historisch korrekt miteinander verbunden, ohne zeitliche Lücken zu erzeugen. Jede Datenänderung aus jeder Tabelle entspricht einem einzelnen Eintrag in der finalen Tabelle (s. Fig 4).

Unified timeline joins
Figure 4: Resultat eines unified timeline joins mit allen Zeitintervallen und ihrer entsprechenden Gültigkeit.

Die finale historisierte Tabelle kann dann entweder direkt für das Training oder zur Vorhersage an einen Machine Learning Algorithmus weitergegeben, oder z.B. in eine Vektordatenbank geschrieben werden, wo andere Modelle auf die historisierten Daten zugreifen können.

Transformer basierte Modelle benötigen qualitativ hochwertige und akkurate Daten, um korrekt trainiert zu werden. Daten aus Point-In-Time Tabellen ermöglichen es, dass diese Modelle Zusammenhänge korrekt erlernen und temporalen Kontext richtig abbilden, was die Qualität des Endproduktes erhöht.

Schlussendlich ist es unabhängig des finalen Anwendungsszenarios wichtig, dass eine solide Historisierung den Wert der Daten erhöht. Dazu bedarf es einer flexiblen und skalierbaren Datenarchitektur.  Sie ist der Schlüssel und die Grundlage, Daten in hoher Qualität zu halten, neue Datenprodukte zu erzeugen und kontinuierlich Mehrwert aus diesen zu generieren.

Quellen

[1]https://tdan.com/data-vault-series-1-data-vault-overview/5054
[2]https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/fact-table-structure/
[3]https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/type-2/
[4]https://infinitelambda.com/multitable-scd2-joins/

Teile diesen Artikel mit anderen

Über den Autor

Alexandra Terwey ist Senior Consultant bei der Woodmark Consulting AG. Mit einem Hintergrund in experimenteller Physik hat sie sich mittlerweile auf Data Engineering spezialisiert und arbeitet an flexiblen Datenarchitekturen von der Quelle bis zur Anwendung.

Zur Übersicht Blogbeiträge