Manuelle notebooks og jobs fungerer fint i starten. Men når pipelines bliver forretningskritiske, skaber Lakeflow Jobs og Declarative Automation Bundles det fundament, der gør platformen skalerbar, robust og nem at drifte.
Mange virksomheder baserer beslutninger og processer på data pipelines, der driftes manuelt med scripts, notebooks og løst sammenhængende jobs. Det fungerer fint i starten. Data-teamet kender virksomhedens data og arbejdsgange og ved, hvor de skal kigge, når noget fejler.
Når pipeline-landskabet vokser, bliver ændringer gradvist dyrere. Et fejlkonfigureret job i produktion kan betyde forsinkede rapporter, manglende dataleverancer til forretningen og flere timers fejlsøgning på tværs af miljøer.
Databricks understøtter begge tilgange - manuelle tasks og jobs, og en fuldt struktureret opsætning med graph-orkestrering på tværs af miljøer. Men hvornår er manuelle pipelines nok, og hvornår skal man skifte til et mere struktureret setup?
Databricks er en platform til at bygge og drive dataplatforme i enterprise-skala - fra dataopsamling og transformation til analytics og AI.
Virksomheder bruger den som det centrale lag, der forsyner forretningen med data til rapportering, automatisering og AI-produkter. Platformen er de facto-standard i mange store organisationer og kører typisk på Azure, AWS eller GCP.
Lakeflow Jobs er Databricks' orkestreringslag til data- og AI-workloads. Et job består af én eller flere tasks - notebooks, Python-scripts, SQL-queries eller eksterne integrationer - koblet som en Directed Acyclic Graph (DAG).
Rækkefølge, parallel udførelse og fejlhåndtering beskrives eksplicit i jobbet. Retry policies og alarmer er en del af opsætningen, så teamet ikke skal beslutte reaktionen i øjeblikket - særligt relevant når pipelines understøtter forretningskritiske processer.
En Directed Acyclic Graph er en grafstruktur, hvor noder repræsenterer tasks og kanter repræsenterer afhængigheder. "Acyclic" betyder ingen cirkulære afhængigheder - tasks køres altid i en defineret rækkefølge uden at vente på sig selv.
Declarative Automation Bundles (DAB) gør det muligt at definere hele Databricks-projektet som kode – jobs, compute, adgangsrettigheder og miljøkonfigurationer samlet i en central databricks.yml-fil. DABs er Databricks’ pendant til Infrastructure-as-Code (IaC), som man kender det fra Bicep eller Terraform i Microsoft Azure.
Bundlen beskriver targets for dev, test og prod, så samme projektstruktur kan deployes på tværs af miljøer med de forskelle, der hører til hvert miljø. Det gør bundlen til den autoritative kilde til, hvad der kører i produktion - og til hvad der har ændret sig, når noget fejler.
IaC er en tilgang, hvor infrastruktur og konfiguration beskrives som kode frem for at blive sat op manuelt. Det giver versionsstyring, reproducerbarhed og mulighed for CI/CD-integration på infrastrukturniveau. Kendte IaC-værktøjer er Terraform og Bicep - DABs er Databricks' tilsvarende implementering for pipeline-projekter.
Det afgørende spørgsmål er sjældent antallet af pipelines. Det er, hvor mange mennesker, miljøer og forretningsprocesser de understøtter.
Når flere udviklere arbejder på de samme pipelines, når produktion bliver forretningskritisk, eller når compliance-krav øges, begynder gevinsten ved Lakeflow Jobs og DABs typisk at overstige omkostningen ved at indføre dem. Konkret anbefaler vi skiftet, når:
Flere udviklere arbejder på de samme pipelines, og fejl som følge af manuelle ændringer bliver sværere at identificere og rette.
Pipelines understøtter processer, der ikke tåler nedetid eller datafejl - og hvor retry policies, alarmer og rollback skal være på plads fra starten.
Krav om dokumentation af ændringer gør manuelle deployments tidskrævende og revisionsmæssigt risikable.
Dev, test og prod skal opføre sig konsistent. Manuel konfiguration pr. miljø er ikke holdbart på skala.
Teamet sætter bundlen op, deployer manuelt fra en lokal maskine og betragter opgaven som løst. Det første tegn på, at det ikke holder, kommer typisk første gang noget fejler i produktion, og ingen kan svare på, hvad der er ændret siden sidst.
Vores anbefaling er at starte simpelt: manuelle notebooks og jobs er det rigtige udgangspunkt, når man prototyper, eksperimenterer, eller når pipelinen er enkel og overskuelig for hele teamet.
At gøre deployment til et pipeline-step i Azure DevOps eller GitHub Actions kræver, at teamet aftaler en branching-model og en deploy-strategi på tværs af miljøer. Det er der, gevinsten sidder: alle ved, hvad der kører, og ingen deployer manuelt til produktion.
Teams, der springer dette trin over og deployer manuelt, ender typisk med en bundle, der lever i én persons lokale miljø - og som ingen tør røre, fordi historikken mangler.
Hvis I kan svare ja til 3 eller flere af disse punkt, så vil DABs og Lakeflow Jobs typisk skabe mere værdi end manuel administration.
Flere end 2 udviklere arbejder parallelt på data pipelines.
Dev/test/produktion har udviklet sig til at have forskellige konfigurationer, som ikke er dokumenteret
En fejl i produktion har tidligere kostet mere end en time at spore til en specifik ændring
Pipelines understøtter kritiske forretningsprocesser
I ønsker CI/CD eller compliance-sporbarhed
Immeo har vi bygget moderne dataplatforme og data pipelines på Databricks med både DAB og Lakeflow Jobs som grundlag for pipeline-opsætningen. På 60 minutter kortlægger vi tre ting: hvem der deployer til produktion i dag, om development og produktion faktisk opfører sig ens, og hvor I har mest at vinde ved at skifte til CI/CD.
