Ի՞նչը կարող է սխալ լինել Data Science-ի հետ: Տվյալների հավաքագրումը

Այսօր կան 100500 Data Science դասընթացներ, և վաղուց հայտնի է, որ Data Science-ում ամենաշատ գումարը կարելի է վաստակել Data Science դասընթացների միջոցով (ինչու՞ փորել, երբ կարող ես թիակներ վաճառել): Այս դասընթացների հիմնական թերությունն այն է, որ դրանք իրական աշխատանքի հետ կապ չունեն. ոչ ոք ձեզ չի տա մաքուր, մշակված տվյալներ պահանջվող ձևաչափով: Իսկ երբ դու թողնում ես դասընթացն ու սկսում իրական խնդիր լուծել, ի հայտ են գալիս բազմաթիվ նրբերանգներ։

Հետևաբար, մենք սկսում ենք մի շարք գրառումներ «Ինչը կարող է սխալ լինել Data Science-ի հետ», հիմնված իրական իրադարձությունների վրա, որոնք տեղի են ունեցել ինձ, իմ ընկերների և գործընկերների հետ: Մենք կվերլուծենք Տվյալների գիտության բնորոշ առաջադրանքները՝ օգտագործելով իրական օրինակներ. ինչպես է դա իրականում տեղի ունենում: Այսօր սկսենք տվյալների հավաքագրման առաջադրանքից:

Եվ առաջին բանը, որի վրա մարդիկ սայթաքում են, երբ սկսում են աշխատել իրական տվյալների հետ, իրականում հավաքելն է այս տվյալները, որոնք առավել համապատասխան են մեզ: Այս հոդվածի հիմնական ուղերձը.

Մենք համակարգված կերպով թերագնահատում ենք տվյալները հավաքելու, մաքրելու և պատրաստելու համար անհրաժեշտ ժամանակը, ռեսուրսները և ջանքերը:

Եվ ամենակարեւորը, մենք կքննարկենք, թե ինչ անել դա կանխելու համար:

Ըստ տարբեր գնահատականների՝ մաքրումը, փոխակերպումը, տվյալների մշակումը, առանձնահատկությունների ճարտարագիտությունը և այլն պահանջում են ժամանակի 80-90%-ը, իսկ վերլուծությունը՝ 10-20%-ը, մինչդեռ գրեթե ողջ ուսումնական նյութը կենտրոնացած է բացառապես վերլուծության վրա:

Որպես տիպիկ օրինակ դիտարկենք պարզ վերլուծական խնդիրը երեք տարբերակով և տեսնենք, թե որոնք են «ծանրացնող հանգամանքները»։

Եվ որպես օրինակ, կրկին մենք կդիտարկենք տվյալների հավաքագրման և համայնքները համեմատելու առաջադրանքի նմանատիպ տատանումները հետևյալի համար.

1. Reddit-ի երկու ենթագրանց
2. Հաբրի երկու բաժին
3. Odnoklassniki-ի երկու խումբ

Պայմանական մոտեցում տեսականորեն

Բացեք կայքը և կարդացեք օրինակները, եթե պարզ է, մի քանի ժամ հատկացրեք կարդալու համար, մի քանի ժամ կոդի համար՝ օգտագործելով օրինակները և վրիպազերծելը: Ավելացրեք մի քանի ժամ հավաքման համար: Նետում մի քանի ժամ ռեզերվ (բազմապատկեք երկուսով և ավելացրեք N ժամ):

Հիմնական կետ. Ժամանակի գնահատումները հիմնված են ենթադրությունների և ենթադրությունների վրա, թե որքան ժամանակ կպահանջվի:

Անհրաժեշտ է սկսել ժամանակի վերլուծությունը՝ գնահատելով վերը նկարագրված պայմանական խնդրի հետևյալ պարամետրերը.

• Ո՞րն է տվյալների չափը և դրանցից որքան է անհրաժեշտ ֆիզիկապես հավաքելու համար (*տես ստորև*):
• Որքա՞ն է մեկ ձայնագրության հավաքման ժամանակը և որքա՞ն ժամանակ պետք է սպասեք, մինչև կարողանաք հավաքել երկրորդը:
• Մտածեք գրել կոդ, որը կփրկի վիճակը և կսկսի վերագործարկումը, երբ (ոչ եթե) ամեն ինչ ձախողվի:
• Պարզեք, թե արդյոք մեզ թույլտվություն է պետք և սահմանեք API-ի միջոցով մուտք ստանալու ժամանակը:
• Սահմանեք սխալների քանակը որպես տվյալների բարդության ֆունկցիա - գնահատեք կոնկրետ առաջադրանքի համար՝ կառուցվածք, քանի փոխակերպում, ինչ և ինչպես պետք է հանել:
• Ուղղել ցանցի սխալներն ու խնդիրները ոչ ստանդարտ նախագծի վարքագծի հետ:
• Գնահատեք, թե արդյոք պահանջվող գործառույթները առկա են փաստաթղթերում, և եթե ոչ, ապա ինչպես և որքան է անհրաժեշտ լուծման համար:

