Är Data Lakehouse svaret på hur man bringar ordning och reda i er kaotiska Data Lake eller får fart på den långsamma utvecklingen i ditt Data Warehouse? Du som står inför att införa en dataplattform i molnet, måste du tänka om kring din arkitektur?
Det har skett enorma framsteg kring hur vi bygger dataplattformar de senaste åren och nya begrepp och strategier sköljer över oss hela tiden. Inte nog med att de stora molnleverantörerna Microsoft, AWS och Google gör stora satsningar, bolag som t.ex. Data Bricks marknadsför sin Delta Lake med stor framgång just nu och Snowflake är fortsatt heta på marknaden.
Jag har jobbat som utvecklare och arkitekt i snart 15 år inom Business Intelligence och tänkte försöka ge mig på att reda ut vad detta egentligen handlar om – Är det ett paradigmskifte eller bara skickliga marknadsförare som varit i farten? Det har generellt funnits två huvudstrategier som dominerat marknaden de senaste åren, där Data Lakehouse ska vara den perfekta kompromissen där de två ska bli ett.
Ett Data Warehouse är till stor del till för att sammanställa data från olika ställen på ett sätt som gör det enkelt och snabbt att skapa analyser och rapporter och har funnits i över 30 år i olika former. En databas där vi har gemensamma definitioner och beräkningar av våra viktigaste nyckeltal och hur de förhåller sig till varandra – En strävan efter ”a Single version of the Truth” för en organisation där det är lätt att konsumera högkvalitativ information för många bättre beslut.
Att bygga ett Data Warehouse är per definition att försöka skapa ordning och reda, så att fler kan arbeta mer datadrivet på ett enklare och snabbare sätt utan att behöva bekymra sig allt för mycket om kvaliteten på data och om vems siffror som egentligen stämmer.
För drygt 10 år äntrade Big Data scenen med buller och brak med helt nya förmågor att lagra och bearbeta filer av olika typer i stora volymer. Med tiden kunde vi se ett parallellt spår bildas med dataplattformar baserad på olika varianter av Hadoop-lösningar, som vi på senare tid har börjat samla under begreppet Data Lakes. Ofta drivet av förmågorna kring att hantera just stora, snabba eller komplexa data, andra med en önskan att mer fokusera på analysförmågan snarare än rapportering.
I en modern dataplattform i molnet är det dock ofta inte så svartvit som det ibland utmålas, vi har länge nyttjat Data Lakens fördelar tillsammans med databasens styrkor i den totala plattformen. Med modern DevOps och möjligheten att skala prestanda har också minskat den initiala kostnaden att införa ett Data Warehouse dramatiskt. De som satsat på en Data Lake strategi har ofta börjat bygga på flera olika lager i sin struktur för att bättre kunna återanvända beräkningar och få bättre struktur på sitt data. Så vilka huvudsakliga utmaningar adresserar egentligen ett Data Lakehouse?
Att definiera en informationsmängd med ett Schema är bra för att skapa tydlighet för användarna och öka graden av återanvändbarhet och datakvalitet. Det blir ett tydligt gränssnitt där information presenteras på ett enklare sätt än bara en hög med filer som ofta görs i en Data Lake. Något som kräver stor kunskap för att göra ett korrekt utdrag och detta är något som Data Warehouses alltid varit väldigt noga med.
Ett problem som dock uppstår när man behandlar lite större datamängder i ett Data Warehouse är att data behöver flyttas igenom olika lager i en databas (schema-on-write), ofta i enlighet med en standardiserad ETL-process. Något som ofta tar tid, datorkraft och ökar risken för att någon del inte ska fungera. Om du dessutom kommer på vid ett senare tillfälle att du vill behandla om datat på ett annat sätt kan detta innebär långa och komplicerade omladdningar. Här finns stor potential med att separera beräkningslogiken från lagringen, så länge vi kan få tillräckligt bra prestanda i utläsningen.
Data Lakehouse löser detta genom problem genom Schema-on-Read, d.v.s. att inte fysiskt behöva skriva ner datat på disk utan mer som vyer på en mängd filer.
En enkel sak som att ha bra ordning och reda på sina dimensioner, som t.ex. kunder, produkter och avdelningar är en utmaning om du byggt en lösning baserat på filer i en Data Lake. I ett Data Warehouse är detta sällan ett problem, antingen uppdaterar man en kundrad med senaste informationen eller så har du någon typ av historikhantering. Detta är inte helt trivialt att lösa om kundinformation ligger utspridd i en massa filer och du kan tvingas läsa igenom tusentals filer för att hitta vilken adress en kund hade för ett år sedan.
Här finns stor potential att snabba upp processen framför allt för de som jobbar med friare analyser, och även öka kvaliteten i analyserna. I ett Data Lakehouse ska detta fungera lika smidigt som i en databas, men det ser väldigt olika ut beroende på leverantör och implementation.
En plattform för att stödja behoven från både Data Science och traditionell BI möjliggör att vi i högre grad kan nyttja och produktionssätta avancerade analyser i rapporter, dashboards och i operativa processer. Ofta finns det stora värdet av avancerad analyser när dessa kommer i stor användning, där de många små besluten kan optimeras. Kan teamen dessutom jobba mer tillsammans så minskar risken för dubbelarbete och vi kan få ut mer ännu mer värde i affärsverksamheten.
Jag tycker man ständigt ska utmana sättet vi jobbar på för att se om det går att göra bättre och mer effektivt. Det finns mycket att vinna på att inte fastna i att man t.ex. måste ha en databas för att bygga ett Data Warehouse, och vi har sett otal exempel på misslyckade försök med att t.ex. bygga finansiell rapportering ovanpå en Data Lake där det ofta slutat med att det ändå byggts en databas ovanpå Data Laken. Datakvaliteten i en Data Lake utan väldigt hård och strikt styrning stagnerar alltid i kvalitet med tiden.
Vad jag kan bedöma är en Data Lakehouse inget annat än en naturlig evolution av ett Data Warehouse fast utan att använda en databas. Vi kommer garanterat se en utveckling i den riktningen framöver, och vägen dit är troligen någon slags hybridvariant. Så fundera på de förutsättningar och behov som finns i din organisation, samtidigt som det viktigaste faktiskt är att börja bygga. Med en bra struktur i dina lager och bra meta-datastyrning är det lätt att justera vid ett senare tillfälle.
Hvis I som mange andre virksomheder bruger Microsoft Teams og også arbejder i fællesskab om at analysere eller forecaste med data, så er der godt nyt. Der er i Januar 2023, kommet en opdatering til Power BI integrationen i Teams og det gør det nu endnu nemmere at dele rapporter og indsigter med dine kollegaer.
Du kan dele Power BI-rapporter og dashboards i Teams-kanaler, så alle kan se og samarbejde om dataene. Du kan også bruge Teams-funktioner som kommentarer og @-mentions til at samarbejde og diskutere rapporter og data.
For at komme i gang skal du først oprette en Power BI-konto og derefter integrere den med Teams. Derefter kan du dele rapporter og dashboards med dine kolleger ved at indsætte dem i en Teams-kanal.
Når du har delt en rapport eller et dashboard, kan du og dine kolleger interagere med dataene ved at tilføje kommentarer, stille spørgsmål eller anvende @-mentions. Dette gør det nemmere at samarbejde om dataanalyse og beslutningstagning.
Så kort og godt, Power BI i Microsoft Teams gør det nemt for dig at samarbejde med dine kolleger om data og træffe datadrevne beslutninger.
Er i endnu ikke kommet i gang med at analysere data eller mangler hjælp til at komme i gang med et BI-projekt eller Power BI så kontakt Random Forest til en uforpligtende snak om hvordan vi kan hjælpe jer. I kan også læse mere på vores hjemmeside her.
|
|