डेटा इंजीनियरिंग इंटरव्यू: एक क्रिटिकल पाइपलाइन के लिए डेटा क्वालिटी SLOs कैसे डिज़ाइन करें?

प्रॉम्प्ट और लागू संदर्भ

एक दैनिक fact_order_settlements डेटासेट 12 सोर्स सिस्टम्स से लगभग 10 मिलियन ऑर्डर इवेंट्स को प्रोसेस करता है। फ़ाइनेंस अपना क्लोज़ 07:00 UTC पर शुरू करता है। ऑर्केस्ट्रेटर वर्तमान में केवल यह रिपोर्ट करता है कि जॉब्स समाप्त हुईं या नहीं, इसलिए एक ग्रीन रन भी देर से पार्टीशन प्रकाशित कर सकता है, किसी एक सोर्स को छोड़ सकता है, ऑर्डर वर्शन को डुप्लिकेट कर सकता है, या सोर्स के कुल योग (totals) से असहमत हो सकता है।

डेटा क्वालिटी SLOs और उन्हें लागू करने वाले कंट्रोल्स डिज़ाइन करें। सोर्स सिस्टम सोर्स, करेंसी और बिज़नेस डेट के अनुसार रिकॉर्ड काउंट और ग्रॉस अमाउंट वाला एक कंट्रोल मैनिफ़ेस्ट प्रदान करते हैं। रॉ इवेंट्स 30 दिनों के लिए रीप्ले करने योग्य रहते हैं, सुधार (corrections) 24 घंटे तक आ सकते हैं, और दो उपभोक्ताओं की अलग-अलग ज़रूरतें हैं: फ़ाइनेंस को प्रमाणित (certified) डेटा की आवश्यकता होती है, जबकि एनालिस्ट स्पष्ट रूप से चिह्नित प्रारंभिक (preliminary) व्यू का उपयोग कर सकते हैं।

SLIs, उद्देश्यों, नियम लगाने के स्थान, रिलीज़ गेट्स, ओनरशिप, अलर्ट रूटिंग, एरर-बजट कार्रवाइयों, इंसिडेंट रिकवरी और रोलआउट वैलिडेशन को कवर करें। 10 मिलियन इवेंट्स, 12 सोर्स, डेडलाइन्स, रिटेंशन और प्रस्तावित लक्ष्य इंटरव्यू की मान्यताएं हैं। प्रोडक्शन लक्ष्यों के लिए उपभोक्ता सहमति और ऐतिहासिक मापों की आवश्यकता होती है। यह एक data प्रश्न है क्योंकि इसका मूल एक डेटा उत्पाद के लिए एक संचालन योग्य (operable) क्वालिटी कॉन्ट्रैक्ट है। यह कार्य किसी इंसिडेंट से पहले शुरू होता है और सर्टिफ़िकेशन तथा पॉलिसी समीक्षा तक जारी रहता है।

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

पहला, क्या उम्मीदवार "हाई-क्वालिटी डेटा" को अवलोकनीय (observable) उपभोक्ता परिणामों में बदल सकता है? फ्रेशनेस, पूर्णता (completeness), वैधता (validity), निरंतरता (consistency), सटीकता (accuracy), और विशिष्टता (uniqueness) अलग-अलग विफलता मोड का वर्णन करते हैं। एक मिश्रित (blended) क्वालिटी स्कोर कई पासिंग चेक्स के पीछे शून्य-सहिष्णुता (zero-tolerance) वाले डुप्लिकेट को छिपा सकता है।

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

तीसरा, क्या उम्मीदवार एक SLI विनिर्देश को उसके कार्यान्वयन (implementation) से अलग कर सकता है? "फ़ाइनेंस को क्लोज़ से पहले प्रमाणित डेटा प्राप्त होता है" परिणाम को व्यक्त करता है। शेड्यूलर के समाप्त होने के समय को मापना एक ऐसा कार्यान्वयन है जो पब्लिकेशन, कैटलॉग, परमिशन और डाउनस्ट्रीम-रीड विफलताओं को छोड़ देता है। मजबूत उत्तर उपभोक्ता सीमा के करीब मापते हैं और ब्लाइंड स्पॉट्स का दस्तावेजीकरण करते हैं।

चौथा, क्या प्रत्येक विफलता एक पूर्व निर्धारित कार्रवाई का कारण बनती है? एक हार्ड इनवेरिएंट (hard invariant) को पब्लिकेशन ब्लॉक या क्वारंटीन की आवश्यकता होती है। एक चेतावनी को एक ओनर और समीक्षा पथ की आवश्यकता होती है। एक पेज को तत्काल उपभोक्ता प्रभाव का प्रतिनिधित्व करना चाहिए। "हर विफल नियम पर अलर्ट करें" डिज़ाइन कार्य को ऑन-कॉल इंजीनियर पर स्थानांतरित करता है और शोर पैदा करता है।

अंत में, क्या उम्मीदवार ओनरशिप को निष्पादन योग्य बना सकता है? प्रोड्यूसर्स, प्लेटफ़ॉर्म इंजीनियर्स, डेटासेट ओनर्स और फ़ाइनेंस ज़िम्मेदारी साझा कर सकते हैं, लेकिन प्रत्येक नियम, इंसिडेंट और अप्रूवल के लिए अभी भी एक प्रत्यक्ष ज़िम्मेदार ओनर और एक एस्केलेशन पथ की आवश्यकता होती है।

उत्तर देने से पहले स्पष्टीकरण प्रश्न

फ़ाइनेंस के लिए "तैयार" का क्या अर्थ है? यदि क्लोज़ के लिए 07:00 बजे प्रमाणित डेटा की आवश्यकता है, तो मापें कि फ़ाइनेंस प्रमाणित वर्शन को कब क्वेरी कर सकता है, न कि जब अंतिम ट्रांसफ़ॉर्मेशन बाहर निकलता है। यदि कोई प्रीव्यू उपयोगी है, तो इसे एक अलग स्टेटस और कॉन्ट्रैक्ट के तहत प्रकाशित करें।
कौन सा स्वतंत्र प्रमाण पूर्णता और शुद्धता को परिभाषित करता है? एक सोर्स मैनिफ़ेस्ट काउंट और अमाउंट के समाधान (reconciliation) का समर्थन करता है। इसके बिना, ऑफ़सेट, सोर्स स्नैपशॉट, या लेज़र टोटल का उपयोग करें और सांख्यिकीय वॉल्यूम चेक्स को प्रमाण के बजाय विसंगति पहचान (anomaly detection) के रूप में लेबल करें।
बिज़नेस की और अपडेट मॉडल क्या है? विशिष्टता (source_id, order_id, version) पर लागू हो सकती है, जबकि नवीनतम बिज़नेस स्थिति के लिए प्रति ऑर्डर एक विजेता (winning) वर्शन की आवश्यकता हो सकती है। देर से आने वाले सुधार चेक और सर्टिफ़िकेशन लाइफ़साइकिल दोनों को बदल देते हैं।
कौन सी विफलताएं डिग्रेड हो सकती हैं और कौन सी ब्लॉक होनी चाहिए? छूटी हुई कुंजियाँ, डुप्लिकेट वर्शन, या लेज़र बेमेल क्लोज़ को दूषित कर सकते हैं और उन्हें सर्टिफ़िकेशन को ब्लॉक करना चाहिए। प्रमाणित वित्तीय फ़ील्ड्स जारी रहने के दौरान एक वैकल्पिक मार्केटिंग विशेषता को क्वारंटीन किया जा सकता है।
SLO विंडो में कितने क्वालिटी इवेंट्स मौजूद हैं? एक दैनिक पाइपलाइन में सार्थक मासिक 99.9% उद्देश्य के लिए बहुत कम अवलोकन होते हैं। एक रोलिंग 60-बिज़नेस-डे लक्ष्य जैसे कि 59 समय पर सर्टिफ़िकेशन में समझने योग्य ग्रैन्युलैरिटी होती है।
विफल गेट को कौन माफ़ (waive) कर सकता है? एक अपवाद (exception) के लिए एक अप्रूवर, प्रभावित उपभोक्ता, समाप्ति समय, कारण और ऑडिट रिकॉर्ड की आवश्यकता होती है। ऑन-कॉल इंजीनियर को किसी इंसिडेंट के दौरान चुपचाप वित्तीय अनुबंध को पुनर्परिभाषित नहीं करना चाहिए।
क्या रिकवरी संभव है? तीस-दिवसीय रॉ रीप्ले नियतात्मक (deterministic) पुनर्निर्माण का समर्थन करता है। यदि सोर्स इतिहास परिवर्तनशील या अधूरा है, तो रिकवरी और प्रमाण आवश्यकताएं बदलनी चाहिए।

30-सेकंड उत्तर फ़्रेमवर्क

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

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

चरण-दर-चरण विस्तृत विवरण

चरण 1: डेटा उत्पाद और उपभोक्ता परिणामों को परिभाषित करें

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

