Bygg en prediktiv vedlikeholdsløsning med Amazon Kinesis, AWS Glue og Amazon SageMaker

Organisasjoner bygger og bruker i økende grad maskinlæring (ML)-drevne løsninger for en rekke brukstilfeller og problemer, inkludert prediktivt vedlikehold av maskindeler, produktanbefalinger basert på kundepreferanser, kredittprofilering, innholdsmoderering, svindeloppdagelse og mer. I mange av disse scenariene kan effektiviteten og fordelene fra disse ML-drevne løsningene forbedres ytterligere når de kan behandle og utlede innsikt fra datahendelser i nesten sanntid.

Selv om forretningsverdien og fordelene med nesten sanntids ML-drevne løsninger er godt etablert, er arkitekturen som kreves for å implementere disse løsningene i stor skala med optimal pålitelighet og ytelse komplisert. Dette innlegget beskriver hvordan du kan kombinere Amazon Kinesis, AWS Limog Amazon SageMaker å bygge en funksjonsteknikk og slutningsløsning for nesten sanntid for prediktivt vedlikehold.

Bruk saksoversikt

Vi fokuserer på et prediktivt vedlikeholdsbruk der sensorer som er utplassert i felt (som industrielt utstyr eller nettverksenheter), må skiftes ut eller utbedres før de blir defekte og forårsaker nedetid. Nedetid kan være dyrt for bedrifter og kan føre til dårlig kundeopplevelse. Forutsigbart vedlikehold drevet av en ML-modell kan også bidra til å øke de vanlige planbaserte vedlikeholdssyklusene ved å informere når en maskindel i god stand ikke bør skiftes ut, og dermed unngå unødvendige kostnader.

I dette innlegget fokuserer vi på å bruke maskinlæring på et syntetisk datasett som inneholder maskinfeil på grunn av funksjoner som lufttemperatur, prosesstemperatur, rotasjonshastighet, dreiemoment og verktøyslitasje. Datasettet som brukes er hentet fra UCI Data Repository.

Maskinfeil består av fem uavhengige feilmoduser:

• Verktøyslitasjesvikt (TWF)
• Varmespredningssvikt (HDF)
• Strømsvikt (PWF)
• Overbelastningssvikt (OSF)
• Tilfeldig feil (RNF)

Maskinfeiletiketten indikerer om maskinen har feilet for et bestemt datapunkt hvis noen av de foregående feilmodusene er sanne. Hvis minst én av feilmodusene er sann, mislykkes prosessen og maskinfeiletiketten settes til 1. Målet for ML-modellen er å identifisere maskinfeil på riktig måte, slik at en nedstrøms prediktiv vedlikeholdshandling kan settes i gang.

Løsningsoversikt

For vårt prediktive vedlikeholdsbruk antar vi at enhetssensorer strømmer ulike målinger og avlesninger om maskindeler. Løsningen vår tar deretter et stykke strømmedata hver gang (mikrobatch), og utfører prosessering og funksjonsutvikling for å lage funksjoner. De opprettede funksjonene brukes deretter til å generere slutninger fra en trent og distribuert ML-modell i nesten sanntid. De genererte konklusjonene kan videre behandles og konsumeres av nedstrømsapplikasjoner, for å iverksette passende tiltak og starte vedlikeholdsaktivitet.

Følgende diagram viser arkitekturen til vår samlede løsning.

Løsningen består stort sett av følgende seksjoner, som er forklart i detalj senere i dette innlegget:

• Streaming av datakilde og inntak - Vi bruker Amazon Kinesis datastrømmer å samle strømmedata fra feltsensorene i stor skala og gjøre det tilgjengelig for videre behandling.
• Funksjonsteknikk i nesten sanntid – Vi bruker AWS Glue-strømmejobber til å lese data fra en Kinesis-datastrøm og utføre databehandling og funksjonsutvikling før vi lagrer de avledede funksjonene i Amazon enkel lagringstjeneste (Amazon S3). Amazon S3 gir et pålitelig og kostnadseffektivt alternativ for å lagre store datamengder.
• Modelltrening og utplassering – Vi bruker AI4I prediktivt vedlikeholdsdatasett fra UCI Data Repository for å trene en ML-modell basert på XGBoost-algoritmen ved å bruke SageMaker. Deretter distribuerer vi den trente modellen til et SageMaker asynkron inferensendepunkt.
• ML-slutning i nær sanntid – Etter at funksjonene er tilgjengelige i Amazon S3, må vi generere slutninger fra den distribuerte modellen i nesten sanntid. SageMaker asynkrone slutningsendepunkter er godt egnet for dette kravet fordi de støtter større nyttelaststørrelser (opptil 1 GB) og kan generere slutninger i løpet av minutter (opptil maksimalt 15 minutter). Vi bruker S3-hendelsesvarsler for å kjøre en AWS Lambda funksjon for å påkalle et SageMaker asynkron inferensendepunkt. SageMaker asynkrone slutningsendepunkter aksepterer S3-plasseringer som input, genererer slutninger fra den distribuerte modellen og skriver disse slutningene tilbake til Amazon S3 i nesten sanntid.

Kildekoden for denne løsningen er plassert på GitHub. Løsningen er testet og bør kjøres i us-east-1.

Vi bruker en AWS skyformasjon mal, distribuert ved hjelp av AWS-serverløs applikasjonsmodell (AWS SAM), og SageMaker bærbare datamaskiner for å distribuere løsningen.

Forutsetninger

For å komme i gang må du som en forutsetning ha SAM CLI, Python 3og PIP installert. Du må også ha AWS kommandolinjegrensesnitt (AWS CLI) riktig konfigurert.

Distribuere løsningen

Du kan bruke AWS CloudShell for å kjøre disse trinnene. CloudShell er et nettleserbasert skall som er forhåndsautentisert med konsolllegitimasjonen din og inkluderer forhåndsinstallerte vanlige utviklings- og driftsverktøy (som AWS SAM, AWS CLI og Python). Derfor er ingen lokal installasjon eller konfigurasjon nødvendig.

• Vi begynner med å lage en S3-bøtte der vi lagrer skriptet for AWS Glue-strømmejobben vår. Kjør følgende kommando i terminalen din for å lage en ny bøtte:

aws s3api create-bucket --bucket sample-script-bucket-$RANDOM --region us-east-1

• Noter ned navnet på bøtten som er opprettet.

• Deretter kloner vi kodelageret lokalt, som inneholder CloudFormation-malen for å distribuere stabelen. Kjør følgende kommando i terminalen din:

git clone https://github.com/aws-samples/amazon-sagemaker-predictive-maintenance

• Naviger til sam-mal-katalogen:

cd amazon-sagemaker-predictive-maintenance/sam-template

• Kjør følgende kommando for å kopiere AWS Glue-jobbskriptet (fra glue_streaming/app.py) til S3-bøtten du opprettet:

aws s3 cp glue_streaming/app.py s3://sample-script-bucket-30232/glue_streaming/app.py

• Du kan nå gå videre med byggingen og distribusjonen av løsningen, gjennom CloudFormation-malen via AWS SAM. Kjør følgende kommando:

sam deploy --guided

• Oppgi argumenter for distribusjonen, for eksempel stabelnavnet, foretrukket AWS-region (us-east-1), Og GlueScriptsBucket.

Sørg for at du oppgir samme S3-bøtte som du opprettet tidligere for AWS Glue script S3-bøtte (parameter GlueScriptsBucket i følgende skjermbilde).

Etter at du har oppgitt de nødvendige argumentene, starter AWS SAM stackdistribusjonen. Følgende skjermbilde viser ressursene som er opprettet.

Etter at stabelen er distribuert, bør du se følgende melding.

• På AWS CloudFormation-konsollen åpner du stabelen (for dette innlegget, nrt-streaming-inference) som ble gitt ved distribusjon av CloudFormation-malen.
• På Ressurser merker du SageMaker notatbokforekomst-ID.

• Åpne denne forekomsten på SageMaker-konsollen.

SageMaker notatbokforekomsten har allerede de nødvendige notatbøkene forhåndslastet.

Naviger til notatbøkene og åpne og følg instruksjonene i notatbøkene (Data_Pre-Processing.ipynb og ModelTraining-Evaluation-and-Deployment.ipynb) for å utforske datasettet, utføre forbehandling og funksjonsutvikling, og trene og distribuere modellen til et SageMaker asynkront inferensendepunkt.

Streaming av datakilde og inntak

Kinesis Data Streams er en serverløs, skalerbar og holdbar datastrømmetjeneste i sanntid som du kan bruke til å samle inn og behandle store datastrømmer i sanntid. Kinesis Data Streams gjør det mulig å fange opp, behandle og lagre datastrømmer fra en rekke kilder, for eksempel IT-infrastrukturloggdata, applikasjonslogger, sosiale medier, markedsdatafeeder, webklikkstrømdata, IoT-enheter og sensorer og mer. Du kan klargjøre en Kinesis-datastrøm i on-demand-modus eller klargjort modus avhengig av gjennomstrømnings- og skaleringskrav. For mer informasjon, se Velge modus for datastrømkapasitet.

For vårt bruk antar vi at ulike sensorer sender målinger som temperatur, rotasjonshastighet, dreiemoment og verktøyslitasje til en datastrøm. Kinesis Data Streams fungerer som en trakt for å samle inn og innta datastrømmer.

Vi bruker Amazon Kinesis Data Generator (KDG) senere i dette innlegget for å generere og sende data til en Kinesis-datastrøm, som simulerer data som genereres av sensorer. Dataene fra datastrømmen sensor-data-stream tas inn og behandles ved hjelp av en AWS Glue-strømmejobb, som vi diskuterer videre.

Funksjonsteknikk i nesten sanntid

AWS Glue-strømmejobber gi en praktisk måte å behandle strømmedata i stor skala, uten behov for å administrere datamiljøet. AWS Glue lar deg utføre uttrekk, transformasjon og lasting (ETL) operasjoner på strømmedata ved å bruke jobber som kjører kontinuerlig. AWS Glue streaming ETL er bygget på Apache Spark Structured Streaming-motoren, og kan innta strømmer fra Kinesis, Apache Kafka og Amazon administrerte strømming for Apache Kafka (Amazon MSK).

Streaming ETL-jobben kan bruke både AWS Glue innebygde transformasjoner og transformasjoner som er hjemmehørende i Apache Spark Structured Streaming. Du kan også bruke Spark ML og MLLib biblioteker i AWS Limjobber for enklere funksjonsbehandling ved hjelp av lett tilgjengelige hjelpebiblioteker.

Hvis skjemaet for strømmingsdatakilden er forhåndsbestemt, kan du spesifisere det i en AWS Data Catalog-tabell. Hvis skjemadefinisjonen ikke kan bestemmes på forhånd, kan du aktivere skjemadeteksjon i streaming ETL-jobben. Jobben bestemmer deretter automatisk skjemaet fra de innkommende dataene. I tillegg kan du bruke AWS limskjemaregister for å tillate sentral oppdagelse, kontroll og utvikling av datastrømskjemaer. Du kan videre integrere Schema Registry med datakatalogen for valgfritt å bruke skjemaer som er lagret i Schema Registry når du oppretter eller oppdaterer AWS Glue-tabeller eller -partisjoner i datakatalogen.

For dette innlegget lager vi en AWS Glue Data Catalog-tabell (sensor-stream) med Kinesis-datastrømmen vår som kilde og definere skjemaet for sensordataene våre.

Vi lager en AWS Glue dynamisk dataramme fra Data Catalog-tabellen for å lese strømmedataene fra Kinesis. Vi spesifiserer også følgende alternativer:

• En vindusstørrelse på 60 sekunder, slik at AWS Glue-jobben leser og behandler data i 60-sekunders vinduer
• Utgangsposisjonen TRIM_HORIZON, for å tillate lesing fra de eldste postene i Kinesis-datastrømmen

Vi bruker også Spark MLlib's StringIndexer funksjonstransformator for å kode strengkolonnetypen til etikettindekser. Denne transformasjonen er implementert ved hjelp av Spark ML Pipelines. Spark ML Pipelines gi et enhetlig sett med høynivå-API-er for ML-algoritmer for å gjøre det enklere å kombinere flere algoritmer til én enkelt pipeline eller arbeidsflyt.

Vi bruker foreachBatch API for å påkalle en funksjon kalt processBatch, som igjen behandler dataene det refereres til av denne datarammen. Se følgende kode:

# Read from Kinesis Data Stream
sourceStreamData = glueContext.create_data_frame.from_catalog(database = "sensordb", table_name = "sensor-stream", transformation_ctx = "sourceStreamData", additional_options = {"startingPosition": "TRIM_HORIZON"})
type_indexer = StringIndexer(inputCol="type", outputCol="type_enc", stringOrderType="alphabetAsc")
pipeline = Pipeline(stages=[type_indexer])
glueContext.forEachBatch(frame = sourceStreamData, batch_function = processBatch, options = {"windowSize": "60 seconds", "checkpointLocation": checkpoint_location})

Funksjonen processBatch utfører de spesifiserte transformasjonene og partisjonerer dataene i Amazon S3 basert på år, måned, dag og batch-ID.

Vi partisjonerer også AWS Glue-partisjonene på nytt i en enkelt partisjon, for å unngå å ha for mange små filer i Amazon S3. Å ha flere små filer kan hindre leseytelsen, fordi det forsterker overheaden knyttet til å søke, åpne og lese hver fil. Vi skriver til slutt funksjonene for å generere slutninger til et prefiks (funksjoner) i S3-bøtten. Se følgende kode:

# Function that gets called to perform processing, feature engineering and writes to S3 for every micro batch of streaming data from Kinesis.
def processBatch(data_frame, batchId):
transformer = pipeline.fit(data_frame)
now = datetime.datetime.now()
year = now.year
month = now.month
day = now.day
hour = now.hour
minute = now.minute
if (data_frame.count() > 0):
data_frame = transformer.transform(data_frame)
data_frame = data_frame.drop("type")
data_frame = DynamicFrame.fromDF(data_frame, glueContext, "from_data_frame")
data_frame.printSchema()
# Write output features to S3
s3prefix = "features" + "/year=" + "{:0>4}".format(str(year)) + "/month=" + "{:0>2}".format(str(month)) + "/day=" + "{:0>2}".format(str(day)) + "/hour=" + "{:0>2}".format(str(hour)) + "/min=" + "{:0>2}".format(str(minute)) + "/batchid=" + str(batchId)
s3path = "s3://" + out_bucket_name + "/" + s3prefix + "/"
print("-------write start time------------")
print(str(datetime.datetime.now()))
data_frame = data_frame.toDF().repartition(1)
data_frame.write.mode("overwrite").option("header",False).csv(s3path)
print("-------write end time------------")
print(str(datetime.datetime.now()))

Modelltrening og utplassering

SageMaker er en fullt administrert og integrert ML-tjeneste som gjør det mulig for dataforskere og ML-ingeniører å raskt og enkelt bygge, trene og distribuere ML-modeller.

Innenfor Data_Pre-Processing.ipynb-notisboken, vi importerer først AI4I Predictive Maintenance-datasettet fra UCI Data Repository og utfører utforskende dataanalyse (EDA). Vi utfører også funksjonsutvikling for å gjøre funksjonene våre mer nyttige for opplæring av modellen.

Innenfor datasettet har vi for eksempel en funksjon som heter type, som representerer produktets kvalitetstype som L (lav), M (middels) eller H (høy). Fordi dette er en kategorisk funksjon, må vi kode den før vi trener modellen vår. Vi bruker Scikit-Learns LabelEncoder for å oppnå dette:

from sklearn.preprocessing import LabelEncoder
type_encoder = LabelEncoder()
type_encoder.fit(origdf['type'])
type_values = type_encoder.transform(origdf['type'])

Etter at funksjonene er behandlet og de kurerte tog- og testdatasettene er generert, er vi klare til å trene en ML-modell for å forutsi om maskinen feilet eller ikke basert på systemavlesninger. Vi trener en XGBoost-modell ved å bruke den innebygde SageMaker-algoritmen. Xgboost kan gi gode resultater for flere typer ML-problemer, inkludert klassifisering, selv når treningsprøver er begrenset.

SageMaker treningsjobber gi en kraftig og fleksibel måte å trene ML-modeller på SageMaker. SageMaker administrerer den underliggende datainfrastrukturen og leverer flere alternativer å velge mellom, for ulike modellopplæringskrav, basert på brukssaken.

xgb = sagemaker.estimator.Estimator(container,
role,
instance_count=1,
instance_type='ml.c4.4xlarge',
output_path=xgb_upload_location,
sagemaker_session=sagemaker_session)
xgb.set_hyperparameters(max_depth=5,
eta=0.2,
gamma=4,
min_child_weight=6,
subsample=0.8,
silent=0,
objective='binary:hinge',
num_round=100)

xgb.fit({'train': s3_train_channel, 'validation': s3_valid_channel})

Når modellopplæringen er fullført og modellevalueringen er tilfredsstillende basert på forretningskravene, kan vi starte modelldistribusjon. Vi oppretter først en endepunktkonfigurasjon med AsyncInferenceConfig-objektalternativet og bruker modellen som er trent tidligere:

endpoint_config_name = resource_name.format("EndpointConfig")
create_endpoint_config_response = sm_client.create_endpoint_config(
EndpointConfigName=endpoint_config_name,
ProductionVariants=[
{
"VariantName": "variant1",
"ModelName": model_name,
"InstanceType": "ml.m5.xlarge",
"InitialInstanceCount": 1,
}
],
AsyncInferenceConfig={
"OutputConfig": {
"S3OutputPath": f"s3://{bucket}/{prefix}/output",
#Specify Amazon SNS topics
"NotificationConfig": {
"SuccessTopic": "arn:aws:sns:<region>:<account-id>:<success-sns-topic>",
"ErrorTopic": "arn:aws:sns:<region>:<account-id>:<error-sns-topic>",
}},
"ClientConfig": {"MaxConcurrentInvocationsPerInstance": 4},
},)

Vi oppretter deretter et SageMaker asynkront slutningsendepunkt ved å bruke endepunktkonfigurasjonen vi opprettet. Etter at det er klargjort, kan vi begynne å påkalle endepunktet for å generere slutninger asynkront.

endpoint_name = resource_name.format("Endpoint")
create_endpoint_response = sm_client.create_endpoint(
EndpointName=endpoint_name, EndpointConfigName=endpoint_config_name)

Nesten sanntidsslutning

SageMaker asynkron slutning endepunkter gir muligheten til å sette innkommende slutningsforespørsler i kø og behandle dem asynkront i nesten sanntid. Dette er ideelt for applikasjoner som har slutningsforespørsler med større nyttelaststørrelser (opptil 1 GB), som kan kreve lengre behandlingstider (opptil 15 minutter), og som har krav til ventetid nesten i sanntid. Asynkron inferens lar deg også spare kostnader ved å automatisk skalere forekomsttellingen til null når det ikke er noen forespørsler å behandle, slik at du bare betaler når endepunktet ditt behandler forespørsler.

Du kan opprette et SageMaker asynkront inferensendepunkt som ligner på hvordan du oppretter et sanntidsslutningsendepunkt og i tillegg spesifisere AsyncInferenceConfig objekt, mens du oppretter endepunktkonfigurasjonen med EndpointConfig-feltet i CreateEndpointConfig API. Følgende diagram viser inferensarbeidsflyten og hvordan et asynkront inferensendepunkt genererer en inferens.

For å påkalle det asynkrone inferensendepunktet, bør nyttelasten for forespørselen lagres i Amazon S3 og referanse til denne nyttelasten må oppgis som en del av InvokeEndpointAsync-forespørselen. Ved påkalling setter SageMaker forespørselen i kø for behandling og returnerer en identifikator og utdataplassering som et svar. Ved behandling plasserer SageMaker resultatet i Amazon S3-lokasjonen. Du kan valgfritt velge å motta suksess- eller feilmeldinger med Amazon enkel varslingstjeneste (Amazon SNS).

Test ende-til-ende-løsningen

For å teste løsningen, fullfør følgende trinn:

• På AWS CloudFormation-konsollen åpner du stabelen du opprettet tidligere (nrt-streaming-inference).
• På Utganger fanen, kopier navnet på S3-bøtten (EventsBucket).

Dette er S3-bøtten som AWS Glue-strømmejobben vår skriver funksjoner til etter å ha lest og behandlet fra Kinesis-datastrømmen.

Deretter setter vi opp hendelsesvarsler for denne S3-bøtten.

• Naviger til bøtta på Amazon S3-konsollen EventsBucket.
• På Eiendommer fanen, i Begivenhetsvarsler delen velger Opprett hendelsesvarsling.

• Til Arrangementsnavn, Tast inn invoke-endpoint-lambda.
• Til Prefix, Tast inn features/.
• Til suffiks, Tast inn .csv.
• Til Hendelsestyper, plukke ut Alle objekter skaper hendelser.

• Til Destinasjon, plukke ut Lambda funksjon.
• Til Lambda funksjon, og velg funksjonen invoke-endpoint-asynch.
• Velg lagre endringer.

• Åpne jobben på AWS Glue-konsollen GlueStreaming-Kinesis-S3.
• Velg Kjør jobb.

Deretter bruker vi Kinesis Data Generator (KDG) for å simulere sensorer som sender data til vår Kinesis-datastrøm. Hvis dette er første gang du bruker KDG, se Oversikt for det første oppsettet. KDG gir en CloudFormation-mal for å opprette brukeren og tildele akkurat nok tillatelser til å bruke KDG for å sende hendelser til Kinesis. Kjør CloudFormation-mal i AWS-kontoen du bruker til å bygge løsningen i dette innlegget. Etter at KDG er satt opp, logger du på og får tilgang til KDG for å sende testhendelser til Kinesis-datastrømmen vår.

