ETL står för Extract, Transform och Load. ETL-verktyg extraherar data från olika källor och omvandlar dem till ett mellanformat som är lämpligt för målsystem eller datamodellkraven. Och slutligen laddar de in data till en måldatabas, datalager eller till och med datasjö.
Jag minns tider från 15 till 20 år tillbaka när termen ETL var något som bara ett fåtal förstod vad det är. När olika anpassade batchjobb hade sin topp på den lokala hårdvaran.
Många projekt gjorde någon form av ETL. Även om de inte visste, borde de döpa det till ETL. Under den tiden, när jag förklarade någon design som involverade ETL-processer, och jag ringde dem och beskrev dem på det sättet, såg det nästan ut som en annan världsteknologi, något mycket sällsynt.
Men idag är det annorlunda. Migrering till molnet är högsta prioritet. Och ETL-verktyg är den mycket strategiska delen av arkitekturen för de flesta projekt.
I slutändan innebär att migrera till molnet att ta data från den lokala källan och omvandla den till molndatabaser i en form som är så kompatibel som möjligt med molnarkitekturen. Exakt jobbet med ETL-verktyget.
Innehållsförteckning
Historien om ETL och hur den ansluter till nuet
Källa: aws.amazon.com
Huvudfunktionerna för ETL var alltid desamma.
ETL-verktyg extraherar data från olika källor (det är databaser, platta filer, webbtjänster eller på sistone molnbaserade applikationer).
Det innebar vanligtvis att ta filer på Unix-filsystemet som inmatning och förbearbetning, bearbetning och efterbearbetning.
Du kan se det återanvändbara mönstret av mappnamn som:
- Inmatning
- Produktion
- Fel
- Arkiv
Under dessa mappar fanns en annan undermappsstruktur, huvudsakligen baserad på datum, också.
Detta var bara standardsättet att bearbeta inkommande data och förbereda den för laddning i någon form av databas.
Idag finns det inga Unix-filsystem (inte på samma sätt som tidigare) — kanske till och med inga filer. Nu finns det API:er – gränssnitt för applikationsprogrammering. Du kan, men du behöver inte ha en fil som indataformat.
Allt kan lagras i cacheminnet. Det kan fortfarande vara en fil. Vad det än är så måste det följa något strukturerat format. I de flesta fall betyder detta JSON- eller XML-format. I vissa fall kommer det gamla bra CSV-formatet (Comma-separated-value) att göra det också.
Du definierar inmatningsformatet. Om processen också kommer att innebära att skapa historiken för indatafiler är helt upp till dig. Det är inte längre ett standardsteg.
Omvandling
ETL-verktyg omvandlar extraherade data till ett lämpligt format för analys. Detta inkluderar datarensning, datavalidering, databerikning och dataaggregering.
Som tidigare var fallet gick data igenom en komplex anpassad logik för Pro-C- eller PL/SQL-processdataindelning, datatransformering och datamålschemalagringssteg. Det var en lika obligatorisk standardprocess som att separera de inkommande filerna i undermappar baserat på det skede som filen bearbetades.
Varför var det så naturligt om det samtidigt var fundamentalt fel? Genom att direkt transformera inkommande data utan permanent lagring förlorade du den största fördelen med rådata – oföränderlighet. Projekt bara kastade bort det utan någon chans till återuppbyggnad.
Tja, gissa vad. Idag, ju mindre omvandling av rådata du utför, desto bättre. För den första datalagringen i systemet, det vill säga. Det kan vara nästa steg kommer att vara en seriös dataförändring och datamodellomvandling, visst. Men du vill ha lagrat rådata i så mycket oförändrad och atomär struktur som möjligt. Ett stort skifte från tiderna på plats, om du frågar mig.
Ladda
ETL-verktyg laddar de transformerade data till en måldatabas eller datalager. Detta inkluderar att skapa tabeller, definiera relationer och ladda data i lämpliga fält.
Laddningssteget är förmodligen det enda som följer samma mönster i evigheter. Den enda skillnaden är en måldatabas. Medan det tidigare var Oracle för det mesta, kan det nu vara vad som helst som är tillgängligt i AWS-molnet.
ETL i dagens molnmiljö
Om du planerar att överföra din data från on-premise till (AWS) moln, behöver du ett ETL-verktyg. Det går inte utan det, varför denna del av molnarkitekturen förmodligen blev den viktigaste pusselbiten. Om det här steget är fel, kommer allt annat efteråt att följa och dela samma lukt överallt.
Och även om det finns många tävlingar, skulle jag nu fokusera på de tre jag har personlig erfarenhet av mest:
- Data Migration Service (DMS) – en inbyggd tjänst från AWS.
- Informatica ETL – förmodligen den största kommersiella aktören i ETL-världen, som framgångsrikt förvandlar sin verksamhet från lokal till moln.
- Matillion för AWS – en relativt ny spelare i molnmiljöer. Inte inbyggt i AWS, men inbyggt i molnet. Med ingenting liknande historia jämförbar med Informatica.
AWS DMS som ETL
Källa: aws.amazon.com
AWS Data Migration Services (DMS) är en helt hanterad tjänst som gör att du kan migrera data från olika källor till AWS. Den stöder flera migreringsscenarier.
- Homogena migrationer (t.ex. Oracle till Amazon RDS för Oracle).
- Heterogena migrationer (t.ex. Oracle till Amazon Aurora).
DMS kan migrera data från olika källor, inklusive databaser, datalager och SaaS-applikationer, till olika mål, inklusive Amazon S3, Amazon Redshift och Amazon RDS.
AWS behandlar DMS-tjänsten som det ultimata verktyget för att överföra data från vilken databaskälla som helst till molnbaserade mål. Medan huvudmålet med DMS bara är datakopiering till molnet, gör det ett bra jobb med att transformera data längs vägen också.
Du kan definiera DMS-uppgifter i JSON-format för att automatisera olika transformationsjobb åt dig samtidigt som du kopierar data från källan till målet:
- Slå samman flera källtabeller eller kolumner till ett enda värde.
- Dela upp källvärdet i flera målfält.
- Ersätt källdata med ett annat målvärde.
- Ta bort all onödig data eller skapa helt ny data baserat på inmatningskontexten.
Det betyder – ja, du kan definitivt använda DMS som ett ETL-verktyg för ditt projekt. Kanske kommer det inte att vara lika sofistikerat som de andra alternativen nedan, men det kommer att göra jobbet om du definierar målet tydligt i förväg.
Lämplighetsfaktor
Även om DMS tillhandahåller vissa ETL-funktioner, handlar det i första hand om datamigreringsscenarier. Det finns vissa scenarier där det kan vara bättre att använda DMS istället för ETL-verktyg som Informatica eller Matillion:
Matillion ETL
Källa: matillion.com
är en molnbaserad lösning och du kan använda den för att integrera data från olika källor, inklusive databaser, SaaS-applikationer och filsystem. Det erbjuder ett visuellt gränssnitt för att bygga ETL-pipelines och stöder olika AWS-tjänster, inklusive Amazon S3, Amazon Redshift och Amazon RDS.
Matillion är lätt att använda och kan vara ett bra val för organisationer som är nya med ETL-verktyg eller med mindre komplexa dataintegrationsbehov.
Å andra sidan är Matillion en sorts tabula rasa. Den har några fördefinierade potentiella funktioner, men du måste anpassa den för att få den till liv. Du kan inte förvänta dig att Matillion ska göra jobbet åt dig direkt, även om kapaciteten finns där per definition.
Matillion beskrev sig också ofta som ELT snarare än ett ETL-verktyg. Det betyder att det är mer naturligt för Matillion att göra en belastning innan omvandlingen.
Lämplighetsfaktor
Matillion är med andra ord effektivare när det gäller att transformera data först när de redan är lagrade i databasen än tidigare. Den främsta anledningen till det är den anpassade skriptskyldigheten som redan nämnts. Eftersom all speciell funktionalitet måste kodas först, kommer effektiviteten sedan mycket att bero på effektiviteten av den anpassade koden.
Det är bara naturligt att förvänta sig att detta kommer att hanteras bättre i måldatabassystemet och lämnar på Matillion bara en enkel 1:1-laddningsuppgift – mycket färre möjligheter att förstöra den med anpassad kod här.
Även om Matillion tillhandahåller en rad funktioner för dataintegration, kanske den inte erbjuder samma nivå av datakvalitet och styrningsfunktioner som vissa andra ETL-verktyg.
Matillion kan skala upp eller ner baserat på organisationens behov, men det kanske inte är lika effektivt för att hantera mycket stora datamängder. Den parallella bearbetningen är ganska begränsad. I detta avseende är Informatica säkert ett bättre val eftersom den är mer avancerad och funktionsrik på samma gång.
Men för många organisationer kan Matillion för AWS tillhandahålla tillräcklig skalbarhet och parallell bearbetningskapacitet för att möta deras behov.
Informatica ETL
Källa: informatica.com
Informatica för AWS är ett molnbaserat ETL-verktyg designat för att hjälpa till att integrera och hantera data över olika källor och mål i AWS. Det är en helt hanterad tjänst som tillhandahåller en rad funktioner och möjligheter för dataintegration, inklusive dataprofilering, datakvalitet och datastyrning.
Några av de viktigaste egenskaperna hos Informatica för AWS inkluderar:
Lämplighetsfaktor
Uppenbarligen är Informatica det mest funktionsrika ETL-verktyget på listan. Det kan dock vara dyrare och mer komplext att använda än några av de andra ETL-verktygen som finns tillgängliga i AWS.
Informatica kan vara dyrt, särskilt för små och medelstora organisationer. Prismodellen är baserad på användning, vilket innebär att organisationer kan behöva betala mer när deras användning ökar.
Det kan också vara komplicerat att ställa in och konfigurera, särskilt för de som är nya med ETL-verktyg. Detta kan kräva en betydande investering i tid och resurser.
Det leder oss också till något vi kan kalla en ”komplex inlärningskurva”. Detta kan vara en nackdel för dem som behöver integrera data snabbt eller har begränsade resurser att ägna åt utbildning och onboarding.
Dessutom kanske Informatica inte är lika effektiv för att integrera data från icke-AWS-källor. I detta avseende kan DMS eller Matillion vara ett bättre alternativ.
Slutligen är Informatica i hög grad ett slutet system. Det finns bara en begränsad möjlighet att anpassa det till projektets specifika behov. Du måste bara leva med inställningen den ger ur lådan. Det begränsar alltså flexibiliteten hos lösningarna på något sätt.
Slutord
Som det händer i många andra fall finns det ingen lösning som passar alla, inte ens sådant som ETL-verktyget i AWS.
Du kanske väljer den mest komplexa, funktionsrika och dyra lösningen med Informatica. Men det är vettigt att göra det mesta om:
- Projektet är ganska stort och du är säker på att hela den framtida lösningen och datakällorna ansluter till Informatica också.
- Du har råd att ta med ett team av skickliga Informatica-utvecklare och konfiguratorer.
- Du kan uppskatta det robusta supportteamet bakom dig och är bra på att betala för det.
Om något från ovan är avstängt, kan du ge det ett försök till Matillion:
- Om projektets behov generellt sett inte är så komplexa.
- Om du behöver inkludera några mycket anpassade steg i bearbetningen är flexibilitet ett nyckelkrav.
- Om du inte har något emot att bygga de flesta funktionerna från grunden med teamet.
För allt som är ännu mindre komplicerat är det självklara valet DMS för AWS som en inbyggd tjänst, som förmodligen kan tjäna ditt syfte väl.
Kolla sedan in verktyg för datatransformation för att hantera din data bättre.