ETL

ETL står for "extract, transform, load" og beskriver processen med at tage data fra kildesystemer, konvertere dem til en ensartet struktur og indlæse dem i en destination, f.eks. et data warehouse. Det er rørsystemet under analyser, og dets pålidelighed afgør, om de rapporter, der er bygget ovenpå, kan stoles på.

Hvert trin medfører forskellige vanskeligheder. Udtrækning skal indhente data fra systemer, der ikke er designet til at blive forespørget eksternt, håndtere API-hastighedsgrænser, trinvis ændringsdetektion og kilder, der ikke giver nogen pålidelig måde at identificere, hvad der er ændret. Transformation skal afstemme inkonsistente formater, forskellige identifikatorer, modstridende definitioner og manglende værdier. Indlæsning skal håndtere volumen, vedligeholde historik og håndtere poster, der ankommer sent eller i forkert rækkefølge.

ELT-varianten vender de sidste to faser om, idet den indlæser rådata til destinationen og transformerer dem der. Dette er blevet almindeligt, fordi moderne lagerplatforme har tilstrækkelig behandlingskapacitet til at gøre transformation på stedet effektiv, og fordi opbevaring af rådata gør det muligt at revidere og genanvende transformationer uden at skulle udtrække dem fra kilder igen. Det betyder også, at fejl i transformationslogikken kan rettes snarere end er permanente.

Trinvis behandling er den praktiske nødvendighed, der komplicerer de fleste implementeringer. Genbehandling af alle historiske data på hver kørsel er simpelt og bliver uholdbart, efterhånden som volumen vokser, så pipelines skal identificere, hvad der er ændret siden sidste kørsel. Kilder uden pålidelige tidsstempler for ændringer, poster, der opdateres med tilbagevirkende kraft, og sletninger, der ikke efterlader spor, gør alt dette sværere, end det ser ud til, og forkert trinvis logik producerer uopmærksomt ufuldstændige data.

Fejlhåndtering afgør, om en pipeline er produktionsklar. Pipelines fejler rutinemæssigt, fordi kildesystemer ændrer deres skemaer, legitimationsoplysninger udløber, upstream-tjenester er utilgængelige, eller uventede data ankommer. De vigtige egenskaber er, at fejl opdages med det samme, at delvise kørsler ikke efterlader destinationen i en inkonsekvent tilstand, at genkørsler giver det samme resultat i stedet for at duplikere poster, og at nogen underrettes i stedet for at fejlen opdages, når en rapport ser forkert ud.

Validering af datakvalitet hører hjemme i pipelinen snarere end efter den. Kontrol af rækkeantal i forhold til forventningerne, verificering af, at nøglefelter er udfyldt, bekræftelse af, at værdier falder inden for plausible intervaller, og test af referentiel konsistens for at opdage korruption ved indgangspunktet. Uden disse tests spreder dårlige data sig til rapporter og beslutninger, og det opdages typisk af en person, der bemærker et usandsynligt tal uger senere.

Planlægning og afhængighedsstyring afgør, om outputtet er sammenhængende. Pipelines kører sjældent isoleret, og et downstream-job, der starter, før dets upstream-kilde er færdig, producerer delvise resultater, der ser komplette ud. Der findes orkestreringsværktøjer til at udtrykke disse afhængigheder eksplicit, og pipelines, der er kædet sammen af ​​timingantagelser snarere end af deklarerede afhængigheder, fejler periodisk på måder, der er vanskelige at reproducere.

Dokumentation og afstamning er vigtig, fordi pipelines lever længere end de mennesker, der bygger dem. At vide, hvor hvert felt stammer fra, hvilke transformationer der blev anvendt, og hvilke forretningsregler der er kodet, er nødvendigt for at besvare spørgsmål om, hvorfor et tal ser ud, som det gør, og for at vurdere virkningen af ​​at ændre et kildesystem. Udokumenterede pipelines bliver til systemer, som ingen tør ændre, og det er sådan, organisationer ender med parallelle pipelines, der producerer modstridende tal.

Da pålidelighed snarere end sofistikering bestemmer den leverede værdi, bør den ingeniørdisciplin, der anvendes på pipelines, matche den, der anvendes på produktionssoftware. I praksis bygges og drives pipelines af produktudvikling eller Det afdeling, transformationslogikken, der koder forretningsdefinitioner, er specificeret med dataanalyse, og valideringsreglerne er værd at blive enige om, før den første pipeline bygges, i stedet for at blive tilføjet efter den første hændelse.