डेटा क्यूए: आपल्याला याची आवश्यकता का आहे आणि ते कसे करावे

अनुभवी डेटा व्यावसायिक (डेटा शास्त्रज्ञ, डेटा विश्लेषक, डेटा अभियंता इ.) “कचरा इन, कचरा बाहेर टाकणे” या म्हणीशी परिचित असतील. थोडक्यात सांगा, चुकीच्या डेटावर आधारित बेसिक रिसर्चचा परिणाम वाईट निष्कर्षांवर येईल. हे टाळण्यासाठी, हे महत्त्वाचे आहे की दुसरे काहीही करण्यापूर्वी डेटा शास्त्रज्ञांना प्रथम त्यांनी पहात असलेला डेटा जाणून घ्यावा.

डेटासेटशी अधिक परिचित होणे हे समजून घेणे सुरू होते की त्यांच्यापर्यंत पोहोचण्यापूर्वी डेटासेटने आधीच विस्तृत प्रवास केला आहे. म्हणूनच, त्यांनी त्यांचे संशोधन सुरू करण्यापूर्वी डेटा व्यावसायिकांना त्या प्रवासाची प्रत्येक गोष्ट समजून घेणे आवश्यक आहे.

डेटा क्यूएची पहिली पायरी म्हणजे डेटा गोळा करण्याची प्रक्रिया समजून घेणे. यासाठी, शास्त्रज्ञांनी विचारलेल्या काही प्रश्नांमध्ये प्रथम हे समाविष्ट करणे आवश्यक आहे:

This हा डेटा कसा गोळा केला किंवा तयार केला गेला? ‍

हे डेटाद्वारे लॉग इन करणार्‍या सिस्टमद्वारे किंवा सर्वेक्षणात तयार केले गेले आहे? हे एका विशिष्ट डिव्हाइसद्वारे तयार केले गेले होते? तसे असल्यास, डिव्हाइस स्वयंचलितपणे किंवा व्यक्तिचलितपणे चालते? डेटा संकलन कालावधीत सिस्टम बॅकआउट सारख्या काही बग किंवा इतर समस्या आल्या?

This या टप्प्यांपर्यंत डेटा कोणाने हाताळला?

आत्तापर्यंत डेटाचे व्यवस्थापन करणार्‍या लोकांनी यावर काही फिल्टर लागू केले आहेत का? केवळ संबंधित उपलब्ध स्त्रोतांच्या भागातून डेटा गोळा करून किंवा संबंधित असू शकेल असा डेटा काढून टाकून त्यांनी कोणत्याही पक्षपातीपणाची ओळख करुन दिली? मी पहात नाही असा डेटा आहे?

Data डेटामध्ये कोणतेही फिल्टर आहेत?

डेटा संकलन प्रक्रियेने काही फिल्टर अनावधानाने अंमलात आणले असू शकतात, उदाहरणार्थ, सर्व डेटा संकलन पद्धती किंवा उपकरणे समान रीतीने कार्यरत नसल्यास.

आपण प्राप्त केलेला डेटा संकलनाच्या पूर्वीच्या टप्प्यावर फिल्टर केला गेला असावा.

ते त्यांचे संशोधन सुरू करण्यापूर्वी डेटा शास्त्रज्ञांना दोन गोष्टींबद्दल निश्चित असणे आवश्यक आहे: कोणताही डेटा गहाळ आहे की नाही आणि ते ज्या डेटाची तपासणी करत आहेत त्यात काही बदल झाले आहेत की नाही.

एकदा एखाद्या डेटासेटने घेतलेल्या प्रवासाबद्दल आणि त्यानंतर कोणतेही फिल्टर किंवा पक्षपाती उघडकीस आले की ते डेटा स्पष्ट झाल्यानंतर डेटा व्यावसायिक डेटा क्यूए सुरू करू शकतात. हा लेख डेटा क्यूए चे दोन टप्पे पार पाडण्यासाठी सामान्य मार्गदर्शक तत्त्वे ऑफर करतो: Apप्रुरी डेटा व्हॅलिडेशन आणि स्टॅटिस्टिकल डेटा व्हॅलिडेशन. संशोधन सुरू होण्यापूर्वी या डेटा क्यूए चरणांची पूर्तता करणे महत्त्वपूर्ण आहे. ठोस डेटा क्यूए प्रक्रियेद्वारे डेटा शास्त्रज्ञ हे सुनिश्चित करू शकतात की त्यांनी आपल्या संशोधनावर आधारित माहिती योग्य आहे.

अपप्रायोरी डेटा प्रमाणीकरण

अप्रीओरी डेटा प्रमाणीकरण डेटामधील सर्व फील्डचे पुनरावलोकन करण्याच्या प्रक्रियेचे वर्णन करते आणि ज्या डेटासेटमध्ये आपण विश्वास ठेवू शकता अशा अस्तित्वात नसू शकणारे नियम आणि शर्ती तयार करतात.

उदाहरणार्थ, जाहिरातींमधील रूपांतरणे दर्शविणारा डेटासेट घ्या, जेथे रूपांतरण घडण्यासाठी क्लिक आवश्यक आहे. ही अट रूपांतरण स्तंभ आणि क्लिक स्तंभ यांच्यातील संबंध परिभाषित करते. क्लिक केल्याशिवाय रूपांतरण अस्तित्त्वात नसल्यामुळे, त्याच पंक्तीतील एका क्लिकसाठी रुपांतरणासाठी TRUE मूल्य FALSE मूल्यासह दिसू शकत नाही.

डेटा व्यावसायिकांनी डेटासेटची तपासणी करण्यास आणि त्यास विस्तृत स्तंभात, विविध स्तंभ आणि पंक्तींमधील संबंधांचे वर्णन करण्यास सक्षम असणे आवश्यक आहे. डेटा विश्वसनीय असल्याचे समजण्यासाठी या संबंधांनी पाळणे आवश्यक कठोर नियम त्यांनी ओळखले पाहिजेत.

दुसरे उदाहरण म्हणून, शहरासाठी फील्ड आणि राज्यासाठी फील्ड असलेले डेटासेटचा विचार करा. जर डेटासेटमध्ये एलए आणि न्यूयॉर्क जोडलेले असतील तर याचा अर्थ नाही. राज्य फील्डमध्ये एक राज्य असणे आवश्यक आहे आणि संबंधित शहर क्षेत्रामध्ये सूचित केलेले शहर त्या राज्यात प्रत्यक्षात अस्तित्वात असले पाहिजे. म्हणून नियम निश्चित करणे आवश्यक आहे.

अतार्किक डेटाची उदाहरणे.

त्यांच्यासमोर ठेवलेल्या माहितीची काळजीपूर्वक तपासणी करून डेटा व्यावसायिकांनी शोधत असलेले डेटा आणि संशोधनावर अवलंबून राहू शकते हे सत्यापित करण्यासाठी आवश्यक असलेले प्रश्न व उत्तरे तयार करण्यात सक्षम असणे आवश्यक आहे. परंतु कोणते प्रश्न विचारायचे हे डेटा वैज्ञानिकांना कसे कळेल? उत्तर सोपे आहे: त्यांचे गृहकार्य करा!

आरंभ करण्यासाठी एक चांगली जागा म्हणजे स्तंभानुसार डेटा स्तंभ पहात आणि त्या प्रत्येकाच्या दरम्यानच्या संबंधांवर विचार करणे. डेटा वैज्ञानिकांनी विचार केला पाहिजे की स्तंभ एखाद्या घटकाच्या रुपात पाहिले जाऊ शकतो - डेटाचा तुकडा जो सहकारी स्तंभांच्या समुदायात राहतो. पंक्ती, एक अस्तित्व म्हणून, त्याच्या स्तंभांच्या माहितीची बेरीज असते आणि त्या दरम्यानचे संबंध देखील असतात. डेटा व्यावसायिकांना याची खात्री करणे आवश्यक आहे की त्यांनी या समुदायांमधील सर्वात लहान घटकासह, एकल मूल्यासह प्रारंभ केला आहे आणि हळूहळू झूम कमी करा आणि त्याचे संबंध इतर "अणू" वर बनवा - इतर स्तंभांमधील मूल्ये, सर्व मिळून "रेणू तयार करतात." ”ही एक रो आहे.

एप्रुरी डेटा प्रमाणीकरण करताना येथे काही नियम विचारात घ्याः

Column स्तंभात केवळ अपरकेस किंवा लोअरकेस अक्षरे असणे आवश्यक आहे

Column स्तंभातील मूल्य एन मधील मूल्यापेक्षा मोठे किंवा लहान असणे आवश्यक आहे. संबंधित स्तंभ

Column स्तंभात विशिष्ट मूल्ये किंवा वर्ण असू शकत नाहीत

Column स्तंभात विशिष्ट लांबीची मूल्ये असणे आवश्यक आहे

एप्रुरी डेटा प्रमाणीकरणादरम्यान देखील विचारले जाणारे प्रश्न हे समाविष्ट करतात:

There अशी कोणतीही व्हॅल्यूज गहाळ आहेत जेथे मूल्ये गहाळ होऊ नयेत?

The डेटामधे आम्ही डेटामध्ये पाहू इच्छित अशी सर्व फील्ड्स समाविष्ट आहेत काय?

Different वेळेत वेगवेगळ्या बिंदूंवर समान प्रमाणात डेटा प्रदान करणारे डेटावरील टाइमस्टॅम्प वैध आहेत काय? नसल्यास त्या वर्तनचे स्पष्टीकरण देता येईल का?

Values ​​मूल्यांच्या प्रमाणात अर्थ प्राप्त होतो? उदाहरणार्थ, स्तंभात केवळ शून्य आणि तीस दरम्यानची मूल्ये दर्शविली गेली असतील तर त्या श्रेणीबाहेर काही मूल्ये आहेत का?

A अशा फील्डमध्ये डुप्लिकेट असतात जिथे कोणतेही डुप्लिकेट अस्तित्त्वात नसावेत? ‍

शक्य असल्यास, डेटा व्यावसायिकांनी त्यांच्याकडे असलेल्या डेटाची तुलना देखील सत्य-थेट निरीक्षणाद्वारे प्रदान केलेल्या माहितीसह केली पाहिजे. उदाहरणार्थ, एखाद्या वापरकर्त्याच्या डिव्हाइसच्या जीपीएसवर एखाद्या कंपनीचा थेट प्रवेश असल्यास, डेटासेटमध्ये दर्शविल्यानुसार त्या वापरकर्त्याने एखाद्या विशिष्ट ठिकाणी भेट दिली आहे की नाही हे कंपनीने सत्यापित केले पाहिजे.

जर, अपुरीरी डेटा प्रमाणीकरणादरम्यान, डेटा कोणत्याही चाचणीत अयशस्वी झाला, तर डेटा व्यावसायिकांनी डेटाच्या मालकास सूचित केले पाहिजे आणि त्यांच्या संशोधनासाठी या डेटावर अवलंबून राहण्यापूर्वी समस्येचे निराकरण केले पाहिजे. ही परिस्थिती चांगली बातमी आणि वाईट बातमी दोन्ही असूनही (डेटावर विश्वास ठेवता येत नाही, परंतु एक बग शोधला गेला आहे), डेटा चाचणीत का अयशस्वी झाला हे समजून घेतल्यामुळे कदाचित अन्य अडचणी दूर केल्या गेल्या पाहिजेत. .

सांख्यिकीय डेटा प्रमाणीकरण

डेटा क्यूएच्या दुसर्‍या टप्प्यात, सांख्यिकीय डेटा प्रमाणीकरण, डेटा व्यावसायिकांनी ते पाहिलेला डेटा आपल्या अपेक्षेनुसार जुळत नाही की नाही हे सत्यापित करणे आवश्यक आहे. या सूक्ष्म प्रक्रियेमध्ये प्रत्येक गोष्टीवर प्रश्नचिन्ह समाविष्ट असते. डेटा वैज्ञानिकांनी जसा आहे तसा काहीही घेऊ नये - उदाहरणार्थ त्यांनी विचार केला पाहिजे की त्यांनी पहात असलेला डेटा त्यांच्या अंतर्ज्ञान आणि कौशल्याच्या अनुरुप आहे की नाही आणि त्यांच्या हातात असलेल्या इतर डेटासेटसमवेत त्याचा अर्थ आहे की नाही.

सांख्यिकीय डेटा प्रमाणीकरणात डेटा शास्त्रज्ञ डेटा आणि त्यामागील “का” समजून घेण्यासाठी त्यांचे डोमेन ज्ञान आणि सिस्टमचे त्यांचे ज्ञान वापरतात. आम्ही त्यांना ज्या स्थितीत सापडण्याची अपेक्षा करतो त्या लिहून प्रारंभ करण्याची शिफारस करतो. उदाहरणार्थ, जर तुमची सिस्टम दररोज दहा दशलक्ष वापरकर्त्यांची सेवा करत असेल तर, आपण त्या रकमेच्या आसपास असलेल्या डेटामधील प्रतिदिन प्रतिबिंबित होण्याची अपेक्षा करू शकाल. जर दिलेल्या महिन्यात डेटा केवळ 100,000 वापरकर्त्यांना सूचित करीत असेल तर हे असे प्रकरण दर्शवते जे सांख्यिकीय डेटा प्रमाणीकरणा दरम्यान उघड केले जाईल परंतु अपुरी डेटा प्रमाणीकरणा दरम्यान नाही.

सांख्यिकीय डेटा प्रमाणीकरण दरम्यान शोधल्या जाणार्‍या अटींच्या अतिरिक्त उदाहरणांमध्ये हे समाविष्ट आहेः

● टाइमस्टॅम्प्स: डेटा आपण पाहू इच्छित टाइमफ्रेम प्रतिबिंबित करतो? उदाहरणार्थ, जर आपण आइस्क्रीमचा वापर मोजत असाल आणि हिवाळ्याच्या महिन्यांत आपला डेटा पूर्व किनारपट्टीवरील माहिती दर्शवित असेल तर हे कदाचित आपल्या निकालास चिकटून जाईल. तथापि, बहुतेक लोक -10 डिग्री हवामानात खरोखरच आइस्क्रीम शंकूसाठी जातील का?

Lier आउटलेटर मूल्ये: ती वास्तविक आहेत काय? ते डेटामध्ये अस्तित्त्वात का आहेत? उदाहरणार्थ, आपल्याकडे तपमान नोंदविणारी पाच मशीन्स आहेत असे समजा, जेथे सेल्सिअसमध्ये चार रेकॉर्ड तापमान, तर फॅरेनहाइटमधील पाचव्या मशीनची नोंद आहे. आपला डेटा कदाचित नंतर “32, 32, 104, 33, 32.” दर्शवू शकेल. आउटलेटर मूल्य असे दर्शविते की या डेटासेटमधील काहीतरी लक्ष देणे आवश्यक आहे. लक्षात ठेवा की 99% वेळेत, एका डेटासेटमध्ये काही आउटलेट व्हॅल्यू समाविष्ट असतील. जर आपले तसे होत नसेल तर प्ले वर आपल्याला एखाद्या प्रकारची समस्या उद्भवली पाहिजे.

Data डेटाची मात्रा: याचा अर्थ प्राप्त होतो? पंक्ती, अद्वितीय वापरकर्ते, शहरे इत्यादींची संख्या आपल्यास अपेक्षित असलेल्याशी जुळते? दुसर्‍या शब्दांत सांगायचे तर भिन्न शहरांमधील डेटाचे प्रमाण त्या शहरांमधील भिन्न लोकसंख्या दर्शविते. जर एखादे शहर जादा किंवा तिचे प्रतिनिधित्व करत नसेल तर आपण त्या कशासाठी खाते देऊ शकता?

शिकागोमधील वापरकर्त्यांची संख्या इतर शहरांपेक्षा त्यांच्या आकारापेक्षा खूपच जास्त आहे.

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

प्रमाणीकरण परीक्षेच्या निकालांचे आपण कसे उपचार करावे?

सांख्यिकीय डेटा प्रमाणीकरणासाठी काय अपेक्षित आहे हे समजणे आवश्यक आहे. आपणास जे शोधायचे आहे त्याबद्दल काही अंतर्ज्ञान न घेता स्तंभाच्या वर्णनात्मक आकडेवारीची गणना करणे आपल्याला जे काही सापडेल त्यास न्याय्य ठरविण्याच्या ज्ञात पक्षपातीकडे नेईल. हा योग्य दृष्टीकोन नाही. तद्वतच, डेटा व्यावसायिकांना त्यांच्याकडून काय अपेक्षित आहे याची कल्पना येईल आणि डेटासेट त्या अपेक्षेसह संरेखित करेल. जर तसे झाले नाही, तर आपण त्याउलटबद्दल उत्सुक असले पाहिजे; आपल्या अपेक्षा बंद झाल्यामुळे ते अस्तित्त्वात आहे किंवा आपण डेटामध्ये काही त्रुटी आढळली आहे का?

किती पंक्तींमध्ये समस्याग्रस्त डेटा आहे हे समजून घेणे देखील महत्त्वाचे आहे. अशा काही मोजक्या पंक्ती असल्यास, या त्रुटींचा विचार करणे आणि त्या सुधारणे योग्य ठरणार नाही कारण ही तुलनात्मकदृष्ट्या अल्प प्रमाणात डेटा आहे. डेटासह समस्या शोधणे सामान्य आहे; काहीही सापडणे जवळपास अशक्य आहे.

विशेषत: जर डेटा परिपूर्ण दिसत नसेल तर कोणत्या ना कोणत्या समस्येवर शंका घेणे शहाणपणाचे ठरेल. तेथे कोणतेही डेटा आउटलिअर आणि / किंवा शून्य नसल्यास, आपण आधीच्या टप्प्यावर डेटा साफ केला आहे की नाही ते तपासावे. अशा साफसफाईच्या प्रक्रियेत डेटामध्ये आवाज आणि अवांछित पक्षपाती असू शकतात.

निष्कर्ष

आम्ही येथे वर्णन केलेल्या डेटा QA प्रक्रियाची अंमलबजावणी करताना आपण कधीच लक्षात न घेतलेल्या डेटा लेखन प्रक्रियेत बगच्या संख्येने आश्चर्यचकित व्हाल. बरेच लोक निकाल देण्यात अयशस्वी होण्याचे कारण हे दोष आहेत; हे खराब मॉडेलची निवड किंवा खराब वैशिष्ट्य अभियांत्रिकीमुळे नाही. कारण डेटा QAing ची महत्त्वपूर्ण प्रक्रिया दुर्लक्षित केली गेली.

परंतु या प्रकरणाची वस्तुस्थिती अशी आहे की डेटा क्यूए फार महत्वाचा आहे, परंतु हे देखील कंटाळवाणे, वेळ घेणारे आणि चूक प्रवण आहे. संबंधित प्रश्न विचारणे विसरणे सोपे आहे आणि त्यासाठी संबंधित तपशील गमावणे.

जरी आपल्याला आढळले की आपला डेटा पक्षपाती आहे आणि त्यात त्रुटी आहेत, याचा अर्थ असा नाही की तो वापरला जाऊ शकत नाही. याचा अर्थ डेटा व्यावसायिकांना पक्षपातीपणा आणि त्रुटींबद्दल जागरूक असणे आवश्यक आहे आणि हे समजून घ्यावे की संशोधनाचे निकाल केवळ ज्या संदर्भात संशोधन केले गेले त्या संदर्भातच संबंधित आहेत. उदाहरणार्थ, जर लवकर फिल्टर केले गेले असेल आणि उर्वरित डेटा एखाद्या विशिष्ट देशाचा असेल तर, त्या अभ्यासाचे निकाल केवळ त्या देशाशी संबंधित असतील आणि इतर देशांमध्ये जे सत्य आहे ते कमी करणे हे दिलेल्या डेटासेटसह शक्य नाही.

एकाच देशातील डेटावर आधारित अभ्यासाचे निष्कर्ष केवळ त्या देशाशी संबंधित असतील.

डेटा क्यूएंगमध्ये गुंतलेली सर्व कार्य आणि अज्ञाततेच्या प्रकाशात, आम्ही एक साधन विकसित केले आहे जे आपल्यासाठी बर्‍याच कामांना स्वयंचलित करते. आम्ही डेटा अत्यंत गंभीरपणे घेतो आणि आमचे साधन कोणत्याही डेटा वाईट डेटावर आधारित असण्याची शक्यता दूर करते. आमचे डेटा क्यूए साधन प्रत्येक डेटासेट स्कॅन करते आणि त्यातील सर्व त्रुटी नोंदवतात. यासह, आम्ही हे सुनिश्चित करण्यास सक्षम आहोत की आम्ही घन, विश्वासार्ह डेटावर आधारित संशोधन आणि निष्कर्षांसह "कचरा टाकणे, कचरा बाहेर टाकणे" टाळले पाहिजे.

उपयुक्त दुवे

pandas-प्रोफाइलिंग - pandas DataFrame ऑब्जेक्ट्स कडील प्रोफाइलिंग अहवाल

स्पार्क-डीएफ-प्रोफाइलिंग - अपाचे स्पार्क डेटाफ्रेम्स कडील प्रोफाइलिंग अहवाल

हे ब्लॉग पोस्ट मूलतः बिगबिड ब्लॉगसाठी लिहिलेले होते आणि येथे उपलब्ध आहे