Ամենակարևորն այն է, որ ժամանակը գնահատելու համար, իրականում անհրաժեշտ է ժամանակ և ջանք ծախսել «գործող հետախուզության» վրա, միայն այդ դեպքում ձեր պլանավորումը համարժեք կլինի: Հետևաբար, որքան էլ ձեզ մղեն ասելու «որքա՞ն ժամանակ է պահանջվում տվյալների հավաքագրման համար», ինքներդ ձեզ որոշ ժամանակ գնեք նախնական վերլուծության համար և վիճեք, թե որքանով է ժամանակը տարբերվելու՝ կախված խնդրի իրական պարամետրերից:

Եվ հիմա մենք ցույց կտանք կոնկրետ օրինակներ, որտեղ նման պարամետրերը կփոխվեն:

Հիմնական կետ. Գնահատումը հիմնված է աշխատանքի ծավալի և բարդության վրա ազդող հիմնական գործոնների վերլուծության վրա:

Գուշակության վրա հիմնված գնահատումը լավ մոտեցում է, երբ ֆունկցիոնալ տարրերը բավականաչափ փոքր են, և չկան շատ գործոններ, որոնք կարող են էապես ազդել խնդրի ձևավորման վրա: Բայց տվյալների գիտության մի շարք խնդիրների դեպքում նման գործոնները չափազանց շատ են դառնում, և նման մոտեցումը դառնում է ոչ ադեկվատ։

Reddit համայնքների համեմատություն

Սկսենք ամենապարզ դեպքից (ինչպես պարզվում է հետագայում): Ընդհանուր առմամբ, լիովին անկեղծ լինելու համար, մենք ունենք գրեթե իդեալական դեպք, եկեք ստուգենք մեր բարդության ստուգաթերթը.

• Կա կոկիկ, հստակ և փաստագրված API:
• Դա չափազանց պարզ է, և ամենակարևորը, նշանը ձեռք է բերվում ավտոմատ կերպով:
• Կա python փաթաթան - բազմաթիվ օրինակներով:
• Համայնք, որը վերլուծում և հավաքում է տվյալներ Reddit-ի վրա (նույնիսկ YouTube-ի տեսանյութերը, որոնք բացատրում են, թե ինչպես օգտագործել python wrapper-ը) Օրինակ.
• Մեզ անհրաժեշտ մեթոդները, ամենայն հավանականությամբ, գոյություն ունեն 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-ի սահմանները. մենք ստիպված ենք տվյալներ վերցնել խմբաքանակով (քուն հարցումների միջև և այլն):
• Հավաքման ժամանակը. ամբողջական վերլուծության և համեմատության համար դուք պետք է զգալի ժամանակ հատկացնեք միայն սարդին subreddit-ով քայլելու համար:
• Բոտը պետք է աշխատի սերվերի վրա. դուք չեք կարող այն գործարկել ձեր նոութբուքի վրա, դնել այն ձեր ուսապարկում և զբաղվել ձեր գործով: Այսպիսով, ես ամեն ինչ գործարկեցի VPS-ով: Օգտագործելով habrahabr10 գովազդային կոդը, կարող եք խնայել արժեքի ևս 10%-ը:
• Որոշ տվյալների ֆիզիկական անհասանելիությունը (դրանք տեսանելի են ադմինիստրատորների համար կամ չափազանց դժվար է հավաքել) - սա պետք է հաշվի առնել, սկզբունքորեն ոչ բոլոր տվյալները կարող են հավաքվել համապատասխան ժամանակում:
• Ցանցային սխալներ. Ցանցը ցավ է:
• Սա կենդանի իրական տվյալներ է. այն երբեք մաքուր չէ:

Իհարկե, մշակման մեջ անհրաժեշտ է ներառել այս նրբությունները։ Հատուկ ժամերը/օրերը կախված են զարգացման փորձից կամ նմանատիպ առաջադրանքների վրա աշխատելու փորձից, այնուամենայնիվ, մենք տեսնում ենք, որ այստեղ խնդիրը զուտ ինժեներական է և չի պահանջում մարմնի լրացուցիչ շարժումներ լուծելու համար. ամեն ինչ կարելի է շատ լավ գնահատել, պլանավորել և կատարել:

Հաբր հատվածների համեմատություն

