Rapporter uppdaterade i realtid är en våt dröm för beslutsfattare. Här är ett antal koncept att betänka för att påbörja arbetet med att förena två traditionellt sett oförenliga världar – datalagret och realtidsanalysen.
Med rapporter uppdaterade i realtid kan beslutsfattare till exempel följa sina ordrar och transaktioner i samma ögonblick som de skapas. IT-folket pratar samtidigt mycket om nyttan med ett så kallat datalager (d.v.s. data warehouse) som bottenplatta för all analys och rapportering. Nyttan med att lyfta data och analys in i en egen miljö är ofta mycket stor, men innebär för de flesta en fördröjning från det att en post skapas i ett transaktionssystem tills det att den syns i rapporter eller tillgängliggörs för analys.
Rapportering mot källsystemet – bra och dåligt
Ett traditionellt datalager kräver dataladdningar från transaktionssystemet vilket skapar fördröjningar, samt i tillägg tidskrävande dataförflyttningar inom datalagret, för att tillgängliggöra de senaste uppdateringarna för rapportering och analys. Detta leder till att realtidsanalyser ofta görs direkt mot källsystemet, där ju datat finns tillgängligt så snart en post skapats. Rapportering sker då antingen med hjälp av källsystemets egna verktyg eller med externa varianter.
Hämtning av data direkt ur källsystemet innebär flera utmaningar;
- Källsystemens egna oftast bristfälliga funktionalitet rörande analys – begränsat!
- Långa ledtider från själva databasuppslaget (SQL-frågan som ställs av rapportverktyget mot databasen) till presentationen – segt!
- Hög belastning på minne och processor på den maskin där källsystemet ligger. Detta kan skapa problem även för de som jobbar inne i de kritiska vardagliga processerna (exempelvis för de som jobbar med inköp eller finans i ERP-systemet) – riskfyllt!
- Endast en datakälla per rapport eller analys. Man tappar med andra ord möjligheten att utföra analys på data kombinerad från flera olika system – begränsat!
Trots dessa utmaningar lämpar det sig ibland väl att rapportera direkt mot källsystemets data då det ibland helt enkelt är smidigast och ”good enough”. Men om man har en tilltro till att data är en viktig tillgång och en nyckel till affärsnytta och konkurrensfördelar, så är sannolikt nyttjandet av ett datalager imperativt.
Hur kan datalagret få löpande tillgång till aktuell data?
Det finns flera fördelar med att lägga ett datalager på toppen av ett eller flera källsystem. En av de stora nyttoeffekterna är att datat kan enhetliggöras, stuvas om och optimeras för analys. Datalagret skall byggas med krav på analys i åtanke, vad gäller såväl strukturer som prestanda och tillgänglighet.
Förflyttning av data från källsystem till datalager är ofta en flaskhals då stora datavolymer ska laddas över vid ett och samma tillfälle. Även om inkrementella laddningar (som bara omfattar ny eller ändrad data) sätts upp så kan dataladdningen löpa i allt från timmar till dagar. Dessutom tenderar dessa körningar att schemaläggas för exekvering en gång per dag eller en gång per månad, beroende på område och behovsbild. Laddningen i sig är alltid en belastning på processorer och minne vilket också kan störa affärsverksamheten.
Jaha, hur löser vi då detta med sega, schemalagda dataladdningar? Hur kan vi få över transaktioner till ett datalager i realtid? Beroende på förutsättningar och målbild finns det olika vägar framåt, exempelvis:
- Det finns idag avancerade minnesdatabaser som är lämpade att simultant stödja såväl transaktionssystem som analyssystem. Här snurrar alltså exempelvis ERP- och CRM-systemet tillika datalagret på samma databas/plattform vilket då till stor del eliminerar behovet av dataladdningar.
- Med hjälp av CDC (Change Data Capture) -teknik, kan man fånga och flytta förändringar som sker i ett källsystems databas (exempelvis ny order eller förändring av faktura) till valfri mottagare i realtid. När en ny rad läggs till i en tabell eller om ett värde förändras i ett fält kan man med hjälp av CDC omedelbart agera och flytta ut posten till staging-ytan i ett datalager. Här ges alltså möjligheten till analys av data i en mer ändamålsenlig miljö, i samma ögonblick som datat genererats i källsystemet.
- ESP (Event Stream Processing) är en teknik som handlar om att fånga och bearbeta strömmande data för att sedan tolka och simultant förmedla viktiga händelser i denna till exempelvis ett datalager. Denna teknik skiljer sig från CDC som läser data från databasloggar.
Hur kan du effektivisera datahanteringen i själva datalagret?
En naturligt påföljande tanke för den som förstår hur ett datalager funkar är att realtidsladdningar inte med självklarhet är synonymt med realtidsanalys. Detta i och med att det traditionella datalagret är uppbyggt i flera lager: staging – DW – data mart – kub, som i sin tur kräver interna förflyttningar av data. Med hjälp av genomtänkt design kan du dock komma en bra bit på vägen:
- Det finns idag teknik som bygger på utnyttjande av internminnet på servern för lagring istället för en klassiskt spinnande magnethårddisk. Detta har revolutionerat datalagrens design och de flesta datalagerleverantörerna har idag en ”in-memory”-variant att erbjuda (antingen helt eller delvis). Detta innebär att de klassiska lagren i ett datalager inte längre behövs.
- Mycket kan göras bara genom att ändra designen av det traditionella datalagret. Ofta finns exempelvis möjlighet att jobba med push-teknik, som till skillnad från de klassiska schemalagda dataförflyttningarna, möjliggör att laddningar genereras omedelbart vid förändringar i det underliggande lagret.
- Det går också att jobba med vyer istället för fysiska tabeller för att helt motverka fysiska dataförflyttningar. Nackdelen med denna approach är att databasuppslagen tar längre tid vilket kan sinka analysarbetet.
- Vad gäller OLAP (klassisk kub-teknologi) så finns två varianter; MOLAP och ROLAP, där ROLAP innebär att datat inte fysiskt förvaras i kuben utan att det hämtas i den underliggande ”datamarten” i direkt samband med att SQL-frågan ställs via ett rapporterings- eller analysverktyg. Detta ökar tidsåtgången för databasuppslaget, men motverkar behovet av ytterligare en dataförflyttning, vilket på det sättet sparar tid.
- Ytterligare en tanke är att man måhända inte alltid behöver ställa frågan (SQL-) mot en kub eller en data mart (det vill säga mot ett lager högt upp). Ibland duger det att gå direkt på de staging-vyerna (det första lagret) som även dessa möjliggör mer flexibilitet, högre prestanda och transparens än ett uppslag mot källsystemet, om de designas smart.
Arkitekturen ska bygga på affärsförståelse
Så även om det kan innebära en kompromiss mellan tillgänglighet av data realtid och ”query prestanda” kan man, genom förståelse för hur datat ska användas i det dagliga arbetet, designa ett datalager att så effektivt som möjligt möta krav på realtid där det verkligen är viktigt (ibland matchar inte drömmen om realtid verklig affärsnytta) och samtidigt leverera den transparens, flexibilitet och prestandaförbättring som ett klassiskt datalager innebär.
Rent arkitektoriskt ligger utmaningen i att, genom förståelse för hur den verkliga användningen av datat kommer att se ut, designa ett datalager som är affärsoptimerat baserat på den typ av analys eller rapportering som ska utföras mot det. Strukturerna i datalagret kan och bör alltså se olika ut beroende på om scenariot är absolut realtid eller om det är okej att ett visst subset av data kan tillgängliggöras med viss fördröjning.
Vill du veta mer?
Fyll i din e-postadress så hör vi av oss inom kort.