Tilbage

7 faldgruber i Data Warehouse - del 4

Det store Data Warehouse problem. Dette er den fjerde 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.

Presset til at forsætte, kommer fornemmelsen af at organisationen begynder at tvivle på projektet. Omkostningerne og den tid der er forbrugt lever ikke op til den leverance organisationen har fået.

Ydermere er forsøget på at håndtere fragmentationen i data gået langt over gevind, og realiteterne i at situationen nu kun er endnu værre er næsten ironisk.

Uanset hvad, så lyver data ikke. Så længe det kan komme frem til Data Warehouse og ud til slutbrugerne i korrekt og brugbare resultater på den ene eller den anden måde, så skal det nok gå. Men....

Data lyver

Ved gennemgang af website data og trafik i Data Warehouse, opstår en række åbenlyse problemer.

Brugerne som tilgår systemet, bliver nu pludseligt talt dobbelt, hvis de både tilgår via mobil og en desktop. Selv om før omtalte identity management system er sat korrekt op. Data fra sessionerne er ikke retvisende.

Server-side sessionsstyring burde have løst problemet, men det er langt mere komplekst end først antaget. Tidsstempler fra de forskellige platforme konflikter og tidszonerne blandet ind, gør det kun værre.

Yderligere, så skulle det have været sat op, så en ny brugers tidligere genererede data skulle sættes sammen med den nye oprettede profil. Sessionsstyringen kræver en meget mere kompleks algoritme for at kunne håndtere processen i at sammensætte de unikke bruger-ids fra de forskellige events.

For resten, glem ikke al den offline data der bliver genereret fra den ny-udviklede app.

Det ender med at være 2-3 forskellige events for hver bruger med et forskelligt billede at den rejse brugeren har gjort på websitet. En samlet rejse kan ikke sammensættes ud fra eksisterende data. Identity management virker i teorien, men virkeligheden er en helt anden.

Krydret med at ca 20% af alle brugere anvender en eller anden form for ad-blocker, gør at data kun bliver mere skævt end realiteterne.

Hold planen og forventningerne

Marketing banker nu på døren og undrer sig over hvordan de nu skal kunne sammenligne deres dyrt brugte reklamepenge med brugerens adfærd. De blev lovet tydeliggørelse af deres investering gennem data. I stedet har de nu kun en stor bunke fragmenteret data med forskellige aftryk fra brugerne som ser ud til at være forskellige alle sammen.

I det mindste har produkt teamet den fornøjelse at deres brugere kun kan handle hvis de har en profil, så data herfra er direkte brugbart. Men det hjælper ikke rigtigt på det faktum at teamet med et budget på flere millioner ikke kan se forholdet mellem omkostningerne og konverteringerne.

Ironisk nok, så har de eksisterende systemer en langt bedre indsigt til en lavere pris.

Der eksisterer nu pr faktum flere events for den samme bruger og flere sessioner for en enkelt bruger på tværs af platforme. Data er ikke længere retvisende.

Brandslukning

Der er nu gået 6 måneder siden projektet startede op og ledelsen at begyndt at tale omkring deres usikkerhed på succesen. Projektet er langt bagud planen og allerede langt over budget. Databasen til slutbrugerne er endnu ikke helt på plads og de forespørgsler der bliver udført giver svar alt for langsomt.

Overbevisende bliver der talt med ledelsen med forsikring om at investeringen nok skal komme igen. Det er blevet tid til at optimere på forespørgslerne.

Dynamisk partitionering bliver implementeret på Data Warehouse for at allokere datastorage korrekt og muliggøre at det kun er det seneste data der bliver udskiftet. Resten kan forblive i memory. Der arbejdes nu med optimering af dataudtræk og jobbet bliver sjovt.

Det går dog op for en at den måde data er gemt på, alligevel ikke er så optimal og kost-effektiv. Gennemsnitlig svartid er langt fra de første forventninger. Hvad sker der?

Det at optimere en specifik forespørgsel er let nok, men at optimere på et generelt niveau er næsten umuligt. Men det er jo omkostningen ved en fleksibel arkitektur i et Data Warehouse - eller er det?

Forsøget med at skalere de mange milliarder af rækker uden at have de korrekte kompetencer hos DBA'en gør at man arbejder solen sort. Man kan måske forsøge sig med noget smart hashing og caching mekanismer for at optimere forespørgsler i runtime.

Det ser ud til at virke ok, men det er pludselig på bekostning af det implementerede elastiske Data Warehouse. Og erkendelsen af at der bliver behov for ekstern hjælp er nu evident.

Hvad er billigst? At ansætte en fuldtids DBA eller lege katten efter musen i et fuld dynamisk setup?

Mister troen på egen plan

Ved fælles hjælp i teamet får man udarbejdet en rapport til ledelsen. De er bestemt ikke tilfredse med resultaterne. De blev lovet en analytisk platform i form af et Data Warehouse for 3 måneder siden og der er endnu ikke leveret noget færdigt produkt. Heller ikke delvist.

Hvis marketing kan søsætte deres initiativer rettidigt, hvorfor kan dette så ikke? Det er jo bare et Data Warehouse.

Opbakningen fra nøglepersoner og ledelsen er ved at ryge en tur. Projektet er for omkostningstungt og under på randen af nedlukning. Medarbejdere i organisationen er begyndt at tale om at "trække stikket" og fordele de afsatte penge til andre projekter.