7.8 डेटा गुणवत्ता और ऑब्ज़र्वेबिलिटी

अवलोकन और प्रेरणा

डेटा गुणवत्ता उपयोग के लिए उपयुक्तता (fitness for use) है: वह सीमा जिस तक डेटा उन निर्णयों, उत्पादों, और रिपोर्टों की सेवा करता है जो उस पर निर्भर हैं। एक डेटासेट अमूर्त रूप में अच्छा या बुरा नहीं होता। यह किसी उद्देश्य के लिए पर्याप्त रूप से अच्छा है, या नहीं है। एक ग्राहक पता जो मार्केटिंग गणना के लिए ठीक है, एक कानूनी सूचना के लिए अनुपयुक्त हो सकता है। यह ढांचा मायने रखता है, क्योंकि यह बातचीत को “क्या हमारा डेटा उत्तम है” (कभी नहीं) से “क्या हमारा डेटा उस काम के लिए उपयुक्त है जो हम अभी उसके साथ करने वाले हैं” (उत्तर देने योग्य, और परीक्षण योग्य) की ओर ले जाता है। क्लासिक आयाम हैं सटीकता, पूर्णता, संगति, समयबद्धता, वैधता, और विशिष्टता, और अधिकांश वास्तविक समस्याएं इनमें से किसी एक में सिमट जाती हैं।

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

डेटा ऑब्ज़र्वेबिलिटी वह अनुशासन है जो आपके उपभोक्ताओं से पहले इसे पकड़ लेता है। यह सॉफ़्टवेयर ऑब्ज़र्वेबिलिटी और टेलीमेट्री (अध्याय 9.2) का सीधा समानांतर है: वही सहज ज्ञान जो आपको रिक्वेस्ट विलंबता (latency) और त्रुटि दरों की निगरानी करने को कहता है, वही आपको डेटा ताज़गी (freshness), वॉल्यूम, स्कीमा, और वितरण (distribution) की निगरानी करने को कहता है। यह अध्याय डेटा रणनीति और गवर्नेंस (अध्याय 7.1) और डेटा इंजीनियरिंग (अध्याय 7.2) पर आधारित है, और यह डेटा मॉडलिंग तथा सिमेंटिक लेयर (अध्याय 7.7) और जिम्मेदार व भरोसेमंद AI (अध्याय 6.5) में आगे बढ़ता है। उन उद्यमों के लिए जो कई स्रोत सिस्टमों का मिलान करते हैं और उन सरकारों के लिए जो सांविधिक आंकड़े प्रकाशित करती हैं, डेटा विश्वसनीयता को स्वामियों और सेवा स्तरों वाली एक इंजीनियरिंग समस्या के रूप में मानना ही विश्वास और एक बहुत सार्वजनिक सुधार के बीच का अंतर है।

मुख्य सिद्धांत

• डेटा गुणवत्ता उपयोग के लिए उपयुक्तता है, पूर्णता नहीं; इसे उद्देश्य के विरुद्ध परिभाषित करें।
• खराब डेटा किसी डेटा न होने से भी बुरा है, क्योंकि यह चुपचाप निर्णयों को भ्रष्ट करता है।
• डेटा का परीक्षण वैसे ही करें जैसे आप कोड का करते हैं: पाइपलाइन में एसर्शन, अपेक्षाएं, और स्कीमा जांच।
• उत्पादकों और उपभोक्ताओं के बीच अनुबंध (contracts) अपेक्षाओं को स्पष्ट और लागू करने योग्य बनाते हैं।
• ताज़गी, वॉल्यूम, स्कीमा, और वितरण का अवलोकन करें, ठीक वैसे ही जैसे आप सेवाओं का अवलोकन करते हैं।
• वंशावली (lineage) “कुछ गलत है” को “यहां देखें क्या टूटा और यह किसे प्रभावित करता है” में बदल देती है।
• डेटा घटनाओं को उत्पादन घटनाओं की तरह मानें, स्वामित्व, गंभीरता, और सेवा स्तरों के साथ।
• समस्याओं को वहां पकड़ें जहां वे प्रवेश करती हैं, न कि तीन परतें नीचे किसी डैशबोर्ड में।

