ऐसा लगता है कि यह डेटा गुणवत्ता पर मेरी श्रृंखला का भाग 2 है!
पिछली पोस्ट में, मैंने प्रोत्साहनों के माध्यम से डेटा गुणवत्ता बढ़ाने के लिए Airbnb की रणनीति का पता लगाया। उन्होंने स्वामित्व की वास्तविक भावना को बढ़ावा देते हुए, डेटा उत्पादकों और उपभोक्ताओं के बीच एक आम समझ स्थापित करने के लिए एकल स्कोर और स्पष्ट स्कोरिंग मानदंड लागू किए।
अब, Lyft एक अलग दृष्टिकोण अपना रहा है, एक ही चीज़ को अलग तरीके से प्रयास नहीं कर रहा है, बल्कि डेटा गुणवत्ता के विभिन्न पहलुओं पर ध्यान केंद्रित कर रहा है। और, Lyft की रणनीति Airbnb के प्रयासों की पूरक है। जबकि मैं Airbnb के DQ स्कोर (या किसी भी समान स्कोर) को डेटा गुणवत्ता बढ़ाने के विभिन्न प्रयासों को समेकित करने के एक प्रभावी साधन के रूप में मानता हूं, Lyft एक अलग कोण से इस चुनौती से निपट रहा है।
Airbnb का DQ स्कोर डेटा गुणवत्ता का ठोस दृश्य प्रदान करने के लिए एक मूल्यवान उपकरण के रूप में कार्य करता है। संक्षेप में, डेटा गुणवत्ता बढ़ाने की किसी भी पहल का इस स्कोर पर स्पष्ट प्रभाव दिखना चाहिए। दूसरी ओर, Lyft विशिष्ट गुणवत्ता मानदंडों के विरुद्ध डेटा का परीक्षण और सत्यापन करके गुणवत्ता को सक्रिय रूप से बढ़ाने के लिए एक संभावित पहल प्रस्तुत करता है।
मौलिक रूप से, यह डेटा गुणवत्ता जीवनचक्र में एक अलग बिंदु है। गुणवत्ता में सुधार के लिए एक तंत्र का परिचय देने के लिए शुरुआत में इसे मापने की क्षमता की आवश्यकता होती है।
इसलिए, जबकि Airbnb का ध्यान डेटा गुणवत्ता को मापने और अवलोकन करने पर है, इस गुणवत्ता को बढ़ाने और "अच्छा दिखने" के लिए निर्माता की रुचि पर निर्भर करते हुए, Lyft एक अलग दृष्टिकोण अपनाता है। Lyft सक्रिय रूप से डेटा गुणवत्ता का परीक्षण और सत्यापन करने पर जोर देता है, जिससे उत्पादकों और उपभोक्ताओं दोनों को गुणवत्ता में प्रभावी ढंग से सुधार और नियंत्रण करने के साधन उपलब्ध होते हैं।
सामूहिक रूप से, ये दृष्टिकोण पूरे जीवनचक्र में डेटा गुणवत्ता को संबोधित करने और बढ़ाने के लिए एक व्यापक रणनीति प्रदान करते हैं।
इस कारण से, मुझे लिफ़्ट के दृष्टिकोण पर करीब से नज़र डालने में विशेष रुचि थी।
एक अन्य कारक जिसने मुझे आकर्षित किया, वह है परीक्षण, विशेष रूप से, अनुबंध परीक्षण, जिसका उपयोग माइक्रोसर्विस आर्किटेक्चर के उद्भव के साथ बुनियादी सॉफ्टवेयर इंजीनियरिंग में कई वर्षों से किया जा रहा है। हालाँकि, डेटा अनुबंध, डेटा इंजीनियरिंग के क्षेत्र में कुछ और नवीनतम हैं और इन्हें उच्च-गुणवत्ता वाली डेटा पाइपलाइनों के निर्माण की राह पर शिखर या अंतिम कदमों में से एक के रूप में देखा जाता है। यही कारण है कि मैं लिफ़्ट के दृष्टिकोण की अधिक विस्तार से जांच करना चाहता था और कुछ संभावित समानताएं तलाशना चाहता था।
Airbnb ने DQ स्कोर विकसित किया है, जो डेटा गुणवत्ता के 4 अलग-अलग पहलुओं को मापने और बढ़ाने पर केंद्रित है:
डीक्यू स्कोर में मार्गदर्शक सिद्धांत हैं, जिनमें पूर्ण कवरेज, स्वचालन, क्रियाशीलता, बहु-आयामीता और विकासशीलता शामिल हैं। इसमें सटीकता, विश्वसनीयता, प्रबंधन और प्रयोज्यता जैसे आयाम हैं।
Lyft's Verity एक प्लेटफ़ॉर्म है जिसे 5 आयामों में डेटा गुणवत्ता बढ़ाने के लिए डिज़ाइन किया गया है
डेटा गुणवत्ता को इस माप के रूप में परिभाषित करता है कि डेटा का कितनी अच्छी तरह उपयोग किया जा सकता है, जिसमें अर्थ संबंधी शुद्धता, स्थिरता, पूर्णता, विशिष्टता, सुगठितता और समयबद्धता जैसे पहलू शामिल हैं।
Lyft's Verity द्वारा बेहतर किए गए 5 डेटा गुणवत्ता पहलुओं और Airbnb के DQ स्कोर द्वारा मापे गए 4 डेटा गुणवत्ता आयामों के बीच समानताएं बनाना आसान है। उदाहरण के लिए, समयबद्धता जैसे पहलू निश्चित रूप से डीक्यू स्कोर की विश्वसनीयता में योगदान देंगे, जबकि सटीकता डेटा की अर्थ संबंधी शुद्धता, पूर्णता और विशिष्टता पर निर्भर होगी। दूसरी ओर, उपयोगिता स्कोर अन्य कारकों के बीच डेटा की स्थिरता से प्रभावित होता है।
लिफ़्ट की वेरिटी अर्थ संबंधी शुद्धता, स्थिरता, पूर्णता, विशिष्टता, सुगठितता और समयबद्धता से संबंधित जांच को परिभाषित करने पर केंद्रित है। यह परीक्षण-प्रथम और सत्यापन दृष्टिकोण का पालन करता है, जबकि एयरबीएनबी का एकीकृत डीक्यू स्कोर विभिन्न आयामों के माध्यम से डेटा गुणवत्ता का मूल्यांकन करने पर जोर देता है।
यदि हम DQ स्कोर को इस अंतिम स्कीमा में शामिल करना चाहते हैं, तो यह अलर्ट/डीबग चरणों के पक्ष में होगा।
Airbnb का DQ स्कोर सटीकता, विश्वसनीयता, प्रबंधन और प्रयोज्य पहलुओं में डेटा गुणवत्ता का आकलन करने के लिए विभिन्न संकेतों का उपयोग करता है।
हमारे पास इनपुट संकेतों का एक सेट भी था जो गुणवत्ता को अधिक सीधे मापता है (मिडास प्रमाणीकरण, डेटा सत्यापन, बग, एसएलए, स्वचालित डीक्यू जांच इत्यादि), जबकि अन्य गुणवत्ता के लिए प्रॉक्सी की तरह थे (उदाहरण के लिए, वैध स्वामित्व, सुशासन स्वच्छता, पक्के पथ टूलींग का उपयोग)।
जैसा कि पहले चर्चा की गई है, Airbnb के DQ स्कोर और Verity के बीच ओवरलैप होने की संभावना है। जबकि Airbnb माप और स्कोरिंग पर जोर देते हुए डेटा गुणवत्ता को दाईं ओर धकेलने पर ध्यान केंद्रित करता है, Lyft's Verity डेटा गुणवत्ता में सक्रिय सुधार पर जोर देते हुए, चेक परिभाषा कॉन्फ़िगरेशन, परीक्षण और सत्यापन प्रक्रियाओं को बाईं ओर स्थानांतरित करके एक सक्रिय दृष्टिकोण अपनाता है।
अब, मेरी प्राथमिक रुचि चेक परिभाषा कॉन्फ़िगरेशन, परीक्षण और सत्यापन पहलुओं में बाईं ओर है।
Lyft अपनी प्रक्रियाओं में डेटा गुणवत्ता परीक्षण को कैसे एकीकृत करता है?
वर्तमान में, Lyft's Verity मुख्य रूप से अपने Hive डेटा वेयरहाउस में संग्रहीत डेटा की गुणवत्ता सुनिश्चित करने पर केंद्रित है। हालाँकि, भविष्य में अन्य डेटा स्रोतों का समर्थन करने के लिए इसकी क्षमताओं का विस्तार करने की योजना है।
ध्यान दें कि जब वे हाइव को डेटा वर्कहाउस के रूप में संदर्भित करते हैं, तो वे वास्तव में इसे हाइब्रिड डेटा स्टोरेज समाधान के रूप में उपयोग करते हैं, संरचित, संसाधित और साफ़ किए गए डेटा (सिल्वर लेयर) के लिए डेटा वेयरहाउस के रूप में काम करते हैं, जबकि कच्चे इवेंट के लिए डेटा लेक के रूप में भी काम करते हैं। डेटा (कांस्य परत)।
हाइव में खराब डेटा गुणवत्ता के कारण ख़राब प्रयोग मेट्रिक्स, गलत मशीन लर्निंग सुविधाएँ और त्रुटिपूर्ण कार्यकारी डैशबोर्ड थे।
यह सुनिश्चित करने के लिए कि केवल उच्च गुणवत्ता वाले कच्चे डेटा को संसाधित किया जाता है और व्युत्पन्न डेटा के रूप में हाइव में संग्रहीत किया जाता है, वेरिटी के चेक को एयरफ्लो डीएजी में एकीकृत किया जा सकता है।
डेटा निर्माता और उपभोक्ता अपने डेटा की गुणवत्ता जांच को परिभाषित कर सकते हैं और डेटा का उत्पादन होने पर या उसके अंदर उपभोग होने से पहले सत्यापित कर सकते हैं
वायु प्रवाह याफ्लाइट .…
VerityAirflowOperator का उपयोग चेक विफलता पर DAG को रोकने के लिए अवरुद्ध तरीके से किया जा सकता है, जिससे खराब डेटा को उत्पादन तक पहुंचने से रोका जा सकता है। यह "का उपयोग करता है
स्टेज-चेक-एक्सचेंज पैटर्न: हम एक चरणबद्ध स्कीमा में डेटा बनाते हैं, ब्लॉकिंग ऑपरेटर के साथ डेटा को सत्यापित करते हैं, फिर गुणवत्ता जांच पास करने पर इसे उत्पादन में बढ़ावा देते हैं।
कच्चे और व्युत्पन्न डेटा दोनों को सत्यापित करने के लिए जाँच मैन्युअल रूप से भी की जा सकती है या स्वचालित रूप से शेड्यूल की जा सकती है।
वेरिटी शेड्यूल्ड चेक किसी भी डेटा ऑर्केस्ट्रेशन इंजन से अलग होते हैं, इसलिए एयरफ़्लो या फ़्लाइट पूरी तरह से बंद होने पर भी वे चलते रहते हैं। यह एयरफ्लो टास्क कभी नहीं चलने के कारण चेक के अलर्ट न होने की एक आम समस्या का समाधान करता है।
इसलिए, चेक को ट्रिगर करने के अनिवार्य रूप से 3 प्राथमिक तरीके हैं: एयरफ़्लो डीएजी के हिस्से के रूप में, मैन्युअल रूप से, या वेरिटी प्लेटफ़ॉर्म/यूआई के माध्यम से शेड्यूल किया गया।
इस प्रकार की वास्तविक समय जांच को लागू करने से विसंगतियों का शीघ्र पता लगाया जा सकेगा, जिससे भंडारण और प्रसंस्करण लागत कम होगी और समग्र डेटा गुणवत्ता में वृद्धि होगी।
खैर, पूरी तरह से, सत्यता जांच को एक एपीआई सर्वर के माध्यम से प्रबंधित किया जाता है, जिसका उपयोग कुछ एपीआई के माध्यम से प्रोग्रामेटिक रूप से जांच को ट्रिगर करने के लिए किया जा सकता है।
वेरिटी एपीआई सर्वर - यह सेवा चेक चलाने के साथ-साथ उनके परिणामों को जारी रखने और पुनर्प्राप्त करने के संबंध में सभी बाहरी एपीआई को संभालती है। एपीआई सर्वर किसी भी जांच को निष्पादित नहीं करता है, बल्कि हमारी चेक कतार को एक संदेश लिखता है, जो उपयोग करता है
SimpleQueueService (एसक्यूएस)।
तो, हो सकता है, आप संभावित रूप से इन नौकरियों को अधिक वास्तविक समय में ट्रिगर कर सकते हैं, जैसे स्ट्रीमिंग नौकरी से या यहां तक कि, लंबे समय तक, हाइव चेंज डेटा कैप्चर (सीडीसी) के साथ एकीकृत करके।
हालाँकि, जब एयरफ़्लो के बाहर निष्पादित किया जाता है, तो ये कार्य डेटा प्रोसेसिंग कार्य को अवरुद्ध करने में सक्षम नहीं होंगे; इसके बजाय, वे चेक कतार में भेजे गए अतुल्यकालिक अलर्ट उत्पन्न करेंगे। कुछ उपभोक्ता चेक विफल होने पर डेटा प्रोसेसिंग में देरी करना पसंद करेंगे, जबकि अन्य आगे बढ़ना और अलर्ट प्राप्त करना पसंद करेंगे।
यहां एक उदाहरण दिया गया है जो यह जांचता है कि rider_events.session_id
कभी शून्य नहीं है या नहीं। यह क्वेरी और स्थिति घटकों के संयोजन के माध्यम से पूरा किया जाता है।
core rider events session_id is not null: # check name metadata: id: 90bde4fa-148b-4f06-bd5f-f15b3d2ad759 ownership_slack: #dispatch-service-dev tags: [rides, core-data, high-priority] query: type: dsl data_source_id: hive.core.rider_events filters: - session_id = null condition: type: fixed_threshold max: 0 notifier_group: pagerduty_policy: dispatch-service email: [email protected]
वेरिटी मुख्य रूप से संपूर्ण डेटा स्कीमा को परिभाषित करने के बजाय डेटा गुणवत्ता जांच को परिभाषित करने और लागू करने पर केंद्रित है।
स्कीमा सत्यापन कोई नवीन अवधारणा नहीं है। इवेंट-आधारित सिस्टम में इवेंट डेटा स्कीमा को परिभाषित करने के लिए कई विधियाँ मौजूद हैं, जैसे JSON स्कीमा, प्रोटोकॉल बफ़र्स, एवरो, या Parquet जैसे स्टोरेज प्रारूप। इष्टतम विकल्प आपके तकनीकी स्टैक, उपयोग और विशिष्ट आवश्यकताओं पर निर्भर करता है।
जबकि डेटा स्कीमा डेटा ऑब्जेक्ट या तालिका पंक्तियों की समग्र संरचना को परिभाषित करने के लिए मूल्यवान हैं, वे उपभोक्ताओं के लिए विशिष्ट अधिक परिष्कृत सत्यापन जांच, जैसे डेटा वितरण, व्यावसायिक नियम, एसएलए और थ्रेसहोल्ड को कैप्चर करने में कम पड़ जाते हैं।
डेटा अनुबंध स्कीमा सत्यापन से आगे जाते हैं, जो वाक्यात्मक त्रुटियों की पहचान करने पर केंद्रित है। मैं व्यक्तिगत रूप से पाता हूं कि JSON स्कीमा यहां एक अधिक उपयुक्त और पठनीय विकल्प प्रदान करता है, जो इन संरचनात्मक और वाक्यात्मक सत्यापन क्षमताओं को क्रमबद्धता या भंडारण संबंधी चिंताओं से प्रभावी ढंग से अलग करता है।
हालाँकि, सिमेंटिक त्रुटियों को संबोधित करने और डेटा सटीकता को बढ़ाने के लिए, डेटा जांच को परिभाषित करने का एक प्रभावी साधन होने से डेटा अनुबंधों के अन्य पहलू को परिभाषित करने की अनुमति मिलती है।
यहीं पर वेरिटी डीएसएल काम आता है।
वाक्यात्मक दृष्टिकोण से, उपभोक्ता या निर्माता की परवाह किए बिना सत्यापन जाँच सुसंगत रहती है। सत्यापन नियमों का सेट किसी विशिष्ट उपभोक्ता या निर्माता से बंधा नहीं है और इसे एक बार और सभी के लिए एकल स्कीमा के रूप में परिभाषित किया जा सकता है।
हालाँकि, वेरिटी डेटा अनुबंध डीएसएल छोटे स्वतंत्र नियमों को परिभाषित करने वाली एक बेहतर ग्रैन्युलैरिटी प्रदान करता है, जो इस संदर्भ के लिए विशेष रूप से उपयुक्त है: डेटा का अर्थपूर्ण अर्थ और उपयोग विशिष्ट उपभोक्ता के आधार पर भिन्न होता है। इसके अतिरिक्त, सभी उपभोक्ताओं को किसी वस्तु के सभी गुणों का उपयोग करने की आवश्यकता नहीं है। उनकी उम्मीदें अलग-अलग हैं. इसका मतलब यह नहीं है कि वे विरोधाभासी हैं (जो निश्चित रूप से एक मुद्दा होगा), बल्कि पूरक और विशिष्ट हैं।
इसलिए, सभी उपभोक्ताओं को अद्वितीय नियम स्थापित करने की अनुमति देना, जो सहयोगात्मक रूप से संयुक्त होने पर, डेटा गुणवत्ता के अर्थपूर्ण महत्व की व्यापक समझ प्रदान कर सकते हैं, काफी महत्वपूर्ण है।
और यह सहयोगात्मक पहलू है जो विशेष रूप से मेरे साथ मेल खाता है। धैर्य रखें, यह एक खिंचाव की तरह लग सकता है, लेकिन मेरे दृष्टिकोण से, यह उल्लेख के लायक है। :)
डेटा एक्सचेंज विभिन्न टीमों (निर्माताओं और उपभोक्ताओं) को प्रभावी ढंग से सहयोग करने में सक्षम बनाता है। पारंपरिक सॉफ्टवेयर विकास में एपीआई की तरह, इन डेटा एक्सचेंजों की साझा समझ स्थापित करना सर्वोपरि है। माइक्रोसर्विस आर्किटेक्चर में, उपभोक्ता-संचालित अनुबंध (सीडीसी) के रूप में जाना जाने वाला एक सहयोगात्मक परीक्षण दृष्टिकोण उभरा है, जहां उपभोक्ता उत्पादकों द्वारा प्रदान किए गए एपीआई के अपेक्षित व्यवहार को परिभाषित करते हैं। नए संस्करण जारी करने से पहले इन अनुबंधों को सत्यापित करने की जिम्मेदारी निर्माताओं की है।
मुझे लगता है कि डेटा अनुबंध एक समान सहयोगात्मक भावना साझा करते हैं। भले ही डेटा सत्यापन रिलीज़ समय के बजाय वास्तविक डेटा पर किया जाता है, और रिलीज़ को अवरुद्ध नहीं करता है, यह सहयोग पर आधारित है और डेटा उत्पादकों और उपभोक्ताओं के बीच टीम वर्क को प्रोत्साहित करता है। मेरा दृढ़ विश्वास है कि यह सहयोगात्मक दृष्टिकोण डेटा गुणवत्ता में सुधार के लिए महत्वपूर्ण है और इसे इस प्रक्रिया में और एकीकृत किया जाना चाहिए।
खैर, मैं समानताएं खींचने का बहुत बड़ा प्रशंसक हूं...
वास्तव में ध्यान दें कि यह सहयोगात्मक पहलू Lyft के सत्यता चार्टर के हिस्से के रूप में भी उल्लिखित है।
वेरिटीयूआई, वेरिटी होमपेज के माध्यम से एक सुव्यवस्थित डेटा खोज अनुभव प्रदान करता है। चेक डेफिनिशन मेटाडेटा पर हमारी पूर्ण-पाठ खोज उपयोगकर्ताओं को वर्तमान में लागू किए जा रहे सभी चेक और उनके चेक परिणाम देखने देती है। इसमें स्वामित्व टीम, तालिका नाम और टैग जैसे उपयोगी एकत्रीकरण हैं।
मैं इस बारे में पूरी तरह से स्पष्ट नहीं हूं कि वेरिटी प्लेटफॉर्म यूआई के माध्यम से उपभोक्ताओं और उत्पादकों के बीच डेटा अनुबंध के मुद्दों को कैसे साझा किया जाता है, लेकिन मैं डैशबोर्ड के माध्यम से सहयोग के महत्व को निश्चित रूप से पहचानता हूं:
सौभाग्य से, सोडा कोर नामक एक और ओपन-सोर्स डेटा गुणवत्ता ढांचा है जो समान कार्यक्षमता प्रदान करता है।
सोडा कोर एक मुफ़्त और ओपन-सोर्स कमांड-लाइन टूल और पायथन लाइब्रेरी है जो डेटा इंजीनियरों को डेटा गुणवत्ता का परीक्षण करने में सक्षम बनाता है। यह SQL क्वेरी उत्पन्न करने के लिए उपयोगकर्ता-परिभाषित इनपुट का उपयोग करता है जो अमान्य, गुम या अप्रत्याशित डेटा को खोजने के लिए डेटा स्रोत में डेटासेट पर जांच चलाता है। जब चेक विफल हो जाते हैं, तो वे उस डेटा को सामने लाते हैं जिसे आपने चेक में "खराब" के रूप में परिभाषित किया है।
डेटासेट के स्कैन के दौरान, सोडा कोर अमान्य, गुम या अप्रत्याशित डेटा की पहचान करने के लिए पूर्वनिर्धारित जांच का मूल्यांकन करता है।
यहां पहले से परिभाषित वेरिटी डीएसएल परीक्षण के लिए सोडा.कोर सिंटैक्स का उपयोग करके समतुल्य जांच है।
name: rider_events_session_id_check source: hive query: SELECT * FROM rider_events WHERE session_id IS NULL; raise_alert: true threshold: 10 action: slack message: "There are more than 10 rows that are null for the 'session_id' property in the 'rider_events' table. Please investigate this issue."
soda run --check checks/rider_events_session_id_check.yaml
सोडा कोर आपके डेटा की गुणवत्ता सुनिश्चित करने के लिए एक शक्तिशाली उपकरण है। इससे आपको डेटा समस्याओं को जल्दी पहचानने और ठीक करने में मदद मिल सकती है, इससे पहले कि वे आपके व्यवसाय के लिए समस्याएं पैदा कर सकें।
यह ध्यान देने योग्य है कि सोडा कोर स्पार्क डेटाफ्रेम के साथ सहजता से एकीकृत होकर स्ट्रीमिंग डेटा के लिए डेटा गुणवत्ता जांच की सुविधा भी प्रदान कर सकता है।
जबकि हाइव के लिए वेरिटी की डेटा गुणवत्ता जांच स्थिर डेटासेट पर लागू की जाती है, स्ट्रीमिंग डेटा की जांच अधिक हल्के और कुशल होने की आवश्यकता है।
डेटा को आम तौर पर बहुत कम विलंबता के साथ घटनाओं के छोटे बैचों में संसाधित किया जाएगा, जो उन्हें वास्तविक समय की जांच और विसंगति का पता लगाने जैसे विशिष्ट उपयोग के मामलों के लिए उपयुक्त बनाता है।
अंत में, आइए उल्लेख करें कि अन्य डेटा सत्यापन उपकरण उपलब्ध हैं, जैसे DeeQu, ग्रेट एक्सपेक्टेशंस, ...
हमने डेटा गुणवत्ता सुधार के लिए दो अलग-अलग दृष्टिकोण देखे हैं, प्रत्येक की अपनी ताकत और कार्यप्रणाली है। एक दृश्यता और अवलोकन क्षमता बढ़ाने पर ध्यान केंद्रित करता है, डेटा उत्पादकों को गुणवत्ता स्तर बढ़ाने के लिए प्रेरित करता है। दूसरा परीक्षण और सत्यापन-प्रथम दृष्टिकोण के माध्यम से गुणवत्ता मानक को ऊपर उठाने को प्राथमिकता देता है। दोनों एक दूसरे के पूरक हैं.
डेटा जांच को परिभाषित करने के लिए वेरिटी केवल एक डोमेन-विशिष्ट भाषा (डीएसएल) नहीं है; यह एक केंद्रीकृत मंच है जो डेटा पेशेवरों को प्रभावी ढंग से सहयोग करने का अधिकार देता है। यह प्लेटफ़ॉर्म उत्पादकों और उपभोक्ताओं को प्रारूप, संरचना और सटीकता सहित डेटा गुणवत्ता अपेक्षाओं पर संरेखित करने में मदद करता है।
अधिक परिष्कृत डेटा गुणवत्ता आवश्यकताओं को पूरा करने के लिए मेटाडेटा प्रबंधन और खोज जैसी सुविधाओं के व्यापक सेट के साथ एकीकृत करके वेरिटी की डेटा अनुबंध प्रबंधन क्षमताओं को और बढ़ाया जा सकता है (है?)।
Airbnb के DQ स्कोर के समान, Lyft's Verity डेटा उत्पादकों और उपभोक्ताओं के बीच एक सहयोगात्मक फीडबैक लूप को बढ़ावा देता है। डेटा गुणवत्ता का स्वामित्व लेने के लिए प्रत्येक टीम को प्रोत्साहित और सशक्त बनाकर, वेरिटी एक सहायक वातावरण तैयार करता है जहां डेटा गुणवत्ता में लगातार सुधार होता है।
क्या आपको यह लेख उपयोगी लगा? मेरा अनुसरण करो
यहाँ भी प्रकाशित किया गया है.