ETL står for Extract, Transform og Load. ETL-verktøy trekker ut data fra ulike kilder og transformerer dem til et mellomformat som passer for målsystemer eller datamodellkravene. Og til slutt laster de data inn i en måldatabase, datavarehus eller til og med datainnsjø.
Jeg husker tider fra 15 til 20 år tilbake da begrepet ETL var noe bare noen få forsto hva det er. Da ulike tilpassede batchjobber hadde sitt høydepunkt på den lokale maskinvaren.
Mange prosjekter gjorde en form for ETL. Selv om de ikke visste det, burde de kalle det ETL. I løpet av den tiden, hver gang jeg forklarte design som involverte ETL-prosesser, og jeg ringte dem og beskrev dem på den måten, så det nesten ut som en annen verdensteknologi, noe veldig sjeldent.
Men i dag er ting annerledes. Migrering til skyen er toppprioritet. Og ETL-verktøy er selve den strategiske delen av arkitekturen til de fleste prosjekter.
Til syvende og sist betyr migrering til skyen å ta dataene fra lokalt som en kilde og transformere dem til skydatabaser i en form som er så kompatibel som mulig med skyarkitekturen. Akkurat jobben til ETL-verktøyet.
Innholdsfortegnelse
Historien om ETL og hvordan den kobles til nåtiden
Kilde: aws.amazon.com
Hovedfunksjonene til ETL var alltid de samme.
ETL-verktøy trekker ut data fra ulike kilder (det være seg databaser, flate filer, webtjenester eller i det siste skybaserte applikasjoner).
Det betydde vanligvis å ta filer på Unix-filsystemet som input og forhåndsbehandling, behandling og etterbehandling.
Du kan se det gjenbrukbare mønsteret av mappenavn som:
- Inndata
- Produksjon
- Feil
- Arkiv
Under disse mappene fantes det også en annen undermappestruktur, hovedsakelig basert på datoer.
Dette var bare standardmåten for å behandle innkommende data og forberede dem for lasting i en slags database.
I dag er det ingen Unix-filsystemer (ikke på samme måte som før) – kanskje til og med ingen filer. Nå er det APIer – applikasjonsprogrammeringsgrensesnitt. Du kan, men du trenger ikke å ha en fil som inndataformat.
Det hele kan lagres i cache-minnet. Det kan fortsatt være en fil. Uansett hva det er, må det følge et eller annet strukturert format. I de fleste tilfeller betyr dette JSON- eller XML-format. I noen tilfeller vil det gamle gode Comma-separated-value-formatet (CSV) gjøre det også.
Du definerer inndataformatet. Hvorvidt prosessen også vil innebære å lage historikken til inndatafiler er utelukkende opp til deg. Det er ikke lenger et standardtrinn.
Transformasjon
ETL-verktøy forvandler de utpakkede dataene til et passende format for analyse. Dette inkluderer datarensing, datavalidering, databerikelse og dataaggregering.
Som det pleide å være tilfellet, gikk dataene gjennom en kompleks tilpasset logikk av Pro-C eller PL/SQL prosedyredatainnsamling, datatransformasjon og datamålskjemalagringstrinn. Det var en tilsvarende obligatorisk standardprosess som det var å skille de innkommende filene i undermapper basert på stadiet filen ble behandlet.
Hvorfor var det så naturlig hvis det samtidig var grunnleggende feil? Ved å transformere innkommende data direkte uten permanent lagring, mistet du den største fordelen med rådata – uforanderlighet. Prosjekter bare kastet det bort uten noen sjanse for gjenoppbygging.
Vel, gjett hva. I dag jo mindre transformasjon av rådata du utfører, jo bedre. For den første datalagringen i systemet, altså. Det kan være det neste trinnet vil være noen alvorlige dataendring og datamodelltransformasjon, helt klart. Men du ønsker å ha lagret rådataene i så mye uendret og atomær struktur som mulig. Et stort skifte fra de lokale tidene, spør du meg.
Laste
ETL-verktøy laster de transformerte dataene inn i en måldatabase eller datavarehus. Dette inkluderer å lage tabeller, definere relasjoner og laste inn data i de aktuelle feltene.
Lastetrinnet er sannsynligvis det eneste som følger det samme mønsteret i evigheter. Den eneste forskjellen er en måldatabase. Mens det tidligere var Oracle mesteparten av tiden, kan det nå være det som er tilgjengelig i AWS-skyen.
ETL i dagens skymiljø
Hvis du planlegger å bringe dataene dine fra on-premise til (AWS) sky, trenger du et ETL-verktøy. Det går ikke uten, og derfor ble denne delen av skyarkitekturen trolig den viktigste brikken i puslespillet. Hvis dette trinnet er feil, vil alt annet etterpå følge, og dele den samme lukten overalt.
Og selv om det er mange konkurranser, vil jeg nå fokusere på de tre jeg har mest personlig erfaring med:
- Data Migration Service (DMS) – en innebygd tjeneste fra AWS.
- Informatica ETL – sannsynligvis den viktigste kommersielle aktøren i ETL-verdenen, med suksess med å transformere virksomheten fra lokalt til sky.
- Matillion for AWS – en relativt ny aktør i skymiljøer. Ikke innfødt til AWS, men innfødt til skyen. Med ingenting som historie kan sammenlignes med Informatica.
AWS DMS som ETL
Kilde: aws.amazon.com
AWS Data Migration Services (DMS) er en fullstendig administrert tjeneste som lar deg migrere data fra forskjellige kilder til AWS. Den støtter flere migrasjonsscenarier.
- Homogene migrasjoner (f.eks. Oracle til Amazon RDS for Oracle).
- Heterogene migrasjoner (f.eks. Oracle til Amazon Aurora).
DMS kan migrere data fra ulike kilder, inkludert databaser, datavarehus og SaaS-applikasjoner, til ulike mål, inkludert Amazon S3, Amazon Redshift og Amazon RDS.
AWS behandler DMS-tjenesten som det ultimate verktøyet for å bringe data fra enhver databasekilde inn i skybaserte mål. Mens hovedmålet med DMS bare er datakopiering til skyen, gjør det en god jobb med å transformere dataene underveis også.
Du kan definere DMS-oppgaver i JSON-format for å automatisere ulike transformasjonsjobber for deg mens du kopierer dataene fra kilden til målet:
- Slå sammen flere kildetabeller eller kolonner til én enkelt verdi.
- Del opp kildeverdien i flere målfelt.
- Erstatt kildedata med en annen målverdi.
- Fjern eventuelle unødvendige data eller lag helt nye data basert på inndatakonteksten.
Det betyr – ja, du kan definitivt bruke DMS som et ETL-verktøy for prosjektet ditt. Kanskje det ikke vil være like sofistikert som de andre alternativene nedenfor, men det vil gjøre jobben hvis du definerer målet klart på forhånd.
Egnethetsfaktor
Selv om DMS gir noen ETL-funksjoner, handler det først og fremst om datamigrasjonsscenarier. Det er noen scenarier der det kan være bedre å bruke DMS i stedet for ETL-verktøy som Informatica eller Matillion:
Matillion ETL
Kilde: matillion.com
er en skybasert løsning, og du kan bruke den til å integrere data fra ulike kilder, inkludert databaser, SaaS-applikasjoner og filsystemer. Den tilbyr et visuelt grensesnitt for å bygge ETL-rørledninger og støtter ulike AWS-tjenester, inkludert Amazon S3, Amazon Redshift og Amazon RDS.
Matillion er enkel å bruke og kan være et godt valg for organisasjoner som er nye til ETL-verktøy eller med mindre komplekse dataintegrasjonsbehov.
På den annen side er Matillion en slags tabula rasa. Den har noen forhåndsdefinerte potensielle funksjoner, men du må spesialkode den for å bringe den til live. Du kan ikke forvente at Matillion skal gjøre jobben for deg ut av boksen, selv om evnen er der per definisjon.
Matillion beskrev seg også ofte som ELT i stedet for et ETL-verktøy. Det betyr at det er mer naturlig for Matillion å gjøre en belastning før transformasjonen.
Egnethetsfaktor
Matillion er med andre ord mer effektiv i å transformere dataene bare når de allerede er lagret i databasen enn før. Hovedårsaken til det er den tilpassede skriptforpliktelsen som allerede er nevnt. Siden all spesialfunksjonalitet må kodes først, vil effektiviteten i stor grad avhenge av effektiviteten til den tilpassede koden.
Det er bare naturlig å forvente at dette vil bli bedre håndtert i måldatabasesystemet og la Matillion bare ha en enkel 1:1-lastingsoppgave – mye færre muligheter til å ødelegge den med tilpasset kode her.
Selv om Matillion tilbyr en rekke funksjoner for dataintegrasjon, tilbyr den kanskje ikke samme nivå av datakvalitet og styringsfunksjoner som noen andre ETL-verktøy.
Matillion kan skalere opp eller ned basert på behovene til organisasjonen, men det er kanskje ikke like effektivt for å håndtere svært store datamengder. Den parallelle behandlingen er ganske begrenset. I denne forbindelse er Informatica sikkert et bedre valg fordi det er mer avansert og funksjonsrikt på samme tid.
For mange organisasjoner kan imidlertid Matillion for AWS gi tilstrekkelig skalerbarhet og parallellbehandlingsevner for å møte deres behov.
Informatikk ETL
Kilde: informatica.com
Informatica for AWS er et skybasert ETL-verktøy designet for å hjelpe med å integrere og administrere data på tvers av ulike kilder og mål i AWS. Det er en fullstendig administrert tjeneste som tilbyr en rekke funksjoner og muligheter for dataintegrasjon, inkludert dataprofilering, datakvalitet og datastyring.
Noen av hovedkarakteristikkene til Informatica for AWS inkluderer:
Egnethetsfaktor
Det er klart at Informatica er det mest funksjonsrike ETL-verktøyet på listen. Imidlertid kan det være dyrere og mer komplisert å bruke enn noen av de andre ETL-verktøyene som er tilgjengelige i AWS.
Informatica kan være dyrt, spesielt for små og mellomstore organisasjoner. Prismodellen er basert på bruk, noe som betyr at organisasjoner kan måtte betale mer etter hvert som bruken øker.
Det kan også være komplisert å sette opp og konfigurere, spesielt for de som er nye med ETL-verktøy. Dette kan kreve betydelige investeringer i tid og ressurser.
Det fører oss også til noe vi kan kalle en «kompleks læringskurve». Dette kan være en ulempe for de som trenger å integrere data raskt eller har begrensede ressurser å bruke på opplæring og onboarding.
Dessuten er Informatica kanskje ikke like effektiv for å integrere data fra ikke-AWS-kilder. I denne forbindelse kan DMS eller Matillion være et bedre alternativ.
Til slutt, Informatica er i høy grad et lukket system. Det er kun en begrenset mulighet til å tilpasse det til prosjektets spesifikke behov. Du må bare leve med oppsettet det gir ut av esken. Dermed begrenser det fleksibiliteten til løsningene på en eller annen måte.
Siste ord
Som det skjer i mange andre tilfeller, er det ingen løsning som passer alle, selv noe som ETL-verktøyet i AWS.
Du kan velge den mest komplekse, funksjonsrike og dyre løsningen med Informatica. Men det er fornuftig å gjøre det meste hvis:
- Prosjektet er ganske stort, og du er sikker på at hele den fremtidige løsningen og datakildene også kobles til Informatica.
- Du har råd til å ta med et team av dyktige Informatica-utviklere og konfiguratorer.
- Du kan sette pris på det robuste supportteamet bak deg og er flinke til å betale for det.
Hvis noe ovenfra er slått av, kan du kanskje gi det en sjanse til Matillion:
- Dersom prosjektets behov generelt sett ikke er så komplekse.
- Hvis du trenger å inkludere noen veldig tilpassede trinn i behandlingen, er fleksibilitet et nøkkelkrav.
- Hvis du ikke har noe imot å bygge de fleste funksjonene fra bunnen av med teamet.
For alt som er enda mindre komplisert, er det åpenbare valget DMS for AWS som en innfødt tjeneste, som sannsynligvis kan tjene formålet ditt godt.
Deretter kan du sjekke datatransformasjonsverktøy for å administrere dataene dine bedre.