Door: Steffi
Als data-engineer is een veelvoorkomende taak het bouwen van ETL’s: processen die gegevens extraheren, transformeren en laden. Een logisch gebruiksscenario voor een dergelijk proces is het importeren van gegevens uit een bron in een datawarehouse, zodat de geïmporteerde gegevens kunnen worden gecombineerd met andere kennis in het datawarehouse.
Een dergelijke import bestaat doorgaans uit drietal stappen:
1: data wordt uit de bron opgehaald (ofwel geëxtraheerd),
2: data wordt zodanig getransformeerd dat deze in de structuur van het data warehouse past (ofwel getransformeerd), en ten slotte stap
3: waarin de gegevens in het datawarehouse worden opgeslagen (ofwel geladen).
Deze blogpost gaat vooral over de tweede stap, de transformatie van de data.
Waarom is het noodzakelijk?
Om de aanpak die we gaan bespreken te begrijpen, is het de moeite waard om eerst de vraag te beantwoorden waarom we dit überhaupt doen.
Als we gegevens ophalen uit een systeem, verschaft dit ons vaak nuttige inzichten. Meestal kunnen de gegevens uit een specifiek systeem slechts een beperkt aantal vragen beantwoorden die bovendien vaak gebonden zijn aan een specifiek domein. Nuttig, maar een beperkte scope dus.
Neem bijvoorbeeld een specifieke Google-advertentiecampagne. Google-Ads geeft u toegang tot een verscheidenheid aan rapporten en statistieken, die op zichzelf zeker al nuttig zijn. Maar door de aard van de service zelf hebben de rapporten en statistieken alleen betrekking op advertenties zelf. Ze verschaffen ons geen inzicht in bijvoorbeeld onze voorraden, marges of de relatie met klanten buiten de advertenties. Om de data die Google Ads biedt optimaal te benutten, zouden we die data moeten combineren met data uit andere bronnen. Daartoe zouden we de gegevens uit Google Ads moeten importeren in ons eigen systeem, bij voorkeur een datawarehouse, waarin ook gegevens staan opgeslagen van andere (operationele) systemen. Pas dan kunnen inzichten verder gaan dan een specifiek domein.
Enkele overwegingen
We zouden nu voor een eenvoudige aanpak kunnen kiezen en ‘gewoon’ alle gegevens downloaden die Google-advertenties ons ter beschikking stellen en deze onbewerkt opslaan in ons datawarehouse. Dat brengt ons een stap verder, maar stel je voor dat Google-advertenties een andere definitie en een ander identificatienummer gebruiken om te identificeren dan bijvoorbeeld ons eigen Customer Relationship Management Systeem. Dat betekent ook dat we onze kennis over onze klant niet met Google-data kunnen combineren. Zonde toch?
Wat we dus het liefst willen, is dat de Google Ads-gegevens in ons datawarehouse worden opgeslagen op zo’n manier dat het aansluit bij de andere gegevens die we uit andere systemen hebben, zodat het gemakkelijk kan worden gecombineerd. Om dat mogelijk te maken, moeten we de gegevens dus vertalen en transformeren naar een bepaalde structuur.
Stel, we hebben een datawarehouse met gegevens uit meerdere bronnen. Laten we verder aannemen dat het datawarehouse gegevens opslaat in een relationeel model en dat de data tot op zekere hoogte is genormaliseerd. Dan hebben we structuur voor verdere analysedoeleinden. We willen graag dat de nieuwe data op een efficiënte manier worden opgeslagen en bovendien willen we misschien niet alle data uit het bronsysteem opslaan. Omdat we niet van plan zijn alle gegevens te gebruiken, of dat we dezelfde gegevens al uit een andere bron halen. Of omdat we slechts een deel van de software gebruiken en niet alle functionaliteiten waardoor het beschikbaar is gesteld.
Een belangrijke stap bij het vertalen van het brondatamodel naar het onze, is dus om eerst af te vragen wat voor soort vragen we met deze data willen beantwoorden. Op basis daarvan kunnen we een selectie maken van wat we willen importeren. Het kan ook zijn dat we geïnteresseerd zijn in de gegevens in een lagere frequentie dan de bron biedt, of dat we een deel van de gegevens liever geaggregeerd dan onbewerkt willen hebben. Tal van redenen dus om niet alle data doorlopend te downloaden.
Om de opslag en ook het gebruik van de gegevens efficiënt te maken, willen we de gegevens graag in een relationeel model hebben, ook al is dit bij de bron misschien niet het geval, of is deze niet altijd even consistent.
Bij het importeren van bijvoorbeeld gegevens uit een REST API kan de data relationeel zijn, maar er is vaak geen mechanisme dat consistentie op een bepaald tijdstip garandeert. Bovendien zullen we -zelfs als de gegevens op een bepaald tijdstip consistent zijn- deze waarschijnlijk niet snel genoeg kunnen ophalen om ervoor te zorgen dat ze ook blijven op het moment dat we ze gaan verwerken. In de praktijk zijn we vaak niet in staat om in één enkele uitvraag alle data op te halen. Gewoonweg omdat de data te omvangrijk is. Gevolg is dat we meerdere uitvragingen moeten doen. Met het risico dat gegevens inconsistent worden.
Naast het identificeren van de entiteiten en hun relaties moeten er dus overwegingen worden gemaakt over de timing en de eventuele inconsistentie van de gegevens.
Er zijn verschillende benaderingen om met inconsistentie in ETL-processen om te gaan, teveel voor dit artikel.
Om optimaal gebruik te maken van de nieuwe gegevensbron, willen we entiteiten waarover we gegevens importeren, in kaart brengen met de entiteiten die we al in ons datawarehouse opslaan. Bijvoorbeeld klant-ID’s om onze klanten op unieke wijze te identificeren, opgeslagen als een genormaliseerde klantentabel in ons datawarehouse. We kunnen ervan uitgaan dat ook Google gebruik maakt van klant-ID’s. Vervolgens willen we dat de klant-ID’s uit Google-advertenties overeenkomen met de klant-ID’s die we in ons systeem hebben.
Om dat te bereiken, kunnen we tijdens onze transformatiestap een ‘mapping’ uitvoeren en de gegevens al opslaan met de toegewezen klant-ID (waarbij we de oorspronkelijke klant-ID van Google Ads ernaast kunnen houden) of we kunnen de gegevens opslaan met de klant-ID van Google Ads en zorg voor een mappingtabel in ons datawarehouse.
Op dezelfde manier willen we voor alle entiteiten die we in de Google Ads-gegevens vinden, deze kunnen matchen met de reeds bestaande entiteiten in ons datawarehouse. Dit stelt ons namelijk in staat om de nieuw geïmporteerde gegevens te combineren en nieuwe inzichten te verkrijgen. Op deze manier identificeren we al onze bedrijfsentiteiten uit al onze bronnen.
Samenvatting
- Bepaal welke gegevens beschikbaar zijn
- Bepaal welke gegevens u wilt importeren
(Wees hier conservatief, als u geen vraag weet die deze gegevens kunnen beantwoorden, importeer dan niet 🙂) - Maak een model van de entiteiten en relaties van de brongegevens
- Vertaal het model naar een model dat past bij de structuur van uw datawarehouse
- Zorg ervoor dat alle entiteiten zijn toegewezen aan bestaande entiteiten