ETL

ETL står för extrahera, transformera, ladda och beskriver processen att hämta data från källsystem, konvertera dem till en enhetlig struktur och ladda dem till en destination, till exempel ett datalager. Det är rörsystemet under analyser, och dess tillförlitlighet avgör om rapporterna som bygger ovanpå dem kan litas på.

Varje steg medför specifika svårigheter. Extraktionen måste hämta data från system som inte är utformade för att efterfrågas externt, hantera API-hastighetsgränser, stegvis förändringsdetektering och källor som inte ger något tillförlitligt sätt att identifiera vad som har ändrats. Transformationen måste förena inkonsekventa format, olika identifierare, motstridiga definitioner och saknade värden. Inläsningen måste hantera volym, underhålla historik och hantera poster som anländer sent eller i fel ordning.

ELT-varianten vänder på de två sista stegen, laddar rådata till destinationen och transformerar den där. Detta har blivit vanligt eftersom moderna lagerplattformar har tillräcklig bearbetningskapacitet för att göra transformation på plats effektiv, och eftersom bevarande av rådata gör att transformationer kan revideras och tillämpas på nytt utan att extraheras från källor. Det innebär också att fel i transformationslogiken är återställbara snarare än permanenta.

Stegvis bearbetning är den praktiska nödvändighet som komplicerar de flesta implementeringar. Att ombearbeta all historisk data vid varje körning är enkelt och blir ohållbart allt eftersom volymen växer, så pipelines måste identifiera vad som har ändrats sedan den senaste körningen. Källor utan tillförlitliga tidsstämplar för ändringar, poster som uppdateras retroaktivt och borttagningar som inte lämnar några spår gör detta svårare än det verkar, och felaktig stegvis logik producerar tyst ofullständig data.

Felhantering avgör om en pipeline är produktionsklassad. Pipelines misslyckas rutinmässigt eftersom källsystem ändrar sina scheman, autentiseringsuppgifter löper ut, uppströmstjänster är otillgängliga eller oväntade data anländer. De viktiga egenskaperna är att fel upptäcks omedelbart, att delvisa körningar inte lämnar destinationen i ett inkonsekvent tillstånd, att omkörningar ger samma resultat snarare än att duplicera poster och att någon meddelas snarare än att felet upptäcks när en rapport ser fel ut.

Validering av datakvalitet hör hemma inuti pipelinen snarare än efter den. Att kontrollera radantal mot förväntningarna, verifiera att nyckelfält är ifyllda, bekräfta att värden faller inom rimliga intervall och testa referenskonsistens för att upptäcka korruption vid ingångspunkten. Utan dessa tester sprider sig dålig data till rapporter och beslut, och det upptäcks vanligtvis av någon som lägger märke till en osannolik siffra veckor senare.

Schemaläggning och beroendehantering avgör om utdata är koherent. Pipelines körs sällan isolerat, och ett nedströmsjobb som startar innan dess uppströmskälla har slutförts producerar partiella resultat som ser kompletta ut. Orkestreringsverktyg finns för att uttrycka dessa beroenden explicit, och pipelines som är kedjade av tidsantaganden snarare än av deklarerade beroenden misslyckas intermittent på sätt som är svåra att reproducera.

Dokumentation och härkomst är viktiga eftersom pipelines lever längre än de människor som bygger dem. Att veta var varje fält har sitt ursprung, vilka transformationer som tillämpades och vilka affärsregler som är kodade är nödvändigt för att besvara frågor om varför ett tal ser ut som det gör, och för att bedöma effekterna av att ändra ett källsystem. Odokumenterade pipelines blir system som ingen vågar modifiera, vilket är så organisationer får parallella pipelines som producerar motstridiga siffror.

Eftersom tillförlitlighet snarare än sofistikering avgör det levererade värdet, bör den ingenjörsdisciplin som tillämpas på pipelines matcha den som tillämpas på produktionsprogramvara. I praktiken byggs och drivs pipelines av produktutveckling eller IT-avdelning, transformationslogiken som kodar affärsdefinitioner specificeras med uppgifter analytics, och valideringsreglerna är värda att komma överens om innan den första pipelinen byggs snarare än att läggas till efter den första incidenten.