Kürzlich hatte ich eine Diskussion mit einigen Architekten, die für eines der größten Krankenversicherungs-Systeme in den USA arbeiten. Sie interessierten sich für die Aggregation ihrer unzähligen Silos mit medizinischen Daten (Gesundheitsdaten) und wollten diese Integration durch die Umwandlung der Daten in über 100 Milliarden semantische Tripel erreichen. Hier unser Vorschlag:

Als ich mit dem Projekt begann, wollten die Architekten des Unternehmens semantische Tripel verwenden, um die in Silos gespeicherten Petabyte von Daten zueinander in Beziehung zu setzen. Ob das sinnvoll war, sei dahingestelltnbsp– wir mussten jedenfalls herausfinden, wie man dieses Vorhaben realisieren kann. Rein hypothetisch bedeutete das: Wenn die Systeme 500 Millionen Datensätze und 200 Elemente pro Datensatz speicherten, würde das Team am Ende bis zu 100 Milliarden Trippel erhalten. Unter Governance-Aspekten wären die daraus resultierenden Datensätze nur sehr schwer zu verwalten (weil alle für Menschen verständlichen Datensätze „geschreddert“ würden). Entsprechend schlecht wäre die Performance und auch die Implementierung würde sich hinziehen.

Nachdem unser Team bei MarkLogic sich mit den Integrationsanforderungen vertraut gemacht hatte, schlugen wir eine Architektur vor, die stattdessen ein kombiniertes Dokumenten- und Semantik-Modell verwendet. Diese Multi Model Architektur würde mit erheblich weniger Objekten in der Datenbank auskommen. Genauer gesagt, wären es nur 500 Millionen Dokumente und vielleicht eine ähnliche Anzahl Tripel, die mit diesen Dokumenten verknüpft wären. Diese kombinierte Architektur wäre wesentlich leistungsstärker, besser skalierbar und von der Time-to-Market her schneller. Zudem würde eine bessere Governance gewährleistet. Werfen wir einmal einen genaueren Blick auf unseren Vorschlag.

Ausgangspunkt

Wie viele Anbieter im Gesundheitswesen hatte auch dieser Kunde Dutzende, wenn nicht Hunderte von Datensilos, deren Daten sich teilweise überlappten. Und wie viele andere Unternehmen hatte man auch hier stark auf relationale Technologien für die Transaktionsverarbeitung und das Data Warehousing gesetzt. Relationale Datenbanken waren in den letzten 35 Jahren die Eckpfeiler operativer Transaktionsdatenbanken. Ihre wichtigsten Merkmale sind die Transaktionsintegrität, eine hohe Leistung für kleine Transaktionen und Zuverlässigkeit. Das Ablegen von Daten in einer Datawarehouse Datenbank, die nach einem mehrdimensionalen Würfel organisiert ist, wurde populär, weil damit analytische Abfragen bei großen Datenmengen übergreifend über sorgfältig angelegte Dimensionen möglich waren. In letzter Zeit erfreuen sich Graph- und Dokumentendatenbanken zunehmender Beliebtheit. Graphdatenbanken können einfach (abstrakte) Beziehungen darstellen und Berechnungen über sie durchführen. Dokumentendatenbanken wiederum wurden populär, weil sie Dinge der realen Welt auf natürliche Weise repräsentieren können.

Das Hauptproblem von relationalen Datenbanken ist, dass die Daten zuerst modelliert werden müssen. Und das ist recht teuer. Folglich versuchen Unternehmen vorherzusagen, welche Daten benötigt werden, wie diese zueinander in Beziehung stehen und welche Fragen die Daten beantworten sollten.

In dieser Umgebung könnten wir damit nur anwendungsspezifische Datensilos erhalten. In Zeiten, in denen sich alles schnell verändert, wäre das ein Scheitern „mit Ansage“. Wie Sie unten in Abbildung 1 sehen können, führten vor allem ETL-Prozesse und bestimmte anwendungszentrierte Datensätze zu vielen Datensilos für strukturierte Datensätze. Tatsächlich fließen 60 Prozent eines neuen Data-Warehousing-Projekts in ETL-Prozesse. Pro Jahr geben Unternehmen 36 Milliarden US-Dollar für die Erstellung relationaler Datensilos aus. Dazu kommen weitere Silos für unstrukturierte Daten. Berücksichtigt man zudem, wo sich all diese Datensätze befinden, erhält man schnell zigtausend verschiedene Datenquellen oder Speicherorte.

Abbildung 1: Fülle an ETL-Prozessen und Datensilos

Eine andere Art der Betrachtung des Problems ist, dass Unternehmen zwar eine 360-Grad-Sicht auf sämtliche Geschäftsdaten wünschen, aber mehrere Silos für Geschäftsdaten oder Technologien betreiben, wie wir unten in Abbildung 2 sehen können. Dazu kommen dann noch UNZÄHLIGE ETL-Prozesse, um diese Silos zu synchronisieren.

Abbildung 2: Unternemens- und Technologie-Datensilos können nur mit enormem Aufwand synchronisiert werden.

Was Unternehmen brauchen, ist eine zentrale Stelle, um sämtliche Daten Schema-agnostisch verwalten, zueinander in Beziehung setzen sowie zuverlässig und transaktionsorientiert speichern zu können. Eine solche zentrale Stelle muss neben operativen Abläufen auch Analysen unterstützen, und zwar ohne endlose ETL-Zyklen. Stellen Sie sich das wie folgt vor: Wenn Ihre Datenmenge permanent wächst, brauchen Sie dafür eine dauerhafte Bleibe. Ansonsten werden Sie alle Ressourcen Ihrer Organisation dafür ausgeben, Daten von einem Silo in einen anderen zu verschieben. Diese zentrale Stelle bezeichnen wir als „Operational Data Hub (ODH)“.

Merkmale eines Operational Data Hubs (ODH)

Drei verschiedene ODH-Ansätze

Die Herausforderungen, die es beim Erstellen eines Operational Data Hub (ODH) zur Reduzierung von Datensilos zu meistern gilt, habe ich bereits beschrieben. Als Nächstes möchte ich auf nicht-relationale Technologie-Alternativen eingehen. Vor dem Hintergrund der oben genannten Eigenschaften werde ich die Vor- und Nachteile von drei verschiedenen Architektur-Designs für einen Operational Data Hub erörtern:

1. Semantische Tripel-Datenbank/reine Graph-Architektur
2. Architektur mit einer reinen Dokumentendatenbank
3. Multi Model Ansatz, der Dokumenten- und Tripel-Datenbanken kombiniert

1. Semantische RDF-Tripel-Datenbank/reiner Graphansatz

Es gibt zwei verschiedene Datenbanken, die zum Speichern verknüpfter Daten entwickelt wurden: RDF-Tripel-Datenbanken und Graphdatenbanken. Zwischen ihnen gibt es feine Unterschiede. Aber wie mein Kollege Matt Allen es in diesem Thread schon beschreibt, liegt der Schwerpunkt bei Graph- und RDF-Tripel-Datenbanken auf den Beziehungen zwischen den Daten, oft auch als „verknüpfte Daten“ bezeichnet. Datenpunkte werden als „Knoten“ bezeichnet, und die Beziehungen zwischen einem Datenpunkt und einem anderen heißen „Edges“. Aus einem Netzwerk von Knoten und Edges lassen sich interessante Visualisierungen erstellen – ein wesentliches Merkmal von Graphdatenbanken.

Das Design eines Operational Data Hub mit einem „reinen Tripel-Datenbank“-Ansatz bietet eine flexible Methode, um verschiedene Datensilos miteinander zu verknüpfen. Auf die wichtigsten Vorteile und Probleme gehe ich weiter unten ein. Weil eine Graphdatenbank jede Beziehung modellieren kann, erhalten Sie unbegrenzte Flexibilität darüber, wie semantische Tripel organisiert und abgefragt werden. Sie können während der Runtime einfach neue Typen und Beziehungen hinzufügen. Überdies können Sie semantische Tripel über eine wohldefinierte Standardsprache wie SPARQL abfragen. Beim Modelling der gesamten Ontologie und aller Inhalte ist jedoch einiges zu bedenken. Während es sinnvoll ist, die semantischen Konzepte in einer Ontologie als Tripel zu modellieren – weil das ihrer natürlichen Granularitätsebene entspricht –, bedeutet das für das Content-Management auf dieser Ebene einige Herausforderungen.

Reiner Graph-/RDF-Tripel-Datenbankansatz – Vorteile

• Unbegrenzte Flexibilität – Modelle jeder beliebigen Struktur
• Definieren von Typen und Beziehungen während der Runtime
• Beziehungen zwischen jeder Entität auf jede erdenkliche Weise
• Beziehungsmuster für Abfragen
• Verwenden einer Standard-Abfragesprache –SPARQL
• Erstellen von maximalem Kontext für Daten

Reiner Graph-/RDF-Tripel-Datenbankansatz – Nachteile

• Schwierige Modellierung auf derart niedriger Ebene
• Schwer mit anderen Systemen integrierbar
• Keine Standard-Abfragesprache, Experten sind schwer zu finden
• Keine effektive Möglichkeit, um Dokumente zusammenzufügen und ähnliche, aber semantisch unterschiedliche Inhalte zu vergleichen

2. Reiner Dokumentenansatz

Da eine Dokumentendatenbank Schema-agnostisch ist, ist die Produktivität am schnellsten gegeben, wenn Daten unverändert vom System aufgenommen werden und dann je nach gewünschter Ausgabe agil „just in time“ modelliert werden. Im Gegensatz zu relationalen Daten, wo die Daten die ideale Form bestimmen, berücksichtigen wir eher die möglichen Anwendungen und die Analytics die zukünftig vielleicht gebraucht wird.

Der ETL-Standardprozess (Extrahieren, Transformieren, Laden) wird zum „ELT“-Prozess (Extrahieren, Laden und Transformieren, je nach Bedarf). Mit Dokumenten können Sie Datensätze so behalten, wie sie aufgenommen wurden. Oder Sie erhalten Sie in der Form, in der die Daten normalerweise verwendet werden. Ziel des Data Modeling ist es, anwendungsspezifische Objekte oder unternehmensweite Geschäftsobjekte zu identifizieren und Dokumente zu modellieren, die zu diesen Objekten passen. Wir können hier benutzerorientierte, intuitive Modelle entwickeln, die auch technisch nicht versierte Benutzer lesen und verstehen können.

Reiner Dokumentenansatz – Vorteile

• Genaues Modeling der Geschäftstätigkeit – ohne Kompromisse
• Schnelle Entwicklung
• Schema-agnostisch, Entwicklung während der Runtime, Strukturen für Rich Data, JSON, XML und RDF-Daten
• Abfragen des gesamten Kontexts
• Verwandelt Daten in aussagekräftige Informationen
• Abfragen nach Relevanz möglich

Reiner Dokumentenansatz – Nachteile

• Defensives Programmieren für neue Datenstrukturen
• Teure Plattformen
• Unausgereifte Tools
• Experten sind schwer zu finden

3. Multi Model Semantik und Dokumentenansatz

Bei einem Multi Model Ansatz bilden eine Dokumenten- und Tripel-Datenbank einen Operational Data Hub. Dadurch erhalten Sie das Beste beider Welten: das natürliche, für Benutzer leicht verständliche geschäftliche Objektmodell und ein semantisches Konzept, das die Beziehung zwischen diesen Modellen ebenfalls für Benutzer gut verständlich darstellt. Die Data Governance wird einfacher. Die Verknüpfungen zwischen den Dokumenten sind intuitiv und sehr schnell.

