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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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% और बचा सकते हैं।
कुछ डेटा की भौतिक पहुंच से परे होना (वे प्रशासकों को दिखाई देते हैं या उन्हें एकत्रित करना बहुत कठिन होता है) - इसे ध्यान में रखा जाना चाहिए; सभी डेटा को उचित समय में एकत्रित नहीं किया जा सकता है।
नेटवर्किंग त्रुटियाँ: नेटवर्किंग एक कष्टकारी कार्य है।
यह वास्तविक, सजीव डेटा है - यह कभी भी साफ़ नहीं होता।

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

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

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

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

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

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

जटिलता के अनुसार कुल चेकलिस्ट:

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

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

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

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

आइये अपनी कठिनाई सूची से शुरुआत करें, और ध्यान दें कि उनमें से कई, जितनी वे शुरू में दिखाई देती हैं, उससे कहीं अधिक कठिन होंगी:

इसमें API तो है, लेकिन इसमें आवश्यक कार्यों का लगभग पूर्ण अभाव है।
कुछ कार्यों के लिए ईमेल द्वारा पहुंच की आवश्यकता होती है, अर्थात तुरंत पहुंच प्रदान नहीं की जाती।
यह बहुत ही खराब तरीके से प्रलेखित है (आइए इस तथ्य से शुरू करें कि रूसी और अंग्रेजी शब्द हर जगह मिश्रित हैं, और पूरी तरह से असंगत रूप से - कभी-कभी आपको बस यह अनुमान लगाने की आवश्यकता होती है कि आपसे कहीं क्या चाहिए) और, इसके अलावा, यह डेटा प्राप्त करने के लिए डिज़ाइन द्वारा उपयुक्त नहीं है, उदाहरण के लिए, वह कार्य जिसकी हमें आवश्यकता है.
दस्तावेज़ में एक सत्र की आवश्यकता होती है, लेकिन वास्तव में इसका उपयोग नहीं होता है - और API मोड की सभी पेचीदगियों को समझने का कोई तरीका नहीं है, सिवाय इसके कि इधर-उधर टटोलते रहें और आशा करें कि कुछ काम करेगा।
कोई उदाहरण और समुदाय नहीं हैं, जानकारी एकत्र करने में सहायता का एकमात्र बिंदु एक छोटा सा है आवरण पायथन में (बहुत अधिक उपयोग उदाहरणों के बिना)।
सेलेनियम सबसे अधिक कुशल विकल्प प्रतीत होता है, क्योंकि अधिकांश आवश्यक डेटा लॉक होते हैं।
1) अर्थात्, प्राधिकरण एक काल्पनिक उपयोगकर्ता (और मैनुअल पंजीकरण) के माध्यम से किया जाता है।
2) हालाँकि, सेलेनियम के साथ सही और दोहराए जाने योग्य संचालन की कोई गारंटी नहीं है (कम से कम ok.ru के मामले में तो निश्चित रूप से)।
3) Ok.ru वेबसाइट में जावास्क्रिप्ट त्रुटियां हैं और कभी-कभी यह अजीब और असंगत तरीके से व्यवहार करती है।
4) आपको पृष्ठांकन, तत्वों को लोड करना आदि से निपटना होगा।
5) रैपर द्वारा लौटाई गई API त्रुटियों को हैकी तरीके से संभालना होगा, उदाहरण के लिए, इस तरह (प्रायोगिक कोड का एक अंश):
```
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) अंततः, सेलेनियम + एपीआई विकल्प सबसे तर्कसंगत विकल्प लगता है।
स्थिति को सहेजना और सिस्टम को पुनः आरंभ करना, साइट के असंगत व्यवहार सहित बहुत सारी त्रुटियों को संभालना आवश्यक है - और इन त्रुटियों की कल्पना करना काफी कठिन है (जब तक कि आप एक पेशेवर पार्सर लेखक न हों, बेशक)।

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

निष्कर्ष

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

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

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

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

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

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

स्रोत: www.habr.com