Redigera

Share via

Orkestrera MLOps med hjälp av Azure Databricks

Azure Databricks

Lösningsidéer

Den här artikeln är en lösningsidé. Om du vill att vi ska utöka innehållet med mer information, till exempel potentiella användningsfall, alternativa tjänster, implementeringsöverväganden eller prisvägledning, kan du meddela oss genom att ge GitHub-feedback.

Den här artikeln innehåller en arkitektur och process för maskininlärningsåtgärder (MLOps) som använder Azure Databricks. Den här processen definierar ett standardiserat sätt att flytta maskininlärningsmodeller och pipelines från utveckling till produktion, med alternativ för att inkludera automatiserade och manuella processer.

Arkitektur

Diagram som visar en lösning för att använda Azure Databricks för MLOps.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Den här lösningen ger en robust MLOps-process som använder Azure Databricks. Alla element i arkitekturen kan anslutas, så du kan integrera andra Azure- och tredjepartstjänster i arkitekturen efter behov. Den här arkitekturen och beskrivningen är anpassad från e-boken The Big Book of MLOps. Den här e-boken utforskar arkitekturen som beskrivs här i detalj.

  • Källkontroll: Det här projektets kodlagringsplats organiserar notebook-filer, moduler och pipelines. Dataforskare skapar utvecklingsgrenar för att testa uppdateringar och nya modeller. Kod utvecklas i notebook-filer eller i IDE:er, som backas upp av Git, med Databricks Repos-integrering för synkronisering med dina Azure Databricks-arbetsytor. Källkontroll främjar maskininlärningspipelines från utveckling, mellanlagring (för testning) till produktion (för distribution).

  • Lakehouse – produktionsdata: Dataforskare arbetar i utvecklingsmiljön, där de har skrivskyddad åtkomst till produktionsdata. (Alternativt kan data speglas eller redigeras.) De har också läs- och skrivåtkomst till en utvecklingslagringsmiljö för utveckling och experimentering. Vi rekommenderar en Lakehouse-arkitektur för data där data lagras i Azure Data Lake Storage i Delta Lake-format . Åtkomstkontroller definieras med direktgenomströmning för Microsoft Entra-autentiseringsuppgifter eller tabellåtkomstkontroller.

Utveckling

I utvecklingsmiljön utvecklar dataforskare och tekniker maskininlärningspipelines.

  1. Undersökande dataanalys (EDA): Dataforskare utforskar data i en interaktiv, iterativ process. Det här ad hoc-arbetet kanske inte distribueras till mellanlagring eller produktion. Verktygen kan vara Databricks SQL, dbutils.data.summarizeoch AutoML.

  2. Modellträningoch andra maskininlärningspipelines: Maskininlärningspipelines utvecklas som modulär kod i notebook-filer och/eller ID:er. Till exempel läser modellträningspipelinen data från Funktionslager och andra Lakehouse-tabeller. Träning och justering av loggmodellparametrar och mått till MLflow-spårningsservern. API:et för funktionsarkivet loggar den slutliga modellen. Dessa loggar länkar modellen, dess indata och träningskoden.

  3. Incheckningskod: Dataexperten överför koden för funktionalisering, träning och andra pipelines till källkontroll för att höja arbetsflödet för maskininlärning mot produktion.

Mellanlagring

I mellanlagringsmiljön testar CI-infrastrukturen ändringar i maskininlärningspipelines i en miljö som efterliknar produktion.

  1. Sammanslagningsbegäran: När en sammanslagningsbegäran (eller pull)-begäran skickas mot projektets mellanlagringsgren (main) i källkontrollen, kör ett CI/CD-verktyg (kontinuerlig integrering och kontinuerlig leverans) som Azure DevOps tester.

  2. Enhets- och CI-tester: Enhetstester körs i CI-infrastruktur och integreringstester kör arbetsflöden från slutpunkt till slutpunkt på Azure Databricks. Om testerna godkänns sammanfogas koden.

  3. Skapa en versionsgren: När maskininlärningstekniker är redo att distribuera de uppdaterade maskininlärningspipelines till produktion kan de skapa en ny version. En distributionspipeline i CI/CD-verktyget distribuerar om de uppdaterade pipelinerna som nya arbetsflöden.

Produktion

