Ein tiefes Verständnis der Beziehungen zwischen Daten ist ein mächtiges Werkzeug

Die Macht von Beziehungen zwischen Daten

Werner Vogels

© Shutterstock / Masterlevsha

Daten sind das neue Gold – dieser Spruch ist mittlerweile Allgemeingut geworden. Mit welchen Datenbank-Technologien Amazon aufwartet – und auch seine eigenen internen Prozesse unterstützt -, beschreibt Amazon CTO Werner Vogels in dieser Kolumne. Insbesondere spielt dabei die Graphendatenbank Amazon Neptune eine Hauptrolle.

Die Macht von Beziehungen zwischen Daten

Wurden Sie beispielsweise schon jemals von ihrer Bank angerufen, weil betrügerische Aktivitäten vermutetet wurden? Die meisten Banken erkennen diese automatisch. Weicht das Muster wie und wo Geld ausgegeben wird, vom Normallfall ab, treten sie unmittelbar in Aktion. Oft geschieht das sogar, bevor die Opfer überhaupt bemerken, dass irgendetwas nicht stimmt. Folgen eines potentiellen Identitätsdiebstahls können dadurch für den Kunden abgewehrt werden.

Ein weiteres Beispiel ist das Verhältnis von Informationen über Krankheiten und Genen. Wer die zugrunde liegenden Zusammenhänge versteht, kann auch nach Mustern in der Wechselwirkung von Proteinen suchen. So findet ein Genetiker auch weitere Gene, die mit einer Krankheit eventuell im Zusammenhang stehen, was weitere Forschungsbemühungen unterstützt.

Dabei gilt: Je tiefer die Zusammenhänge von Daten verstanden werden, um so aussagekräftiger sind die daraus gewonnen Erkenntnisse. Mit genügend verknüpften Datenpunkten lassen sich sogar Vorhersagen über die Zukunft treffen, vergleichbar mit einem Empfehlungssystem (einer „recommendation engine“). Aber je mehr Daten verbunden sind und die Menge und Komplexität der verbundenen Daten wächst, umso komplizierter wird es, die Beziehungen der Daten zu speichern oder abzufragen.

Moderne Applikationen setzen zunehmend auf verteilte, unabhängig voneinander arbeitende Systeme, die als Service rund um Geschäftsanforderungen strukturiert sind („Microservices“). Solche Applikationen nutzen entkoppelte Datenspeicher, bei der eine Eins-zu-Eins-Beziehung zwischen einem Service und seiner Datenbank herrscht, statt eine zentrale Datenbank für alles zu nutzen. Daher ist es wichtig, von monolithischen „Allzweck“-Datenbanken wegzukommen und auf zweckoptimierte Datenbanken umzuschwenken.

Diese für bestimmte Zwecke entworfene Datenbanken unterstützen verschiedene Datenmodelle und ermöglichen es Kunden, fallbedingte, hoch skalierbare und verteilte Anwendungen zu entwickeln. Stark vernetzte Daten sind ein gutes Beispiel dafür, warum es wichtig ist, das richtige Werkzeug für ein spezielles Problem zu haben. In diesem Fall ist eine Graphen-Datenbank genau das richtige Hilfsmittel für stark vernetzte Daten.

Graphen-basierte Datenmodelle

In Graphen-basierten Datenmodellen sind die Beziehungen der Datenpunkte Kern des Datenmodells. Sie lassen sich mit Graphen direkt darstellen, anstatt erst Fremdschlüssel zu verwenden oder Tabellen miteinander zu verbinden. Die Daten sind dabei als Knoten (oder Ecken) und Verbindungen (Kanten) modelliert.

Die Knoten symbolisieren für gewöhnlich eine Person, einen Ort oder einen Gegenstand. Die Kanten stellen Zusammenhänge zwischen ihnen dar. In Abbildung 1 sind Bob, die Mona Lisa und das Louvre jeweils ein Knoten. Sie sind über verschiedene Beziehungen verbunden. Zum Beispiel interessiert sich Bob für die Mona Lisa. Diese befindet sich im Louvre. Ein solcher Graph ist ein Beispiel für einen Wissens-Graphen („knowledge graph“). Er unterstützt Anwender, die sich für die Mona Lisa interessieren, dabei, auch andere Kunstwerke von Leonardo da Vinci im Louvre zu entdecken.

