- Chez Netflix, la modélisation des données des domaines métier (par ex. films, acteurs, séries, etc.) faisait face à des problèmes de collaboration et de qualité des données en raison de doublons, d’incohérences et d’une terminologie non standard selon les systèmes
- L’UDA (architecture de données unifiée) vise à « modéliser une fois, représenter partout » : il s’agit d’une infrastructure fondée sur un knowledge graph qui permet de définir une seule fois les concepts du domaine, puis de les projeter et de les relier de manière cohérente dans différents systèmes
- L’UDA prend en charge la génération automatique de schémas, le mapping et l’automatisation des déplacements de données du modèle de domaine vers des conteneurs de données (par ex. GraphQL, Avro, Iceberg, etc.)
- Les utilisateurs métier peuvent, via des outils s’appuyant sur l’UDA comme Sphere ou PDM, explorer les données, générer des rapports et gérer des données de référence simplement en recherchant des termes
- En s’appuyant sur des technologies sémantiques comme RDF et SHACL, auxquelles s’ajoute son propre métamodèle Upper, Netflix parvient à concilier collaboration à grande échelle, gouvernance, cohérence des schémas et extensibilité
Montée en complexité des systèmes Netflix et défis des modèles de domaine
- À mesure que les services de Netflix se sont étendus aux films, séries, jeux, événements en direct, publicité, etc., la complexité des systèmes qui les soutiennent a elle aussi fortement augmenté
- Des concepts métier centraux comme
actor ou movie ont été définis séparément dans différents systèmes (Enterprise GraphQL Gateway, plateforme de gestion des assets, media computing, etc.), puis exploités de façon fragmentée, sans réelle coopération ni partage
- Cela a entraîné plusieurs problèmes
- Modèles dupliqués et incohérents : la même entité est redéfinie dans plusieurs systèmes, ce qui rend les conflits difficiles à éviter
- Incohérences terminologiques : même au sein d’un même système, des termes différents sont utilisés, ou bien un même terme est dupliqué, ce qui brouille la communication
- Problèmes de qualité des données : incohérences et erreurs de référence entre de très nombreux microservices, avec une gestion insuffisante des identifiants et des clés externes, nécessitant des corrections manuelles
- Limites de connectivité : relations limitées à l’intérieur des systèmes et intégration insuffisante entre eux
- Pour résoudre cela, il fallait une base permettant de définir une seule fois un modèle conceptuel puis de le réutiliser partout, tout en l’attachant et l’intégrant réellement aux systèmes et aux données existants
Vue d’ensemble de l’UDA (Unified Data Architecture)
- L’UDA est une plateforme fondée sur la connectivité des données au sein de Netflix Content Engineering
- Elle permet de définir une seule fois le modèle de domaine (les concepts métier), puis d’en assurer la projection cohérente dans tous les systèmes, tout en prenant en charge l’automatisation, la découverte et l’interopérabilité sémantique
- Principales capacités rendues possibles par l’UDA
- Enregistrement et liaison des modèles de domaine : utiliser une source unique pour les définitions officielles des concepts afin d’éviter la confusion entre équipes et la modélisation en doublon
- Mapping entre modèles de domaine et conteneurs de données : représenter sous forme de graphe les concepts métier, leur structure, et l’emplacement des données réelles (bases de données, tables, services, etc.) afin de les comprendre facilement
- Transformation des modèles de domaine en langages de définition de schéma : conversion automatique vers GraphQL, Avro, SQL, RDF, Java et d’autres systèmes, afin de réduire le travail manuel et les erreurs
- Déplacement fiable des données entre conteneurs : traitement automatisé des conversions et des transferts de données entre systèmes comme les entités GraphQL, Data Mesh, CDC, Iceberg, etc.
- Exploration et recherche des concepts de domaine : possibilité d’explorer et de rechercher les relations entre concepts métier pour accéder plus facilement à l’information pertinente
- Introspection programmatique du knowledge graph : exploitation d’informations métier connectées via Java, GraphQL et SPARQL pour l’automatisation et la production d’insights
Architecture cœur de l’UDA
-
Fondée sur un Knowledge Graph
- Knowledge graph basé sur RDF/SHACL reliant sous forme de données de graphe tous les éléments : modèles de domaine, schémas, conteneurs de données, mappings, etc.
- Modèle d’information centré sur les named graphs : chaque named graph suit un modèle de gouvernance structuré, permettant cadre d’interprétation, modularisation et politiques d’exploitation
-
Métamodèle Upper
- Upper est un langage de métamodélisation qui définit rigoureusement les modèles de domaine
- Il modélise, par types et hiérarchies, les entités, attributs et relations clés de chaque domaine, et peut être représenté, versionné et interrogé en RDF
- Upper est lui-même modélisé avec Upper (auto-référence, auto-validation), ce qui garantit la cohérence de toutes les extensions et projections
- Les valeurs d’attributs peuvent être adaptées par domaine, et tous les concepts sont représentés en RDF conceptuel et en named graphs, afin de prendre en charge introspection, recherche et gestion des versions
- Upper combine un haut niveau d’abstraction avec une sélection ciblée des éléments essentiels des technologies sémantiques W3C comme RDFS/OWL/SHACL, ce qui permet de modéliser efficacement des domaines même sans maîtriser les concepts d’ontologie
- À partir du métamodèle Upper, une API Java basée sur Jena ainsi qu’un schéma GraphQL sont générés automatiquement, puis reliés à des services GraphQL réels
-
Conteneurs de données et mappings
- Data Container : dépôt réel des données (par ex. entités d’un service GraphQL, enregistrements Avro d’une source Data Mesh, lignes d’une table Iceberg, objets d’une API Java, etc.)
- Mappings : définition de correspondances un à un entre des éléments précis du modèle de domaine et des conteneurs de données (tables, champs, etc.)
- Grâce aux mappings, il est possible de suivre le chemin d’un concept de domaine jusqu’à son emplacement réel dans les données, et inversement d’explorer les concepts de domaine liés à une donnée
- Automatisation et déplacements de données pilotés par l’intention : le système utilise les informations de mapping pour déterminer automatiquement les flux et transformations de données
-
Projections
- Conversion et génération automatiques du modèle de domaine vers les schémas des systèmes cibles (par ex. GraphQL, Avro, etc.), avec automatisation du code, des schémas et des pipelines
- Garantie de cohérence des schémas et réduction au minimum des définitions en doublon ainsi que des problèmes de synchronisation
Cas d’usage concrets
-
PDM (Primary Data Management)
- Plateforme de gestion des données de référence et des taxonomies (systèmes de classification hiérarchiques)
- Transformation du modèle de domaine en classifications hiérarchiques ou plates, avec génération automatique d’une UI destinée aux utilisateurs métier
- Définition cohérente des termes métier, base sur le modèle SKOS, génération automatique par l’UDA des schémas et pipelines Avro/GraphQL
- Il suffit de fournir le modèle de domaine pour que l’UI, les pipelines de données et l’API GraphQL soient configurés automatiquement
-
Sphere (Operational Reporting)
- Outil self-service de reporting opérationnel fondé sur un knowledge graph
- Recherche fondée sur les termes métier, exploration et automatisation des stratégies de jointure, permettant la découverte des données et la création de rapports sans complexité technique
- Grâce aux métadonnées et mappings fournis par l’UDA, le système identifie et exécute automatiquement jusqu’à l’emplacement réel des données et la logique de jointure
- À partir de termes familiers comme
actor ou movie, on peut explorer les concepts, puis le système génère automatiquement des requêtes SQL en suivant le knowledge graph sur la base des concepts sélectionnés, sans jointures manuelles ni travail technique supplémentaire
Conclusion et perspectives
- L’UDA entraîne une transformation fondamentale de la manière dont Netflix modélise et intègre ses données
- Avec une seule définition du modèle de domaine, les systèmes de toute l’organisation peuvent interconnecter les données de façon cohérente, automatisée et extensible
- À l’avenir, la prise en charge de Protobuf/gRPC et d’autres technologies sera ajoutée, et le périmètre d’application s’élargira, notamment avec la mise en données réelles du knowledge graph
2 commentaires
Je dois mettre en place quelque chose de similaire, mais je ne sais pas par où commencer.
Commentaires sur Hacker News
Malgré tous les avantages, j’ai l’impression que cette approche a un gros problème dont on parle rarement
C’est un problème métier qui affecte aussi les questions techniques, et qui finit donc par devenir un problème technique secondaire ayant un impact sur la vitesse de développement
Comme le contrat selon lequel toute l’organisation peut faire confiance à une définition unifiée des données engage le métier, dès qu’on définit ou modifie des données, on est obligé de prendre en compte non seulement son propre domaine mais aussi les nombreux cas d’usage de toute l’organisation
Même un petit changement peut affecter toute l’organisation, ce qui crée des procédures complexes nécessitant l’approbation de nombreuses parties prenantes
C’est la version « données » du problème classique des grandes entreprises : « pourquoi faut-il deux mois pour changer la couleur d’un bouton »
Bien sûr, j’admets qu’en général, dupliquer les données ou les disperser de manière incohérente est un problème plus grave
Mais parfois, quand on veut déployer rapidement un changement petit et isolé, ce type de système devient un obstacle majeur
J’ai déjà essayé de développer un produit pour résoudre ça
J’ai tenté une approche qui permettait de suivre un modèle commun à l’entreprise tout en spécialisant facilement le modèle en local (en étendant un langage de définition des données de type Prolog, et en réfléchissant réellement à un modèle d’entreprise fondé sur la réalité plutôt que sur des besoins immédiats)
Malheureusement, j’ai essayé au moment où la vague NoSQL et Big Data battait son plein, donc le timing n’était pas bon
Avec NoSQL et Big Data, la culture veut qu’on puisse fonctionner avec des modèles souples et recoller les morceaux plus tard même si certaines données sont perdues ou mal comprises
L’ambiance était davantage au « on verra plus tard » qu’à la conception d’un modèle solide dès le départ, ce que j’ai trouvé un peu regrettable mais que j’ai fini par accepter
Je suis d’accord sur le fait qu’il s’agit fondamentalement d’un problème métier, et je pense qu’on peut le traiter de manière systématique avec la technologie
Je suis convaincu que nous avons mis en place une méthode plus structurée pour introduire et déployer des knowledge graphs model-first dans l’entreprise
UDA est abordé avec prudence pour éviter que tout ce qui est demandé ne devienne au contraire encore plus bureaucratique
UDA coexiste avec les systèmes existants et n’impose pas une adoption forcée
En revanche, on veut en faire un outil puissant et simple pour les équipes qui souhaitent que leur modèle métier soit utilisable partout et facilement connectable, extensible et découvrable
(je précise que je suis l’un des architectes d’UDA)
D’expérience, j’ai souvent vu l’absence de modèle de données logique ou cohérent à cause des opinions des « grands personnages » dans l’entreprise
Même lorsque les techniciens de terrain veulent traiter les données de façon plus rationnelle et conforme aux standards, la réalité est qu’une personne influente impose directement son modèle mental et force les développeurs à s’y adapter
Une fois que ce type de pensée symbolique s’installe, la probabilité de construire un modèle de données cohérent dans cette entreprise tend vers zéro
Au final, je pense que c’est pour ce genre de problèmes qu’on paie des sommes absurdement élevées à des consultants
Je me suis longtemps demandé ce qu’était SAP, et quand je l’ai enfin compris, ça m’a surpris
Comme énormément d’entreprises utilisent SAP, j’imaginais qu’il devait y avoir une technologie impressionnante derrière, mais j’ai découvert qu’en pratique il s’agit d’imposer un schéma figé auquel le client doit s’adapter
Le texte original ne me semble pas nier qu’il s’agit d’un problème métier
Les modèles définis sont conçus pour couvrir tous les rôles, et l’ingénierie n’en est qu’une partie
Ça fait un moment maintenant que le Semantic Web, RDF, OWL, SKOS, etc. sont apparus
J’ai apprécié le fait de continuer à s’appuyer sur le W3C et de ne pas réinventer une roue qui existe déjà
Je ne sais pas si l’approche UDA deviendra grand public, mais j’y vois une tentative prometteuse pour réduire de manière innovante les difficultés d’application du DDD (Domain-Driven Design) et des concepts sémantiques dans les organisations de grande taille
S’il est possible de fournir à plusieurs équipes de développement des outils et un ensemble de technologies communs partageant le même système de signification des données, afin de produire un effet de « compound interest », il devient peut-être possible d’éviter d’aplatir artificiellement les contrats de données en DTO, POST, etc. uniquement à cause des contraintes de transport réseau
Je vois d’un bon œil le fait que Netflix mène cette expérience intéressante de manière publique
Ça me rappelle un projet appelé Dragon chez Uber
J’avais travaillé sur Dragon schema at Uber, mais cela n’a pas pu être open sourcé
Ensuite Joshua a rejoint LinkedIn, où il a participé au projet LambdaGraph et au langage Hydra, qui sont disponibles en open source ici
Le défaut de ce genre d’approche, comme du mouvement Semantic Web d’il y a dix ans, c’est la charge de travail supplémentaire énorme qu’implique la formalisation et la maintenance des concepts
Je me demande si les LLM (grands modèles de langage) pourraient aujourd’hui réduire ce fardeau
Je trouve regrettable le choix du terme « domain model » employé ici
Le domain model dont il est question ici est un concept purement centré sur la donnée, alors que dans le vrai domain modeling, l’essentiel est de se concentrer sur le comportement (behavior) plutôt que sur la structure des données
Les données d’un domain model existent pour permettre le comportement, et c’est ce comportement qui constitue le cœur du code
Il y a bien une complexité inhérente au fait de représenter le data modeling de différentes façons selon les points de vue, mais cette différence peut aussi être vue comme une fonctionnalité
Toutes les situations n’exigent pas le même niveau de complexité ou de finesse, et les modèles de représentation sont en général optimisés pour des scénarios de lecture
Avec cette approche, on peut se retrouver à privilégier davantage l’uniformité que le traitement contextuel de l’information ; elle peut mieux passer à l’échelle dans des environnements où la compréhension du domaine est élevée, mais dans la pratique, j’ai constaté que la plupart des cas d’usage deviennent difficiles si l’on ne simplifie pas les domain models complexes ou subtils
Question : « Avez-vous déjà vu ce genre d’initiative produire plus de 5 % d’amélioration métier, ou plus de 5 millions de dollars de gains mesurables ? »
J’ai vu plusieurs tentatives d’unification de tables de données, mais en pratique, dès lors qu’il fallait des analyses différentes, l’unification des tables ne servait à rien, et les analyses continuaient à être menées séparément
Autrement dit, même si l’on unifie la couche de base selon la manière dont tout le monde voudrait analyser les choses, les analyses divergentes continuent malgré tout à évoluer séparément
Cela dit, cette tentative-ci ne semble pas chercher à tout unifier de force, mais plutôt à faciliter un large accès, ce qui paraît intelligent
Je comprends profondément l’objectif de définir officiellement les concepts métier afin que tout le monde partage les mêmes définitions et qu’on réduise la confusion
Par exemple, même si tout le monde veut une liste maîtresse des prisons, une prison peut désigner le bâtiment lui-même, un ensemble de détenus (par exemple des prisons hommes et femmes distinctes sur le même site), ou encore une institution exploitée sous un contrat donné ; tout dépend de la définition
De ce point de vue, chaque perspective organisationnelle a besoin d’objets subtilement différents
Je me demande quel est le lien avec le Domain-Driven Design (DDD)
En DDD, n’est-on pas justement censé partir du principe qu’un même concept peut être représenté différemment selon les systèmes ?
Je n’ai cependant pas lu l’article jusqu’au bout à cause de son côté très UML
Le Domain de upper:DomainModel est bien le même D (domaine) que dans DDD, et c’est aussi le cas pour DGS (Domain Graph Service)
En DDD, on admet qu’un même concept puisse être représenté différemment selon les systèmes en parallèle, alors que dans UDA, l’idée est de faire coexister explicitement ces différents concepts au sein de chaque domaine
La notion même de « même chose » devient subjective
Je suis presque soulagé qu’ils n’aient pas employé le terme « ubiquitous language »
Ce concept est en fait totalement opposé à la démarche présentée ici
Ceux qui n’ont fait qu’entendre parler de notions voisines sans vraiment creuser pourraient ne pas voir la différence
Je me demande pourquoi Netflix Engineering publie son contenu sur Medium
Avec les pop-ups de Medium et le fait qu’on peut y perdre facilement des lecteurs, je me demande si cela vaut vraiment la peine d’accepter ce risque
Chaque fois que je vois une URL Medium en hexadécimal, ça me donne envie de la lire via scribe.rip
Article UDA sur scribe.rip
Si c’est géré par l’équipe marketing, il est possible qu’il y ait une stratégie incluant aussi le SEO
L’effet de « discovery » offert par Medium existe réellement
Et il est probable que le type d’ingénieurs qui écrivent sur Medium corresponde au profil que Netflix cherche à recruter
C’est aussi plus pratique, car il n’y a pas besoin de gérer un blog soi-même
Je me demande comment ils gèrent le versioning des modèles ou les breaking changes
Quand on opère avec des modèles plus séparés, on peut généralement corriger facilement les choses morceau par morceau comme avant, mais je me demande comment cela fonctionne dans un modèle intégré de ce type
J’imagine que, dans l’approche de Netflix, ils ajoutent un nouveau modèle puis retirent progressivement l’ancien
Ce n’est pas encore entièrement implémenté dans UDA, mais le plan est d’appliquer la même approche qu’avec Federated GraphQL
Ils prévoient d’introduire le modèle de gestion de la dépréciation qui a fait ses preuves avec Federated GraphQL, et ils ont déjà géré avec succès plus de 500 schémas GraphQL fédérés
L’essentiel de la roadmap consiste à suivre les consommateurs des projected models tout en gérant activement les cycles de dépréciation
J’ai le sentiment que, pour faire réussir un graphe unifié, il faut résoudre à la fois trois dimensions : le métier, la communication et la technique
Le problème de communication exige de briser la « subtile indépendance » des équipes autonomes
Il faut jouer un rôle de passerelle entre les équipes et analyser aussi leurs modèles de données
Le simple partage de schémas ne suffit pas ; il faut absolument mener un travail de concertation en interviewant directement les personnes concernées
L’aspect technique est en fait le plus simple, et il suffirait d’imposer un « schéma épais » comme Microsoft Graph
Ce processus demande énormément d’empathie et de patience
La résolution technique suppose une décision ferme de la direction ainsi qu’un véritable pouvoir d’exécution ; si chaque équipe peut continuer à agir librement, aucune idée ne servira à grand-chose
L’aspect métier est de loin le plus difficile
Changer d’un coup des processus et une terminologie optimisés depuis vingt ans est pratiquement impossible
Au final, cela ne vaut l’investissement colossal « sur toute une vie » que si l’adhésion de toute l’entreprise est totale
Je crois beaucoup à l’intérêt d’introduire un vocabulaire commun
Mais cela devient de plus en plus difficile à mesure qu’on élargit le périmètre à l’ensemble de l’entreprise, aux nouvelles acquisitions, aux différents processus métier et à la dimension temporelle
Construire rapidement une interface entre deux systèmes, passe encore, mais dans une entreprise avec plusieurs couches, on peut se demander qui serait capable de créer et surtout de maintenir durablement une base idéale cataloguant toutes les connaissances
La plupart des tentatives qui ont vraiment tenu dans le temps l’ont fait soit à un niveau très abstrait, soit en limitant strictement leur périmètre à des cas d’usage spécifiques
D’expérience, même lorsqu’on définit une entité à l’échelle de toute l’entreprise (par exemple l’entité officielle représentant une société), chaque département finit par devoir l’étendre, et il faut alors prendre des décisions politiques et optimistes sur la question de savoir si les nouveaux attributs doivent être utilisables par tous les départements ou seulement par celui qui les a ajoutés
Dès qu’on met à jour une entité officielle, il faut une gestion du changement rigoureuse, avec évaluation de l’impact global
Si c’est bien conçu dès le départ et soutenu par une culture organisationnelle rigoureuse, cela peut fortement réduire les coûts et les frictions, et dans le cas de Netflix, cela semble plausible
Wikidata est cité comme exemple unique de vocabulaire commun à grande échelle ayant réellement survécu
1,65 milliard de nœuds de graphe continuent de s’étendre sous un vocabulaire standardisé