Als het doel is om een functioneel alternatief te voorzien voor gevoelige data, zijn tools voor de creatie van synthetische data bij uitstek geschikt. Ze kunnen immers meer dan enkel de bestaande gegevens door elkaar gooien: ze zijn gemaakt om de structuur van gegevens aan te leren, waarna je willekeurig veel nieuwe gegevens volgens dezelfde structuur kan aanmaken. In combinatie met generatoren voor totaal fictieve gegevens, hebben we daarmee alles voorhanden om niet alleen de originele gegevens te verbergen, maar ook om te zorgen dat wat in de plaats komt, realistisch oogt.

Dat betekent echter niet dat het een kwestie is van een druk op de knop. Eén en ander hangt af van allerlei randvoorwaarden en aannames over de inhoud en structuur van de gegevens. Afhankelijk van de beoogde toepassing of het doel, kan het nodig zijn om extra beperkingen en filters op te leggen, of misschien net om bepaalde delen van de gegevens buiten beschouwing te laten. In dit artikel kijken we vooral naar die praktische bekommernissen: wat kom je zoal tegen als data professional die synthetische data moet aanmaken?

Setup

Wie een dataset wil scramblen, heeft uiteraard toegang nodig tot de originele gegevens. Het spreekt voor zich dat het uploaden van gevoelige data naar een cloud service of zelfs het gebruik van een Docker container voorzien door een derde partij, slechts mogelijk is als er grondig is nagedacht over GDPR-compliance, eventueel een Data Protection Impact Assessments (DPIA) is opgesteld, en best ook met de DPO is overlegd. We doen zelf geen enkele uitspraak over de geschiktheid van eender welke tool vis-à-vis de GDPR-wetgeving. Voor al wat volgt gaan we ervan uit dat we werken met tabulaire, tekstuele of numerieke gegevens, die lokaal beschikbaar zijn – met andere woorden, een grote spreadsheet.

De markt

In een vorig artikel vermeldden we al enkele spelers vanuit de optiek van AI-projecten en software testing. Hier ligt onze focus meer op de privacybescherming en data science. Voor het analyseren en synthetiseren van tabulaire gegevens is er een heel sterk groeiende markt. Enkele interessante spelers zijn de volgende – en er zijn er ongetwijfeld nog veel meer:

• Mostly.ai
• YData
• Tonic
• Gretel
• Synthesized.io

Open source tools zijn er minder en zijn vaak afkomstig van projecten die op universiteiten zijn begonnen. Benerator vermelden we apart omdat deze al langer bestaat en ook een uitgebreid commercieel aanbod heeft. Jongere open source initiatieven zijn onder andere:

• Synthetic Data Vault (SDV)
• Mimesis
• Synthia
• Data Responsibly‘s DataSynthesizer
• MITRE’s Synthea / SyntheticMass (toegespitst op eHealth)

SDV is momenteel de populairste van de open source tools, en we gebruiken deze voor al wat volgt. In onze Quick Review vind je meer uitleg over deze tool.

Het stappenplan

Het plan van aanpak om synthetische data te produceren is bij de meeste tools heel gelijkaardig. We kunnen het onderverdelen in 6 grote stappen:

1. Upload en inlezen van de gegevens. Met name de tekst-encodering kan hier wel eens voor problemen zorgen als de gegevens uit oudere bronnen afkomstig zijn. Problemen hiermee moeten opgelost worden voordat men aan de volgende stappen begint.
2. Analyse en typering van de gegevens. Voor elke kolom: welke zijn de minima, maxima, de waarden die voorkomen, zijn er missende waarden, etc. Omdat de computer niet weet wat de achterliggende betekenis van de gegevens is, is het vaak nodig om in deze stap manueel correcties uit te voeren:
   • Niet alle getalwaarden kan je zomaar beschouwen als “hoeveelheden” die je vrij kan optellen of aftrekken. Sommige zijn categoriën, zoals NACE codes of postcodes, andere zijn misschien onderdeel van een datum.
   • Ontbrekende gegevens zal je in sommige gevallen kunnen gelijkstellen met 0 of met een reeds aanwezige default categorie, maar vaak wil je ze misschien beschouwen als een klasse apart. Een ontbrekende geboortedatum wilt immers niet zeggen dat iemand geboren is in het jaar 0.
3. Transformatie van gegevens. Hierbij worden o.a. ontbrekende gegevens afgesplitst, of categorische variabelen omgezet in een getal-encodering om compacter voorgesteld te worden. Deze stap gebeurt vooral achter de schermen, maar het is vaak mogelijk om manueel configuratie-opties toe te voegen: van sommige kolommen willen we bijvoorbeeld forceren dat de waarden altijd uniek zijn, andere kolommen willen we misschien negeren.
4. Een generatief model trainen. Dit kunnen zowel “klassieke” statistische modellen zijn als deep-learning varianten. Sommige modellen zijn enigszins in staat om diepere verbanden tussen de gegevens te reproduceren, maar dit blijft erg afhankelijk van de hoeveelheid gegevens en hun distributie.
5. Genereren van nieuwe gegevens. Bij gebruik van een generatief model staat er in principe geen limiet op de hoeveelheid gegevens die aangemaakt kan worden.
6. Evalueren en visualiseren van de resultaten. De meeste commerciële tools genereren een mooi eindrapport met daarin een verslag van het hele proces en enkele samenvattende grafieken die toelaten om in een oogopslag te zien of er anomalieën zijn, en of er nog andere correcties toegevoegd dienen te worden. Bij open-source tools is dat vaak beperkt tot enkele metrieken en moet je verdere gegevensanalyse zelf bijprogrammeren.

Gegevens

Wie de tools liefst niet uittest op eigen (gevoelige) data, vindt veel datasets op Kaggle. Zelf maakten we voor onze testen onder andere gebruik van een variant op de Adult Census Income dataset.

Praktische bekommernissen

Telgegevens

Sommige datasets bevatten tellingen. Dat kan het resultaat zijn van een COUNT() functie in de SQL-query voor data-extractie. Om dan een correcte inschatting te kunnen maken van de distributies van de andere variabelen, is het nodig om deze telling ongedaan te maken en de tabel te “unrollen”. Een nieuw gegenereerde tabel moet nadien natuurlijk terug “opgeteld” worden om terug in het originele formaat te staan. Op deze manier kan men desgewenst ook garanderen dat de resulterende tabel ook effectief hetzelfde aantal records voorstelt als in de originele database, zelfs al is er een ander aantal combinaties van variabelen. De kolom met de telvariabele wordt uiteraard niet meegenomen in het generatief model.

Behoud van alle mogelijkheden

Voor sommige toepassingen kan het nodig zijn dat een gesynthetiseerde dataset zeker ook alle mogelijke waarden bevat die voorkomen in de originele dataset – bij wijze van representativiteit voor de originele dataset. Maar met name als bepaalde waarden erg zeldzaam zijn, bestaat er een reëel risico dat ze niet genoeg doorwegen bij de training van het generatief model, waardoor ze achteraf bijna nooit gegenereerd worden. De meeste generatieve modellen laten het conditioneel samplen van gegevens toe: datapunten kunnen gegenereerd worden waarvoor de waarde van een of meerdere variabelen vaststaan. De distributie van de andere waarden volgt dan een conditionele distributie, gegeven deze vaste waarden. Doe dat voor elke waarde die voorkomt in de originele dataset, en men kan garanderen dat elke waarde (alleszins onafhankelijk) voorkomt. Dit vraagt weliswaar wat extra programmeerwerk om gedaan te krijgen, en bovendien impliceert dit ook dat een outputdataset een bepaalde minimumgrootte zal hebben.

Duplicaten en overlap

Het genereren van nieuwe gegevens gebeurt door te samplen uit een generatief model – te vergelijken met het trekken van een lottocombinatie. Zeker als er veel gegevens worden gesynthetiseerd, is het altijd mogelijk dat er twee keer hetzelfde tussenzit. Is dat ongewenst, dan moet een optie toegevoegd worden om duplicaten te verwijderen – en nadien opnieuw gegevens bij te genereren totdat de gewenste grootte opnieuw is bereikt. Eventueel kan men ook forceren dat gesynthetiseerde gegevens zeker niet mogen voorkomen in de originele dataset – dat de twee datasets dus volledig disjunct zijn. Dat laatste voegt echter weinig toe qua privacybescherming: zonder kennis van de originele dataset, kan men steeds bogen op een zekere plausible deniability dat een synthetisch record identiek zou zijn aan een record uit de echte dataset.

Trainingstijd

Zeker bij grote datasets met veel variabelen, en bij gebruik van deep learning tools kan het een lange tijd in beslag nemen om een generatief model te trainen. Dat maakt het moeilijk om iteratief te werk te gaan bij het verfijnen van de opties. Het kan nuttig zijn om tijdens de ontwikkeling, de dataset ten grondslag van de training te beperken tot enkele duizenden willekeurig geselecteerde records. Daarbij mogen we al wat hierboven al werd vermeld natuurlijk niet uit het oog verliezen – bijvoorbeeld, ook hier kan het nuttig zijn om een extra optie te hebben die garandeert dat een selectie uit de trainingset nog steeds minstens 1 datapunt bevat voor elke waarde van elke variabele.

Afhankelijke kolommen

Een kolom die volledig (lineair) afhankelijk is van een of meerdere andere kolommen, moeten we verwijderen en achteraf terug herberekenen. Dat is typisch het geval bij wiskundige afhankelijkheden: een kolom die een som is van twee andere kolommen, of een percentage van een andere kolom voorstelt. We kunnen best niet hopen dat een generatief model dat verband zelf aanleert. Het is veel zekerder om zulke afhankelijke kolommen gewoon te verwijderen uit de dataset, en nadat een nieuwe dataset is gegenereerd, deze kolommen terug te berekenen op basis van de gesynthetiseerde data en dan pas toe te voegen.

Constraints

Iemands geboortedatum valt altijd vroeger dan iemands sterfdatum. Dat is logisch, maar als men voor een fictief persoon een nieuwe geboortedatum en sterfdatum genereert uit het generatief model dat werd getraind op de distributies van alle geboorte- en sterfdata in een dataset, dan kan het voorvallen dat deze logische beperking niet altijd gerespecteerd blijft. Het kunnen opleggen van constraints – de ene variabele is altijd groter of kleiner dan een andere, of altijd positief of negatief, etc. – is een belangrijke feature. Eenvoudige beperkingen, zoals zonet aangehaald, zijn eventueel nog eenvoudig te implementeren door “rejection sampling”: voldoet een gesynthetiseerd record niet aan alle constraints, wordt het gedeleted en wordt een nieuw gegenereerd, totdat alle records voldoen. Worden de constraints ingewikkelder of strikter, dan kan het nodig zijn om zelf de nodige filters te programmeren, of om een post-processing stap te definiëren waarin correcties uitgevoerd kunnen worden.

Kolommen bevriezen

Willen we een dataset scramblen met een kolom geslacht en een kolom woonplaats, dan is het eigenlijk voldoende om enkel de kolom met woonplaatsen door elkaar te husselen om een goed gemengde dataset te bekomen. Het geslacht is daar onafhankelijk van, en kunnen we even goed negeren. Het bevriezen van kolommen, in feite gewoon het verwijderen voor de verwerking en terug eraan plakken na het einde, kan zo een grote tijdswinst opleveren. Het is weeral een kolom minder waarvan de distributie aangeleerd moet worden. 

Kolommen bevriezen, impliceert weliswaar een voorwaarde: ofwel dat de gesynthetiseerde dataset even lang moet zijn als de originele zodat de dimensies overeenkomen, ofwel dat de gegevens in de bevroren kolom(men) helemaal willekeurig verdeeld zijn, dus op geen enkele manier gesorteerd of gegroepeerd, zodat de bevroren kolom(men) zonder effect op de gegevensdistributie kunnen verkort of verlengd worden. Dat laatste kan echter moeilijk te bewijzen zijn.

Maar zeker als het de bedoeling is dat een gesynthetiseerde dataset even groot is als de originele, wat toch vaak voorkomt, is het een enorm grote tijdswinst als van een dataset met 60 kolommen, er slechts 6 moeten gesynthetiseerd worden om een voldoende gescramblede dataset te krijgen. Bovendien zal een generatief model met minder kolommen meestal ook accurater getraind kunnen worden, dus is het resultaat waarschijnlijk zelfs kwalitatief beter. Eventueel kan de synthetische dataset achteraf nog eens geshuffled worden om enige overgebleven structurele gelijkenis met de originele dataset te verbergen. 

Rapportering en grafieken

De gescramblede dataset moet nog vergeleken worden met het origineel, om te verifiëren dat de procedure wel goed verlopen is en of er bepaalde parameters beter aangepast zouden kunnen worden. Het visualiseren van datasets is een uitdaging op zich, waarbij rekening moet worden gehouden met het type van variabele en de waarden die ze kan aannemen. Boxplots zijn vaak een goede keuze voor continue variabelen, en staafdiagrammen voor categorische variabelen. Daarbij moet aandacht worden besteed aan de assen, die overeen moeten komen om in een oogopslag te kunnen vergelijken. Het kan nodig zijn hier en daar extra te groeperen of aggregeren om grafieken van complexe categorische variabelen overzichtelijk te houden. Voor de verbanden tussen twee variabelen kan men verschillende vormen van bivariate plots, heatmaps en correlatiematrices benutten. Werkt men in Python dan zijn matplotlib en seaborn nuttige grafische libraries.

Conclusie

Met synthetische data generatoren hebben we een krachtige tool in handen om data scrambling te kunnen doen. We kunnen er bovendien meer mee dan enkel de gegevens door elkaar haspelen: desgewenst interpoleren ze ook tussen minimum- en maximumwaarden, of tussen datums, en zo kunnen ze ook fictieve gegevens genereren volgens dezelfde structuur als de originele dataset. Het aanmaken van een echt goede synthetische dataset vergt vaak een iteratieve aanpak, om het achterliggend generatief model te finetunen.

We merken in de praktijk dat er heel wat extra checks en balances komen kijken bij het werken met echte datasets. Het is zelden zo dat een generatief model gegenereerd uit een willekeurige dataset met default parameters, vanaf de eerste keer optimaal is. Met name erg ongelijke distributies zorgen voor problemen in het leerproces en voor statistische instabiliteit in het resulterende generatief model. Bij wijze van voorbeeld: als een dataset slechts 1 persoon bevat met een zeldzame ziekte, en het is toevallig een 43-jarige Limburger, dan riskeren we dat het systeem leert dat alle personen met deze ziekte per definitie 43-jarige Limburgers moeten zijn. Bovendien merken we dat we de beste resultaten bekomen als een dataset weinig variabelen heeft, en voor elke waarde van elke variabele veel datapunten (rijen, samples). Dit alles maakt dat we de beste resultaten vaak bekomen door zoveel mogelijk kolommen te bevriezen, en het aantal te scramblen kolommen te beperken tot het minimum noodzakelijke om het doel van scrambling te bereiken. Die oefening kan voor elke dataset anders zijn.

Een vraag die regelmatig terugkomt is: kunnen we dezelfde analytics op de dusdanig gescramblede / gesynthetiseerde dataset loslaten en leidt dat dan tot dezelfde conclusies? Het antwoord is: het hangt ervan af hoe diep je wilt gaan. De structuur van de gegevens wordt in het generatief model immers approximatief aangeleerd. Daarbij merken we:

• De statistieken en verdeling van individuele variabelen (minimum, maximum, gemiddelde etc.) blijven meestal relatief goed behouden,
• De verbanden tussen twee variabelen (correlatie etc.) blijven matig behouden, en hoe gelijkmatiger en stabieler deze variabelen zijn verdeeld hoe beter dat dat lukt,
• De verbanden tussen meerdere variabelen (regressies etc.) blijven relatief slecht behouden of gaan verloren.

Voor complexe analyses zijn scrambled of synthetische data dus zeker geen drop-in replacement voor de echte data. Ze zijn wel erg nuttig voor het testen of ontwikkelen van data processing scripts of analyse-pipelines, omdat we wel een goed beeld hebben van welke waarden er allemaal voorkomen en in welk bereik deze vallen.

We hebben nog heel wat andere potentiële struikelblokken die we in de praktijk kunnen tegenkomen niet besproken. Er kunnen afhankelijkheden bestaan tussen rijen – bijvoorbeeld, een tabel die verschillende records bevat per persoon. Er kunnen ook verbanden zijn in de tijd – bijvoorbeeld datasets die bestaan uit opeenvolgende kwartalen, of datasets waarin de datums die voorkomen alleen maar werkdagen zijn en nooit weekenddagen, wat maakt dat je niet zomaar eender welke datum kan synthetiseren. Een dataset kan ook bestaan uit meerdere tabellen die met elkaar verbonden zijn. Zulke complexere problemen zijn mogelijk nog voer voor een vervolg-artikel later dit jaar.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Kennis en informatie in een bedrijfsorganisatorische context is doorgaans verspreid over databases, rekenbladen, documenten, etc. Daarnaast bezitten kenniswerkers ook domeinexpertise die niet in een systeem wordt opgeslagen. Maar wat als men die kennis en informatie wenst te integreren om, bijvoorbeeld, processen te automatiseren of nieuwe inzichten te verwerven? Knowledge graphs bieden hiervoor een oplossing.

In deze webinar werpt Christophe Debruyne zijn licht op het concept van de knowledge graphs en hun mogelijkheden. Hij behandelt daarvoor de volgende topics:

– Wat is een knowledge graph – Knowledge graphs versus andere initiatieven – Knowledge graphs versus andere AI technieken – Toepassingsgebied van knowledge graphs – Bouwen en onderhouden van een knowledge graph

Dans le contexte organisationnel d’une entreprise, les connaissances et les informations sont généralement réparties dans des bases de données, des tableurs, des documents, etc. Parallèlement, les travailleurs de la connaissance possèdent une expertise de domaine qui n’est pas stockée dans un système. Mais que faire dès lors si l’on souhaite intégrer ces connaissances et informations pour, par exemple automatiser des processus ou acquérir de nouvelles connaissances ? Les knowledge graphs offrent une solution à cet égard.

Dans ce webinaire, Christophe Debruyne fait la lumière sur le concept des graphes de connaissances et leurs possibilités. Il aborde les topics suivants :

– Qu’est-ce qu’un knowledge graph – Positionnement des knowledge graphs face à d’autres initiatives – Positionnement des knowledge graphs face à d’autres techniques d’IA – Domaine d’application des knowledge graphs – Construction et maintenance d’un knowledge graph

Recording

Presentation

Er was eens… een metrorit. En voor metroritten heb je tegenwoordig een MOBIB-kaart nodig. Dit deed me terugdenken aan het verhaal van de smartcards, en hoe we er veel te veel nodig hebben… Bij deze dan het lang beloofde derde deel van dat verhaal.

Over Metro- en Treinkaarten

Onlangs moest ik na lange tijd nog eens de metro nemen. Ik wist dat mijn papieren kaartje met magneetstrip ondertussen niet meer geldig zou zijn: de overschakeling naar MOBIB is nu volledig doorgevoerd. De MOBIB-kaart is RFID technologie, waardoor je ze kan gebruiken door ze gewoon tegen een kaartlezer tegen te houden (je hoeft ze nergens in te steken). Meer over deze technologie kan je terugvinden in één van onze techno’s: Het ABC van RFID.

Nu, ik heb reeds een treinabonnement, en ook dit staat op een MOBIB-kaart… van de NMBS. Ik moest er dus achter zien te komen of ik deze ook voor de metro kon gebruiken. Na wat zoekwerk, zag ik dat ik online een account kon aanmaken bij de MIVB en dat ik een bestaande MOBIB-kaart kon koppelen aan mijn account. Wanneer ik dit echter probeerde, wist het systeem mij te vertellen dat mijn kaart niet gekend was, maar dat dit wel het geval zou zijn indien ik deze eerst kon opladen via één van de GO-machines in de metrostations.

Zo gezegd zo gedaan, en – wonder boven wonder? – dit werkte inderdaad zoals aangegeven: ik kon mijn NMBS-kaart gebruiken als houder voor het saldo van mijn metroritten, en ik kon deze kaart daarna ook effectief koppelen aan mijn online profiel bij MIVB. (Eén mankement: het resterend saldo aan ritten is niet zichtbaar; maar misschien is dit ook voor de eigen kaarten van MIVB geen feature? – graag een comment indien iemand dit weet!)

Wat leren we nu uit dit verhaal?

• Ten eerste, de technologische mogelijkheden om het probleem van het teveel aan kaarten in mijn portefeuille op te lossen, zijn reeds duidelijk aanwezig, maar, gezien het aantal kaarten dat ik nog nodig heb, is er nog geen verregaande implementatie gebeurd (zo is mijn abonnement bij De Lijn, verkregen via NMBS, nog steeds een stukje papier, en een koppeling met bijvoorbeeld de Belgische eID is nog steeds beperkt tot de occasionele online aankoop van een treinticket). Conclusie: nog steeds geen one card to rule them all…
• Ten tweede: de netwerken van MIVB en NMBS zijn voorlopig nog onvoldoende geïntegreerd om reeds bij de aanmaak van een nieuwe kaart bij één firma, rechtstreeks ook de nodige gegevens te versturen aan de andere. Op zich is dit soort integratie misschien nogal veeleisend, maar in deze nieuwe wereld van de IT, met zijn Cloud, zijn microservices, en vooral, zijn API economy, zijn er toch wel een aantal architecturen te bedenken waarin dit geen probleem zou mogen zijn. Het “only once principe” is echter vaak meer een verhaal van politiek en economie, dan van technologie.

“Card Management as a Service”

Ik zou hier graag reeds even vooruitblikken op een toekomstige blog, waarin ik de voordelen van een gescheiden beheer van gegevensnetwerken versus er van gebruik makende toepassingen wil toelichten: Stel dat we één instelling hadden die het beheer van de kaarten en de ermee gepaard gaande gegevens, netwerken en basisdiensten op zich nam, en dat de andere bedrijven, zoals de vervoersmaatschappijen in kwestie, van deze diensten gebruik maakten. Dit zou ervoor zorgen dat alles wat met kaarten te maken had, efficiënter zou kunnen worden gemaakt wegens schaalvoordelen, én dat de vervoersmaatschappijen zelf deze verantwoordelijkheid niet meer hoefden te dragen. Dit is eigenlijk precies één van de belangrijke verwezenlijkingen van Cloud, en, meer in het bijzonder, het “as a Service” verhaal, maar dan toegepast op chipkaarten. Daarnaast kan men het ook bekijken in een microservices en API context (“you build it, you run it”).

Hierover dus later meer. Waar ik het nu verder over wil hebben is de toekomst…

De Nabije Toekomst?

Vandaag is het reeds mogelijk om met je smartphone vervoersbewijzen aan te kopen, betalingen te doen, ja, zelfs jezelf te identificeren voor gebruik van overheidstoepassingen. Een toekomst waarin we geen kaarten meer nodig hebben, maar waarin deze volledig zijn vervangen door de smartphone, is dus zeker technisch realiseerbaar, en op lange termijn misschien zelfs realistisch. Het belangrijkste probleem hierbij is er één dat slechts langzaamaan kan worden opgelost: de logistiek van het on-boarden van alles en iedereen die nu nog met kaarten werkt, en van alles en iedereen die nu nog geen smartphone heeft. In een nog verdere toekomst zullen we misschien zelfs de portefeuille in zijn geheel kunnen afschaffen, indien we dit ook met het systeem van cash geld zouden doen!

Science Fiction

Wat als we dan nog eens een paar decennia verder in de toekomst kijken? We zien reeds nu zaken opduiken als bio-authentication, waarbij we onze vingerafdrukken, stem, gezicht, of zelfs context gebruiken om te authenticeren. Daarnaast doet men ook gericht onderzoek naar nanotechnologie, robotica, artificiële intelligentie, Internet of Things, … Allemaal zaken die ervoor zorgen dat technologie en ons lichaam steeds dichter bij elkaar komen en uiteindelijk zelfs kunnen worden samengevoegd.

Uiteindelijk zou het dan mogelijk worden dat de smartphone wordt vervangen door een scherm op de huid van onze arm (zie filmpje hierboven voor wat binnenkort al kan!), met alle nodige technologie netjes verborgen aan de binnenkant van ons lichaam! Sterker nog: het scherm zou evengoed virtueel voor onze ogen kunnen worden getoverd, dankzij technologie rechtstreeks in onze ogen of hersenen. Op die manier hebben we niets meer nodig: al het nodige dragen we steeds met ons mee, zoals we dat met ons lichaam doen. En onszelf identificeren om ons vervoersbewijs te legitimiseren, doen we door eens te wuiven.

Op zich een groot gemak, maar uiteraard is hier ook een duistere zijde aan verbonden: het zou wel eens heel moeilijk kunnen worden om “off-the-grid”, of “offline” te gaan, of om zonder al deze technologische snufjes te kunnen. Sterker nog: we zouden Big Brother scenario’s kunnen krijgen, of een regelrecht doembeeld, zoals in de film “In Time“. Maar goed: wat er met een technologie gedaan wordt, staat los van de technologie zelf (ook met een eenvoudige hamer kan je zowel bouwen als verwonden).

Besluit

Er staan ons nog een aantal wonderlijke technologische evoluties te wachten, maar er blijft vooral nog veel werk aan de winkel wat betreft het vereenvoudigen van het leven van de gewone burger, met al zijn chipkaarten, zijn smartphone en zijn muntjes van twee eurocent, en van alle administratie die daarbij komt kijken. Samenwerking, integratie, en het zo breed mogelijk invoeren van het only once principe zijn de boodschap.

Data Centric IT

De meeste informatici weten wel wat data is, en wat databases zijn, maar zijn toch vooral ‘opgevoed’ met een focus op applicaties, algoritmes, enz. De applicatie is uiteraard erg belangrijk: ze verricht het nuttige werk van een computersysteem. Toch moeten we dit nuanceren. Een applicatie is eigenlijk enkel een hulpmiddel voor het manipuleren van de data. Als we er eens bij stil staan, dan komen we tot de vaststelling dat nagenoeg elke applicatie die we kennen, dient om data uit te lezen, in te voeren, mooi/anders weer te geven of te bewerken. Dit geldt zowel voor eindgebruikersapplicaties als voor applicaties die enkel I/O doen (b.v. de zogenaamde ‘batch’ applicaties). Dus eigenlijk is de data de centrale asset van een IT-systeem!

Dan kunnen we ons de vraag stellen of we hier bij het ontwikkelen van de architectuur van computersystemen niet meer rekening mee zouden moeten houden? We kunnen de data voorop stellen als centrale entiteit bij de communicatie tussen verschillende applicaties en gebruikers, en ook binnen verschillende subsystemen binnen applicaties. Doen we dit consequent, dan evolueren we stilaan naar een Data-Centric aanpak van IT.

REST

REST staat als acroniem voor ‘Representational State Transfer’. Deze wijze van data-overdracht heeft een aantal verschillende eigenschappen, waaronder dat men heel eenvoudig via http(s!) en via gebruik van eenvoudige principes als CRUD (Create – Read – Update – Delete) verschillende systemen kan laten communiceren. Voor de rest ga ik hier niet meer verder over uitweiden in deze blog, behalve één belangrijke eigenschap: een goedgemaakte REST API biedt een zelf-descriptief overzicht op data (zogenaamde resources), en niet op methodes. (Voor een mooie en praktische uitleg over REST, kan ik verwijzen naar stackoverflow en ook naar deze leuke.)

Men kan dit principe nog anders uitleggen: de namen die men aan de functies geeft die men in een REST API (Application Programming Interface) kan oproepen om een resultaat te bekomen, zullen geen werkwoorden zijn, maar naamwoorden. Een voorbeeld maakt dit een stuk duidelijker:

Nemen we een applicatie die als één van haar functionaliteiten een lijst van personen/gebruikers beheert. Het is de bedoeling dat andere applicaties personen kunnen zoeken, opvragen, toevoegen, veranderen en verwijderen. In plaats van op de traditionele manier een programmatorische  API of een SOAP (Simple Object Access Protocol) webservice aan te bieden, openen we via een RESTful webservice een raam op de door de applicatie beheerde gegevens. Dit ziet er dan b.v. als volgt uit:

• “GET www.app.be/rest/user”: geeft alle beheerde personen (meestal geeft men daarbij slechts een beperkt aantal gegevens per persoon)
• “POST /user” (we laten het eerste deel van de url vanaf nu achterwege, dit is altijd hetzelfde): laat toe om de gegevens voor een nieuwe persoon door te sturen.
• “GET /user/100023”: geeft detailgegevens over persoon met volgnummer 100023

Het is dus eigenlijk alsof je rechtstreeks in een hiërarchische structuur van je gegevens alle nodige bewerkingen kan uitvoeren. Uiteraard zal de achterliggende applicatie niet zomaar alles toelaten: ze zal nog steeds verantwoordelijk zijn voor controle op input, en voor authenticatie en autorisatie van de systemen die van de RESTful service gebruik maken. De beveiliging in een dergelijke aanpak gebeurt best volgens de principes van Data-Centric Security, daar deze als van nature in een dergelijke Data-Centric Architecture thuishoren.
Uiteindelijk kan veelvuldig toepassen van RESTful principes om applicaties aan te sturen, leiden tot een mooi Data-Centric Ecosysteem, waar de principes van deze architectuur doorgetrokken zijn over een groot aantal verschillende applicaties: In plaats van elke applicatie nog een aparte url te geven, zal men eerder een algemene url opzetten voor de data binnen de gehele groep samenwerkende applicaties (e.g. ‘data.socialsecurity.be’ zou dit kunnen zijn voor alle applicaties binnen de sociale zekerheid). Vele applicaties samen, elk verantwoordelijk voor hun stukje van de hiërarchie, zullen instaan voor deze ene grote RESTful data API, en alle applicaties zullen er op hun beurt weer gebruik van kunnen maken, zonder dat ze zich iets hoeven aan te trekken van waar de data vandaan komt of naartoe gaat (of door welke applicatie ze wordt beheerd). De applicaties hoeven elkaar op deze manier niet meer te kennen of te adresseren; ze hebben enkel het adres nodig van de data. In een enterprise omgeving zal men typisch gebruik maken van een ‘API management suite‘ om zo’n RESTful API, of groep ervan, te beheren.

Men kan het toepassen van dit principe ook zien als een vorm van Data Virtualization, aangezien men services aanbiedt om de data, die normaal gezien in onderliggende databases zit, virtueel te ontsluiten. Indien men deze architectuur via Cloud-technologie implementeert, kan men het ook zien als een vorm van Data-as-a-Service (DaaS). Wanneer men de data ook aanbiedt aan externe partijen, kan het eventueel gaan om Open Data.

Het doortrekken van deze architectuur over de gehele organisatie, of zelfs over meerdere samenwerkende organisaties, kan sterke synergieën teweeg brengen, doordat de data voor alle applicaties éénvormig beschikbaar wordt, en doordat het gemakkelijker wordt om reeds door RESTful services ontsloten data te gaan hergebruiken vanuit meerdere applicaties. Dit leidt uiteindelijk tot wat men noemt, een bloeiende ‘API economy‘. Uiteraard is een goede governance over de data, een Enterprise Information Model, en een sterk Master Data Management van belang om hiermee echt succesvol te zijn.

Communiceren via REST of via EDA ?

Via RESTful services kan je dus in principe alle applicaties die dit vereisen, met elkaar laten communiceren. Dezelfde mogelijkheden heb ik echter eerder al voorgesteld in de context van Event Driven Architecture (EDA) in twee eerdere blogs (basis en geavanceerd). Je kan je afvragen of dit niet redundant is, of welke van de twee nu de beste oplossing is?

Het antwoord is – je had het allicht zien aankomen – dat beide oplossingen hun plaats hebben in een gedistribueerd ecosysteem. Events werken namelijk typisch asynchroon, terwijl REST synchroon kan worden gebruikt. Dit betekent dat een applicatie onmiddellijk op de hoogte kan worden gebracht, indien er een voor haar interessant Event beschikbaar is. Indien de applicatie echter meer data nodig heeft, die zich niet in een beschikbaar huidig Event bevindt, dan kan het deze gaan opvragen d.m.v. het gebruik van een RESTful service. Het besluit is dus dat we Events kunnen gebruiken om nieuwe gegevens zo snel mogelijk over het netwerk te verspreiden, naar alle belanghebbenden, en dat we RESTful services kunnen gebruiken om reeds gekende informatie universeel ter beschikking te stellen op het netwerk, waar alle geïnteresseerden ze kunnen gaan raadplegen. Een mooi complementair geheel dus – en het goede nieuws is dat de beide benaderingen meestal ondersteund kunnen worden door één en dezelfde onderliggende middleware technologie (typisch, de ‘Enterprise Service Bus‘ (ESB) ).

Besluit

Net zoals REST, passen Events heel goed in een Data-Centric Architectuur: Events, zeker business Events, zijn namelijk ook data, en een belangrijke informatiebron voor Analytics. Samen met REST hebben we dus de twee stukken van de communicatiepuzzel binnen Data-Centric IT volledig in handen.

Dat wisten we dus al – maar wat nu we een tijdje verder zijn, de eerste successen geboekt zijn? Enkele lessen kunnen getrokken worden, nu we dit aan den lijve hebben kunnen ondervinden. We geven ze hier al kort mee; elk van deze deelaspecten kan het onderwerp vormen van aparte blogs, waarin we er telkens wat meer aan besteden …

• men heeft specifieke skills nodig (business analyse, data mining, …) die verder gaan dan deze die nodig zijn voor Data Integration en Statistics;
• men moet rekening houden met evolutie in de modellen, onderliggend aan analytics, en dient dus een model management te voorzien;
• men moet een goed idee hebben van hoe (en met welk personeel) men zal afhandelen (workflow, case management, business processen, …) wat men met analytics detecteert;
• afhankelijk van de behoeften van de business (bv. (near) real-time detectie), is er misschien nood aan specifieke implementatie-architectuur (bv. Complex-event Processing, of moderne BI-architecturen, Data Virtualisatie) bij de koppeling van analytics aan de productiesystemen. Klassieke DWH-gebaseerde architecturen kunnen immers tekort schieten! Veel hangt ook af van de aanwezige Enterprise Architectuur.

Zeker en vast “to be continued”, dus … blijf ons volgen!

(Talend vermeldde ik reeds als DI-onderdeel van open source BI-platformen, deel1 en deel 2, en na recente overname van Sopera, als opkomende EAI-speler die een open source alternatief biedt.)

Hoe doet Talend het, en wat is er zo sterk aan?

In de eerste plaats gaat het om connectiviteit, waarbij de bron en/of het resultaat van de ETL-routines in Hadoop gaat. Tot daar nog niks spectaculairs.
Maar de Talend Integration Suite gaat nog verder, en profiteert van haar mogelijkheid om native Hadoop-code te genereren, waarbij net de transformatie-operaties aan Hadoop gegeven worden om aldus van Hadoops performantie voor Big Data te profiteren.
Dit soort ETL is niet zo bekend, maar heet ELT: “Extract-Load-Transform”, een stokpaardje van Talend.

Merk wel op dat de generatie van Hadoop-code enkel in de Subscription-versie (Talend Integration Suite) vervat zit, niet in de gratis versie (Talend Open Studio). Geen verrassingen hier.

Voor de liefhebbers: lees hier meer.

Conclusie

MapReduce is niet alleen voor Analytics, en Talend is een belangrijke, groeiende speler, die ook Big Data aankan.

Dit is m.i. goed gezien, want vaak zijn de redenen voor het falen van SOA-projecten e.d. (verwachtingen niet ingelost, vertragingen, budget overscheden, …) te vinden in de onderliggende datakwaliteitsproblemen of moeilijkheden op het vlak van data-integratie – naast de beter bekende redenen zoals gebrekkig requirements management en slechte software-kwaliteitscontrole (SQA). Dit zou dus wel eens een vruchtbaar huwelijk kunnen blijken.

U kan er hier meer over lezen.