Lösningsidéer
I den här artikeln beskrivs en lösningsidé. Molnarkitekten kan använda den här vägledningen för att visualisera huvudkomponenterna för en typisk implementering av den här arkitekturen. Använd den här artikeln som utgångspunkt för att utforma en välkonstruerad lösning som överensstämmer med arbetsbelastningens specifika krav.
Den här artikeln innehåller en arkitektur och process för maskininlärningsåtgärder (MLOps) som använder Azure Databricks. Dataforskare och tekniker kan använda den här standardiserade processen för att flytta maskininlärningsmodeller och pipelines från utveckling till produktion.
Den här lösningen kan dra nytta av fullständig automatisering, kontinuerlig övervakning och robust samarbete och därför rikta in sig på en mlOps-mognadsnivå på nivå 4. Den här arkitekturen använder den uppflyttade kod som genererar modellmetoden snarare än metoden för att höja upp modeller . Den uppflyttade kod som genererar modellmetoden fokuserar på att skriva och hantera koden som genererar maskininlärningsmodeller. Rekommendationerna i den här artikeln innehåller alternativ för automatiserade eller manuella processer.
Arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
Arbetsflöde
Följande arbetsflöde motsvarar föregående diagram. Använd källkontroll och lagringskomponenter för att hantera och organisera kod och data.
Källkontroll: Det här projektets kodlagringsplats organiserar notebook-filer, moduler och pipelines. Du kan skapa utvecklingsgrenar för att testa uppdateringar och nya modeller. Utveckla kod i Notebook-filer som stöds av Git eller integrerade utvecklingsmiljöer (IDE:er) som integreras med Git-mappar så att du kan synkronisera med dina Azure Databricks-arbetsytor. Källkontroll främjar maskininlärningspipelines från utvecklingsmiljön, testning i mellanlagringsmiljön och distribution i produktionsmiljön.
Lakehouse-produktionsdata: Som dataexpert har du skrivskyddad åtkomst till produktionsdata i utvecklingsmiljön. Utvecklingsmiljön kan ha speglade data och redigerade konfidentiella data. Du har också läs- och skrivåtkomst i en utvecklingslagringsmiljö för utveckling och experimentering. Vi rekommenderar att du använder en lakehouse-arkitektur för data där du lagrar Delta Lake-formatdata i Azure Data Lake Storage. Ett sjöhus ger en robust, skalbar och flexibel lösning för datahantering. Om du vill definiera åtkomstkontroller använder du direktgenomströmnings - eller tabellåtkomstkontroller för Microsoft Entra ID-autentiseringsuppgifter.
Följande miljöer består av huvudarbetsflödet.
Utveckling
I utvecklingsmiljön utvecklar du maskininlärningspipelines.
Utföra undersökande dataanalys (EDA): Utforska data i en interaktiv, iterativ process. Du kanske inte distribuerar det här arbetet till mellanlagring eller produktion. Använd verktyg som Databricks SQL, kommandot dbutils.data.summarize och Databricks AutoML.
Utveckla modellträning och andra maskininlärningspipelines: Utveckla modulär kod för maskininlärningspipelines och samordna kod via Databricks Notebooks eller ett MLflow-projekt. I den här arkitekturen läser modellträningspipelinen data från funktionsarkivet och andra lakehouse-tabeller. Pipelinen tränar och justerar loggmodellparametrar och mått till MLflow-spårningsservern. Funktionslagrings-API:et loggar den slutliga modellen. Dessa loggar inkluderar modellen, dess indata och träningskoden.
Incheckningskod: Om du vill höja upp arbetsflödet för maskininlärning mot produktion måste du checka in koden för funktionalisering, träning och andra pipelines till källkontroll. I kodbasen placerar du maskininlärningskod och driftkod i olika mappar så att teammedlemmar kan utveckla kod samtidigt. Maskininlärningskod är kod som är relaterad till modellen och data. Driftskod är kod som är relaterad till Databricks-jobb och infrastruktur.
Den här kärncykeln med aktiviteter som du utför när du skriver och testar kod kallas för innerloop-processen. Om du vill utföra innerloopprocessen för utvecklingsfasen använder du Visual Studio Code i kombination med DEV-containern CLI och Databricks CLI. Du kan skriva koden och utföra enhetstestning lokalt. Du bör också skicka, övervaka och analysera modellpipelines från den lokala utvecklingsmiljön.
Mellanlagring
I mellanlagringsmiljön testar infrastruktur för kontinuerlig integrering (CI) ändringar i maskininlärningspipelines i en miljö som efterliknar produktion.
Sammanfoga en begäran: När du skickar en sammanslagningsbegäran eller pull-begäran mot projektets mellanlagringsgren (main) i källkontrollen, kör ett CI/CD-verktyg (kontinuerlig integrering och kontinuerlig leverans) som Azure DevOps tester.
Köra enhetstester och CI-tester: Enhetstester körs i CI-infrastruktur och integreringstester körs i arbetsflöden från slutpunkt till slutpunkt på Azure Databricks. Om testerna godkänns sammanfogas koden.
Skapa en versionsgren: När du vill distribuera de uppdaterade maskininlärningspipelines till produktion kan du 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.
Uppdatering av funktionstabell: Den här pipelinen läser data, beräknar funktioner och skriver till funktionslagertabeller . Du kan konfigurera den här pipelinen så att den antingen körs kontinuerligt i strömningsläge, körs enligt ett schema eller körs på en utlösare.
Modellträning: I produktion kan du konfigurera modelltränings- eller omträningspipelinen så att den antingen körs på en utlösare eller ett schema för att träna en ny modell på de senaste produktionsdata. Modeller registreras automatiskt i Unity Catalog.
Modellutvärdering och upphöjning: När en ny modellversion registreras utlöses CD-pipelinen, som kör tester för att säkerställa att modellen fungerar bra i produktionen. När modellen klarar tester spårar Unity Catalog förloppet via modellstegsövergångar. Testerna omfattar efterlevnadskontroller, A/B-tester för att jämföra den nya modellen med den aktuella produktionsmodellen och infrastrukturtester. Lakehouse-tabeller registrerar testresultat och mått. Du kan också kräva manuella signeringar innan modeller övergår till produktion.
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 Unity Catalog och utför slutsatsdragning i ett Databricks-jobb. Den kan publicera förutsägelser till Lakehouse-tabeller, en JDBC-anslutning (Java Database Connectivity), flata filer, meddelandeköer eller andra underordnade system.
Onlineservering (REST API:er): För användningsfall med låg latens behöver du vanligtvis onlineservering. MLflow kan distribuera modeller till Mosaic AI Model Serving, molnleverantörstjänstsystem och andra system. I samtliga fall initieras serversystemet med den senaste produktionsmodellen från Unity Catalog. För varje begäran hämtar den funktioner från en onlinefunktionsbutik och gör förutsägelser.
Övervakning: Kontinuerliga eller periodiska arbetsflöden övervakar indata och modellförutsägelser för drift, prestanda och andra mått. Du kan använda Delta Live Tables-ramverket för att automatisera övervakningen av pipelines 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. Om du vill övervaka programmått, loggar och infrastruktur kan du även integrera Azure Monitor med Azure Databricks.
Driftidentifiering och modellträning: Den här arkitekturen stöder både manuell och automatisk omträning. Schemalägg omträningsjobb för att hålla modellerna fräscha. När en identifierad drift överskrider ett förkonfigurerat tröskelvärde som du angav i övervakningssteget analyserar omträningspipelines omträningen av driften och utlösaromträningen. Du kan konfigurera pipelines så att de utlöses automatiskt, eller så kan du få ett meddelande och sedan köra pipelines manuellt.
Komponenter
En datasjöhusarkitektur förenar elementen i datasjöar och informationslager. Använd ett lakehouse för att få datahanterings- och prestandafunktioner som vanligtvis finns i informationslager, men med de billiga, flexibla objektlager som datasjöar erbjuder.
- Delta Lake är det rekommenderade dataformatet 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. MLflow har följande komponenter:
Spårningsfunktionen spårar experiment så att du kan registrera och jämföra parametrar, mått och modellartefakter.
- Automatisk loggning av Databricks utökar automatisk MLflow-loggning för att spåra maskininlärningsexperiment och loggar automatiskt modellparametrar, mått, filer och ursprungsinformation.
MLflow Model är ett format som du kan använda för att lagra och distribuera modeller från alla maskininlärningsbibliotek till olika plattformar för modellservering och slutsatsdragning.
Unity Catalog tillhandahåller centraliserade funktioner för åtkomstkontroll, granskning, ursprung och dataidentifiering i Azure Databricks-arbetsytor.
Mosaic AI Model Serving är värd för MLflow-modeller som REST-slutpunkter.
Azure Databricks tillhandahåller en hanterad MLflow-tjänst som har 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. Den förinstallerar även Azure Databricks för Machine Learning-verktyg, till exempel AutoML och funktionsarkivklienter.
Ett funktionslager är en centraliserad lagringsplats med funktioner. Använd funktionsarkivet för att identifiera och dela funktioner och förhindra datasnedvridning mellan modellträning och slutsatsdragning.
Databricks SQL integreras med en mängd olika verktyg så att du kan skapa frågor och instrumentpaneler i dina favoritmiljöer utan att anpassa dig till en ny plattform.
Git-mappar ger integrering med git-providern på Azure Databricks-arbetsytan, vilket förbättrar notebook- eller kodsamarbetet och IDE-integreringen.
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. Överväg följande anpassningar:
Använd flera utvecklingsarbetsytor som delar en gemensam produktionsarbetsyta.
Byt ut 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.
Använd Microsoft Fabric eller Azure Synapse Analytics som alternativa tjänster för maskininlärningsfunktioner.
Information om scenario
Den här lösningen ger en robust MLOps-process som använder Azure Databricks. Du kan ersätta alla element i arkitekturen så att du kan integrera andra Azure-tjänster och partnertjänster efter behov. Den här arkitekturen och beskrivningen är anpassad från e-boken The Big Book of MLOps. E-boken utforskar den här arkitekturen mer detaljerat.
MLOps hjälper till att minska risken för fel i maskininlärnings- och AI-system och förbättrar effektiviteten i samarbete och verktyg. En introduktion till MLOps och en översikt över den här arkitekturen finns i Arkitekt MLOps på lakehouse.
Använd den här arkitekturen för att:
Anslut dina affärsintressenter till maskininlärnings- och datavetenskapsteam. Använd den här arkitekturen för att införliva notebook-filer och ID:er för utveckling. Affärsintressenter kan 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 precis som andra data. Maskininlärningsdata innehåller data från funktionsutveckling, utbildning, slutsatsdragning och övervakning. Den här arkitekturen å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 använder du modulära pipelines och kod i den här arkitekturen för att testa enskilda komponenter och minska 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 du behöver inte automatisera varje steg. 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- och AI-tekniker 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 scenariots 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 arkitekturen omfattar små och stora organisationer i följande branscher:
- Konsumentvaror och detaljhandelstjänster
- Financial services
- Hälsovård och biovetenskap
- Informationsteknik
Exempel finns i Databricks-kunder.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudsakliga författare:
- Brandon Cowen | Senior Cloud Solution Architect
- Prabal Deb | Huvudprogramtekniker
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.