डेटा इंजीनियरिंग इंटरव्यू: डेटा लिनिएज (Data Lineage) सिस्टम डिज़ाइन करें

प्रश्न और प्रासंगिक संदर्भ

आपकी कंपनी में Airflow, Spark, dbt और Kafka पर प्रतिदिन 30,000 डेटासेट्स और 200,000 पाइपलाइन रन होते हैं। टीमों को तीन सवालों के जवाब देने की आवश्यकता है: कोई डेटासेट या फ़ील्ड कहाँ से आया, किसी प्रस्तावित बदलाव से क्या प्रभावित होगा, और किसी विशेष निष्पादन (execution) द्वारा कौन से आउटपुट उत्पन्न किए गए थे। एक ऐसा लिनिएज सिस्टम डिज़ाइन करें जो टेबल- और कॉलम-स्तरीय निर्भरताओं को कैप्चर करे, अपस्ट्रीम और डाउनस्ट्रीम ट्रैवर्सल का समर्थन करे, पिछले समय के लिनिएज का पुनर्निर्माण करे, पुनः प्रयासों (retries) और विफल या आंशिक रन को संभाले, मेटाडेटा एक्सेस लागू करे, और यह उजागर करे कि ग्राफ़ भरोसा करने लायक पूर्ण है या नहीं।

इंटरव्यू के लिए मान लें कि इवेंट इनजेशन पीक पर 500 इवेंट्स प्रति सेकंड है, तीन-हॉप (three-hop) ट्रैवर्सल आमतौर पर 2 सेकंड के भीतर पूरा होना चाहिए, और विस्तृत निष्पादन इतिहास 1 वर्ष के लिए बनाए रखा जाता है। ये परिदृश्य इनपुट हैं, उद्योग के बेंचमार्क नहीं। डिज़ाइन में यह स्पष्ट होना चाहिए कि वास्तविक ट्रैफ़िक देखने के बाद सीमाओं को कैसे मापा और संशोधित किया जाएगा।

वर्तमान 2026 डेटा-इंजीनियरिंग इंटरव्यू सामग्री सीधे उम्मीदवारों से पूछती है कि वे डेटा लिनिएज के लिए कैसे डिज़ाइन करते हैं और टेबल, कॉलम, जॉब स्तरों, मेटाडेटा कैप्चर, नामकरण और बदलाव के प्रभाव (change impact) को रेखांकित करती है। OpenLineage 1.50.0 एक उपयोगी तथ्यात्मक आधार रेखा प्रदान करता है: Job, Run और Dataset मुख्य इकाइयाँ हैं; नेमस्पेस और नाम Jobs और Datasets की पहचान करते हैं; एक Run UUID का उपयोग करता है; रन इवेंट्स के निश्चित लाइफ़साइकिल स्टेट्स होते हैं; और फ़ैसेट्स (facets) स्कीमा और कॉलम निर्भरताओं के साथ मॉडल का विस्तार करते हैं। श्रेणी data है क्योंकि केंद्रीय क्षमताएँ मेटाडेटा मॉडलिंग, पाइपलाइन सिमेंटिक्स, इम्पैक्ट एनालिसिस और डेटा गवर्नेंस हैं।

इंटरव्यूअर क्या मूल्यांकन करता है

पहला संकेत यह है कि क्या उम्मीदवार पहचान और सिमेंटिक्स (identity and semantics) से शुरुआत करता है। एक ग्राफ़ अनुपयोगी हो जाता है जब वही टेबल orders, prod.orders और एक वेयरहाउस URL के रूप में दिखाई देती है, या जब किसी पुनः प्रयास (retry) को गलती से एक नया जॉब मान लिया जाता है। ग्राफ़ डेटाबेस चुनने से पहले स्थिर संसाधन कुंजियाँ (stable resource keys), पर्यावरण सीमाएँ (environment boundaries), जॉब परिभाषाएँ, निष्पादन आईडी, फ़ील्ड पाथ और संस्करण सिमेंटिक्स स्थापित किए जाने चाहिए।

दूसरा संकेत यह है कि क्या लिनिएज निष्पादन की वास्तविकता को दर्शाता है। सोर्स कोड से घोषित लिनिएज (declared lineage) रिलीज़ से पहले मदद करता है; वास्तविक रन से देखा गया लिनिएज (observed lineage) यह साबित करता है कि क्या पढ़ा और लिखा गया था। एक विफल रन अस्थायी या आंशिक आउटपुट लिख सकता है, जबकि एक सफल निष्पादन स्थिति अभी भी डेटा की शुद्धता साबित नहीं करती है। एक मजबूत डिज़ाइन इवेंट साक्ष्य, रन स्थिति, घोषित किनारों (declared edges), प्रेक्षित किनारों (observed edges) और प्रकाशन स्थिति (publication state) को अलग रखता है।

तीसरा संकेत सिस्टम डिज़ाइन की गहराई है। उम्मीदवार को प्रोड्यूसर इंटीग्रेशन, एक टिकाऊ और इडेम्पोटेंट (idempotent) इनजेशन पाथ, अपरिवर्तनीय रॉ इवेंट्स (immutable raw events), सामान्यीकरण (normalization), टेम्पोरल ग्राफ़ मटीरियलाइज़ेशन, ट्रैवर्सल इंडेक्स, ताज़गी और कवरेज मेट्रिक्स, बैकफ़िल और एक्सेस कंट्रोल को कवर करना चाहिए। केवल यह कहना कि "इसे ग्राफ़ डेटाबेस में डाल दें" सबसे कठिन समस्याओं को छोड़ देता है।

