डाटा विज्ञान संग के गलत हुन सक्छ? तथ्यांक संकलन

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

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

र वास्तविक डेटाको साथ काम गर्न थालेपछि मानिसहरूले ठक्कर खाएको पहिलो कुरा वास्तवमा यो डेटा सङ्कलन गर्नु हो जुन हाम्रो लागि सबैभन्दा सान्दर्भिक छ। यस लेखको मुख्य सन्देश:

हामी व्यवस्थित रूपमा डेटा सङ्कलन, सफा र तयार गर्न आवश्यक समय, स्रोत र प्रयासलाई कम आँकलन गर्छौं।

र सबैभन्दा महत्त्वपूर्ण कुरा, हामी यसलाई रोक्न के गर्ने भनेर छलफल गर्नेछौं।

विभिन्न अनुमानका अनुसार, सफाई, रूपान्तरण, डाटा प्रोसेसिङ, फीचर इन्जिनियरिङ, आदिमा ८०-९०% समय लाग्छ, र विश्लेषण १०-२०% हुन्छ, जबकि प्रायः सबै शैक्षिक सामग्री विश्लेषणमा मात्र केन्द्रित हुन्छन्।

एउटा साधारण उदाहरणको रूपमा तीनवटा संस्करणहरूमा एउटा साधारण विश्लेषणात्मक समस्यालाई हेरौं र हेरौं कि "उत्तेजक परिस्थितिहरू" के हुन्।

र उदाहरणको रूपमा, फेरि, हामी डेटा सङ्कलन र समुदायहरू तुलना गर्ने कार्यको समान भिन्नताहरू विचार गर्नेछौं:

1. दुई Reddit subreddits
2. Habr को दुई खण्ड
3. Odnoklassniki को दुई समूह

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

साइट खोल्नुहोस् र उदाहरणहरू पढ्नुहोस्, यदि यो स्पष्ट छ भने, पढ्नको लागि केही घण्टा, उदाहरणहरू र डिबगिङ प्रयोग गरेर कोडको लागि केही घण्टाहरू छुटाउनुहोस्। सङ्कलनका लागि केही घण्टा थप्नुहोस्। रिजर्भमा केही घण्टामा फ्याँक्नुहोस् (दुईले गुणा गर्नुहोस् र N घण्टा थप्नुहोस्)।

मुख्य बिन्दु: समय अनुमानहरू अनुमान र अनुमानमा आधारित हुन्छन् कि यसले कति समय लिन्छ।

माथि वर्णन गरिएको सशर्त समस्याको लागि निम्न प्यारामिटरहरू अनुमान गरेर समय विश्लेषण सुरु गर्न आवश्यक छ:

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

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

र अब हामी विशिष्ट उदाहरणहरू प्रदर्शन गर्नेछौं जहाँ त्यस्ता प्यारामिटरहरू परिवर्तन हुनेछन्।

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

कार्यात्मक तत्वहरू पर्याप्त मात्रामा सानो हुँदा अनुमान-आधारित अनुमान राम्रो दृष्टिकोण हो र समस्याको डिजाइनलाई महत्त्वपूर्ण रूपमा प्रभाव पार्न सक्ने धेरै कारकहरू छैनन्। तर डेटा विज्ञान समस्याहरूको संख्यामा, त्यस्ता कारकहरू धेरै धेरै हुन्छन् र यस्तो दृष्टिकोण अपर्याप्त हुन्छ।

Reddit समुदायहरूको तुलना

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

• त्यहाँ एक सफा, स्पष्ट र दस्तावेज API छ।
• यो अत्यन्त सरल छ र सबैभन्दा महत्त्वपूर्ण कुरा, टोकन स्वचालित रूपमा प्राप्त हुन्छ।
• छन् पाइथन र्यापर - धेरै उदाहरणहरु संग।
• एउटा समुदाय जसले reddit मा डेटा विश्लेषण र सङ्कलन गर्दछ (जस्तै पाइथन र्यापर कसरी प्रयोग गर्ने भनेर YouTube भिडियोहरूमा पनि) उदाहरणका लागि.
• हामीलाई आवश्यक पर्ने विधिहरू प्रायः 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()

बाट लिइएको हो यो र्‍यापिङको लागि सुविधाजनक उपयोगिताहरूको चयन।

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

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

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

Habr खण्डहरूको तुलना

थ्रेडहरू र/वा Habr को खण्डहरू तुलना गर्ने थप रोचक र गैर-तुच्छ मामलामा जाऔं।

हाम्रो जटिलता चेकलिस्ट जाँच गरौं - यहाँ, प्रत्येक बिन्दु बुझ्नको लागि, तपाईंले कार्य आफैंमा थोरै खन्नुपर्छ र प्रयोग गर्नुपर्नेछ।

• सुरुमा तपाईले सोच्नुहुन्छ कि त्यहाँ एपीआई छ, तर त्यहाँ छैन। हो, हो, Habr सँग एपीआई छ, तर यो प्रयोगकर्ताहरूको लागि पहुँचयोग्य छैन (वा हुनसक्छ यसले काम गर्दैन)।
• त्यसपछि तपाइँ भर्खर html पार्स गर्न सुरु गर्नुहुन्छ - "आयात अनुरोधहरू", के गलत हुन सक्छ?
• जे भए पनि कसरी पार्स गर्ने? सबैभन्दा सरल र प्रायः प्रयोग गरिने दृष्टिकोण भनेको IDs मा दोहोर्याउनु हो, ध्यान दिनुहोस् कि यो सबैभन्दा प्रभावकारी छैन र विभिन्न केसहरू ह्यान्डल गर्नुपर्नेछ - यहाँ सबै अवस्थितहरू बीच वास्तविक ID हरूको घनत्वको उदाहरण हो।

  
  बाट लिइएको हो यो लेख

• वेबको शीर्षमा HTML मा बेरिएको कच्चा डाटा पीडा हो। उदाहरणका लागि, तपाईं लेखको मूल्याङ्कन सङ्कलन र बचत गर्न चाहनुहुन्छ: तपाईंले html बाट अङ्क फाड्नु भयो र थप प्रक्रियाका लागि सङ्ख्याको रूपमा बचत गर्ने निर्णय गर्नुभयो: 

  1) int(स्कोर) ले त्रुटि फ्याँक्छ: Habré मा एक माइनस छ, जस्तै, उदाहरणका लागि, रेखा "–5" मा - यो एक en ड्यास हो, माइनस चिन्ह होइन (अप्रत्याशित रूपमा, सही?), त्यसैले केहि बिन्दुमा मैले पार्सरलाई यस्तो भयानक फिक्सको साथ जीवनमा उठाउनुपर्ने थियो।

  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+ घण्टा लाग्नेछ (यो विशुद्ध रूपमा पहिले नै काम गर्ने एकल-थ्रेडेड पार्सरको कार्यान्वयन समय हो, जुन सुत्छ र कुनै प्रतिबन्ध अन्तर्गत पर्दैन)। IN यो लेख, यसले केहि बिन्दुमा समान योजनाको नेतृत्व गर्‍यो:

जटिलता द्वारा कुल चेकलिस्ट:

• नेटवर्कसँग काम गर्दै र आईडीद्वारा पुनरावृत्ति र खोजीसँग html पार्सिङ।
• विषम संरचनाको कागजात।
• त्यहाँ धेरै ठाउँहरू छन् जहाँ कोड सजिलै खस्न सक्छ।
• लेख्न जरुरी छ || कोड।
• आवश्यक कागजात, कोड उदाहरणहरू, र/वा समुदाय हराइरहेको छ।

यो कार्यको लागि अनुमानित समय Reddit बाट डाटा सङ्कलन गर्नको लागि 3-5 गुणा बढी हुनेछ।

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

वर्णन गरिएको सबैभन्दा प्राविधिक रूपमा रोचक मामलामा जाऔं। मेरो लागि, यो एकदम चाखलाग्दो थियो किनभने पहिलो नजरमा, यो एकदम मामूली देखिन्छ, तर यो त्यस्तो तरिकामा परिणत हुँदैन - जसरी तपाईंले यसलाई एक लट्ठी प्रहार गर्नुहुन्छ।

हाम्रो कठिनाई चेकलिस्टको साथ सुरू गरौं र ध्यान दिनुहोस् कि तिनीहरूमध्ये धेरै पहिले हेर्दा भन्दा धेरै गाह्रो हुनेछन्:

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

  2) यद्यपि, सेलेनियमको साथ सही र दोहोर्याउन मिल्ने कामको लागि कुनै ग्यारेन्टीहरू छैनन् (कम्तिमा निश्चित रूपमा ok.ru को मामलामा)।

  3) Ok.ru वेबसाइटमा JavaScript त्रुटिहरू छन् र कहिलेकाहीँ अनौठो र असंगत रूपमा व्यवहार गर्दछ।

  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) अन्ततः, सेलेनियम + एपीआई सबैभन्दा तर्कसंगत विकल्प जस्तो देखिन्छ।

