Nieuw batch importschema

codefornl / helpradar

https://www.helpradar.nl

MIT License

2 stars 8 forks source link

Nieuw batch importschema #18

Closed JanZegers closed 4 years ago

JanZegers commented 4 years ago

Bij het analyseren van corona-data.db merkte ik dat het handig is als ik meer weer van de post. Zoals:

[x] Moment van scrapen
[x] Wanneer issue is gepost
[x] Of en wanneer hij is gesloten, of bijvoorbeeld voor het laatst is gezien.
[x] Een uniforme tag, nu is er group en category en die worden random gevuld. Dit kan vaak met kleine vertaaltabel veel duidelijker worden gemaakt
[x] Expliciete column met het platform, nu staat er wel of geen id achter de source

Issue is nog wat grof, maar kan in overleg uitgewerkt worden.

Ik ga dit meteen maar even goed aanpakken zodat een scraper iedere keer gewoon alle data van een importbatch kwijt kan. Dit kan dan in een volgende stap geaggregeerd worden tot één initiatief met versies.

[x] Platform
[x] ImportBatch
[x] ImportHelpInitiatieve
[x] Aanpassen scrapers zodat deze batches maken voor een platform import.

Dit maakt het mogelijk om zsm al data te gaan verzamelen over de tijd met de bestaande scrapers.

Plat

ferrydeboer commented 4 years ago

@JanZegers Even een iets bredere vraag. Zou het makkelijker zijn als we (ook) meer ongestructureerde data opslaan en bijvoorbeeld een NoSQL db zouden gebruiken?

Ik kan me voorstellen dat je eigenlijk zoveel mogelijk informatie wilt hebben voor de analyse en dat die niet volledige gestructureerd hoeft te zijn op belangrijke aspecten na zoals datum bereiken.

JanZegers commented 4 years ago

@ferrydeboer Ik ben zelf wel voorstander van NoSQL om de data niet te laten verdampen. Maar de vraag is wat we willen bereiken. Ik denk dat we eerst meer tijd kunnen besteden aan de datapipeline, om de data op te schonen. Wellicht dat een NoSQL database daarbij kan helpen. Om met alle data beschikbaar tot een gezamelijk datamodel te komen. Want nu is de data van elke website anders.

ferrydeboer commented 4 years ago

Ik ben ook al even wat verder aan het denken hoe we technisch gezien invulling moeten geven aan met name de data over tijd. Even uitgaande van de aanname dat we periodiek een website scrapen zie ik twee strategieën:

Collectie en merging in twee losse stappen / databases. Met andere woorden de collectie database bevat voor iedere sessie een kopie van een item op een website en een merging proces verwerkt die gegevens tot een entry (al dan niet met historie)
Collectie en merging in één proces en uiteindelijk bestaat er dus maar één entry (met eventueel historie per item)

Persoonlijk denk ik dat die laatste het eenvoudigst is. Is wellicht in een later stadium op te splitsen mocht dat nodig blijken. En dan rest de vraag dus nog of we de historie bijhouden? Wellicht enkel als het record niet identiek is.

ferrydeboer commented 4 years ago

Nu ik wat meer over prioriteiten na denk zeg ik, gewoon zo snel mogelijk scraping automatiseren en ruwe data (grotendeels) gedupliceerd in een database wegschrijven: https://github.com/codefornl/helpradar/milestone/3