Metodtips och rekommenderade CI/CD-arbetsflöden på Databricks

CI/CD (kontinuerlig integrering och kontinuerlig leverans) har blivit en hörnsten i modern datateknik och analys, eftersom det säkerställer att kodändringar integreras, testas och distribueras snabbt och tillförlitligt. Databricks inser att du kan ha olika CI/CD-krav formade av organisationens inställningar, befintliga arbetsflöden och specifika teknikmiljöer och tillhandahåller ett flexibelt ramverk som stöder olika CI/CD-alternativ.

På den här sidan beskrivs metodtips som hjälper dig att utforma och skapa robusta, anpassade CI/CD-pipelines som överensstämmer med dina unika behov och begränsningar. Genom att utnyttja dessa insikter kan du påskynda dina initiativ för datateknik och analys, förbättra kodkvaliteten och minska risken för distributionsfel.

Grundläggande principer för CI/CD

Effektiva CI/CD-arbetsflöden delar grundläggande principer oavsett implementationens detaljer. Följande universella metodtips gäller för organisationsinställningar, utvecklararbetsflöden och molnmiljöer och säkerställer konsekvens mellan olika implementeringar, oavsett om ditt team prioriterar notebook-utveckling eller infrastruktur som kod-arbetsflöden. Anta dessa principer som skyddsräcken samtidigt som du skräddarsyr detaljer efter din organisations teknikstack och processer.

• Versionskontroll allt
  • Lagra notebook-filer, skript, infrastrukturdefinitioner (IaC) och jobbkonfigurationer i Git.
  • Använd förgreningsstrategier, till exempel Gitflow, som är anpassade till standardmiljöer för utveckling, mellanlagring och produktionsdistribution.
• Automatisera testning
  • Implementera enhetstester för affärslogik med hjälp av bibliotek, till exempel pytest för Python och ScalaTest för Scala.
  • Verifiera notebook- och arbetsflödesfunktioner med verktyg, till exempel Databricks CLI bundle validate.
  • Använd integreringstester för arbetsflöden och datapipelines, till exempel chispa för Spark DataFrames.
• Använda infrastruktur som kod (IaC)
  • Definiera kluster, jobb och arbetsytekonfigurationer med Databricks Asset Bundles YAML eller Terraform.
  • Parameterisera i stället för hårdkodning av miljöspecifika inställningar, till exempel klusterstorlek och hemligheter.
• Isolera miljöer
  • Underhålla separata arbetsytor för utveckling, mellanlagring och produktion.
  • Använd MLflow Model Registry för modellering av versionshantering i olika miljöer.
• Välj verktyg som matchar ditt molnekosystem:
  • Azure: Azure DevOps och Databricks resursbuntar eller Terraform.
  • AWS: GitHub Actions och Databricks Asset Bundles eller Terraform.
  • GCP: Cloud Build och Databricks Asset Bundles eller Terraform.
• Övervaka och automatisera återställningar
  • Spåra distributionens framgångsgrader, jobbprestanda och testtäckning.
  • Implementera automatiserade återställningsmekanismer för misslyckade distributioner.
• Förena tillgångshantering
  • Använd Databricks-tillgångspaket för att distribuera kod, jobb och infrastruktur som en enda enhet. Undvik isolerad hantering av notebooks, bibliotek och arbetsflöden.

Databricks-tillgångspaket för CI/CD

Databricks Asset Bundles erbjuder en kraftfull, enhetlig metod för att hantera kod, arbetsflöden och infrastruktur i Databricks-ekosystemet och rekommenderas för dina CI/CD-pipelines. Genom att paketera dessa element i en enda YAML-definierad enhet förenklar paket distributionen och säkerställer konsekvens mellan miljöer. För användare som är vana vid traditionella CI/CD-arbetsflöden kan det dock krävas ett skifte i tankesättet för att införa paket.

Java-utvecklare används till exempel för att skapa JAR med Maven eller Gradle, köra enhetstester med JUnit och integrera dessa steg i CI/CD-pipelines. På samma sätt paketar Python-utvecklare ofta kod i hjul och testar med pytest, medan SQL-utvecklare fokuserar på frågevalidering och hantering av notebook-filer. Med paket konvergerar dessa arbetsflöden till ett mer strukturerat och normativt format, vilket betonar paketering av kod och infrastruktur för sömlös distribution.

I följande avsnitt beskrivs hur utvecklare kan anpassa sina arbetsflöden för att utnyttja paket effektivt.

Om du snabbt vill komma igång med Databricks-tillgångspaketen kan du prova en handledning: Utveckla ett jobb med Databricks-tillgångspaketen eller Utveckla deklarativa pipelines för Lakeflow med Databricks-tillgångspaketen.

Rekommendationer för CI/CD-källkontroll

Det första valet som utvecklare måste göra när de implementerar CI/CD är hur du lagrar och versionkällfiler. Med paket kan du enkelt innehålla allt – källkod, byggartefakter och konfigurationsfiler – och hitta dem på samma källkodslagringsplats, men ett annat alternativ är att separera paketkonfigurationsfiler från kodrelaterade filer. Valet beror på teamets arbetsflöde, projektkomplexitet och CI/CD-krav, men Databricks rekommenderar följande:

• För små projekt eller nära koppling mellan kod och konfiguration använder du en enda lagringsplats för både kod- och paketkonfiguration för att förenkla arbetsflöden.
• För större team eller oberoende versionscykler använder du separata lagringsplatser för kod- och paketkonfiguration, men etablerar tydliga CI/CD-pipelines som säkerställer kompatibilitet mellan versioner.

Oavsett om du väljer att samplaceera eller separera dina kodrelaterade filer från paketkonfigurationsfilerna ska du alltid använda versionshanterade artefakter, till exempel Git-incheckningshashvärden, när du laddar upp till Databricks eller extern lagring för att säkerställa spårnings- och återställningsfunktioner.

Enkel lagringsplats för kod och konfiguration

I den här metoden lagras både källkoden och paketkonfigurationsfilerna på samma lagringsplats. Detta förenklar arbetsflöden och säkerställer atomiska ändringar.

Exempel: Python-kod i ett paket

I det här exemplet finns Python-filer och paketfiler på en lagringsplats:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── workflows/
│   │   ├── my_pipeline.yml      # YAML pipeline def
│   │   └── my_pipeline_job.yml  # YAML job def that runs pipeline
│   ├── clusters/
│   │   ├── dev_cluster.yml      # development cluster def
│   │   └── prod_cluster.yml     # production def
├── src/
│   ├── my_pipeline.ipynb       # pipeline notebook
│   └── mypython.py              # Additional Python
└── README.md

Separata lagringsplatser för kod och konfiguration

I den här metoden finns källkoden på en lagringsplats, medan paketkonfigurationsfilerna underhålls i en annan. Det här alternativet är perfekt för större team eller projekt där separata grupper hanterar programutveckling och Databricks-arbetsflödeshantering.

Exempel: Java-projekt och -paket

I det här exemplet finns ett Java-projekt och dess filer på en lagringsplats och paketfilerna finns på en annan lagringsplats.

Lagringsplats 1: Java-filer

Den första lagringsplatsen innehåller alla Java-relaterade filer:

java-app-repo/
├── pom.xml                  # Maven build configuration
├── src/
│   ├── main/
│   │   ├── java/            # Java source code
│   │   │   └── com/
│   │   │       └── mycompany/
│   │   │           └── app/
│   │   │               └── App.java
│   │   └── resources/       # Application resources
│   └── test/
│       ├── java/            # Unit tests for Java code
│       │   └── com/
│       │       └── mycompany/
│       │           └── app/
│       │               └── AppTest.java
│       └── resources/       # Test-specific resources
├── target/                  # Compiled JARs and classes
└── README.md

• Utvecklare skriver programkod i src/main/java eller src/main/scala.
• Enhetstester lagras i src/test/java eller src/test/scala.
• Vid en pull request eller commit, CI/CD-pipelines:
  • Kompilera koden till en JAR, till exempel target/my-app-1.0.jar.
  • Ladda upp JAR-filen till en Databricks Unity Catalog-volym. Se ladda upp JAR.

Lagringsplats 2: Paketfiler

En andra lagringsplats innehåller endast paketkonfigurationsfilerna:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── jobs/
│   │   ├── my_java_job.yml  # YAML job dev
│   │   └── my_other_job.yml # Additional job definitions
│   ├── clusters/
│   │   ├── dev_cluster.yml  # development cluster def
│   │   └── prod_cluster.yml # production def
└── README.md

• Paketkonfigurationen databricks.yml och jobbdefinitionerna underhålls oberoende av varandra.

• Databricks.yml refererar till den uppladdade JAR-artefakten, till exempel:

  - jar: /Volumes/artifacts/my-app-${{ GIT_SHA }}.)jar
  

Rekommenderat CI/CD-arbetsflöde

Oavsett om du samlokaliserar eller separerar dina kodfiler från dina paketkonfigurationsfiler, skulle ett rekommenderat arbetsflöde vara följande:

1. Kompilera och testa koden

   • Utlöses vid en pull request eller ett commar till huvudgrenen.
   • Kompilera kod och köra enhetstester.
   • Mata ut en versionsfil, till exempel my-app-1.0.jar.

2. Ladda upp och lagra den kompilerade filen, till exempel en JAR-fil, till en Databricks Unity Catalog-volym.

   • Lagra den kompilerade filen i en Databricks Unity Catalog-volym eller en artefaktlagringsplats som AWS S3 eller Azure Blob Storage.
   • Använd ett versionsschema som är kopplat till Git-incheckningshashvärden eller semantisk versionshantering, till exempel dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jar.

3. Verifiera paketet

   • Kör databricks bundle validate för att säkerställa att konfigurationen databricks.yml är korrekt.
   • Det här steget säkerställer att felkonfigurationer, till exempel bibliotek som saknas, fångas tidigt.

4. Distribuera paketet

   • Använd databricks bundle deploy för att distribuera paketet till en mellanlagrings- eller produktionsmiljö.
   • Referera till det uppladdade kompilerade biblioteket i databricks.yml. Information om hur du refererar till bibliotek finns i Biblioteksberoenden för Databricks tillgångspaket.

CI/CD för maskininlärning

Maskininlärningsprojekt introducerar unika CI/CD-utmaningar jämfört med traditionell programvaruutveckling. När du implementerar CI/CD för ML-projekt måste du förmodligen överväga följande:

• Samordning med flera team: Dataforskare, ingenjörer och MLOps-team använder ofta olika verktyg och arbetsflöden. Databricks förenar dessa processer med MLflow för experimentspårning, deltadelning för datastyrning och Databricks-tillgångspaket för infrastruktur som kod.
• Data- och modellversionshantering: ML-pipelines kräver spårning, inte bara kod utan även träning av datascheman, funktionsdistributioner och modellartefakter. Databricks Delta Lake tillhandahåller ACID-transaktioner och tidsresor för dataversionshantering, medan MLflow Model Registry hanterar modellspårning.
• Reproducerbarhet mellan miljöer: ML-modeller är beroende av specifika kombinationer av data, kod och infrastruktur. Databricks-tillgångspaket säkerställer atomisk distribution av dessa komponenter i utvecklings-, mellanlagrings- och produktionsmiljöer med YAML-definitioner.
• Kontinuerlig omträning och uppföljning: Modeller försämras på grund av datadrift. Lakeflow Jobs möjliggör automatiserade omträningspipelines, medan MLflow integreras med Prometheus och Lakehouse Monitoring för att spåra prestanda.

MLOps Stacks för ML CI/CD

Databricks hanterar ML CI/CD-komplexitet via MLOps Stacks, ett ramverk i produktionsklass som kombinerar Databricks-tillgångspaket, förkonfigurerade CI/CD-arbetsflöden och modulära ML-projektmallar. Dessa stackar upprätthåller bästa praxis samtidigt som de möjliggör flexibilitet för samarbete över flera team inom dataingenjörskap, datavetenskap och MLOps-roller.

ML CI/CD-samarbete kan se ut så här:

• Datatekniker genomför ETL-pipelineändringar i ett paket, vilket utlöser automatiserad schemavalidering och en mellanlagringsdistribution.
• Dataforskare skickar ML-kod, vilken kör enhetstester och distribueras till en staging-miljö för integrationstestning.
• MLOps-tekniker granskar valideringsmått och höjer upp granskade modeller till produktion med hjälp av MLflow Registry.

Mer information om implementering finns i:

• MLOps Stacks-paket: Stegvis vägledning för paketinitiering och distribution.
• MLOps Stacks GitHub-lagringsplats: Förkonfigurerade mallar för träning, slutsatsdragning och CI/CD.

Genom att anpassa teamen till standardiserade paket och MLOps Stacks kan organisationer effektivisera samarbetet samtidigt som granskningsbarheten bibehålls i HELA ML-livscykeln.

CI/CD för SQL-utvecklare

SQL-utvecklare som använder Databricks SQL för att hantera strömmande tabeller och materialiserade vyer kan utnyttja Git-integrering och CI/CD-pipelines för att effektivisera sina arbetsflöden och underhålla högkvalitativa pipelines. I och med introduktionen av Git-stöd för frågor kan SQL-utvecklare fokusera på att skriva frågor samtidigt som Git kan versionskontrollera sina .sql filer, vilket möjliggör samarbete och automatisering utan att behöva djup infrastrukturexpertis. Dessutom möjliggör SQL-redigeraren samarbete i realtid och integreras sömlöst med Git-arbetsflöden.

För SQL-baserade arbetsflöden:

• Versionskontroll av SQL-filer

  • Lagra .sql filer i Git-lagringsplatser med hjälp av Databricks Git-mappar eller externa Git-leverantörer, till exempel GitHub, Azure DevOps.
  • Använd grenar (till exempel utveckling, mellanlagring, produktion) för att hantera miljöspecifika ändringar.

• Integrera .sql filer i CI/CD-pipelines för att automatisera distributionen:

  • Verifiera syntax- och schemaändringar under pull-begäranden.
  • Distribuera .sql filer till Databricks SQL-arbetsflöden eller jobb.

• Parameterisera för miljöisolering

  • Använd variabler i .sql filer för att dynamiskt referera till miljöspecifika resurser, till exempel datasökvägar eller tabellnamn:

    CREATE OR REFRESH STREAMING TABLE ${env}_sales_ingest AS SELECT * FROM read_files('s3://${env}-sales-data')
    

• Schemalägga och övervaka uppdateringar

  • Använd SQL-uppgifter i ett Databricks-jobb för att schemalägga uppdateringar av tabeller och materialiserade vyer (REFRESH MATERIALIZED VIEW view_name).
  • Övervaka uppdateringshistorik med hjälp av systemtabeller.

Ett arbetsflöde kan vara:

1. Utveckla: Skriv och testa .sql skript lokalt eller i Databricks SQL-redigeraren och checka sedan in dem till en Git-gren.
2. Verifiera: Under en pull-begäran validerar du syntax och schemakompatibilitet med hjälp av automatiserade CI-kontroller.
3. Distribuera: Distribuera .sql skript till målmiljön med hjälp av CI/CD-pipelines, till exempel GitHub Actions eller Azure Pipelines vid sammanslagning.
4. Övervaka: Använd Databricks-instrumentpaneler och aviseringar för att spåra frågeprestanda och datas färskhet.

CI/CD för instrumentpanelsutvecklare

Databricks stöder integrering av instrumentpaneler i CI/CD-arbetsflöden med databricks-tillgångspaket. Med den här funktionen kan instrumentpanelsutvecklare:

• Instrumentpaneler för versionskontroll, vilket säkerställer granskningsbarhet och förenklar samarbetet mellan team.
• Automatisera distribueringen av instrumentpaneler, jobb och pipelines över olika miljöer, för att säkerställa en integrerad och sammanhängande helhet.
• Minska manuella fel och se till att uppdateringar tillämpas konsekvent i olika miljöer.
• Underhåll arbetsflöden för analys av hög kvalitet samtidigt som du följer metodtipsen för CI/CD.

För instrumentpaneler i CI/CD:

• databricks bundle generate Använd kommandot för att exportera befintliga instrumentpaneler som JSON-filer och generera YAML-konfigurationen som innehåller den i paketet:

  resources:
    dashboards:
      sales_dashboard:
        display_name: 'Sales Dashboard'
        file_path: ./dashboards/sales_dashboard.lvdash.json
        warehouse_id: ${var.warehouse_id}
  

• Lagra dessa .lvdash.json filer i Git-lagringsplatser för att spåra ändringar och samarbeta effektivt.

• Distribuera instrumentpaneler automatiskt i CI/CD-pipelines med databricks bundle deploy. Till exempel GitHub Actions-steget för distribution:

  name: Deploy Dashboard
    run: databricks bundle deploy --target=prod
  env:
    DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
  

• Använd till exempel ${var.warehouse_id}variabler för att parametrisera konfigurationer som SQL-lager eller datakällor, vilket säkerställer sömlös distribution i utvecklings-, mellanlagrings- och produktionsmiljöer.

• Använd alternativet bundle generate --watch för att kontinuerligt synkronisera lokala JSON-instrumentpanelsfiler med ändringar som gjorts i Databricks-användargränssnittet. Om det uppstår avvikelser, använd flaggan --force under distributionen för att skriva över instrumentpaneler på distans med lokala versioner.

Information om instrumentpaneler i paket finns i instrumentpanelens resurs. Mer information om paketkommandon finns ibundle kommandogruppen.