• यो राज्य बचत गर्न र प्रणाली पुन: सुरु गर्न आवश्यक छ, साइटको असंगत व्यवहार सहित धेरै त्रुटिहरू ह्यान्डल गर्नुहोस् - र यी त्रुटिहरू कल्पना गर्न धेरै गाह्रो छ (जबसम्म तपाइँ व्यावसायिक रूपमा पार्सरहरू लेख्नुहुन्न)।

यस कार्यको लागि सशर्त समय अनुमान Habr बाट डाटा सङ्कलन गर्नको लागि 3-5 गुणा बढी हुनेछ। तथ्यको बावजुद Habr को मामला मा हामी एचटीएमएल पार्सिङ संग एक फ्रन्टल दृष्टिकोण को उपयोग गर्दछ, र ओके को मामला मा हामी महत्वपूर्ण स्थानहरुमा API संग काम गर्न सक्छौं।

निष्कर्ष

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

अलि बढी दार्शनिक नोटमा, फुर्तिलो अनुमान गर्ने रणनीतिहरूले इन्जिनियरिङ कार्यहरूको लागि राम्रोसँग काम गर्दछ, तर समस्याहरू जुन अधिक प्रयोगात्मक छन् र, एक अर्थमा, "रचनात्मक" र अन्वेषणात्मक, अर्थात्, कम अनुमान गर्न सकिने, कठिनाइहरू छन्, जस्तै समान विषयहरूको उदाहरणहरूमा, जसको हामीले यहाँ चर्चा गरेका छौं ।

निस्सन्देह, डेटा सङ्कलन केवल एक प्रमुख उदाहरण हो - यो सामान्यतया एक अविश्वसनीय सरल र प्राविधिक रूपमा जटिल कार्य हो, र शैतान प्राय: विवरणहरूमा हुन्छ। र यो ठ्याक्कै यस कार्यमा छ कि हामीले के गलत हुन सक्छ र कामले कति समय लिन सक्छ भन्ने सम्भावित विकल्पहरूको सम्पूर्ण दायरा देखाउन सक्छौं।

यदि तपाइँ अतिरिक्त प्रयोगहरू बिना कार्यको विशेषताहरूमा नजर राख्नुहुन्छ भने, Reddit र OK समान देखिन्छ: त्यहाँ एपीआई छ, एक पाइथन र्यापर, तर सारमा, भिन्नता ठूलो छ। यी प्यारामिटरहरू द्वारा न्याय गर्दै, Habr को पार्स ठीक भन्दा बढी जटिल देखिन्छ - तर व्यवहारमा यो एकदम विपरीत छ, र यो समस्याको मापदण्डहरू विश्लेषण गर्न साधारण प्रयोगहरू सञ्चालन गरेर पत्ता लगाउन सकिन्छ।

मेरो अनुभवमा, सबैभन्दा प्रभावकारी दृष्टिकोण भनेको तपाईंले प्रारम्भिक विश्लेषण आफैं र साधारण पहिलो प्रयोगहरूका लागि आवश्यक पर्ने समयको अनुमान लगाउनु हो, कागजातहरू पढेर - यसले तपाईंलाई सम्पूर्ण कामको लागि सही अनुमान दिन अनुमति दिनेछ। लोकप्रिय फुर्तिलो पद्धतिको सन्दर्भमा, म तपाईंलाई "अनुमानित कार्य प्यारामिटरहरू" को लागी टिकट सिर्जना गर्न सोध्छु, जसको आधारमा म "स्प्रिन्ट" भित्र के गर्न सकिन्छ भन्ने मूल्याङ्कन दिन सक्छु र प्रत्येकको लागि थप सटीक अनुमान दिन सक्छु। कार्य।

तसर्थ, सबैभन्दा प्रभावकारी तर्क यस्तो देखिन्छ जसले "गैर-प्राविधिक" विशेषज्ञलाई देखाउँदछ कि कति समय र स्रोतहरू मूल्याङ्कन गर्न बाँकी रहेका मापदण्डहरूमा निर्भर गर्दछ।

स्रोत: www.habr.com