Co se může s Data Science pokazit? Sběr dat

Dnes existuje 100500 XNUMX kurzů Data Science a již dlouho je známo, že nejvíce peněz v Data Science lze vydělat prostřednictvím kurzů Data Science (proč kopat, když můžete prodávat lopaty?). Hlavní nevýhodou těchto kurzů je, že nemají nic společného se skutečnou prací: nikdo vám nedá čistá, zpracovaná data v požadovaném formátu. A když opustíte kurz a začnete řešit skutečný problém, objeví se mnoho nuancí.

Proto začínáme sérii poznámek „Co se může pokazit s Data Science“, založených na skutečných událostech, které se staly mně, mým kamarádům a kolegům. Budeme analyzovat typické úlohy Data Science na skutečných příkladech: jak se to vlastně děje. Začněme dnes úkolem sběru dat.

A první věc, o kterou lidé zakopnou, když začnou pracovat se skutečnými daty, je ve skutečnosti shromažďovat tato data, která jsou pro nás nejdůležitější. Hlavní poselství tohoto článku:

Systematicky podceňujeme čas, zdroje a úsilí potřebné ke sběru, čištění a přípravě dat.

A co je nejdůležitější, probereme, co dělat, abychom tomu zabránili.

Podle různých odhadů zabere čištění, transformace, zpracování dat, inženýrství funkcí atd. 80–90 % času a analýza 10–20 %, zatímco téměř veškerý výukový materiál se zaměřuje výhradně na analýzu.

Podívejme se na jednoduchý analytický problém ve třech verzích jako typický příklad a podívejme se, co jsou „přitěžující okolnosti“.

A jako příklad opět zvážíme podobné varianty úkolu shromažďovat data a porovnávat komunity pro:

1. Dva subreddity na Redditu
2. Dva oddíly Habr
3. Dvě skupiny Odnoklassniki

Podmíněný přístup v teorii

Otevřete web a přečtěte si příklady, pokud jsou jasné, vyhraďte si několik hodin na čtení, několik hodin na kód pomocí příkladů a ladění. Přidejte několik hodin na sběr. Vhoďte pár hodin do rezervy (vynásobte dvěma a přidejte N hodin).

Klíčový bod: Časové odhady jsou založeny na předpokladech a dohadech o tom, jak dlouho to bude trvat.

Svou časovou analýzu musíte zahájit odhadem následujících parametrů pro podmíněný problém popsaný výše:

• Jaká je velikost dat a kolik z nich je potřeba fyzicky shromáždit (*viz níže*).
• Jaká je doba sběru jedné desky a jak dlouho musíte čekat, než budete moci sbírat druhou?
• Zvažte napsání kódu, který uloží stav a spustí restart, když (ne pokud) vše selže.
• Zjistěte, zda potřebujeme autorizaci a nastavte čas pro získání přístupu přes API.
• Nastavte počet chyb jako funkci složitosti dat – vyhodnoťte pro konkrétní úkol: strukturu, kolik transformací, co a jak extrahovat.
• Opravte síťové chyby a problémy s nestandardním chováním projektu.
• Posuďte, zda jsou požadované funkce v dokumentaci, a pokud ne, jak a kolik je potřeba pro řešení.

Nejdůležitější je, že abyste mohli odhadnout čas – vlastně musíte věnovat čas a úsilí „průzkumu v síle“ – jen tak bude vaše plánování adekvátní. Proto bez ohledu na to, jak moc jste nuceni říkat „jak dlouho trvá sběr dat“ – kupte si čas na předběžnou analýzu a argumentujte, jak moc se bude čas lišit v závislosti na skutečných parametrech úkolu.

A nyní si ukážeme konkrétní příklady, kde se takové parametry změní.

Klíčový bod: Odhad je založen na analýze klíčových faktorů ovlivňujících rozsah a složitost práce.

Odhad na základě odhadu je dobrý přístup, když jsou funkční prvky dostatečně malé a není mnoho faktorů, které mohou významně ovlivnit návrh problému. Ale v případě řady problémů Data Science se takových faktorů stává extrémně mnoho a takový přístup se stává nedostatečným.

Srovnání komunit na Redditu

Začněme tím nejjednodušším případem (jak se později ukáže). Obecně, abych byl zcela upřímný, máme téměř ideální případ, podívejme se na náš kontrolní seznam složitosti:

• Existuje úhledné, jasné a zdokumentované API.
• Je to extrémně jednoduché a co je nejdůležitější, token se získává automaticky.
• K dispozici je python wrapper - se spoustou příkladů.
• Komunita, která analyzuje a shromažďuje data na redditu (včetně videí na YouTube vysvětlujících, jak používat python wrapper) tady je příklad.
• Metody, které potřebujeme, pravděpodobně existují v API. Navíc kód vypadá kompaktně a čistě, níže je příklad funkce, která shromažďuje komentáře k příspěvku.

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()

Vzáno z tohle výběr pohodlných nástrojů pro balení.

Navzdory skutečnosti, že se jedná o nejlepší případ, stále stojí za to vzít v úvahu řadu důležitých faktorů z reálného života:

• Limity API - jsme nuceni brát data dávkově (uspání mezi požadavky atd.).
• Čas sběru – pro kompletní analýzu a srovnání si budete muset vyhradit značný čas jen na to, aby pavouk prošel subredditem.
• Robot musí běžet na serveru – nemůžete ho jen spustit na notebooku, dát si ho do batohu a věnovat se své práci. Vše jsem tedy spustil na VPS. Použitím propagačního kódu habrahabr10 můžete ušetřit dalších 10 % nákladů.
• Fyzická nedostupnost některých dat (jsou viditelná pro administrátory nebo je příliš obtížné je shromáždit) - s tím je třeba počítat, v zásadě nelze všechna data shromáždit v adekvátním čase.
• Chyby sítě: Práce v síti je bolest.
• Toto jsou živá skutečná data – nikdy nejsou čistá.

Samozřejmě je nutné tyto nuance zahrnout do vývoje. Konkrétní hodiny/dny závisí na zkušenostech s vývojem nebo zkušenostech s prací na podobných úkolech, nicméně vidíme, že zde je úkol čistě inženýrský a nevyžaduje další pohyby těla k řešení – vše lze velmi dobře posoudit, naplánovat a udělat.

Srovnání sekcí Habr

Přejděme k zajímavějšímu a netriviálnímu případu srovnávání vláken a/nebo sekcí Habr.

Pojďme se podívat na náš kontrolní seznam složitosti – zde, abyste porozuměli každému bodu, budete se muset trochu ponořit do samotného úkolu a experimentovat.

• Nejprve si myslíte, že existuje API, ale není. Ano, ano, Habr má API, ale není uživatelům přístupné (nebo možná vůbec nefunguje).
• Pak stačí začít analyzovat html - „požadavky na import“, co by se mohlo pokazit?
• Jak vůbec analyzovat? Nejjednodušším a nejčastěji používaným přístupem je iterace přes ID, všimněte si, že to není nejúčinnější a bude se muset vypořádat s různými případy - zde je příklad hustoty skutečných ID mezi všemi existujícími.

  
  Vzáno z tohle články.

• Nezpracovaná data zabalená v HTML na vrcholu webu jsou bolest. Chcete například shromáždit a uložit hodnocení článku: vytrhli jste skóre z html a rozhodli jste se jej uložit jako číslo pro další zpracování: 

  1) int(skóre) vyvolá chybu: protože na Habré je mínus, jako například v řádku „–5“ - jedná se o pomlčku, nikoli o znaménko mínus (nečekaně, že?), takže při v určitém okamžiku jsem musel oživit analyzátor tak hroznou opravou.

  try:
        score_txt = post.find(class_="score").text.replace(u"–","-").replace(u"+","+")
        score = int(score_txt)
        if check_date(date):
          post_score += score
  

  Nemusí tam být vůbec žádné datum, plusy a mínusy (jak vidíme výše ve funkci check_date, stalo se to).

  2) Neutečené speciální postavy - přijdou, musíte být připraveni.

  3) Struktura se mění v závislosti na typu příspěvku.

  4) Staré příspěvky mohou mít **divnou strukturu**.

• V podstatě se bude muset zvládnout zpracování chyb a to, co se může nebo nemusí stát, a nemůžete s jistotou předvídat, co se pokazí a jak jinak může být struktura a co kde odpadne - budete to muset zkusit a vzít v úvahu chyby, které analyzátor vyvolá.
• Pak si uvědomíte, že je potřeba parsovat ve více vláknech, jinak parsování v jednom pak zabere 30+ hodin (to je čistě doba provádění již fungujícího jednovláknového parseru, který spí a nespadá pod žádné zákazy). V tohle článek, to v určitém okamžiku vedlo k podobnému schématu:

Celkový kontrolní seznam podle složitosti:

• Práce se sítí a html parsování s iterací a vyhledáváním podle ID.
• Dokumenty heterogenní struktury.
• Je mnoho míst, kam může kód snadno spadnout.
• Je třeba napsat || kód.
• Chybí potřebná dokumentace, příklady kódu nebo komunita.

Odhadovaný čas na tento úkol bude 3–5krát delší než u sběru dat z Redditu.

Srovnání skupin Odnoklassniki

Přejděme k technicky nejzajímavějšímu popsanému případu. Pro mě to bylo zajímavé právě proto, že to na první pohled vypadá docela triviálně, ale vůbec to tak nevypadá - jakmile do toho šťouchnete klackem.

Začněme s naším kontrolním seznamem obtížnosti a poznamenejme, že mnohé z nich budou mnohem obtížnější, než se na první pohled zdá:

• Existuje API, ale téměř úplně postrádá potřebné funkce.
• K některým funkcím si musíte vyžádat přístup poštou, to znamená, že udělení přístupu není okamžité.
• Je to děsně zdokumentované (pro začátek se všude pletou ruské a anglické výrazy a naprosto nejednotně - někdy je potřeba jen uhodnout, co po vás někde chtějí) a navíc provedení není vhodné pro získávání dat např. , funkci, kterou potřebujeme.
• Vyžaduje relaci v dokumentaci, ale ve skutečnosti ji nepoužívá – a neexistuje žádný způsob, jak porozumět všem složitostem režimů API, než šťouchání a doufání, že něco bude fungovat.
• Neexistují žádné příklady a žádná komunita, jediný bod podpory při shromažďování informací je malý obal v Pythonu (bez mnoha příkladů použití).
• Selen se zdá být nejfunkčnější možností, protože mnoho potřebných dat je uzamčeno.
  1) To znamená, že autorizace probíhá prostřednictvím fiktivního uživatele (a registrace ručně).

  2) Se Selenium však nejsou žádné záruky správné a opakovatelné práce (alespoň v případě ok.ru určitě).

  3) Web Ok.ru obsahuje chyby JavaScriptu a někdy se chová podivně a nekonzistentně.

  4) Musíte provést stránkování, načítání prvků atd...

  5) Chyby API, které dává wrapper, budou muset být zpracovány nešikovně, například takto (kus experimentálního kódu):

  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
  

  Moje oblíbená chyba byla:

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

  6) Nakonec se Selenium + API jeví jako nejracionálnější varianta.

• Je potřeba uložit stav a restartovat systém, zvládnout mnoho chyb, včetně nekonzistentního chování webu – a tyto chyby si lze dost těžko představit (pokud samozřejmě nepíšete parsery profesionálně).

Podmíněný časový odhad pro tento úkol bude 3-5krát vyšší než u sběru dat od Habr. Nehledě na to, že v případě Habra používáme frontální přístup s HTML parsováním a v případě OK umíme pracovat s API na kritických místech.

Závěry

Bez ohledu na to, jak moc musíte odhadnout termíny „na místě“ (dnes plánujeme!) modulu pro zpracování objemných dat, dobu realizace téměř nikdy nelze odhadnout ani kvalitativně bez analýzy parametrů úlohy.

Poněkud filozofičtěji řečeno, agilní odhadovací strategie fungují dobře pro inženýrské úlohy, ale problémy, které jsou více experimentální a v jistém smyslu „kreativní“ a průzkumné, tj. méně předvídatelné, mají potíže, jako v příkladech podobných témat. o kterém jsme zde diskutovali.

Sběr dat je samozřejmě jen ukázkovým příkladem – obvykle jde o neuvěřitelně jednoduchý a technicky nekomplikovaný úkol a ďábel se často skrývá v detailech. A právě na tomto úkolu můžeme ukázat celou řadu možných variant, co se může pokazit a jak přesně může práce trvat.

Pokud se podíváte na charakteristiky úlohy bez dalších experimentů, pak Reddit a OK vypadají podobně: existuje API, python wrapper, ale v podstatě je rozdíl obrovský. Soudě podle těchto parametrů vypadá Habrův pars komplikovaněji než OK - ale v praxi je to přesně naopak a přesně to lze zjistit jednoduchými experimenty na analýzu parametrů problému.

Podle mých zkušeností je nejúčinnějším přístupem hrubý odhad času, který budete potřebovat na samotnou předběžnou analýzu a jednoduché první experimenty, čtení dokumentace – ty vám umožní dát přesný odhad celé práce. V rámci populární agilní metodiky vás žádám o vytvoření lístku pro „odhad parametrů úkolu“, na jehož základě mohu posoudit, co lze v rámci „sprintu“ dosáhnout a u každého uvést přesnější odhad. úkol.

Jako nejúčinnější se proto jeví argument, který by „netechnickému“ specialistovi ukázal, kolik času a zdrojů se bude lišit v závislosti na parametrech, které je třeba teprve posoudit.

Zdroj: www.habr.com