डेटा कॉन्ट्रैक्ट्स क्या हैं? उदाहरणों के साथ शुरुआती मार्गदर्शिका

सेमांटिक डेटा कॉन्ट्रैक्ट्स

सेमांटिक डेटा वैलिडेशन सुनिश्चित करते हैं कि डेटा तार्किक रूप से सुसंगत हो और व्यवसायिक लॉजिक के अनुरूप हो।

सेमांटिक वैलिडेशन को स्पष्ट रूप से लागू करना होता है।

वास्तव में, स्कीमा जाँचों के विपरीत, सेमांटिक डेटा कॉन्ट्रैक्ट्स व्यवसायिक लॉजिक पर निर्भर होते हैं और इन्हें बाहरी रूप से लागू करना पड़ता है।

कई उपयोग-परिदृश्यों में, सेमांटिक्स स्कीमा-वैध कॉन्ट्रैक्ट्स का विस्तार जैसा दिखता है। यह अक्सर व्यवसायिक नियमों पर निर्भर करता है और पंक्ति-स्तरीय शर्तों के ऐसे सेट का प्रतिनिधित्व करता है जिनका हमारे डेटा मॉडल को पालन करना चाहिए। 

सेमांटिक कॉन्ट्रैक्ट का एक उदाहरण निम्न हो सकता है:

• मेट्रिक विचलन: मूविंग एवरेज या किसी अन्य थ्रेशहोल्ड से। मसलन, हम यह सह सकते हैं कि कल के सक्रिय उपयोगकर्ताओं की संख्या 7-दिवसीय मूविंग एवरेज के 75% से नीचे गिर जाए, पर 0% बर्दाश्त नहीं करेंगे।
• व्यवसायिक लॉजिक: ट्रांज़ैक्शन मॉनिटरिंग अलर्ट फ़्लैग्स और फ्रॉड प्रिवेंशन स्कोर। इस परिदृश्य में, पेआउट 0 होना चाहिए।
• डेटा लीनिएज: यह बताता है कि डेटा एंटिटीज़ कैसे विकसित होती हैं। उदाहरण के लिए, transaction_completed_at created_at से पहले नहीं हो सकता।
• रेफ़रेंशियल इंटीग्रिटी: एंटिटी संबंध महत्वपूर्ण हैं और इन्हें सेमांटिक कॉन्ट्रैक्ट्स से भी व्यक्त किया जा सकता है। नीचे दिया dbt कोड देखें। यह बताता है कि हर रिफंड का refund_id वैध transaction.id पर वापस मैप होता है।

- name: refunds
   enabled: true
   description: An incremental table
 columns:
     - name: refund_id
       tests:
         - relationships:
             tags: ['relationship']
             to: ref('transactions')
             field: idसंचालित द्वारा

सेमांटिक कॉन्ट्रैक्ट्स पर अलर्ट स्तर सेट करना अंतिम उपयोगकर्ता पर निर्भर है, और अक्सर इसे कस्टम डेटा गुणवत्ता परीक्षणों से लागू किया जाता है।

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

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

उदाहरण के लिए, customers और orders के बीच एक सामान्य संबंध एक-से-कई का होता है, जहाँ एक ग्राहक के कई orders हो सकते हैं। ऐसे परिदृश्य में, ऑर्डर तभी वैध माना जाएगा जब उसमें customers डेटासेट के भीतर एक वैध customer_id हो।

इस प्रकार का प्रतिबंध, एक रेफ़रेंशियल इंटीग्रिटी प्रतिबंध, सुनिश्चित करता है कि एंटिटीज़ के बीच संबंध सही ढंग से बनाए रखें जाएँ।

डेटा कॉन्ट्रैक्ट्स में सर्विस लेवल एग्रीमेंट्स (SLA)

SLA, डेटा गुणवत्ता जाँचों का एक अतिरिक्त स्तर हैं, जिन्हें डेटा कॉन्ट्रैक्ट्स के ज़रिए लागू किया जा सकता है।

SLA डेटा फ्रेशनेस से संबंधित होते हैं।

चूँकि डेटा मॉडल नियमित रूप से नए डेटा से अपडेट होते हैं, SLA में यह जाँच शामिल हो सकती है कि नया डेटा किस अंतिम समय तक उपलब्ध होने की उम्मीद है, या अधिकतम स्वीकार्य देरी क्या है। उदाहरण के लिए, dbt में, इसे freshness tests के माध्यम से हासिल किया जा सकता है:

- name: orders
   enabled: true
   description: A source table declaration
   tests:
     - dbt_utils.recency: # https://github.com/dbt-labs/dbt-utils#recency-source
         tags: ['freshness']
         datepart: day
         field: timestamp
         interval: 1संचालित द्वारा

मान लीजिए हम कल के तथ्यों पर एक रिपोर्ट बनाना चाहते हैं; इसके लिए हमें सुनिश्चित करना होगा कि डेटा मौजूद है। वास्तव में, कुछ दिनों या उससे अधिक समय तक नए ऑर्डर न दिखना अटपटा लगेगा।

नीचे दिए उदाहरण में, हम dbt में टेस्ट कॉन्फ़िग का उपयोग करके अपने डेटासेट में अप्रत्याशित ऑर्डर देरी की जाँच कर सकते हैं। यह आपको उस विशिष्ट नाम का उपयोग करके टेस्ट को चुनने और रेफ़रेंस करने देता है।

version: 2
models:
 - name: orders
   columns:
     - name: status
       tests:
         - accepted_values:
             name: unexpected_order_status_today
             values: ['placed', 'shipped', 'completed', 'returned']
             config:
               where: "order_date = current_date"संचालित द्वारा

कस्टम नाम परिभाषित करके, आपको लॉग संदेशों और मेटाडेटा आर्टिफैक्ट्स में टेस्ट कैसे प्रदर्शित हो—इस पर पूर्ण नियंत्रण मिलता है।

इसी तरह, रियल-टाइम डेटा पाइपलाइनों में, आमतौर पर अपेक्षा होती है कि डेटा कुछ घंटों से अधिक पुराना न हो। स्ट्रीम-प्रोसेसिंग अनुप्रयोगों के लिए SLA महत्वपूर्ण हैं, जहाँ डेटा मिनटों या सेकंडों की लेटेंसी के साथ रियल-टाइम में प्रोसेस होता है।

स्ट्रीमिंग ऐप्स में, हम लेट-एराइविंग इवेंट्स के लिए अधिकतम स्वीकार्य देरी, और Mean Time Between Failures (MTBF) तथा Mean Time to Recovery (MTTR) जैसी मेट्रिक्स की जाँच करना चाहते हैं। इसे लागू करने में घटनाओं का बारीकी से ट्रैक करना और PagerDuty, Datadog, और Grafana जैसे एप्लीकेशन मॉनिटरिंग और इंसीडेंट मैनेजमेंट टूल्स से संबंधित डेटा निकालना शामिल है।

डेटा गवर्नेंस कॉन्ट्रैक्ट्स

व्यक्तिगत पहचान योग्य जानकारी (PII) को सही ढंग से संभालना डेटा ट्रांसफ़ॉर्मेशन प्रक्रिया का अभिन्न हिस्सा है। कई कंपनियों के लिए, यह महत्वपूर्ण है कि ये डेटासेट कम से कम GDPR-अनुपालन हों और HIPAA या PCI DSS जैसी डेटा गोपनीयता विनियमों का पालन करें।

डेटा गवर्नेंस कॉन्ट्रैक्ट्स सुनिश्चित करते हैं कि पर्याप्त प्स्यूडोनिमाइज़ेशन या डेटा मास्किंग नीतियाँ लागू हों। 

नीचे दिया dbt कोड देखें। tests के रूप में लागू कॉन्ट्रैक्ट्स, user_email को SHA256 हैश (मास्क्ड) होना आवश्यक बताते हैं:

models:
 - name: customer_data
   columns:
       - name: user_email
         tests:
           - dbt_expectations.expect_column_values_to_not_match_regex:
               regex: "^(?!.*\b@\b).* # Ensure identifiers do not contain emails
               flags: i # Case-insensitive matchingसंचालित द्वारा

दूसरी ओर, हम अन्य टेबल्स के लिए पैटर्न मिलान लागू करना चाह सकते हैं। उदाहरण के लिए, नीचे दिए उदाहरण में, transaction_reference फ़ील्ड को [“TRX-%”, “%-2023”] पैटर्न का पालन करना चाहिए:

models:
 - name: transaction_data
   columns:
       - name: transaction_reference
         tests:
           - dbt_expectations.expect_column_values_to_match_like_pattern_list:
               like_pattern_list: ["TRX-%", "%-2023"]
               match_on: anyसंचालित द्वारा

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

