Graph-Datenbank für Machine Learning nutzbar machen

Der Graph wird aus einer SQL-Datenbank gespeist und soll flexible Abfragen ermöglichen, um Daten an Entwicklungsumgebungen weiterzugeben. Damit stellt sich eine Frage, die vor jeder Modellierung geklärt sein muss: Enthält der Graph dieselbe Information wie die Quelle – oder ist bei der Übertragung etwas verloren gegangen?

Solange das offen ist, sind alle Modellergebnisse aus dem Graphen unter Vorbehalt. Ein Graph, der 98 Prozent der Quellinformation enthält, sieht in jeder Abfrage vollständig aus.

Ein Neo4j-Wissensgraph, gespeist aus einer relationalen SQL-Datenbank. Ergänzend war die Integration von Wetterdaten vorgesehen, die in der SQL-Datenbank nicht abgedeckt waren.

Eine komplexe Graphstruktur in verallgemeinerter Form dokumentieren. Die Struktur nachvollziehbar zu beschreiben, sodass auch jemand ohne Projektkenntnis damit arbeiten kann, war eine eigene Aufgabe.

Fehlende Abfragestandards. Standardabfragen und Aliase für die Entitäten mussten erst definiert und dokumentiert werden – ohne sie schreibt jeder Nutzer seine eigenen Abfragen, mit unterschiedlichen Ergebnissen bei derselben Frage.

Verifizierung über ein gemeinsames Vergleichsformat. Wir haben Daten aus der SQL- und der Graph-Datenbank in dasselbe tabellenbasierte Format exportiert und dadurch einen vollständigen Vergleich beider Datenbanken möglich gemacht. Abweichungen haben wir bis zu ihrer Ursache zurückverfolgt und daraus Empfehlungen für Schemaänderungen abgeleitet, damit künftig keine Informationen verloren gehen.

Abfragen vereinheitlichen. Für die Datenextraktion haben wir Richtlinien, Abfragevorlagen und Standard-Aliase definiert. Damit liefert dieselbe Frage dasselbe Ergebnis, unabhängig davon, wer sie stellt.

Schnittstelle zu den Entwicklungsumgebungen. Als Anbindung an externe Umgebungen haben wir einen Python-BOLT-Treiber in eine Machine-Learning-Pipeline integriert, sodass der Graph aus Python und R heraus gelesen und geschrieben werden kann.

Entstanden ist unter anderem ein Empfehlungskatalog: Änderungen an Syntax und Datentypen, Schemaanpassungen zur Beschleunigung häufiger Abfragen, Datenbankoptimierungen, Korrekturen möglicher Schema-Deadlocks sowie die Integration von Wetterdaten und weiteren Quellen.

Dazu eine Python- und R-Pipeline als Schnittstelle zu den Entwicklungsumgebungen. Durch die Einbindung in Analysewerkzeuge kann der Graph bei Bedarf abgefragt werden – die Ergebnisse fließen in das Training von Machine-Learning-Modellen und werden direkt auf weitere Daten angewandt.

Der Abgleich einer abgeleiteten Datenbasis gegen ihre Quelle ist eine der unterschätzten Aufgaben in jedem Datenprojekt. In der pharmazeutischen Forschung betrifft das jede Datenbasis, die aus ELN- und LIMS-Systemen abgeleitet wird und Grundlage von Auswertungen werden soll.

Der manuelle Abgleich über ein gemeinsames Exportformat wäre heute automatisiert. Schemata werden als Code versioniert, und Werkzeuge für Datenvergleich und Datenqualitätstests laufen in der CI mit – ein Verlust an Information bei der Übertragung fällt dann bei der Änderung auf und nicht Monate später in einer Auswertung. Für Herkunft und Abhängigkeiten setzen wir heute auf Lineage-Werkzeuge nach dem OpenLineage-Standard statt auf manuell gepflegte Dokumentation. Die Abfragestandards, die wir damals als Richtlinien und Aliase definiert haben, wären heute ein semantischer Layer oder ein Feature Store, aus dem sich Modelle direkt bedienen. Und der Graph selbst hat eine neue Rolle bekommen: Ein Wissensgraph mit sauber definierten Entitäten ist inzwischen die Grundlage dafür, dass Sprachmodelle verlässlich auf Unternehmensdaten zugreifen können; der Aufwand, den wir damals in Schemaqualität und Alias-Definitionen gesteckt haben, zahlt sich in dieser Anwendung ein zweites Mal aus.