DWH voor informatica-studenten (deel 2: lokale opslag)

In de vorige post is ingegaan op de wenselijkheid van het bijhouden van de historie van een transactioneel systeem. Als voorbeeld werd hier het “transactionele systeem” Twitter gebruikt. Hier wordt een analyse op uitgevoerd over het verband tussen het gebruik van bepaalde hashtags of mentions en de mutatie in het followers-bestand. Het bleek dat er een systeem nodig was dat periodiek kijkt naar het Twitter-systeem, en de historie daarvan opslaat.

Naar aanleiding van de vorige post zijn er nog wat openstaande vragen, die in deze post behandeld worden:

1. Hoe vaak moet Twitter gecontroleerd worden op nieuwe data?
2. Waar wordt data lokaal opgeslagen? (Bestandssysteem? Database?)
3. Met welke structuur wordt data lokaal opgeslagen? (XML, Json, derde normaalvorm, anders?)
4. Is er een vertaalslag nodig van de data zoals deze van Twitter komt en zoals die lokaal opgeslagen wordt?

Hoe vaak moet Twitter op nieuwe data gecontroleerd worden?

Gegeven de volgende punten lijkt het ruim voldoende om ieder uur te controleren op nieuwe data:

• Vanaf @kvstrien wordt zelden meer dan eens per uur getweet
• @kvstrien heeft nog nooit meer dan eens per uur een follower erbij gekregen
• Deze blog (die ook lijkt mee te wegen) wordt ook minder vaak dan eens per uur bijgewerkt.

Bijkomend voordeel is dat met de Twitter-ontwikkelaarsaccounts het aantal API-requests dat je mag doen per uur opnieuw ingesteld worden. Een Twitter-hyperactieve politicus of mediaman, zal waarschijnlijk meerdere malen per uur moeten controleren of er nieuwe updates waren van tweets, followers en andere zaken. Het is bij de Twitter-API zelfs mogelijk om een systeem op de ‘streaming API‘ aan te sluiten, waardoor het systeem dat hier gebruik van maakt wijzigingen automatisch gepusht krijgt. In de huidige case is dat echter overkill.

Verdieping: Granulariteit

Bij BI wordt vaak gesproken over de “granulariteit” van data. Daarmee wordt bedoeld tot op welk detailniveau er zinnige dingen over de data gezegd kunnen worden. In dit geval is gekozen om ieder uur Twitter te checken op nieuwe tweets of een mutatie in de followers-groep. Wat betreft de tijdsspanne waarop met data onderbouwde uitspraken gegdaan kunnen worden, ligt de granulariteit dus op uurniveau. Vragen als “Hoeveel minuten duurt het voordat mensen @kvstrien gaan volgen na een populaire tweet?” zullen dus vanuit dit systeem niet te beantwoorden zijn. Wordt echter gevraagd hoeveel uren of dagen het duurt voordat mensen @kvstrien gaan volgen, dan is dat wel te beantwoorden.

Waar wordt de data lokaal opgeslagen?

De opgeslagen data wordt gebruikt om verbanden te leggen – bijvoorbeeld tussen het aantal hashtags, mentions en de mutatie in de followers-groep. Daarom moet een manier van opslag gekozen worden die het makkelijk maakt om relaties te leggen. Het simpelweg opslaan van elk request in een bestand op het bestandssysteem is dan niet erg handig. Beter is het om de data in een relationeel database-systeem (rdbms) te zetten. Het maakt hierbij niet uit welk rdbms dit is – in de praktijkposts zal het gratis, overal beschikbare en open source MySQL gebruikt worden. Mocht je een ander rdbms klaar hebben staan (Postgres, SQL Server, Oracle, DB2, SAS) dan kan dat evengoed gebruikt worden.

Met welke structuur wordt de data opgeslagen?

Er zijn inmiddels al een aantal eigenschappen voorbij gekomen die wenselijk zijn in de structuur waarin de data wordt opgeslagen:

• De structuur moet historie kunnen opslaan
• Binnen de structuur moet het makkelijk zijn relaties te leggen
• De structuur moet makkelijk te verkennen zijn. Deze is niet expliciet genoemd, maar denk hierbij aan zaken als duidelijke, consistente naamgeving (geen afkortingen e.d.) en eenvoudige structuren (geen 20 niveaus aan tabellen voordat je alle data verzameld hebt).
• Bij het verkennen van de data(structuur) is het belangrijk dat er geen ongeldige relaties gelegd worden (een follower die erbij gekomen is mag niet gekoppeld worden aan een tweet die pas een halfuur later is geplaatst).

In dit geval kiezen we om de data te modelleren naar het Dimensioneel Model. Daar ben je vermoedelijk niet bekend mee, en ik ga er vóór de volgende theorie-post niet teveel over vertellen. Mocht je nu alvast meer willen weten, kijk dan eens rond op Wikipedia.

Is er een vertaalslag nodig van Twitter naar een Dimensioneel Model?

Twitter biedt de data aan in bijvoorbeeld JSON, XML, RSS  of ATOM. Om de data in een Dimensioneel Model binnen een rdbms te krijgen, is het nodig om een vertaalslag hiervoor te schrijven. Ik heb nog niet verteld hoe een Dimensioneel Model eruit ziet, dus we kunnen inhoudelijk nog niet echt ingaan op die vertaalslag. Wat we wél kunnen doen, is een structuur opzetten waar we de vertaalslag straks in kunnen hangen. We nemen de volgende stappen:

1. We halen de Twitter-data op (REST, dus HTTP GET requests)
2. We slaan de resultaten op in een structuur die klaar is voor het Dimensioneel Model
3. We laden de data in het Dimensioneel Model

Dit proces noemen we ETL. Extract (stap 1), Transform (stap 2) and Load (stap 3). Aan ETL zal nog een uitgebreidere post geweid worden.

Achtergrond: ETL-tooling

Er zijn talloze handige tools die je helpen bij het opzetten van een ETL-proces: het periodiek uitvoeren, het kopiëren van bestanden die je gaat inlezen, het uitpakken van XML, het verbinding maken met verschillende soorten databases, en het proces schematisch weergeven. Die tools zijn echter niet nodig of verplicht. Als je je ETL-proces wilt opzetten in Bash, Powershell, C#, Python of PHP, dan kan dat. En aangezien we als informatici graag weten wat er achter de schermen gebeurt, zal in de praktijk-posts in het begin de ETL-tooling zelf geschreven worden.

Samenvatting en conclusie

De afgelopen twee posts zijn veel keuzes gemaakt die het systeem gaan vormgeven:

• Het te bouwen systeem moet helpen om analyses te doen over Twitter-data.
• Data wordt opgeslagen in een rdbms
• Binnen het rdmbs wordt data gemodelleerd naar een Dimensioneel Model
• Het systeem wordt elk uur bijgeladen met ‘verse’ data uit Twitter.
• Wat tijd betreft, is de laagste granulariteit van de data dus één uur.

Na al deze begrippen en basis-theorie is er voldoende basis voor wat praktijk-werk: in de volgende post zal het systeem gebouwd worden dat Twitter-data naar onze database laadt!

Share this