उदाहरण के लिए, हम dbt में meta फ़ील्ड का उपयोग करके अपने डेटा मॉडल के मालिक और मॉडल डेवलपमेंट लाइफसाइकल स्टेज को इंगित कर सकते हैं:

# models/schema.yaml
version: 2
models:
 - name: users
   meta:
     owner: "@data_mike"
     model_maturity: in dev
     contains_pii: true
   columns:
     - name: email
       meta:
       contains_pii: trueसंचालित द्वारा

meta फ़ील्ड आपको किसी संसाधन के लिए मेटाडेटा सेट करने देता है, जो बाद में dbt द्वारा जनरेट की गई manifest.json फ़ाइल में कम्पाइल हो जाता है और ऑटो-जनरेटेड डॉक्यूमेंटेशन में देखा जा सकता है। 

हम dbt-checkpoint जैसे पैकेज का उपयोग पुल रिक्वेस्ट के दौरान इसे स्कैन करने के लिए कर सकते हैं, ताकि यह सुनिश्चित हो कि हमारे अनिवार्य मेटा फ़ील्ड मौजूद हैं। यदि किसी मॉडल (मैनिफेस्ट या YAML फ़ाइलों से) में निर्दिष्ट मेटा कीज़ नहीं हैं, तो हुक असफल हो जाता है।

मॉडल की meta कीज़ YAML फ़ाइल या मैनिफेस्ट में होनी चाहिए।

डेटा कॉन्ट्रैक्ट कार्यान्वयन पैटर्न

कॉन्ट्रैक्ट वैलिडेशन, स्ट्रीमिंग डेटा पाइपलाइनों (प्रति पंक्ति) में, डेटा के इन्जेस्ट होने से पहले और बाद में—सोर्स (सोर्स डेटा मॉडल लेयर) पर—किया जा सकता है।

जब हम डेटा को “जैसा है” इन्जेस्ट करते हैं, तो वैलिडेशन प्रक्रिया एक ट्रांसफॉर्मेशन स्टेप की तरह काम करती है, कॉन्ट्रैक्ट नियम लागू करती है और अमान्य डेटा को फ़िल्टर कर देती है, यानी एक समर्पित डेटाबेस व्यू या टेबल में, जहाँ डेटा की आगे जाँच-पड़ताल की जा सके।

जब डेटा सीधे रॉ डेटा लेक में इन्जेस्ट किया जाता है, तब वैलिडेशन जाँचें बाद में भी लागू की जा सकती हैं।

रियल-टाइम डेटा कॉन्ट्रैक्ट वैलिडेशन का मुख्य लाभ यह है कि यह अमान्य रिकॉर्ड्स को उनके अंतिम गंतव्य—डेटा लेक या डेटा वेयरहाउस—तक पहुँचने से पहले ही फ़िल्टर कर देता है। यह दृष्टिकोण इवेंट-ड्रिवन या रियल-टाइम डेटा प्रोसेसिंग, जैसे Change Data Capture (CDC) इवेंट्स में आम है। इस प्रकार के वैलिडेशन में, डेटा पाइपलाइन से बहते समय कॉन्ट्रैक्ट के कुछ पहलुओं की जाँच होती है।

डेटा कॉन्ट्रैक्ट्स टूल्स

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

इसी तरह के कॉन्ट्रैक्ट्स को Google के Dataform के ज़रिए सोर्स (सोर्स डेटा मॉडल लेयर) पर, यानी जब डेटा सफलतापूर्वक हमारे डेटा वेयरहाउस में इन्जेस्ट हो चुका हो, लागू किया जा सकता है। इसके लिए हम साधारण रो कंडीशंस का उपयोग करना चाहेंगे। 

नीचे दिया उदाहरण देखें। यह हमारी टेबल के लिए कुछ रो कंडीशंस लागू करता है:

-- my_table.sqlx
config {
 type: "table",
 assertions: {
   nonNull: ["user_id", "customer_id", "email"]
 }
}
SELECT …संचालित द्वारा

नीचे डेटा कॉन्ट्रैक्ट कार्यान्वयन का एक और उदाहरण है, जिसे Soda.io—एक विशेष डेटा गुणवत्ता फ़्रेमवर्क—का उपयोग करके हासिल किया जा सकता है:

