Tekniken
En data lake är kort och gott en lagringsplats byggd för att hantera och lagra stora mängder data i alla typer av format. Data kan komma från många olika källor, vare sig av typ strukturerad, semistrukturerad, eller ostrukturerad, och lagras i en data lake. Det spelar alltså ingen roll om det är databastabeller, JSON filer, bilder, eller en video som lagras. Således kan även data i olika ”mognadsfaser” lagras på samma plats. Det kan vara rådata, data som transformerats och förfinats, eller ready-for-consumption data i exempelvis en databastabell. Typiska use-cases med data lagrat i data lakes är dataanalys, Machine Learning, IoT, data exploration, eller kanske arkivering i väntan på användning. Enkelt beskrivet så kan datan användas till det absolut mesta.
Värdet
Vilka specifika värden en data lake tillför till ens verksamhet beror såklart på den enskilda situationen och vad man i sitt specifika fall vill uppnå. Men för att ge en grundläggande bild av saken har jag satt ihop ett exempel:
Tänk att du arbetar med analys och behöver sammanställa data i ditt verktyg från 10 olika källor, från olika domäner i verksamheten, där varje källa hanteras olika. Ett annat team i din verksamhet behöver göra samma sak, men använder ett helt annat verktyg, och behöver således göra om processen. Därtill så skiljer sig dataformatet mellan källorna och transformeringar behöver göras. Återigen görs dessa i vardera verktyg och processen upprepas. Med en data lake kan i stället data från dessa 10 källor lagras på en central plats och organiseras upp. Den rådata som kommer in kan lagras, sedan transformeras till ett enhetligt format som i sin tur lagras i en annan del av data laken. Analytiker i verksamheten kan sedan koppla sina verktyg mot denna data lake som är gemensam för verksamheten i stort, avdelningen, eller teamet.
Förstås är det inte alltid så enkelt som jag beskrivit här, men exemplet belyser vilket värde en data lake är tänkt att tillföra och vad man vill lösa med tekniken. Nedan har jag sammanfattat några punkter som jag tycker betonar de viktigaste fördelarna hos data lakes.
- Centralisering av data: data från mängder av olika källor kan samlas på en plats. Man minskar helt enkelt redundans och behov av att duplicera data.
- Flexibilitet: Alla typer av data kan lagras.
- Tillgänglighet: data i en data lake kan lätt göras tillgänglig för många konsumenter.
- Skalbarhet: data lakes är byggda för att hantera stora volymer av data, och kan enkelt skalas upp (cloud) när datamängden växer.
- Kostnadseffektivt: faktorerna är förstås många, där det viktigaste kanske är ursprungsläget, det vill säga hur verksamheten ser ut före implementationen av data lakes. Men med stor sannolikhet medför data lakes en effektivisering. Indirekta besparingar av att inte behöva transformera data för att lagra den är ett exempel. Minimering av dataredundans och att bara betala för det man lagrar (pay-as-you-go i cloud-baserade lösningar) är två andra viktiga faktorer.
Utmaningar
Som med alla tekniker finns det utmaningar och nackdelar även här. En bieffekt av att samla all data på samma plats kan vara att det blir komplext att underhålla. Kravet på att man i organisationen har en gemensam bild och fastslagen process för hur ens data ska se ut och hanteras blir viktigare. Gör man inte detta på ett bra sätt kan det leda till att man till exempel får data som inte är organiserad, uppdaterad, relevant, eller håller rätt kvalité. Helt enkelt så kan det bli svårt att arbeta med den data som ens data lakes innehåller. Påverkan kan då bli stor, till exempel på ens analytiska processer längre ned i flödet. En stor del av syftet med att ha data lakes till att börja med försvinner.
En annan faktor som fort kan bli en nackdel är det säkerhetsmässiga. Lagrar man stora mängder information på ett ställe så ökar i sin tur även påföljderna om ett intrång eller dylikt skulle ske. Säkerhet är alltid viktigt, men kanske än mer så vid centralisering av data. Data lakes i sig innebär inte en lägre säkerhet. Men påföljderna kan fort bli stora om säkerheten inte hanteras rätt.
Architecting data lake-houses in the cloud: Best practices and future directions