- A Netflix enfrentava problemas de colaboração e qualidade de dados porque a modelagem de dados de domínios de negócio (como filmes, atores, séries etc.) era duplicada entre sistemas, inconsistente e baseada em terminologia não padronizada
- A UDA (Arquitetura de Dados Unificada) é uma infraestrutura baseada em grafo de conhecimento com o objetivo de “modelar uma vez, representar em qualquer lugar”, definindo conceitos de domínio uma única vez e projetando-os e conectando-os de forma consistente em diversos sistemas
- A UDA oferece suporte a geração automática de esquemas, mapeamento e automação da movimentação de dados do modelo de domínio para contêineres de dados (como GraphQL, Avro, Iceberg etc.)
- Usuários de negócio podem usar ferramentas baseadas em UDA, como Sphere e PDM, para explorar dados, gerar relatórios e gerenciar dados de referência apenas pesquisando termos
- Sobre tecnologias semânticas como RDF e SHACL, a Netflix aplica seu próprio metamodelo Upper para alcançar, ao mesmo tempo, colaboração em larga escala, governança, consistência de esquema e escalabilidade
O aumento da complexidade dos sistemas da Netflix e os desafios dos modelos de domínio
- À medida que os serviços da Netflix se expandiram para filmes, séries, jogos, eventos ao vivo, publicidade e mais, a complexidade dos sistemas que dão suporte a tudo isso também cresceu fortemente
- Conceitos centrais de negócio como
actor e movie passaram a ser definidos separadamente em diferentes sistemas (como Enterprise GraphQL Gateway, plataforma de gestão de ativos e media computing), operando de forma fragmentada, sem colaboração nem compartilhamento
- Isso gerou problemas como:
- Modelos duplicados e inconsistentes: a mesma entidade era redefinida em sistemas diferentes, dificultando evitar conflitos
- Inconsistência terminológica: mesmo dentro de um mesmo sistema, termos diferentes eram usados para a mesma coisa, ou o mesmo termo era reutilizado com sentidos distintos, causando confusão na comunicação
- Problemas de qualidade de dados: havia inconsistências e erros de referência entre inúmeros microsserviços, e a gestão de identificadores e chaves externas também era insuficiente, exigindo correções manuais
- Limites de conectividade: os relacionamentos dentro dos sistemas eram limitados, e a integração entre sistemas era fraca
- Para resolver isso, era necessária uma base que permitisse definir o modelo conceitual uma vez e reutilizá-lo em todos os lugares, conectando-o e integrando-o de fato aos sistemas e dados reais
Visão geral da UDA (Arquitetura de Dados Unificada)
- A UDA é uma plataforma baseada em conectividade de dados dentro da Content Engineering da Netflix
- Ela define modelos de domínio (conceitos de negócio) uma única vez para projetá-los de forma consistente em todos os sistemas, com suporte a automação, descoberta e interoperabilidade semântica
- Principais capacidades possibilitadas pela UDA:
- Registro e conexão de modelos de domínio: usa definições oficiais de conceitos como fonte única da verdade, evitando confusão entre equipes e modelagem duplicada
- Mapeamento entre modelos de domínio e contêineres de dados: expressa em estrutura de grafo os conceitos de negócio, onde os dados reais estão armazenados (bancos de dados, tabelas, serviços etc.) e como estão estruturados, facilitando o entendimento
- Conversão de modelos de domínio para linguagens de definição de esquema: conversão automática para GraphQL, Avro, SQL, RDF, Java e outros ambientes, reduzindo trabalho manual e erros
- Movimentação confiável de dados entre contêineres de dados: automatiza transformação e transferência de dados entre sistemas como entidades GraphQL, Data Mesh, CDC e Iceberg
- Exploração e busca de conceitos de domínio: permite navegar e pesquisar relações entre conceitos de negócio, facilitando obter informações precisas
- Introspecção programática do grafo de conhecimento: possibilita usar informações de negócio conectadas via Java, GraphQL e SPARQL para automação e geração de insights
Arquitetura central da UDA
-
Baseada em Knowledge Graph
- Um grafo de conhecimento baseado em RDF/SHACL conecta todos os elementos — modelos de domínio, esquemas, contêineres de dados e mapeamentos — como dados em grafo
- Com um modelo de informação centrado em named graphs, cada named graph segue um modelo de governança padronizado, permitindo estrutura de interpretação, modularização e políticas operacionais
-
Metamodelo Upper
- Upper é uma linguagem de metamodelo que define rigorosamente os modelos de domínio
- Ela modela entidades-chave, atributos e relacionamentos de cada domínio com tipos e hierarquias, podendo ser expressa em RDF, versionada e consultada
- O próprio Upper também é modelado em Upper (autorreferência, autovalidação), garantindo consistência em todas as extensões e projeções
- Os valores de atributos podem ser personalizados por domínio, e todos os conceitos são expressos como conceptual RDF e named graphs, com suporte a introspecção, busca e controle de versão
- Além de abstrações de alto nível, o Upper aplica apenas os elementos essenciais das tecnologias semânticas W3C, como RDFS/OWL/SHACL, permitindo modelar domínios com eficiência mesmo sem conhecimento profundo de ontologias
- A partir do metamodelo Upper, são gerados automaticamente uma API Java baseada em Jena e esquemas GraphQL, integrados a serviços GraphQL reais
-
Contêineres de dados e mapeamentos
- Data Container: o repositório real de dados (por exemplo, entidades de um serviço GraphQL, registros Avro de uma fonte Data Mesh, linhas de uma tabela Iceberg, objetos de uma API Java etc.)
- Mappings: definem a ligação direta entre elementos específicos do modelo de domínio e contêineres de dados (tabelas, campos etc.)
- Por meio dos mappings, é possível rastrear conceitos de domínio até a localização real dos dados e, no sentido inverso, explorar de dados para os conceitos de domínio relacionados
- Movimentação de dados e automação orientadas por intenção: o sistema usa as informações de mapeamento para decidir automaticamente fluxos e transformações de dados
-
Projections (projeções)
- Convertem e geram automaticamente modelos de domínio em esquemas dos sistemas de destino (como GraphQL, Avro etc.), automatizando código, esquemas e pipelines
- Garantem consistência de esquema e minimizam definições duplicadas e problemas de sincronização
Casos reais de aplicação
-
PDM (Primary Data Management)
- Plataforma de gerenciamento de dados de referência e taxonomias (sistemas hierárquicos de classificação)
- Converte modelos de domínio em classificações hierárquicas ou planas e gera automaticamente interfaces para usuários de negócio
- Fornece definições consistentes de termos de negócio, é baseada no modelo SKOS e usa a UDA para gerar automaticamente esquemas e pipelines em Avro e GraphQL
- Basta inserir o modelo de domínio para que UI, pipeline de dados e API GraphQL sejam configurados automaticamente
-
Sphere (Operational Reporting)
- Ferramenta de relatórios operacionais self-service baseada em grafo de conhecimento
- Automatiza busca por termos de domínio, navegação e estratégias de join, permitindo descoberta de dados e criação de relatórios sem complexidade técnica
- Com os metadados e mappings da UDA, o sistema identifica e executa automaticamente até a localização dos dados reais e a lógica de join
- Usando termos familiares como
actor e movie, é possível explorar conceitos e, com base nos conceitos selecionados, gerar automaticamente consultas SQL seguindo o grafo de conhecimento, obtendo dados sem necessidade de joins manuais ou trabalho técnico adicional
Conclusão e perspectivas
- A UDA está conduzindo uma mudança fundamental na forma como a Netflix modela e integra dados
- Com uma única definição de modelo de domínio, os sistemas de toda a organização podem se conectar aos dados de maneira consistente, automática e escalável
- No futuro, o escopo de aplicação deve se expandir com suporte adicional a Protobuf/gRPC e com a materialização de dados reais no grafo de conhecimento
2 comentários
Preciso montar algo parecido, mas estou meio perdido.
Comentários do Hacker News
Apesar de todas as vantagens, parece haver um grande problema nessa abordagem que não é mencionado com frequência
Como é um problema de negócio que também afeta problemas técnicos, ele acaba se tornando um problema técnico secundário que impacta a velocidade de desenvolvimento
Como o negócio passa a depender de um contrato em que toda a organização pode confiar em uma única definição integrada de dados, ao definir ou modificar dados agora é inevitável considerar não apenas a própria área, mas também diversos casos de uso de toda a organização
Até uma pequena mudança afeta a organização inteira, então surge um processo complexo que exige aprovação de várias partes interessadas
Esta é a versão de dados do problema clássico das grandes empresas: "por que levar dois meses para mudar a cor de um botão"
Claro, reconheço que normalmente duplicar dados ou espalhá-los de forma inconsistente é um problema ainda mais grave
Mas, às vezes, quando se quer implantar rapidamente uma mudança pequena e isolada, esse tipo de sistema vira um grande obstáculo
Já tentei desenvolver um produto para resolver isso
Tentei uma abordagem que permitisse seguir um modelo corporativo comum e, ao mesmo tempo, especializar facilmente o modelo localmente (estendendo uma linguagem de definição de dados parecida com Prolog e pensando de verdade em um modelo corporativo baseado na realidade, e não apenas no que parece necessário no momento)
Infelizmente, a tentativa aconteceu em plena febre de NoSQL e Big Data, então o timing não foi bom
NoSQL e Big Data traziam uma cultura em que se podia operar com modelos frouxos, e mesmo que alguns dados se perdessem ou fossem mal interpretados, dava para remendar depois
O clima era mais de facilitar o conserto posterior do que projetar um modelo forte desde o início, e, embora seja um pouco lamentável, acabei aceitando isso
Concordo que isso é essencialmente um problema de negócio, e acho que podemos resolvê-lo de forma sistemática com tecnologia
Tenho confiança de que criamos uma forma mais sistemática de introduzir e implantar grafos de conhecimento model-first dentro da empresa
O UDA é abordado com cuidado para não tornar burocrático tudo o que for solicitado
O UDA coexistirá com os sistemas existentes e não forçará adoção obrigatória
Mas a ideia é que ele seja uma ferramenta poderosa e fácil para equipes que querem que seus modelos de negócio sejam usados em qualquer lugar e possam ser conectados, estendidos e descobertos com facilidade
(Sou um dos arquitetos do UDA)
Pela minha experiência, muitas vezes não se cria um modelo de dados lógico ou consistente por causa das opiniões dos "figurões" dentro da empresa
Mesmo quando técnicos que lidam com a operação querem tratar os dados de forma mais racional e alinhada a padrões, a realidade é que pessoas influentes criam diretamente o modelo mental delas e obrigam os desenvolvedores a se ajustarem a ele
Quando esse tipo de pensamento simbólico se instala, a chance de surgir um modelo de dados consistente naquela empresa tende a zero
No fim, acho que é esse tipo de problema que leva a pagamentos absurdamente ineficientes para consultorias
Fiquei muito tempo me perguntando o que era SAP, e me surpreendi quando finalmente descobri
Como tantas empresas usam SAP, eu imaginava que houvesse uma capacidade técnica enorme, mas na prática descobri que a abordagem é ter um esquema fixo e exigir que o cliente se adapte àquela estrutura
Não me parece que o texto original negue que isso seja um problema de negócio
A perspectiva ali é que os modelos definidos são construídos cobrindo todos os papéis, e engenharia é apenas uma parte disso
Já faz bastante tempo desde que Semantic Web, RDF, OWL, SKOS etc. apareceram
Gostei de continuarem apoiando o W3C e de não reinventarem a roda
Não sei se a abordagem UDA vai se popularizar, mas parece promissora como tentativa de reduzir de forma inovadora as dificuldades de aplicar DDD (domain-driven design) e conceitos semânticos em organizações de grande porte
Se for possível fornecer a várias equipes de desenvolvimento um conjunto comum de ferramentas e tecnologias para compartilhar a mesma semântica de dados e obter um efeito de “juros compostos”, talvez não seja mais necessário achatar à força os contratos de dados em DTO, POST etc. por causa da transmissão em rede
Vejo com bons olhos a Netflix por tocar esse experimento interessante de forma pública
Isso me lembrou um projeto chamado Dragon na Uber
Já trabalhei em algo relacionado a Dragon schema at Uber, mas não chegou a virar open source
Depois Joshua foi para o LinkedIn, participou do projeto LambdaGraph e da linguagem Hydra, e eles foram publicados como open source aqui
O lado ruim dessas abordagens, e também da onda Semantic Web de 10 anos atrás, era a carga extra de trabalho necessária para formalizar e manter todos os conceitos
Hoje fico curioso se LLMs (grandes modelos de linguagem) poderiam reduzir esse peso
Achei infeliz a escolha do termo ‘modelo de domínio’ usada desta vez
Aqui, modelo de domínio é um conceito puramente centrado em dados, mas a essência da modelagem de domínio real está mais no comportamento do que na estrutura de dados
Os dados do modelo de domínio existem para viabilizar o comportamento, e o próprio comportamento é o centro do código
Há complexidade no próprio ato de expressar modelagem de dados de várias formas dependendo da perspectiva, mas talvez essa diferença possa até ser vista como um recurso
Nem toda situação exige o mesmo nível de complexidade ou granularidade, e modelos de representação em geral são otimizados para cenários de leitura
Ao usar esse tipo de abordagem, pode haver uma inclinação maior para uniformidade do que para o tratamento contextual da informação; talvez escale melhor em ambientes com alto entendimento de domínio, mas na prática tenho a experiência de que a maioria dos casos de uso fica difícil se não houver simplificação de modelos de domínio complexos ou sutis
A pergunta é: “você já viu alguma melhoria de negócio quantificável acima de 5% ou de 5 milhões de dólares com esse tipo de iniciativa?”
Já passei várias vezes por tentativas de unificar tabelas de dados, mas na prática, quando eram necessárias análises diferentes, a unificação das tabelas não fazia diferença, e as diversas análises continuavam sendo feitas separadamente
Ou seja, mesmo unificando a camada base para atender ao tipo de análise que todos querem, as análises diferentes continuam seguindo separadas
Ainda assim, esta tentativa parece sensata porque não tenta forçar tudo a se unificar em uma coisa só, e sim aumentar a facilidade de acesso amplo
Concordo muito com o objetivo de reduzir confusão ao alinhar definições formais de conceitos de negócio para todos
Por exemplo, mesmo que todos queiram uma lista mestra de prisões, a definição muda completamente dependendo de se a prisão é o prédio em si, o conjunto de presos (como entidades separadas para prisões masculina e feminina no mesmo terreno) ou uma instituição operada sob um contrato específico
Nesse sentido, cada perspectiva dentro da organização precisa de objetos sutilmente diferentes
Fico curioso sobre qual é a relação disso com domain-driven design (DDD)
No DDD, não se parte do princípio de que até o mesmo conceito pode ser representado de forma diferente em sistemas distintos?
Mas acabei não lendo o texto até o fim por causa da sensação de UML
O Domain de
upper:DomainModelé o mesmo D (domínio) do DDD, e o mesmo vale para DGS (Domain Graph Service)No DDD, permite-se que até o mesmo conceito seja representado de formas diferentes em sistemas simultaneamente, mas no UDA isso é projetado para que esses vários conceitos coexistam explicitamente dentro de cada domínio
O conceito de “ser o mesmo” se torna subjetivo
Ainda bem que não usaram o termo "ubiquitous language" (linguagem ubíqua)
Esse conceito é completamente oposto ao desta tentativa
Quem só ouviu falar vagamente do conceito, sem se aprofundar, talvez não perceba a diferença
Fico me perguntando por que a engenharia da Netflix publica conteúdo no Medium
Como o Medium perde leitores facilmente por causa de pop-ups e afins, fico em dúvida se vale a pena assumir esse risco
Sempre que vejo uma URL hexadecimal do Medium, me divirto lendo via scribe.rip
Artigo do UDA no scribe.rip
Se isso for operado pelo time de marketing, pode ser uma estratégia que inclui SEO
O efeito de “discovery” que o Medium oferece é real
E os engenheiros que escrevem no estilo de quem publica no Medium provavelmente são exatamente o tipo de talento que a Netflix quer recrutar
Também é mais prático por não precisar manter um blog próprio
Fico curioso sobre como eles lidam com versionamento de modelos ou breaking changes
Quando se opera com modelos mais separados, é fácil corrigir coisas em pedaços como sempre foi feito, então fico na dúvida de como isso funciona em um modelo tão integrado
Imagino que, na abordagem da Netflix, adicionem um novo modelo e depois descontinuem gradualmente o anterior
No UDA isso ainda não está totalmente implementado, mas o plano é aplicar a mesma abordagem do Federated GraphQL
Pretendem adotar o modelo de gerenciamento de depreciação já validado no Federated GraphQL, e têm experiência em administrar com sucesso mais de 500 esquemas de GraphQL federado
O ponto central é um roadmap para rastrear os consumidores dos projected models e gerenciar ativamente os ciclos de depreciação
Tenho a impressão de que, para um grafo unificado dar certo, é preciso resolver três coisas ao mesmo tempo: negócio, comunicação e tecnologia
O problema de comunicação exige quebrar a “independência silenciosa” das equipes autônomas
É preciso haver alguém que faça a ponte entre equipes diferentes e também analise os modelos de dados
Só compartilhar esquema não basta; é indispensável conversar diretamente com as pessoas e negociar por meio de entrevistas
O lado técnico na verdade é o mais fácil, e impor um “esquema grosso” como o Microsoft Graph torna isso simples
Esse processo exige muita empatia e paciência
A solução técnica depende necessariamente de decisão firme da liderança e autoridade de execução; se cada equipe puder agir totalmente por conta própria, nenhuma ideia funciona
O lado de negócio é o nível máximo de dificuldade
Trocar de uma vez processos e terminologias otimizados ao longo de 20 anos é, na prática, quase impossível
No fim, só vale investir nessa empreitada gigantesca “ao longo de uma vida inteira” se houver buy-in completo da empresa toda
Acredito que introduzir um vocabulário comum é algo muito significativo
Mas, quanto mais ampla a organização — empresa inteira, novas aquisições, diversos processos de negócio, eixo temporal etc. — mais difícil isso fica
Dá até para montar rapidamente uma interface para integrar apenas dois sistemas, mas, quando existem várias camadas dentro de uma empresa, fico em dúvida sobre quem conseguiria criar e manter continuamente um banco de dados ideal que colocasse todo o conhecimento em um catálogo
A maioria das tentativas que de fato sobreviveram operou de forma muito abstrata ou limitou o escopo a casos de uso específicos
Pela experiência, mesmo que se defina uma entidade corporativa comum a toda a empresa (por exemplo, a entidade oficial da empresa), cada departamento acaba precisando estendê-la, e aí surgem decisões políticas e otimistas sobre se novos atributos devem ser usados por todos os departamentos ou apenas por um deles
Atualizar a entidade oficial exige gestão rigorosa de mudanças, com avaliação do impacto total
Se isso for construído corretamente e apoiado por uma cultura organizacional disciplinada, custo e atrito podem cair bastante, e na Netflix isso parece possível
O único exemplo verdadeiramente duradouro de vocabulário comum em larga escala citado é o Wikidata
São 1,65 bilhão de nós de grafo continuando a crescer sob um vocabulário padrão