• Blog
  • Info Support
  • Career
  • Training
  • International Group
  • Info Support
  • Blog
  • Career
  • Training
  • International Group
  • Search
logo InfoSupport
  • Latest blogs
  • Popular blogs
  • Experts
      • All
      • Bloggers
      • Speakers
  • Meet us
  • About us
    • nl
    • en
    • .NET
    • 3D printing
    • Advanced Analytics
    • Agile
    • Akka
    • Alexa
    • Algorithms
    • Api's
    • Architectuur
    • Artificial Intelligence
    • ATDD
    • Augmented Reality
    • AWS
    • Azure
    • Big Data
    • Blockchain
    • Business Intelligence
    • Chatbots
    • Cloud
    • Code Combat
    • Cognitive Services
    • Communicatie
    • Containers
    • Continuous Delivery
    • CQRS
    • Cyber Security
    • Dapr
    • Data
    • Data & Analystics
    • Data Science
    • Data Warehousing
    • Databricks
    • DataOps
    • Developers life
    • DevOps
    • Digital Days
    • Digital Twin
    • Docker
    • eHealth
    • Enterprise Architecture
    • Event Sourcing
    • Hacking
    • Infrastructure & Hosting
    • Innovatie
    • Integration
    • Internet of Things
    • Java
    • Machine Learning
    • Microservices
    • Microsoft
    • Microsoft Bot Framework
    • Microsoft Data Platform
    • Mobile Development
    • Mutation Testing
    • Open source
    • Pepper
    • Power BI
    • Privacy & Ethiek
    • Python
    • Quality Assistance & Test
    • Quality Assurance & Test
    • Requirements Management
    • Scala
    • Scratch
    • Security
    • SharePoint
    • Software Architecture
    • Software development
    • Software Factory
    • SQL Server
    • SSL
    • Start-up
    • Startup thinking
    • Stryker
    • Test Quality
    • Testing
    • TLS
    • TypeScript
    • Various
    • Web Development
    • Web-scale IT
    • Xamarin
    • All
    • Bloggers
    • Speakers
Home » DWH voor informatica-studenten (deel 3: de praktijk)
  • DWH voor informatica-studenten (deel 3: de praktijk)

    • By Koos van Strien
    • Business Intelligence 10 years ago
    • Business Intelligence 0 comments
    • Business Intelligence Business Intelligence
    DWH voor informatica-studenten (deel 3: de praktijk)

    In deel 1 en deel 2 van de serie “DWH voor informatica-studenten” is ingegaan op de vraag hoe we goede (en geldige) analyses kunnen doen op een transactioneel systeem. Er werd gesteld dat om geldige conclusies te trekken over oorzaken en gevolgen, er ook een geldig historisch plaatje van het transactionele systeem geschetst moest worden. Ook werd gesteld dat het belangrijk was dat relaties eenvoudig en duidelijk aanwezig zijn, en de structuur makkelijk te verkennen is. Maar voordat dat we data in dit soort structuren kunnen opslaan, is het handig de data vast lokaal op een systeem aanwezig te hebben! Daarom in deel 3 een praktijk-post, voordat we in deel 4 weer dieper op de stof insteken.

    Scope en structuur van deze post

    Zoals gezegd, zal deze post ingegaan worden op een stukje praktijk: het binnenhalen van de Twitter-data naar een lokaal systeem, en de vormgeving van dat systeem. Om de Twitter-data netjes binnen te halen zal allereerst gekeken worden naar het verbinding maken met Twitter. Aangezien de datastructuren van Twitter op dit moment nog onbekend zijn, zal vervolgens gekeken worden naar de structuren waarin de Twitter-data aangeboden wordt, en hoe die lokaal opgeslagen kunnen worden in een relationele database. Ten slotte zal de structuur van de applicatie in grote lijnen neergezet worden.

    Code, or it didn’t happen…

    Voor een meer in-depth beeld van de applicatie kan deze gevonden worden (met handleiding) op https://github.com/kooss/Twitter_DWH. Hier zijn ook de volgende zaken te vinden:

    • Diagrammen die in deze blog gebruikt worden (in Visio zowel als PNG)
    • SQL-code waarmee in MySQL de bijbehorende database gemaakt kan worden
    • Python-code van de applicatie zelf
    • README-instructies over het aanmaken en gebruiken van de applicatie

    Mochten er zaken niet werken, schroom dan niet om me te benaderen! Mijn mailadres is af te leiden door mijn GitHub-gebruikersnaam te laten volgen door @ infosupport.com.

    Achtergrond: ETL zonder tooling?

    Wanneer je al wat meer bekend bent met Data Warehousing, kan de manier van aanpak in deze post wat vreemd overkomen: geen bekende modelleertechnieken, geen ETL-tooling of andere zaken die het leven veel makkelijker & gestructureerder maken. Zoals in de vorige post te lezen viel, wordt in deze weblogs bewust ingestoken op informatica-studenten – voorkennis van ETL-tooling, bijbehorende cursus en dergelijke zijn dus niet nodig, en we zullen in beginsel de tooling zelf programmeren. Maar allereerst is het zorg om de data überhaupt in de database te krijgen.

    Verbinding met Twitter

    Ok, tijd om aan de slag te gaan! Verbinding leggen met de Twitter API is vrij eenvoudig: de API is ontworpen conform de principes van  Representational State Transfer (REST). Alle communicatie gebeurt door middel van HTTP-requests.  De authenticatie met Twitter gaat via OAuth. Dit alles is goed gedocumenteerd in de Twitter developer documentatie op https://dev.twitter.com/docs. Voor veel programmeertalen zijn er bovendien wrappers en libraries beschikbaar voor de communicatie met Twitter.

    De applicatie voor deze post is geschreven in Python, en maakt gebruikt van de tweepy library. Hiermee is de volgende code alles wat nodig is om verbinding te maken met de Twitter API:

    import tweepy
    
    consumer_key = '' #Consumer key hier invullen
    consumer_secret = '' #Consumer secret hier invullen
    auth = tweepy.OAuthHandler(consumer_key, consumer_secret)
    api_connector = tweepy.API(auth)

    Vervolgens is de API van Twitter eenvoudig te bedienen m.b.v. het zojuist verkregen API-object. Het uitlezen van de ‘home timeline’ gaat bijvoorbeeld als volgt:

    laatste_status_id = 0 #id van de laatste status-message (tweet) die opgehaald is
    home_timeline = api_connector.home_timeline(since_id = laatste_status_id, count = 1)

    Wanneer termen als ‘consumer key’ en ‘consumer secret’ onbekend voorkomen: dit maakt onderdeel uit van de Twitter-authenticatie.

    Twitter-datastructuren

    De Twitter API biedt data via XML, JSON, RSS en Atom aan. We kiezen hier om de data in JSON-formaat op te halen. Hoewel XML voordelen heeft als gedefinieerde datatypes, schema’s en andere zaken die de ETL een stuk makkelijker maken, leest XML wat minder prettig, en voegt XML veel meta-data toe aan de eigenlijke data. Voor nu houden we het zo simpel mogelijk en kiezen voor JSON.

    Omdat we de data lokaal willen opslaan in een relationele database, is er een vertaalslag nodig van JSON naar de relationele database. Om die vertaalslag goed te kunnen maken, is het handig te weten hoe het datamodel eruit ziet wat door de JSON-structuur wordt beschreven. Op een zaterdagmiddag ben ik daar eens wat dieper ingedoken, en daar kwam de volgende schets uit (de kolomnamen zijn voor het overzicht even weggelaten):

    Hoewel het model complex genoeg is om interessante zaken mee uit te proberen, is het voor de doelstellingen in deze post iets te groot: hier is het hoofdzakelijk de bedoeling dat getoond wordt hoe de data vanaf Twitter naar het eigen systeem komt. Daarom wordt in de voorbeeld-applicatie het volgende, sterk vereenvoudigde model gebruikt:

    De lokale datastructuur

    De lokale structuur is opgeslagen in een MySQL-database, waar ook de data vanuit Twitter opgeslagen gaat worden. Schematisch ziet het er als volgt uit (datatypes zijn hier weggelaten):

    Eigenlijk is dit simpelweg een kopie van de data die Twitter via de API aanbiedt. Het grootste verschil eigenlijk is dat de datatypes nu vastgelegd zijn, evenals de foreign key. Wanneer dit werkt, is de applicatie vrij eenvoudig uit te breiden met meer tabellen.

    De applicatie

    Nu het datamodel gedefinieerd is (en in de database aanwezig) en de verbinding met Twitter gemaakt kan worden, is het slechts een kwestie van het daadwerkelijk ophalen van data & lokaal opslaan in de database. Deze code is eigenlijk vrij triviaal.

    In de applicatie zijn daarnaast wat hulpmiddelen opgenomen voor de authenticatie met Twitter. Ook is wat logica opgenomen die ervoor zorgt dat alleen statussen worden opgehaald die nog niet eerder zijn meegenomen.

    Conclusie

    In deze post is een kleine, eenvoudige implementatie gepresenteerd van een applicatie die Twitter-data verzamelt en lokaal opslaat in een database. Teruggrijpend op deel 2, waar het principe van Extract, Transform en Load (ETL) uitgelegd werd, is nu het punt ‘Extract‘ geïmplementeerd: de data van de dynamische bron (Twitter) kan opgeslagen worden in een lokale database. Dit proces heet staging – het lokaal opslaan en ‘vastzetten’ van data, alvorens het verder te verwerken in het Data Warehouse.

    Share this

Koos van Strien

View profile

Related IT training

Go to training website

Related Consultancy solutions

Go to infosupport.com

Related blogs

  • "Garbage in, Garbage out" Vincent Lukassen - 2 years ago

  • Data Governance, een hot topic in menig organisatie

    Data Governance, een hot topic in menig organisatie Vincent Lukassen - 3 years ago

  • Foodsector laat kansen liggen door beperkt gebruik van …

    Foodsector laat kansen liggen door beperkt gebruik van … Hans Geurtsen - 4 years ago

Data Discovery Channel

  • Modern Data Platform

  • Gartner Data & Analytics Summit 2022

  • De Data Architecture ®Evolution

Nieuwsbrief

* verplichte velden

Contact

  • Head office NL
  • Kruisboog 42
  • 3905 TG Veenendaal
  • T +31 318 552020
  • Call
  • Mail
  • Directions
  • Head office BE
  • Generaal De Wittelaan 17
  • bus 30 2800 Mechelen
  • T +32 15 286370
  • Call
  • Mail
  • Directions

Follow us

  • Twitter
  • Facebook
  • Linkedin
  • Youtube

Newsletter

Sign in

Extra

  • Media Library
  • Disclaimer
  • Algemene voorwaarden
  • ISHBS Webmail
  • Extranet
Beheer cookie toestemming
Deze website maakt gebruik van Functionele en Analytische cookies voor website optimalisatie en statistieken.
Functioneel Always active
De technische opslag of toegang is strikt noodzakelijk voor het legitieme doel het gebruik mogelijk te maken van een specifieke dienst waarom de abonnee of gebruiker uitdrukkelijk heeft gevraagd, of met als enig doel de uitvoering van de transmissie van een communicatie over een elektronisch communicatienetwerk.
Voorkeuren
De technische opslag of toegang is noodzakelijk voor het legitieme doel voorkeuren op te slaan die niet door de abonnee of gebruiker zijn aangevraagd.
Statistieken
De technische opslag of toegang die uitsluitend voor statistische doeleinden wordt gebruikt. De technische opslag of toegang die uitsluitend wordt gebruikt voor anonieme statistische doeleinden. Zonder dagvaarding, vrijwillige naleving door uw Internet Service Provider, of aanvullende gegevens van een derde partij, kan informatie die alleen voor dit doel wordt opgeslagen of opgehaald gewoonlijk niet worden gebruikt om je te identificeren.
Marketing
De technische opslag of toegang is nodig om gebruikersprofielen op te stellen voor het verzenden van reclame, of om de gebruiker op een website of over verschillende websites te volgen voor soortgelijke marketingdoeleinden.
Manage options Manage services Manage vendors Read more about these purposes
Voorkeuren
{title} {title} {title}