- Netflix sah sich bei der Datenmodellierung von Business-Domänen (z. B. Filme, Schauspieler, Serien usw.) mit Problemen bei Zusammenarbeit und Datenqualität konfrontiert, weil jedes System redundante, inkonsistente und nicht standardisierte Begriffe verwendete
- UDA (Unified Data Architecture) ist eine auf Wissensgraphen basierende Infrastruktur mit dem Ziel „einmal modellieren, überall abbilden“, bei der Domänenkonzepte einmal definiert und konsistent auf verschiedene Systeme projiziert und mit ihnen verknüpft werden
- UDA unterstützt die automatische Schemaerzeugung, Zuordnung und Automatisierung von Datenbewegungen vom Domänenmodell zu Daten-Containern (z. B. GraphQL, Avro, Iceberg usw.)
- Business-Anwender können mit UDA-gestützten Tools wie Sphere und PDM allein durch die Suche nach Begriffen Daten erkunden, Berichte erstellen und Referenzdaten verwalten
- Auf Basis semantischer Technologien wie RDF und SHACL kommt ein eigenes Upper-Metamodell zum Einsatz, um groß angelegte Zusammenarbeit, Governance, Schema-Konsistenz und Skalierbarkeit zugleich zu erreichen
Wachsende Komplexität der Netflix-Systeme und die Herausforderungen von Domänenmodellen
- Mit der Ausweitung des Netflix-Angebots auf Filme, Serien, Games, Live-Events, Werbung usw. nahm auch die Systemkomplexität zur Unterstützung dieser Angebote stark zu
- Zentrale Business-Konzepte wie „actor“ und „movie“ wurden in unterschiedlichen Systemen (Enterprise GraphQL Gateway, Asset-Management-Plattform, Media Computing usw.) jeweils separat definiert und ohne Zusammenarbeit oder gemeinsame Nutzung fragmentiert betrieben
- Dadurch entstanden folgende Probleme
- Redundante und inkonsistente Modelle: Dieselbe Entität wurde in verschiedenen Systemen neu definiert, wodurch Konflikte schwer zu vermeiden waren
- Inkonsistente Terminologie: Selbst innerhalb desselben Systems wurden unterschiedliche Begriffe verwendet oder derselbe Begriff mehrfach benutzt, was die Kommunikation erschwerte
- Probleme bei der Datenqualität: Zwischen zahlreichen Microservices gab es Inkonsistenzen und Referenzfehler; auch die Verwaltung von Identifikatoren und Fremdschlüsseln war unzureichend, sodass manuelle Korrekturen nötig waren
- Begrenzte Konnektivität: Eingeschränkte Beziehungen innerhalb einzelner Systeme und unzureichende Verknüpfung zwischen Systemen
- Um diese Probleme zu lösen, brauchte es eine Grundlage, auf der ein konzeptionelles Modell einmal definiert und überall wiederverwendet sowie mit realen Systemen und Daten tatsächlich verbunden und integriert werden kann
Überblick über UDA (Unified Data Architecture)
- UDA ist eine auf Datenkonnektivität basierende Plattform innerhalb von Netflix Content Engineering
- Domänenmodelle (Business-Konzepte) werden einmal definiert, um konsistente Projektionen in alle Systeme sowie Automatisierung, Auffindbarkeit und semantische Interoperabilität zu unterstützen
- Wichtige mit UDA mögliche Funktionen
- Registrierung und Verknüpfung von Domänenmodellen: Offizielle Konzeptdefinitionen dienen als Single Source of Truth, um Verwirrung zwischen Teams und doppelte Modellierung zu vermeiden
- Zuordnung von Domänenmodellen zu Daten-Containern: Business-Konzepte und die Orte, an denen die realen Daten gespeichert sind (Datenbanken, Tabellen, Services usw.), werden in einer Graphstruktur dargestellt, sodass sich ihre Struktur leicht nachvollziehen lässt
- Umwandlung von Domänenmodellen in Schemadefinitionssprachen: Automatische Konvertierung für unterschiedliche Systeme wie GraphQL, Avro, SQL, RDF und Java, wodurch manueller Aufwand minimiert und Fehler reduziert werden
- Zuverlässige Datenbewegung zwischen Daten-Containern: Automatische Verarbeitung von Datentransformation und -verschiebung zwischen Systemen wie GraphQL-Entitäten, Data Mesh, CDC und Iceberg
- Erkundung und Suche nach Domänenkonzepten: Beziehungen zwischen Business-Konzepten lassen sich durchsuchen und erkunden, was den Zugriff auf präzise Informationen erleichtert
- Programmgesteuerte Introspection des Wissensgraphen: Nutzung verknüpfter Business-Informationen über Java, GraphQL und SPARQL für Automatisierung und Erkenntnisgewinn
Die Kernarchitektur von UDA
-
Auf Knowledge Graphs basierend
- Ein auf RDF/SHACL basierender Knowledge Graph verbindet alle Elemente wie Domänenmodelle, Schemata, Daten-Container und Mappings als Graphdaten
- Ein Informationsmodell mit named graphs im Zentrum, bei dem jeder named graph einem regelbasierten Governance-Modell folgt und so Interpretationsrahmen, Modularisierung und Betriebsrichtlinien ermöglicht
-
Upper-Metamodell
- Upper ist eine Metamodellsprache zur strikten Definition von Domänenmodellen
- Zentrale domänenspezifische Entitäten, Attribute und Beziehungen werden als Typen und Hierarchien modelliert und können in RDF dargestellt, versioniert und abgefragt werden
- Upper ist selbst mit Upper modelliert (selbstreferenziell, selbstvalidierend) und sorgt so für Konsistenz bei allen Erweiterungen und Projektionen
- Attributwerte lassen sich domänenspezifisch anpassen, und alle Konzepte werden als conceptual RDF und in named graphs dargestellt, was Introspection, Suche und Versionsverwaltung unterstützt
- Upper bietet ein hohes Abstraktionsniveau und nutzt zugleich gezielt nur die wesentlichen Teile semantischer W3C-Technologien wie RDFS/OWL/SHACL, sodass effektive Domänenmodellierung auch ohne Ontologie-Kenntnisse möglich ist
- Aus dem Upper-Metamodell werden eine Jena-basierte Java-API und GraphQL-Schemata automatisch erzeugt und mit realen GraphQL-Services verknüpft
-
Daten-Container und Mappings
- Data Container: reale Datenspeicher (z. B. Entitäten eines GraphQL-Service, Avro-Records aus einer Data-Mesh-Quelle, Zeilen in Iceberg-Tabellen, Objekte einer Java-API usw.)
- Mappings: Definition einer 1:1-Verknüpfung zwischen bestimmten Elementen des Domänenmodells und Daten-Containern (Tabellen, Feldern usw.)
- Über Mappings lässt sich die Beziehung von Domänenkonzepten zu realen Datenpositionen nachverfolgen und umgekehrt von Daten zu zugehörigen Domänenkonzepten navigieren
- Intentionsbasierte Datenbewegung/Automatisierung: Anhand der Mapping-Informationen bestimmt das System Datenflüsse und Transformationen automatisch
-
Projections (Projektionen)
- Automatische Umwandlung und Erzeugung vom Domänenmodell zu Zielsystem-Schemata (z. B. GraphQL, Avro usw.) einschließlich Automatisierung von Code, Schemata und Pipelines
- Gewährleistung von Schema-Konsistenz sowie Minimierung redundanter Definitionen und von Synchronisationsproblemen
Beispiele aus der Praxis
-
PDM (Primary Data Management)
- Plattform zur Verwaltung von Referenzdaten und Taxonomien (hierarchische Klassifikationssysteme)
- Domänenmodelle werden in hierarchische oder flache Klassifikationen umgewandelt, und die UI für Business-Anwender wird automatisch erzeugt
- Konsistente Definition von Business-Begriffen, basierend auf dem SKOS-Modell; mit UDA werden Avro- und GraphQL-Schemata sowie Pipelines automatisch erzeugt
- Wird nur das Domänenmodell eingegeben, werden UI, Datenpipeline und GraphQL-API automatisch konfiguriert
-
Sphere (Operational Reporting)
- Self-Service-Tool für operatives Reporting auf Basis eines Wissensgraphen
- Suche und Navigation auf Basis von Domänenbegriffen sowie automatisierte Join-Strategien ermöglichen Datenerkundung und Reporterstellung ohne technische Komplexität
- Mit UDA-basierten Metadaten und Mappings erkennt und verarbeitet das System automatisch sowohl den tatsächlichen Speicherort der Daten als auch die Join-Logik
- Konzepte lassen sich mit vertrauten Begriffen wie „actor“ und „movie“ erkunden; auf Basis der ausgewählten Konzepte erzeugt das System automatisch SQL-Abfragen entlang des Wissensgraphen, sodass sich Daten ohne separate Joins oder technische Arbeiten abrufen lassen
Fazit und Ausblick
- UDA treibt einen grundlegenden Wandel in Netflixs Art der Datenmodellierung und -integration voran
- Mit einer einmaligen Definition des Domänenmodells wird eine konsistente, automatisierte und skalierbare Datenanbindung über die Systeme der gesamten Organisation hinweg möglich
- Künftig sind zusätzliche Unterstützungen wie Protobuf/gRPC sowie eine Ausweitung auf reale Daten im Wissensgraphen vorgesehen
2 Kommentare
Ich muss etwas Ähnliches aufbauen, aber ich bin ziemlich ratlos.
Hacker-News-Kommentare
Trotz aller Vorteile scheint es bei diesem Ansatz ein großes, oft kaum erwähntes Problem zu geben
Es ist ein Business-Problem, wirkt sich aber auch auf technische Fragen aus und wird dadurch letztlich zu einem nachgelagerten technischen Problem, das die Entwicklungsgeschwindigkeit beeinflusst
Wenn das Business darauf basiert, dass die gesamte Organisation einem einzigen einheitlichen Datenmodell vertrauen kann, muss man bei der Definition oder Änderung von Daten zwangsläufig nicht nur den eigenen Bereich, sondern zahlreiche Use Cases der gesamten Organisation berücksichtigen
Selbst kleine Änderungen betreffen dann die ganze Organisation, sodass komplexe Prozesse mit Freigaben durch viele Stakeholder entstehen
Das ist die Daten-Version des klassischen Problems in Großunternehmen, warum „eine Änderung der Button-Farbe zwei Monate dauert“
Natürlich ist es meist das gravierendere Problem, Daten zu duplizieren oder inkonsistent zu verteilen
Aber manchmal will man kleine, isolierte Änderungen schnell ausrollen, und dann wird so ein System zu einem großen Hindernis
Ich habe einmal versucht, dafür ein Produkt zu entwickeln
Der Ansatz war, dem unternehmensweiten gemeinsamen Modell zu folgen und gleichzeitig lokale Spezialisierungen des Modells leicht zu ermöglichen (indem wir eine Prolog-artige Sprache zur Datendefinition erweitert und uns ernsthaft mit realitätsbasierten Unternehmensmodellen beschäftigt haben statt mit theoretischen Anforderungen)
Leider war das Timing schlecht, weil wir das mitten im NoSQL- und Big-Data-Hype versucht haben
NoSQL und Big Data stehen für eine Kultur, in der man mit lockeren Modellen arbeitet und es in Ordnung ist, wenn Daten teilweise verloren gehen oder missverstanden werden, solange man es später irgendwie flicken kann
Statt zu Beginn ein starkes Modell zu entwerfen, herrschte eher die Stimmung, dass Nacharbeit schon machbar sei; etwas schade, aber ich habe es akzeptiert
Ich stimme zu, dass es im Kern ein Business-Problem ist, und wir glauben, dass man es technisch systematisch lösen kann
Wir sind zuversichtlich, einen systematischeren Weg gefunden zu haben, modellorientierte Wissensgraphen in Unternehmen einzuführen und auszurollen
UDA geht bewusst vorsichtig vor, damit nicht alles, was angefragt wird, noch bürokratischer wird
UDA existiert neben bestehenden Systemen und erzwingt keine pauschale Übernahme
Für Teams, die möchten, dass ihr Business-Modell überall nutzbar und leicht verknüpfbar, erweiterbar und auffindbar ist, soll es aber ein starkes und einfaches Werkzeug sein
(Der Verfasser weist darauf hin, dass er einer der UDA-Architekten ist)
Meiner Erfahrung nach scheitert ein logisches oder konsistentes Datenmodell in Unternehmen oft an den Behauptungen von „big men“
Selbst wenn technische Praktiker Daten vernünftiger und standardisierter behandeln wollen, bastelt eine einflussreiche Person ihr Modell im Kopf zusammen und zwingt Entwickler, sich daran anzupassen
Sobald sich diese symbolische Denkweise einmal festsetzt, sinkt die Wahrscheinlichkeit für ein konsistentes Datenmodell in diesem Unternehmen gegen null
Letztlich ist das, denke ich, auch ein Grund, warum ineffizient so viel Geld an Berater gezahlt wird
Ich habe mich lange gefragt, was SAP eigentlich ist, und war überrascht, als ich es schließlich verstanden habe
Weil so viele Unternehmen SAP nutzen, hatte ich vermutet, dass da enorme technische Raffinesse dahintersteckt, tatsächlich ist es aber eher ein festes Schema, an das sich die Kunden anpassen sollen
Im Original lese ich nicht heraus, dass bestritten wird, dass es ein Business-Problem ist
Die definierten Modelle werden über alle Rollen hinweg festgelegt, und Engineering ist nur ein Teil davon
Es wirkt so, als sei seit dem Auftreten von Semantic Web, RDF, OWL, SKOS usw. schon ziemlich viel Zeit vergangen
Gut fand ich, dass man W3C weiterhin unterstützt und das Rad nicht neu erfindet
Ob sich der UDA-Ansatz allgemein durchsetzen wird, weiß ich nicht, aber als Versuch, die Schwierigkeiten bei der Anwendung von DDD (Domain-Driven Design) und semantischen Konzepten in großen Organisationen grundlegend zu verringern, wirkt es vielversprechend
Spannend ist die Möglichkeit, mehreren Entwicklungsteams gemeinsame Werkzeuge und einen gemeinsamen Technologie-Stack für dieselbe Daten-Semantik zu geben und damit einen „Compound-Interest“-Effekt zu erzeugen; vielleicht muss man Datenverträge dann nicht mehr wegen DTOs, POST usw. für Netzwerkübertragung künstlich einebnen
Positiv, dass Netflix ein solches interessantes Experiment offen vorantreibt
Das erinnert mich an ein Projekt namens Dragon bei Uber
Ich hatte an Arbeiten zu Dragon schema at Uber mitgewirkt, aber es wurde nie Open Source
Später wechselte Joshua zu LinkedIn und arbeitete am Projekt LambdaGraph und an der Sprache Hydra; das ist hier als Open Source verfügbar
Ein Nachteil solcher Ansätze und auch der Semantic-Web-Strömung von vor zehn Jahren war immer der enorme Zusatzaufwand, Konzepte zu formalisieren und zu pflegen
Heute frage ich mich, ob LLMs (Large Language Models) diese Last verringern können
Schade finde ich die Wahl des Begriffs „Domain Model“ in diesem Fall
Das Domain Model ist hier rein datenorientiert, während es beim eigentlichen Domain Modeling im Kern eher um Verhalten als um Datenstrukturen geht
Die Daten in einem Domain Model existieren, um Verhalten zu ermöglichen, und das Verhalten selbst ist der Mittelpunkt des Codes
Es ist zwar komplex, Datenmodellierung je nach Perspektive unterschiedlich auszudrücken, aber genau dieser Unterschied kann auch eine Stärke sein
Nicht jede Situation erfordert dieselbe Komplexität oder dieselbe Detailtiefe, und Repräsentationsmodelle werden in der Regel für Lese-Szenarien optimiert
Bei diesem Ansatz könnte die Einheitlichkeit wichtiger werden als die situationsabhängige Behandlung von Informationen; in Umgebungen mit hohem Domänenverständnis mag das skalierbarer sein, in der Praxis werden die meisten Use Cases aber schwierig, wenn man komplexe oder feingliedrige Domain-Modelle nicht vereinfacht
Die Frage ist, ob jemand schon einmal einen Fall gesehen hat, in dem ein solcher Versuch zu einer messbaren Business-Verbesserung von mehr als 5 % oder mehr als 5 Millionen Dollar geführt hat
Ich habe mehrfach Versuche erlebt, Datentabellen zu vereinheitlichen, aber in der Praxis war das bedeutungslos, sobald unterschiedliche Analysen benötigt wurden, und verschiedene Analysen liefen weiterhin getrennt
Anders gesagt: Selbst wenn man die Basisschicht so vereinheitlicht, wie es alle für ihre gewünschte Analyseform wollen, laufen unterschiedliche Analysen am Ende doch weiterhin separat
Trotzdem wirkt dieser Versuch klug, weil er offenbar nicht alles in ein einziges Modell zwängen will, sondern die breite Zugänglichkeit verbessern möchte
Dem Ziel, formale Definitionen von Business-Konzepten zu vereinheitlichen und Verwirrung zu verringern, kann ich sehr viel abgewinnen
Selbst wenn alle eine Master-Liste von Gefängnissen wollen, ist es je nach Definition etwas völlig anderes, ob ein Gefängnis das Gebäude selbst ist, eine Gruppe von Gefangenen (mit getrennten Männer- und Frauengefängnissen auf demselben Gelände als eigenständige Einheiten) oder eine Einrichtung, die unter einem bestimmten Vertrag betrieben wird
In diesem Sinn brauchen verschiedene Perspektiven in einer Organisation leicht unterschiedliche Objekte
Ich frage mich, wie das mit Domain-Driven Design (DDD) zusammenhängt
In DDD geht man doch gerade davon aus, dass selbst dasselbe Konzept je nach System unterschiedlich dargestellt werden kann
Den Artikel selbst habe ich wegen des UML-Gefühls aber nicht bis zum Ende gelesen
Das Domain in upper:DomainModel ist dasselbe Domain wie das D in DDD, ebenso bei DGS (Domain Graph Service)
DDD erlaubt, dass dasselbe Konzept gleichzeitig je nach System unterschiedlich repräsentiert wird, während UDA so gestaltet ist, dass diese verschiedenen Konzepte innerhalb jeder Domain explizit koexistieren
Der Begriff „gleich“ wird dadurch subjektiv
Fast schon gut, dass nicht der Begriff „ubiquitous language“ verwendet wurde
Dieses Konzept ist das genaue Gegenteil von dem, was hier versucht wird
Wer nur davon gehört hat, ohne tiefer einzusteigen, erkennt den Unterschied womöglich nicht
Ich frage mich, warum Netflix Engineering Inhalte auf Medium veröffentlicht
Durch die Pop-ups auf Medium verliert man Leser leicht; ich frage mich, ob sich dieses Risiko lohnt
Immer wenn ich eine hexadezimale Medium-URL sehe, lese ich sie spaßeshalber über scribe.rip
scribe.rip UDA-Artikel
Wenn das Marketing-Team dahintersteckt, ist es möglicherweise eine Strategie inklusive SEO
Der „Discovery“-Effekt von Medium ist tatsächlich real
Und Ingenieure, die gern in diesem Medium-Stil schreiben, gehören vielleicht genau zu der Zielgruppe, die Netflix rekrutieren möchte
Es ist auch bequemer, keinen eigenen Blog betreiben zu müssen
Ich frage mich, wie man mit Versionsmanagement des Datenmodells oder mit Breaking Changes umgeht
Wenn Modelle stärker voneinander getrennt sind, kann man wie bisher leicht einzelne Teile reparieren; wie funktioniert das in so einem integrierten Modell?
Ich vermute, dass Netflix einfach ein neues Modell hinzufügt und das alte schrittweise auslaufen lässt
In UDA ist das noch nicht vollständig implementiert, aber man plant denselben Ansatz wie bei Federated GraphQL
Übernommen werden soll das in Federated GraphQL bewährte Modell für Deprecation-Management; wir haben bereits erfolgreich mehr als 500 föderierte GraphQL-Schemas verwaltet
Der Kern der Roadmap ist, Konsumenten der projected models nachzuverfolgen und Deprecated-Zyklen aktiv zu steuern
Mein Eindruck ist, dass man für den Erfolg eines integrierten Graphen Business, Kommunikation und Technik gleichermaßen lösen muss
Beim Kommunikationsproblem muss man die latente Unabhängigkeit autonomer Teams aufbrechen
Man braucht Menschen, die teamübergreifend Brücken schlagen und auch die Datenmodelle analysieren
Reines Schema-Sharing reicht nicht; man muss direkt mit Leuten sprechen und durch Interviews zu Einigungen kommen
Technisch ist es eher am einfachsten, und mit einem „dicken Schema“ wie bei Microsoft Graph lässt sich das relativ straightforward durchsetzen
Dafür braucht man allerdings viel Empathie und Geduld
Eine technische Lösung erfordert klare Entscheidungen und Durchsetzungsbefugnis des Managements; wenn jedes Team frei schalten und walten kann, nützt keine Idee etwas
Die Business-Seite ist die höchste Schwierigkeitsstufe
Prozesse und Begriffe zu ändern, die über 20 Jahre optimiert wurden, ist praktisch unmöglich
Am Ende lohnt sich diese enorme Aufgabe „für ein ganzes Berufsleben“ nur, wenn es wirklich unternehmensweites Buy-in gibt
Ich glaube, dass die Einführung eines gemeinsamen Vokabulars sehr sinnvoll ist
Aber je weiter sich eine Organisation ausdehnt – über das ganze Unternehmen, neue Akquisitionen, verschiedene Business-Prozesse und über die Zeit hinweg –, desto schwieriger wird es
Eine Schnittstelle zwischen zwei Systemen kann man schnell zusammenbauen, aber wer soll in einem Enterprise mit vielen Schichten eine ideale Datenbank bauen und dauerhaft pflegen, die das gesamte Wissen in einem Katalog abbildet?
Die erfolgreich gebliebenen Versuche waren meist entweder sehr abstrakt gehalten oder auf einen bestimmten Use Case begrenzt
Meiner Erfahrung nach muss selbst eine unternehmensweite Entität (z. B. die offizielle Unternehmensentität) von einzelnen Abteilungen erweitert werden, und dann braucht es politische und optimistische Entscheidungen darüber, ob neue Attribute von allen Abteilungen oder nur von der jeweiligen Abteilung genutzt werden sollen
Wenn man die offizielle Entität aktualisiert, muss man die Auswirkungen auf alles sorgfältig prüfen und striktes Change Management betreiben
Wenn das sauber aufgebaut ist und von einer strengen Organisationskultur getragen wird, können Kosten und Reibung stark sinken; bei Netflix scheint das denkbar
Als praktisch einziges überlebendes Beispiel für ein groß angelegtes gemeinsames Vokabular wurde Wikidata genannt
Dort wächst ein standardisiertes Vokabular mit 1,65 Milliarden Graph-Knoten kontinuierlich weiter