अंत में, इंटरव्यूअर कैलिब्रेटेड विश्वास चाहता है। गायब इंस्ट्रूमेंटेशन दृश्यमान रहना चाहिए। महत्वपूर्ण जॉब्स के 60% हिस्से से तैयार किया गया एक साफ-सुथरा ग्राफ़ खतरनाक है यदि UI इसे पूर्ण के रूप में प्रस्तुत करता है। मजबूत उत्तर प्रोवेनेंस (उत्पत्ति), प्रेक्षण समय, आत्मविश्वास, कवरेज और कमियों (gaps) को उजागर करते हैं ताकि उपयोगकर्ता यह तय कर सकें कि क्या परिनियोजन (deployment) निर्णय के लिए इम्पैक्ट क्वेरी पर्याप्त है।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• लिनिएज को किन निर्णयों का समर्थन करना चाहिए? घटना निदान (incident diagnosis), प्री-डिप्लॉयमेंट इम्पैक्ट एनालिसिस, गवर्नेंस डिस्कवरी, PII प्रोपेगेशन और ऑडिट साक्ष्य की ताज़गी, इतिहास और शुद्धता की आवश्यकताएं अलग-अलग होती हैं।
• डेटासेट के रूप में क्या गिना जाता है? टेबल्स, व्यूज, फ़ाइलें, ऑब्जेक्ट प्रीफ़िक्स, Kafka टॉपिक्स, मटीरियलाइज़्ड व्यूज, डैशबोर्ड्स और मशीन-लर्निंग फ़ीचर्स को स्पष्ट ग्रैन्युलैरिटी की आवश्यकता होती है। हर फ़ाइल को एक नोड के रूप में मानने से एक अनुपयोगी ग्राफ़ बन सकता है।
• क्या हमें घोषित (declared), प्रेक्षित (observed) या दोनों प्रकार के लिनिएज की आवश्यकता है? घोषित लिनिएज निष्पादन से पहले भविष्य के बदलाव दिखा सकता है; प्रेक्षित लिनिएज इनपुट्स और आउटपुट्स को एक ठोस Run से जोड़ सकता है। UI को चुपचाप उनके अर्थों का विलय नहीं करना चाहिए।
• आवश्यक फ़ील्ड-स्तरीय सटीकता क्या है? प्रत्यक्ष मान व्युत्पत्ति (direct value derivation) जॉइन, फ़िल्टर, ग्रुपिंग, सॉर्ट, विंडो या कंडीशन के माध्यम से अप्रत्यक्ष प्रभाव से भिन्न होती है। कुछ इंजन एक लॉजिकल प्लान उजागर करते हैं; अन्य केवल टेबल लिनिएज उजागर करते हैं।
• विभिन्न एनवायरनमेंट्स में डेटासेट्स और जॉब्स की पहचान कैसे की जाती है? नेमस्पेस, कैनोनिकल नाम, उपनाम (aliases), केस नियम, नाम परिवर्तन और स्वामित्व को परिभाषित करें। एक डिस्प्ले लेबल एक टिकाऊ प्राइमरी की (primary key) नहीं है।
• विफल या आंशिक रन के बाद क्या होना चाहिए? स्पष्ट करें कि क्या आंशिक रूप से लिखे गए आउटपुट प्रकाशित, अलग (isolated) या रोल बैक किए गए हैं और क्या इम्पैक्ट एनालिसिस में उन्हें साक्ष्य, वर्तमान सत्य या दोनों के रूप में शामिल किया जाना चाहिए।
• पॉइंट-इन-टाइम इतिहास कब तक क्वेरी करने योग्य रहना चाहिए? रन इवेंट्स के एक वर्ष के इतिहास का मतलब यह नहीं है कि कम-विलंबता वाली सर्विंग लेयर में प्रत्येक विस्तारित कॉलम किनारे के एक वर्ष की आवश्यकता हो।
• कौन सा मेटाडेटा संवेदनशील है? SQL टेक्स्ट, फ़ील्ड नाम, स्वामित्व, PII टैग और डेटासेट का अस्तित्व संरक्षित जानकारी प्रकट कर सकते हैं। ट्रैवर्सल परिणामों को कैटलॉग के समान ही प्राधिकरण (authorization) अनुशासन की आवश्यकता होती है।
• स्केल और सेवा उद्देश्य क्या हैं? इवेंट दर, ग्राफ़ का आकार, ट्रैवर्सल गहराई, विलंबता प्रतिशतक (latency percentile), रिकवरी-पॉइंट ऑब्जेक्टिव और रन तथा दृश्यमान लिनिएज के बीच स्वीकार्य देरी की पुष्टि करें।

30-सेकंड उत्तर रूपरेखा

"मैं कैनोनिकल Job, Run, Dataset और Field पहचानकर्ताओं को मॉडल करूँगा, फिर घोषित को प्रेक्षित से और टेबल को कॉलम लिनिएज से अलग करूँगा। प्रोड्यूसर्स एक टिकाऊ लॉग द्वारा समर्थित एक प्रमाणित, इडेम्पोटेंट गेटवे के माध्यम से वर्ज़न किए गए इवेंट्स का उत्सर्जन करते हैं। उपभोक्ता रॉ साक्ष्य बनाए रखते हैं और टेम्पोरल अपस्ट्रीम और डाउनस्ट्रीम इंडेक्स बनाते हैं; प्रकाशन की पुष्टि होने तक विफल आउटपुट डायग्नोस्टिक रहते हैं। ट्रैवर्सल गहराई, समय और अनुमति द्वारा सीमित होते हैं और प्रोवेनेंस तथा कमियों को उजागर करते हैं। मैं लैग, अपेक्षित-जॉब कवरेज, टर्मिनल-इवेंट पूर्णता, अनसुलझी पहचान, पुराने किनारों और सैंपल किए गए पाथ सटीकता को मापूँगा, विश्वसनीय कॉलम निष्कर्षण जोड़ने से पहले महत्वपूर्ण पाइपलाइनों के लिए टेबल लिनिएज लॉन्च करूँगा।"

चरण-दर-चरण गहन उत्तर

चरण 1: स्टोरेज इंजन से पहले सत्य मॉडल (truth model) को परिभाषित करें।

चार प्रकार के रिकॉर्ड का उपयोग करें:

नेमस्पेस Dataset के लिए डेटा स्रोत से और Job के लिए शेड्यूलर या प्रोसेसिंग सिस्टम से आना चाहिए। उपनामों (aliases) को वैधता अंतराल (validity intervals) के साथ एक अलग मैपिंग में रखें। analytics.orders का नाम बदलकर analytics.sales_orders करने से स्ट्रिंग समानता के आधार पर चुपचाप पहचान नहीं बननी चाहिए या उसका विलय नहीं होना चाहिए; इसके लिए एक स्पष्ट रीनेम या उपनाम इवेंट की आवश्यकता होती है।

