Hvad er ETL-proces (ekstrakt, transformation, indlæsning) i datalageret?

what is etl extract

Denne dybdegående vejledning om ETL-proces forklarer procesflow og trin involveret i ETL-processen (ekstraktion, transformation og belastning) i datavarehus:

Denne tutorial i serien forklarer: Hvad er ETL-proces? Dataekstraktion, transformation, indlæsning, flade filer, hvad er iscenesættelse? ETL-cyklus osv.

Lad os begynde!!

=> Tjek den perfekte træningsvejledning til datalager her.

Hvad du lærer:

• ETL (Extract, Transform, Load) Process Fundamentals
  • Hvad er ETL-proces i datalager?
  • Dataekstraktion
    • Ekstraktionsmetoder i datalager
    • Uddrag af ændrede data
  • Datatransformation
    • Sådan implementeres transformation?
  • Data indlæses
  • Flade filer
    • Behandling af faste længde flade filer
    • Behandler afgrænsede flade filer
  • Formål med iscenesættelsesområde
  • Design af iscenesættelsesområdet
  • ETL procesflow
• Konklusion
  • Anbefalet læsning

ETL (Extract, Transform, Load) Process Fundamentals

Målgruppe

• Datalager / ETL-udviklere og testere.
• Databaseprofessionelle med grundlæggende viden om databasekoncepter.
• Databaseadministratorer / big data-eksperter, der ønsker at forstå Data warehouse / ETL-områder.
• College-kandidater / Freshers, der leder efter datalagerjob.

Hvad er ETL-proces i datalager?

Vi ved alle, at datalager er en samling af enorme datamængder, der giver information til forretningsbrugere ved hjælp af Business Intelligence-værktøjer.

For at tjene dette formål skal DW indlæses med jævne mellemrum. Dataene i systemet samles fra et eller flere operationelle systemer, flade filer osv. Processen, der bringer dataene til DW, er kendt som ETL-proces . Ekstraktion, transformation og indlæsning er ETL's opgaver.

# 1) Ekstraktion: Alle de foretrukne data fra forskellige kildesystemer såsom databaser, applikationer og flade filer identificeres og ekstraheres. Dataekstraktion kan fuldføres ved at køre job i ikke-åbningstider.

# 2) Transformation: De fleste af de udpakkede data kan ikke indlæses direkte i målsystemet. Baseret på forretningsreglerne kan der foretages nogle transformationer, før dataene indlæses.

For eksempel, en målkolonnedata kan forvente to kildekolonner sammenkædede data som input. Ligeledes kan der være kompleks logik til datatransformation, der har brug for ekspertise. Nogle data, der ikke har brug for nogen transformation, kan flyttes direkte til målsystemet.

Transformationsprocessen korrigerer også dataene, fjerner eventuelle forkerte data og retter eventuelle fejl i dataene, inden de indlæses.

# 3) Indlæser: Alle de indsamlede oplysninger indlæses i måldatavarehustabellerne.

Dataekstraktion

Dataekstraktion spiller en vigtig rolle i designet af et vellykket DW-system. Forskellige kildesystemer kan have forskellige dataegenskaber, og ETL-processen styrer disse forskelle effektivt, mens data ekstraheres.

' Logisk datakort ”Er et basisdokument til dataudvinding. Dette viser, hvilke kildedata der skal gå til hvilken måltabel, og hvordan kildefelterne kortlægges til de respektive måltabelfelter i ETL-processen.

Nedenfor er de trin, der skal udføres under design af logiske datakort:

• En datalagerarkitekt designer det logiske datakortdokument.
• Ved at henvise til dette dokument opretter ETL-udvikleren ETL-job, og ETL-testere opretter testsager.
• Alle de specifikke datakilder og de respektive dataelementer, der understøtter forretningsbeslutningerne, vil blive nævnt i dette dokument. Disse dataelementer fungerer som input under udvindingsprocessen.
• Data fra alle kildesystemerne analyseres, og enhver form for dataanomalier dokumenteres, så dette hjælper med at designe de rigtige forretningsregler for at stoppe med at udtrække de forkerte data i DW. Sådanne data afvises her selv.
• Når den endelige kilde- og måldatamodel er designet af ETL arkitekter og forretningsanalytikere, kan de gennemgå en tur med ETL-udviklerne og testerne. Ved dette får de en klar forståelse af, hvordan forretningsreglerne skal udføres i hver fase af ekstraktion, transformation og indlæsning.
• Ved at gennemgå kortlægningsreglerne fra dette dokument skal ETL-arkitekter, udviklere og testere have en god forståelse af, hvordan data strømmer fra hver tabel som dimensioner, fakta og andre tabeller.
• Enhver form for databehandlingsregler eller formler nævnes også her for at undgå udvinding af forkerte data. For eksempel, uddrag kun de sidste 40 dages data osv.
• Det er ETL-teamets ansvar at bore ned i dataene i henhold til forretningskravene for at frembringe alle nyttige kildesystemer, tabeller og kolonnedata, der skal indlæses i DW.

Logisk datakortdokument er generelt et regneark, der viser følgende komponenter:

Ekstraktionsdiagram:

Angiv om tidsvinduet for at køre jobbet til hvert kildesystem på forhånd, så ingen kildedata vil blive savnet under ekstraktionscyklussen.

Med ovenstående trin opnår ekstraktion målet om at konvertere data fra forskellige formater fra forskellige kilder til et enkelt DW-format, der gavner hele ETL-processerne. Sådanne logisk placerede data er mere nyttige til bedre analyse.

Ekstraktionsmetoder i datalager

Afhængigt af kilde- og måldatamiljøer og forretningsbehov kan du vælge den ekstraktionsmetode, der passer til din DW.

# 1) Logiske ekstraktionsmetoder

Dataekstraktion i et datalagersystem kan være en engangs fuld belastning, der oprindeligt udføres (eller) det kan være inkrementelle belastninger, der opstår hver gang med konstante opdateringer.

hvad er alfa- og betatest

• Fuld ekstraktion: Som navnet selv antyder, ekstraheres kildesystemdataene fuldstændigt til måltabellen. Hver gang denne form for ekstraktion indlæser hele aktuelle kildesystemdata uden at overveje de sidste udpakkede tidsstempler. Fortrinsvis kan du bruge fuld ekstraktion til de indledende belastninger eller tabeller med færre data.
• Inkrementel ekstraktion: De data, der tilføjes / ændres fra en bestemt dato, overvejes for trinvis ekstraktion. Denne dato er forretningsspecifik som sidste udpakkede dato (eller) sidste ordredato osv. Vi kan henvise til en tidsstempelkolonne fra selve kildetabellen (eller) der kan oprettes en separat tabel, der kun sporer detaljerne om udvindingsdato. Henvisning til tidsstemplet er en væsentlig metode under trinvis ekstraktion. Logik uden tidsstempel kan mislykkes, hvis DW-tabellen har store data.

# 2) Fysiske ekstraktionsmetoder

Afhængigt af kildesystemernes kapaciteter og begrænsningerne i data kan kildesystemerne levere dataene fysisk til ekstraktion som online-ekstraktion og offline-ekstraktion. Dette understøtter enhver af de logiske ekstraktionstyper.

• Online ekstraktion :: Vi kan oprette forbindelse direkte til alle kildesystemdatabaser med forbindelsesstrengene for at udtrække data direkte fra kildesystemtabellerne.
• Offline ekstraktion :: Vi opretter ikke direkte forbindelse til kildesystemdatabasen her, i stedet leverer kildesystemet data eksplicit i en foruddefineret struktur. Kildesystemer kan levere data i form af flade filer, dumpfiler, arkivlogfiler og tabellerum.

ETL-værktøjer er bedst egnede til at udføre komplekse dataekstraktioner, hvilket som helst antal gange for DW, selvom de er dyre.

Uddrag af ændrede data

Når den indledende indlæsning er afsluttet, er det vigtigt at overveje, hvordan man ekstraherer de data, der ændres fra kildesystemet yderligere. ETL Process-teamet skal designe en plan for, hvordan ekstraktion til de indledende belastninger og de inkrementelle belastninger implementeres i begyndelsen af ​​selve projektet.

For det meste kan du overveje strategien 'Revisionskolonner' for den inkrementelle belastning for at registrere dataændringerne. Generelt kan kildesystemtabellerne indeholde revisionskolonner, der gemmer tidsstemplet for hver indsættelse (eller) ændring.

Tidsstemplet kan blive befolket af databasetriggere (eller) fra selve applikationen. Du skal sikre nøjagtigheden af ​​revisionskolonnernes data, selvom de indlæses på nogen måde for ikke at gå glip af de ændrede data for trinvise belastninger.

Under den inkrementelle belastning kan du overveje den maksimale dato og klokkeslæt for, hvornår den sidste belastning er sket, og udtrække alle data fra kildesystemet med tidsstemplet større end det sidste belastningstidsstempel.

Mens du udtrækker dataene:

• Brug forespørgsler optimalt til kun at hente de data, du har brug for.
• Brug ikke Distinct-klausulen meget, da den forsinker udførelsen af ​​forespørgslerne.
• Brug SET-operatører som Union, Minus, Intersect forsigtigt, da det forringer ydeevnen.
• Brug sammenligningsnøgleord som lignende, mellem osv. I hvor sætning, snarere end funktioner som substr (), to_char () osv.

Datatransformation

Transformation er processen, hvor et sæt regler anvendes på de udpakkede data, før kildesystemdataene direkte indlæses i målsystemet. De udpakkede data betragtes som rådata.

Transformationsprocessen med et sæt standarder bringer alle forskellige data fra forskellige kildesystemer til brugbare data i DW-systemet. Datatransformation sigter mod kvaliteten af ​​dataene. Du kan henvise til datakortedokumentet for alle de logiske transformeringsregler.

Baseret på transformationsreglerne, hvis nogen kildedata ikke overholder instruktionerne, afvises sådanne kildedata inden indlæsning i mål-DW-systemet og placeres i en afvisningsfil eller afvisningstabel.

Transformationsreglerne er ikke angivet for kolonnedata med lige indlæsning (behøver ingen ændring) fra kilde til mål. Derfor kan datatransformationer klassificeres som enkle og komplekse. Datatransformationer kan involvere kolonnekonvertering, omformatering af datastruktur osv.

Nedenfor er nogle af de opgaver, der skal udføres under datatransformation:

# 1) Valg: Du kan vælge enten hele tabeldataene eller et specifikt sæt kolonnedata fra kildesystemerne. Valg af data afsluttes normalt ved selve udvindingen.

Der kan være tilfælde, hvor kildesystemet ikke tillader at vælge et bestemt sæt kolonnedata under ekstraktionsfasen, derefter udpakke hele dataene og foretage markeringen i transformationsfasen.

# 2) Opdeling / sammenføjning: Du kan manipulere de valgte data ved at opdele eller sammenføje dem. Du bliver bedt om at opdele de valgte kildedata endnu mere under transformationen.

For eksempel, hvis hele adressen er gemt i et enkelt stort tekstfelt i kildesystemet, kan DW-systemet muligvis bede om at opdele adressen i separate felter som by, stat, postnummer osv. Dette er let til indeksering og analyse baseret på hver komponent individuelt.

Mens sammenføjning / fletning af to eller flere kolonnedata bruges i vid udstrækning under transformationsfasen i DW-systemet. Dette betyder ikke at flette to felter i et enkelt felt.

For eksempel, hvis information om en bestemt enhed kommer fra flere datakilder, kan indsamling af oplysningerne som en enkelt enhed kaldes som sammenføjning / fletning af dataene.

# 3) Konvertering: De ekstraherede kildesystemdata kan være i forskellige formater for hver datatype, derfor skal alle de udpakkede data konverteres til et standardiseret format under transformationsfasen. Den samme form for format er let at forstå og let at bruge til forretningsbeslutninger.

# 4) Sammenfatning: I nogle situationer vil DW søge efter opsummerede data snarere end detaljerede data på lavt niveau fra kildesystemerne. Fordi data på lavt niveau ikke er bedst egnet til analyse og forespørgsel af forretningsbrugere.

For eksempel, salgsdata for hver checkout kræves muligvis ikke af DW-systemet, det daglige salgsprodukt (eller) daglige salg fra butikken er nyttigt. Derfor kan opsummering af data udføres under transformationsfasen i henhold til forretningskravene.

# 5) Berigelse: Når en DW-søjle dannes ved at kombinere en eller flere søjler fra flere poster, vil data berigelse omarrangere felterne for en bedre visning af data i DW-systemet.

# 6) Formater revisioner: Formatrevisioner sker hyppigst i transformationsfasen. Datatypen og dens længde revideres for hver kolonne.

For eksempel, en kolonne i et kildesystem kan være numerisk, og den samme kolonne i et andet kildesystem kan være en tekst. For at standardisere dette ændres datatypen for denne kolonne under transformationsfasen til tekst.

# 7) Afkodning af felter: Når du udtrækker data fra flere kildesystemer, kan dataene i forskellige systemer dekodes forskelligt.

For eksempel, et kildesystem kan repræsentere kundestatus som AC, IN og SU. Et andet system kan repræsentere den samme status som 1, 0 og -1.

I løbet af datatransformationsfasen skal du afkode sådanne koder til korrekte værdier, der er forståelige for forretningsbrugere. Derfor kan ovenstående koder ændres til Aktiv, Inaktiv og Suspenderet.

# 8) Beregnede og afledte værdier: Ved at overveje kildesystemdataene kan DW gemme yderligere kolonnedata til beregningerne. Du skal foretage beregningerne baseret på forretningslogikken, før du gemmer den i DW.

# 9) Konvertering af dato / tid: Dette er en af ​​de vigtigste datatyper at koncentrere sig om. Dato / tidsformatet kan være forskelligt i flere kildesystemer.

For eksempel, en kilde kan gemme datoen den 10. november 1997. En anden kilde kan gemme den samme dato i 11/10/1997-format. Derfor, under datatransformationen, skal alle dato- / tidsværdier konverteres til et standardformat.

# 10) Af duplikering: Hvis kildesystemet har duplikater, skal du sikre dig, at kun en post er indlæst i DW-systemet.

Transformationsflowdiagram:

Sådan implementeres transformation?

Afhængig af kompleksiteten af ​​datatransformationer kan du bruge manuelle metoder, transformationsværktøjer (eller) kombination af begge, hvad der er effektivt.

# 1) Manuel teknik

Manuelle teknikker er tilstrækkelige til små DW-systemer. Dataanalytikere og udviklere opretter programmer og scripts til at transformere data manuelt. Denne metode kræver detaljeret test for hver del af koden.

Vedligeholdelsesomkostningerne kan blive høje på grund af de ændringer, der opstår i forretningsregler (eller) på grund af chancerne for at få fejl med stigningen i datamængderne. Du skal tage sig af metadata oprindeligt og også med enhver ændring, der opstår i transformationsreglerne.

# 2) Transformationsværktøjer

Hvis du vil automatisere det meste af transformationsprocessen, kan du vedtage transformationsværktøjerne afhængigt af det budget og den tidsramme, der er tilgængelig for projektet. Mens du automatiserer, skal du bruge god kvalitetstid på at vælge værktøjerne, konfigurere, installere og integrere dem med DW-systemet.

Praktisk talt Komplet transformation med selve værktøjerne er ikke mulig uden manuel indgriben. Men de data, der er transformeret af værktøjerne, er bestemt effektive og nøjagtige.

For at opnå dette skal vi indtaste korrekte parametre, datadefinitioner og regler til transformationsværktøjet som input. Fra de givne input registrerer selve værktøjet metadataene, og disse metadata føjes til de samlede DW-metadata.

Hvis der er ændringer i forretningsreglerne, skal du blot indtaste disse ændringer i værktøjet, resten af ​​transformationsændringerne bliver taget hånd om af selve værktøjet. Derfor er en kombination af begge metoder effektiv at bruge.

Data indlæses

Uddragne og transformerede data indlæses i mål-DW-tabellerne under Load-fasen af ​​ETL-processen. Virksomheden beslutter, hvordan indlæsningsprocessen skal ske for hver tabel.

Indlæsningsprocessen kan ske på nedenstående måder:

