Parameterisera pipelines med config-dict

En pipeline med hårdkodade filsökvägar, kolumnnamn och tröskelvärden slutar fungera när miljön ändras — till exempel vid en annan server, ett namnbyte på en kolumn eller en ändrad affärsregel. Varje ändring kräver att själva pipelinekoden redigeras, vilket ökar risken för fel. Lösningen är att flytta alla variabla värden till en konfigurationsordlista som läses in vid körning och skickas vidare till pipelinefunktionerna.

Ersätt varje hårdkodat värde med en post i en konfigurationsordlista. Gruppera relaterade inställningar logiskt: sökvägar för indata och utdata tillsammans, tröskelvärden för datarensning tillsammans och mappningar av kolumnnamn tillsammans. Config-dict blir den enda sanningskällan för alla pipelineparametrar. När ett värde i config ändras uppdateras varje funktion som använder det utan att funktionskropparna behöver ändras.

Extract-funktionen läser alla sina parametrar från config: indatasökvägen, datumkolumnerna som ska tolkas samt eventuella inställningar för teckenkodning eller avgränsare. Det innebär att samma pipeline kan köras mot ett testdataset eller en fil från en annan månad genom att endast ändra config — ingen kodändring krävs. Ni kan ha separata config-filer för utvecklings-, staging- och produktionsmiljöer.

Varje transformationsfunktion tar emot hela config och hämtar de värden den behöver. Funktioner bör använda config.get('key', default) med rimliga standardvärden så att pipelinen är robust även vid ofullständiga config-filer. En funktion som som standard kräver ett tröskelvärde på 5000 men kan åsidosättas via config är både säker och flexibel.

För pipelines i produktion bör config lagras i en JSON-fil i stället för i en Python-ordlista som är hårdkodad i skriptet. Läs in den med json.load() när pipelinen startar. Då kan driftteam ändra tröskelvärden utan åtkomst till Pythonkoden, och config kan versionshanteras med Git — varje ändring blir en spårad commit med en beskrivning av affärsorsaken till ändringen.

Underhåll separata config-filer för varje miljö: config_dev.json, config_staging.json och config_prod.json. Avgör vilken som ska läsas in baserat på en miljövariabel. Detta mönster förhindrar att produktionssökvägar till filer används av misstag under utveckling och håller miljöspecifika hemligheter (till exempel databasautentiseringsuppgifter) borta från det gemensamma kodarkivet.

Källdata har ofta kolumnnamn som skiljer sig från er interna namnstandard. I stället för att hårdkoda df.rename(columns={'OrderDate': 'order_date', 'Qty': 'quantity'}) i pipeline-koden kan ni lagra namnbytesmappningen i konfigurationen. Då blir pipelinen oberoende av källans kolumnnamn och enkel att anpassa när den uppströms dataleverantören ändrar sitt exportformat.

Aggregeringsfasen grupperar ofta efter olika kolumner för olika användningsområden. Lagra gruppnycklarna och aggregeringsspecifikationerna i konfigurationen i stället för att hårdkoda dem. Då kan analytiker skapa olika sammanfattningstabeller (per region, kategori eller månad) genom att ändra konfigurationen, utan att behöva ändra aggregeringsfunktionen. Funktionen blir en generell aggregator som helt styrs av konfigurationen.

Validera konfigurationen när pipelinen startar, så att saknade eller ogiltiga nycklar upptäcks innan några data har lästs in. En pipeline som körs i 10 minuter och sedan misslyckas eftersom revenue_cap var en sträng i stället för ett flyttal slösar med tid. Kontrollera att alla obligatoriska nycklar finns, att värdena har rätt typ och att sökvägarna är åtkomliga, med en kort konfigurationskontroll som körs innan någon kostsam I/O utförs.

Låt användare ange en ofullständig konfiguration som bara skriver över de värden de vill ändra. Slå samman användarkonfigurationen ovanpå en standardkonfiguration med {**defaults, **user_config}. Det här mönstret ger rimliga standardvärden samtidigt som allt fortfarande kan konfigureras. Det är samma mönster som används av populära Python-bibliotek som tar emot konfiguration som en dict eller kwargs.

Spara konfigurationen tillsammans med resultatfilen, så att alla som granskar resultatet direkt kan återskapa den pipelinekörning som skapade det. Lagra den som en JSON-sidofil med samma namn som resultatet, men med filändelsen .config.json. Ta med tidsstämpeln för pipelinekörningen i den sparade konfigurationen, så att varje resultatfil kan spåras fullständigt.

I den här lektionen har ni lärt er att: ersätta hårdkodade värden med en konfigurationsdict som läses in från JSON, skicka konfigurationen till funktioner för extrahering, transformering och aggregering för full parametrisering samt validera konfigurationer vid start och spara dem tillsammans med resultatfiler för reproducerbarhet. Nästa avsnitt handlar om att testa pipelinesteg med radantalskontroller och assertions.