Maskininlärningstekniker hanterar produktionsmiljön, där maskininlärningspipelines direkt hanterar slutprogram. Viktiga pipelines i funktionstabeller för produktionsuppdatering, träna och distribuera nya modeller, köra slutsatsdragning eller servering och övervaka modellprestanda.

  1. Uppdatering av funktionstabell: Den här pipelinen läser data, beräknar funktioner och skriver till Funktionslagertabeller . Den körs kontinuerligt i strömningsläge, körs enligt ett schema eller utlöses.

  2. Modellträning: I produktion utlöses eller schemaläggs modelltränings- eller omträningspipelinen för att träna en ny modell på de senaste produktionsdata. Modeller är registrerade i MLflow Model Registry.

  3. Kontinuerlig distribution: Registrering av nya modellversioner utlöser CD-pipelinen, som kör tester för att säkerställa att modellen fungerar bra i produktionen. När modellen klarar testerna spåras dess förlopp i modellregistret via modellstegsövergångar. Registerwebbhooks kan användas för automatisering. Tester kan omfatta efterlevnadskontroller, A/B-tester för att jämföra den nya modellen med den aktuella produktionsmodellen och infrastrukturtester. Testresultat och mått registreras i Lakehouse-tabeller. Du kan också kräva manuella signeringar innan modeller övergår till produktion.

  4. Modelldistribution: När en modell går in i produktion distribueras den för bedömning eller servering. De vanligaste distributionslägena är:

    • Batch- eller strömningsbedömning: För svarstider på minuter eller längre är batch- och strömning de mest kostnadseffektiva alternativen. Bedömningspipelinen läser de senaste data från Funktionsarkivet, läser in den senaste versionen av produktionsmodellen från modellregistret och utför slutsatsdragning i ett Databricks-jobb. Den kan publicera förutsägelser till Lakehouse-tabeller, en JDBC-anslutning (Java Database Anslut ivity), flata filer, meddelandeköer eller andra underordnade system.
    • Online-servering (REST API:er): För användningsfall med låg svarstid är onlineservering i allmänhet nödvändigt. MLflow kan distribuera modeller till MLflow Model Serving på Azure Databricks, molnleverantörstjänstsystem och andra system. I samtliga fall initieras serveringssystemet med den senaste produktionsmodellen från modellregistret. För varje begäran hämtar den funktioner från en funktionsbutik online och gör förutsägelser.

  5. Övervakning: Kontinuerliga eller periodiska arbetsflöden övervakar indata och modellförutsägelser för drift, prestanda och andra mått. Delta Live Tables kan förenkla automatiseringen av övervakningspipelines och lagra måtten i Lakehouse-tabeller. Databricks SQL, Power BI och andra verktyg kan läsa från dessa tabeller för att skapa instrumentpaneler och aviseringar.

  6. Omträning: Den här arkitekturen stöder både manuell och automatisk omträning. Schemalagda omträningsjobb är det enklaste sättet att hålla modellerna fräscha.

Komponenter

  • Data Lakehouse. En Lakehouse-arkitektur förenar de bästa elementen i datasjöar och informationslager och levererar datahantering och prestanda som vanligtvis finns i informationslager med de billiga, flexibla objektlager som erbjuds av datasjöar.
    • Delta Lake är det rekommenderade valet för ett dataformat med öppen källkod för ett lakehouse. Azure Databricks lagrar data i Data Lake Storage och tillhandahåller en högpresterande frågemotor.
  • MLflow är ett projekt med öppen källkod för att hantera livscykeln för maskininlärning från slutpunkt till slutpunkt. Det här är de viktigaste komponenterna:
    • Med spårning kan du spåra experiment för att registrera och jämföra parametrar, mått och modellartefakter.
    • Med MLFlow-modellen kan du lagra och distribuera modeller från alla maskininlärningsbibliotek till olika modellhanterings- och slutsatsdragningsplattformar.
    • Model Registry tillhandahåller ett centraliserat modellarkiv för hantering av modelllivscykelstegsövergångar från utveckling till produktion.
    • Med modellservering kan du vara värd för MLflow-modeller som REST-slutpunkter.
  • Azure Databricks. Azure Databricks tillhandahåller en hanterad MLflow-tjänst med företagssäkerhetsfunktioner, hög tillgänglighet och integrering med andra funktioner för Azure Databricks-arbetsytor.
    • Databricks Runtime for Machine Learning automatiserar skapandet av ett kluster som är optimerat för maskininlärning och förinstallerar populära maskininlärningsbibliotek som TensorFlow, PyTorch och XGBoost utöver Azure Databricks för Machine Learning-verktyg som AutoML- och Feature Store-klienter.
    • Feature Store är en centraliserad lagringsplats med funktioner. Det möjliggör funktionsdelning och identifiering, och det hjälper till att undvika datasnedvridning mellan modellträning och slutsatsdragning.
    • Databricks SQL. Databricks SQL ger en enkel upplevelse för SQL-frågor på Lakehouse-data och för visualiseringar, instrumentpaneler och aviseringar.
    • Databricks Repos tillhandahåller integrering med din Git-provider på Azure Databricks-arbetsytan, vilket förenklar samarbetsutvecklingen av notebook-filer eller kod och IDE-integrering.
    • Arbetsflöden och jobb är ett sätt att köra icke-interaktiv kod i ett Azure Databricks-kluster. För maskininlärning tillhandahåller jobb automatisering för förberedelse av data, funktionalisering, träning, slutsatsdragning och övervakning.

