Kom i gang med webskraping

Når data blir tilgjen­gelig­gjort på web, er det i form av web­sider (html), flash eller pdf. Ingen av disse for­matene er egnet som en datak­ilde til videre­bruk, men med litt arbeid kan de bli det. Denne posten gir deg det du trenger for å komme i gang med web­skrap­ing, kun­sten å mask­inelt hente ut og struk­turere data fra web.

“Bruk­san­vis­nin­gen” er basert på en glim­rende guide fra ProP­ub­li­ca, ispedd egne erfaringer med alter­na­tive verk­tøy til de ProP­ub­li­ca har benyttet.

Webskraping: eksempel og verktøy

Web­skrap­ing er å lese en web­side via en pro­gram­vare for så å hente ut visse del­er av (html-)koden web­si­den består av, for deretter å lagre disse delene etter eget ønske. Typisk skriv­er man et lite script som gjør denne jobben.

Eksem­pel: du job­ber med økonomi/politikk i en redak­sjon og ønsker å vite 1) hvor ofte din kom­mune er klaget inn for KOFA (Kla­gen­em­n­da for offentlige anskaf­felser) de sen­este årene, 2) hvem som klager oftest/oftest blir innklaget i ditt område, og 3) hvor ofte kom­munen får med­hold i sak­ene de blir innklaget for. Videre ville det være gre­it å lage seg en liten tjen­este som automa­tisk informer­er deg hvis det dukker opp nye sak­er som involver­er din kommune/et spe­sielt fir­ma i KOFA.

All denne infor­masjo­nen finnes på kofa.no, men ikke på en slik måte at denne enkelt kan leses av. Se på en vilkårlig detalj­side fra kofa.no. Infor­masjo­nen her er allerede ganske godt struk­tur­ert, ved å sam­le dette inn i en data­base (eller Excel, hvis du fore­trekker det) kan alle tre punk­tene over raskt besvares. 

Propublica.org gir deg en fyldig guide for hvor­dan gjøre just dette i ruby med noko­giri. Du kan strengt tatt bruke et hvilket som helst språk, selv har jeg gode erfaringer med python og Beau­ti­ful­Soup, og anbe­faler det som et gre­it sted å starte. 

Poenget er helt enkelt å lese inn en web­side, selek­tere ele­menter som skal spares (det er dette noko­giri og Beau­ti­ful­Soup benyttes til), for så å lagre disse utval­gte ele­mentene på en måte du selv fore­trekker. Det finnes masse guider på webben om detal­jene i hvor­dan dette gjøres for utal­lige språk, her er et eksem­pel­søk.

Når du så har satt sam­men et script som hen­ter ut det du vil ha, kan det være gre­it å automa­tis­ere kjørin­gen av scriptet. Denne typen infor­masjon er det kan­skje prak­tisk å få på starten av arbei­ds­da­gen eller starten av uken. Å sette et script til å automa­tisk kjøre på visse tider kan f.eks. gjøres ved å sette opp en crontab (automa­tis­ert opp­gave). På den måten kan du også sende e‑post automa­tisk til deg selv, det som du vel­ger å skrive ut (print/put/echo/…) i scriptet blir innhold­et i mailen. Sørg for å gi deg selv nyt­tig og menings­full infor­masjon i disse mai­lene, før eller siden glem­mer du detal­jene i hvor­dan infor­masjo­nen hentes inn.

Vis hensyn

Hent bare ut den infor­masjo­nen du trenger, og hent data så sjeldent som mulig. Les denne for flere detal­jer. Sørg f.eks. for at kallet mot web­serveren du skrap­er ikke kjøres i en loop, men kun en gang i starten av scriptet. Å legge inn litt ven­tetid på strate­giske sted­er i scriptet (funksjo­nen sleep i mange språk) er også en god idé. Du trenger sjeldent hur­tighet i slike script, så å skåne web­ser­vere og data­bas­eser­vere for en bom­barder­ing av kall har du lite å tape og mye å vinne på. Du vil ikke hisse på deg driftspersonalet/sikkerhetspersonalet til organ­isas­jo­nen du job­ber mot.

Fix broken windows

Fix bro­ken win­dows er en teori om å motar­bei­de for­fall i pro­gram­vareutvikling. Det samme prin­sip­pet gjelder i web­skrap­ing som et mid­del mot “dataråte” (eller kan­skje bare “råtne data”, dataråte er et ord som også brukes på data­sys­te­mer som for­fall­er ved at gam­le fil­for­mater ikke lenger er støt­tet i nyere ver­sjon­er). Så fort det er feil i dataene du sam­ler inn beg­yn­ner ver­di­en av dem å synke, jo lenger du kan sam­le inn uten feil jo mer blir dataene verdt. Råtne data er smitt­somt. Fiks eventuelle prob­le­mer så snart du oppdager dem.

Pdf, ocr, flash og annet gruff

