Mi ronthat el az adattudományban? Adatgyűjtés

Ma 100500 XNUMX adattudományi kurzus létezik, és régóta köztudott, hogy az adattudományban a legtöbb pénzt az adattudományi kurzusokon lehet keresni (miért ásni, ha lehet lapátokat eladni?). Ezeknek a kurzusoknak a fő hátránya, hogy semmi közük a valódi munkához: senki nem ad tiszta, feldolgozott adatokat a szükséges formátumban. És amikor elhagyja a tanfolyamot, és elkezdi megoldani a valódi problémát, sok árnyalat jelenik meg.

Ezért elindítunk egy jegyzetsorozatot „Mi lehet a baj az adattudományban”, amely valós eseményeken alapul, amelyek velem, bajtársaimmal és kollégáimmal történtek. A tipikus Data Science feladatokat valós példák segítségével elemezzük: hogyan történik ez valójában. Kezdjük ma az adatgyűjtési feladattal.

És az első dolog, amibe az emberek belebotlanak, amikor elkezdenek valódi adatokkal dolgozni, az az, hogy összegyűjtik a számunkra legrelevánsabb adatokat. A cikk legfontosabb üzenete:

Szisztematikusan alábecsüljük az adatok gyűjtéséhez, tisztításához és előkészítéséhez szükséges időt, erőforrásokat és erőfeszítéseket.

És ami a legfontosabb, megbeszéljük, mit tegyünk ennek megakadályozása érdekében.

Különböző becslések szerint a tisztítás, átalakítás, adatfeldolgozás, jellemző tervezés stb. az idő 80-90%-át, az elemzés 10-20%-át vesz igénybe, miközben szinte minden oktatási anyag kizárólag az elemzésre fókuszál.

Nézzünk meg egy egyszerű analitikai problémát három változatban tipikus példaként, és nézzük meg, mik a „nehezítő körülmények”.

Példaként ismét megvizsgáljuk az adatgyűjtés és a közösségek összehasonlításának feladatának hasonló változatait:

1. Két Reddit alreddit
2. Két szakasza a Habr
3. Az Odnoklassniki két csoportja

Feltételes megközelítés elméletben

Nyissa meg az oldalt, és olvassa el a példákat, ha egyértelmű, szánjon néhány órát az olvasásra, néhány órát a kódra a példák és a hibakeresés segítségével. Adjon hozzá néhány órát a gyűjtéshez. Dobj be néhány órát tartalékba (szorozd meg kettővel és adj hozzá N órát).

Kulcspont: Az időbecslések feltételezéseken és találgatásokon alapulnak arra vonatkozóan, hogy mennyi ideig tart.

Az időelemzést a fent leírt feltételes probléma alábbi paramétereinek becslésével kell kezdeni:

• Mekkora az adatok mérete, és mennyit kell belőlük fizikailag összegyűjteni (*lásd alább*).
• Mennyi az egyik lemez gyűjtési ideje, és mennyit kell várni, mielőtt begyűjtheti a másodikat?
• Fontolja meg olyan kód írását, amely elmenti az állapotot, és elindítja az újraindítást, ha (nem ha) minden meghiúsul.
• Állapítsa meg, hogy szükségünk van-e engedélyre, és állítsa be az API-n keresztüli hozzáférés megszerzésének idejét.
• Állítsa be a hibák számát az adatok összetettségének függvényében - értékelje ki egy adott feladathoz: struktúra, hány transzformáció, mit és hogyan kell kinyerni.
• Javítsa ki a hálózati hibákat és a nem szabványos projektviselkedéssel kapcsolatos problémákat.
• Mérje fel, hogy a szükséges funkciók szerepelnek-e a dokumentációban, és ha nem, akkor hogyan és mennyi szükséges a megoldáshoz.

A legfontosabb dolog az, hogy az idő becsléséhez - valójában időt és erőfeszítést kell szánni az "erőben lévő felderítésre" - csak akkor lesz megfelelő a tervezés. Ezért bármennyire is kényszerítik Önt arra, hogy „mennyi ideig tart az adatgyűjtés” – szánjon magának egy kis időt egy előzetes elemzésre, és érveljen azzal, hogy az idő mennyiben fog változni a probléma valós paramétereitől függően.

És most konkrét példákat mutatunk be, ahol ezek a paraméterek megváltoznak.

Kulcspont: A becslés a munka terjedelmét és összetettségét befolyásoló kulcstényezők elemzésén alapul.

A találgatásokon alapuló becslés akkor jó megközelítés, ha a funkcionális elemek elég kicsik, és nincs sok olyan tényező, amely jelentősen befolyásolhatja a probléma tervezését. De számos adattudományi probléma esetén az ilyen tényezők rendkívül sokasodnak, és ez a megközelítés alkalmatlanná válik.

A Reddit közösségek összehasonlítása

Kezdjük a legegyszerűbb esettel (mint később kiderül). Általánosságban, hogy őszinte legyek, szinte ideális esetünk van, nézzük meg a komplexitási ellenőrzőlistánkat:

• Van egy ügyes, világos és dokumentált API.
• Rendkívül egyszerű, és ami a legfontosabb, a tokent automatikusan megkapja.
• Van python wrapper - sok példával.
• Egy közösség, amely elemzi és adatokat gyűjt a redditen (még a python wrapper használatát elmagyarázó YouTube-videókhoz is) Például.
• A szükséges módszerek valószínűleg az API-ban találhatók. Sőt, a kód kompaktnak és letisztultnak tűnik, az alábbiakban egy olyan funkció látható, amely összegyűjti a bejegyzésekhez fűzött megjegyzéseket.

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

Vett ezt kényelmes csomagolóeszközök választéka.

Annak ellenére, hogy ez a legjobb eset, mégis érdemes figyelembe venni számos fontos tényezőt a való életből:

• API-korlátok - kénytelenek vagyunk kötegekben venni az adatokat (alvás a kérések között stb.).
• Gyűjtési idő – a teljes elemzéshez és összehasonlításhoz jelentős időt kell félretennie ahhoz, hogy a pók végigmenjen a subredditen.
• A botnak egy szerveren kell futnia – nem futtathatja egyszerűen a laptopján, berakhatja a hátizsákjába, és folytathatja a dolgát. Szóval mindent VPS-en futtattam. A habrahabr10 promóciós kód használatával további 10%-ot takaríthat meg a költségekből.
• Egyes adatok fizikai hozzáférhetetlensége (az adminisztrátorok számára láthatóak vagy túl nehezen gyűjthetőek) – ezt figyelembe kell venni, elvileg nem lehet minden adatot megfelelő időben begyűjteni.
• Hálózati hibák: A hálózatépítés fájdalmas.
• Ez élő valós adat – soha nem tiszta.

Természetesen ezeket az árnyalatokat be kell építeni a fejlesztésbe. A konkrét órák/napok a fejlesztési tapasztalattól vagy hasonló feladatokon végzett munkavégzéstől függenek, azonban azt látjuk, hogy itt a feladat tisztán mérnöki jellegű, és nem igényel további testmozgásokat a megoldásához - minden nagyon jól felmérhető, ütemezhető és elvégezhető.

Habr szakaszok összehasonlítása

Térjünk át egy érdekesebb és nem triviális esetre a Habr szálainak és/vagy szakaszainak összehasonlítására.

Nézzük meg összetettségi ellenőrzőlistánkat - itt, hogy megértsük az egyes pontokat, egy kicsit bele kell ásni magába a feladatba, és kísérleteznie kell.

• Először azt hiszed, hogy van API, de nincs. Igen, igen, a Habrnak van API-ja, de egyszerűen nem érhető el a felhasználók számára (vagy lehet, hogy egyáltalán nem működik).
• Ezután elkezdi elemezni a html-t - „import kérések”, mi lehet a hiba?
• Egyébként hogyan kell elemezni? A legegyszerűbb és leggyakrabban használt megközelítés az azonosítókon át történő iteráció, vegye figyelembe, hogy ez nem a leghatékonyabb, és különböző eseteket kell kezelnie – íme egy példa a valódi azonosítók sűrűségére az összes létező között.

  
  Vett ezt cikket.

• A HTML-be csomagolt nyers adatok az internet tetején fájdalmasak. Például egy cikk értékelését szeretné összegyűjteni és menteni: kiszakította a pontszámot a html-ből, és úgy döntött, hogy számként menti el további feldolgozás céljából: 

  1) az int(score) hibát dob: mivel a Habré-n mínusz van, mint például a „–5” sorban - ez en kötőjel, nem mínusz (váratlanul, ugye?), így valamikor életre kellett keltennem az elemzőt egy ilyen szörnyű javítással.

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

  Lehetséges, hogy nincs dátum, plusz és mínusz (amint fentebb a check_date függvényben látjuk, ez történt).

  2) Nem szabadult speciális karakterek – jönni fognak, fel kell készülni.

  3) A szerkezet a poszt típusától függően változik.

  4) A régi bejegyzések **fura szerkezetű** lehetnek.

• Lényegében a hibakezelést és azt, hogy mi történhet vagy nem, kezelni kell, és nem lehet biztosan megjósolni, hogy mi fog elromlani, és hogyan lehet máshol a szerkezet, és mi fog leesni, csak meg kell próbálni és figyelembe venni az értelmező által kiadott hibák.
• Aztán rájössz, hogy több szálban kell elemezni, különben az egyben történő elemzés 30+ órát vesz igénybe (ez pusztán egy már működő egyszálas értelmező végrehajtási ideje, ami alszik és nem esik semmilyen tiltás alá). BAN BEN ezt cikket, ez valamikor hasonló sémához vezetett:

Összes ellenőrző lista összetettség szerint:

• Hálózati munka és html elemzés iterációval és azonosító szerinti kereséssel.
• Heterogén szerkezetű dokumentumok.
• Sok helyen könnyen leeshet a kód.
• Meg kell írni || kód.
• Hiányzik a szükséges dokumentáció, kódpéldák és/vagy közösség.

A feladat becsült ideje 3-5-ször hosszabb lesz, mint a Redditből történő adatgyűjtésé.

Az Odnoklassniki csoportok összehasonlítása

Térjünk át a leírt technikailag legérdekesebb esetre. Számomra pont azért volt érdekes, mert első ránézésre elég triviálisnak tűnik, de egyáltalán nem az lesz - amint bottal böksz rá.

Kezdjük a nehézségi listánkkal, és vegyük észre, hogy sok közülük sokkal nehezebbnek bizonyul, mint elsőre tűnik:

• Van API, de szinte teljesen hiányoznak a szükséges funkciók.
• Bizonyos funkciókhoz levélben kell hozzáférést kérni, vagyis a hozzáférés megadása nem azonnali.
• Rettenetesen dokumentált (eleve az orosz és az angol kifejezések keverednek mindenhol, és teljesen következetlenül - néha csak sejteni kell, hogy valahol mit akarnak tőled), ráadásul a tervezés nem alkalmas pl. , a funkció, amire szükségünk van.
• Megköveteli a munkamenetet a dokumentációban, de valójában nem használja – és az API-módok minden bonyodalmát nem lehet megérteni azon kívül, hogy turkálunk, és reméljük, hogy valami sikerülni fog.
• Nincsenek példák és nincs közösség, az információgyűjtésben az egyetlen támasz egy kicsi csomagolás Pythonban (sok használati példa nélkül).
• A szelén tűnik a legmegfelelőbb megoldásnak, mivel sok szükséges adat zárolva van.
  1) Vagyis az engedélyezés fiktív felhasználón keresztül történik (és kézzel történő regisztráció).

  2) A Selenium esetében azonban nincs garancia a helyes és megismételhető munkára (legalábbis az ok.ru esetében biztosan).

  3) Az Ok.ru webhely JavaScript-hibákat tartalmaz, és néha furcsán és következetlenül viselkedik.

  4) Lapozást, elemek betöltését stb.

  5) Az API-hibákat, amelyeket a burkoló ad, kínosan kell kezelni, például így (egy kísérleti kód):

  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
  

  A kedvenc hibám a következő volt:

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

  6) Végül a Selenium + API tűnik a legracionálisabb lehetőségnek.

• Szükséges az állapot mentése és a rendszer újraindítása, sok hiba kezelése, beleértve a webhely inkonzisztens viselkedését - és ezeket a hibákat meglehetősen nehéz elképzelni (hacsak nem professzionálisan írod az elemzőket).

Ennek a feladatnak a feltételes időbecslése 3-5-szöröse lesz, mint a Habr-ból történő adatgyűjtésnél. Annak ellenére, hogy a Habr esetében frontális megközelítést alkalmazunk HTML elemzéssel, OK esetén pedig kritikus helyeken tudunk dolgozni az API-val.

Álláspontja

Bármennyire is szükséges egy terjedelmes adatfeldolgozó csővezeték modul „helyszíni” (ma tervezzük!) határidejének becslése, a végrehajtási idő szinte soha nem becsülhető meg minőségileg is a feladat paramétereinek elemzése nélkül.

Kicsit filozófiaibb értelemben az agilis becslési stratégiák jól működnek a mérnöki feladatoknál, de a kísérletibb és bizonyos értelemben „kreatív” és feltáró jellegű, azaz kevésbé kiszámítható problémák nehézségeket okoznak, mint a hasonló témák példáiban. amit itt megbeszéltünk.

Természetesen az adatgyűjtés csak ékes példa – általában hihetetlenül egyszerű és technikailag nem bonyolult feladat, és az ördög gyakran a részletekben rejlik. És pontosan ezen a feladaton tudjuk megmutatni a lehetséges lehetőségek teljes skáláját, hogy mi hibázhat, és pontosan mennyi ideig tarthat a munka.

Ha további kísérletek nélkül rápillantunk a feladat jellemzőire, akkor a Reddit és az OK hasonlónak tűnik: van API, python wrapper, de lényegében óriási a különbség. Ezekből a paraméterekből ítélve a Habr-féle pars bonyolultabbnak tűnik, mint az OK-nak – a gyakorlatban azonban ennek éppen az ellenkezője van, és pontosan ez derül ki egyszerű kísérletekkel a probléma paramétereinek elemzésére.

Tapasztalataim szerint az a leghatékonyabb megközelítés, ha hozzávetőlegesen megbecsüljük magához az előzetes elemzéshez és az egyszerű első kísérletekhez szükséges időt, elolvasva a dokumentációt – ezek segítségével pontos becslést adhatunk a teljes munkára. Az elterjedt agilis módszertan kapcsán kérem, hogy készítsen egy jegyet a „feladat paraméterek becslésére”, amely alapján felmérhetem a „sprinten” belül mit lehet teljesíteni, és pontosabb becslést tudok adni mindegyikre. feladat.

Ezért a leghatékonyabb érvnek az tűnik, amely megmutatja egy „nem műszaki” szakembernek, hogy mennyi idő és erőforrás fog változni a még értékelendő paraméterek függvényében.

Forrás: will.com