preliminary: जल्दी उपलब्ध, घोषित लेट सोर्सेज हो सकते हैं, वित्तीय क्लोज़ के लिए कभी उपयोग नहीं किया जाता है;
certified: बताए गए वर्शन के लिए अपरिवर्तनीय (immutable), सभी हार्ड गेट्स पास हो चुके हैं, मैनिफ़ेस्ट और क्वालिटी परिणाम ID के साथ;
superseded: एक सुधार वर्शन द्वारा प्रतिस्थापित जबकि पिछला प्रमाण खोजने योग्य बना रहता है।

यह स्थिति मॉडल एक ग्रीन ऑर्केस्ट्रेशन स्थिति को आकस्मिक व्यावसायिक गारंटी बनने से रोकता है। फ़ाइनेंस केवल certified को क्वेरी करता है; खोजपूर्ण उपभोक्ता फ़ाइनेंस कॉन्ट्रैक्ट को कमजोर किए बिना निश्चितता के लिए फ्रेशनेस का व्यापार कर सकते हैं।

चरण 2: प्रत्येक SLI को योग्य इवेंट्स के अनुपात में अच्छे इवेंट्स के रूप में लिखें

उपभोक्ता-दृश्यमान परिणामों और एक परिभाषित इकाई का उपयोग करें। परिदृश्य के लिए, एक शुरुआती फ्रेशनेस SLI है:

text

freshness_sli =
  business-day partitions certified and queryable by 06:30 UTC
  / eligible business-day partitions

starting_slo = at least 59 good partitions in a rolling 60-business-day window

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

अन्य आयामों को उनके अपने सफलता मानदंड दें:

पूर्णता: प्रत्येक अपेक्षित सोर्स मैनिफ़ेस्ट मौजूद है; रिकॉर्ड काउंट और क्रिटिकल-की कवरेज का मिलान होता है।
विशिष्टता: प्रमाणित पार्टीशन में शून्य डुप्लिकेट (source_id, order_id, version) टुपल्स।
वैधता: आवश्यक कुंजियाँ मौजूद हैं और अनुबंध-नियंत्रित फ़ील्ड्स अनुमत प्रकारों, डोमेन और सीमाओं का उपयोग करते हैं।
निरंतरता: एकत्रीकरण (aggregation) से पहले सोर्स, करेंसी और बिज़नेस डेट के अनुसार काउंट और अमाउंट का समाधान होता है।
सुधार की समयबद्धता: स्वीकृत सुधार एक सहमत विंडो के भीतर एक नए प्रमाणित वर्शन बन जाते हैं।

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

चरण 3: हार्ड इनवेरिएंट्स, SLOs और डायग्नोस्टिक्स को सोच-समझकर चुनें

तीन वर्ग कार्रवाइयों को समझने योग्य रखते हैं:

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

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

चरण 4: चेक्स को सबसे शुरुआती उपयोगी सीमा पर रखें

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

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

निम्नलिखित एक टूल-तटस्थ स्यूडो-YAML है, न कि कोई उत्पाद-विशिष्ट स्कीमा:

yaml

dataset: finance.fact_order_settlements
owner: finance-data
consumer: daily-close
certification_deadline_utc: "06:30"
rules:
  - name: required_business_key
    dimension: completeness
    scope: row
    pass_ratio: 1.0
    action: block_and_quarantine
  - name: unique_order_version
    dimension: uniqueness
    scope: [source_id, order_id, version]
    pass_ratio: 1.0
    action: block_certification
  - name: source_manifest_reconciliation
    dimension: consistency
    scope: [source_id, currency, business_date]
    pass_ratio: 1.0
    action: block_certification_and_page_owner

चरण 5: स्वतंत्र समाधान का उपयोग करें और परिणाम को स्लाइस करें

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

सोर्स, क्षेत्र, करेंसी, इवेंट प्रकार और पाइपलाइन चरण द्वारा विफलताओं को स्लाइस करें। एक वैश्विक 99.99% पास दर कम मात्रा वाले सोर्स के लिए पूर्ण आउटेज को छिपा सकती है। इसके विपरीत, एक ज्ञात लेट सोर्स को इंजेशन, ट्रांसफ़ॉर्मेशन और पब्लिकेशन से समान पेज उत्पन्न नहीं करने चाहिए। पहले कार्रवाई योग्य टूटी हुई सीमा को रूट करें और डायग्नोस्टिक्स को संरक्षित करते हुए व्युत्पन्न अलर्ट्स को दबाएं।

ऐतिहासिक बैंड वॉल्यूम विसंगति का पता लगाने के लिए उपयोगी हैं, लेकिन सीज़नलिटी, प्रचार और नए लॉन्च किए गए सोर्स उन्हें वैध रूप से स्थानांतरित कर सकते हैं। विसंगति को तब तक जांच करने के लिए प्रमाण के रूप में मानें जब तक कि कोई स्वतंत्र नियंत्रण कुल नुकसान की पुष्टि न कर दे।

चरण 6: गेट्स, अपवादों और ओनरशिप को निष्पादन योग्य बनाएं

प्रत्येक नियम को गंभीरता, कार्रवाई, प्रत्यक्ष ओनर, बैकअप ओनर, एस्केलेशन लक्ष्य, रनबुक और अधिकतम पावती समय घोषित करना चाहिए। एक व्यावहारिक विभाजन है:

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

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

चरण 7: एक एरर-बजट पॉलिसी परिभाषित करें जो निर्णयों को बदलती है

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

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

जब डिटेक्शन उपभोक्ता इंसिडेंट्स के साथ मेल नहीं खाते हैं या पेजों में कम सटीकता होती है, तो SLI पर दोबारा विचार करें। माप को फ़ाइनेंस के करीब ले जाएं, छूटे हुए स्लाइस जोड़ें, या एक शोर वाले डायग्नोस्टिक को शिथिल करें। परिचालन शोर को शांत करने के लिए किसी हार्ड इनवेरिएंट को ढीला न करें; कार्यान्वयन या रूटिंग को ठीक करें।

चरण 8: कैनरी, रिकवरी का अभ्यास करें और कवरेज साबित करें

एक सोर्स और एक प्रतिनिधि 14-से-30-दिवसीय ऐतिहासिक विंडो पर गेटिंग के बिना नियमों का शैडो-मूल्यांकन करें। नियंत्रित विफलताओं को इंजेक्ट करें: एक सोर्स छोड़ें, एक ऑर्डर वर्शन को डुप्लिकेट करें, एक स्कीमा तोड़ें, पब्लिकेशन में देरी करें, और रो काउंट को बनाए रखते हुए एक राशि बदलें। सत्यापित करें कि अपेक्षित नियम, ओनर और रनबुक एक बार सक्रिय होते हैं।

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

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

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

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

फ्रेशनेस के लिए, मैं रोलिंग 60-बिज़नेस-डे विंडो पर 06:30 तक 59 प्रमाणित पार्टीशन का प्रस्ताव कर सकता हूँ, फिर फ़ाइनेंस और ऐतिहासिक प्रदर्शन के साथ इसे कैलिब्रेट करूँगा। शुद्धता के अलग हार्ड गेट्स हैं। प्रत्येक सोर्स मैनिफ़ेस्ट अवश्य आना चाहिए; सोर्स और बिज़नेस डेट के अनुसार काउंट और मूल-करेंसी राशियों का मिलान होना चाहिए; आवश्यक बिज़नेस कुंजियाँ पूर्ण होनी चाहिए; और (source_id, order_id, version) अद्वितीय होना चाहिए। मैं इन्हें कभी भी ऐसे स्कोर में औसत नहीं करूँगा जो एक ब्लॉकिंग विफलता को पास होने दे।

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

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

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

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

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

फ़ॉलो-अप प्रश्न और प्रतिक्रियाएं

फ़ॉलो-अप 1: क्या होगा यदि सोर्स मैनिफ़ेस्ट प्रदान नहीं कर सकते हैं?

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

फ़ॉलो-अप 2: क्या होगा यदि फ़ाइनेंस हमेशा के लिए शून्य देर से पार्टीशन की मांग करता है?

एक अंतर्निहित 100% लक्ष्य विश्वसनीयता कार्य को प्राथमिकता देने के लिए कोई तंत्र नहीं छोड़ता है और परिचालन रूप से असमर्थनीय हो सकता है। अनुरोध तक पहुंचने के लिए आवश्यक अतिरेक (redundancy), रीप्ले समय, सोर्स निर्भरता और लागत की मात्रा निर्धारित करें। वित्तीय शुद्धता को एक हार्ड गेट के रूप में रखें, एक मापने योग्य फ्रेशनेस लक्ष्य और एक सख्त आकांक्षात्मक लक्ष्य का प्रस्ताव करें, और प्रतिक्रिया नीति पर स्पष्ट व्यावसायिक, इंजीनियरिंग और संचालन समझौता प्राप्त करें।

फ़ॉलो-अप 3: पार्टीशन प्रमाणित होने के बाद आप सुधार को कैसे संभालते हैं?

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

फ़ॉलो-अप 4: आप सैकड़ों डेटासेट्स में अलर्ट थकान को कैसे रोकते हैं?

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

फ़ॉलो-अप 5: एक स्ट्रीमिंग पाइपलाइन के लिए क्या बदलता है?

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

फ़ॉलो-अप 6: आप डेटा क्वालिटी टूल का मूल्यांकन कैसे करेंगे?

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