Een GDPR-dataflow: van uurlijkse polling naar event-driven PII re-identificatie

Dit is een herkenbare situatie voor enterprise-datateams: een analyseteam vraagt het datateam om gehashte persoons-ID’s voor een goedgekeurde downstreamtoepassing naar hun oorspronkelijke waarden terug te brengen, binnen het GDPR-goedkeuringsproces.

Ik nam deze gecontroleerde re-identificatieworkflow over en ontwierp haar opnieuw. De bestaande oplossing werkte, maar had twee praktische problemen: zij was traag en duur.

Probleem

Persoons-ID’s in het data lake waren standaard gehasht. Gebruikers konden records met stabiele identifiers koppelen zonder de originelen te zien; enkele goedgekeurde gevallen moesten het originele ID via een afzonderlijk opgeslagen mapping herstellen. Dit artikel noemt dat gecontroleerde re-identificatie.

Na voorafgaande goedkeuring uploadde een analyseteam een bestand. Airflow scande de geconfigureerde locaties eenmaal per uur, controleerde de goedkeuring en startte een Spark-job op een dedicated EMR-cluster.

De workflow gebruikte zowel een always-on EMR-cluster als een always-on Amazon Aurora-database. Na verwerking moest de gebruiker het resultaat downloaden en handmatig naar het doelsysteem uploaden.

goedgekeurd verzoek
→ bestand uploaden
→ wachten op de uurlijkse Airflow-scan
→ goedkeuring controleren
→ Spark op always-on EMR
→ resultaat downloaden
→ handmatig naar het doelsysteem uploaden

Een verzoek duurde typisch circa twee uur. Polling, batchverwerking en de handmatige overdracht veroorzaakten de vertraging. Dat was het trage deel.

Tegelijk betaalde deze kleine, incidentele workload permanent voor een always-on EMR-cluster en Aurora-database. Dat was het dure deel.

Analyse van de hoofdoorzaak

1. De AWS-migratie nam de denkwijze van het on-premises data lake mee.

Nadat het platform van lokale servers naar AWS was verhuisd, bleef de architectuur standaard rond permanent draaiende servers gebouwd. Langdurige services en incidentele jobs werden niet verschillend behandeld. Aurora bleef online voor workflowstatus, terwijl een EMR-cluster standby stond voor bestanden die slechts af en toe arriveerden. AWS bood event-driven en pay-per-use diensten, maar de workload werkte nog als een on-premises datacenter.

2. Het team paste nieuwe requirements in de bestaande oplossing.

De werkelijke requirement was: “Wanneer een goedgekeurd bestand arriveert, controleer de autorisatie, verwerk het bestand en lever het resultaat.” Het ontwerp begon echter bij wat al beschikbaar was—Airflow, EMR en een relationele database—en paste de requirement daarin. Een proces dat van nature door bestandsaankomst werd getriggerd, werd Airflow-polling; een korte berekening werd een permanent cluster dat op werk wachtte.

Daardoor volgde de architectuur de bestaande tools in plaats van de trigger, frequentie en levenscyclus van de workload.

Ontwerpaanpak

1. Vervang pull door push om latency te verkorten.

De oorspronkelijke Airflow-schedule vroeg herhaaldelijk of een bestand was aangekomen: een pullmodel. Het pollinginterval werd daardoor onvermijdelijke wachttijd. Ik draaide de richting om. Zodra een bestand S3 bereikte, pushte een event het naar de verwerkingsworkflow, zodat het werk bij aankomst begon in plaats van bij de volgende scan.

2. Gebruik serverless om vaste kosten bij een low-volume workload te verwijderen.

Het bedrijfsmodel was eenvoudig: verzoeken kwamen weinig voor en iedere run was kort, waardoor usage-based kosten al laag waren. De meeste kosten kwamen van always-on Aurora en standby EMR-capaciteit. Met Lambda, Step Functions, DynamoDB en EMR Serverless draaiden er vrijwel geen resources zonder verzoek. Bij dit lage volume vielen de meeste serverless calls binnen de AWS free tier.

Oplossing

Ik bouwde het proces opnieuw rond de aankomst van het bestand:

S3 Object Created Event
→ Lambda start Step Functions
→ Lambda controleert goedkeuring in DynamoDB
→ EMR Serverless voert de re-identificatie uit
→ Lambda levert aan de goedgekeurde bestemming
→ statusmelding bij iedere stap

Het S3-event verwijderde de wachttijd. Step Functions maakte toestanden en fouten expliciet. DynamoDB verving de relationele database voor dit smalle toegangspatroon. EMR Serverless verving het dedicated cluster. Een laatste Lambda leverde het resultaat direct aan bijvoorbeeld een goedgekeurde SFTP-bestemming.

De verantwoordelijke eigenaar kreeg meldingen bij detectie, goedkeuring of afwijzing, verwerking en downstream delivery. Sneller betekende dus niet minder controle.

Kleine tip: stuur bij iedere stap een receipt-email. Bij iedere belangrijke statusovergang gebruikte ik Amazon SNS om stakeholders een ontvangstbevestiging te sturen. Gebruikers hoefden niet meer te raden of het bestand was gevonden, goedgekeurd, verwerkt of afgeleverd. Bij een fout maakte de laatste succesvolle receipt direct duidelijk tussen welke twee stappen het probleem zat. De implementatie kostte weinig en verbeterde zowel de gebruikerservaring als troubleshooting merkbaar.

Resultaten

De typische latency daalde van circa twee uur naar 5–10 minuten. Dit is een geobserveerd bereik, geen formele SLA met een afzonderlijk meetsysteem.

De identificeerbare AWS-resourcekosten binnen de bredere factuur daalden met circa 90%. De vergelijking werd door billing ondersteund, maar betekent niet dat de totale AWS-rekening 90% lager werd.

Ook de workflow zelf veranderde:

• geen uurlijkse polling;
• geen always-on EMR-cluster;
• geen always-on Aurora voor een smal lookup-patroon;
• geen handmatige downstream overdracht;
• expliciete approval checks en statusmeldingen;
• hoofdzakelijk betalen wanneer een goedgekeurd verzoek werkelijk draait.

De kern was de levensduur van resources gelijk te maken aan die van één goedgekeurd verzoek: een incidenteel bestand wachtte niet langer op een permanent systeem, maar activeerde een expliciet proces met governed states, rechten en meldingen.