- Netflix को business domains (जैसे फ़िल्म, actor, series आदि) की data modeling में हर system में duplication, inconsistency और non-standard terminology के कारण collaboration और data quality से जुड़ी समस्याओं का सामना करना पड़ा
- UDA (Unified Data Architecture) का लक्ष्य है 'एक बार मॉडल करें, हर जगह अभिव्यक्त करें' — यह knowledge graph आधारित infrastructure है जो domain concepts को एक बार परिभाषित करके अलग-अलग systems में उन्हें एकसमान तरीके से project और connect करता है
- UDA domain model → data containers (जैसे GraphQL, Avro, Iceberg आदि) के लिए automatic schema generation, mapping और data movement automation को support करता है
- Business users, Sphere और PDM जैसे UDA-आधारित tools के ज़रिए, केवल terminology search करके data exploration, report generation और reference data management कर सकते हैं
- RDF, SHACL जैसी semantic technologies के ऊपर Netflix ने अपना Upper metamodel लागू किया है, जिससे large-scale collaboration, governance, schema consistency और scalability एक साथ हासिल होते हैं
Netflix systems की बढ़ती complexity और domain models की चुनौतियाँ
- Netflix की services जब फ़िल्म, series, games, live events और ads तक फैलीं, तो उन्हें support करने वाले systems की complexity भी काफ़ी बढ़ गई
actor, movie जैसे core business concepts अलग-अलग systems (Enterprise GraphQL Gateway, asset management platform, media computing आदि) में अलग-अलग परिभाषित किए गए, और बिना collaboration या sharing के fragmented तरीके से चलाए गए- इसके कारण नीचे जैसी समस्याएँ पैदा हुईं
- Duplicate और inconsistent models: अलग-अलग systems में एक ही entity को फिर से define किया गया, जिससे conflicts रोकना मुश्किल हुआ
- Terminology mismatch: एक ही system के भीतर भी अलग-अलग terms का उपयोग, या एक ही term का कई बार उपयोग, जिससे communication में confusion हुआ
- Data quality issues: कई microservices के बीच inconsistency और reference errors मौजूद थे; identifiers और foreign keys का management भी कमज़ोर था, इसलिए manual fixes की ज़रूरत पड़ती थी
- Connectivity limitations: systems के भीतर relationships सीमित थे और systems के बीच integration भी पर्याप्त नहीं था
- इन समस्याओं को हल करने के लिए, एक बार conceptual model define करके उसे हर जगह reuse करने और उसे real systems व data से व्यावहारिक रूप से connect और integrate करने वाली बुनियाद की ज़रूरत थी
UDA (Unified Data Architecture) का overview
- UDA Netflix Content Engineering के भीतर data connectivity आधारित platform है
- यह domain models (business concepts) को एक बार define करके सभी systems में consistent projection, automation, discovery और semantic interoperability को support करता है
- UDA से संभव मुख्य capabilities
- Domain model registration और connection: official concept definitions को single source की तरह उपयोग करके teams के बीच confusion और duplicate modeling को रोकना
- Domain models और data containers की mapping: business concepts और real data कहाँ stored है (database, table, service आदि) तथा उसकी structure को graph structure में दिखाना, ताकि आसानी से समझा जा सके
- Domain models को schema definition languages में transform करना: GraphQL, Avro, SQL, RDF, Java आदि अलग-अलग systems के लिए automatic transformation, जिससे manual काम कम हो और errors घटें
- Data containers के बीच reliable data movement: GraphQL entities, Data Mesh, CDC, Iceberg आदि systems के बीच data transformation और movement को अपने-आप handle करना
- Domain concepts की exploration और search: business concepts के बीच relationships को explore और search करने की सुविधा, जिससे सही जानकारी पाना आसान हो
- Knowledge graph के लिए programmatic introspection: Java, GraphQL, SPARQL के ज़रिए connected business information का उपयोग, automation और insights निकालना
UDA की core architecture
-
Knowledge Graph आधारित
- RDF/SHACL आधारित knowledge graph में domain models, schemas, data containers, mappings आदि सभी elements graph data के रूप में जुड़े होते हैं
- Named graph केंद्रित information model में हर named graph एक नियमबद्ध governance model का पालन करता है, और interpretation framework, modularization तथा operational policies को सक्षम बनाता है
-
Upper metamodel
- Upper domain models को सख़्ती से define करने वाली metamodel language है
- यह domain-specific key entities, attributes और relationships को type और hierarchy के रूप में model करती है, और उन्हें RDF में express, version-manage और query किया जा सकता है
- Upper को भी Upper से model किया गया है (self-reference, self-validation), जिससे सभी extensions और projections में consistency मिलती है
- Attribute values को domain-specific ढंग से customize किया जा सकता है, और सभी concepts को conceptual RDF तथा named graphs के रूप में व्यक्त किया जाता है, जिससे introspection, search और version management संभव होता है
- Upper, high-level abstraction के साथ RDFS/OWL/SHACL जैसी W3C semantic technologies के केवल ज़रूरी हिस्सों को चुनकर लागू करता है, इसलिए ontology concepts की गहरी जानकारी के बिना भी domain modeling प्रभावी ढंग से की जा सकती है
- Upper metamodel से Jena-आधारित Java API और GraphQL schema अपने-आप generate होते हैं, और वे real GraphQL services से जुड़े रहते हैं
-
Data containers और mappings
- Data Container: actual data storage units (जैसे GraphQL service की entities, Data Mesh source के Avro records, Iceberg table की rows, Java API objects आदि)
- Mappings: domain model के किसी specific element और data container (table, field आदि) के बीच one-to-one connection की definition
- Mappings के ज़रिए domain concepts → actual data location को trace किया जा सकता है, और उल्टा data → संबंधित domain concepts की exploration भी की जा सकती है
- Intent-based data movement/automation: mapping information का उपयोग करके system अपने-आप data flows और transformations तय करता है
-
Projections
- Domain model → target system schema (जैसे GraphQL, Avro आदि) में automatic transformation और generation (code, schema, pipeline automation)
- Schema consistency सुनिश्चित होती है, और duplicate definitions व synchronization issues कम से कम होते हैं
वास्तविक उपयोग के उदाहरण
-
PDM (Primary Data Management)
- Reference data और taxonomy (hierarchical classification system) management platform
- Domain models को hierarchical या flat classifications में बदलता है, और business users के लिए UI अपने-आप generate करता है
- Business terminology की consistent definitions, SKOS model आधारित setup, और UDA के ज़रिए Avro/GraphQL schemas तथा pipelines का automatic generation
- केवल domain model input देने पर UI, data pipeline और GraphQL API अपने-आप configure हो जाते हैं
-
Sphere (Operational Reporting)
- Knowledge graph आधारित self-service operational reporting tool
- Domain terminology आधारित search, exploration और join strategy automation के ज़रिए technical complexity के बिना data discovery और report generation संभव बनाता है
- UDA-आधारित metadata और mappings की मदद से system actual data locations और join logic को अपने-आप समझकर execute करता है
actor, movie जैसे परिचित terms से concepts को explore किया जा सकता है, और चुने गए concepts के आधार पर knowledge graph को follow करके SQL queries अपने-आप generate होती हैं; अलग से join या technical काम किए बिना data हासिल किया जा सकता है
निष्कर्ष और आगे की दिशा
- UDA, Netflix के data modeling और integration approach में बुनियादी बदलाव ला रहा है
- एक ही domain model definition के आधार पर, पूरे संगठन के systems में consistent, automated और scalable data integration संभव हो जाता है
- आगे चलकर Protobuf/gRPC जैसे अतिरिक्त support और knowledge graph को real data तक विस्तार देने की योजना है
2 टिप्पणियां
कुछ ऐसा ही बनाना है, लेकिन समझ नहीं आ रहा कि कहाँ से शुरू करें।
Hacker News राय
सभी फायदों के बावजूद, मुझे लगता है कि इस तरीके में एक बड़ी समस्या है जिसका अक्सर ज़िक्र नहीं होता
यह एक बिज़नेस समस्या है, लेकिन तकनीकी समस्या को भी प्रभावित करती है, और अंततः डेवलपमेंट की गति को प्रभावित करने वाली द्वितीयक तकनीकी समस्या बन जाती है
चूंकि पूरा संगठन एकीकृत डेटा परिभाषा पर भरोसा कर सके, इस अनुबंध पर बिज़नेस टिका होता है, इसलिए अब डेटा को परिभाषित या बदलते समय सिर्फ अपने क्षेत्र ही नहीं बल्कि पूरे संगठन के विविध उपयोग मामलों पर विचार करना अनिवार्य हो जाता है
छोटी-सी तब्दीली भी पूरे संगठन को प्रभावित कर सकती है, इसलिए कई हितधारकों की मंज़ूरी से गुजरने वाली जटिल प्रक्रिया बन जाती है
बड़े एंटरप्राइज़ में यह उस क्लासिक समस्या का डेटा संस्करण है कि "बटन का रंग बदलने में दो महीने क्यों लगते हैं"
बेशक, आम तौर पर डेटा की कॉपी बनाना या उसे असंगत रूप से बिखेर देना इससे भी बड़ी समस्या होती है, यह मैं मानता हूँ
लेकिन कभी-कभी जब आप छोटे और अलग-थलग बदलाव जल्दी deploy करना चाहते हैं, तो ऐसा सिस्टम बहुत बड़ी रुकावट बन जाता है
इसे हल करने के लिए मैंने एक प्रोडक्ट बनाने की कोशिश की थी
हमने ऐसा तरीका आज़माया जो कंपनी-स्तरीय कॉमन मॉडल का पालन करते हुए भी लोकल स्तर पर मॉडल को आसानी से विशेषीकृत करने दे सके (Prolog जैसी data definition language को विस्तार देना, और सिर्फ तुरंत की ज़रूरत नहीं बल्कि वास्तविकता-आधारित enterprise model पर सचमुच गंभीरता से सोचना)
दुर्भाग्य से, हमने यह उस समय किया जब NoSQL और Big Data का ज़ोर चरम पर था, इसलिए timing ठीक नहीं थी
NoSQL और Big Data की संस्कृति यह थी कि ढीले-ढाले मॉडल के साथ भी काम चल सकता है, और डेटा का कुछ हिस्सा खो जाए या गलत समझ लिया जाए तो बाद में पैबंद लगा देंगे
शुरुआती दौर में मज़बूत मॉडल डिज़ाइन करने से ज़्यादा, बाद में संभाल लेना आसान है — ऐसा माहौल था; थोड़ा अफ़सोस हुआ, लेकिन मान लिया
मैं इस बात से सहमत हूँ कि यह मूल रूप से एक बिज़नेस समस्या है, और हमारा मानना है कि टेक्नोलॉजी के ज़रिये इसे व्यवस्थित रूप से हल किया जा सकता है
हमें भरोसा है कि हमने enterprise के भीतर model-first knowledge graph को अपनाने और deploy करने का अधिक व्यवस्थित तरीका तैयार किया है
UDA इस बात को लेकर सावधान है कि जो कुछ भी माँगा जाए, वह सब कुछ और अधिक bureaucratic न बना दे
UDA मौजूदा सिस्टम्स के साथ-साथ मौजूद रहता है और किसी पर इसे अनिवार्य रूप से अपनाने का दबाव नहीं डालता
लेकिन जो टीमें चाहती हैं कि उनका बिज़नेस मॉडल हर जगह इस्तेमाल हो सके और आसानी से connect, extend और discover किया जा सके, उनके लिए इसे एक शक्तिशाली और आसान टूल बनाना लक्ष्य है
(मैं UDA architects में से एक हूँ, यह स्पष्ट कर दूँ)
मेरे अनुभव में, अक्सर कंपनी के भीतर "big men" के दावों की वजह से तार्किक या सुसंगत डेटा मॉडल बन ही नहीं पाते
भले ही प्रैक्टिकल इंजीनियर डेटा को ज़्यादा तार्किक और standards के अनुरूप संभालना चाहते हों, प्रभावशाली लोग अपने दिमाग़ में बना मॉडल थोप देते हैं और डेवलपर्स को उसी के हिसाब से ढलना पड़ता है
एक बार यह प्रतीकात्मक सोच भीतर बैठ जाए, तो उस कंपनी में सुसंगत डेटा मॉडल बन पाने की संभावना लगभग शून्य रह जाती है
आखिरकार, मेरी नज़र में इसी तरह की समस्याओं के कारण consultants को अक्षम तरीके से बहुत पैसा दिया जाता है
मैं लंबे समय तक सोचता रहा कि SAP आखिर है क्या, और जब सच में समझ आया तो हैरानी हुई
मैंने सोचा था कि इतनी सारी कंपनियाँ SAP इस्तेमाल करती हैं, तो ज़रूर इसमें जबरदस्त टेक्नोलॉजी होगी, लेकिन असल में यह एक fixed schema रखकर ग्राहकों से कहता है कि वे उसी ढाँचे के अनुसार खुद को ढालें
मूल लेख मुझे ऐसा नहीं लगा कि वह इसे बिज़नेस समस्या मानने से इनकार कर रहा है
मेरा समझना है कि परिभाषित मॉडल सभी भूमिकाओं को ध्यान में रखकर बनाए जाते हैं, और engineering उनमें से सिर्फ एक हिस्सा है
Semantic Web, RDF, OWL, SKOS वगैरह आए हुए काफ़ी समय हो चुका है
यह अच्छा लगा कि W3C का समर्थन जारी रखा गया और पहले से मौजूद पहिए को फिर से नहीं बनाया गया
पता नहीं UDA का तरीका व्यापक रूप से स्थापित होगा या नहीं, लेकिन बड़े संगठनों में DDD (Domain-Driven Design) और semantic concepts लागू करने की कठिनाइयों को क्रांतिकारी ढंग से कम करने की कोशिश के रूप में यह उम्मीद जगाता है
अगर कई डेवलपमेंट टीमों को डेटा के एक ही semantic system को साझा करने के लिए कॉमन टूल्स और टेक्नोलॉजी सेट मिल जाएँ, और उससे "compound interest" जैसा असर पैदा हो, तो शायद डेटा contracts को सिर्फ DTO, POST जैसी network transport ज़रूरतों के कारण ज़बरदस्ती सपाट नहीं करना पड़े
Netflix का इस तरह के दिलचस्प प्रयोग को खुले तौर पर आगे बढ़ाना सकारात्मक लगता है
इससे Uber का Dragon प्रोजेक्ट याद आता है
मैंने Dragon schema at Uber से जुड़ा काम किया था, लेकिन उसे open source नहीं किया जा सका
बाद में Joshua LinkedIn चले गए और LambdaGraph प्रोजेक्ट तथा Hydra भाषा पर काम में शामिल हुए, जो यहाँ open source के रूप में उपलब्ध हैं
इस तरह के तरीकों की, और 10 साल पहले के Semantic Web प्रवाह की भी, सबसे बड़ी कमी यह थी कि concepts को formalize और maintain करने का अतिरिक्त काम बहुत ज़्यादा था
अब जिज्ञासा है कि क्या LLMs (large language models) इस बोझ को कम कर सकते हैं
इस बार "domain model" शब्द का चयन थोड़ा खटकता है
यहाँ domain model पूरी तरह data-centric अवधारणा है, जबकि वास्तविक domain modeling का सार data structure नहीं बल्कि behavior पर फोकस करना होता है
domain model में data का काम behavior को संभव बनाना है, और behavior ही code का केंद्र होता है
data modeling को अलग-अलग दृष्टिकोणों से अलग तरह व्यक्त करने में जटिलता तो है, लेकिन मुझे लगता है कि यह अंतर अपने आप में एक feature भी हो सकता है
हर स्थिति में एक जैसी जटिलता या सूक्ष्मता की ज़रूरत नहीं होती, और representation model को सामान्यतः read scenarios के लिए optimize किया जाता है
इस तरीके का इस्तेमाल करने पर संदर्भानुसार जानकारी को संभालने की बजाय एकरूपता पर ज़्यादा ज़ोर आ सकता है; domain understanding गहरी हो तो scalability बेहतर लग सकती है, लेकिन मेरा अनुभव है कि जटिल या सूक्ष्म domain models को सरल किए बिना ज़्यादातर use cases संभालना मुश्किल हो जाता है
सवाल यह है: "क्या आपने ऐसे प्रयास से 5% से अधिक या $5M से अधिक का कोई मापनीय बिज़नेस सुधार देखा है?"
मैंने data tables को एकीकृत करने की कोशिशें कई बार देखी हैं, लेकिन व्यवहार में जब अलग-अलग analysis की ज़रूरत होती है, तो table integration का अर्थ कम रह जाता है और विभिन्न analyses फिर भी अलग-अलग ही चलते रहते हैं
यानी, भले ही सबकी मनचाही analysis शैली के अनुरूप base layer को एकीकृत कर दिया जाए, अलग-अलग analyses फिर भी अलग रास्ते से जारी रहते हैं
फिर भी, यह प्रयास ऐसा नहीं लगता कि सब कुछ एक में समेट देना चाहता है; बल्कि व्यापक पहुँच को आसान बनाना चाहता है, इसलिए समझदारी भरा लगता है
आधिकारिक बिज़नेस अवधारणाओं की परिभाषाओं को सबके लिए एकसमान बनाकर भ्रम कम करने के उद्देश्य से मैं गहराई से सहमत हूँ
उदाहरण के लिए, मान लीजिए सबको master prison list चाहिए, लेकिन prison की परिभाषा यह है कि क्या वह इमारत स्वयं है, कैदियों का समूह है (जैसे एक ही परिसर में पुरुष और महिला prison अलग-अलग इकाइयाँ हों), या किसी विशेष contract के तहत संचालित संस्था है — परिभाषा के आधार पर यह पूरी तरह बदल जाता है
इस अर्थ में, संगठन के अलग-अलग दृष्टिकोणों को सूक्ष्म रूप से अलग objects की ज़रूरत पड़ती है
जानना चाहता हूँ कि इसका Domain-Driven Design (DDD) से क्या संबंध है
DDD तो यह मानकर चलता है कि एक ही concept भी अलग-अलग systems में अलग ढंग से व्यक्त किया जा सकता है, है न?
हालांकि, लेख का UML जैसा एहसास होने के कारण मैं उसे अंत तक नहीं पढ़ पाया
upper:DomainModel में Domain का अर्थ DDD के D (domain) जैसा ही है, और DGS (Domain Graph Service) में भी वही है
DDD एक ही समय में एक ही concept की अलग-अलग system-specific representations को स्वीकार करता है, जबकि UDA इस तरह डिज़ाइन किया गया है कि हर domain के भीतर ये विविध अवधारणाएँ स्पष्ट रूप से साथ मौजूद रह सकें
"same" की अवधारणा अपने आप में subjective हो जाती है
अच्छा ही हुआ कि उन्होंने "ubiquitous language" शब्द का इस्तेमाल नहीं किया
यह अवधारणा इस प्रयास की अवधारणा से पूरी तरह उलट है
जो लोग सिर्फ संबंधित शब्द सुनकर रह गए हैं और गहराई में नहीं गए, वे शायद यह फर्क न समझें
यह सवाल उठता है कि Netflix Engineering अपनी सामग्री Medium पर क्यों डालता है
Medium के pop-ups वगैरह से पाठकों को आसानी से खोने का खतरा रहता है, तो क्या वह जोखिम उठाना वाकई सार्थक है?
जब भी hex वाला Medium URL दिखता है, तो उसे scribe.rip के ज़रिये पढ़ने में मज़ा आता है
scribe.rip UDA article
अगर इसे marketing team चला रही हो, तो संभव है इसमें SEO तक शामिल रणनीति हो
Medium का "discovery" प्रभाव वास्तव में होता है
और Medium पर लिखने की शैली वाले इंजीनियर वही प्रतिभा समूह हो सकते हैं जिन्हें Netflix recruit करना चाहता है
खुद ब्लॉग maintain नहीं करना पड़े, यह और भी सुविधाजनक है
सोच रहा हूँ कि data model की versioning या breaking changes को यह कैसे संभालता है
जब मॉडल अधिक बँटे हुए हों, तो पुराने तरीके से टुकड़ों में आसानी से बदलाव किया जा सकता है; ऐसे integrated model में यह कैसे होगा, यही सवाल है
मेरा अनुमान है कि Netflix के तरीके में नया मॉडल जोड़कर पुराने मॉडल को धीरे-धीरे retire किया जाता होगा
UDA में यह अभी पूरी तरह लागू नहीं हुआ है, लेकिन योजना Federated GraphQL जैसा ही तरीका अपनाने की है
Federated GraphQL में साबित हो चुके deprecation management model को अपनाया जाएगा, और 500 से अधिक federated GraphQL schemas को सफलतापूर्वक manage करने का अनुभव भी है
मुख्य बात यह है कि projected models के consumers को track करते हुए deprecated cycle को सक्रिय रूप से manage करने का roadmap तैयार है
एक integrated graph को सफल बनाने के लिए बिज़नेस, communication और technology — तीनों को हल करना पड़ता है, यह मैंने महसूस किया है
communication की समस्या में "autonomous teams की छिपी हुई स्वतंत्रता" को तोड़ना पड़ता है
कोई ऐसा चाहिए जो टीमों के बीच पुल का काम करे और data models का विश्लेषण भी कर सके
सिर्फ schema share कर देना काफ़ी नहीं; लोगों से सीधे interview करके समन्वय बनाना ज़रूरी है
तकनीकी पक्ष अपेक्षाकृत सबसे आसान है; Microsoft Graph की तरह "thick schema" लागू कर दें तो सरल हो सकता है
इस पूरी प्रक्रिया के लिए काफ़ी empathy और patience चाहिए
तकनीकी समाधान के लिए management का दृढ़ निर्णय और execution authority अनिवार्य है; अगर हर टीम को पूरी आज़ादी से चलने दिया जाए, तो कोई भी विचार काम नहीं आएगा
बिज़नेस पक्ष सबसे कठिन स्तर का है
20 साल में optimize हुए processes और terminology को एक साथ बदलना लगभग असंभव है
अंततः, पूरे संगठन का संपूर्ण buy-in मिले तभी यह विशाल काम "जीवन भर" के निवेश लायक बनता है
मेरा मानना है कि common vocabulary को अपनाना बहुत अर्थपूर्ण है
लेकिन जैसे-जैसे enterprise, नए acquisitions, अलग-अलग business processes और time axis का दायरा बढ़ता है, यह लगातार कठिन होता जाता है
दो systems को जोड़ने वाला interface तो शायद जल्दी बना लिया जाए, लेकिन किसी enterprise में कई layers मौजूद हों और एक ideal DB में सारा knowledge catalog करना हो, तो सवाल यह है कि उसे बनाए और लगातार बनाए रखे कौन
जो प्रयास सफलतापूर्वक टिके रहे हैं, वे ज़्यादातर या तो बहुत abstract स्तर पर संचालित हुए या किसी विशिष्ट use case तक सीमित रखे गए
अनुभव के आधार पर कहूँ तो, enterprise-wide entities (जैसे कंपनी की आधिकारिक entity) को परिभाषित करने के बाद भी हर विभाग को उन्हें extend करने की ज़रूरत पड़ती है, और फिर यह राजनीतिक तथा आशावादी निर्णय लेने पड़ते हैं कि नई properties सभी विभागों के लिए उपलब्ध हों या सिर्फ संबंधित विभाग के लिए
आधिकारिक entity को update करने पर पूरे प्रभाव का मूल्यांकन करते हुए कठोर change management चाहिए
अगर इसे सही तरीके से बनाया जाए और सख्त संगठनात्मक संस्कृति उसका समर्थन करे, तो लागत और friction काफ़ी कम हो सकते हैं; Netflix में यह संभव लगता है
बड़े पैमाने की common vocabulary का लगभग एकमात्र सफल उदाहरण Wikidata है
1.65 अरब graph nodes एक मानकीकृत vocabulary के तहत लगातार विस्तार पा रहे हैं