Å lese .pdf på omtrent samme måte som html virk­er i teorien, det er bare veldig mye vanske­ligere å få til på en effek­tiv og gjen­bruk­bar måte i prak­sis. Jeg har ikke selv fått dette til på en måte jeg men­er er god nok for automa­tis­erte job­ber. Da Sen­ter for statlig økon­o­mistyring (Sfso) startet å pub­lis­ere månedlig stat­sreg­n­skap i desem­ber i fjor, gjorde jeg et forsøk på .pdfene de pub­lis­er­er. Dette er et muli­gens gjen­nom­før­bart pros­jekt, men krev­er mye mer arbeid enn det er verdt uten en god plan videre. Jeg gav opp.

Hvis ditt pros­jekt krev­er skrap­ing av .pdfer kan guiden til ProP­ub­li­ca (ruby) eller Scrap­er­wi­ki (python) være til nytte.

OCR er en forko­r­telse for opti­cal char­ac­ter recog­ni­tion, optisk teg­ng­jenkjen­ning på norsk. Målet med denne teknikken er å tolke bilder av tekst om til tekst (noen luringer lagr­er innhold i pdf eller html som pix­el-baserte bilder). I teorien virk­er dette også, og det finnes bråte­vis med dig­i­talis­er­ing­spros­jek­ter som baser­er seg på denne meto­den. I prak­sis er dette også ofte en skuf­felse, så ha mod­er­ate forhåp­ninger til effek­tivitet og pre­sisjon her. Googles tesser­act-ocr er et ofte sitert verk­tøy i denne sam­men­heng. For detal­jer om fram­gangsmåte, se ProP­ub­li­ca eller Google code.

Et siste triks er skrap­ing av flash­sider. ProP­ub­li­ca vis­er deg hvor­dan du kan finne fram til dataene som en flash­side benyt­ter. Ved å bruke fire­bug kan du snappe opp slikt, og så hoppe over hele flash-biten. Flash lar seg ikke skrape slik html gjør, da flash på web vis­es som et html-ele­ment som innkap­sler en flash-fil (.swf).

La analysen begynne!

Når du nå har sam­let inn data med scriptet ditt, og lagret dataene slik du lik­er å ha dem, kan du beg­ynne å analy­sere. I mange til­feller vil den jobben du har gjort så langt være grunnlaget for en sto­ry, kan­skje du kan ringe en ekspert eller kon­fron­tere en part med funnene dine i et inter­vju? Uansett kan det være lurt å dobbelt­sjekke dataene for feil eller man­gler. En datavask i Google refine kan i mange til­feller slå sam­men disse to opp­gavene, sjekk ut artikke­len om datavask­ing her på Vox Pub­li­ca. ProP­ub­li­ca har også en artikkel om Google refine.

Veien videre

Web­skrap­ing er litt vanske­lig første gang. Din andre skrap­er tar kun en brøkdel av tiden å skrive, og blir bedre enn den første. En skrap­er har typisk kun få kodelin­jer, er lett å lese og forstå og kan enkelt mod­i­fis­eres. Det er sannsyn­lig at web­skrap­ing blir en vik­tigere metode framover, da stadig mer data pub­lis­eres på nett. Web­skrap­ing er ikke den beste løs­nin­gen for noen av oss, det vi egentlig vil ha er et API, men å få data ut på web er et skritt i rik­tig retning.

Å scrape en web­side ruti­nemes­sig og så selv legge dataene et sted hvor de kan nås via et API, er en god idé. Scraperwiki.org er en operasjon­alis­er­ing av denne ideen, med et til­legg om at vi kollek­tivt kan gjen­bruke hveran­dres datainnsam­ling. Å bruke Scrap­er­wi­ki til å ta hånd om data­la­gring, automa­tis­er­ing og arkitek­tur for API­et kan være en løs­ning for team som job­ber sam­men i en redak­sjon. Redak­sjon­er som er i direk­te konkur­ranse med andre (riksme­di­er) vil nok fore­trekke bedriftsin­terne løsninger.

Når en web­side endr­er struk­tur går ofte skrap­ere “i stykker”, de finner ikke det de er på jakt etter lenger for­di dataene ikke er der i hier­arki­et hvor de plei­de å være. Dette er et av argu­mentene mot å bruke skrap­ing som del av en arbei­ds­flyt. Det finnes et poten­sielt ved­like­hold­sar­beid du selv ikke kan påvirke hyp­pigheten av. Min erfar­ing er at dette ikke er et stort prob­lem da web­sider, kan­skje særlig statlige/kommunale, sjeldent endres på andre måter enn at mer innhold fylles på. Jeg har flere skrap­ere som har kjørt siden jeg beg­y­nte med dette for et drøyt år siden, og ingen skrap­ere som har stop­pet eller krasjet. 

Web­skrap­ing er ikke den beste løs­nin­gen, men den virk­er.