Gelaagde architectuur voor dataplatformen: de plek waar datatransformaties plaatsvinden

In de vorige twee blogs over Gelaagde Architectuur voor Data Platforms hebben we de volledige gelaagde architectuur voor dataplatforms geïntroduceerd, zoals te zien is in Figuur 1, en zijn we dieper ingegaan op de Data Sources en Ingestion Layer.

                                                                    Figuur 1 – Lagen van een dataplatform

In deze blog kijken we naar de Processing Layer, waarbij het doel is om de brondata te transformeren naar een datamodel dat klaar is voor analyse en rapportage. We bespreken de verschillende soorten verwerkingen, dat de verwerking kan worden gedaan door een ETL- of ELT-proces en de locatie van de verwerking.
Data wordt vanuit de databronnen opgenomen in de opslag-laag van het platform. Het is de taak van de Processing Layer om deze procedure te orkestreren en de data zo te transformeren dat deze vervolgens in de Storage-laag kan worden opgeslagen.

. In de opslag-laag worden gestructureerde data opgeslagen in een bepaald datamodel, dat hetzelfde datamodel kan zijn als de databron. In dit geval zijn er geen transformaties nodig op de data. Vaak wordt het datamodel in de opslag-laag echter gewijzigd om beter aan te sluiten bij het doel van het dataplatform. In dit geval transformeert de verwerkingslaag de data van het brondatamodel naar het datamodel in de opslag-laag.
 

Real-time of Batch verwerking

Een belangrijke beslissing die we moeten nemen, betreft de vraag of we batchverwerking of real-time verwerking moeten toepassen. Real-time verwerking is nodig wanneer het altijd nodig is om naar de meest actuele data te kijken. In dit geval is het niet acceptabel wanneer de data in het dataplatform niet overeenkomen met de meest actuele data in de databron. Batchverwerking daarentegen is geschikt wanneer een vertraging in de data acceptabel is. Vanwege de tijdsdruk van het nodig hebben van actuele data, is real-time verwerking veel complexer, en daarom adviseren wij om dit alleen te gebruiken als het absoluut noodzakelijk is. Om de risico's van real-time verwerking te verminderen, is het ook noodzakelijk om een soort batchproces te hebben om ervoor te zorgen dat er een methode is om de data in te halen of opnieuw te laden wanneer er een technisch probleem of probleem met de data zelf is dat moet worden gecorrigeerd. Het moet ook worden ondersteund door de databron en de opnamelaag en heeft een constante stroom van datawijzigingen nodig die kunnen worden verwerkt. De opnamelaag moet daarom gebeurtenissen of berichten verzenden die in realtime kunnen worden verwerkt.

Een architectuur die zowel gebruik maakt van real-time verwerking als batchverwerking is de Lambda-architectuur. De Lambda-architectuur maakt gebruik van een snelheidslaag die gebruikmaakt van real-time verwerking om de data onmiddellijk beschikbaar te maken en een batchlaag voor een uitgebreidere en nauwkeurigere weergave van de data. De resultaten van zowel de snelheidslaag als de batchlaag worden gecombineerd in een serveerlaag die de data beschikbaar maakt. Het voordeel van de Lambda-architectuur is dat het de data in real-time beschikbaar maakt, maar het biedt ook de nauwkeurigheid van batchverwerking die uitgebreidere controles kan bevatten dan mogelijk is met real-time verwerking.


Real-time of bijna real-time

Als we het over real-time hebben, bedoelen we ook near real-time. Het verschil tussen real-time en near real-time is dat bij near real-time een kleine vertraging (van enkele seconden tot minuten) is toegestaan. Hoeveel vertraging acceptabel is, hangt af van het gebruik. Voor de meeste gebruiksscenario's zou bijna realtime voldoende moeten zijn. Real-time verwerking betekent dat een vertraging van maximaal 1 seconde is toegestaan. Een oplossing die bijvoorbeeld de hartslag voor IC-patiënten monitort, moet een minimale vertraging hebben die niet langer mag zijn dan 1 seconde. Deze tijdseis maakt real-time verwerking duurder (omdat er meer rekenkracht nodig is) en/of het beperkt de mogelijke transformaties vanwege hun complexiteit, zodat het minder tijd zou kosten.

Verrijking van data

In sommige gevallen sluit de brondata alleen niet volledig aan bij de behoeften van de datagebruikers. In dit geval kan dataverrijking een rol spelen. dataverrijking is het proces van het toevoegen of verbeteren van de verzamelde data. Dit kan worden gedaan door data uit verschillende bronnen te combineren, bijvoorbeeld in de vorm van interne bronnen zoals andere applicaties, of bronnen van derden, zoals weerdata, sociale media en gekochte datasets van externe bedrijven. Het kan ook zijn dat dataverrijkingsprocessen automatisch ontbrekende data toevoegen door algoritmen toe te passen op de bestaande data en zo de kwaliteit van de data te verbeteren. Sommige ETL-tools hebben al ingebouwde controles en datasets om ontbrekende data toe te voegen of bestaande data te herstellen; Bijvoorbeeld de postcode- en adrescheck die vaak wordt toegepast. Dataverrijking wordt vaak toegepast in klantanalyse door demografische en geografische data toe te voegen aan de klantdata.

ETL of ELT?

De real-time of batchprocessen die worden uitgevoerd, worden ook wel de Extract, Transform and Load (ETL) processen genoemd. In een ETL-proces wordt de data uit de databron gehaald, getransformeerd naar het datamodel van de opslag-laag en vervolgens opgeslagen in de opslag-laag.

Maar tegenwoordig, nu steeds grotere hoeveelheden data vaker moeten worden opgeslagen, wordt het concept van het Extract, Load and Transform (ELT)-proces steeds populairder, waarbij data eerst in de opslag-laag worden geladen en daarna worden getransformeerd. Deze methode wordt vaak gecombineerd met een data lake waarbij de data as-is wordt opgeslagen in het data lake. Vanuit het data lake kan het worden getransformeerd en opgeslagen in een datamodel, in een andere opslagtechnologie of weer in het data lake. Maar het kan ook zo zijn dat de data niet getransformeerd wordt; Alleen geanalyseerd als dat nodig is. De ELT-methode wordt vaak gebruikt bij het werken met semi-gestructureerde of ongestructureerde data die ongewijzigd zijn opgeslagen in een data lake.

Het analyseren van data die zijn opgeslagen in een vooraf gedefinieerde structuur is veel eenvoudiger, en om die reden is het ETL-proces de beste aanpak voor data die vaak moeten worden geraadpleegd. Maar voor data die slechts af en toe nodig zijn (of waarvan het niet zeker is of ze ooit nodig zijn), is het het meest efficiënt om ze op te slaan zoals ze zijn en ze alleen te verwerken wanneer ze nodig zijn, daarbij met behulp van ELT.

Praktische tips

Test of elke record is verwerkt. Dit kan worden gedaan door rijtellingen en samenvattingen uit te voeren op de brondata en de verwerkte data. Als die overeenkomen is dat niet altijd een garantie dat alles correct is verwerkt, maar als het niet overeenkomt weet je zeker dat er iets mis is gegaan.

Implementeer logica slechts één keer in de code en roep dezelfde routine aan wanneer dezelfde transformatie nodig is voor verschillende datasets. Dit maakt het onderhoud eenvoudiger.

Documenteer de logica die wordt toegepast op de brondata en voer vervolgens audits uit om te controleren of de documentatie overeenkomt met de werkelijke code.

Implementeer data lineage om na te gaan hoe de brondata wordt getransformeerd.

Locatie van verwerking

Bij het verwerken van enorme hoeveelheden data is het beste om dit zo dicht mogelijk bij de plaats waar de data zijn opgeslagen te doen om de dataoverdracht tot een minimum te beperken, wat kan worden gedaan door de logica in de database te implementeren. De meeste ETL-tools kunnen het grootste deel van de verwerkingslogica naar de databaselaag pushen in plaats van deze op een aparte server te verwerken.

Een trend die we momenteel zien is serverless computing, waarbij de ETL- of ELT-processen worden uitgevoerd door cloudservices. Dit betekent dat er geen toegewijde server nodig is en dat u alleen hoeft te betalen voor de tijd die nodig is om de processen uit te voeren. Dit kan zeer kosteneffectief zijn, vooral wanneer de processen slechts een korte periode draaien.

Datamining

Een specifieke vorm van verwerking is datamining. Datamining gaat over het extraheren en ontdekken van patronen en betekenisvolle informatie in grote datasets, en bestaat uit grote batchprocessen die de enorme hoeveelheden data lezen. Het gaat dus niet om het verwerken van de data zelf, maar meer om het detecteren en extraheren van zinvolle informatie uit de data. Datamining bestaat vaak uit een van de volgende soorten verwerkingen:

• Detectie van afwijkingen: identificatie van ongebruikelijke datarecords
• Leren van associatieregels: relaties vinden tussen datavoorvallen
• Clustering: het vinden van overeenkomsten tussen datarecords om ze te groeperen
• Classificatie: categoriseer datarecords op basis van bepaalde dataelementen
• Regressie: het zoeken naar de relatie tussen verschillende data-elementen
• Samenvatting: een korte weergave van de datasets

Sommige van de bovenstaande soorten datamining kunnen alleen worden gedaan met behulp van geavanceerde analyse-algoritmen. In een van de vervolgblogs gaan we dieper in op de (geavanceerde) analysemethoden. Wees ook zeer voorzichtig bij het gebruik van persoonsdata in combinatie met datamining, want dit kan leiden tot privacy- en juridische problemen wanneer er niet voldoende voorzorgsmaatregelen zijn genomen.

In deze blog hebben we de verschillende soorten verwerkingen beschreven, het verschil tussen ETL- en ELT-processen en de locatie van de verwerking. Er is geen one-size-fits-all oplossing. Elke situatie en use case is anders en dat zal resulteren in andere keuzes over de Processing-laag.

Het Data Modernization & Analytics-team van Deloitte helpt klanten bij het moderniseren van hun data-infrastructuur om de levering van analyses te versnellen, zoals self-service BI en AI-oplossingen. Dit doen we door best practices en bewezen oplossingen te combineren met innovatieve technologieën van de volgende generatie, zoals cloud-gebaseerde platforms en big data-architecturen. We kunnen je helpen met het ontwerpen en ontwikkelen van de ETL (of ELT) processen.

Onze volgende blog gaat over de Storage Layer. Wil je meer weten over de verschillende mogelijkheden over hoe data opgeslagen kan worden in het dataplatform, lees dan onze volgende blog in de serie over de Layered Architecture.