Alternativ

Du kan anpassa den här lösningen till din Azure-infrastruktur. Vanliga anpassningar är:

  • Flera utvecklingsarbetsytor som delar en gemensam produktionsarbetsyta.
  • Utbyte av en eller flera arkitekturkomponenter för din befintliga infrastruktur. Du kan till exempel använda Azure Data Factory för att samordna Databricks-jobb.
  • Integrera med dina befintliga CI/CD-verktyg via Git- och Azure Databricks REST-API:er.

Information om scenario

MLOps hjälper till att minska risken för fel i maskininlärnings- och AI-system och förbättra effektiviteten i samarbete och verktyg. En introduktion till MLOps och en översikt över den här arkitekturen finns i Architecting MLOps on the Lakehouse (Arkitekt MLOps på Lakehouse).

Med hjälp av den här arkitekturen kan du:

  • Anslut dina affärsintressenter med maskininlärnings- och datavetenskapsteam. Med den här arkitekturen kan dataforskare använda notebook-filer och ID:er för utveckling. Det gör det möjligt för affärsintressenter att visa mått och instrumentpaneler i Databricks SQL, allt inom samma Lakehouse-arkitektur.
  • Gör maskininlärningsinfrastrukturen datacentrisk. Den här arkitekturen behandlar maskininlärningsdata (data från funktionsutveckling, utbildning, slutsatsdragning och övervakning) precis som andra data. Den återanvänder verktyg för produktionspipelines, instrumentpaneler och annan allmän databehandling för bearbetning av maskininlärningsdata.
  • Implementera MLOps i moduler och pipelines. Precis som med alla program möjliggör modulära pipelines och kod i den här arkitekturen testning av enskilda komponenter och minskar kostnaden för framtida refaktorisering.
  • Automatisera dina MLOps-processer efter behov. I den här arkitekturen kan du automatisera steg för att förbättra produktiviteten och minska risken för mänskliga fel, men alla steg behöver inte automatiseras. Azure Databricks tillåter användargränssnitt och manuella processer utöver API:er för automatisering.

Potentiella användningsfall

Den här arkitekturen gäller för alla typer av maskininlärning, djupinlärning och avancerad analys. Vanliga maskininlärnings-/AI-tekniker som används i den här arkitekturen är:

  • Klassisk maskininlärning, som linjära modeller, trädbaserade modeller och ökning.
  • Modern djupinlärning, som TensorFlow och PyTorch.
  • Anpassad analys, till exempel statistik, Bayesianska metoder och grafanalys.

Arkitekturen stöder både små data (enskild dator) och stora data (distribuerad databehandling och GPU-accelererad). I varje steg i arkitekturen kan du välja beräkningsresurser och bibliotek för att anpassa till dina data- och problemdimensioner.

Arkitekturen gäller för alla typer av branscher och affärsanvändningsfall. Azure Databricks-kunder som använder den här och liknande arkitekturer inkluderar små och stora organisationer i branscher som dessa:

  • Konsumentvaror och detaljhandelstjänster
  • Financial services
  • Hälsovård och biovetenskap
  • Informationsteknik

Exempel finns på Databricks-webbplatsen.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Annan deltagare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg