Landingssone
Innen databehandling er en landingssone (engelsk: staging area) et mellomstopp for lagre data som skal prosesseres som en del av en ETL-prosess. Landingssonen er plassert mellom datakilden(e) og destinasjonen(e), som ofte er datavarehus, datatorg eller andre dataregistre.[1]Landingssoner er ofte transient av natur ved at innholdet kan bli slettet før man kjører en ETL-prosess eller rett etter at en prosess har kjørt. Det finnes imidlertid også arkitekturer for landingssoner som er designet for å holde på dataene i lengre perioder for å muliggjøre arkivering eller feilsøking.
En vedvarende landingssone (engelsk: persistent staging area, PSA) en type landingssone i datavarehus som tar vare på hele endringshistorikken til en kildetabell eller -spørring.[2]
Implementasjoner rediger
Landingssoner kan implementeres i form av tabeller i en relasjonell database, tekstbaserte filer lagret i et filsystem, eller proprietært formaterte binærfiler lagret i filsystemer.[3] Arkitekturen på en landingssone kan variere i kompleksitet fra en mengde enkle relasjonstabeller i destinasjons-databasen til egne databaseinstanser eller filsystemer.[4] Selv om kilde- og destinasjonssystemet i ETL-prosesser ofte er relasjonelle databaser behøver ikke landingssonen som ligger mellom datakilde- og destinasjonene være en relasjonell database.[5]
Funksjoner rediger
Landingssoner kan utformes med mange funksjoner, men den primære motivasjonen er å øke effektiviten til ETL-prosesser, sikre dataintegritet, og støtte sikring av datakvalitet. Eksempler på funksjoner til en landingssone inkluderer følgende:
- Konsolidering
- Datatilpasning (alignment)
- Minimere uoverensstemmelse (contention)
- Uavhengig skedulering/ flere destinasjoner
- Fangst av dataendringer
- Datavask
- Forhåndsutregning av aggregeringer
- Dataarkivering og feilsøking
Konsolidering rediger
En av de primære funksjonene til en landingssone er å konsolidere data fra flere kildesystemer.[3] På denne måten fungerer landingssonen som en stor "bøtte" hvor data fra flere kildesystemer kan samles opp midlertidig for videre behandling. Det er vanlig å merke data i landingssonen med ekstra metadata som viser opprinnelsested og tidsstempel som angir når dataene ble plassert i landingssonen.
Datatilpasning (alignment) rediger
Samkjøring av data omfatter standardisering av referansedata på tvers av flere kildesystemer og validering av relasjoner mellom oppføringer og dataelementer fra ulike kilder.[3] Datatilpasning i landingssonen er en funksjon som er nært knyttet til og støtter opp under grunndataforvaltning.[6]
Minimere uoverensstemmelse (contention) rediger
Landingssonen og ETL-prosesser som den støtter er ofte laget med et mål om å minimere motstridende informasjon i kildesystemer. Kopiering av alle nødvendige data fra kildesystemer til en landingssone på en gang er ofte mer effektivt enn å hente individuelle oppføringer (eller en liten mengde oppføringer) ved behov på grunn av at man kan utnytte teknisk effektivitet på grunn av gode strømmeteknologier, mindre overhead, samt at man unngår samtidighetslåser i kildesystemer.
Uavhengig skedulering/flere destinasjoner rediger
Landingssonen kan støtte hosting av data som skal prosesseres etter uavhengige tidsplaner, samt data som er ment for flere destinasjoner.[3] I noen tilfeller kan data bli hentet inn til landingssonen til forskjellige tider for å bli oppbevart og behandlet samtidig på et senere tidspunkt. Som et eksempel kan daglige driftsdata bli dyttet over til et operasjonelt datalager (ODS) mens de samme dataene kan sendes i en månedlig aggregert form til et datavarehus.
Oppfanging av dataendringer rediger
Landingssonen kan støtte opp under effektiv deteksjon av endringer i datasystemer. Dette er særlig nyttig når kildesystemer ikke støtter pålitelige former for fangst av dataendringer eller tidsstempler som håndheves av system.
Datavask rediger
Datavask omfatter identifisering og fjerning eller oppdatering av ugyldige data som kommer fra kildesystemene. En ETL-prosess som benytter seg av landingssonen kan brukes til å implementere forretningslogikk for å identifisere og håndtere "ugyldig" data. Ugyldige data kan ofte defineres gjennom en kombinasjon av forretningslogikk og og tekniske begrensninger. Tekniske begrensninger kan også håndteres i landingssonen (for eksempel tabellbegrensninger i en relasjonsdatabase).[3]
Forhåndsutregning av aggregeringer rediger
Forhåndsutregning av aggregeringer, komplekse beregninger og anvendelse av kompleks forretningslogikk kan gjøres i en landingssone for å støtte svært responsive tjenestenivåavtaler for rapportering i destinasjonssystemer.[4]
Dataarkivering og feilsøking rediger
Dataarkivering kan utføres i eller støttes av en landingssone. I dette scenariet kan landingssonen brukes til å opprettholde historiske oppføringer under lasteprosessen, eller for å dytte data til et arkiv i destinasjonen. I tillegg kan dataene opprettholdes innenfor landingssonen for lengre perioder av gangen for å støtte teknisk feilsøking i ETL-prosessen.[4]
Referanser rediger
- ^ Oracle 9i Data Warehousing Guide, Data Warehousing Concepts, Oracle Corp.
- ^ «Persistent Staging». Data Warehouse Automation - Dimodelo Solutions (engelsk). Besøkt 22. april 2023.
- ^ a b c d e Data Warehousing Fundamentals: A Comprehensive Guide for IT Professionals, p. 137-138, Paulraj Ponniah, 2001.
- ^ a b c BI Experts: Big Data and Your Data Warehouse's Data Staging Area, The Data Warehousing Institute, Phillip Russom, 2012.
- ^ Is Data Staging Relational? Arkivert 26. desember 2013 hos Wayback Machine. Arkivert 2013-12-26 hos Wayback Machine, Ralph Kimball, 1998.
- ^ Master Data Management in Practice: Achieving True Customer MDM, Dalton Cervo and Mark Allen, 2011.