Skip to content

Ett datalager eller inte ett datalager är frågan?

Denna vecka har jag deltagit i flera möten avseende datalager och dess modellering. Inom detta område finns allt fler skolor och idéer.  I en lösning diskuterades hur en Qlikview lösning skiljer sig från en dimensionsmodelleringsbaserad. I ett annat uppdrag kom krav på en specialrapport till datalagret där varje rad skall beräknas för sig. Hur löser man detta på bästa sätt?

Jag håller också på med ett projekt kring en datalagerverktygsuppgradering vilket innebär att jag gör en review av nuvarande lösning och ger förslag på framtida lösning. Här ser jag att mycket har förändrats och använts olika genom åren. Vad skall skrivas om tas bort eller ändras?

Ovanstående problem visar att det finns många olika alternativ för BI/DW och dess arkitektur.

Här kommer några arkitekturalternativ för ovanstående frågeställningar.

  • Bygg ett normaliserat datalager enligt tredje normalform
  • Låt användarna direkt göra rapporter mot källssystemen
  • Indexera all data och använd ett sökverktyg för att hitta data
  • Ta in alla data i en modell exempelvis qlikviews associerade och bygg lösningen i verktyget
  • Bygg ett denormaliserat datalager med dimensionsmodellering
  • Lägg ut all data från legala system och extern data i en sjö(datalake)
  • Använd källsystemens rapportgeneratorer
  • Bygg ett datavault datalager
  • Lägg in all data i hadoop
  • Låt de självbetjänade verktygen själva blenda data i analysen
  • Bygg ett egenutvecklat program för analysen
  • Blanda datalager med olika egna källor
  • Kombinera ovanstående

Tittar man på dessa så finns det några klassiska saker att beakta.

Vad bör hanteras i källsystemen, vad skall hanteras vid integration, vad skall hanteras avseende historik, hur skall förändringar hanteras, hur skall realtid hanteras, hur frigörs data från källsystemen, hur hanteras api och webserviceanrop och hur skall icke komplett data hanteras.

Många av dessa frågor är av strukturkaraktär kopplade till datakvalitet och blir därför lätt IT-drivna. De icke funktionella kraven från verksamheten blir en av ingångarna för dessa. Annars utgår man ju idag nästan alltid från verksamhetens krav, behov och värde.

För några år sedan hade jag förespråkat en gemensam lösning för ovan i ett enterprise datawarehouse. Idag ser jag lite olika lösningar för de olika delarna där man utifrån hela informationsflödets paraply tillhandahåller olika kontrollerade lösningar.

Återkom om ni vill veta mer om detta!

Håkan

hakan.alsen@knowit.se