# Checks for basic validations
checks for dim_customer:
 - row_count between 10 and 1000
 - missing_count(birth_date) = 0
 - invalid_percent(phone) < 1 %:
     valid format: phone number
 - invalid_count(number_cars_owned) = 0:
     valid min: 1
     valid max: 6
 - duplicate_count(phone) = 0संचालित द्वारा

अलर्ट सेटिंग्स को समायोजित करने से आप जाँच को वैलिडेशन असफल कराने के बजाय चेतावनी जारी करने के लिए कॉन्फ़िगर कर सकते हैं। Soda स्कैन किसी समझौते में निर्दिष्ट जाँचें चलाता है, YAML फ़ाइल या प्रोग्रामेटिक इनवोकेशन के भीतर इनलाइन जाँचता है, और हर जाँच के लिए एक परिणाम लौटाता है: पास, फेल, या एरर।

मेरे अनुभव में, कई कंपनियों में डेटा कॉन्ट्रैक्ट्स का परिचय खंडित रहता है—यह डेटा पाइपलाइन डिज़ाइन पैटर्न (बैच या रियल-टाइम), डेटा सीरियलाइज़ेशन विकल्पों, और स्टोरेज व प्रोसेसिंग के लिए उपयोग किए जाने वाले सिस्टम्स जैसे कारकों पर निर्भर करता है।

डेटा कॉन्ट्रैक्ट्स का कार्यान्वयन व्यवसायिक आवश्यकताओं और लॉजिक पर निर्भर करता है।

Great Expectations, एक Python लाइब्रेरी, का उपयोग सेमांटिक-स्तर डेटा कॉन्ट्रैक्ट्स लागू करने के लिए किया जा सकता है। इसे pip से इंस्टॉल किया जा सकता है: pip install great_expectations। 

great_expectations init चलाने के बाद, हम डेटा वैलिडेशन कर सकते हैं:

Using v3 (Batch Request) API
 ___              _     ___                  _        _   _
/ __|_ _ ___ __ _| |_  | __|_ ___ __  ___ __| |_ __ _| |_(_)___ _ _  ___
| (_ | '_/ -_) _ |  _| | _|\ \ / '_ \/ -_) _|  _/ _ |  _| / _ \ ' \(_-<
\___|_| \___\__,_|\__| |___/_\_\ .__/\___\__|\__\__,_|\__|_\___/_||_/__/
                               |_|
            ~ Always know what to expect from your data ~
Let's create a new Data Context to hold your project configuration.
Great Expectations will create a new directory with the following structure:
   great_expectations
   |-- great_expectations.yml
   |-- expectations
   |-- checkpoints
   |-- plugins
   |-- .gitignore
   |-- uncommitted
       |-- config_variables.yml
       |-- data_docs
       |-- validations
OK to proceed? [Y/n]:संचालित द्वारा

नीचे दिया कोड स्निपेट देखें। यह बताता है कि price कॉलम के लिए डेटा जाँच परिभाषा कैसे बनाई जाए:

"expectation_type": "expect_column_values_to_match_regex",
"kwargs": {
 "column": "price",
 "mostly": 1.0,
 "regex": "^\\$([0-9],)*[0-9]+\\.[0-9]{2}$"
},संचालित द्वारा

डेटा कॉन्ट्रैक्ट्स के सर्वोत्तम अभ्यास

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

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

निष्कर्ष

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

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

डेटा गवर्नेंस कॉन्ट्रैक्ट्स को CI/CD पाइपलाइनों में भी लागू किया जा सकता है और जब वे संवेदनशील डेटा वाले कॉलम, मेटाडेटा (डेटा मालिक आदि) और किसी डेटा प्रोडक्ट तक पहुँच के लिए अधिकृत उपयोगकर्ता भूमिकाएँ इंगित करते हैं, तो ये बहुत उपयोगी हो जाते हैं। 

किसी मॉडल का मेटाडेटा, साथ ही डेवलपर द्वारा परिभाषित अन्य अनिवार्य मेटा फ़ील्ड्स, मॉडल के संसाधन उपयोग और प्रदर्शन की निगरानी में मदद करते हैं। 

डेटा कॉन्ट्रैक्ट्स के भीतर सर्विस लेवल एग्रीमेंट्स (SLA), डेटा फ्रेशनेस, पूर्णता और फ़ेल्यर रिकवरी से संबंधित विशिष्ट प्रतिबद्धताओं को स्पष्ट करते हैं।

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