Layered Architecture for Data Platforms: waar data wordt opgeslagen

In de vorige blogs over de Gelaagde Architectuur voor Data Platformen hebben we de gelaagde architectuur voor dataplatforms geïntroduceerd, zijn we dieper ingegaan op de laag Databronnen en Ingestion en hebben we de Processing-laag besproken. In deze blog kijken we naar de opslaglaag. Over het algemeen wordt de opslaglaag gebruikt om de data op te slaan in een datamodel, zodat de data kunnen worden geanalyseerd of gerapporteerd.

Wanneer de data uit de databronnen worden opgenomen en vervolgens worden getransformeerd in de opslag laag, worden deze vervolgens opgeslagen in de opslag laag. Het doel van de opslag laag is om de data te beschermen tegen calamiteiten, storingen of gebruikersfouten, om de data beschikbaar te maken voor ontwikkelaars, data wetenschappers en eindgebruikers, en om data te archiveren die voor een lange periode bewaard moet worden. Er zijn

Er zijn veel verschillende technologieën die kunnen worden gebruikt om de data op te slaan, elk met hun eigen voor- en nadelen, afhankelijk van het type opslag dat u nodig heeft. De meest voorkomende opslagtechnologieën zijn:

• Relational Database Management Systems (RDBMS): Dit zijn relationele databases die vaak worden gebruikt voor Online Transaction Processing (OLTP)-systemen zoals de ERP- of CRM-systemen die veel bedrijven gebruiken. De meeste applicaties gebruiken een relationele database om de data op te slaan die in het systeem worden ingevoerd. Voor Online Analytical Processing (OLAP) kunnen relationele databases ook goed passen, maar voor dit soort systemen worden vaak andere opslagtechnologieën gebruikt.
• Massive Parallel Processing (MPP) database: Dit is een soort relationele database, maar met als belangrijkste verschil dat de data zijn verdeeld over verschillende computers (met bijgevoegde opslag) die elk een deel van de data verwerken. Dit soort databases worden alleen gebruikt voor OLAP-oplossingen en zijn niet geschikt voor OLTP, omdat deze databases zijn ontworpen om query's te verwerken die enorme hoeveelheden data nodig hebben en niet goed zijn in het verwerken van veel kleine verzoeken. Meestal worden deze MPP-databases gebruikt wanneer de relationele database niet snel genoeg is.
• NoSQL-databases: De NoSQL-databases (Not Only SQL) worden geïntroduceerd om enkele van de nadelen van de relationele databases te overwinnen die verband houden met de schaalbaarheid en de flexibiliteit van het datamodel. NoSQL-databases zijn niet-tabelvormige databases en slaan data anders op dan relationele databases. Verderop in deze blog bespreken we de verschillende soorten NoSQL databases.
• Hadoop Distributed File System: Deze opslagtechnologie is een gedistribueerd bestandssysteem dat (grote) bestanden verdeelt over meerdere computers met aangesloten opslag om ze sneller te kunnen lezen en schrijven. Het idee van deze opslagoplossing is dat goedkope servers kunnen worden gebruikt om de kosten van het opslaan van enorme hoeveelheden data te beperken.
• In-memory databases : Met in-memory databases worden de data bewaard in het hoofdgeheugen van de computer. De data op de schijf worden alleen gebruikt als back-up in geval van stroomuitval of storing, wat in-memory databases erg snel, maar ook vrij duur maakt. Daarom mogen in-memory databases alleen worden gebruikt als de hoeveelheid data klein is, de prestaties van groot belang zijn en de data vaak worden geraadpleegd. 
• Cloudopslag: Cloudopslag is vergelijkbaar met het Hadoop Distributed File System. Het is een opslagoplossing die alle soorten data kan opslaan, zoals bestanden of tabellen. Het is mogelijk om te kiezen tussen verschillende protocollen over hoe de data toegankelijk zijn, hoe snel deze moeten zijn, de beveiligingsopties en de betrouwbaarheid (bijv. aantal kopieën dat in verschillende datacenters of regio's is opgeslagen).

De meeste producten van verschillende leveranciers in de bovenstaande categorieën lijken veel op elkaar, dus voor de meeste gebruikssituaties maakt het echt niet veel uit welk product en welke leverancier wordt gekozen. Dit is niet het geval voor de NoSQL-databases. Er zijn momenteel een paar honderd NoSQL-databases en ze hebben elk verschillende eigenschappen waardoor ze nuttig zijn voor bepaalde gebruiksscenario's. Over het algemeen kunnen deze NoSQL-databases worden gecategoriseerd in 4 verschillende groepen (zie figuur 2):

• Documentdatabases: slaat data op in een semi-gestructureerd bestandsformaat zoals JSON.
• Sleutel-waarde-archieven: slaat sleutels en waarden op. data kunnen alleen worden opgehaald door de sleutel.
• Kolomfamilies: slaat data op in tabellen, rijen en dynamische kolommen
• Graph databases: slaat data op in knooppunten (mensen, plaatsen, dingen) en randen (relaties)

Maar ook binnen elke groep zijn er veel verschillen tussen de databases.

Een dataplatform kan gebruik maken van meerdere verschillende NoSQL-databases of meerdere opslagtechnologieën voor verschillende doeleinden of verschillende soorten data. Voordat u echter beslist welke opslagtechnologie u wilt gebruiken, moet u rekening houden met het doel van de opslaglaag. Dit kan zijn:

• Landingsgebied: Het landingsgebied is de plaats waar de opgenomen data eerst worden opgeslagen voordat deze verder worden verwerkt.
• Staging-gebied: De staging-gebied is een tussenliggende opslagruimte voor het ETL-proces.
• Data Warehouse: In het datawarehouse worden de data geïntegreerd en opgeslagen in een datamodel, zodat ze kunnen worden gebruikt voor analyse of rapportage.
• Data Mart: Dit is een speciale laag bovenop het datawarehouse die slechts een deel van de data opslaat voor een specifieke use case.
• Operationele dataopslag: Specifieke opslagoplossing om data op te slaan die nodig zijn om over te rapporteren ter ondersteuning van de huidige activiteiten.
• Data Lake: Dit is een centrale plek waar alle beschikbare data wordt opgeslagen.
• Archiveren: Hier worden de binnenkomende data gearchiveerd.

Voor elk van deze zeven mogelijke doeleinden is er een specifieke opslagtechnologie die het beste werkt (zoals te zien is in tabel 1).

Een dataplatform dient vaak meerdere doelen, wat betekent dat het meerdere opslagtechnologieën kan hebben voor elk ander doel. Zoals u in tabel 1 kunt zien, is cloudopslag goed voor de meeste doeleinden, behalve wanneer de data vaak worden gewijzigd; De relationele databases zijn goed voor de meeste workloads, behalve wanneer het om ongestructureerde data gaat of wanneer hoge prestaties nodig zijn. Hadoop is een goede keuze wanneer u ongestructureerde data moet opslaan of wanneer u een goedkope opslagoplossing voor de lange termijn nodig hebt. In-memory databases zijn vooral goed wanneer prestaties erg belangrijk zijn en de hoeveelheid (gestructureerde) data klein is. MPP-databases zijn een goede keuze wanneer u enorme hoeveelheden gestructureerde data moet opslaan en verwerken. NoSQL-databases zijn niet goed voor de meeste doeleinden, maar kunnen dan een zeer goede keuze zijn voor bepaalde specifieke gebruiksscenario's.

Wanneer u overweegt welke opslagtechnologieën u wilt gebruiken, kunt u uzelf de volgende vragen stellen:

Welke soort(en) data moet ik opslaan? Gaat het om gestructureerde, semi-gestructureerde of ongestructureerde data? Kijk niet alleen naar de huidige situatie, maar denk ook na over toekomstige eisen.

Wat zijn de prestatie-eisen van de opslagtechnologie? Moet de opslagtechnologie snel genoeg zijn om de binnenkomende data op te slaan of moet het ook snel genoeg zijn om de data aan de eindgebruikers te serveren?

Wat zijn de schaalbaarheidsvereisten? Heb je een zeer stabiele voorspellende workload of zal de workload sterk variëren?

Wil je de data opslaan in de Cloud? Deze vraag kan te maken hebben met waar uw data worden gegenereerd en waar u uw data wilt gebruiken. Het kan ook een wettelijke vraag zijn of het is toegestaan om de data in de cloud op te slaan.

Wilt u vendor lock-in voorkomen? Vendor lock-in kan worden verminderd door gebruik te maken van industriestandaarden en open source technologieën. Daarnaast bieden sommige leveranciers opslagtechnologieën die werken op meerdere cloudaanbieders.

De opslaglaag is een van de plaatsen waar beveiliging een belangrijke rol speelt, waarover meer in detail in een vervolgblog over de beveiligingslaag. Een van de belangrijkste beslissingen die moet worden overwogen is of de beveiliging wordt afgedwongen op de opslaglaag of op andere lagen, zoals de analyselaag en/of de visualisatielaag. Als beveiliging wordt afgedwongen in de opslaglaag, is het mogelijk om af te dwingen dat alleen bepaalde mensen met de oorspronkelijke rechten toegang kunnen krijgen tot de data, onafhankelijk van de tool die wordt gebruikt. Als beveiliging wordt afgedwongen in de analyselaag en/of de visualisatielaag, moet ervoor worden gezorgd dat het niet mogelijk is om deze lagen te omzeilen om toegang te krijgen tot de data in de opslaglaag. Er zijn voor- en nadelen voor elke optie die zullen worden besproken in de blog over de beveiligingslaag. De opslaglaag kan ook een andere belangrijke rol spelen in de beveiliging en dat is dat veel opslagtechnologieën auditing van alle activiteiten ondersteunen. Dit is een logboek van welke gebruikers toegang hebben gehad tot welke data en het kan waarschuwingen geven wanneer bepaalde gebruikers specifieke activiteiten uitvoeren.

In deze blog hebben we de verschillende opslagtechnologieën beschreven en de doeleinden waarvoor opslag nodig is in een dataplatform. Sommige opslagtechnologieën zijn beter geschikt voor bepaalde doeleinden dan andere, zoals te zien is in tabel 1. We hebben ook een aantal standaardvragen geïntroduceerd die u kunnen helpen bij de beslissing welke opslagtechnologieën u moet gebruiken.
Deloitte kan u helpen bij het kiezen van de opslagtechnologieën die u wilt gebruiken voor het dataplatform en wij kunnen u ook helpen bij de implementatie ervan. Onze volgende blog gaat over de Analytics Layer. Als je meer wilt weten over hoe de data kan worden geanalyseerd, lees dan onze volgende blog in onze serie over de gelaagde architectuur.

Het Data Modernization & Analytics team van Deloitte helpt klanten met het moderniseren van hun data-infrastructuur om de levering van analytics te versnellen, zoals self-service BI en AI-gestuurde oplossingen. Dit wordt gedaan door best practices en bewezen oplossingen te combineren met innovatieve technologieën van de volgende generatie, zoals cloud-gebaseerde platforms en big data-architecturen.

Praktische tips

Ontwerp een back-up- en herstelstrategie.

Denk aan het bewaren van data. Hoe lang moet data bewaard worden? Hoe lang is het wettelijk verplicht en toegestaan om data te bewaren?

Maak een keuze tussen schema-on-read en schema-on-write. Schema-on-write betekent dat alle binnenkomende data moeten worden gemodelleerd, terwijl schema-on-read inhoudt dat de data worden opgeslagen zoals ze zijn en alleen worden gemodelleerd wanneer ze worden gebruikt. Vaak maakt een datawarehouse gebruik van schema-on-write, terwijl een data lake gebruikmaakt van schema-on-read.