In een moderne organisatie komt steeds meer data binnen. De truc is om deze te filteren, te verrijken en vervolgens te analyseren om te kijken wat er is gebeurd, maar vooral om te beslissen wat er moet gebeuren. Een goed doortimmerde datastrategie en een flexibel ingerichte datastructuur zijn essentieel. In het webinar ‘felyx: Clearing the road for Sustainable Dataops Driven Architectures’ vertellen Daan Stroosnier en Mees Strooker over hoe e-scooterverhuurder Felyx zijn datastrategie opnieuw inrichtte.
Felyx is een snelgroeiende Nederlandse start-up (2017) die elektrische deelscooters verhuurt. Klanten kunnen zich aanmelden via een app, waarna te zien is waar de dichtstbijzijnde e-scooter te vinden is. Felyx is inmiddels actief in twaalf steden in Nederland, België en Duitsland, verhuurt zo’n 6000 e-scooters, en heeft ruim 100 duizend maandelijks actieve gebruikers die samen inmiddels 15 miljoen kilometers hebben afgelegd. De onderneming verzamelt op diverse manieren data, die door Felyx worden gebruikt om de klanten beter te bedienen, maar ook om strategische beslissingen te nemen. Hoe heeft Felyx zijn data-strategie bepaald en hoe is de data-infrastructuur ingericht?
Diverse databronnen
Een belangrijk deel van de data komt uit de Felyx app. “Daarbij gaat het vooral om customer data, zoals het gebruik van de app en de e-scooter”, zegt Daan Stroosnier, Global Head of Data Analytics. “Aangevuld met zaken als referral promoties, kortingen en dergelijke.” Een andere bron van data zijn de e-scooters, in feite IoT-apparaten die voortdurend informatie naar Felyx sturen. “De accu van de e-scooter is een apart IoT-device”, vertelt Stroosnier. “Deze stuurt informatie over de lading en conditie naar ons, zodat we weten wanneer deze moet worden verwisseld.”
De eigen technici en fleet managers, die bij Felyx de ‘service agents’ vormen en die gebruik maken van een eigen front-end als operationeel systeem. Hier zijn bijvoorbeeld ook service tickets terug te vinden, waarin de staat van onderhoud van zowel e-scooter als accu wordt bijgehouden.
Als laatste noemt Stroosnier externe databronnen. “Je kunt je voorstellen dat weersinformatie voor ons belangrijk is. Bij slecht weer worden er nu eenmaal minder kilometers gemaakt. Ook marktinformatie over onze concurrenten wordt in onze database opgeslagen. Het is onze taak als database engineers om al deze data toegankelijk te maken en ervoor te zorgen dat er zo weinig mogelijk menselijke input nodig is en zoveel mogelijk automatisering. Daarvoor is het belangrijk om al deze data te verzamelen, en vooral om te zorgen voor een goede data-infrastructuur.”
Van legacy naar state-of-the-art
De oorspronkelijke data-infrastructuur is voornamelijk organisch gegroeid. “Voordat ik bij Felyx kwam, was er een student die de hele datawarehouse en bijbehorende infrastructuur in zijn eentje had opgezet”, vertelt Data Engineer Mees Strooker. “Hij heeft een geweldige prestatie verricht, maar uiteindelijk was deze structuur niet houdbaar en moesten we vrijwel opnieuw beginnen.” Voor elke strategische en operationele behoefte werd een applicatie gemaakt, wat uiteindelijk leidde tot een ondoordringbaar kluwen aan applicaties. Een van de grootste problemen bleek uiteindelijk de schaalbaarheid van de PostgreSQL database, wat vooral te merken was aan de afgenomen prestaties. “Dat betekende veel tijdverlies en onderhoud, en ook analytische queries begonnen traag te worden.”
Legacy
De oude situatie bestond uit ETL-processen die op drie manieren data te verwerken kregen
•Via 3rd party API’s
•Via OLTP-snapshots
•Via de event queue
De ETL-processen werden gehost op Heroku, dat werkt met geïsoleerde containers, ‘dyno’s’ genaamd, die op een niet echt handige manier schaalbaar zijn. Horizontaal is niet zo’n probleem, doordat gewoon extra containers kunnen worden toegevoegd. Verticaal is lastiger, want wanneer meer resources nodig zijn voor een specifieke dyno, dan kan het gebeuren dat een hele groep tegelijk moet worden opgewaardeerd, wat hogere kosten dan eigenlijk noodzakelijk met zich meebrengt. Ook waren er problemen met de event queue wanneer er een event schema change plaatsvond.
De debugging en fault trapping was slecht gedocumenteerd en elke aanpassing die werd gedaan, was direct op de live data. Het gevolg was dat wanneer er iets fout ging, het niet mogelijk was om terug te gaan, want de source data was weg. Ook vond er geen validatie plaats van de data die voor analyse werd doorgegeven.
Nieuwe situatie
Felyx besloot om de hele datastuctuur om te gooien en definieerde daarvoor een aantal essentiële uitgangspunten:
•Schaalbaarheid en elasticiteit
•Verandering is de enige constante
•Unix-filosofie
•Verbeterde debugging-mogelijkheden
“In de praktijk betekent dit dat we bij elke tool die we willen inzetten ons afvragen ‘kunnen we eventueel nog terug?’”, vertelt Strooker. “En wat betreft de Unix-filosofie werkten we met een proof of concept of een minimum viable product voor elke module, zodat we uiteindelijk de keuze hadden tussen twee of drie opties.” Het resultaat is dat er verschillende technologieën allemaal samenwerken, waarbij vooral de betere documentatie veel tijd bespaart als er iets mis lijkt te gaan.
Wat betekent dit in de praktijk? De ruwe data wordt opgeslagen in verschillende cloud buckets:
Streaming event data in Avro-format
OLTP database-snapshots in CSV
3rd party API-calls in JSON
De event-data wordt verwerkt in een continue Kubernetes pod, de snapshots en 3rd party API-calls worden verwerkt via Airflow.
Uiteindelijk komt de data in het Snowflake warehouse terecht waarbij de validatie wordt gedaan door Apache Beam. Het schema wordt beheerd door Liquibase.
“Apache Beam maakt het mogelijk om veel data af te handelen en te valideren. Liquibase stelt ons in staat om schemas incrementeel te wijzigen zonder dat er iets stuk gaat in de data.”
Data model
Felyx heeft een datamodel met veel lagen. Niet alleen om de kwaliteit van de data te waarborgen, maar ook om de data zodanig te formateren dat de data analists en scientists er gemakkelijk mee kunnen werken. “Ze kunnen zelf relationele tabellen maken”, legt Strooker uit. “Voor ons warehouse hebben we verschillende opties bekeken. Een daarvan was een data vault, maar dat bleek vanuit technisch oogpunt overkill.”
Uiteindelijk kozen de data engineers voor 3rd normal form with history. “Hiermee kunnen we verrijkte lagen maken boven op de genormaliseerde tabellen.” Strooker benadrukt dat elke keuze een compromis is. “En we zijn er niet zeker van of we de beste oplossing gekozen hebben. Maar het belangrijkste is dat wanneer we switchen het mogelijk is om de hele datastructuur opnieuw op te bouwen, omdat we de juiste tooling daarvoor hebben.”
Data processing
Voor het uiteindelijke verwerken van de data in bruikbare informatie, gebruikt Felyx Data Build Tool voor het beheren van verrijkte datamodellen en het updaten van data marts. Data analysts kunnen daardoor gemakkelijk een deel van de taken van de data engineers overnemen, omdat ze daarbij met eenvoudige SQL statements kunnen werken. Version control, testing en herbruikbare code in de vorm van macro’s komen zo in het domein van de analisten.
Wat er achter DBT gebeurt is net zo belangrijk, zegt Strooker. “Je maakt met behulp van eenvoudige SQL statements een transformatiepijplijn voor de data. Je kunt vanuit deze SQL code direct documentatie laten genereren, zodat iedereen begrijpt wat de code doet.” Bovendien biedt DBT verschillende materialisatiestrategieën, waaronder tabellen, views, en ephemeral data in de vorm van CTE’s. “Ook incremental is mogelijk, waarbij je met behulp van DBT kijkt of er nieuwe data is die aan de query voldoet, zonder dat de hele dataset opnieuw moet worden opgebouwd.”
Eindgebruikers
Waar gaat al die data, genormaliseerd en verrijkt, uiteindelijk heen? De eindgebruikers, vanuit het standpunt van de data engineers, zijn te verdelen in drie groepen.
•Analytics translators – zij gebruiken Metabase voor descriptive en diagnostics analysis
•Analytics engineers – custom dashboards in RShiny en Dash, eveneens voor descriptive en diagnostics analysis
•Data scientists – gebruiken ML modellen voor predictive en prescriptive analysis
Eindresultaat
Dankzij de hele operatie ziet het datalandschap van Felyx er nu heel anders uit. “Ons belangrijkste doel was flexibiliteit”, zegt Strooker, “en dat is zeker gelukt.” Met de nu gekozen tools is change management mogelijk, en kunnen nieuwe data domains worden toegevoegd en ingeladen. “De truc is het intensieve gebruik van templates, zoals Apache Airflow DAG’s, DBT modellen en Helm charts.” Hierdoor kan Felyx flexibel schakelen tussen verschillende environments en dynamisch gebruik maken van scripts.
Schema management wordt afgehandeld door Liquibase, waardoor het hele datamodel veilig kan worden aangepast wanneer nodig. En tot slot, maakt Felyx gebruik van Snowflake zero copy cloning. Daarmee kan worden getest met een kloonversie van de database, die na gebruik gewoon kan worden verwijderd. Deze blijkt erg effectief voor de CI/CD pipeline.