• Indledende belastning: Indlæser data for at udfylde de respektive DW-tabeller for første gang.
• Inkrementel belastning: Når DW-tabellerne er indlæst, anvendes resten af ​​de løbende ændringer med jævne mellemrum.
• Fuld opdatering: Hvis nogen tabeller, der er i brug, skal opdateres, fjernes de aktuelle data fra tabellen helt og genindlæses. Genindlæsning svarer til den oprindelige belastning.

Se nedenstående eksempel for bedre forståelse af indlæsningsprocessen i ETL:

# 1) Under den indledende indlæsning, de data, der sælges den 3.^rdJuni 2007 indlæses i DW-måltabellen, fordi det er de oprindelige data fra ovenstående tabel.

#to) Under den inkrementelle belastning skal vi indlæse de data, der sælges efter 3^rdJuni 2007. Vi bør overveje alle poster med den solgte dato større end (>) den foregående dato for den næste dag. Derfor den 4^thJuni 2007, hent alle poster med solgt dato> 3^rdJuni 2007 ved at bruge forespørgsler og indlæse kun de to poster fra ovenstående tabel.

Den 5^thJuni 2007, hent alle poster med solgt dato> 4^thJuni 2007 og indlæser kun en post fra ovenstående tabel.

# 3) Under fuld opdatering indlæses alle ovenstående tabeldata i DW-tabellerne ad gangen uanset den solgte dato.

De indlæste data er gemt i de respektive dimensionstabeller (eller) faktatabeller. Dataene kan indlæses, tilføjes eller flettes til DW-tabellerne som følger:

# 4) Indlæs: Dataene indlæses i måltabellen, hvis de er tomme. Hvis der findes nogle data i tabellen, fjernes de eksisterende data og indlæses derefter med de nye data.

For eksempel,

Eksisterende tabeldata

Ændrede data

Data efter indlæsning

# 5) Tilføj: Append er en udvidelse af ovenstående belastning, da den fungerer på allerede eksisterende tabeller. I måltabellerne tilføjer Append flere data til de eksisterende data. Hvis der findes en duplikatpost med inputdataene, kan den tilføjes som duplikat (eller) den kan afvises.

For eksempel,

Eksisterende tabeldata

Ændrede data

Data efter tilføjelse

# 6) Destruktiv fusion: Her sammenlignes de indgående data med de eksisterende måldata baseret på den primære nøgle. Hvis der er et match, opdateres den eksisterende målpost. Hvis der ikke findes noget match, indsættes en ny post i måltabellen.

For eksempel,

Eksisterende tabeldata

Ændrede data

Data efter konstruktiv fletning

# 7) Konstruktiv går: I modsætning til destruktiv fusion, hvis der er et match med den eksisterende post, efterlader den den eksisterende post, som den er, og indsætter den indgående post og markerer den som de nyeste data (tidsstempel) med hensyn til den primære nøgle.

For eksempel,

Eksisterende tabeldata

Ændrede data

Data efter konstruktiv fletning

Teknisk set er opdatering nemmere end opdatering af dataene. Opdateringen har brug for en særlig strategi for kun at udtrække de specifikke ændringer og anvende dem på DW-systemet, mens Opdater bare erstatter dataene. Men opdatering af data tager længere tid afhængigt af datamængderne.

Hvis du har sådanne opdateringsjob, der skal køres dagligt, skal du muligvis bringe DW-systemet ned for at indlæse dataene. I stedet for at nedbringe hele DW-systemet for at indlæse data hver gang, kan du opdele og indlæse data i form af få filer.

Noter køretiden for hver belastning under test. Hvis nogen data ikke er i stand til at blive indlæst i DW-systemet på grund af nøglemangler osv., Så giv dem måder at håndtere sådan slags data på. Sørg for, at indlæste data testes grundigt.

Indlæsningsdiagram:

Flade filer

Flade filer bruges i vid udstrækning til at udveksle data mellem heterogene systemer, fra forskellige kildestyringssystemer og fra forskellige kildedatabasesystemer til datalagerapplikationer. Flade filer er også mest effektive og lette at administrere for homogene systemer.

Flade filer bruges primært til følgende formål:

# 1) Levering af kildedata: Der kan være få kildesystemer, der af sikkerhedsmæssige årsager ikke giver DW-brugere adgang til deres databaser. I sådanne tilfælde leveres dataene gennem flade filer.

Tilsvarende stammer dataene fra de eksterne leverandører eller mainframesystemer i det væsentlige i form af flade filer, og disse bliver FTP'et af ETL-brugerne.

# 2) Arbejds- / iscenesættelsestabeller: ETL-processen opretter iscenesættelsestabeller til dets interne formål. Sammenslutningen af ​​iscenesættelse af tabeller med de flade filer er meget lettere end DBMS, fordi læsning og skrivning til et filsystem er hurtigere end at indsætte og forespørge om en database.

# 3) Forberedelse til bulkbelastning: Når udvindings- og transformationsprocesserne er udført, hvis in-stream-bulkbelastningen ikke understøttes af ETL-værktøjet (eller) Hvis du vil arkivere dataene, kan du oprette en flad fil. Disse flade fildata læses af processoren og indlæser dataene i DW-systemet.

Flade filer kan oprettes på to måder som 'flade filer med fast længde' og 'Afgrænsede flade filer'. Flade filer kan oprettes af programmørerne, der arbejder for kildesystemet.

Lad os se, hvordan vi behandler disse flade filer:

Behandling af faste længde flade filer

Generelt har flade filer kolonner med fast længde, derfor kaldes de også som positionelle flade filer. Nedenfor er layoutet på en flad fil, der viser de nøjagtige felter og deres positioner i en fil.

Layoutet indeholder feltnavn, længde, startposition hvor felttegnet begynder, slutpositionen, hvor felttegnet slutter, datatypen som tekst, numerisk osv. og eventuelle kommentarer.

Afhængigt af datapositionerne vil ETL-testteamet validere nøjagtigheden af ​​dataene i en flad fil med fast længde.

Behandler afgrænsede flade filer

I afgrænsede flade filer adskilles hvert datafelt med afgrænsere. Denne afgrænser angiver start- og slutpositionen for hvert felt. Generelt bruges et komma som en afgrænser, men du kan bruge ethvert andet symbol eller et sæt symboler.

Afgrænsede filer kan være af .CSV-udvidelse (eller) .TXT-udvidelse (eller) uden udvidelse. Udviklerne, der opretter ETL-filerne, vil angive det egentlige afgrænsningssymbol for at behandle filen. I det afgrænsede fillayout kan den første række repræsentere kolonnenavnene.

Samme som de positionelle flade filer, vil ETL-testteamet eksplicit validere nøjagtigheden af ​​de afgrænsede fladfildata.

Formål med iscenesættelsesområde

Hovedformålet med iscenesættelsesområdet er at gemme data midlertidigt til ETL-processen. Iscenesættelsesområdet kaldes bagrummet til DW-systemet. ETL-arkitekt beslutter, om data skal gemmes i iscenesættelsesområdet eller ej.

Staging hjælper med at få data fra kildesystemer meget hurtigt. På samme tid, hvis DW-systemet mislykkes, behøver du ikke starte processen igen ved at indsamle data fra kildesystemerne, hvis iscenesættelsesdataene allerede findes.

Efter dataekstraktionsprocessen er her grundene til at iscenesætte data i DW-systemet:

# 1) Gendannelsesmulighed: De udfyldte iscenesættelsestabeller gemmes i selve DW-databasen (eller), de kan flyttes til filsystemer og kan gemmes separat. På et tidspunkt kan iscenesættelsesdataene fungere som gendannelsesdata, hvis noget transformation eller indlæsningstrin mislykkes.

Der kan være chancer for, at kildesystemet har overskrevet de data, der bruges til ETL, og derfor holder de udpakkede data i iscenesættelse os til enhver reference.

bedste mobiltelefon spion til Android

# 2) Sikkerhedskopiering: Det er vanskeligt at tage backup af store mængder DW-databasetabeller. Men sikkerhedskopier er et must for enhver katastrofegendannelse. Derfor, hvis du har de iscenesatte data, der er udpakkede data, så kan du køre jobene til transformation og indlæsning, hvorefter de nedbrudte data kan genindlæses.

For at sikkerhedskopiere iscenesættelsesdataene kan du ofte flytte iscenesættelsesdataene til filsystemer, så det er let at komprimere og gemme i dit netværk. Når det er nødvendigt, skal du bare komprimere filer, indlæses i iscenesættelsestabeller og kører jobbet for at genindlæse DW-tabellerne.

# 3) Revision: Nogle gange kan der ske en revision på ETL-systemet for at kontrollere dataforbindelsen mellem kildesystemet og målsystemet. Revisorerne kan validere de originale inputdata mod outputdataene baseret på transformationsreglerne.

Iscenesættelsesdataene og sikkerhedskopieringen er meget nyttige her, selvom kildesystemet har de tilgængelige data eller ej. Da revision kan ske når som helst og i enhver periode af de nuværende (eller) tidligere data. Iscenesættelsesområdet skal være godt planlagt.

Design af iscenesættelsesområdet

I datalageret kan dataene om mellemstationer designes som følger:

Med hver nye belastning af data i iscenesættelsestabeller kan de eksisterende data slettes (eller) opretholdes som historiske data til reference. Hvis data slettes, kaldes det et ”Transient staging area”.

Hvis data opretholdes som historie, kaldes det et 'vedvarende iscenesættelsesområde'. Du kan også designe et iscenesættelsesområde med en kombination af de to ovennævnte typer, som er “Hybrid”.

Her er de grundlæggende regler, der skal kendes under design af iscenesættelsesområdet:

• Kun ETL-teamet skal have adgang til datastagingområdet. Forespørgsel om iscenesættelsesdata er begrænset til andre brugere.
• Tabeller i iscenesættelsesområdet kan tilføjes, ændres eller slippes af ETL-dataarkitekt uden at involvere andre brugere. Da iscenesættelsesområdet ikke er et præsentationsområde til generering af rapporter, fungerer det bare som en arbejdsbænk.
• ETL-arkitekt skal estimere datalagringsmålingen for iscenesættelsesområdet for at give detaljerne til DBA- og OS-administratorer. Administratorer tildeler plads til iscenesættelse af databaser, filsystemer, kataloger osv.

Hvis mellemstationsområdet og DW-databasen bruger den samme server, kan du nemt flytte dataene til DW-systemet. Hvis serverne er forskellige, skal du bruge FTP (eller) databaselinks.

ETL procesflow

En standard ETL-cyklus gennemgår nedenstående procestrin:

• Start ETL-cyklussen for at køre job i rækkefølge.
• Sørg for, at alle metadata er klar.
• ETL-cyklus hjælper med at udtrække data fra forskellige kilder.
• Valider de udpakkede data.
• Hvis der anvendes iscenesættelsestabeller, indlæser ETL-cyklussen dataene i iscenesættelsen.
• ETL udfører transformationer ved at anvende forretningsregler, ved at oprette aggregater osv
• Hvis der er fejl, vil ETL-cyklussen bringe det til udtryk i form af rapporter.
• Derefter indlæser ETL-cyklus data i måltabellerne.
• Tidligere data, der skal gemmes til historisk reference, arkiveres.
• Resten af ​​de data, der ikke behøver at blive gemt, renses.

ETL-procesflowdiagram:

Konklusion

I denne vejledning lærte vi om de vigtigste koncepter i ETL-processen i datavarehus. Nu skal du være i stand til at forstå, hvad der er dataekstraktion, datatransformation, dataindlæsning og ETL-procesflowet.

Læs den kommende tutorial for at vide mere om Data Warehouse Testing !!

=> Besøg her for den eksklusive datalagringsserie.

Anbefalet læsning

• Vejledning til test af datavarehus med eksempler | ETL testguide
• De 10 bedste datakortningsværktøjer, der er nyttige i ETL-processen (2021 LIST)
• ETL Testing Tutorial Data Warehouse Testing Tutorial (En komplet guide)
• Data Mining: Process, teknikker og større problemer i dataanalyse
• Data Mining Process: Modeller, processtrin og involverede udfordringer
• ETL Testing Interview Spørgsmål og svar
• Top 10 ETL-testværktøjer i 2021
• Top 10 populære datalagerværktøjer og testteknologier