अनुशंसाएँ

आयाम के अनुसार गुणवत्ता को परिभाषित करें, और उसे मापें

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

एसर्शन और अपेक्षाओं के साथ पाइपलाइनों का परीक्षण करें

डेटा उतनी ही परीक्षण कठोरता का हकदार है जितनी एप्लिकेशन कोड। हर चरण पर डेटा सत्यापन का उपयोग करें: एसर्शन-आधारित परीक्षण जो पाइपलाइन को विफल कर देते हैं जब एक अपरिवर्तनीयता (invariant) का उल्लंघन होता है, और अपेक्षा-आधारित परीक्षण जो घोषित करते हैं कि एक टेबल के लिए “सामान्य” कैसा दिखता है और विचलन को फ़्लैग करते हैं। यह दावा करें कि प्राइमरी कीज़ अद्वितीय और गैर-शून्य हैं, कि फ़ॉरेन कीज़ हल होती हैं, कि श्रेणीबद्ध (categorical) कॉलम केवल स्वीकृत मान रखते हैं, कि संख्यात्मक कॉलम प्रशंसनीय सीमा में आते हैं, और कि पंक्ति गणनाएं एक अपेक्षित बैंड में गिरती हैं। स्कीमा जांच जोड़ें जो ज़ोर से विफल हों जब अपस्ट्रीम में कोई कॉलम जोड़ा, हटाया, नाम बदला, या फिर से टाइप किया जाए। इन जांचों को निरंतर एकीकरण (continuous integration) में चलाएं ताकि मर्ज से पहले एक खराब रूपांतरण पकड़ा जाए, और उन्हें फिर से उत्पादन में लाइव डेटा के विरुद्ध चलाएं ताकि उपभोक्ताओं तक पहुंचने से पहले एक खराब स्रोत पकड़ा जाए। लक्ष्य है जल्दी और ज़ोर से विफल होना, क्योंकि एक टूटी हुई पाइपलाइन चुपचाप गलत पाइपलाइन से सुरक्षित है।

उत्पादकों और उपभोक्ताओं के बीच डेटा अनुबंध स्थापित करें

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

डेटा ऑब्ज़र्वेबिलिटी के चार संकेतों की निगरानी करें

डेटा ऑब्ज़र्वेबिलिटी चार संकेतों को देखती है, ठीक उसी तरह जैसे आप एक चल रही सेवा को देखते हैं (अध्याय 9.2)। ताज़गी: क्या डेटा उतना ही हाल का है जितना उसे होना चाहिए, या पाइपलाइन रुक गई है। वॉल्यूम: क्या पंक्ति गणना अपेक्षित सीमा में है, या एक टेबल आधी-खाली या दोगुनी-लोड होकर पहुंची। स्कीमा: क्या संरचना अप्रत्याशित रूप से बदल गई है। वितरण: क्या मान स्वयं बहक गए हैं, ताकि एक कॉलम जो 2 प्रतिशत शून्य था अचानक 40 प्रतिशत शून्य हो जाए, या एक औसत ऐसे तरीके से बदल गया हो जो एक अपस्ट्रीम बग का संकेत देता है। इन संकेतों को अपनी महत्वपूर्ण टेबलों पर इंस्ट्रूमेंट करें, उनके सामान्य पैटर्न सीखें, और उल्लंघनों पर अलर्ट करें। यही तरीका है जिससे आप “एक कार्यकारी ने देखा कि डैशबोर्ड गलत दिख रहा था” को “स्वामी टीम को विफलता के बिंदु पर पेज किया गया” से बदलते हैं। एक डेटा समस्या का सबसे खराब संभव संसूचक (detector) एक डाउनस्ट्रीम मानव है जो संख्या पर भरोसा करता है।

विसंगति पहचान (anomaly detection) जोड़ें, लेकिन अलर्ट थकान के विरुद्ध इसे ट्यून करें

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

प्रभाव विश्लेषण और मूल कारण के लिए वंशावली (lineage) को ट्रैक करें

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

डेटा घटनाओं को उत्पादन घटनाओं की तरह मानें

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

निरंतर प्रोफ़ाइल और सामंजस्य (reconcile) करें

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

समझौते: फायदे और नुकसान

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

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

अपनी टीम के साथ चर्चा करने योग्य प्रश्न

1. जब खराब डेटा उत्पादन तक पहुंचता है, तो सबसे पहले किसे पता चलता है, और कैसे? यह आपकी डेटा विश्वसनीयता के बारे में सबसे प्रकट करने वाला एकल प्रश्न है, क्योंकि ईमानदार उत्तर आमतौर पर “एक उपभोक्ता को, संयोग से” होता है। यदि एक विश्लेषक, एक कार्यकारी, या एक ग्राहक आपका पहचान तंत्र है, तो आपका पता लगाने का औसत समय दिनों में मापा जाता है और हर बार आपकी विश्वसनीयता को झटका लगता है। विकल्प है ऐसी इंस्ट्रूमेंटेशन जो विफलता के बिंदु पर, गलत संख्या फैलने से पहले, स्वामी टीम को पेज करे। वास्तविक संख्याएं लाएं: आपकी पिछली दस डेटा घटनाओं में से कितनी निगरानी द्वारा पकड़ी गईं बनाम एक डाउनस्ट्रीम मानव द्वारा रिपोर्ट की गईं, और हर एक कितनी देर तक अज्ञात बैठी रही। उत्तर आपको बताता है कि क्या आपके पास ऑब्ज़र्वेबिलिटी है या केवल उम्मीद, और इसे सीधे तय करना चाहिए कि आप पहले ताज़गी, वॉल्यूम, स्कीमा, और वितरण जांच में कहां निवेश करते हैं।

2. किन डेटासेट के पास एक स्वामी, एक अनुबंध, और एक सेवा स्तर है, और कौन अनाथ हैं? पैमाने पर, अधिकांश डेटा गुणवत्ता विफलताएं एक बिना-स्वामी वाले इंटरफ़ेस तक वापस जाती हैं: एक उत्पादक टीम ने कुछ बदल दिया बिना यह जाने कि कौन उस पर निर्भर था, क्योंकि किसी अनुबंध ने ऐसा नहीं कहा। स्वामित्व वह नींव है जो अनुबंधों, अलर्टिंग मार्गों, और घटना प्रतिक्रिया को संभव बनाती है, और अनाथ डेटासेट वे जगहें हैं जहां चुप्पी भरी भ्रष्टता रहती है। अपनी सबसे महत्वपूर्ण टेबलों से गुज़रें और हर एक के बारे में पूछें, कौन जवाबदेह है, उत्पादक ने किस बात की प्रतिबद्धता की है, और उपभोक्ताओं को किस ताज़गी और सटीकता का वादा किया गया है। अपनी वंशावली लाएं: जिन टेबलों की सबसे बड़ी डाउनस्ट्रीम विस्फोट त्रिज्या है, वे वही हैं जिन्हें इसकी सबसे ज़्यादा ज़रूरत है और अक्सर वे वही हैं जिनके पास यह नहीं है। “महत्वपूर्ण” और “स्वामित्व वाला” के बीच का अंतर अगली तिमाही के लिए आपकी प्राथमिकता सूची है।

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

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