संकलित SQL, dbt मैनिफ़ेस्ट या कॉन्फ़िगरेशन से प्राप्त घोषित लिनिएज (declared lineage) को Run द्वारा उत्सर्जित प्रेक्षित लिनिएज (observed lineage) से अलग मॉडल करें। टेबल किनारों को फ़ील्ड किनारों से अलग मॉडल करें। एक फ़ील्ड किनारा आउटपुट फ़ील्ड, इनपुट फ़ील्ड, ट्रांसफ़ॉर्मेशन प्रकार और यह रिकॉर्ड करता है कि क्या निर्भरता प्रत्यक्ष मान व्युत्पत्ति है या अप्रत्यक्ष प्रभाव। OpenLineage का कॉलम मॉडल प्रत्यक्ष पहचान, ट्रांसफ़ॉर्मेशन और एग्रीगेशन को अप्रत्यक्ष जॉइन, ग्रुप, फ़िल्टर, सॉर्ट, विंडो और कंडीशन प्रभावों से अलग करता है। यह अंतर तब मायने रखता है जब यह तय करना हो कि किसी फ़ील्ड के मान, प्रकार या उपलब्धता को बदलने से आउटपुट प्रभावित होता है या नहीं।

प्रत्येक किनारे में validFrom, वैकल्पिक validTo, observedAt, प्रोड्यूसर, स्रोत इवेंट, Job वर्ज़न, Run ID, रन स्थिति, लिनिएज प्रकार, और आत्मविश्वास या व्युत्पत्ति विधि शामिल होनी चाहिए। ये विशेषताएँ एक अयोग्य तीर (arrow) को ऐसे साक्ष्य में बदल देती हैं जो "कब तक का?" और "किसके अनुसार?" का उत्तर दे सकता है।

चरण 2: निष्पादन के यथासंभव निकट लिनिएज कैप्चर करें।

जहाँ उपलब्ध हों, नेटिव या मेंटेन किए गए इंटीग्रेशन्स का उपयोग करें: टास्क लाइफ़साइकिल के लिए ऑर्केस्ट्रेशन श्रोता (listeners), Spark लॉजिकल-प्लान इंस्ट्रूमेंटेशन, dbt आर्टिफ़ैक्ट्स और रन परिणाम, और वेयरहाउस तथा स्ट्रीमिंग सिस्टम के लिए कनेक्टर्स या क्वेरी इतिहास। SQL के विरुद्ध regex की तुलना में पार्स किए गए या इंजन द्वारा निर्मित लॉजिकल प्लान को प्राथमिकता दें। डायनेमिक SQL, मैक्रोज़, स्टोर्ड प्रोसीजर्स, अस्थायी ऑब्जेक्ट्स, यूज़र-डिफ़ाइंड फ़ंक्शन्स और रनटाइम ब्रांच चयन स्ट्रिंग पार्सिंग को अधूरा बना देते हैं।

लिनिएज पेलोड के चारों ओर एक वर्ज़न किया गया इनजेशन एनवेलप परिभाषित करें:

{
  "eventId": "producer-unique-id",
  "producer": "spark-prod-eu",
  "schemaVersion": "1.0",
  "emittedAt": "2026-07-19T00:00:00Z",
  "job": { "namespace": "spark-prod", "name": "daily_orders" },
  "runId": "53ee3770-86fa-4cb9-8c31-a09072dd88f7",
  "state": "COMPLETE",
  "inputs": [{ "namespace": "warehouse-prod", "name": "raw.orders" }],
  "outputs": [{ "namespace": "warehouse-prod", "name": "mart.daily_orders" }]
}

eventId इडेम्पोटेंसी के लिए इस प्लेटफ़ॉर्म एनवेलप की एक आवश्यकता है; यह दावा न करें कि यह प्रत्येक बाहरी लिनिएज मानक में एक अनिवार्य फ़ील्ड है। प्रोड्यूसर्स उसी ID के साथ डिलीवरी का पुनः प्रयास करते हैं। गेटवे प्रोड्यूसर को प्रमाणित करता है, स्कीमा अनुकूलता और आकार सीमाओं की जाँच करता है, प्राप्ति समय जोड़ता है, और स्वीकार करने से पहले इवेंट को एक पार्टीशन किए गए टिकाऊ लॉग में लिखता है। अमान्य इवेंट्स एक कारण, प्रोड्यूसर और सुरक्षित पेलोड संदर्भ के साथ एक क्वारंटाइन स्ट्रीम में जाते हैं; वे लॉग्स में गायब नहीं होते हैं।

Run ID द्वारा पार्टीशन करना असंबंधित रन को वितरित करते हुए Run के स्थानीय क्रम को सुरक्षित रखता है। इवेंट का समय देर से या विषम हो सकता है, इसलिए उपभोक्ता उत्सर्जित और प्राप्त दोनों समय संग्रहीत करता है और लाइफ़साइकिल नियम लागू करता है। OpenLineage START, RUNNING, COMPLETE, ABORT, FAIL, और OTHER को परिभाषित करता है; टर्मिनल इवेंट्स को देर से आने वाले START द्वारा पूर्ववत (undo) नहीं किया जाना चाहिए। अपरिवर्तनीय इवेंट को तब भी बनाए रखें जब यह मटीरियलाइज़्ड वर्तमान स्थिति को नहीं बदलता है।

चरण 3: प्रोवेनेंस को नष्ट किए बिना सामान्यीकृत करें।

एक नॉर्मलाइज़र प्रत्येक इंटीग्रेशन के पेलोड को कैनोनिकल पहचान और किनारा सिमेंटिक्स में परिवर्तित करता है। यह पंजीकृत उपनामों, केस सम्मेलनों, पर्यावरण, अस्थायी डेटासेट्स और नेस्टेड फ़ील्ड पाथ्स को हल करता है। अज्ञात पहचानों का अनुमान लगाने के बजाय उन्हें एक अनसुलझी कतार (unresolved queue) में डाला जाता है। रॉ इवेंट, सामान्यीकृत रिकॉर्ड, रिज़ॉल्वर वर्ज़न और कोई भी चेतावनियाँ जुड़ी रहती हैं ताकि किसी खराब मैपिंग को ठीक किया जा सके और दोबारा चलाया जा सके।