• Bruk regionen der du opprettet Kinesis-datastrømmen (us-east-1).
• Velg datastrømmen på rullegardinmenyen sensor-data-stream.
• på Rekorder per sekund seksjon, velg Konstant og skriv inn 100.
• Opphev Komprimer poster.
• Til Opptaksmal, bruk følgende mal:

{
"air_temperature": {{random.number({"min":295,"max":305, "precision":0.01})}},
"process_temperature": {{random.number({"min":305,"max":315, "precision":0.01})}},
"rotational_speed": {{random.number({"min":1150,"max":2900})}},
"torque": {{random.number({"min":3,"max":80, "precision":0.01})}},
"tool_wear": {{random.number({"min":0,"max":250})}},
"type": "{{random.arrayElement(["L","M","H"])}}"
}

• Klikk Send data for å begynne å sende data til Kinesis-datastrømmen.

AWS Glue-strømmejobben leser og trekker ut en mikrobatch med data (som representerer sensoravlesninger) fra Kinesis-datastrømmen basert på vindusstørrelsen som er oppgitt. Strømmejobben behandler og utfører funksjonsutvikling på denne mikrobatchen før den partisjoneres og skrives til prefiksfunksjonene i S3-bøtten.

Ettersom nye funksjoner skapt av AWS Glue-strømmejobben skrives til S3-bøtten, vil en Lambda-funksjon (invoke-endpoint-asynch) utløses, som påkaller et SageMaker asynkront inferensendepunkt ved å sende en påkallingsforespørsel for å få slutninger fra vår distribuerte ML-modell. Sluttpunktet for asynkron inferens setter forespørselen om asynkron påkalling i kø. Når behandlingen er fullført, lagrer SageMaker slutningsresultatene på Amazon S3-posisjonen (S3OutputPath) som ble spesifisert under konfigurasjonen av asynkron inferensendepunkt.

For vår brukssituasjon indikerer slutningsresultatene om en maskindel sannsynligvis vil svikte eller ikke, basert på sensoravlesningene.

SageMaker sender også et suksess- eller feilvarsel med Amazon SNS. For eksempel, hvis du setter opp en e-post abonnement for suksess og feil SNS-emner (spesifisert i den asynkrone SageMaker-slutpunktkonfigurasjonen), kan en e-post sendes hver gang en slutningsforespørsel behandles. Følgende skjermbilde viser et eksempel på e-post fra SNS suksessemnet.

For applikasjoner i den virkelige verden kan du integrere SNS-varsler med andre tjenester som f.eks Amazon enkel køtjeneste (Amazon SQS) og Lambda for ytterligere etterbehandling av de genererte slutningene eller integrasjon med andre nedstrømsapplikasjoner, basert på dine krav. For eksempel, for vårt prediktive vedlikeholdsbruk, kan du aktivere en Lambda-funksjon basert på en SNS-varsling for å lese den genererte slutningen fra Amazon S3, behandle den videre (som aggregering eller filtrering), og starte arbeidsflyter som å sende arbeidsordrer for utstyrsreparasjon til teknikere.

Rydd opp

Når du er ferdig med å teste stabelen, slett ressursene (spesielt Kinesis-datastrømmen, Glue-strømmejobben og SNS-emner) for å unngå uventede kostnader.

Kjør følgende kode for å slette stabelen din:

sam delete nrt-streaming-inference

Slett også ressursene som SageMaker-endepunkter ved å følge oppryddingsdelen i notatboken ModelTraining-Evaluation-and-Deployment.

konklusjonen

I dette innlegget brukte vi en prediktiv brukssak for vedlikehold for å demonstrere hvordan man bruker ulike tjenester som Kinesis, AWS Glue og SageMaker for å bygge en nær-sanntids-inferenspipeline. Vi oppfordrer deg til å prøve denne løsningen og gi oss beskjed om hva du synes.

Hvis du har spørsmål, del dem i kommentarene.

Om forfatterne

Rahul Sharma er en løsningsarkitekt ved AWS Data Lab, og hjelper AWS-kunder med å designe og bygge AI/ML-løsninger. Før han begynte i AWS, har Rahul tilbrakt flere år i finans- og forsikringssektoren, og hjulpet kunder med å bygge data- og analytiske plattformer.

Pat Reilly er en arkitekt i AWS Data Lab, hvor han hjelper kunder med å designe og bygge dataarbeidsmengder for å støtte virksomheten deres. Før AWS konsulterte Pat hos en AWS-partner, og bygget opp AWS-dataarbeidsmengder på tvers av en rekke bransjer.