5. कौन से मशीन लर्निंग मॉडल और विश्लेषण उस डेटा पर निर्णय ले रहे हैं जिसे हम कभी सत्यापित नहीं करते, और वे चुपचाप कौन सी त्रुटियां एन्कोड कर सकते हैं? एक डैशबोर्ड एक मानव को एक गलत संख्या दिखाता है जो उस पर सवाल उठा सकता है, लेकिन एक मॉडल गलत फ़ीचर पर प्रशिक्षित होता है और उन त्रुटियों को अपनी हर भविष्यवाणी में एन्कोड करता है, एक ऐसे पैमाने और अपारदर्शिता पर जो नुकसान को देखना या पूर्ववत करना कहीं ज़्यादा कठिन बनाती है। प्रतिस्पर्धी दबाव गति है: डेटा साइंस टीमें नए फ़ीचर पर तेज़ी से आगे बढ़ना चाहती हैं, और हर फ़ीड में सत्यापन, अनुबंध, और ताज़गी गारंटी जोड़ना घर्षण जैसा महसूस होता है जब तक कि एक मॉडल चुपचाप बिगड़ न जाए क्योंकि एक अपस्ट्रीम कॉलम बहक गया। अपने उत्पादन मॉडल और विश्लेषण की एक सूची लाएं, हर एक जो डेटासेट उपभोग करता है, और एक ईमानदार निशान कि उन फ़ीड में से किनके पास परीक्षण, अनुबंध, और ऑब्ज़र्वेबिलिटी है बनाम कौन असुरक्षित हैं। एक उद्यम या सरकारी परिस्थिति में जहां एक मॉडल क्रेडिट, लाभों, या प्रवर्तन निर्णयों को प्रभावित करता है, असत्यापित प्रशिक्षण डेटा एक गुणवत्ता जोखिम के ऊपर एक लेखा-परीक्षा (audit) और निष्पक्षता देयता बन जाता है, इसलिए कौन सी फ़ीड एक मॉडल रिलीज़ को गेट करती है, इस प्रश्न का एक स्वामी और एक दस्तावेज़ीकृत उत्तर होना चाहिए (अध्याय 6.5)।

6. जब एक गुणवत्ता बग तथ्य घटित होने के हफ्तों बाद सामने आता है, तो क्या हम वास्तव में पुनः-प्रोसेस और सामंजस्य कर सकते हैं, या हमने पहले ही वह त्याग दिया है जिसकी हमें ज़रूरत होगी? कई गुणवत्ता विफलताएं लोड समय पर अदृश्य होती हैं और केवल बाद में स्पष्ट होती हैं, जब एक सामंजस्य टूटना या एक संदिग्ध रुझान किसी को देखने के लिए प्रेरित करता है, और तब तक इसे स्वच्छता से ठीक करने की क्षमता उन विकल्पों पर निर्भर करती है जो आपने कहीं पहले बनाए थे: क्या आपने अपरिवर्तनीय कच्चे रिकॉर्ड रखे, क्या स्वतंत्र स्रोतों का सामंजस्य किया जा सकता है, और क्या वंशावली आपको खराब आंकड़े को उसकी उत्पत्ति तक ट्रेस करने देती है। तनाव है लागत और सरलता बनाम पुनरुत्पादन-योग्यता, क्योंकि कच्चा डेटा बनाए रखना और सिस्टमों के बीच निरंतर सामंजस्य चलाना मुफ़्त नहीं है, और एक बार रूपांतरित टेबलें सही दिखने लगें तो कच्चे इनपुट को हटा देने का प्रलोभन होता है। अपनी कच्चे डेटा की प्रतिधारण (retention) और अपरिवर्तनीयता नीति, उन महत्वपूर्ण सिस्टम जोड़ों की सूची जिनका आप स्वचालित रूप से सामंजस्य करते हैं, और एक वास्तविक उदाहरण लाएं जिसे आप या तो पुनः-प्रोसेस कर पाए या नहीं कर पाए। एक सरकारी एजेंसी के लिए जो किसी प्रकाशित संख्या को स्रोत रिकॉर्ड तक ट्रेस करने के सांविधिक दायित्व के तहत है, या एक उद्यम जो एक नियामक पुनःकथन (restatement) का सामना कर रहा है, अपरिवर्तनीय कच्चा डेटा और स्वचालित सामंजस्य वैकल्पिक स्वच्छता नहीं बल्कि वह तंत्र है जो एक सुधार को रक्षणीय (defensible) बनाता है।

क्षेत्रीय दृष्टिकोण

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

लघु व्यवसाय। बिना किसी डेटा इंजीनियर और सीमित बजट के, अपने वेयरहाउस, BI टूल, या SaaS प्लेटफ़ॉर्म में पहले से बनी गुणवत्ता सुविधाओं पर भरोसा करें जिनके लिए आप भुगतान करते हैं, बजाय एक अलग स्टैक खड़ा करने के। अपना प्रयास उन मुट्ठी भर संख्याओं पर केंद्रित करें जो वास्तव में निर्णयों को चलाती हैं (राजस्व, पाइपलाइन, इन्वेंटरी), उन्हें नियमित अंतराल पर एक स्वतंत्र स्रोत के विरुद्ध जांचें, और जहां मौजूद हों वहां एक विक्रेता की ताज़गी और स्कीमा अलर्ट को पर्याप्त मानें। जो टूल आप पहले से चला रहे हैं उनमें एम्बेडेड गुणवत्ता खरीदना उस पाइपलाइन बनाने से बेहतर है जिसे बनाए रखने वाला कोई नहीं है।

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

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

उदाहरण

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

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

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

व्यवसाय मामला: प्रेरणाएं, ROI, और TCO

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

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

• स्तर 1, आरंभ (Initiate): गुणवत्ता किसी का काम नहीं है। समस्याएं उपभोक्ताओं द्वारा पाई जाती हैं, आमतौर पर एक गलत संख्या के रिपोर्ट तक पहुंचने के बाद। कोई परीक्षण नहीं, कोई निगरानी नहीं, कोई स्वामित्व नहीं। समाधान मैन्युअल आग बुझाना है, और वही विफलताएं दोबारा होती हैं।
• स्तर 2, विकास (Develop): कुछ टीमें अपनी महत्वपूर्ण टेबलों पर बुनियादी परीक्षण (कीज़, शून्य, स्वीकृत मान) और अपने सबसे ज़्यादा परवाह किए जाने वाले डेटासेट पर थोड़ी ताज़गी और वॉल्यूम निगरानी जोड़ती हैं। प्रथाएं जहां मौजूद हैं वहां काम करती हैं, लेकिन कवरेज और कठोरता टीम-दर-टीम अलग-अलग होती है, कुछ भी मानकीकृत नहीं है, और घटनाओं को अभी भी प्रतिक्रियात्मक रूप से संभाला जाता है।
• स्तर 3, मानकीकरण (Standardize): गुणवत्ता आयाम सीमाओं के साथ परिभाषित हैं, और वही अपेक्षाएं टीमों में लागू होती हैं बजाय इस पर निर्भर होने के कि किसने पाइपलाइन बनाई। डेटा अनुबंध महत्वपूर्ण उत्पादक सीमाओं को नियंत्रित करते हैं, ऑब्ज़र्वेबिलिटी महत्वपूर्ण टेबलों पर ताज़गी, वॉल्यूम, स्कीमा, और वितरण को कवर करती है, और वंशावली प्रभाव विश्लेषण का समर्थन करती है। हर महत्वपूर्ण डेटासेट का एक नामित स्वामी है, और डेटा घटनाएं संगठन-व्यापी एक दस्तावेज़ीकृत गंभीरता और प्रतिक्रिया प्रक्रिया का पालन करती हैं।
• स्तर 4, प्रबंधन (Manage): गुणवत्ता और विश्वसनीयता बेसलाइन के विरुद्ध मापी और नियंत्रित की जाती हैं। डेटा डाउनटाइम को वास्तविक मीट्रिक के साथ ट्रैक किया जाता है: पता लगाने का औसत समय, हल करने का औसत समय, सहमत सेवा स्तरों के विरुद्ध ताज़गी और सटीकता, और त्रुटि बजट जिसे एक डेटासेट कार्रवाई ट्रिगर होने से पहले खर्च कर सकता है। सामंजस्य टूटने की दरें, परीक्षण उत्तीर्ण दरें, और विसंगति झूठी-सकारात्मक दरों का समय के साथ रुझान किया जाता है, अलर्टिंग को अनुमान के बजाय उन संख्याओं के विरुद्ध ट्यून किया जाता है, और एक डेटा रिलीज़ पर जाओ या न-जाओ निर्णय उम्मीद के बजाय बेसलाइन के विरुद्ध मापी गई गुणवत्ता पर आधारित होते हैं।
• स्तर 5, ऑर्केस्ट्रेशन (Orchestrate): गुणवत्ता और ऑब्ज़र्वेबिलिटी व्यापक, स्वचालित, और अनुकूली हैं। विसंगति पहचान सूक्ष्म बहाव पकड़ती है, अनुबंध यांत्रिक रूप से लागू किए जाते हैं, और वंशावली स्वचालित रूप से कैप्चर की जाती है और एक कैटलॉग में प्रकाशित होती है। डेटा के पास उत्पादन सेवाओं जैसे सेवा स्तर और ऑन-कॉल स्वामित्व है, सामंजस्य निरंतर चलता है, और दोषरहित पोस्टमॉर्टम डेटा डाउनटाइम में स्थिर कमी को फीड करते हैं। गुणवत्ता डेटा गवर्नेंस, मशीन लर्निंग, और व्यवसाय योजना के साथ एकीकृत है, और संगठन डेटा परिदृश्य के बदलने के साथ सीमाओं, कवरेज, और स्वामित्व को निरंतर पुनः-स्कोप करता है।

