🥇डेटा साइंस में क्या गलत हो सकता है? डेटा संग्रह

आज 100500 डेटा साइंस पाठ्यक्रम हैं और यह लंबे समय से ज्ञात है कि डेटा साइंस में सबसे अधिक पैसा डेटा साइंस पाठ्यक्रमों के माध्यम से कमाया जा सकता है (जब आप फावड़ा बेच सकते हैं तो खुदाई क्यों करें?)। इन पाठ्यक्रमों का मुख्य नुकसान यह है कि इनका वास्तविक कार्य से कोई लेना-देना नहीं है: कोई भी आपको आवश्यक प्रारूप में साफ, संसाधित डेटा नहीं देगा। और जब आप पाठ्यक्रम छोड़ते हैं और किसी वास्तविक समस्या को हल करना शुरू करते हैं, तो कई बारीकियाँ सामने आती हैं।

इसलिए, हम मेरे, मेरे साथियों और सहकर्मियों के साथ हुई वास्तविक घटनाओं पर आधारित नोट्स "डेटा साइंस में क्या गलत हो सकता है" की एक श्रृंखला शुरू कर रहे हैं। हम वास्तविक उदाहरणों का उपयोग करके विशिष्ट डेटा विज्ञान कार्यों का विश्लेषण करेंगे: यह वास्तव में कैसे होता है। आइए आज डेटा संग्रह कार्य से शुरुआत करें।

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

हम व्यवस्थित रूप से डेटा एकत्र करने, साफ़ करने और तैयार करने के लिए आवश्यक समय, संसाधनों और प्रयास को कम आंकते हैं।

और सबसे महत्वपूर्ण बात, हम चर्चा करेंगे कि इसे रोकने के लिए क्या करना चाहिए।

विभिन्न अनुमानों के अनुसार, सफाई, परिवर्तन, डेटा प्रोसेसिंग, फीचर इंजीनियरिंग आदि में 80-90% समय लगता है, और विश्लेषण में 10-20% समय लगता है, जबकि लगभग सभी शैक्षिक सामग्री विशेष रूप से विश्लेषण पर केंद्रित होती है।

आइए एक साधारण विश्लेषणात्मक समस्या को तीन संस्करणों में एक विशिष्ट उदाहरण के रूप में देखें और देखें कि "गंभीर परिस्थितियाँ" क्या हैं।

और एक उदाहरण के रूप में, हम फिर से डेटा एकत्र करने और समुदायों की तुलना करने के कार्य की समान विविधताओं पर विचार करेंगे:

दो रेडिट सबरेडिट्स
हबर के दो खंड
Odnoklassniki के दो समूह

सिद्धांत में सशर्त दृष्टिकोण

साइट खोलें और उदाहरण पढ़ें, यदि यह स्पष्ट है, तो पढ़ने के लिए कुछ घंटे अलग रखें, उदाहरणों का उपयोग करने वाले कोड और डिबगिंग के लिए कुछ घंटे अलग रखें। संग्रह के लिए कुछ घंटे जोड़ें. कुछ घंटे आरक्षित रखें (दो से गुणा करें और एन घंटे जोड़ें)।

मुख्य बिंदु: समय का अनुमान अनुमानों और अनुमान पर आधारित होता है कि इसमें कितना समय लगेगा।

ऊपर वर्णित सशर्त समस्या के लिए निम्नलिखित मापदंडों का अनुमान लगाकर समय विश्लेषण शुरू करना आवश्यक है:

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

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

और अब हम विशिष्ट उदाहरण प्रदर्शित करेंगे जहां ऐसे पैरामीटर बदल जाएंगे।

मुख्य बिंदु: अनुमान कार्य के दायरे और जटिलता को प्रभावित करने वाले प्रमुख कारकों के विश्लेषण पर आधारित है।

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

रेडिट समुदायों की तुलना

आइए सबसे सरल मामले से शुरू करें (जैसा कि बाद में पता चला)। सामान्य तौर पर, पूरी तरह से ईमानदार होने के लिए, हमारे पास लगभग एक आदर्श मामला है, आइए हमारी जटिलता जांच सूची देखें:

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

def get_comments(submission_id):
    reddit = Reddit(check_for_updates=False, user_agent=AGENT)
    submission = reddit.submission(id=submission_id)
    more_comments = submission.comments.replace_more()
    if more_comments:
        skipped_comments = sum(x.count for x in more_comments)
        logger.debug('Skipped %d MoreComments (%d comments)',
                     len(more_comments), skipped_comments)
    return submission.comments.list()

से लिया गया यह रैपिंग के लिए सुविधाजनक उपयोगिताओं का चयन।

इस तथ्य के बावजूद कि यह सबसे अच्छा मामला है, फिर भी वास्तविक जीवन के कई महत्वपूर्ण कारकों को ध्यान में रखना उचित है:

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

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

हेबर अनुभागों की तुलना

आइए हेबर के थ्रेड्स और/या अनुभागों की तुलना के अधिक दिलचस्प और गैर-तुच्छ मामले की ओर बढ़ते हैं।

आइए हमारी जटिलता चेकलिस्ट देखें - यहां, प्रत्येक बिंदु को समझने के लिए, आपको कार्य में थोड़ा खोदना होगा और प्रयोग करना होगा।

पहले तो आपको लगता है कि कोई एपीआई है, लेकिन ऐसा नहीं है। हां, हां, हैबर के पास एक एपीआई है, लेकिन यह उपयोगकर्ताओं के लिए पहुंच योग्य नहीं है (या शायद यह बिल्कुल भी काम नहीं करता है)।
फिर आप बस HTML - "आयात अनुरोध" को पार्स करना शुरू कर दें, क्या गलत हो सकता है?
फिर भी पार्स कैसे करें? सबसे सरल और सबसे अधिक इस्तेमाल किया जाने वाला तरीका आईडी पर पुनरावृत्ति करना है, ध्यान दें कि यह सबसे कुशल नहीं है और इसे विभिन्न मामलों को संभालना होगा - यहां सभी मौजूदा आईडी के बीच वास्तविक आईडी के घनत्व का एक उदाहरण दिया गया है।

से लिया गया यह लेख।
वेब के शीर्ष पर HTML में लिपटा कच्चा डेटा कष्टकारी है। उदाहरण के लिए, आप किसी लेख की रेटिंग एकत्र करना और सहेजना चाहते हैं: आपने HTML से स्कोर को फाड़ दिया है और इसे आगे की प्रक्रिया के लिए एक संख्या के रूप में सहेजने का निर्णय लिया है:
1) int(स्कोर) एक त्रुटि देता है: चूंकि हैबे पर एक माइनस है, उदाहरण के लिए, लाइन "-5" में - यह एक एन डैश है, माइनस साइन नहीं (अप्रत्याशित रूप से, ठीक है?), इसलिए कुछ बिंदु पर मुझे ऐसे भयानक सुधार के साथ पार्सर को जीवंत बनाना पड़ा।
```
try:
      score_txt = post.find(class_="score").text.replace(u"–","-").replace(u"+","+")
      score = int(score_txt)
      if check_date(date):
        post_score += score
```
हो सकता है कि कोई तारीख, प्लस या माइनस बिल्कुल भी न हो (जैसा कि हम ऊपर चेक_डेट फ़ंक्शन में देखते हैं, ऐसा हुआ)।

2) अनछुए विशेष पात्र - वे आएंगे, आपको तैयार रहने की आवश्यकता है।

3) पोस्ट के प्रकार के आधार पर संरचना बदलती रहती है।

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

जटिलता के आधार पर कुल चेकलिस्ट:

नेटवर्क के साथ काम करना और पुनरावृत्ति के साथ HTML पार्सिंग और आईडी द्वारा खोज।
विषम संरचना के दस्तावेज़.
ऐसे कई स्थान हैं जहां कोड आसानी से गिर सकता है।
लिखना जरूरी है || कोड.
आवश्यक दस्तावेज़, कोड उदाहरण और/या समुदाय गायब हैं।

इस कार्य के लिए अनुमानित समय Reddit से डेटा एकत्र करने की तुलना में 3-5 गुना अधिक होगा।

Odnoklassniki समूहों की तुलना

आइए वर्णित सबसे तकनीकी रूप से दिलचस्प मामले पर चलते हैं। मेरे लिए, यह बिल्कुल दिलचस्प था क्योंकि पहली नज़र में, यह काफी मामूली लगता है, लेकिन यह बिल्कुल भी वैसा नहीं होता - जैसे ही आप इस पर छड़ी मारते हैं।

आइए अपनी कठिनाई चेकलिस्ट से शुरुआत करें और ध्यान दें कि उनमें से कई पहले की तुलना में कहीं अधिक कठिन साबित होंगी:

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

2) हालाँकि, सेलेनियम के साथ सही और दोहराए जाने वाले काम की कोई गारंटी नहीं है (कम से कम ok.ru के मामले में तो निश्चित रूप से)।

3) Ok.ru वेबसाइट में जावास्क्रिप्ट त्रुटियां हैं और कभी-कभी अजीब और असंगत व्यवहार करती है।

4) आपको पृष्ठांकन, तत्वों को लोड करना आदि करना होगा...

5) रैपर द्वारा दी गई एपीआई त्रुटियों को अजीब तरीके से संभालना होगा, उदाहरण के लिए, इस तरह (प्रयोगात्मक कोड का एक टुकड़ा):
```
def get_comments(args, context, discussions):
    pause = 1
    if args.extract_comments:
        all_comments = set()
#makes sense to keep track of already processed discussions
        for discussion in tqdm(discussions): 
            try:
                comments = get_comments_from_discussion_via_api(context, discussion)
            except odnoklassniki.api.OdnoklassnikiError as e:
                if "NOT_FOUND" in str(e):
                    comments = set()
                else:
                    print(e)
                    bp()
                    pass
            all_comments |= comments
            time.sleep(pause)
        return all_comments
```
मेरी पसंदीदा गलती थी:

OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: …)”)

6) अंततः, सेलेनियम + एपीआई सबसे तर्कसंगत विकल्प लगता है।
स्थिति को सहेजना और सिस्टम को पुनरारंभ करना, साइट के असंगत व्यवहार सहित कई त्रुटियों को संभालना आवश्यक है - और इन त्रुटियों की कल्पना करना काफी कठिन है (जब तक कि आप पेशेवर रूप से पार्सर नहीं लिखते हैं)।

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

निष्कर्ष

इससे कोई फर्क नहीं पड़ता कि आपको एक विशाल डेटा प्रोसेसिंग पाइपलाइन मॉड्यूल की "मौके पर" समय सीमा का अनुमान लगाने की कितनी आवश्यकता है (हम आज योजना बना रहे हैं!), कार्य मापदंडों का विश्लेषण किए बिना निष्पादन समय का गुणात्मक रूप से अनुमान लगाना लगभग कभी भी संभव नहीं है।

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

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

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

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

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

स्रोत: www.habr.com

डेटा साइंस में क्या गलत हो सकता है? डेटा संग्रहण

सिद्धांत में सशर्त दृष्टिकोण

रेडिट समुदायों की तुलना

हेबर अनुभागों की तुलना

Odnoklassniki समूहों की तुलना

निष्कर्ष

एक टिप्पणी जोड़ें उत्तर रद्द