Անցնենք Habr-ի թելերը և/կամ հատվածները համեմատելու ավելի հետաքրքիր և ոչ տրիվիալ դեպքին:

Եկեք ստուգենք մեր բարդության ստուգաթերթը. այստեղ, յուրաքանչյուր կետը հասկանալու համար, դուք պետք է մի փոքր խորանաք առաջադրանքի մեջ և փորձարկեք:

• Սկզբում կարծում եք, որ կա API, բայց չկա: Այո, այո, Habr-ն ունի API, բայց այն պարզապես հասանելի չէ օգտատերերի համար (կամ գուցե այն ընդհանրապես չի աշխատում):
• Այնուհետև դուք պարզապես սկսում եք վերլուծել html - «ներմուծման հարցումները», ի՞նչը կարող է սխալ լինել:
• Ինչպե՞ս, այնուամենայնիվ, վերլուծել: Ամենապարզ և ամենահաճախ օգտագործվող մոտեցումը ID-ների վրա կրկնելն է, նկատի ունեցեք, որ այն ամենաարդյունավետը չէ և պետք է լուծի տարբեր դեպքեր. ահա իրական ID-ների խտության օրինակ բոլոր գոյություն ունեցողների միջև:

  
  Վերցված ինչ - որ տեղից սա է հոդվածներ:

• Համացանցի վերևում HTML-ով փաթաթված չմշակված տվյալները ցավալի են: Օրինակ, դուք ցանկանում եք հավաքել և պահպանել հոդվածի վարկանիշը. դուք պոկել եք միավորը html-ից և որոշել եք այն պահել որպես թիվ հետագա մշակման համար. 

  1) int(score)-ը սխալ է թույլ տալիս. քանի որ 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-ի վերլուծությունը կրկնելով և որոնել ըստ ID-ի:
• Տարասեռ կառուցվածքի փաստաթղթեր.
• Կան բազմաթիվ վայրեր, որտեղ կոդը հեշտությամբ կարող է ընկնել:
• Անհրաժեշտ է գրել || կոդը։
• Անհրաժեշտ փաստաթղթերը, ծածկագրի օրինակները և/կամ համայնքը բացակայում են:

Այս առաջադրանքի համար նախատեսված ժամանակը 3-5 անգամ ավելի մեծ կլինի, քան Reddit-ից տվյալների հավաքագրման համար:

Odnoklassniki խմբերի համեմատություն

Անցնենք նկարագրված տեխնիկապես ամենահետաքրքիր դեպքին։ Ինձ համար դա հետաքրքիր էր հենց այն պատճառով, որ առաջին հայացքից այն բավականին չնչին է թվում, բայց ամենևին էլ այդպես չի ստացվում՝ հենց որ փայտ խփես դրա վրա:

Սկսենք մեր դժվարության ստուգաթերթից և նշենք, որ դրանցից շատերը շատ ավելի դժվար կլինեն, քան առաջին հայացքից են թվում.

• Կա API, բայց այն գրեթե ամբողջությամբ չունի անհրաժեշտ գործառույթները:
• Որոշ գործառույթների համար անհրաժեշտ է մուտքի թույլտվություն խնդրել փոստով, այսինքն՝ մուտքի թույլտվությունը ակնթարթային չէ:
• Դա ահավոր փաստագրված է (սկզբից, ռուսերեն և անգլերեն տերմինները խառնվում են ամենուր, և բոլորովին անհամապատասխան, երբեմն պարզապես պետք է գուշակել, թե ինչ են ուզում ձեզանից ինչ-որ տեղ) և, ավելին, դիզայնը հարմար չէ, օրինակ, տվյալներ ստանալու համար. , մեզ անհրաժեշտ գործառույթը.
• Պահանջում է սեսիա փաստաթղթերում, բայց իրականում չի օգտագործում այն, և այլ կերպ հասկանալու API ռեժիմների բոլոր բարդությունները, բացի շրջվելուց և հուսալից, որ ինչ-որ բան կաշխատի, այլ կերպ չկա:
• Չկան օրինակներ և համայնքներ, տեղեկատվության հավաքագրման միակ աջակցության կետը փոքրն է փաթաթան Python-ում (առանց օգտագործման բազմաթիվ օրինակների):
• Թվում է, թե սելենը ամենագործունակ տարբերակն է, քանի որ անհրաժեշտ տվյալներից շատերը արգելափակված են:
  1) Այսինքն, թույլտվությունը տեղի է ունենում մտացածին օգտագործողի միջոցով (և գրանցումը ձեռքով):

  2) Այնուամենայնիվ, Selenium-ի հետ չկան երաշխիքներ ճիշտ և կրկնվող աշխատանքի համար (գոնե ok.ru-ի դեպքում հաստատ):

  3) Ok.ru կայքը պարունակում է JavaScript-ի սխալներ և երբեմն իրեն տարօրինակ և անհամապատասխան է պահում:

  4) Դուք պետք է կատարեք էջադրում, բեռնում տարրեր և այլն...

  5) API-ի սխալները, որոնք տալիս է wrapper-ը, պետք է անհարմար կերպով վարվեն, օրինակ, այսպես (փորձնական կոդի մի հատված).

  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) Ի վերջո, Selenium + API-ն ամենառացիոնալ տարբերակն է թվում:

• Պետք է պահպանել վիճակը և վերագործարկել համակարգը, կարգավորել բազմաթիվ սխալներ, այդ թվում՝ կայքի անհամապատասխան վարքագիծը, և այդ սխալները բավականին դժվար է պատկերացնել (եթե իհարկե մասնագիտորեն վերլուծողներ չգրես):

Այս առաջադրանքի պայմանական ժամանակի գնահատումը կլինի 3-5 անգամ ավելի բարձր, քան Habr-ից տվյալների հավաքագրման համար: Չնայած այն հանգամանքին, որ Habr-ի դեպքում մենք օգտագործում ենք ճակատային մոտեցում HTML վերլուծությամբ, իսկ OK-ի դեպքում կարող ենք աշխատել API-ի հետ կրիտիկական վայրերում։

Արդյունքները

Անկախ նրանից, թե որքան էլ ձեզանից պահանջվում է «տեղում» գնահատել ժամկետները (մենք այսօր ծրագրում ենք) ծավալուն տվյալների մշակման խողովակաշարի մոդուլի, կատարման ժամանակը գրեթե երբեք հնարավոր չէ գնահատել նույնիսկ որակապես՝ առանց առաջադրանքի պարամետրերը վերլուծելու:

Մի փոքր ավելի փիլիսոփայական նկատառումով, արագաշարժ գնահատման ռազմավարությունները լավ են աշխատում ինժեներական առաջադրանքների համար, բայց խնդիրները, որոնք ավելի փորձնական են և, ինչ-որ իմաստով, «ստեղծագործական» և հետախուզական, այսինքն՝ ավելի քիչ կանխատեսելի, ունեն դժվարություններ, ինչպես օրինակ նմանատիպ թեմաների օրինակներում: որը մենք քննարկել ենք այստեղ:

Իհարկե, տվյալների հավաքագրումը պարզապես վառ օրինակ է. դա սովորաբար աներևակայելի պարզ և տեխնիկապես ոչ բարդ խնդիր է, և սատանան հաճախ մանրուքների մեջ է: Եվ հենց այս առաջադրանքի վրա է, որ մենք կարող ենք ցույց տալ հնարավոր տարբերակների ողջ շրջանակը, թե ինչ կարող է սխալ լինել և կոնկրետ որքան ժամանակ կարող է տևել աշխատանքը:

Եթե ​​առանց լրացուցիչ փորձերի նայեք առաջադրանքի բնութագրերին, ապա Reddit-ը և OK-ը նման են տեսքի. կա API, python-ի փաթաթան, բայց ըստ էության տարբերությունը հսկայական է: Դատելով այս պարամետրերից, Habr-ի պարսը ավելի բարդ է թվում, քան OK-ը, բայց գործնականում դա բոլորովին հակառակն է, և դա հենց այն է, ինչ կարելի է պարզել խնդրի պարամետրերը վերլուծելու համար պարզ փորձեր կատարելով:

Իմ փորձով, ամենաարդյունավետ մոտեցումն է մոտավորապես գնահատել այն ժամանակը, որը ձեզ անհրաժեշտ կլինի բուն նախնական վերլուծության և պարզ առաջին փորձերի համար, կարդալով փաստաթղթերը. դրանք թույլ կտան ճշգրիտ գնահատական ​​տալ ամբողջ աշխատանքին: Հանրաճանաչ արագաշարժ մեթոդաբանության առումով ես խնդրում եմ ձեզ ստեղծել «առաջադրանքի պարամետրերի գնահատման» տոմս, որի հիման վրա ես կարող եմ գնահատել, թե ինչ կարող է իրականացվել «սպրինտի» շրջանակներում և տալ ավելի ճշգրիտ գնահատական ​​յուրաքանչյուրի համար։ առաջադրանք.

Հետևաբար, թվում է, թե ամենաարդյունավետ փաստարկը այն փաստարկն է, որը ցույց կտա «ոչ տեխնիկական» մասնագետին, թե որքան ժամանակ և ռեսուրսներ կտարբերվեն՝ կախված այն պարամետրերից, որոնք դեռ պետք է գնահատվեն:

Source: www.habr.com