Uitdagingen voor het ontwikkelen van data lakes

Een veel gebruikte definitie voor het data lake concept luidt als volgt: "A data lake is a storage repository, usually in Hadoop, that holds a vast amount of raw data in its native format until it is needed." In dit artikel wordt deze definitie gevolgd door: "A data lake is a great place for investigating, exploring, experimenting, and refining data, in addition to archiving data."

De meesten kunnen zich in deze definitie vinden en zijn het er mee eens dat een data lake ideaal is voor data scientists, statistici en andere zakelijke gebruikers die gegevens vrij willen verkennen en onderzoeken. Het nut van een data lake is overduidelijk voor zakelijke toepassingen. Met een data lake hebben de gebruikers alle door hen gewenste gegevens binnen handbereik. Ze zullen zich voelen als kinderen in een snoepwinkel.

Volgens deze definitie is een data lake bedoeld als fysieke opslag van gegevens. Gegevens uit diverse bronnen worden naar deze gecentraliseerde omgeving gekopieerd en daar opgeslagen. Hadoop wordt normaliter aanbevolen als de gegevensopslagtechnologie, aangezien het relatief goedkoop is en veel opslagformaten ondersteunt waardoor gegevens in hun oorspronkelijke formaat opgeslagen kunnen worden.
Bij het opzetten van een fysiek data lake moeten organisaties zich echter bewust zijn van de volgende kritische uitdagingen die het project kunnen doen slagen of falen:

• Big data is te veel om te verplaatsen: Als een gegevensbron echt groot is, kan het kopiëren te lang duren (bijvoorbeeld vanwege de beschikbare bandbreedte) en het (nogmaals) opslaan van al die gegevens kan weleens te duur zijn. Soms is het beter de (analytische) verwerking te verplaatsen naar de locatie waar de gegevens opgeslagen zijn dan de gegevens te verplaatsen naar de plek waar de analytische verwerking plaatsvindt.
• Complexe “T” verplaatst naar gegevensgebruik: Zoals de definitie aangeeft is het de bedoeling dat ruwe en onverwerkte gegevens in hun oorspronkelijke formaat in een data lake opgeslagen worden. Dit houdt in dat er geen T wordt uitgevoerd (de T komt van de populaire afkorting ETL – Extract Transform Load). Dat wil zeggen dat gebruikers die gegevens uit een data lake halen alle transformatielogica en -verwerking moeten ontwikkelen en uitvoeren. Dit kan complex en tijdrovend zijn. ETL-specialisten weten hoe complex die T kan zijn.
• Bedrijfspolitiek: Het is in veel data warehouse-projecten een enorme uitdaging geweest om afdelingen en divisies te overtuigen van de waarde van het kopiëren van gegevens naar een centraal data warehouse. Politieke, organisatorische en bestuurlijke aspecten zijn vaak in botsing gekomen met deze gecentraliseerde data warehouse-aanpak. Talrijke data warehouse-projecten zijn hierdoor vastgelopen en in sommige gevallen leidde dit zelfs tot een voortijdige beëindiging van deze projecten. Hoeveel vergelijkbare problemen kunnen dan wel niet ontstaan wanneer een data lake wordt ontwikkeld dat mogelijk gegevens uit nog meer bronnen haalt (lees: meer afdelingen en divisies)?
• Bescherming van gegevens en regelgeving: Als gevolg van de nieuwe regelgeving inzake de bescherming en privacy van gegevens, gelden er steeds meer regels die het bij elkaar opslaan van bepaalde soorten gegevens verbieden. In sommige landen zijn zeer strikte regels ingevoerd over wat al dan niet is toegestaan. Bovendien kunnen gegevens in sommige omgevingen uitsluitend door wetenschappers gebruikt worden nadat de gegevens geanonimiseerd zijn. Dit houdt in dat deze gegevens niet in hun oorspronkelijke vorm opgeslagen kunnen worden; ze moeten eerst verwerkt worden.
• Wet- en regelgeving: Aanvullende wetten en regels die niet specifiek betrekking hebben op de privacy van gegevens, kunnen ook de fysieke verplaatsing van gegevens naar een data lake verhinderen. Sommige landen staan bijvoorbeeld niet toe dat gegevens het land “verlaten.” Dit kan problemen geven wanneer een data lake niet in hetzelfde land is opgebouwd als de bronsystemen.
• Gegevens opgeslagen buiten hun oorspronkelijke beveiligingssysteem: Veel bronsystemen, met name de transactiesystemen, beschermen hun gegevens met zware beveiligingssystemen. Er zijn autorisatie-, authenticatie- en encryptieregels opgesteld om de gegevens te beschermen tegen incorrect gebruik. Zodra gegevens hun bronsystemen verlaten en gekopieerd worden naar een data lake, zijn ze opeens niet meer beveiligd. In veel situaties is dit totaal onaanvaardbaar. Gegevens kunnen te vertrouwelijk, te gevoelig of te persoonlijk zijn om ze buiten hun bestaande beveiligingssysteem te kopiëren.
• Ontbrekende metagegevens: Sommige gegevensbronnen beschikken niet over metagegevens die de gegevens beschrijven. De metagegevens zitten ‘in de hoofden’ van de ontwikkelaars en gebruikers. Zij hebben de gegevensbron gebouwd en gebruiken deze elke dag, waardoor ze weten wat alles betekent. Als we die gegevens uit hun oorspronkelijke omgeving halen, komen de metagegevens niet mee, waardoor het een beproeving voor de data lake-gebruikers wordt om te begrijpen wat de gegevens werkelijk betekenen.
• Niet alle gegevensbronnen in het oorspronkelijke formaat: Sommige gegevensbronnen zijn lastig naar een data lake te kopiëren met behoud van het oorspronkelijke formaat. Bijvoorbeeld, op mainframes worden databasesystemen zoals IMS en IDMS nog steeds gebruikt om gegevens op te slaan. Omdat de gegevens in dergelijke systemen verbonden zijn met pointer-structuren, heeft het 1-op-1 kopiëren naar een data lake geen zin. De pointer-structuren zullen eerst naar echte waardes omgezet moeten worden. Dit betekent dat deze gegevens niet in hun originele formaat in het data lake opgeslagen kunnen worden. Er bestaan verscheidene voorbeelden van gegevensbronnen die, vanwege technische redenen, niet naar een data lake gekopieerd kunnen worden met behoud van hun originele formaat.
• Verversen van het data lake: Uiteindelijk moeten de gegevens die in een data lake opgeslagen zijn, op dezelfde manier ververst worden als dat staging areas, data warehouses en data marts ververst moeten worden. Een complete ETL-oplossing is niet nodig, omdat het data lake de ruwe gegevens in het oorspronkelijke formaat bevat. Een EL-oplossing (Extract Load) volstaat waarschijnlijk. Desalniettemin moeten verversingsprocedures opgezet en ingepland worden en moeten er procedures ontwikkeld worden voor het geval er iets mis gaat. Bijvoorbeeld, wat doen we als de EL-run ’s nachts crasht en de helft van de gegevens al in het data lake geladen is en de data scientists deze gegevens de volgende dag om 8:00 al nodig hebben? Wie bellen we om dit probleem op te lossen?

Samenvattend, we begrijpen allemaal de waarde om data scientists, gegevensonderzoekers en andere zakelijke gebruikers toegang te gegevens tot data lakes. Het kopiëren van ruwe gegevens in het oorspronkelijke formaat naar een data lake klinkt eenvoudig. Maar wees voorzichtig, het is niet zo eenvoudig als sommigen ons willen laten geloven. Er wachten ons enkele serieuze uitdagingen bij het opzetten van een data lake. Bagatelliseer ze niet, maar bestudeer ze in detail bij het ontwerpen en ontwikkelen van een data lake.