Abb. 1

Anwendungen verarbeiten Beziehungen

Wie das vorangegangene Beispiel des Wissen-Graphen zeigt, sind Graphen eine gute Wahl, wenn es darum geht, die Beziehung zwischen Daten zu verstehen und schnell abzufragen. Es gibt jedoch noch weitere Einsatzfelder:

Soziale Netzwerke

Anwendungen für soziale Netzwerke müssen eine große Menge von Nutzerprofilen und Interaktionen verfolgen. Entwickler können beispielsweise einen Social Media Feed in ihre Anwendung einbauen. Mit einem Graphen können sie den Nutzern Aktualisierungen anzeigen, die nach Relevanz priorisiert wurden: Zum Beispiel Aktualisierung von ihrer Familie oder von Freunden, deren Neuigkeiten sie mögen oder in deren Nähe sie wohnen.

Abb. 2

Empfehlungssysteme (Recommendation Engines)

Empfehlungssysteme speichern die Beziehungen zwischen Informationen, wie über Kundeninteressen, Freunde oder gekaufte Produkte. Mit einem Graphen lassen sich die Beziehungen schnell abfragen, um personalisierte und für den Anwender relevante Empfehlungen zu geben.

Abb. 3

Beispiel Betrugserkennung

Ein Graph kann außerdem dazu beitragen, Betrugsfälle, beispielsweise für den Online-Einzelhandel, zu erkennen. Mit ihm können Abfragen entwickelt werden, mit denen ganz einfach Muster in den Datenbeziehungen entdeckt werden können. Ein Beispiel für verdächtige Muster sind mehrere Personen, die mit der selben persönlichen E-Mail-Adresse verknüpft sind, oder verschiedene Personen, die die selbe IP-Adresse nutzen, aber verschiedenen Adressen haben.

Abb. 4

Die Herausforderung, Graphen zu speichern

Ein Problem ist jedoch das Speichern von Graphen. Dabei gibt es verschiedene Möglichkeiten: als relationale Datenbank, als eine Key-Value-Datenbank oder als eine Graphdatenbank. Viele Nutzer verwenden einen Prototyp in kleinen Maßstab, wenn sie mit Graphen starten. Das funktioniert anfangs normalerweise gut. Die Herausforderungen steigen aber mit der Datenmenge.

Graphen-basierte Anwendungen weisen in der Regel einen hohen Grad an zufälligem Zugriff auf. Die Anzahl der besuchten Knoten nimmt erheblich zu, wenn Anwender Beziehungen durchlaufen (Graph-Fan-Out). Außerdem werden die Daten, die für die Beantwortung einer Graphenabfrage erforderlich sind, oft nicht im Arbeitsspeicher zwischengespeichert (nicht-lokaler Zugriff).

Zudem verlangen selbst scheinbar einfache Abfragen in einem Graphen nach dem Zugriff und der Durchsuchung großer Datenmengen. So erfordert das Skalieren und der Betrieb von Graphdatenbanken häufig einen hohen manuellen Aufwand für Anpassungen und Leistungsoptimierung.

Anwender, die für Graphen relationale Datenbanken oder eine Key-Value-Datenbank verwenden, müssen SQL-Joins oder ein entsprechendes Verfahren nutzen, um Beziehungen zwischen Daten abzufragen. Diese Joins auszuführen, benötigt jedoch Zeit. Daher müssen die Anwender häufig ihr Datenmodell denormalisieren. Dadurch erhöht sich die Leseleistung auf Kosten der Schreibleistung. Ein denormalisiertes Datemodell bedingt jedoch für jede neue Beziehung eine Änderung des Datenmodells und verzögert dadurch die Entwicklung von Anwendungen.

Eine speziell für Graphen entwickelte Datenbank

Mit Amazon Neptune stellte Amazon Web Services (AWS) 2017 eine Graphdatenbank vor, die sich dafür eignet, Beziehungen in stark miteinander verwobenen Daten zu verarbeiten. Neptune ist ein voll verwalteter Dienst für Graphdatenbanken. Für eine hohe Verfügbarkeit repliziert er sechs Kopien der Daten in drei Verfügbarkeitszonen. Dabei unterstützt er bis zu 15 Lese-Replikas mit niedriger Latenz. Graphen können so mit einer niedrigen Latenz im Millisekundenbereich abgefragt werden. Neptune skaliert den Speicherplatz automatisch, um Milliarden von Beziehungen zu speichern.

AWS hat den Dienst seit seiner Vorstellung kontinuierlich weiterentwickelt. So wurde auf der AWS re:Invent 2019 die Amazon Neptune Workbench, eine „Werkbank“ für Neptune angekündigt. Anwender können damit aus der AWS-Konsole heraus ein Jupyter Notebook anlegen: Diese Open-Source-Anwendung ermöglicht es, Dokumente mit Live-Code, Gleichungen, Visualisierungen und Text zu erzeugen und zu teilen. Sobald das Notebook angelegt ist, können Anwender Graphdatenbanken mithilfe der Gremlin- oder der SPARQL-Sprache (ehem. RDF Query Language) abfragen. Seit kurzem unterstützt Neptune auch Streams und Text-Suche, um die Verbindung von Graphen mit anderen Software-Bausteinen zu vereinfachen.

Neptune Streams erleichtert es, Änderungen im Graphen zu erfassen und Graphen mit anderen spezialisierten Datenbanken zu integrieren. Falls zusätzlich zum Graphen eine Text-Suche verwendet wird, erlaubt es Neptune außerdem, externe Text-Indizes für Gremlin- oder SPARQL-Graphabfragen zu nutzen.

Bei der Entwicklung von Neptune dachte Amazon Web Services zunächst vor allem an soziale Medien, das Erkennen von Betrugsmustern oder Empfehlungs-Lösungen. Kunden wie Nike, Activision und NBC Universal verwenden tatsächlich auch solche Anwendungen auf Neptune-Basis.

Allerdings finden Entwickler auch zahlreiche neue Anwendungsmöglichkeiten, wenn man ihnen performante, spezialisierte Tools für bestimmte Aufgaben gibt. Kunden haben gezeigt, wie sie mit Graphen interessante neue Anwendungen entwickeln können – von Wissens-Graphen bis zur Auflösung von Identitäts-Beziehungen. So verwendet Thomson Reuters Graphen, um komplexe regulatorische Modelle zu verstehen. Netflix verbessert die Zuverlässigkeit seiner Dateninfrastruktur durch ein auf Graphen basierendes System. Damit entwickelt das Unternehmen skalierbare Lösungen, um die Herkunft von Daten zu verwalten. Zeta Global hat eine Kunden-Analytik-Plattform aufgebaut, die mit einer Graphen-basierten Identitäts-Auflösung verschiedene Geräte und Nutzer in Beziehungen setzt.

Langzeitperspektive: Zwei Modelle unterstützen

Graphdatenbanken lassen sich auf zwei Wegen implementieren: als Property-Graphen (PG) und auf Basis des W3C Resource Description Framework (RDF). Beide Verfahren haben ihre Berechtigung. Gute Lösungen ermöglichen das flexible Umschalten zwischen beiden Methoden.

Beide Modelle nutzen Knoten und gerichtete Verbindungen. Und in beiden können Eigenschaften (Attribut-Werte-Paare) Knoten zugeordnet werden. Bei Property-Graphen ist diese Zuordnung auch für Kanten möglich, während RDF-basierte Graphen die Eigenschaften von Knoten einfach als weitere Kanten behandeln. Allerdings gibt es auch verschiedene Technologien, um Kanten-Eigenschaften in RDF darzustellen. Aufgrund dieser Eigenheiten unterscheiden sich die Datenmodelle in den jeweiligen Graphdatenmodellen im Endergebnis geringfügig.

Für diese Unterschiede gibt es gute Gründe. Property-Graphen ähneln konventionellen Datenstrukturen in einer isolierten Anwendung oder einem isolierten Anwendungsszenario. RDF-Graphen wurden dagegen ursprünglich dafür entwickelt, die Interoperabilität und den Austausch zwischen unabhängig voneinander entwickelten Anwendungen zu unterstützen. RDF-Graphen können auch dreigeteilt dargestellt werden, indem man den Startpunkt der Kante (typischerweise Subjekt genannt), das Label (Prädikat) und der Endpunkt (Objekt) angibt. RDF-Graphdatenbanken heißen daher auch Triple Stores.

Beide Methoden werden häufig eingesetzt: Aktuell unterstützen weit verbreitete Open-Source- oder von Herstellern unterstützte Implementierungen Property-Graphen. Allerdings gibt es dafür keine offenen Standards für Schema-Definition, Abfragesprachen oder Datenaustauschformate. RDF ist dagegen Teil einer Reihe von W3C-Standard-Spezifikationen, die auf anderen gültigen Web-Standards aufbauen und gemeinsam als das Semantische Web oder Linked Data bezeichnet werden. Zu diesen Standards gehören etwa Schemasprachen (RDFS und OWL) oder deklarative Abfragesprachen (SPARQL), Serialisierungsformate sowie eine Vielzahl von unterstützenden Spezifikationen. Diese ermöglichen zum Beispiel auch das Mapping von relationalen Datenbanken in RDF-Graphen. Die W3C-Spezifikationen unterstützen ebenso ein Standard-Framework für Inferenz, also Methoden, um aus Daten, die als Graph dargestellt werden, Schlussfolgerungen zu ziehen.

Unsere Erfahrung ist, dass Entwickler letztendlich einfach Graphen bauen wollen und dass sie dafür beide Modelle benötigen. Einige unserer Kunden beginnen zum Beispiel mit einer isolierten Anwendung in einem Property-Graph. Dann stellen sie aber fest, dass sie mit anderen Systemen interoperieren müssen. Andere Anwender starteten mit der Entwicklung für die Interoperabilität und den Austausch mit RDF. Dann mussten sie aber unabhängige, für einen Geschäftsprozess individuelle Anwendung aufbauen und im Speicher ausgerichtete Daten in Property-Graphen umwandeln. Wir haben daher bewusst die Entscheidung getroffen, mit Neptune sowohl Property-Graphen als auch RDF zu unterstützen, damit Entwickler jederzeit wählen zu können, welcher Ansatz sich für welche Aufgabe am besten eignet.

Bausteine zusammenführen

Die innovativen Anwendungen, für die unsere Kunden Neptune nutzen, sind Beispiele dafür, was passiert, wenn Entwickler die richtigen Werkzeuge für ihre Aufgaben haben. Aus diesem Grund hat AWS die größte Auswahl an spezialisierten Datenbanken: damit Entwickler mehr Wahlmöglichkeiten und mehr Freiheiten haben. Über Graphen hinaus können Kunden auch Daten haben, für die sich andere Arten von Datenbanken wie relationale, Zeitreihen- oder In-Memory-Datenbanken besser eignen. Und das ist auch gut so – denn darauf baut zeitgemäße Anwendungsentwicklung auf.

Als weiteres Beispiel ist Neptune etwa Teil des Toolkits, mit dem wir den Wissens-Graphen von Alexa kontinuierlich für mehrere zehn Millionen Kunden erweitern. Alexa nutzt darüber hinaus andere Datenbanken wie Amazon DynamoDB für Key-Value- oder Dokument-Daten und Amazon Aurora für relationale Daten. Verschiedene Daten kommen mit unterschiedlichen Herausforderungen, und die Wahl der richtigen Datenbank für jedes Anwendungsszenario erlaubt mehr Geschwindigkeit und mehr Flexibilität.

Geschrieben von
Werner Vogels
Werner Vogels
Werner Vogels ist Chief Technology Officer (CTO) und Vizepräsident von Amazon.com. Werner bloggt unter https://www.allthingsdistributed.com.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: