I Apache Airflow er valget af executor en afgørende faktor for, hvordan opgaver bliver kørt, administreret og skaleret. Executorens primære opgave er at håndtere opgavernes eksekvering på de relevante arbejdsmaskiner. Afhængigt af systemkrav, ressourcebehov og kompleksiteten af de arbejdsprocesser, man ønsker at automatisere, kan forskellige executors være mere eller mindre passende. Her gennemgår vi nogle af de mest anvendte executors og deres anvendelsesmuligheder.

Local Executor (Lokalt eksekveringsmiljø)

Local Executor er en simpel løsning, der kan være tilstrækkelig for mindre arbejdsbelastninger og i scenarier, hvor opgaver ikke afhænger af hinanden. Denne executor er ideel til scenarier, hvor man ønsker at køre flere opgaver samtidig, men uden at bruge eksterne systemer. I eksemplet med to arbejdstagere (workers) ser vi, hvordan opgaver kan blive udført parallelt, hvor hver arbejdstager arbejder uafhængigt på deres opgave. Den største fordel ved Local Executor er enkelheden og den relativt hurtige opsætning, men samtidig er dens kapacitet begrænset af den fysiske maskine, der kører den.

Når det kommer til optimering af Local Executor, kan man justere graden af parallelisme, hvilket betyder, at flere opgaver kan køres samtidigt, afhængigt af maskinens kapacitet. Det gør den især effektiv for lange kørende opgaver, men det er vigtigt at huske på, at systemet kun kan skalere til en vis grænse, før det bliver nødvendigt at overveje andre løsninger.

Celery Executor (Remote Executor)

Celery Executor er et af de fjernexecutorsystemer, der bruger Celery, et distribueret opgavestyringssystem, som giver mulighed for at køre opgaver parallelt på flere maskiner. Denne executor er ideel til store Airflow-opsætninger, hvor opgaver skal fordeles over flere maskiner for at kunne håndtere et stort antal opgaveinstanser eller ressourcekrævende opgaver.

En af Celery Executors største fordele er dens skalerbarhed. Når arbejdsbyrden vokser, kan man nemt tilføje flere arbejdsmaskiner, hvilket gør systemet meget fleksibelt. Celery giver desuden mulighed for at adskille ressourcer, så bestemte opgaver kan tildeles specifikke maskiner med de nødvendige ressourcer eller konfigurationer. Det betyder, at opgaver ikke forstyrrer hinanden, og systemet kan håndtere høje krav til samtidighed og parallelisme.

Dog er Celery Executor ikke uden sine udfordringer. Opsætningen kræver flere komponenter, herunder en beskedbrokker som RabbitMQ eller Redis og en resultatbackend, hvilket gør den initiale opsætning mere kompleks end Local Executor. Derudover kan der opstå operationelle udfordringer ved at vedligeholde flere systemkomponenter, og der kan opstå latens ved kommunikationen mellem Airflow, brokeren og arbejdsmaskinerne.

Kubernetes Executor (Remote Executor)

Kubernetes Executor er designet til at køre opgaver i individuelle Kubernetes-podder, hvilket gør det til et dynamisk og skalerbart valg for store og komplekse arbejdsbelastninger. Kubernetes, som er en container-orchestration platform, giver mulighed for at køre opgaver på en dynamisk måde, hvor ressourcer tildeles ad hoc baseret på efterspørgslen. Denne executor er især nyttig, når opgaver kræver store mængder ressourcer som CPU, hukommelse eller GPU, eller når de skal køre i specifikke miljøer, der kræver særlige containerkonfigurationer.

Kubernetes Executor skaber en robust og fejltolerant infrastruktur, hvor podder automatisk kan genstartes, hvis de fejler, og opgaver kan omfordeles til andre podder. Det gør systemet ideelt til komplekse miljøer, der kræver høj tilgængelighed og skalerbarhed. Kubernetes gør det også muligt at udnytte skybaserede tjenester som GKE, EKS og AKS, hvilket gør opsætningen og administrationen lettere i cloud-miljøer.

En vigtig fordel ved Kubernetes Executor er dets dynamiske skalerbarhed. Ressourcer allokeres kun, når opgaverne køres, hvilket giver en mere effektiv udnyttelse af systemressourcerne. Derudover kan hver pod tilpasses med særlige konfigurationer, der gør det muligt at køre opgaver under forskellige betingelser. Denne fleksibilitet er en stor fordel i miljøer med meget varierende arbejdsbelastninger.

Der er dog også nogle overvejelser, man bør tage i betragtning, når man bruger Kubernetes Executor. Opsætning og vedligeholdelse af en Kubernetes-klynge kræver specialiseret viden om Kubernetes og distribuerede systemer, og der er også et overhead i forbindelse med at starte nye podder, som kan gøre det mindre effektivt for meget små eller hurtige opgaver.

Valg af den rette Executor

Når du skal vælge en executor til din Airflow-opsætning, er det vigtigt at overveje både den tekniske kompleksitet og de konkrete behov, som din arbejdsbyrde kræver. Hvis du arbejder med enkle opgaver og en enkelt maskine, kan Local Executor være tilstrækkelig. For større systemer med behov for skalerbarhed og parallelisme bør du overveje Celery Executor eller Kubernetes Executor. Hver af disse løsninger kommer med deres egne fordele og udfordringer, og det er nødvendigt at afveje disse mod de specifikke krav til systemets stabilitet, skalerbarhed og vedligeholdelse.

Uanset hvilken executor du vælger, er det essentielt at forstå de underliggende systemer og den infrastruktur, der er nødvendig for at støtte en effektiv og pålidelig eksekvering af opgaver. Det er også vigtigt at tage højde for fremtidig vækst og sikre, at den valgte løsning kan skaleres effektivt uden at skabe unødvendig kompleksitet.

Hvordan man definerer rækkefølgen af opgaver i Airflow DAG’er

Når man opretter en Directed Acyclic Graph (DAG) i Apache Airflow, er det vigtigt at definere, i hvilken rækkefølge opgaverne skal udføres. Dette kan virke simpelt, men for større og mere komplekse arbejdsgange er en korrekt opgaveordning afgørende for at sikre, at alle processer kører effektivt og uden problemer. I eksemplet, vi arbejder med, bruger vi en simpel rækkefølge, der eksplicit angiver, hvordan opgaverne skal køres med hjælp af >>-ikonet: get_pictures >> notify. Denne tilgang er især velegnet til mindre og enklere sæt af kode, hvor en grundlæggende forståelse af opgaveafhængigheder er tilstrækkelig.

Selvom den beskrevne metode fungerer godt for mindre projekter, er der flere avancerede måder at definere og håndtere opgaveafhængigheder i Airflow. Disse metoder vil blive udforsket nærmere i de senere kapitler. I øjeblikket er den vigtigste praktiske tilgang at bruge Airflow’s Graph-view for at visualisere, om de definerede afhængigheder og opgaveordninger er blevet korrekt implementeret. Når DAG’en er korrekt defineret, og Airflow har modtaget den nødvendige kode, vil du kunne se en oversigt, der ligner det billede, der er vist i den tilhørende figur.

I denne del har vi arbejdet med at oprette den første DAG, som involverer grundlæggende konfiguration, API-nøgler, DAG-struktur og hvordan operators fungerer i forhold til DAG’er. Det er vigtigt at forstå, at det er DAG-forfatteren og vedligeholderne af koden, der bestemmer, hvordan opgaverne skal opdeles og organiseres. At bryde opgaverne ned i mindre enheder gør det meget nemmere at fejlsøge og finde løsninger på problemer, sammenlignet med at arbejde med store, monolitiske opgaver. En god praksis er derfor altid at arbejde hen imod en arkitektur, der både opfylder udviklerens og brugerens behov i pipeline-strukturen.

Når man skaber og vedligeholder DAG’er, skal man tænke på skalerbarhed og vedligeholdelse. En veldesignet pipeline kræver ikke kun korrekt ordnede opgaver, men også, at man overvejer, hvordan hver enkelt opgave passer ind i den samlede workflow. Det er nødvendigt at sikre, at de rigtige opgaver er opdelt, og at Airflow’s ressourcer ikke overbelastes af unødvendige beregningstunge opgaver, som kunne køres eksternt.

I næste kapitel vil vi udvide funktionaliteten af notifikationer og vise, hvordan man kan integrere notifikationer via Slack og e-mail i arbejdsteamets kommunikation. Dette kan være særligt nyttigt i tilfælde af fejl i pipeline-strukturen, hvor man ønsker at få en øjeblikkelig advarsel, så der hurtigt kan tages hånd om problemer.

En vigtig overvejelse, som også vil blive behandlet i fremtidige kapitler, er hvordan man kan oprette forbindelser til eksterne kilder som databaser, API’er og cloud storage. Dette gør Airflow til et særligt kraftfuldt værktøj til workflow management, da det kan integrere med andre systemer og tjenester. Det er dog væsentligt at forstå, at Airflow selv ikke bør bruges til beregningstunge opgaver. I stedet bør sådanne opgaver køre på dedikerede platforme som Spark eller Hadoop eller cloud-baserede løsninger som Google Cloud Dataproc eller Amazon EMR. Airflow skal primært bruges som orkestrator, og ikke som den egentlige beregningsmaskine.

At forstå hvordan og hvor Airflow opbevarer sine forbindelser, er også centralt. Forbindelser i Airflow kan opbevares i metadata-databasen, som er tilgængelig gennem UI’et, eller i miljøvariabler og secrets backends, som AWS Secrets Manager. De forskellige metoder til at gemme og administrere forbindelser har deres fordele og ulemper. I store, distribuerede miljøer er det ofte mest hensigtsmæssigt at bruge secrets backends, da de giver en højere grad af sikkerhed og fleksibilitet, mens metadata-databasen er lettere at bruge i mindre opsætninger.

Det er desuden vigtigt at forstå, hvordan Airflow’s UI fungerer med hensyn til forbindelsehåndtering. Når en bruger navigerer til "Admin"-menuen og vælger "Connections", kan de tilføje, redigere eller slette forbindelser direkte. Airflow UI’en tillader også, at man duplicerer forbindelser, hvilket kan være nyttigt til at kopiere skabeloner for forbindelseindstillinger. Hver forbindelse har et unikt ID, der bruges til at referere til forbindelsen i DAG-koden, og forbindelsestyperne spænder fra cloud-udbydere som AWS, GCP og Azure til HTTP og FTP.

Afslutningsvis, når man arbejder med Airflow, er det afgørende at forstå, hvordan man korrekt håndterer opgaveordninger, eksterne forbindelser og ressourceforbrug. At bygge og vedligeholde en robust Airflow-pipeline kræver ikke blot teknisk viden, men også en systematisk tilgang til at organisere og strukturere de opgaver, der udføres.

Hvordan skaber vi vores egen legende? En refleksion over ideer, myter og konflikter
Hvordan Natyashastra Formede Indisk Teater og Estetik
Hvordan NeoReaktionær Teori Er Forbundet med Alt-Right: Teknologi, Race og Fremtidens Samfund
Hvordan Statistisk Analyse Kan Styrke Indfødte Identiteter og Kultur i Aotearoa
Hvordan AI og Robotics Arbejder Sammen for at Transformere Automatisering