चर्चा के लिए विचार

1. आपकी कौन सी टेबलें सबसे ज़्यादा नुकसान पहुंचाएंगी यदि वे एक हफ्ते के लिए चुपचाप गलत हों, और क्या वही टेबलें हैं जिनकी आप सबसे ज़्यादा निगरानी करते हैं?
2. आपकी पिछली अपस्ट्रीम-कारित घटना को एक डेटा अनुबंध कहां रोक सकता था, और वहां एक क्यों नहीं था?
3. आज एक सामान्य मूल-कारण जांच में कितना इंजीनियरिंग समय लगता है, और स्वचालित वंशावली कितना बचाएगी?
4. क्या आपके कोई भी मशीन लर्निंग मॉडल ऐसे डेटा पर प्रशिक्षित हो रहे हैं जिसे आप सत्यापित नहीं करते, और वे कौन सी त्रुटियां एन्कोड कर सकते हैं?
5. क्या आपकी अलर्टिंग इतनी अच्छी तरह ट्यून की गई है कि लोग हर अलर्ट पर कार्य करते हैं, या किसी ने चैनल म्यूट कर दिया है?
6. आपके सबसे महत्वपूर्ण उपभोक्ता वास्तव में किन ताज़गी और सटीकता सेवा स्तरों पर सहमत होंगे, और क्या आप आज उन्हें पूरा कर सकते हैं?

मुख्य निष्कर्ष

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

संदर्भ और आगे का अध्ययन

• Barr Moses, Lior Gavish, and Molly Vorwerck, “Data Quality Fundamentals.”
• Jacek Majchrzak, Sven Balnojan, and Marian Siwiak, “Data Contracts.”
• Danette McGilvray, “Executing Data Quality Projects.”
• Thomas C. Redman, “Data Driven: Profiting from Your Most Important Business Asset.”
• Laura Sebastian-Coleman, “Measuring Data Quality for Ongoing Improvement.”
• Joe Reis and Matt Housley, “Fundamentals of Data Engineering.”
• DAMA International, “DAMA-DMBOK: Data Management Body of Knowledge.”
• ISO/IEC 25012, “Data quality model.”