स्कीमा परिवर्तन वर्ज़न किए गए फ़ील्ड परिभाषाएँ बनाते हैं। customer_id को हटाना और बाद में फिर से बनाना निरंतर फ़ील्ड इतिहास को नहीं दर्शाता है। एक स्कीमा हैश या कैटलॉग वर्ज़न और वैधता अंतराल पॉइंट-इन-टाइम क्वेरीज़ को सही फ़ील्ड चुनने की अनुमति देता है। स्ट्रीमिंग पाइपलाइनों के लिए, स्थिर ग्रैन्युलैरिटी पर टॉपिक और ट्रांसफ़ॉर्मेशन Job रिकॉर्ड करें; प्रत्येक पार्टीशन-ऑफ़सेट युग्म को एक स्थायी ग्राफ़ नोड में विस्फोट करने के बजाय पार्टीशन्स और ऑफ़सेट्स को Run साक्ष्य के रूप में बनाए रखें।

निष्पादन स्थिति को सावधानी से संभालें। COMPLETE का अर्थ है कि Job निष्पादन समाप्त हो गया; यह आउटपुट की व्यावसायिक गुणवत्ता को प्रमाणित नहीं करता है। एक FAIL या ABORT इवेंट अभी भी इनपुट्स और प्रयास किए गए आउटपुट्स की रिपोर्ट कर सकता है। निदान के लिए उन प्रेक्षित किनारों को संग्रहीत करें, लेकिन वर्तमान प्रकाशित लिनिएज को केवल तभी मटीरियलाइज़ करें जब आउटपुट प्रकाशन नीति संतुष्ट हो। उस नीति के लिए एक परमाणु कमिट मार्कर (atomic commit marker) या एक अलग गुणवत्ता गेट की आवश्यकता हो सकती है। इसे स्पष्ट रूप से लेबल करें।

चरण 4: उद्देश्य-अनुकूल इंडेक्स के साथ एक इवेंट-सोर्स्ड टेम्पोरल ग्राफ़ बनाएं।

टिकाऊ लॉग और अपरिवर्तनीय ऑब्जेक्ट-स्टोर संग्रह रिकवरी के स्रोत हैं। उपभोक्ता तीन प्रोजेक्शन बनाते हैं:

1. कैनोनिकल Jobs, Datasets, Fields, स्कीमा, उपनामों, मालिकों और एक्सेस नीतियों के लिए एक मेटाडेटा स्टोर।
2. वैधता अंतराल और निष्पादन प्रोवेनेंस के साथ घोषित और प्रेक्षित लिनिएज के लिए एक टेम्पोरल किनारा स्टोर।
3. लाइफ़साइकिल इवेंट्स, इनपुट/आउटपुट स्नैपशॉट, स्थिति और नैदानिक विवरणों के लिए एक Run स्टोर।

एक पुनरुत्पादक प्रथम-पास क्षमता अनुमान दैनिक Run गणना को इवेंट थ्रूपुट के साथ भ्रमित होने से रोकता है। न्यूनतम रूप से, 200,000 Runs में से प्रत्येक के लिए एक START और एक टर्मिनल इवेंट प्रति दिन 400,000 इवेंट्स उत्पन्न करता है, जो औसतन लगभग 4.6 प्रति सेकंड है। यदि एक सामान्य Run एक START, दो RUNNING अपडेट और एक टर्मिनल इवेंट उत्सर्जित करता है, तो वह प्रति दिन 800,000 हो जाता है, लगभग 9.3 प्रति सेकंड; इसलिए 500-प्रति-सेकंड इनपुट एक बर्स्ट लक्ष्य है, औसत नहीं। 20 KB के माने गए औसत रॉ पेलोड के साथ, 800,000 इवेंट्स के लिए कम्प्रेशन और रेप्लिकेशन से पहले प्रति दिन लगभग 16 GB या प्रति वर्ष 5.8 TB की आवश्यकता होती है। पेलोड आकार और प्रति Run इवेंट्स को मापा जाना चाहिए क्योंकि कॉलम फ़ैसेट्स इस अनुमान को काफी हद तक बदल सकते हैं।

कम-विलंबता वाले इम्पैक्ट क्वेरीज़ के लिए, कैनोनिकल नोड ID और समय बकेट या सक्रिय संस्करण द्वारा की (key) किए गए डाउनस्ट्रीम और अपस्ट्रीम एडजैसेंसी इंडेक्स दोनों को बनाए रखें। ब्रेड्थ-फ़र्स्ट ट्रैवर्सल (breadth-first traversal) में स्पष्ट अधिकतम गहराई, नोड गणना, किनारे का प्रकार, एनवायरनमेंट और समय सीमा होती है। यदि कोई सीमा पहुँच जाती है तो सेवा आंशिक-परिणाम संकेतक लौटाती है। एक ग्राफ़ डेटाबेस इसे लागू कर सकता है, लेकिन यह अनिवार्य नहीं है; उपयुक्त इंडेक्स वाली रिलेशनल एज टेबल्स या एक की-वैल्यू एडजैसेंसी सेवा इस पैमाने पर सरल हो सकती है। चुनने से पहले वास्तविक फ़ैनआउट और पॉइंट-इन-टाइम प्रेडिकेट्स का बेंचमार्क करें।

कॉलम लिनिएज टेबल लिनिएज से बहुत बड़ा हो सकता है। टेबल किनारों को हॉट प्रोजेक्शन में स्टोर करें, अक्सर क्वेरी किए जाने वाले फ़ील्ड एडजैसेंसी को हॉट रखें, और पुराने या कम-उपयोग वाले विस्तृत किनारों को एक कंप्रेस्ड ऐतिहासिक स्टोर में रखें। पूर्ण सकर्मक समापन (transitive closure) की पहले से गणना न करें: घने ग्राफ़ इसे अपडेट और अधिकृत करने के लिए महंगा बनाते हैं। नोड, दिशा, गहराई, समय, एज-काइंड फ़िल्टर और प्राधिकरण दायरे द्वारा सीमित क्वेरी परिणामों को कैश करें; संबंधित किनारा संस्करण बदलने पर उन्हें अमान्य करें।

चरण 5: क्वेरी अनुबंध को स्पष्ट बनाएं।

API को निम्नलिखित का समर्थन करना चाहिए:

• गहराई और समय के बिंदु द्वारा सीमित किसी Dataset या Field के लिए अपस्ट्रीम या डाउनस्ट्रीम ट्रैवर्सल;
• प्रस्तावित स्कीमा या फ़ील्ड परिवर्तन के लिए इम्पैक्ट एनालिसिस, जिसमें प्रत्यक्ष और अप्रत्यक्ष निर्भरताओं को अलग किया गया हो;
• Run लुकअप जो सटीक इनपुट, आउटपुट, Job संस्करण, लाइफ़साइकिल और प्रकाशन स्थिति दिखाता है;
• प्रत्येक लौटाए गए किनारे पर प्रोवेनेंस, जिसमें घोषित बनाम प्रेक्षित और अंतिम प्रेक्षण समय शामिल है;
• गैर-इंस्ट्रूमेंटेड Jobs, अनसुलझी पहचानों, पुराने प्रोड्यूसर्स और ट्रंकेटेड ट्रैवर्सल के लिए गैप मार्कर।

प्राधिकरण केवल ट्रैवर्सल के बाद लागू नहीं किया जा सकता है। किसी छिपे हुए Dataset का नाम या अस्तित्व अपने आप में संवेदनशील हो सकता है। विस्तार के दौरान कॉलर की नीति को हल करें, गवर्नेंस नियमों के अनुसार संरक्षित नोड्स को छोड़ दें या बदलें, डिग्री काउंट्स को छिपे हुए पड़ोसियों को लीक करने से रोकें, और संवेदनशील ट्रैवर्सल का ऑडिट करें। कैश कुंजियों में प्राधिकरण दायरा शामिल होता है ताकि एक उपयोगकर्ता का ग्राफ़ कभी दूसरे को न दिया जाए।

2-सेकंड के तीन-हॉप उद्देश्य के लिए, दिशा, गहराई, फ़ैनआउट, टेम्पोरल फ़िल्टर और कॉलम बनाम टेबल क्वेरी द्वारा P50, P95 और P99 को मापें। सीमित नोड बजट पार होने पर एक प्रतिक्रिया एक निरंतरता टोकन (continuation token) या एक स्पष्ट ट्रंकेशन लौटा सकती है। चुपचाप एक अधूरा ग्राफ़ लौटाना अस्वीकार्य है।

चरण 6: रीप्ले, बैकफ़िल और डिजास्टर रिकवरी डिज़ाइन करें।

उपभोक्ता टिकाऊ-लॉग ऑफ़सेट को चेकपॉइंट करते हैं। चूँकि प्रोसेसिंग कम से कम एक बार (at least once) होती है, प्रोजेक्शन राइट्स इडेम्पोटेंसी के लिए eventId और प्रोजेक्शन संस्करण का उपयोग करते हैं। एक सामान्यीकरण बग को एक नया रिज़ॉल्वर संस्करण तैनात करके, रॉ इवेंट्स से एक शैडो प्रोजेक्शन में पुनर्निर्माण करके, गणना और नमूना पाथ्स की तुलना करके, और सत्यापन के बाद पाठकों को स्विच करके ठीक किया जाता है। पूर्ण रीप्ले के दौरान एकमात्र सर्विंग ग्राफ़ को अधिलेखित (overwrite) न करें।

एन्क्रिप्शन और लाइफ़साइकिल नीति के साथ, आवश्यक 1 वर्ष के लिए अपरिवर्तनीय स्टोरेज में रॉ इवेंट्स बनाए रखें। पुनर्प्राप्ति समय को कम करने के लिए कैनोनिकल मेटाडेटा और एज प्रोजेक्शन का स्नैपशॉट लें, लेकिन साबित करें कि स्नैपशॉट और बाद के इवेंट्स वही परिणाम उत्पन्न करते हैं। पुनर्प्राप्ति उद्देश्यों को परिभाषित करें, एक इनजेशन क्षेत्र के नुकसान का परीक्षण करें, और सत्यापित करें कि निर्माता पुनः प्रयास अतिरिक्त किनारे नहीं बनाते हैं।

पॉइंट-इन-टाइम लिनिएज किनारे की वैधता और प्रेक्षण समय का उपयोग करता है, न कि वर्तमान ग्राफ़ और टाइमस्टैम्प लेबल का। पिछले महीने की एक क्वेरी को उस समय मान्य पहचानों, स्कीमा संस्करणों और अधिकृत किनारों को हल करना चाहिए। यदि किसी स्रोत ने कभी इतिहास उत्सर्जित नहीं किया है, तो उसका आविष्कार करने के बजाय उस सीमा को वापस लौटाएँ।

चरण 7: उत्पाद गुण के रूप में विश्वास को मापें।

कम से कम इन मेट्रिक्स को ट्रैक करें:

कवरेज के लिए एक हर (denominator) की आवश्यकता होती है। केवल प्राप्त इवेंट्स की संख्या की नहीं, बल्कि शेड्यूलर की इन्वेंट्री या वेयरहाउस क्वेरी इतिहास के विरुद्ध लिनिएज-उत्सर्जक Runs की तुलना करें। विश्वास बैज प्रकाशित करें जैसे "12 मिनट पहले देखा गया," "केवल घोषित," "कॉलम लिनिएज अनुपलब्ध," या "17 में से 2 अपस्ट्रीम Jobs गैर-इंस्ट्रूमेंटेड।" एक अपारदर्शी कॉन्फिडेंस स्कोर से बचें जो विफलता मोड को छुपाता है।

पहचान, एग्रीगेशन, जॉइन, फ़िल्टर, रीनेम, रीट्राई, विफलता और आंशिक-प्रकाशन मामलों वाले नियतात्मक (deterministic) पाइपलाइन फिक्स्चर के साथ मान्य करें। प्रोडक्शन में, हाल के रन का नमूना लें और इंजन योजना, उत्सर्जित इवेंट, सामान्यीकृत किनारे और क्वेरी परिणाम की एंड-टू-एंड तुलना करें। प्रत्येक प्रोजेक्शन रिलीज़ के दौरान नोड और एज काउंट का मिलान करें।

चरण 8: निर्णय मूल्य के आधार पर रोल आउट करें।

