- Netflix enfrentaba problemas de colaboración y calidad de datos porque el modelado de datos de los dominios de negocio (por ejemplo, películas, actores, series, etc.) estaba duplicado entre sistemas, era inconsistente y usaba terminología no estandarizada
- UDA (Arquitectura de Datos Unificada) es una infraestructura basada en grafos de conocimiento cuyo objetivo es “modelar una vez y expresar en todas partes”, definiendo los conceptos del dominio una sola vez y proyectándolos y conectándolos de forma consistente en distintos sistemas
- UDA admite la generación automática de esquemas, el mapeo y la automatización del movimiento de datos desde el modelo de dominio hacia contenedores de datos (por ejemplo, GraphQL, Avro, Iceberg, etc.)
- Los usuarios de negocio pueden explorar datos, generar reportes y gestionar datos de referencia solo con buscar términos, mediante herramientas basadas en UDA como Sphere y PDM
- Sobre tecnologías semánticas como RDF y SHACL, aplica su propio metamodelo Upper para lograr al mismo tiempo colaboración a gran escala, gobernanza, consistencia de esquemas y escalabilidad
El aumento de la complejidad en los sistemas de Netflix y los desafíos de los modelos de dominio
- A medida que los servicios de Netflix se expandieron hacia películas, series, juegos, eventos en vivo, publicidad y más, la complejidad de los sistemas que los soportan también aumentó de forma importante
- Conceptos clave del negocio como
actor y movie se definían de forma independiente en distintos sistemas (Enterprise GraphQL Gateway, plataforma de gestión de activos, media computing, etc.) y se operaban de manera fragmentada, sin suficiente colaboración ni compartición
- Esto generó problemas como los siguientes
- Modelos duplicados e inconsistentes: la misma entidad se redefinía en distintos sistemas, dificultando evitar conflictos
- Inconsistencia terminológica: incluso dentro de un mismo sistema se usaban términos diferentes, o el mismo término se duplicaba con significados distintos, lo que generaba confusión en la comunicación
- Problemas de calidad de datos: había inconsistencias y errores de referencia entre numerosos microservicios, y la gestión de identificadores o claves externas también era deficiente, por lo que se requerían correcciones manuales
- Limitaciones de conectividad: relaciones restringidas dentro de cada sistema y poca integración entre sistemas
- Para resolver estos problemas, se necesitaba una base que permitiera definir el modelo conceptual una sola vez y reutilizarlo en todas partes, conectándolo e integrándolo de manera real con los sistemas y datos existentes
Resumen de UDA (Arquitectura de Datos Unificada)
- UDA es una plataforma basada en conectividad de datos dentro de Content Engineering de Netflix
- Define una sola vez el modelo de dominio (conceptos de negocio) para proyectarlo de forma consistente en todos los sistemas, y habilita automatización, descubrimiento e interoperabilidad semántica
- Funcionalidades principales que UDA hace posibles
- Registro y conexión de modelos de dominio: usa definiciones oficiales de conceptos como fuente única para evitar confusión entre equipos y modelado duplicado
- Mapeo entre modelos de dominio y contenedores de datos: representa en una estructura de grafo tanto los conceptos de negocio como la ubicación y estructura de los datos reales donde se almacenan (bases de datos, tablas, servicios, etc.) para que puedan entenderse fácilmente
- Conversión del modelo de dominio a lenguajes de definición de esquemas: conversión automática a distintos sistemas como GraphQL, Avro, SQL, RDF y Java, reduciendo trabajo manual y errores
- Movimiento confiable de datos entre contenedores de datos: procesamiento automático de transformación y traslado de datos entre sistemas como entidades GraphQL, Data Mesh, CDC e Iceberg
- Exploración y búsqueda de conceptos de dominio: permite explorar y buscar relaciones entre conceptos de negocio, facilitando obtener información precisa
- Introspección programática del grafo de conocimiento: aprovecha información de negocio conectada mediante Java, GraphQL y SPARQL para automatización y obtención de insights
Arquitectura central de UDA
-
Basada en Knowledge Graph
- Con un grafo de conocimiento basado en RDF/SHACL, conecta como datos de grafo todos los elementos: modelos de dominio, esquemas, contenedores de datos y mapeos
- Con un modelo de información centrado en named graphs, cada named graph sigue un modelo de gobernanza con reglas, lo que permite un marco de interpretación, modularización y políticas operativas
-
Metamodelo Upper
- Upper es un lenguaje de metamodelado que define estrictamente los modelos de dominio
- Modela por tipo y jerarquía las entidades, atributos y relaciones clave de cada dominio, y puede expresarse, versionarse y consultarse en RDF
- El propio Upper también está modelado con Upper (autorreferencia y autovalidación), lo que aporta consistencia a todas las extensiones y proyecciones
- Permite personalización por dominio para valores de atributos, y todos los conceptos se expresan como conceptual RDF y named graphs, habilitando introspección, búsqueda y control de versiones
- Junto con un alto nivel de abstracción, Upper aplica de forma selectiva solo los elementos esenciales de tecnologías semánticas W3C como RDFS/OWL/SHACL, de modo que se puede modelar el dominio eficazmente sin necesidad de dominar conceptos ontológicos
- A partir del metamodelo Upper se generan automáticamente una API de Java basada en Jena y un esquema GraphQL, integrados con servicios GraphQL reales
-
Contenedores de datos y mapeos
- Data Container: repositorio de datos real (por ejemplo, entidades de un servicio GraphQL, registros Avro de una fuente de Data Mesh, filas de una tabla Iceberg, objetos de una API de Java, etc.)
- Mappings: definen una conexión uno a uno entre elementos específicos del modelo de dominio y contenedores de datos (tablas, campos, etc.)
- Mediante los mapeos, se puede rastrear desde un concepto de dominio hasta la ubicación de los datos reales, y a la inversa, explorar desde los datos hacia los conceptos de dominio relacionados
- Movimiento de datos y automatización basados en intención: usando la información de mapeo, el sistema decide automáticamente el flujo y la transformación de datos
-
Projections (proyecciones)
- Transformación y generación automáticas del modelo de dominio hacia esquemas del sistema objetivo (por ejemplo, GraphQL, Avro, etc.), automatizando código, esquemas y pipelines
- Garantiza consistencia de esquemas y minimiza definiciones duplicadas y problemas de sincronización
Casos de uso reales
-
PDM (Primary Data Management)
- Plataforma de gestión de datos de referencia y taxonomías (sistemas de clasificación jerárquica)
- Convierte modelos de dominio en clasificaciones jerárquicas o planas, y genera automáticamente interfaces para usuarios de negocio
- Definición consistente de términos de negocio, basada en el modelo SKOS, con generación automática de esquemas y pipelines de Avro y GraphQL mediante UDA
- Con solo ingresar el modelo de dominio, se configuran automáticamente la UI, los pipelines de datos y la API GraphQL
-
Sphere (Operational Reporting)
- Herramienta de reportería operativa self-service basada en grafos de conocimiento
- Automatiza búsquedas, exploración y estrategias de join basadas en términos del dominio, permitiendo descubrir datos y crear reportes sin complejidad técnica
- Con metadatos y mapeos basados en UDA, el sistema identifica y ejecuta automáticamente incluso la ubicación real de los datos y la lógica de joins
- Permite explorar conceptos con términos familiares como
actor y movie, y con base en los conceptos seleccionados genera automáticamente consultas SQL siguiendo el grafo de conocimiento, para obtener datos sin joins manuales ni trabajo técnico adicional
Conclusión y perspectivas
- UDA está impulsando un cambio fundamental en la forma en que Netflix modela e integra datos
- Con una sola definición del modelo de dominio, los sistemas de toda la organización pueden integrarse de forma consistente, automatizada y escalable
- En el futuro se planea ampliar su alcance con soporte adicional para Protobuf/gRPC, entre otros, y con la incorporación de datos reales al grafo de conocimiento
2 comentarios
Tengo que armar algo parecido, pero me siento perdido.
Comentarios de Hacker News
A pesar de todas las ventajas, parece que este enfoque tiene un gran problema del que no se habla mucho
Es un problema de negocio que también afecta al aspecto técnico, así que termina convirtiéndose en un problema técnico secundario que impacta la velocidad de desarrollo
Como el negocio depende del contrato de que toda la organización pueda confiar en una única definición integrada de los datos, ahora al definir o modificar datos no queda otra que considerar no solo el propio ámbito, sino también los diversos casos de uso de toda la organización
Incluso un cambio pequeño afecta a toda la organización, así que surgen procesos complejos que requieren la aprobación de múltiples partes interesadas
Esta es la versión de datos del clásico problema en grandes empresas de “por qué cambiar el color de un botón toma dos meses”
Claro, reconozco que normalmente duplicar datos o dispersarlos de forma inconsistente es un problema aún más grave
Pero a veces, cuando quieres desplegar rápido un cambio pequeño y aislado, este tipo de sistema se vuelve un gran obstáculo
Intenté desarrollar un producto para resolver esto
Probé un enfoque que permitía seguir un modelo corporativo común y al mismo tiempo especializar fácilmente el modelo a nivel local (extendiendo un lenguaje de definición de datos parecido a Prolog, y pensando de verdad en un modelo corporativo basado en la realidad, no en lo que parecía necesario en el momento)
Lamentablemente, lo intenté en plena fiebre de NoSQL y Big Data, así que el momento no fue bueno
NoSQL y Big Data ven normal operar con modelos flexibles, y existe una cultura de que si parte de los datos se pierde o se malinterpreta, luego se puede parchear
En vez de diseñar un modelo sólido desde el inicio, predominaba la idea de que arreglarlo después era fácil; es una pena, pero lo acepté
Coincido en que esto es, en esencia, un problema de negocio, y creemos que se puede resolver de forma sistemática con tecnología
Tenemos confianza en que establecimos una forma más estructurada de introducir y desplegar un knowledge graph model-first dentro de la empresa
UDA se aborda con cuidado para no volver más burocrático todo lo que se solicite
UDA coexiste con los sistemas existentes y no fuerza su adopción incondicional
Pero queremos que sea una herramienta potente y fácil para los equipos que desean que su modelo de negocio pueda usarse en todas partes y que sea fácil de conectar, extender y descubrir
(Aclaro que soy uno de los arquitectos de UDA)
Por experiencia, recuerdo muchos casos en los que no se terminaba construyendo un modelo de datos lógico o consistente por culpa de lo que decían los “big men” dentro de la empresa
Aunque los técnicos de campo intentaban tratar los datos de forma más racional y conforme a estándares, la realidad era que una figura influyente armaba directamente su propio modelo mental y obligaba a los desarrolladores a ajustarse a él
Una vez que esa forma de pensar simbólica se instala, la probabilidad de que esa empresa llegue a tener un modelo de datos consistente se acerca a cero
Al final, creo que por este tipo de problemas se termina pagando a consultores cantidades ineficientemente altas de dinero
Durante mucho tiempo me pregunté qué era SAP, y cuando por fin lo entendí me sorprendió
Como muchísimas empresas usan SAP, asumía que tendría una tecnología impresionante, pero en realidad descubrí que funciona con un esquema fijo y exige que el cliente se adapte a esa estructura
No me parece que el texto original niegue que esto sea un problema de negocio
La perspectiva es que los modelos definidos se establecen a través de todos los roles, y la ingeniería es solo una parte de eso
Ha pasado bastante tiempo desde que aparecieron Semantic Web, RDF, OWL, SKOS y demás
Me gustó que siguieran apoyando a W3C y no reinventaran ruedas que ya existen
No sé si el enfoque UDA vaya a volverse algo masivo, pero genera expectativa como un intento de reducir de forma innovadora las dificultades de aplicar DDD (diseño guiado por dominio) y conceptos semánticos en organizaciones grandes
Si se puede ofrecer a varios equipos de desarrollo una herramienta y un conjunto tecnológico común para compartir el mismo sistema de significado de los datos, podría lograrse un efecto de “interés compuesto” sin tener que aplanar a la fuerza los contratos de datos por culpa de DTO, POST u otros mecanismos de transporte de red
Veo con buenos ojos que Netflix impulse y publique un experimento tan interesante
Me recordó a un proyecto llamado Dragon en Uber
Había trabajado en algo relacionado con Dragon schema at Uber, pero no llegó a open source
Después Joshua se fue a LinkedIn y participó en el proyecto LambdaGraph y el lenguaje Hydra, que fueron publicados como open source aquí
La desventaja de este tipo de enfoque, igual que la ola de Semantic Web de hace 10 años, era la enorme carga adicional de trabajo para formalizar y mantener los conceptos
Hoy me pregunto si los LLM (modelos de lenguaje grandes) podrán reducir esa carga
Me decepcionó un poco la elección del término “modelo de dominio” en este caso
Aquí el modelo de dominio es un concepto puramente centrado en datos, pero el modelado de dominio real se centra esencialmente en el comportamiento (Behavior), más que en la estructura de datos
Los datos dentro de un modelo de dominio existen para habilitar comportamientos, y el comportamiento en sí es el centro del código
Hay complejidad en expresar el modelado de datos de distintas maneras según la perspectiva, pero creo que esa diferencia incluso puede verse como una ventaja
No todas las situaciones requieren el mismo nivel de complejidad o detalle, y normalmente los modelos de representación se optimizan para escenarios de lectura
Con este enfoque, uno podría inclinarse más hacia la uniformidad que hacia el tratamiento contextual de la información; quizá escale mejor en entornos con alta comprensión del dominio, pero en la práctica he visto que la mayoría de los casos de uso se vuelven difíciles si no se simplifican modelos de dominio complejos o sutiles
La pregunta de si alguien ha visto una mejora de negocio cuantificable de “más del 5% o más de 5 millones de dólares” con este tipo de intentos
Había vivido varios intentos de unificar tablas de datos, pero en la práctica, si se necesitaban análisis distintos, entonces unificar las tablas no servía de mucho y los distintos análisis seguían haciéndose por separado
Es decir, aunque se unifique la capa base para ajustarla a la forma de análisis que todos quieren, los análisis diferentes igual continúan avanzando por separado
Aun así, este intento parece inteligente porque no busca forzar que todo quede unificado en uno solo, sino facilitar un acceso amplio
Me identifico mucho con el objetivo de unificar las definiciones formales de los conceptos de negocio para reducir la confusión
Por ejemplo, aunque todos quieran una lista maestra de prisiones, una prisión puede significar el edificio en sí, un conjunto de reclusos (como entidades separadas de prisión de hombres y prisión de mujeres dentro del mismo predio), o una institución operada bajo un contrato específico; según la definición, cambia por completo
En ese sentido, cada perspectiva dentro de la organización necesita objetos sutilmente distintos
Me pregunto qué relación tiene esto con el diseño guiado por dominio (DDD)
En DDD, ¿no se parte de que incluso el mismo concepto puede representarse de forma distinta según el sistema?
Pero no leí el texto hasta el final porque daba una vibra muy de UML
El Domain de
upper:DomainModeles el mismo que la D (dominio) de DDD, y lo mismo aplica a DGS (Domain Graph Service)En DDD se permite que incluso el mismo concepto se represente de manera distinta según el sistema al mismo tiempo, pero en UDA está diseñado para que estas distintas conceptualizaciones coexistan explícitamente dentro de cada dominio
El concepto de “igualdad” se vuelve subjetivo
Casi mejor que no hayan usado el término "ubiquitous language" (lenguaje ubicuo)
Ese concepto es completamente opuesto a este intento
Quien solo haya oído los términos relacionados sin profundizar podría no notar la diferencia
Me pregunto por qué Netflix Engineering publica contenido en Medium
Dado que Medium puede ahuyentar lectores fácilmente con sus popups y demás, me pregunto si realmente vale la pena asumir ese riesgo
Cada vez que veo una URL hex de Medium me divierto leyéndola por scribe.rip
Artículo de UDA en scribe.rip
Si lo maneja el equipo de marketing, quizá sea una estrategia que también incluye SEO
El efecto de “descubrimiento” (discovery) que da Medium sí existe
Y es posible que los ingenieros que escriben en Medium sean justo el tipo de talento que Netflix quiere reclutar
También es más cómodo porque no tienen que mantener su propio blog
Me pregunto cómo manejan el versionado del modelo de datos o los breaking changes
Cuando los modelos se operan de forma más separada, se pueden corregir fácilmente por partes como siempre, así que tengo curiosidad por cómo funciona eso en un modelo integrado de este tipo
Supongo que en el enfoque de Netflix agregan un nuevo modelo y luego van retirando el anterior de manera gradual
En UDA todavía no está completamente implementado, pero planean aplicar el mismo enfoque que en Federated GraphQL
Piensan adoptar el modelo de gestión de deprecation que ya ha sido probado en Federated GraphQL, y tienen experiencia administrando con éxito más de 500 esquemas federados de GraphQL
La clave es una hoja de ruta para rastrear a los consumidores de projected models y gestionar activamente los ciclos de deprecation
La sensación es que para que un grafo unificado tenga éxito hay que resolver tres cosas: negocio, comunicación y tecnología
El problema de comunicación requiere romper la “independencia implícita” de los equipos autónomos
Hay que cumplir un papel de puente entre equipos y además analizar los modelos de datos
No basta con compartir esquemas; es indispensable sentarse a entrevistar directamente a las personas y negociar
El aspecto técnico en realidad es el más fácil, y si impones un “esquema grueso” como Microsoft Graph puede simplificarse
Todo este proceso requiere bastante empatía y paciencia
La solución técnica también exige decisiones firmes de la dirección y autoridad de ejecución; si cada equipo puede moverse libremente, ninguna idea sirve de mucho
El aspecto de negocio es el de mayor dificultad
Cambiar de una sola vez procesos y terminología optimizados durante 20 años es, en realidad, casi imposible
Al final, solo si existe un buy-in realmente total a nivel de toda la empresa vale la pena esta tarea enorme como inversión “para toda la vida”
Creo que introducir un vocabulario común es muy valioso
Pero a medida que la organización se amplía —toda la empresa, nuevas adquisiciones, distintos procesos de negocio, el eje temporal— se vuelve cada vez más difícil
Hacer una interfaz entre solo dos sistemas puede resolverse rápido, pero cuando dentro de una empresa hay muchas capas, me cuesta imaginar quién podría construir y mantener continuamente una base de datos ideal que catalogue todo el conocimiento
La mayoría de los intentos que han sobrevivido lo han hecho operando de forma muy abstracta o limitando el alcance a casos de uso específicos
Por experiencia, incluso si defines una entidad corporativa común para toda la empresa (por ejemplo, la entidad oficial de una compañía), cada departamento termina necesitando extenderla, y surgen decisiones políticas y optimistas sobre si un atributo nuevo debe poder usarse en toda la empresa o solo en ese departamento
Actualizar la entidad oficial requiere una gestión de cambios rigurosa y evaluar el impacto total
Si se construye correctamente y va respaldado por una cultura organizacional estricta, los costos y la fricción pueden reducirse mucho, y en Netflix parece plausible
Se menciona a Wikidata como el único ejemplo realmente superviviente de un vocabulario común a gran escala
Sigue expandiéndose bajo un vocabulario estándar con 1.65 mil millones de nodos de grafo