Wenn Datenplattformen wie MarkLogic verwendet werden, um Dokumente mit der Semantik zu kombinieren, können Unternehmen schnell Datensilos integrieren und mit diesem Operational Data Hub Just-in-Time-Anwendungen entwickeln. Der Ansatz von MarkLogic hat sich als weitaus flexibler erwiesen und bietet bei einer vergleichbaren Problematik eine viel schnellere Time-to-Market als ein relationaler Datenbankansatz.

Dokumenten- und Tripel-Datenbanken bieten mehr Flexibilität als nur relationale Datenbanken.

Vorteile von Multi Model Semantik und Dokumentenansatz

• Daten werden unverändert in die Datenbanken aufgenommen – dies schafft eine starke Data Governance (Herkunft, Historie, Lebenszyklus, Sicherheitszertifizierungen).
• Die Ontologie kann für Tags genutzt werden oder zur Anreicherung von Dokumenten mit Tripeln dienen.
• Mit der einheitlichen Abfrage-Ansicht kann per Ontologie ähnlicher Inhalt aus verschiedenen Quellen gefunden werden.
• Die flexible API unterstützt SPARQL, REST-Suchabfragen und/oder Java bzw. JavaScript.

Die obige Abbildung zeigt, wie sich die Multi Model Semantik und die Dokumentenarchitektur mit der Plattform von MarkLogic implementieren lassen, um einen ODH zu schaffen. Jede Quelle, auf die APIs oder Anwendungen zugreifen müssen, kann nach eigenen Standards formatiert und gespeichert werden. Das gilt auch für die Unternemens-Objekte (wie Patient, Anbieter, Verfahren usw.), die aggregiert werden müssen. Bei dem flexiblen Datenmodell von MarkLogic können Sie diese Objekte in die Datenbank aufnehmen und als unveränderte Dokumente speichern. Mit einem Ontologie-Manager und/oder anderen Techniken – wie maschinelles Lernen oder der vollautomatischen Erkennung von Textbedeutungen (Natural Language Processing, NLP) – können Sie Ontologien erstellen und verwalten, die ähnliche semantische Felder einander zuordnen und die Beziehungen zwischen den Geschäftsobjekten herstellen. Da MarkLogic mit einer integrierten professionellen Tripel-Datenbank ausgeliefert wird, können diese Ontologien direkt in MarkLogic gespeichert werden. Die eingehenden Daten lassen sich mit semantischen Mappings anreichern, die von der Ontologie beim Schreiben definiert werden. Die einheitliche Abfrage-Ansicht profitiert ebenfalls von der Ontologie: Mit SPARQL und der Suchfunktion können zusätzliche semantische Abfragefunktionen beim erweiterten Lesen der Abfragen hinzugefügt werden. Dieser kombinierte Inhalt aus allen Registrierungssystemen wird dann über die REST API für andere Systeme oder Anwendungen zugänglich.

Die folgende Abbildung zeigt, wie die Semantik für Abfragen und zum Harmonisieren/Normalisieren ähnlicher Semantikkonzepte (z. B. Patienten-IDs aus Registrierungssystemen, die Daten in verschiedenen Formaten speichern) verwendet werden kann. Im Gesundheitswesen verwenden HL7 v3, HL7 v2 und FHIR zwar alle eine Patienten-ID. Aber die Syntax zur Identifizierung dieses Konzepts ist immer anders. Mit semantischen Tripeln kann festgestellt werden, ob sich diese Syntaxen wirklich auf das Patienten-ID-Konzept des Unternehmens beziehen.

Beeindruckt von unserem Vorschlag hat sich das Team dann für die Multi Model Dokument- und Semantik-Architektur entschieden. Ich werde Sie über die Fortschritte auf dem Laufenden halten.

So reduzieren Multi Model Datenbanken die Datensilos from MarkLogic.