व्यावसायिक रूप से महत्वपूर्ण डोमेन और टेबल-स्तरीय लिनिएज से शुरुआत करें। कैनोनिकल पहचान और मालिकों को पंजीकृत करें, उच्चतम प्रभाव वाले शेड्यूलर और इंजनों को इंस्ट्रूमेंट करें, और व्यापक इम्पैक्ट एनालिसिस का वादा करने से पहले ताज़गी और कवरेज को उजागर करें। फिर विश्वसनीय लॉजिकल प्लान, प्री-डिप्लॉयमेंट घोषित लिनिएज, इतिहास और PII प्रोपेगेशन वाले इंजनों के लिए कॉलम लिनिएज जोड़ें।

सफलता को निर्णयों द्वारा मापा जाता है: उपयोगी प्री-डिप्लॉयमेंट इम्पैक्ट रिपोर्ट वाले महत्वपूर्ण परिवर्तनों का प्रतिशत, उन घटनाओं का प्रतिशत जिनकी पहली खराब अपस्ट्रीम सीमा की पहचान की जा सकती है, अनसुलझी पहचानों में कमी, और महत्वपूर्ण प्रोड्यूसर्स का कवरेज। नोड गणना और एक दृष्टि से घना ग्राफ़ सफलता के मेट्रिक्स नहीं हैं।

उच्च गुणवत्ता वाला नमूना उत्तर

"मैं निर्णयों और पहचानों को परिभाषित करके शुरुआत करूँगा। इस प्रणाली के लिए, एक Dataset या Job को एक एनवायरनमेंट के भीतर कैनोनिकल नेमस्पेस और नाम द्वारा पहचाना जाता है, एक Field एक कैनोनिकल पाथ और स्कीमा संस्करण जोड़ता है, और एक Run एक UUID द्वारा पहचानी जाने वाली एक निष्पादन प्रक्रिया है। उपनाम और नाम परिवर्तन स्पष्ट, समयबद्ध मैपिंग हैं। मैं संकलित योजनाओं से घोषित लिनिएज को निष्पादन से प्रेक्षित लिनिएज से अलग रखूँगा, और टेबल निर्भरताओं को फ़ील्ड निर्भरताओं से अलग रखूँगा।

संग्रह के समय, Airflow, Spark, dbt और प्रासंगिक Kafka प्रोसेसिंग फ्रेमवर्क में मेंटेन किए गए इंटीग्रेशन एक वर्ज़न किया गया पेलोड उत्सर्जित करते हैं। Spark और SQL इंजनों को जहाँ संभव हो लॉजिकल प्लान का उपयोग करना चाहिए क्योंकि regex डायनेमिक SQL, जॉइन, मैक्रोज़ या रनटाइम शाखाओं को विश्वसनीय रूप से नहीं समझ सकता है। प्रत्येक प्लेटफ़ॉर्म एनवेलप में एक प्रोड्यूसर-विशिष्ट इवेंट ID, प्रोड्यूसर, स्कीमा संस्करण, Job पहचान, Run ID, लाइफ़साइकिल स्थिति और इनपुट व आउटपुट शामिल होते हैं। इनजेशन गेटवे प्रोड्यूसर को प्रमाणित करता है, पेलोड को मान्य करता है, और स्वीकार करने से पहले इसे एक टिकाऊ लॉग में जोड़ता है। उसी इवेंट ID की बार-बार डिलीवरी इडेम्पोटेंट होती है; अमान्य इवेंट्स एक दृश्यमान क्वारंटाइन कतार में जाते हैं।

रॉ इवेंट अपरिवर्तनीय है। एक नॉर्मलाइज़र पंजीकृत उपनामों को हल करता है और स्रोत इवेंट और रिज़ॉल्वर संस्करण को बनाए रखते हुए वर्ज़न किए गए Jobs, Datasets, Fields और किनारे बनाता है। यह कभी भी किसी अज्ञात पहचान का अनुमान नहीं लगाता है। Run स्थिति सर्विंग को प्रभावित करती है: START और RUNNING साक्ष्य जोड़ सकते हैं, जबकि COMPLETE, ABORT और FAIL टर्मिनल हैं। विफल Runs निदान के लिए उपलब्ध रहते हैं, लेकिन उनके प्रयास किए गए आउटपुट को वर्तमान प्रकाशित लिनिएज के रूप में तब तक बढ़ावा नहीं दिया जाता जब तक कि एक स्वतंत्र प्रकाशन मार्कर यह न कहे कि डेटा दृश्यमान हो गया है। COMPLETE निष्पादन के पूरा होने को साबित करता है, डेटा की शुद्धता को नहीं।

उपभोक्ता एक कैनोनिकल मेटाडेटा स्टोर, एक टेम्पोरल एज स्टोर और एक Run स्टोर बनाते हैं। अपस्ट्रीम और डाउनस्ट्रीम दोनों एडजैसेंसी इंडेक्स सीमित ब्रेड्थ-फ़र्स्ट ट्रैवर्सल का समर्थन करते हैं। प्रत्येक किनारे में वैधता अंतराल, प्रेक्षण समय, प्रोड्यूसर, Job संस्करण, Run, स्थिति, घोषित-या-प्रेक्षित प्रकार और प्रत्यक्ष-या-अप्रत्यक्ष फ़ील्ड रूपांतरण होता है। एक पॉइंट-इन-टाइम क्वेरी उस समय मान्य पहचानों और किनारों का चयन करती है। मैं एक सार्वभौमिक सकर्मक समापन (universal transitive closure) की पहले से गणना नहीं करूँगा क्योंकि उच्च फ़ैनआउट, बदलते संस्करण और प्राधिकरण इसे महंगा और जोखिम भरा बनाते हैं।

30,000 डेटासेट्स और 200,000 Runs प्रति दिन के लिए, 500 पीक इवेंट्स प्रति सेकंड इतना मामूली है कि इसे एक टिकाऊ पार्टीशन वाले लॉग और इंडेक्स किए गए रिलेशनल या की-वैल्यू प्रोजेक्शन के साथ शुरू किया जा सके, फिर वास्तविक फ़ैनआउट के विरुद्ध ग्राफ़-विशिष्ट स्टोरेज का बेंचमार्क किया जा सके। कॉलम किनारे बड़ा आयाम हैं, इसलिए हाल ही में और अक्सर पूछे जाने वाले एडजैसेंसी हॉट रहते हैं जबकि विस्तृत पुराने इतिहास को कंप्रेस किया जा सकता है। तीन-हॉप, 2-सेकंड के लक्ष्य को ग्राफ़ प्रकार और फ़ैनआउट द्वारा P50, P95 और P99 पर मापा जाता है। प्रत्येक अनुरोध में गहराई और नोड बजट होते हैं और यह एक स्पष्ट निरंतरता या ट्रंकेशन मार्कर लौटाता है।

क्वेरी सेवा ग्राफ़ विस्तार के दौरान प्राधिकरण करती है। इसे छिपे हुए नोड नाम, अस्तित्व या पड़ोसी गणना को लीक नहीं करना चाहिए, और इसकी कैश कुंजी में कॉलर का नीति दायरा शामिल होता है। प्रतिक्रिया में प्रोवेनेंस और दृश्यमान अंतराल शामिल होते हैं: केवल घोषित, प्रेक्षित समय, अनसुलझी पहचान, पुराने प्रोड्यूसर्स, गायब कॉलम लिनिएज और गैर-इंस्ट्रूमेंटेड Jobs।

मैं प्रोजेक्शन को रीप्ले करने योग्य बनाऊँगा। रॉ इवेंट्स को 1 वर्ष के लिए बनाए रखा जाता है। उपभोक्ता ऑफ़सेट को चेकपॉइंट करते हैं और इडेम्पोटेंट तरीके से लिखते हैं। रिज़ॉल्वर या स्कीमा बग्स को एक शैडो प्रोजेक्शन का पुनर्निर्माण करके, सक्रिय प्रोजेक्शन के विरुद्ध इसका मिलान करके, ज्ञात पाथ्स का परीक्षण करके और केवल सत्यापन के बाद स्विच करके ठीक किया जाता है। स्नैपशॉट रिकवरी को छोटा करते हैं लेकिन नियतात्मक पुनर्निर्माण साबित करने के लिए बाद के इवेंट्स के साथ परीक्षण किए जाते हैं।

अंत में, मैं अपेक्षित-जॉब कवरेज, टर्मिनल-इवेंट पूर्णता, पहचान-समाधान विफलताओं, एज फ्रेशनेस, महत्वपूर्ण टेबल और कॉलम कवरेज, अस्वीकृत इवेंट्स और सैंपल पाथ शुद्धता के साथ विश्वास को मापूँगा। विभाजक शेड्यूलर इन्वेंट्री और क्वेरी इतिहास से आता है। मैं महत्वपूर्ण वित्त और ग्राहक डोमेन के लिए टेबल लिनिएज लॉन्च करूँगा, कवरेज अंतराल प्रकाशित करूँगा, फिर कॉलम और घोषित लिनिएज जोड़ूँगा जहाँ निष्कर्षण विश्वसनीय है। सिस्टम तब सफल होता है जब इंजीनियर सुरक्षित परिवर्तन कर सकते हैं और साक्ष्य के साथ घटनाओं का पता लगा सकते हैं, न कि तब जब ग्राफ़ में केवल कई नोड्स हों।"

सामान्य गलतियाँ

• ग्राफ़ डेटाबेस से शुरुआत करना → स्टोरेज का विकल्प पहचान, निष्पादन स्थिति, इतिहास या गायब इंस्ट्रूमेंटेशन को हल नहीं करता है → पहले संस्थाओं, साक्ष्य, लाइफ़साइकिल और क्वेरी अनुबंधों को परिभाषित करें।
• डिस्प्ले नामों को प्राथमिक कुंजियों के रूप में उपयोग करना → उपनाम, केस परिवर्तन, वातावरण और नाम परिवर्तन नोड्स को विभाजित या विलय करते हैं → कैनोनिकल नेमस्पेस/नाम पहचान और स्पष्ट समयबद्ध उपनामों का उपयोग करें।
• घोषित और प्रेक्षित लिनिएज को एक समान मानना → संकलित संभावनाएँ रनटाइम पाथ्स से भिन्न हो सकती हैं → प्रत्येक किनारे के प्रकार और प्रोवेनेंस को संग्रहीत करें और क्वेरीज़ को उन्हें फ़िल्टर करने दें।
• विफल Run से प्रत्येक प्रयास किए गए आउटपुट को बढ़ावा देना → आंशिक फ़ाइलें या टेबल्स गलत वर्तमान सत्य बन जाते हैं → नैदानिक साक्ष्य रखें, लेकिन किनारे को सक्रिय करने से पहले प्रकाशन सिमेंटिक्स की आवश्यकता होती है।
• यह मानना कि COMPLETE का अर्थ सही डेटा है → निष्पादन डुप्लिकेट या अमान्य आउटपुट के साथ समाप्त हो सकता है → डेटा-गुणवत्ता स्थिति को Run लाइफ़साइकिल से अलग रखें।
• regex के साथ सभी SQL को पार्स करना → डायनेमिक SQL, बोलियाँ (dialects), मैक्रोज़ और नेस्टेड एक्सप्रेशन्स गलत निर्भरताएँ उत्पन्न करते हैं → इंजन प्लान और समर्थित पार्सर को प्राथमिकता दें; असमर्थित कवरेज को उजागर करें।
• इवेंट अनुबंध के बिना पेलोड हैश द्वारा डिडुप्लिकेट करना → अलग-अलग प्रगति इवेंट्स सामग्री साझा कर सकते हैं और पुनः प्रयासों में टाइमस्टैम्प भिन्न हो सकते हैं → इनजेशन एनवेलप में एक निर्माता-स्थिर इवेंट ID की आवश्यकता होती है।
• केवल वर्तमान ग्राफ़ को बनाए रखना → पिछला प्रभाव और घटना का पुनर्निर्माण असंभव हो जाता है → अपरिवर्तनीय इवेंट्स और टेम्पोरल एज वर्ज़न बनाए रखें।
• सभी सकर्मक पाथ्स की पहले से गणना करना → फ़ैनआउट, संस्करण परिवर्तन और प्राधिकरण महंगे अमान्यकरण का कारण बनते हैं → सीमित ट्रैवर्सल और लक्षित कैशिंग का उपयोग करें।
• केवल अंतिम प्रतिक्रिया को अधिकृत करना → ट्रैवर्सल या कैशिंग के दौरान छिपे हुए नोड्स और डिग्री काउंट्स लीक हो सकते हैं → विस्तार के दौरान नीति लागू करें और कैश कुंजियों का दायरा निर्धारित करें।
• प्राप्त-इवेंट गणना को कवरेज के रूप में रिपोर्ट करना → मूक प्रोड्यूसर्स इवेंट्स और मेट्रिक दोनों से गायब हो जाते हैं → शेड्यूलर इन्वेंट्री या क्वेरी इतिहास से तुलना करें।
• अज्ञात कमियों के साथ एक पूर्ण दिखने वाला ग्राफ़ दिखाना → उपयोगकर्ता असुरक्षित परिवर्तन निर्णय लेते हैं → प्रत्येक प्रासंगिक परिणाम में ताज़गी, प्रोवेनेंस, अनसुलझी पहचान और गायब प्रोड्यूसर्स को सामने लाएँ।

फ़ॉलो-अप सवाल और जवाब

फ़ॉलो-अप 1: एक विफल Spark Run ने FAIL उत्सर्जित करने से पहले एक टेबल पार्टीशन लिखा था। क्या किनारा दिखना चाहिए?

Run और प्रयास किए गए इनपुट-आउटपुट किनारे को प्रेक्षित नैदानिक साक्ष्य के रूप में रखें, जिसे FAIL के रूप में टैग किया गया है और प्रकाशित नहीं किया गया है। यह वर्तमान प्रोडक्शन ग्राफ़ में दिखाई देता है या नहीं यह स्टोरेज कमिट और प्रकाशन नीति पर निर्भर करता है। यदि पार्टीशन दृश्यमान हो गया है, तो इसे रोलबैक या सत्यापन तक विफल या संदिग्ध संस्करण के रूप में दिखाएं; यदि राइट परमाणु (atomic) था और निरस्त कर दिया गया था, तो इसे सक्रिय न करें। निष्पादन साक्ष्य और प्रकाशन स्थिति दोनों को संरक्षित करने से फोरेंसिक विवरण खोने या विश्वसनीय सत्य के रूप में आंशिक आउटपुट प्रस्तुत करने से बचा जा सकता है।

फ़ॉलो-अप 2: आप ऐसे प्रोड्यूसर का पता कैसे लगाते हैं जिसने चुपचाप लिनिएज भेजना बंद कर दिया है?

प्राप्त-इवेंट मेट्रिक्स अकेले किसी अनुपस्थित प्रोड्यूसर का पता नहीं लगा सकते हैं। Airflow शेड्यूल, Spark इतिहास, dbt रन परिणाम, वेयरहाउस क्वेरी लॉग या किसी अन्य स्वतंत्र नियंत्रण तल (control plane) से एक अपेक्षित-Run इन्वेंट्री बनाएं। विलंबता विंडो के भीतर कैनोनिकल Job और Run पहचान द्वारा लिनिएज इवेंट्स में अपेक्षित Runs को जोड़ें। अनुपलब्ध शुरुआत, अनुपलब्ध टर्मिनल इवेंट्स और क्रिटिकलिटी टियर द्वारा गिरती कवरेज पर अलर्ट करें, जबकि एक अक्षम Job को एक टूटे हुए इंटीग्रेशन से अलग करें।

फ़ॉलो-अप 3: बदले गए Job के चलने से पहले आप इम्पैक्ट एनालिसिस का उत्तर कैसे देंगे?

प्रस्तावित संकलित योजना या मैनिफ़ेस्ट से निकाले गए घोषित लिनिएज का उपयोग करें और सक्रिय परिभाषा के साथ इसकी तुलना करें। हटाए गए या बदले गए आउटपुट से डाउनस्ट्रीम ट्रैवर्स करें, परिणाम को घोषित प्री-डिप्लॉयमेंट साक्ष्य के रूप में लेबल करें, और दिखाएं कि प्रेक्षित लिनिएज इसकी पुष्टि कहाँ करता है या इससे असहमत है। एक CI गेट प्रभावित महत्वपूर्ण संपत्तियों के लिए स्वामी समीक्षा की आवश्यकता कर सकता है। यह दावा न करें कि भविष्य का रनटाइम पाथ प्रेक्षित है; डिप्लॉयमेंट के बाद भी डायनेमिक शाखाएं भिन्न हो सकती हैं।

फ़ॉलो-अप 4: सब कुछ एक ग्राफ़ डेटाबेस में क्यों नहीं स्टोर करते?

बेंचमार्किंग के बाद एक एकल डेटाबेस स्वीकार्य हो सकता है, लेकिन Run इवेंट इतिहास, अपरिवर्तनीय रीप्ले, मेटाडेटा खोज और कम-विलंबता एडजैसेंसी के अलग-अलग एक्सेस पैटर्न होते हैं। टिकाऊ इवेंट स्रोत को पुनर्निर्माण योग्य प्रोजेक्शन से अलग करना रिकवरी की रक्षा करता है और प्रत्येक प्रोजेक्शन को विकसित होने की अनुमति देता है। उन पैटर्न को संतुष्ट करने वाले कम से कम स्टोर्स से शुरुआत करें, फ़ैनआउट और टेम्पोरल-क्वेरी लागत को मापें, और केवल तभी विशेष स्टोरेज जोड़ें जब साक्ष्य परिचालन लागत को सही ठहराते हों।

फ़ॉलो-अप 5: कॉलम लिनिएज किनारों की संख्या को सैकड़ों गुना बढ़ा देता है। आप सबसे पहले क्या डिग्रेड करेंगे?

शुद्धता और महत्वपूर्ण निर्णयों की रक्षा करें। उच्च-महत्व वाले डोमेन के लिए टेबल लिनिएज और हाल के कॉलम लिनिएज को हॉट रखें, पुराने विस्तृत किनारों को कंप्रेस्ड इतिहास में ले जाएं, और कम उपयोग किए जाने वाले फ़ील्ड पाथ्स को एसिंक्रोनस रूप से प्रोसेस करें। ट्रैवर्सल बजट लागू करें और स्पष्ट आंशिक स्थिति लौटाएं। चुपचाप कॉलम उत्तरों को टेबल अनुमानों से न बदलें। इंजन और डोमेन द्वारा कॉलम कवरेज को ट्रैक करें ताकि डिग्रेडेशन मापने योग्य और प्रतिवर्ती (reversible) बना रहे।