Varför misslyckas Data Lake-projekt?
Data lake används ofta som ett alternativ till Data Warehouse trots att de varken är jämförbara eller utbytbara. De senaste tio åren har vi hört talas om många data lake-initiativ och projekt som inte blir färdiga efter lång tid eller inte lyckas leverera affärsvärde för sin organisation. I den här texten reder vi ut varför det är så.
Gemensamt för många organisationer är att kompetensen om användbarheten i en data lake ofta saknas. Man har inte undersökt vad det grundläggande syftet är med en data lake eller vilka behov man har för hanteringen av sin data. Istället omfamnar man idén om att man behöver en data lake för att kunna ha en ”modern analysplattform”,och med hotet att tappa mot konkurrenter så startas sedan ett projekt.
Strukturerade, semistrukturerade och ostrukturerade data
Syftet med en data lake är att lagra ostrukturerade data. Skillnaden mellan strukturerade data och ostrukturerade data är att strukturerade data lagras och hanterats i ett tabulärt format, så som Excel, medan ostrukturerat data lagras utan något bestämt format, så som anteckningar i Windows. Det vanligaste är att affärssystem endast lagrar strukturerade data i en databas.
Ett bra exempel på ett stort system som använder strukturerade, semi-strukturerade och ostrukturerade data är världens största videosajt, Youtube. Youtube använder strukturerade data för att lagra användaruppgifter, metadata kring de videos som användarna laddat upp, vilka användare som kommenterat vilka videos och så vidare.
Youtube sparar också semi-strukturerade data för vilka reklamsnuttar som varje användare får ta del av, hur och i vilken ordning användarna klickar runt i Youtubes menyer. Youtube genererar interna metadata som till exempel håller reda på hur lång tid det tog att läsa videon från serverklustret.
Videodata är ostrukturerade data och något som Youtube baserar hela sin affärsidé på. De sparar ner den faktiska videon i binärformat, alltså ett format som kan konverteras till video och kan strömmas till en webbläsare.
Anpassa projekten efter datan
Data lake löser problemen med stora mängder data (big data) som är för otymplig att hantera i ett Data Warehouse. Det är en vanlig föreställning att mycket data och AI-algoritmer i sig ger affärsvärde men det är inte helt sant: AI- eller ML-algoritmer fungerar väl på maskingenererad data och beteendedata, det som ibland kallas IoT. Men långt ifrån alla data som en organisation genererar är maskingenererad, de flesta data är ”vanliga” strukturerade affärsdata. Men ska vanliga strukturerade data verkligen laddas in i en data lake?
Den data som ligger i data lakes är ofta semi-strukturerad rådata där användarbeteenden och systembeteenden kan utvinnas via avancerade analyser, ofta via ML-algoritmer. Grundproblemet i många organisationer är att man i det första skedet valt data lake för sin data när man egentligen behövde ett Data Warehouse. Därför misslyckas data lake-projekten – man har inte anpassat sitt projekt efter vilken sorts data man har.
Problemen som uppstår beror på att data laken har matats med data som egentligen är strukturerad. Det är svårt att garantera någon datakvalitet. I stället för att dela upp datan – så strukturerade data landar direkt i ett Data Warehouse och semi-strukturerade data hamnar i en data lake – så vill teknikleverantörerna sälja ytterligare produkter.
Nu finns det till och med lösningar där man bygger ett transformeringslager ovanpå en data lake – alltså för att åstadkomma precis det som ett vanligt Data Warehouse gör – något som är döpt till ”data lakehouse”. Detta kommer innehålla samma dåliga datakvalitet som en data lake och det kommer gå långsamt.
Ackumulerade problem
Många får problem när de tänker att ett data lake-projekt ska lösa de problem som orsakats av en undermålig implementering av ett Data Warehouse-projekt. Data Warehouse är inte okomplicerat att implementera och ett sådant projekt kräver erfarenhet och kompetens. Men att tro att en data lake gör så att de utmaningar som finns med ett Data Warehouse försvinner är att lura sig själv. Istället skapar man sig en rad nya problem, utöver de problem man hade sen tidigare.
Slutsatsen är – om din data behöver ett Data Warehouse så är det ett Data Warehouse du ska satsa på. Din data behöver sannolikt inte en data lake, med eller utan nya tillbehör.
