Leestijd 7 min

Jan Eerdekens

In deze technische blogpost wil ik het hebben over hoe je eenvoudige en flexibele ETL-gebaseerde anonimisering kunt opzetten. Waarom? Wel, ik had onlangs de gelegenheid om een klein proof of concept uit te voeren voor een klant. De klant wilde weten welke opties beschikbaar waren om interne gegevens te nemen, alle persoonlijk identificeerbare informatie (PII) te verwijderen of anonimiseren en deze op een eenvoudige manier en vorm beschikbaar te maken voor externe partijen. Na het verzamelen van verdere vereisten werd de context voor dit proof of concept als volgt gedefinieerd: Welke oplossing dan ook, het moet in staat zijn om gegevens te extraheren uit een on premise Oracle database . Het eindresultaat moet een set CSV-bestanden zijn in een Amazon S3-bucket . Tussen het ophalen van de Oracle-gegevens en het dumpen ervan in CSV-vorm op S3, moet er iets zijn dat PII-gegevens verwijdert/anonimiseert. Indien mogelijk moet de gekozen oplossing cloud native zijn. In deze 3-delige blogreeks leg ik uit hoe je eenvoudige en flexibele ETL-gebaseerde anonimisering opzet: Het onderzoek naar producten die gebruikt zouden kunnen worden om het probleem op te lossen. Controleer ook hoe geschikt ze zijn voor wat de proof of concept moet bereiken. Hoe het gekozen product gebruikt kan worden om een ETL pipeline te maken die aan de eisen voldoet. Daarnaast, hoe je een lokale Oracle database opzet in Docker die gebruikt kan worden als databron voor het data ingestion deel van het proof of concept (gewoon omdat dit zo'n PITA was om te doen). En of dit op een cloud native manier kan worden gedaan. Onderzoek Het onderzoeksdeel van het proof of concept bestaat uit 2 delen: Hoe haal je data uit een Oracle database, anonimiseer je het op de een of andere manier en sla je het op als een stel CSV bestanden in een S3 bucket aka het ETL gedeelte. Uitzoeken wat de beste manier is om de anonimisering uit te voeren. De gegevens extraheren, transformeren en opslaan Het probleem van de klant klonk meteen al opmerkelijk als iets dat je zou kunnen oplossen met een ETL-product: Extract Transform Load . Het onderzoeksgedeelte voor dit deel van het proof of concept zou zich dus concentreren op dit type product. Ik kreeg ook wat input van iemand in mijn team om eens te kijken naar singer.io , omdat dat iets was dat ze in het verleden met succes hadden gebruikt voor dit soort problemen. Als je naar de homepage van Singer kijkt, vallen een aantal dingen meteen op: Singer maakt gegevensextractie en -consolidatie mogelijk voor alle tools van je organisatie. De open-source standaard voor het schrijven van scripts die gegevens verplaatsen. Unix-geïnspireerd: Singer taps en targets zijn eenvoudige applicaties samengesteld met pipes. JSON-gebaseerd: Singer-toepassingen communiceren met JSON, waardoor ze eenvoudig te gebruiken en te implementeren zijn in elke programmeertaal. Singer is dus gewoon een specificatie, zij het geen officiële. Het is een eenvoudig, op JSON gebaseerd dataformaat en je kunt iets in dit formaat produceren (een tap in Singer terminologie) of het formaat consumeren (een target ). Je kunt deze taps en targets aan elkaar koppelen om gegevens van de ene locatie te halen en op een andere locatie op te slaan. Singer wordt standaard geleverd met een heleboel taps (meer dan 100) en targets (10). Deze taps en targets zijn geschreven in Python. Omdat het centrale punt van het systeem slechts een gegevensformaat is, is het vrij eenvoudig om er zelf een te schrijven of een bestaand formaat aan te passen. Bij het controleren van de taps zou de standaard Oracle-tap het Extract-gedeelte van ons proof of concept moeten dekken. Hetzelfde lijkt echter niet het geval te zijn voor het Load gedeelte als we kijken naar de standaard targets. Er is een CSV target , maar deze slaat de resultaten lokaal op, niet in een S3 bucket. Er is een optie om gewoon dit doel te gebruiken en de S3 upload zelf te doen nadat de ETL pijplijn is voltooid. Een andere optie zou zijn om het bestaande CSV target aan te passen en de bestandsopslag te veranderen naar S3. Even Googelen levert een door de gemeenschap gemaakt S3 CSV Singer doel op. Volgens de documentatie zou dit target precies moeten doen wat we willen. Oeps, Singer transformeert niet Met de Extract en Load delen gedekt, blijft alleen het Transform deel van de ETL pijplijn over om uit te zoeken... en dit is waar het een beetje vreemd wordt. Ook al is Singer geclassificeerd als een ETL tool, het lijkt geen ondersteuning te hebben voor het transformatie gedeelte? Toen ik hier verder naar keek, kwam ik deze onheilspellend getitelde post tegen: Why our ETL tool does not do transformations . Als ik dit lees, lijkt het erop dat ze hun JSON specificatie/gegevensformaat beschouwen als het transformatiegedeelte. Dus ze ondersteunen transformatie naar ruwe gegevens en het opslaan ervan, maar ondersteunen geen andere soorten transformaties. Dat deel mag je zelf doen nadat het ergens is opgeslagen door een Singer-doel. Het blijkt dus dat Singer meer lijkt op het EL deel van een ELT product dan op een "old school" ETL product . Op dit punt zou Singer in ieder geval voldoende moeten zijn om de gegevens uit een Oracle database te halen en in CSV-formaat in een S3 bucket te zetten. En omdat Singer vrij eenvoudig, open en uitbreidbaar is, laat ik het hier voorlopig bij. Laten we verder kijken naar de anonimiseringsopties die in deze Singer-context zouden kunnen passen. Gegevens anonimiseren Net als bij het ETL-gedeelte, kreeg ik ook voor dit gedeelte wat input die me wees op Microsoft Presidio . Op de homepage kunnen we het volgende lezen: Het biedt snelle identificatie- en anonimiseringsmodules voor privé-entiteiten in tekst en afbeeldingen , zoals creditcardnummers, namen en meer. Het faciliteert zowel volledig geautomatiseerde als semi-geautomatiseerde PII de-identificatiestromen op meerdere platforms. Aanpasbaarheid in PII-identificatie en -anonimisering. Er staan dus veel veelbelovende dingen in die me zouden kunnen helpen bij het oplossen van mijn anonimiseringsbehoeften. Bij nader onderzoek lijkt het erop dat ik dit product evalueer tijdens een grote transformatie (snap je? 😉 ) van V1 naar V2. V1 bevatte wat ETL-achtige dingen zoals het ophalen van gegevens uit bronnen (hoewel Oracle-ondersteuning in de roadmap nooit lijkt te zijn gerealiseerd ) en het opslaan van geanonimiseerde resultaten in een aantal vormen/locaties. V2 heeft deze aanpak echter volledig losgelaten en concentreert zich puur op het detecteren en vervangen van PII-gegevens. In de kern is Presidio V2 een op Python gebaseerd systeem dat bovenop een AI-model is gebouwd. Dit stelt het in staat om automatisch PII-gegevens te ontdekken in tekst en afbeeldingen en deze te vervangen volgens de regels die je definieert. Ik heb wat tests gedaan met behulp van hun online testtool en het werkt min of meer, maar voor onze specifieke context moet het zeker worden aangepast. Als we kijken naar de meegeleverde testgegevens, lijkt het erop dat het vooral eenvoudige en korte gegevens zijn, maar geen grote tekstblokken of afbeeldingen. Dit roept de vraag op: zelfs als we Presidio kunnen configureren om te doen wat we willen, slaan we misschien kleine spijkers met een grote hamer? Is Presidio te veel? Laten we hier nog eens over nadenken. Als we gemakkelijk kunnen weten en definiëren welke eenvoudige kolommen in welke tabellen moeten worden geanonimiseerd en wanneer gewoon nulling of hashing van de kolomwaarden voldoende is, dan hebben we het autodetectie deel van Presidio niet nodig. We hebben ook geen Presidio-ondersteuning nodig voor volledige tekst of afbeeldingen en we hebben ook geen fancy substitutie-ondersteuning nodig. Presidio zou een krachtige bibliotheek kunnen zijn om een automatische anonimiseringsstap te maken voor onze Singer-gebaseerde pijplijn. Het helpt ook dat Presidio gebaseerd is op Python. Maar mijn gevoel zegt dat ik misschien eerst moet proberen om een iets eenvoudigere oplossing te vinden. Ik begon te zoeken naar iets dat een eenvoudige PII-vervanging kan doen en dat werkt in een Singer tap/target context. Ik vond deze Github repository: pipelinewise-transform-field . In de documentatie staat "Transformatiecomponent tussen Singer taps en targets". Klinkt verdacht veel als het " T " deel dat Singer als een ETL miste! Verderop in de configuratiesectie lezen we zelfs: "Je moet definiëren welke kolommen door welke methode moeten worden getransformeerd en in welke conditie de transformatie moet worden toegepast." en de mogelijke transformatietypes zijn: SET-NULL : transformeert elke invoer naar NULL HASH : transformeert stringinvoer naar hash HASH-SKIP-FIRST-n : Transformeert stringinvoer naar hash waarbij de eerste n tekens worden overgeslagen, bijv. HASH-SKIP-FIRST-2 MASK-DATE : Vervangt de maand- en dagdelen van datumkolommen door 1 jan. MASK-NUMBER : Zet elke numerieke waarde om in nul. MASK-HIDDEN : verandert een willekeurige tekenreeks in 'verborgen'. Dit lijkt volledig te voldoen aan onze eenvoudige anonimiseringseisen! We kunnen zelfs zien hoe we het moeten gebruiken in de context van Singer: some-singer-tap | transform-field --config [config.json] | some-singer-target Standaard Conclusie We hebben nu alle stukjes van de puzzel voor het opzetten van eenvoudige en flexibele ETL-gebaseerde anonimisering. In de volgende blogpost laten we zien hoe ze in elkaar passen en of ze de resultaten opleveren die de klant zoekt.

Leestijd 3 min

Tom Claus

Liferay DXP is de afgelopen jaren uitgegroeid tot een veelgebruikt portaalplatform voor het bouwen en beheren van geavanceerde digitale ervaringen. Organisaties gebruiken het voor intranetten, klantportalen, self-service platforms en meer. Hoewel Liferay DXP bekend staat om zijn gebruiksvriendelijkheid, kan de standaard zoekfunctionaliteit verder worden geoptimaliseerd om te voldoen aan de moderne verwachtingen van gebruikers. Om dit aan te pakken heeft ACA een geavanceerde oplossing ontwikkeld die de standaard zoekmogelijkheden van Liferay aanzienlijk verbetert. Lees er alles over in deze blog. Zoeken in Liferay: niet altijd efficiënt Traditioneel waren organisatorische zoekopdrachten gebaseerd op individuele trefwoorden . Intranetgebruikers zochten bijvoorbeeld op termen als "verlof" of "vergoeding" om de informatie te vinden die ze nodig hadden. Dit resulteerde vaak in een overvloed aan resultaten en documenten , waardoor gebruikers deze handmatig moesten uitpluizen om relevante informatie te vinden - een tijdrovend en inefficiënt proces dat de gebruikerservaring belemmert. De manier waarop gebruikers zoeken is veranderd De opkomst van AI-tools zoals ChatGPT heeft de manier waarop mensen naar informatie zoeken veranderd. Dit is ook zichtbaar in online zoekmachines zoals Google, waar gebruikers hun zoekopdrachten steeds vaker formuleren als complete vragen. Bijvoorbeeld: "Hoe vraag ik verlof aan?" of "Op welke reiskostenvergoeding heb ik recht?" . Om aan deze veranderende zoekbehoeften te voldoen, moet de zoekfunctionaliteit niet alleen snel zijn, maar ook natuurlijke taal kunnen begrijpen. Helaas schiet de standaard zoekfunctie van Liferay op dit gebied tekort. ACA ontwikkelt geavanceerde AI-gestuurde zoekfunctie voor Liferay Om tegemoet te komen aan het hedendaagse zoekgedrag, heeft ACA een geavanceerde oplossing ontwikkeld voor Liferay DXP 7.4 installaties: Liferay AI Search . Door gebruik te maken van het GPT-4o taalmodel zijn we erin geslaagd om de standaard zoekmogelijkheden van Liferay aanzienlijk te verbeteren. GPT-4o is een state-of-the-art taalmodel getraind op een uitgebreide dataset van tekstuele informatie. Door GPT-4o in onze oplossing te integreren, hebben we de zoekalgoritmes aangepast om complexere zoekopdrachten te verwerken , inclusief vragen in natuurlijke taal. Hoe werkt Liferay AI Search? Gesloten dataset Het AI model heeft alleen toegang tot data binnen de gesloten Liferay omgeving. Dit zorgt ervoor dat alleen relevante documenten - zoals die uit de Bibliotheek en Mediabibliotheek - toegankelijk zijn voor het model. Beheerders controle Beheerders kunnen bepalen welke content wordt opgenomen in de GPT-4o dataset, waardoor ze de nauwkeurigheid en relevantie van zoekresultaten verder kunnen optimaliseren. Afhankelijk van het profiel van de gebruiker worden de antwoorden en zoekresultaten afgestemd op de informatie waartoe hij of zij toegang heeft. Directe antwoorden Dankzij de GPT-4o integratie biedt de zoekfunctionaliteit niet alleen traditionele resultaten, maar ook directe antwoorden op gebruikersvragen. Hierdoor hoeven gebruikers niet meer door zoekresultaten te spitten om de specifieke informatie te vinden die ze nodig hebben. De vergelijking hieronder illustreert het verschil tussen de zoekresultaten van Liferay DXP's standaard zoekfunctie en de verbeterde resultaten van ACA's Liferay AI Search. Wilt u Liferay AI Search in actie zien? Bekijk de demo hieronder of via deze link! Voordelen van Liferay AI Search Of u nu Liferay DXP gebruikt voor uw klantenplatform of intranet, Liferay AI Search biedt tal van voordelen voor uw organisatie: Verhoogde gebruikerstevredenheid: Gebruikers kunnen snel precieze antwoorden vinden op hun vragen. Verbeterde productiviteit: Er wordt minder tijd besteed aan het zoeken naar informatie. Verbeterde kennisdeling: Belangrijke informatie is makkelijker te vinden en te delen. Conclusie Met Liferay AI Search verhoogt ACA de zoekfunctionaliteit van Liferay DXP om te voldoen aan de moderne verwachtingen van gebruikers. Door GPT-4o te integreren in Liferay DXP 7.4 levert deze oplossing niet alleen traditionele zoekresultaten, maar ook directe, relevante antwoorden op complexe zoekopdrachten in natuurlijke taal. Dit leidt tot een snellere, gebruiksvriendelijkere en efficiëntere zoekervaring die zowel de productiviteit als de gebruikerstevredenheid aanzienlijk verhoogt. Klaar om de zoekfunctionaliteit van uw Liferay platform te optimaliseren Neem vandaag nog contact met ons op!

Leestijd 5 min

Thomas Verhoeven

Op de hoogte blijven van de nieuwste trends en best practices is cruciaal in de snel evoluerende wereld van softwareontwikkeling. Innovatieve benaderingen zoals EventSourcing en CQRS kunnen ontwikkelaars in staat stellen flexibele, schaalbare en veilige systemen te bouwen. Op Domain-Driven Design (DDD) Europe 2022 gaf Paolo Banfi een verhelderende lezing over deze twee technieken. Wat is EventSourcing? EventSourcing is een innovatieve benadering van gegevensopslag die prioriteit geeft aan de historische context van een object. In plaats van alleen de huidige status van een object vast te leggen, slaat EventSourcing alle gebeurtenissen op die tot die status hebben geleid. Het creëren van een goed ontworpen event model is cruciaal bij het implementeren van EventSourcing. Het eventmodel definieert de events die zullen worden opgeslagen en hoe ze zullen worden gestructureerd. Zorgvuldige planning van het eventmodel is cruciaal omdat het het gemak van gegevensanalyse beïnvloedt. Het eventmodel aanpassen na de implementatie kan lastig zijn, dus het is belangrijk om het vanaf het begin goed te doen. Wat is CQRS CQRS (Command Query Responsibility Segregation) is een techniek die lees- en schrijfbewerkingen in een systeem scheidt om de efficiëntie en begrijpelijkheid te verbeteren. In een traditionele architectuur interageert een applicatie met een database door middel van een enkele interface. CQRS scheidt echter de lees- en schrijfbewerkingen, die elk door verschillende componenten worden afgehandeld. EventSourcing en CQRS combineren Een van de voordelen van het combineren van EventSourcing en CQRS is dat het bijhouden van wijzigingen en het controleren van gegevens eenvoudiger wordt. Door alle gebeurtenissen bij te houden die tot een bepaalde toestand hebben geleid, is het eenvoudiger om veranderingen in de loop van de tijd bij te houden. Dit kan vooral nuttig zijn voor toepassingen die auditing of regelgeving vereisen. Bovendien biedt het scheiden van lees- en schrijfbewerkingen op deze manier verschillende voordelen. Ten eerste optimaliseert het het systeem door het verminderen van conflicten en het verbeteren van de schaalbaarheid. Ten tweede vereenvoudigt het het systeem door de zorgen van elke kant te isoleren. Ten slotte verbetert het de beveiliging van gevoelige gegevens door de toegang tot de schrijfkant van het systeem te beperken. Een ander belangrijk voordeel van het implementeren van CQRS is de eliminatie van de noodzaak om de hele gebeurtenisstroom te doorlopen om de huidige status te bepalen. Door lees- en schrijfoperaties te scheiden, kan de leeszijde van het systeem speciale modellen onderhouden die geoptimaliseerd zijn voor het bevragen en ophalen van specifieke gegevensweergaven. Als gevolg hiervan is het niet langer nodig om de hele gebeurtenisstroom te doorlopen wanneer het systeem om de laatste status wordt gevraagd. In plaats daarvan kunnen de geoptimaliseerde leesmodellen efficiënt de benodigde gegevens leveren, wat leidt tot betere prestaties en minder vertraging. Wanneer EventSourcind en CQRS gebruiken? Het is belangrijk op te merken dat EventSourcing en CQRS niet voor elk project geschikt zijn. Het implementeren van EventSourcing en CQRS kan vooraf meer werk vergen dan traditionele benaderingen. Ontwikkelaars moeten tijd investeren in het begrijpen en effectief implementeren van deze benaderingen. Voor systemen die een hoge schaalbaarheid, flexibiliteit of beveiliging vereisen, kunnen EventSourcing en CQRS echter een uitstekende oplossing bieden. De beslissing om CQRS of EventSourcing te gebruiken voor uw toepassing hangt af van verschillende factoren, zoals de complexiteit van uw domeinmodel, de schaalbaarheidsvereisten en de behoefte aan een uitgebreid controlespoor van systeemgebeurtenissen. Ontwikkelaars moeten de specifieke behoeften van hun project evalueren voordat ze beslissen of ze deze benaderingen gaan gebruiken. CQRS is vooral nuttig voor applicaties met complexe domeinmodellen die verschillende gegevensweergaven vereisen voor verschillende use cases. Door de lees- en schrijfbewerkingen in afzonderlijke modellen te scheiden, kun je de leesbewerkingen optimaliseren voor prestaties en schaalbaarheid, terwijl je toch een enkele bron van waarheid voor de gegevens behoudt. Event Sourcing is ideaal als je een volledige en nauwkeurige registratie van alle wijzigingen in je systeem in de loop van de tijd moet bijhouden. Door elke gebeurtenis vast te leggen en op te slaan in een alleen-append log, kun je een onveranderlijke audit trail creëren die gebruikt kan worden voor debugging, compliance en andere doeleinden. Conclusie De combinatie van EventSourcing en CQRS kan ontwikkelaars aanzienlijke voordelen bieden, zoals meer flexibiliteit, schaalbaarheid en beveiliging. Ze bieden een frisse benadering van softwareontwikkeling die ontwikkelaars kan helpen toepassingen te maken die beter aansluiten bij de behoeften van moderne organisaties. Als je meer wilt weten over EventSourcing en CQRS, dan zijn er online veel uitstekende bronnen beschikbaar. Conferenties en lezingen zoals DDD Europe zijn ook uitstekende gelegenheden om op de hoogte te blijven van de laatste trends en best practices in softwareontwikkeling. Zorg ervoor dat je deze kansen niet mist als je voorop wilt blijven lopen! De volgende editie van Domain-Driven Design Europe vindt plaats in Amsterdam van 5 tot 9 juni 2023. Wist je dat ACA Group een van de trotse sponsors is van DDD Europe? {% module_block module "widget_bc90125a-7f60-4a63-bddb-c60cc6f4ee41" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"More about ACA Group"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":null,"href":"https://acagroup.be/en/aca-as-a-company/","href_with_scheme":"https://acagroup.be/en/aca-as-a-company/","type":"EXTERNAL"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %}