Strukturering af transformationstrin som funktioner

Jupyter-notebooks er gode til udforskning, men dårlige til databehandlingsforløb i produktion. Kode spredt over 50 celler med global tilstand og uden test er skrøbelig: Hvis du ændrer én celle, kan du ubevidst ødelægge en anden. Det professionelle alternativ er at udtrække hver transformation til en navngiven funktion, der modtager et DataFrame-objekt og returnerer et DataFrame-objekt. Denne adskillelse af ansvar er grundlaget for kode til vedligeholdelig datateknik.

ETL-mønsteret opdeler et databehandlingsforløb i tre faser: Extract (læs fra kilden), Transform (rens og berig) og Load (skriv til destinationen). Hver fase er en separat funktion. Denne opdeling gør det nemt at skifte datakilder (CSV eller database), ændre rense-logikken eller ændre outputformatet uden at berøre de to andre faser. Alle databehandlingsforløb i produktion bør følge denne struktur.

Hver transformationsfunktion bør gøre præcis én ting. En funktion kaldet clean_data(), der fjerner nuller, begrænser outliers, fortolker datoer og koder kategorier, er vanskelig at teste og fejlfinde. Skriv i stedet drop_nulls(), cap_outliers(), parse_dates() og encode_categories() som separate funktioner. Denne granularitet gør det nemt at springe et enkelt trin over, udskifte det eller ændre rækkefølgen.

Forbind funktioner med ét ansvar ved hjælp af pipe() for at opbygge hele transformationsfasen som en læsbar kæde. Kæden læses som en opskrift: hver linje er et trin, og dataene bevæger sig fra øverst til nederst. Du kan kommentere ethvert trin ud eller ændre rækkefølgen uden at omdøbe variable. Det endelige resultat er det rene, berigede DataFrame-objekt, der er klar til indlæsningsfasen.

Hver transformationsfunktion bør valgfrit logge, hvor mange rækker den modtog, og hvor mange den returnerede. Hvis du indbygger logning af rækkeantallet før og efter i funktionen, får du et enkelt revisionsspor, der hurtigt viser, hvor rækker fjernes under en kørsel af databehandlingsforløbet. Gem disse antal i en liste, og udskriv dem som en rapport ved slutningen af hver kørsel.

Den største fordel ved navngivne funktioner er, at de kan testes. Skriv et lille test-DataFrame-objekt, der repræsenterer et realistisk kanttilfælde, og kontrollér funktionens output. Test funktionen drop_null_rows med én række, der indeholder en null-værdi, og kontrollér, at den fjernes. Test derefter en række uden en null-værdi, og kontrollér, at den bevares. Enhedstest af transformationsfunktioner opdager regressioner, når koden til databehandlingsforløbet ændres.

Efterhånden som databehandlingsforløbet vokser, kan du opdele funktionerne i Python-modulfiler: extract.py, transform.py, load.py og validate.py. Hovedscriptet pipeline.py importerer modulerne og orkestrerer dem. Denne filstruktur er overskuelig, kan testes med pytest og kan installeres som en Python-pakke. Den afspejler den standardstruktur, som datateknikteams bruger med værktøjer som dbt eller Airflow.

En veldesignet forløbsfunktion er idempotent: Hvis du kører den to gange med de samme inputdata, giver det samme output og ingen bivirkninger. Undgå ændringer direkte i det eksisterende objekt (df.drop(..., inplace=True)), og brug altid df.copy() i begyndelsen af funktioner, der ændrer kolonner. Idempotente funktioner kan køres igen efter fejl uden at ødelægge outputdataene.

Tilføj Python-typeangivelser til transformationsfunktionernes signaturer for at gøre kontrakten tydelig: def transform(df: pd.DataFrame) -> pd.DataFrame. Typeangivelser dokumenterer sig selv — enhver udvikler, der læser funktionen, ved præcis, hvad den forventer og returnerer, uden at skulle læse funktionskroppen. De gør det også muligt for værktøjer til statisk analyse som mypy og IDE'ers automatiske fuldførelse at opdage typefejl før kørsel.

Hver transformationsfunktion bør have en docstring på én linje, der angiver, hvad den gør, hvilke kolonner den kræver, og hvilke kolonner den tilføjer eller fjerner. Gode docstrings gør funktionen nem at finde via help() og i IDE-værktøjstip. De fungerer også som specifikationsdokumenter: En fejlslagen kontrol, der er i modstrid med docstringen, er en fejl; en docstring, der ikke stemmer overens med koden, er en dokumentationsfejl.

Orkestrer den komplette ETL ved at kalde de tre faser i rækkefølge: extract, transform og load. Tilføj tidsmåling omkring hver fase for at se, hvor tiden bruges. Fang undtagelser fra hver fase separat, så fejlmeddelelserne identificerer, hvilken fase der mislykkedes. Log start- og sluttidspunktet for hele kørslen samt om den lykkedes eller mislykkedes, så den kan overvåges.

I denne lektion har du lært: at strukturere databehandlingsforløb som ETL-funktioner med ét ansvar, at gøre funktioner testbare, idempotente og selvdokumenterende med typeangivelser og docstrings og at orkestrere hele databehandlingsforløbet med tidsmåling og revisionslogning. Dernæst undersøger vi, hvordan databehandlingsforløb parameteriseres med konfigurationsordbøger, så de kan genbruges på forskellige datasæt.