Data Warehouse Arkitektur Princip #2 - Skalerbar | Erik Haahr
Blog

Data Warehouse Arkitektur Princip #2 - Skalerbar

Ordsproget ‘Tænk stort – start småt’ giver særdeles god mening I forbindelse med opbygningen af et data warehouse.

Ultimativt vil et data warehouse i en succesfuld virksomhed blive stort. Det vil dog som oftest tage for lang tid (og være for dyrt) at forsøge at bygge et komplet data warehouse fra begyndelsen. Derfor vil de fleste starte med at bygge et data warehouse, der understøtter de mest kritiske udækkede analysebehov.

Herefter skal det være muligt at udvide data warehouse til at omfatte flere analysebehov, flere brugere, større data mængder osv.

Både den teknologiske platform og det logiske design skal være forberedt på disse udvidelser – Uden viden om hvilke udvidelser der vil blive behov for og hvornår disse behov vil opstå.

En måde at sikre skalerbarhed på er at fjerne serielle afhængigheder – altså at en proces er afhængig af at en anden proces afslutter succesfuldt før den selv kan begynde. Med andre ord så meget som muligt skal parallelliseres.

Ekstra hardware ressourcer skal kunne tilføjes fortrinsvis i form af identiske komponenter så administration og vedligehold holdes på et simpelt niveau. MPP (Massively Parallel Processing) systemer med en ”shared nothing” arkitektur er klart at foretrække i denne forbindelse, da der også internt i disse systemer er så få flaskehalse som fysisk muligt.

På data modelleringssiden er tredje normalform (3NF) et godt bud på en model der løbende kan udvides uden negative konsekvenser for allerede eksisterende løsninger. Med et stjerneskema vil du hele tiden skulle afveje om du vil skal øge kompleksiteten og sænke performance for eksisterende løsninger eller om du hellere vil skabe et nyt sæt af delvist redundante data med øget administration, øgede hardwarekrav og øgede omkostninger til følge.

Transformationer af data bør foregå i databasen i stedet for i en dedikeret ETL server, da SQL-operationer på et datasæt kan parallelliseres (såfremt der er tale om en relationsdatabase) hvorimod den interne transformation i de fleste ETL-værktøjer foregår serielt. Det skal dog tilføjes, at nogle typer transformationer kun kan foretages serielt, det er bare min erfaring at disse er sjældne. De fleste ETL-værktøjer understøtter da også afvikling af transformationer i databasen (ofte kaldet ”push-down”).

0 kommentarer | >