Tilbage

7 faldgruber i Data Warehouse - del 2

Koncepter og planlægning. Dette er den anden af i alt 7 artikler om de 7 faldgruber, som BI Architect Brian Bønk Rueløkke gennem tiden er stødt på i sit arbejde med Data Warehouse.

Opbygning af konceptet: Data Warehouse

Hvis du har besluttet dig for at investere den rette mængde tid i at opbygge et Data Warehouse, er det også vigtigt at planlægge og konceptualisere korrekt fra starten af.

Det skal kunne behandle alle former for data, struktureret, semi-struktureret (selv de bleeding edge irriterende nestede JSON filer), og gemme det i et let tilgængeligt og forståeligt format baseret på hurtige svartider.

Men hvad skal med?

At foregribe strukturen på al dette data, vil tage uforholdsmæssigt lang tid og arbejde, særligt hvis du overvejer at opbygge en tilpasningsparat løsning der kan understøtte forretningen. Så beslutningen omkring noget selv-lærende ETL system der kan læse al data i hele verden er ikke så lang.

Særligt omkring marketing og produkt teams. Her skal man være klar til at håndtere al den forskelligartede data som kollegerne herfra kan generere. Husk på at web-data er født med skidte formater. Selv-lærende ETL er nu endnu tættere på, men det skal kunne mere endnu.

At sammenkoble data fra web med data fra mobile enheder er noget som nogen af de allerede anvendte services er super gode til. Denne del skal også planlægges med i løsningen (på én eller anden måde).

Og hvis endelig det er lykkedes at sammensætte data mellem web og mobile enheder, så skal der også udvikles noget identity management som sikrer at brugerenes genererede events fra både mobil og web bliver opsamlet korrekt og gemt med de rette bruger-id's.

Husk også at håndtere alle de (irriterende) brugere som tilgår websitet anonymt og som ikke har lavet en profil. Så her skal der måske kigges på nogen historiske elementer som kan sammenkædes med et enheds-id for at gruppere disse brugeres adfærd. Når så brugeren endelig opretter en profil på sitet, skal man også huske at associere denne nye profil med de historiske handlinger. Let og simpelt, som forretningsbrugerne vil have det.

Lækkert - med al den data. Men hvor skal den opbevares?

Storage

Skal der være en tabel pr type af event fra websitet eller skal der oprettes én stor tabel med alle events - eller noget midt imellem? Hvis der skal opretholdes de tidligere nævnte hurtige svartider skal data i alle tilfælde gemmes i nogen kolonner. Så der skal lidt dataarbejde til, det kan hurtigt blive svært at håndtere.

Når så beslutningen omkring storage og ETL er sat og de første spadestik til datastrukturerne er begyndt, så kommer realiteterne fra hverdagen. Der er måske ikke tid nok i "off-hours" til at loade al data, så der skal tænkes i nye retninger for at få data ind og ud hurtigt nok. Tilmed kommer der måske nogen data-scientists fra analyseafdelingen som kun kan bruge ODBC eller JDBC forbindelser til at loade data til deres smarte "jeg kan forudsige verden"-systemer .

Den store specifikation vokser dag for dag.

Langtidsplanlægning og godkendelse fra direktionen

Det er nu tid til at se på den samlede løsning og hvor langt hele processen kommer til at strække sig over. For korrekt at kunne estimere størrelser på diske, skal man også kunne estimere de forventede datamængder i fremtiden.

Ved gennemgang af disse simple analyser som både marketing og produkt-teamet har, kommer det frem at der er ca 100.000 aktive brugere om måneden med hver ca 5 sessioner med 60 events i snit pr session.

Mere end der var planlagt

Beregningerne viser at der bliver genereret mere end 30 millioner events pr måned. Wow - det er lidt mere end først antaget og planlagt.

Uanset hvad, så kan det hurtigt ske at budgettet for hele forretningen bliver højere, og dermed skal der endnu flere brugere på websitet og dermed endnu flere events og sessioner. Det kan hurtigt fordoble tallet, eller måske tredoble det, især hvis marketing gerne vil analysere på flere events end de gør nu.

Meeen, frygt ikke, elastic scaling er opfundet.

En note hertil. Hvis forretningen går som forventet, så rammer datamængderne sandsynligvis milliarder for rækker der er opsamlet inde for, skal vi sige, 3 år. Dette dog uden at tænke på forretningens generelle udvikling.

Uanset hvad, så vil en hjemmebygget løsning langt overgå de standard løsninger vi omtalte i første del af denne serie.

Omkostningerne - lad os se på dem.

Cloud computing og services er faldet meget de seneste par år, så den samlede løsning er nu endnu mere økonomisk rentabel end hvis den var startet for 3 år siden. Alligevel skal der skeles til den øgede datamængde og tilvækst i samme. En hurtig beslutning kan være at finde en løsning, hvor services betales delt - én regning for storage og én for regnekraft.

Nu er planen så langt at den skal godkendes for direktionen.

Præsentation til C-level

De skal kun bruge en "return of investment" rapport på det samlede projekt for at give grønt lys, så en hurtig analyse på hvor meget dårlige data og manuelle processer koster i organisationen. Selv om man har lavet mange analyser af denne slags, kan jeg godt stadig blive overrasket over hvor meget der egentlig er at finde rundt omkring.

Det kan hurtigt blive en let sag at få overbevist direktionen om beslutningen. På trods af at Gartner beskriver at omkring 60% af disse projekter bliver efterladt og lukket inden de er færdige.

Uanset hvad, så bliver du, på baggrund af den udarbejdede PowerPoint, mødt med accept (til stor overraskelse).

Der er ikke længere nogen tvivl omkring ledelsens og direktionens gennemlæsning af populærlitteraturen og er vilde for at transformere organisationen til at være "data drevet".

Det er det. Nu er de indledende ben-strækninger på plads. Vision, budget og ressourcerne er på plads. Målet kan nu opfyldes og arbejdet kan gå i gang.

Det kan umuligt gå galt.

Næste gang vil jeg skrive lidt om at opretholde leverancerne og arbejde med forskellige perceptionsniveau'er i organisationen.

Lidt links til at læse mere om datadrevne organisationer:

Hvorfor den pseudo data-drevet organisation er god nok for de fleste

Hvorfor vil jeres sælgere ikke være data-drevet?