डेटा सायन्समध्ये काय चूक होऊ शकते? माहिती मिळवणे

आज 100500 डेटा सायन्स अभ्यासक्रम आहेत आणि हे फार पूर्वीपासून माहीत आहे की डेटा सायन्समध्ये सर्वाधिक पैसा डेटा सायन्स कोर्सद्वारे कमावता येतो (जेव्हा तुम्ही फावडे विकू शकता तेव्हा खोदून का काढता?). या अभ्यासक्रमांचा मुख्य तोटा असा आहे की त्यांचा वास्तविक कामाशी काहीही संबंध नाही: कोणीही तुम्हाला आवश्यक स्वरूपात स्वच्छ, प्रक्रिया केलेला डेटा देणार नाही. आणि जेव्हा तुम्ही कोर्स सोडता आणि वास्तविक समस्या सोडवण्यास सुरुवात करता तेव्हा अनेक बारकावे समोर येतात.

म्हणून, मी, माझे सहकारी आणि सहकारी यांच्यासोबत घडलेल्या वास्तविक घटनांवर आधारित “डेटा सायन्समध्ये काय चूक होऊ शकते” या नोट्सची मालिका आम्ही सुरू करत आहोत. आम्ही वास्तविक उदाहरणे वापरून विशिष्ट डेटा विज्ञान कार्यांचे विश्लेषण करू: हे प्रत्यक्षात कसे घडते. आज डेटा संकलनाच्या कामापासून सुरुवात करूया.

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

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

आणि सर्वात महत्त्वाचे म्हणजे हे टाळण्यासाठी काय करावे यावर चर्चा करू.

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

तीन आवृत्त्यांमधील एक साधी विश्लेषणात्मक समस्या एक नमुनेदार उदाहरण म्हणून पाहू आणि "उग्र परिस्थिती" काय आहेत ते पाहू.

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

1. दोन Reddit subreddits
2. Habr दोन विभाग
3. ओड्नोक्लास्निकीचे दोन गट

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

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

महत्त्वाचा मुद्दा: वेळेचा अंदाज गृहीतकांवर आणि किती वेळ लागेल याच्या अंदाजावर आधारित असतो.

वर वर्णन केलेल्या सशर्त समस्येसाठी खालील पॅरामीटर्सचा अंदाज घेऊन वेळेचे विश्लेषण सुरू करणे आवश्यक आहे:

• डेटाचा आकार किती आहे आणि तो किती भौतिकरित्या गोळा करणे आवश्यक आहे (*खाली पहा*).
• एका रेकॉर्डसाठी किती वेळ आहे आणि दुसरा रेकॉर्ड करण्यासाठी तुम्हाला किती वेळ प्रतीक्षा करावी लागेल?
• कोड लिहिण्याचा विचार करा जो राज्य वाचवतो आणि सर्वकाही अयशस्वी झाल्यावर रीस्टार्ट करतो.
• आम्हाला अधिकृततेची आवश्यकता आहे का ते शोधा आणि 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% खर्च वाचवू शकता.
• काही डेटाची भौतिक दुर्गमता (ते प्रशासकांना दृश्यमान आहेत किंवा गोळा करणे खूप कठीण आहे) - हे लक्षात घेतले पाहिजे; तत्त्वतः, सर्व डेटा पुरेशा वेळेत गोळा केला जाऊ शकत नाही.
• नेटवर्क त्रुटी: नेटवर्किंग एक वेदना आहे.
• हा जिवंत वास्तविक डेटा आहे - तो कधीही शुद्ध नसतो.

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

Habr विभागांची तुलना

थ्रेड्स आणि/किंवा Habr च्या विभागांची तुलना करण्याच्या अधिक मनोरंजक आणि क्षुल्लक प्रकरणाकडे वळूया.

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

• प्रथम तुम्हाला असे वाटते की एपीआय आहे, परंतु तेथे नाही. होय, होय, Habr कडे API आहे, परंतु ते वापरकर्त्यांसाठी प्रवेशयोग्य नाही (किंवा कदाचित ते अजिबात कार्य करत नाही).
• मग तुम्ही फक्त html पार्सिंग सुरू करा - "इम्पोर्ट विनंत्या", काय चूक होऊ शकते?
• तरीही पार्स कसे करायचे? सर्वात सोपा आणि वारंवार वापरला जाणारा दृष्टीकोन म्हणजे आयडी वर पुनरावृत्ती करणे, लक्षात घ्या की ते सर्वात कार्यक्षम नाही आणि विविध प्रकरणे हाताळावी लागतील - येथे सर्व अस्तित्वात असलेल्या वास्तविक आयडींच्या घनतेचे उदाहरण आहे.

  
  कडून घेतले हे लेख.

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

  1) int(स्कोअर) एक त्रुटी फेकते: 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
  

  कोणतीही तारीख, प्लस आणि वजा अजिबात असू शकत नाही (जसे आपण वर चेक_डेट फंक्शनमध्ये पाहतो, हे घडले).

  २) अनस्केप केलेले स्पेशल कॅरेक्टर - ते येतील, तुम्हाला तयार राहण्याची गरज आहे.

  3) पोस्टच्या प्रकारानुसार रचना बदलते.

  4) जुन्या पोस्टमध्ये **विचित्र रचना** असू शकते.

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

जटिलतेनुसार एकूण चेकलिस्ट:

• नेटवर्कसह कार्य करणे आणि पुनरावृत्तीसह html पार्स करणे आणि ID द्वारे शोधा.
• विषम संरचनेचे दस्तऐवज.
• अशी अनेक ठिकाणे आहेत जिथे कोड सहज पडू शकतो.
• लिहिणे आवश्यक आहे || कोड
• आवश्यक कागदपत्रे, कोड उदाहरणे आणि/किंवा समुदाय गहाळ आहेत.

Reddit वरून डेटा गोळा करण्यापेक्षा या कार्यासाठी अंदाजे वेळ 3-5 पट जास्त असेल.

ओड्नोक्लास्निकी गटांची तुलना

चला वर्णन केलेल्या सर्वात तांत्रिकदृष्ट्या मनोरंजक प्रकरणाकडे जाऊया. माझ्यासाठी, हे तंतोतंत मनोरंजक होते कारण पहिल्या दृष्टीक्षेपात, ते अगदी क्षुल्लक दिसते, परंतु ते तसे अजिबात होत नाही - जसे आपण त्यावर काठी मारली.

चला आमच्या अडचण चेकलिस्टसह प्रारंभ करूया आणि लक्षात घ्या की त्यापैकी बरेच ते प्रथम पाहतात त्यापेक्षा जास्त कठीण असतील:

• एक API आहे, परंतु त्यात आवश्यक कार्ये जवळजवळ पूर्णपणे नसतात.
• काही फंक्शन्ससाठी तुम्हाला मेलद्वारे प्रवेशाची विनंती करणे आवश्यक आहे, म्हणजेच प्रवेश मंजूर करणे तात्काळ नाही.
• हे भयंकरपणे दस्तऐवजीकरण केलेले आहे (सुरुवातीसाठी, रशियन आणि इंग्रजी संज्ञा सर्वत्र मिसळल्या आहेत आणि पूर्णपणे विसंगत आहेत - कधीकधी आपल्याला त्यांना आपल्याकडून काय हवे आहे याचा अंदाज लावण्याची आवश्यकता असते) आणि शिवाय, डिझाइन डेटा मिळविण्यासाठी योग्य नाही, उदाहरणार्थ. , आम्हाला आवश्यक असलेले कार्य.
• दस्तऐवजात सत्र आवश्यक आहे, परंतु प्रत्यक्षात ते वापरत नाही - आणि एपीआय मोडच्या सर्व गुंतागुंत समजून घेण्याचा कोणताही मार्ग नाही इकडे तिकडे लक्ष देणे आणि काहीतरी कार्य करेल अशी आशा करणे.
• कोणतीही उदाहरणे नाहीत आणि कोणताही समुदाय नाही; माहिती गोळा करण्यासाठी समर्थनाचा एकमेव मुद्दा लहान आहे आवरण Python मध्ये (वापराच्या अनेक उदाहरणांशिवाय).
• सेलेनियम हा सर्वात कार्यक्षम पर्याय असल्याचे दिसते, कारण बरेच आवश्यक डेटा लॉक केलेले आहेत.
  1) म्हणजे, अधिकृतता काल्पनिक वापरकर्त्याद्वारे (आणि हाताने नोंदणी) होते.

  2) तथापि, सेलेनियमसह योग्य आणि पुनरावृत्ती करण्यायोग्य कामाची कोणतीही हमी नाही (किमान ok.ru च्या बाबतीत निश्चितपणे).

  3) Ok.ru वेबसाइटमध्ये JavaScript त्रुटी आहेत आणि कधीकधी विचित्र आणि विसंगतपणे वागतात.

  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) शेवटी, सेलेनियम + API सर्वात तर्कसंगत पर्यायासारखे दिसते.

• स्थिती जतन करणे आणि सिस्टम रीस्टार्ट करणे आवश्यक आहे, साइटच्या विसंगत वर्तनासह बर्‍याच त्रुटी हाताळणे आवश्यक आहे - आणि या त्रुटींची कल्पना करणे खूप कठीण आहे (जोपर्यंत तुम्ही व्यावसायिकपणे पार्सर लिहित नाही तोपर्यंत).

या कार्यासाठी सशर्त वेळेचा अंदाज Habr कडून डेटा गोळा करण्यापेक्षा 3-5 पट जास्त असेल. Habr च्या बाबतीत आम्ही HTML पार्सिंगसह समोरचा दृष्टीकोन वापरतो आणि ओकेच्या बाबतीत आम्ही गंभीर ठिकाणी API सह कार्य करू शकतो हे तथ्य असूनही.

निष्कर्ष

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

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

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

आपण अतिरिक्त प्रयोगांशिवाय कार्याच्या वैशिष्ट्यांकडे लक्ष दिल्यास, Reddit आणि OK सारखे दिसतात: एक API, एक पायथन रॅपर आहे, परंतु थोडक्यात, फरक खूप मोठा आहे. या पॅरामीटर्सचा आधार घेत, हॅब्रचे पार्स ओकेपेक्षा अधिक क्लिष्ट दिसतात - परंतु व्यवहारात ते अगदी उलट आहे आणि समस्येच्या पॅरामीटर्सचे विश्लेषण करण्यासाठी साधे प्रयोग करून हेच ​​शोधले जाऊ शकते.

माझ्या अनुभवानुसार, सर्वात प्रभावी दृष्टीकोन म्हणजे तुम्हाला प्राथमिक विश्लेषणासाठी लागणाऱ्या वेळेचा अंदाज लावणे आणि साधे पहिले प्रयोग, कागदपत्रे वाचणे - हे तुम्हाला संपूर्ण कामाचा अचूक अंदाज देण्यास अनुमती देईल. लोकप्रिय चपळ पद्धतीच्या संदर्भात, मी तुम्हाला “अंदाज टास्क पॅरामीटर्स” साठी एक तिकीट तयार करण्यास सांगतो, ज्याच्या आधारावर मी “स्प्रिंट” मध्ये काय साध्य केले जाऊ शकते याचे मूल्यांकन देऊ शकतो आणि प्रत्येकासाठी अधिक अचूक अंदाज देऊ शकतो. कार्य

म्हणून, सर्वात प्रभावी युक्तिवाद असा दिसतो जो "गैर-तांत्रिक" तज्ञांना दर्शवेल की अद्याप मूल्यांकन करणे बाकी असलेल्या पॅरामीटर्सवर अवलंबून किती वेळ आणि संसाधने बदलतील.

स्त्रोत: www.habr.com