Den här lösningen visar hur ett maskininlärningsteam kan använda Azure Databricks och Azure Kubernetes Service för att utveckla och distribuera maskininlärning som ett API för att förutsäga sannolikheten för anställdas attrition. API:et kan integreras med externa program som används av personalteamet för att ge ytterligare insikter om sannolikheten för attrition för en viss anställd inom organisationen. Den här informationen kan användas för att behålla medarbetare med hög påverkan som sannolikt kommer att lämna organisationen genom att ge Personal med möjlighet att proaktivt uppmuntra sådana anställda att stanna.
Apache®, Apache Ignite, Ignite och flamlogotypen är antingen registrerade varumärken eller varumärken som tillhör Apache Software Foundation i USA och/eller andra länder. Inget godkännande från Apache Software Foundation underförstås av användningen av dessa märken.
Arkitektur
Ladda ned en PowerPoint-fil för alla arkitekturer.
Arbetsflöde
På hög nivå hanterar den här lösningsdesignen varje steg i maskininlärningslivscykeln:
Dataförberedelse, som omfattar inköp, rensning och transformering av data för bearbetning och analys. Data kan finnas i en datasjö eller ett informationslager och lagras i ett funktionslager när de har kurerats.
Modellutveckling, som omfattar kärnkomponenter i modellutvecklingsprocessen, till exempel experimentspårning och modellregistrering med hjälp av MLflow.
Modelldistribution, som omfattar implementering av en CI/CD-pipeline (kontinuerlig integrering och kontinuerlig leverans) för att containerisera maskininlärningsmodeller som API-tjänster. Dessa tjänster distribueras till Azure Kubernetes-kluster som slutanvändarna kan använda.
Modellövervakning, som omfattar övervakning av API-prestanda och modelldataavvikelse genom att analysera loggtelemetri med Azure Monitor.
När maskininlärningsteamet har distribuerat maskininlärningsmodellen som ett API för slutsatsdragning i realtid kan utvecklare enkelt integrera API:et med externa program som används av externa team, till exempel Personalfrågor. Telemetri samlas in när ett externt team använder modelltjänsten. Maskininlärningsteamet kan använda den här telemetrin för att avgöra när modellen behöver distribueras om. Med den här metoden kan team arbeta självständigt och göra det möjligt för externa team att dra nytta av de kunskaper som det centraliserade maskininlärningsteamet har.
Kommentar
Du kan använda olika verktyg, till exempel Azure Pipelines och GitHub Actions, när du implementerar en CI/CD-pipeline.
De specifika affärskraven för ditt användningsfall för analys kan kräva olika tjänster eller funktioner som inte beaktas i den här designen.
Komponenter
Följande komponenter används som en del av den här designen:
Azure Databricks: En analystjänst för stordata som är enkel att använda, underlättar samarbete och baseras på Apache Spark. Azure Databricks är utformat för datavetenskap och datateknik.
Azure Kubernetes Service: En tjänst som tillhandahåller förenklad distribution och hantering av Kubernetes genom att avlasta driftkostnaderna till Azure.
Azure Container Registry: En privat registertjänst för hantering av containeravbildningar och artefakter. Den här tjänsten baseras på Docker med öppen källkod.
Azure Data Lake Storage: En tjänst som tillhandahåller skalbar lagring som är optimerad för enorma mängder ostrukturerade data. Data Lake Storage Gen2 erbjuder filsystemssemantik, säkerhet på filnivå och skalning.
Azure Monitor: En omfattande lösning för att samla in, analysera och agera på telemetri från dina arbetsbelastningar.
MLflow: En lösning med öppen källkod som är integrerad i Databricks för att hantera livscykeln för maskininlärning från slutpunkt till slutpunkt.
Azure API Management: En fullständigt hanterad tjänst som hjälper kunder att publicera, skydda, transformera, underhålla och övervaka API:er.
Azure Application Gateway: En lastbalanserare för webbtrafik som gör att du kan hantera trafik till dina webbprogram.
Azure DevOps eller GitHub: Lösningar för att implementera DevOps-metoder för att framtvinga automatisering och efterlevnad av dina pipelines för utveckling och distribution av arbetsbelastningar.
Information om scenario
Problemet med attrition av anställda har blivit framträdande sedan pandemin COVID-19. Denna trend, där anställda frivilligt avgår från sina jobb en masse, är populärt känd som den stora avgången. Problemet kan också förstoras för vissa avdelningar i en organisation som kanske saknar dedikerade team som utför avancerad analys, till exempel Personalfrågor.
Det här exempelscenariot illustrerar en driftsmodell för centraliserad maskininlärning. Detta består av ett centralt team som ansvarar för att skapa och distribuera maskininlärningsmodeller för externa team mellan avdelningar inom en organisation. Den här metoden är användbar när avdelningarna är för små för att underhålla ett team som är dedikerade till maskininlärning medan organisationen strävar efter att ingjuta avancerad analys i alla produkter och processer.
Potentiella användningsfall
Det här scenariot fokuserar på att skapa en maskininlärningsmodell för anställdas attrition och integrera den med externa program som används av personalteam. Designen kan dock generaliseras för många maskininlärningsarbetsbelastningar som skapas av både centraliserade och decentraliserade team.
Den här generaliserade metoden passar bäst för:
Maskininlärningsteam som har standardiserats på Databricks för datateknik eller maskininlärningsprogram.
Maskininlärningsteam som har erfarenhet av att distribuera och hantera Kubernetes-arbetsbelastningar och som föredrar att använda dessa kunskaper för att operationalisera maskininlärningsarbetsbelastningar.
Integrera maskininlärningsarbetsbelastningar med externa program som kräver korta svarstider och interaktiva modellförutsägelser (till exempel slutsatsdragning i realtid).
Att tänka på
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
Innan du implementerar den här lösningen kan du överväga några faktorer:
Den här lösningen är utformad för team som kräver en hög grad av anpassning och har omfattande kunskaper om att distribuera och hantera Kubernetes-arbetsbelastningar. Om ditt datavetenskapsteam inte har den här expertisen kan du överväga att distribuera modeller till en annan tjänst, till exempel Azure Machine Learning.
Metodtips för Machine Learning DevOps (MLOps) med Azure Machine Learning innehåller metodtips och rekommendationer för att införa ML-åtgärder (MLOps) i företaget med maskininlärning.
Följ rekommendationerna och riktlinjerna som definierats i Azure Well-Architected Framework för att förbättra kvaliteten på dina Azure-lösningar.
När du implementerar en CI/CD-pipeline kan du använda andra verktyg än i det här exemplet, till exempel Azure Pipelines och GitHub Actions. Mer information om CI/CD finns i CI/CD för mikrotjänstarkitekturer.
Specifika affärskrav för ditt analysanvändningsfall kan kräva användning av tjänster eller funktioner som inte beaktas i den här designen.
Kostnadsoptimering
Kostnadsoptimering handlar om att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.
Alla tjänster som distribueras i den här lösningen använder en förbrukningsbaserad prismodell. Du kan använda Priskalkylatorn för Azure för att beräkna kostnader för ett specifikt scenario. Andra överväganden finns i Kostnadsoptimering i det väldefinierade ramverket.
Distribuera det här scenariot
En proof-of-concept-implementering av det här scenariot finns tillgänglig på GitHub vid kvarhållning av anställda med Databricks och Kubernetes.
Ladda ned en PowerPoint-fil för all arkitektur.
Detta konceptbevis illustrerar:
- Så här tränar du en MLflow-modell för anställdas attrition på Azure Databricks.
- Paketera modeller som en webbtjänst med hjälp av verktyg med öppen källkod.
- Så här distribuerar du till Kubernetes via CI/CD med hjälp av GitHub Actions.
- Så här övervakar du API-prestanda och modelldataavvikelser i Azure Monitor- och Azure Log Analytics-arbetsytor.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Nicholas Moore | Molnlösningsarkitekt
Nästa steg
Produktdokumentation:
- Vad är Azure Databricks?
- MLflow-guide
- Azure Kubernetes Service
- Introduktion till privata Docker-containerregister i Azure
- Om API-hantering
- Vad är Azure Application Gateway?
- Introduktion till Azure Data Lake Storage Gen2
- Översikt över Azure Monitor
- Dokumentation om Azure DevOps
- Azure- och GitHub-integrering
Microsoft Learn-moduler:
- Utföra datavetenskap med Azure Databricks
- Skapa och använda maskininlärningslösningar med Azure Databricks
- Introduktion till Kubernetes i Azure
- Utveckla och distribuera program i Kubernetes
- Automatisera arbetsflödet med GitHub Actions
Relaterade resurser
Du kanske också tycker att dessa Architecture Center-artiklar är användbara: