Redigera

Batchbedömning av Python-modeller i Azure

Azure Container Registry
Azure Event Hubs
Azure Machine Learning
Azure SQL Database
Azure Stream Analytics

Den här arkitekturguiden visar hur du skapar en skalbar lösning för batchbedömningsmodeller i Azure Machine Learning. Lösningen kan användas som en mall och kan generalisera till olika problem.

Arkitektur

Arkitekturdiagram som visar batchbedömning av Python-modeller i Azure

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

Arbetsflöde

Den här arkitekturguiden gäller för både strömmande och statiska data, förutsatt att inmatningsprocessen anpassas till datatypen. Följande steg och komponenter beskriver inmatningen av dessa två typer av data.

Strömmande data:

  1. Strömmande data kommer från IoT-sensorer, där nya händelser strömmas med jämna mellanrum.
  2. Inkommande direktuppspelningshändelser placeras i kö med Hjälp av Azure Event Hubs och bearbetas sedan i förväg med Hjälp av Azure Stream Analytics.
    • Azure Event Hubs. Den här tjänsten för inmatning av meddelanden kan mata in miljontals händelsemeddelanden per sekund. I den här arkitekturen skickar sensorer en dataström till händelsehubben.
    • Azure Stream Analytics. En händelsebearbetningsmotor. Ett Stream Analytics-jobb läser dataströmmarna från händelsehubben och utför dataströmbearbetning.

Statiska data:

  1. Statiska datamängder kan lagras som filer i Azure Data Lake Storage eller i tabellformat i Azure Synapse eller Azure SQL Database.
  2. Azure Data Factory kan användas för att aggregera eller förbearbeta den lagrade datamängden.

Den återstående arkitekturen, efter datainmatning, är lika med både strömmande och statiska data och består av följande steg och komponenter:

  1. Inmatade, aggregerade eller förbearbetade data kan lagras som dokument i Azure Data Lake Storage eller i tabellformat i Azure Synapse eller Azure SQL Database. Dessa data förbrukas sedan av Azure Machine Learning.
  2. Azure Machine Learning används för att träna, distribuera och hantera maskininlärningsmodeller i stor skala. I samband med batchbedömning skapar Azure Machine Learning ett kluster med virtuella datorer med ett alternativ för automatisk skalning, där jobb körs parallellt från och med Python-skript.
  3. Modeller distribueras som hanterade Batch-slutpunkter, som sedan används för att utföra batchinferenser på stora datavolymer under en tidsperiod. Batch-slutpunkter tar emot pekare till data och kör jobb asynkront för att bearbeta data parallellt i beräkningskluster.
  4. Slutsatsdragningsresultatet kan lagras som dokument i Azure Data Lake Storage eller i tabellformat i Azure Synapse eller Azure SQL Database.
  5. Visualisera: De lagrade modellresultaten kan användas via användargränssnitt, till exempel Power BI-instrumentpaneler eller via anpassade webbprogram.

Komponenter

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.

Prestanda

För Python-standardmodeller är det allmänt accepterat att processorer räcker för att hantera arbetsbelastningen. Den här arkitekturen använder processorer. Men för djupinlärningsarbetsbelastningar överträffar grafikprocessorer (GPU: er) vanligtvis processorer med en betydande mängd. Ett stort kluster med processorer behövs vanligtvis för att få jämförbara prestanda.

Parallellisera mellan virtuella datorer och kärnor

När du kör bedömningsprocesser för många modeller i batchläge måste jobben parallelliseras mellan virtuella datorer. Två metoder är möjliga:

  • Skapa ett större kluster med hjälp av billiga virtuella datorer.
  • Skapa ett mindre kluster med högpresterande virtuella datorer med fler kärnor tillgängliga på var och en.

I allmänhet är bedömning av Python-standardmodeller inte lika krävande som bedömning av djupinlärningsmodeller, och ett litet kluster bör kunna hantera ett stort antal köade modeller effektivt. Du kan öka antalet klusternoder i takt med att datamängdsstorlekarna ökar.

För att underlätta i det här scenariot skickas en bedömningsuppgift i ett enda Azure Machine Learning-pipelinesteg . Det kan dock vara effektivare att poängsätta flera datasegment i samma pipelinesteg. I dessa fall skriver du anpassad kod för att läsa i flera datauppsättningar och köra bedömningsskriptet under en körning i ett enda steg.

Hantering

  • Övervaka jobb. Det är viktigt att övervaka förloppet för jobb som körs. Det kan dock vara en utmaning att övervaka över ett kluster med aktiva noder. Om du vill kontrollera tillståndet för noderna i klustret använder du Azure-portalen för att hantera Machine Learning-arbetsytan. Om en nod är inaktiv eller om ett jobb har misslyckats sparas felloggarna i bloblagringen och är också tillgängliga i avsnittet Pipelines . För mer omfattande övervakning ansluter du loggar till Application Insights eller kör separata processer för att söka efter tillståndet för klustret och dess jobb.
  • Loggning. Machine Learning loggar alla stdout/stderr till det associerade Azure Storage-kontot. Om du enkelt vill visa loggfilerna använder du ett lagringsnavigeringsverktyg som Azure Storage Explorer.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

De dyraste komponenterna som används i den här arkitekturguiden är beräkningsresurserna. Beräkningsklustrets storlek skalas upp och ned beroende på jobben i kön. Aktivera automatisk skalning programmatiskt via Python SDK genom att ändra konfigurationen för beräkningsetablering. Du kan också använda Azure CLI för att ange parametrarna för automatisk skalning i klustret.

För arbete som inte kräver omedelbar bearbetning konfigurerar du formeln för automatisk skalning så att standardtillståndet (minimum) är ett kluster med noll noder. Med den här konfigurationen börjar klustret med noll noder och skalas bara upp när det identifierar jobb i kön. Om batchbedömningsprocessen bara sker några gånger om dagen eller mindre möjliggör den här inställningen betydande kostnadsbesparingar.

Automatisk skalning kanske inte är lämplig för batchjobb som sker för nära varandra. Eftersom den tid det tar för ett kluster att starta och spinna ned medför en kostnad, kan det vara mer kostnadseffektivt att hålla klustret igång mellan jobb om en batcharbetsbelastning börjar bara några minuter efter att det tidigare jobbet har avslutats. Den här strategin beror på om bedömningsprocesser är schemalagda att köras med hög frekvens (till exempel varje timme) eller mindre ofta (till exempel en gång i månaden).

Deltagare

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

Huvudsakliga författare:

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

Nästa steg

Produktdokumentation:

Microsoft Learn-moduler: