Bouw een oplossing voor voorspellend onderhoud met Amazon Kinesis, AWS Glue en Amazon SageMaker

Organisaties bouwen en gebruiken steeds vaker door machine learning (ML) gebaseerde oplossingen voor verschillende gebruikssituaties en problemen, waaronder voorspellend onderhoud van machineonderdelen, productaanbevelingen op basis van klantvoorkeuren, kredietprofilering, contentmoderatie, fraudedetectie en meer. In veel van deze scenario's kunnen de effectiviteit en voordelen van deze ML-gestuurde oplossingen verder worden verbeterd wanneer ze in bijna realtime inzichten uit gegevensgebeurtenissen kunnen verwerken en afleiden.

Hoewel de zakelijke waarde en voordelen van bijna-realtime ML-aangedreven oplossingen goed ingeburgerd zijn, is de architectuur die nodig is om deze oplossingen op schaal te implementeren met optimale betrouwbaarheid en prestaties ingewikkeld. Dit bericht beschrijft hoe je kunt combineren Amazon Kinesis, AWS lijm en Amazon Sage Maker om een ​​bijna-realtime feature-engineering- en inferentieoplossing voor voorspellend onderhoud te bouwen.

Gebruik case-overzicht

We richten ons op een geval van voorspellend onderhoud waarbij sensoren die in het veld worden ingezet (zoals industriële apparatuur of netwerkapparatuur), moeten worden vervangen of gecorrigeerd voordat ze defect raken en uitvaltijd veroorzaken. Downtime kan duur zijn voor bedrijven en kan leiden tot een slechte klantervaring. Voorspellend onderhoud op basis van een ML-model kan ook helpen bij het uitbreiden van de reguliere onderhoudscycli op basis van schema's door te informeren wanneer een machineonderdeel in goede staat niet moet worden vervangen, waardoor onnodige kosten worden vermeden.

In deze post richten we ons op het toepassen van machine learning op een synthetische dataset die machinestoringen bevat als gevolg van functies zoals luchttemperatuur, procestemperatuur, rotatiesnelheid, koppel en gereedschapsslijtage. De gebruikte dataset is afkomstig van de UCI-gegevensrepository.

Machinestoring bestaat uit vijf onafhankelijke storingsmodi:

• Gereedschapsslijtagefout (TWF)
• Warmteafvoerfout (HDF)
• Stroomstoring (PWF)
• Overbelastingsfout (OSF)
• Willekeurige storing (RNF)

Het machinefoutlabel geeft aan of de machine is uitgevallen voor een bepaald gegevenspunt als een van de voorgaande foutmodi waar is. Als ten minste één van de storingsmodi waar is, mislukt het proces en wordt het machinestoringslabel ingesteld op 1. Het doel van het ML-model is om machinestoringen correct te identificeren, zodat een downstream voorspellende onderhoudsactie kan worden gestart.

Overzicht oplossingen

Voor ons gebruiksscenario voor voorspellend onderhoud gaan we ervan uit dat apparaatsensoren verschillende metingen en metingen over machineonderdelen streamen. Onze oplossing neemt vervolgens elke keer een stukje streaminggegevens (microbatch) en voert verwerking en feature-engineering uit om functies te creëren. De gemaakte functies worden vervolgens gebruikt om in bijna realtime gevolgtrekkingen te genereren uit een getraind en geïmplementeerd ML-model. De gegenereerde gevolgtrekkingen kunnen verder worden verwerkt en geconsumeerd door downstream-applicaties, om passende acties te ondernemen en onderhoudsactiviteiten te starten.

Het volgende diagram toont de architectuur van onze algemene oplossing.

De oplossing bestaat in grote lijnen uit de volgende secties, die later in dit bericht in detail worden uitgelegd:

• Streaming gegevensbron en opname - We gebruiken Amazon Kinesis-gegevensstromen om op schaal streaminggegevens van de veldsensoren te verzamelen en beschikbaar te stellen voor verdere verwerking.
• Near-realtime feature-engineering - We gebruiken AWS Glue-streamingtaken om gegevens uit een Kinesis-gegevensstroom te lezen en gegevensverwerking en feature-engineering uit te voeren, voordat we de afgeleide functies opslaan in Amazon eenvoudige opslagservice (Amazon S3). Amazon S3 biedt een betrouwbare en kosteneffectieve optie om grote hoeveelheden gegevens op te slaan.
• Modeltraining en -implementatie - We gebruiken de AI4I predictive maintenance dataset van de UCI Data Repository om een ​​ML-model te trainen op basis van het XGBoost-algoritme met behulp van SageMaker. Vervolgens implementeren we het getrainde model op een asynchrone inferentie-eindpunt van SageMaker.
• Bijna realtime ML-inferentie – Nadat de functies beschikbaar zijn in Amazon S3, moeten we in bijna realtime gevolgtrekkingen genereren uit het geïmplementeerde model. Asynchrone inferentie-eindpunten van SageMaker zijn zeer geschikt voor deze vereiste omdat ze grotere payloads (tot 1 GB) ondersteunen en binnen enkele minuten (tot maximaal 15 minuten) gevolgtrekkingen kunnen genereren. We gebruiken S3-gebeurtenismeldingen om een AWS Lambda functie om een ​​asynchrone inferentie-eindpunt van SageMaker aan te roepen. Asynchrone inferentie-eindpunten van SageMaker accepteren S3-locaties als invoer, genereren gevolgtrekkingen van het geïmplementeerde model en schrijven deze gevolgtrekkingen in bijna realtime terug naar Amazon S3.

De broncode voor deze oplossing bevindt zich op GitHub. De oplossing is getest en moet worden uitgevoerd in us-east-1.

We gebruiken een AWS CloudFormatie sjabloon, geïmplementeerd met behulp van AWS serverloos toepassingsmodel (AWS SAM) en SageMaker-notebooks om de oplossing te implementeren.

Voorwaarden

Om aan de slag te gaan, moet u als voorwaarde beschikken over: SAM CLI, Python 3 en PIP geïnstalleerd. Je moet ook de AWS-opdrachtregelinterface (AWS CLI) correct geconfigureerd.

Implementeer de oplossing

Je kunt gebruiken AWS-cloudshell om deze stappen uit te voeren. CloudShell is een browsergebaseerde shell die vooraf is geverifieerd met uw consolereferenties en die vooraf geïnstalleerde algemene ontwikkelings- en bewerkingstools bevat (zoals AWS SAM, AWS CLI en Python). Daarom is er geen lokale installatie of configuratie vereist.

• We beginnen met het maken van een S3-bucket waarin we het script opslaan voor onze AWS Glue-streamingtaak. Voer de volgende opdracht uit in uw terminal om een ​​nieuwe bucket te maken:

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

• Noteer de naam van de gemaakte bucket.

• Vervolgens klonen we de coderepository lokaal, die de CloudFormation-sjabloon bevat om de stapel te implementeren. Voer de volgende opdracht uit in uw terminal:

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

• Navigeer naar de sam-sjabloonmap:

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

• Voer de volgende opdracht uit om het AWS Glue-taakscript (van glue_streaming/app.py) te kopiëren naar de S3-bucket die u hebt gemaakt:

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

• U kunt nu doorgaan met het bouwen en implementeren van de oplossing, via de CloudFormation-sjabloon via AWS SAM. Voer de volgende opdracht uit:

sam deploy --guided

• Geef argumenten voor de implementatie op, zoals de stacknaam, de gewenste AWS-regio (us-east-1), En GlueScriptsBucket.

Zorg ervoor dat u dezelfde S3-bucket opgeeft die u eerder hebt gemaakt voor het AWS Glue-script S3-bucket (parameter GlueScriptsBucket in de volgende schermafbeelding).

Nadat u de vereiste argumenten hebt opgegeven, start AWS SAM de stackimplementatie. De volgende schermafbeelding toont de gemaakte bronnen.

Nadat de stapel met succes is geïmplementeerd, zou u het volgende bericht moeten zien.

• Open op de AWS CloudFormation-console de stapel (voor dit bericht, nrt-streaming-inference) die is opgegeven bij het implementeren van de CloudFormation-sjabloon.
• Op de Resources tabblad, noteer de SageMaker-notebookinstantie-ID.

• Open deze instantie op de SageMaker-console.

De SageMaker-notebookinstantie heeft al de vereiste notebooks vooraf geladen.

Navigeer naar de map notebooks en open en volg de instructies in de notebooks (Data_Pre-Processing.ipynb en ModelTraining-Evaluation-and-Deployment.ipynb) om de dataset te verkennen, voorverwerking en feature-engineering uit te voeren, en het model te trainen en te implementeren op een asynchrone inferentie-eindpunt van SageMaker.

Streaming gegevensbron en opname

Kinesis Data Streams is een serverloze, schaalbare en duurzame realtime datastreamingservice die u kunt gebruiken om grote stromen gegevensrecords in realtime te verzamelen en te verwerken. Kinesis Data Streams maakt het vastleggen, verwerken en opslaan van datastromen uit verschillende bronnen mogelijk, zoals loggegevens van IT-infrastructuur, applicatielogs, sociale media, marktgegevensfeeds, webclickstream-gegevens, IoT-apparaten en sensoren, en meer. U kunt een Kinesis-gegevensstroom inrichten in de on-demand-modus of de ingerichte modus, afhankelijk van de doorvoer- en schaalvereisten. Voor meer informatie, zie De datastroomcapaciteitsmodus kiezen.

Voor ons gebruik gaan we ervan uit dat verschillende sensoren metingen zoals temperatuur, rotatiesnelheid, koppel en gereedschapsslijtage naar een datastroom sturen. Kinesis Data Streams fungeert als een trechter voor het verzamelen en opnemen van datastromen.

We maken gebruik van de Amazon Kinesis-gegevensgenerator (KDG) verderop in dit bericht om gegevens te genereren en te verzenden naar een Kinesis-gegevensstroom, waarbij gegevens worden gesimuleerd die door sensoren worden gegenereerd. De gegevens van de datastroom sensor-data-stream worden opgenomen en verwerkt met behulp van een AWS Glue streaming-taak, die we hierna bespreken.

Near-realtime feature-engineering

AWS Glue-streamingtaken bieden een handige manier om streaminggegevens op schaal te verwerken, zonder dat u de rekenomgeving hoeft te beheren. Met AWS Glue kunt u extractie-, transformatie- en laadbewerkingen (ETL) uitvoeren op streaminggegevens met behulp van continu lopende taken. AWS Glue streaming ETL is gebouwd op de Apache Spark Structured Streaming engine en kan streams opnemen van Kinesis, Apache Kafka en Amazon Managed Streaming voor Apache Kafka (Amazone MSK).

De streaming ETL-taak kan zowel ingebouwde AWS Glue-transformaties gebruiken als transformaties die eigen zijn aan Apache Spark Structured Streaming. U kunt ook de Spark ML gebruiken en MLLib bibliotheken in AWS Glue-taken voor eenvoudigere functieverwerking met behulp van direct beschikbare helperbibliotheken.

Als het schema van de streaminggegevensbron vooraf is bepaald, kunt u dit specificeren in een AWS Data Catalog-tabel. Als de schemadefinitie niet vooraf kan worden bepaald, kunt u schemadetectie inschakelen in de streaming-ETL-taak. De job bepaalt dan automatisch het schema uit de binnenkomende data. Daarnaast kunt u de AWS Lijm Schema Register om centrale detectie, controle en evolutie van datastroomschema's mogelijk te maken. U kunt het Schema-register verder integreren met de gegevenscatalogus om optioneel schema's te gebruiken die zijn opgeslagen in het schemaregister bij het maken of bijwerken van AWS Glue-tabellen of -partities in de gegevenscatalogus.

Voor dit bericht maken we een AWS Glue Data Catalog-tabel (sensor-stream) met onze Kinesis-gegevensstroom als bron en definieer het schema voor onze sensorgegevens.

We maken een dynamisch AWS Glue-dataframe uit de Data Catalog-tabel om de streaminggegevens van Kinesis te lezen. We specificeren ook de volgende opties:

• Een venstergrootte van 60 seconden, zodat de AWS Glue-taak gegevens leest en verwerkt in vensters van 60 seconden
• De startpositie TRIM_HORIZON, om het lezen van de oudste records in de Kinesis-gegevensstroom mogelijk te maken

We gebruiken ook Spark MLlib's StringIndexer feature transformer om het stringkolomtype te coderen in labelindexen. Deze transformatie wordt geïmplementeerd met Spark ML Pipelines. Spark ML-pijpleidingen bieden een uniforme set API's op hoog niveau voor ML-algoritmen om het gemakkelijker te maken om meerdere algoritmen te combineren in een enkele pijplijn of workflow.

We gebruiken de foreachBatch-API om een ​​functie met de naam processBatch aan te roepen, die op zijn beurt de gegevens verwerkt waarnaar door dit dataframe wordt verwezen. Zie de volgende code:

# 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})

De functie processBatch voert de gespecificeerde transformaties uit en verdeelt de gegevens in Amazon S3 op basis van jaar, maand, dag en batch-ID.

We hebben de AWS Glue-partities ook opnieuw gepartitioneerd in een enkele partitie, om te voorkomen dat er te veel kleine bestanden in Amazon S3 staan. Het hebben van meerdere kleine bestanden kan de leesprestaties belemmeren, omdat het de overhead vergroot die verband houdt met het zoeken, openen en lezen van elk bestand. We schrijven tenslotte de features om gevolgtrekkingen te genereren in een prefix (features) binnen de S3-bucket. Zie de volgende code:

# 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()))

Model training en implementatie

SageMaker is een volledig beheerde en geïntegreerde ML-service waarmee datawetenschappers en ML-engineers snel en eenvoudig ML-modellen kunnen bouwen, trainen en implementeren.

Binnen de Data_Pre-Processing.ipynb-notebook, we importeren eerst de AI4I Predictive Maintenance-dataset uit de UCI Data Repository en voeren verkennende data-analyse (EDA) uit. We voeren ook feature-engineering uit om onze functies nuttiger te maken voor het trainen van het model.

Binnen de dataset hebben we bijvoorbeeld een functie met de naam type, die het kwaliteitstype van het product vertegenwoordigt als L (laag), M (gemiddeld) of H (hoog). Omdat dit een categorische functie is, moeten we deze coderen voordat we ons model trainen. We gebruiken Scikit-Learn's LabelEncoder om dit te bereiken:

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

Nadat de functies zijn verwerkt en de samengestelde trein- en testgegevenssets zijn gegenereerd, zijn we klaar om een ​​ML-model te trainen om op basis van systeemmetingen te voorspellen of de machine is mislukt of niet. We trainen een XGBoost-model met behulp van het ingebouwde algoritme van SageMaker. XGBoost kan goede resultaten opleveren voor meerdere soorten ML-problemen, inclusief classificatie, zelfs wanneer de trainingsvoorbeelden beperkt zijn.

SageMaker-trainingsbanen bieden een krachtige en flexibele manier om ML-modellen op SageMaker te trainen. SageMaker beheert de onderliggende rekeninfrastructuur en biedt meerdere opties om uit te kiezen, voor diverse modeltrainingsvereisten, op basis van de use case.

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})

Wanneer de modeltraining is voltooid en de modelevaluatie bevredigend is op basis van de zakelijke vereisten, kunnen we beginnen met de implementatie van het model. We maken eerst een eindpuntconfiguratie met de objectoptie AsyncInferenceConfig en gebruiken het eerder getrainde model:

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},
},)

Vervolgens maken we een asynchrone inferentie-eindpunt van SageMaker, met behulp van de eindpuntconfiguratie die we hebben gemaakt. Nadat het is ingericht, kunnen we beginnen met het aanroepen van het eindpunt om asynchroon gevolgtrekkingen te genereren.

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

Bijna realtime gevolgtrekking

SageMaker asynchrone gevolgtrekking endpoints bieden de mogelijkheid om inkomende inferentieverzoeken in de wachtrij te plaatsen en deze asynchroon in bijna realtime te verwerken. Dit is ideaal voor toepassingen die inferentieverzoeken hebben met grotere payloads (tot 1 GB), mogelijk langere verwerkingstijden (tot 15 minuten) en bijna-realtime latentievereisten hebben. Met asynchrone inferentie kunt u ook kosten besparen door het aantal instanties automatisch op nul te zetten wanneer er geen aanvragen zijn om te verwerken, zodat u alleen betaalt wanneer uw eindpunt aanvragen verwerkt.

U kunt een asynchrone inferentie-eindpunt van SageMaker maken, vergelijkbaar met hoe u een realtime inferentie-eindpunt maakt en bovendien de AsyncInferenceConfig object, terwijl u uw eindpuntconfiguratie maakt met het veld EndpointConfig in de CreateEndpointConfig-API. Het volgende diagram toont de inferentie-workflow en hoe een asynchrone inferentie-eindpunt een inferentie genereert.

Om het asynchrone inferentie-eindpunt aan te roepen, moet de payload van het verzoek worden opgeslagen in Amazon S3 en moet een verwijzing naar deze payload worden verstrekt als onderdeel van het InvokeEndpointAsync-verzoek. Na het aanroepen plaatst SageMaker het verzoek voor verwerking in de wachtrij en retourneert het een identificatie en uitvoerlocatie als antwoord. Na verwerking plaatst SageMaker het resultaat op de Amazon S3-locatie. U kunt er optioneel voor kiezen om succes- of foutmeldingen te ontvangen met Amazon eenvoudige meldingsservice (Amazone SNS).

Test de end-to-end oplossing

Voer de volgende stappen uit om de oplossing te testen:

• Open op de AWS CloudFormation-console de stapel die u eerder hebt gemaakt (nrt-streaming-inference).
• Op de Uitgangen tabblad, kopieer de naam van de S3-bucket (EventsBucket).

Dit is de S3-bucket waarnaar onze AWS Glue-streamingtaak functies schrijft na het lezen en verwerken van de Kinesis-gegevensstroom.

Vervolgens stellen we gebeurtenismeldingen in voor deze S3-bucket.

• Navigeer op de Amazon S3-console naar de bucket EventsBucket.
• Op de Properties tab, in de Gebeurtenismeldingen sectie, kies Gebeurtenismelding maken.

• Voor Evenement naam, ga naar binnen invoke-endpoint-lambda.
• Voor Voorvoegsel, ga naar binnen features/.
• Voor Toevoeging, ga naar binnen .csv.
• Voor Soorten evenementenselecteer Alle gebeurtenissen voor het maken van objecten.

• Voor Bestemmingselecteer Lambda-functie.
• Voor Lambda-functieen kies de functie invoke-endpoint-asynch.
• Kies Wijzigingen opslaan.

• Open de taak op de AWS Glue-console GlueStreaming-Kinesis-S3.
• Kies Voer de taak uit.

Vervolgens gebruiken we de Kinesis Data Generator (KDG) om sensoren te simuleren die gegevens naar onze Kinesis-gegevensstroom sturen. Als dit de eerste keer is dat u de KDG gebruikt, raadpleeg dan: Overzicht voor de eerste opstelling. De KDG biedt een CloudFormation-sjabloon om de gebruiker aan te maken en net genoeg machtigingen toe te wijzen om de KDG te gebruiken voor het verzenden van gebeurtenissen naar Kinesis. Voer de ... uit CloudFormation-sjabloon binnen het AWS-account dat u gebruikt om de oplossing in dit bericht te bouwen. Nadat de KDG is ingesteld, logt u in en opent u de KDG om testgebeurtenissen naar onze Kinesis-gegevensstroom te sturen.

• Gebruik de regio waarin u de Kinesis-gegevensstroom hebt gemaakt (us-east-1).
• Kies in het vervolgkeuzemenu de gegevensstroom sensor-data-stream.
• In het Records per seconde sectie, selecteer constante en vul 100 in.
• unselect Records comprimeren.
• Voor Opnamesjabloon, gebruik de volgende sjabloon:

{
"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"])}}"
}

• Klik Verstuur data om te beginnen met het verzenden van gegevens naar de Kinesis-gegevensstroom.

De AWS Glue-streamingtaak leest en extraheert een microbatch gegevens (die sensormetingen vertegenwoordigen) uit de Kinesis-gegevensstroom op basis van de verstrekte venstergrootte. De streamingtaak verwerkt en voert vervolgens feature-engineering uit op deze microbatch voordat deze wordt gepartitioneerd en naar de prefix-functies in de S3-bucket wordt geschreven.

Omdat nieuwe functies die zijn gemaakt door de AWS Glue-streamingtaak naar de S3-bucket worden geschreven, wordt een Lambda-functie (invoke-endpoint-asynch) wordt geactiveerd, dat een asynchrone inferentie-eindpunt van SageMaker aanroept door een aanroepverzoek te verzenden om gevolgtrekkingen te krijgen van ons geïmplementeerde ML-model. Het asynchrone inferentie-eindpunt zet de aanvraag voor asynchrone aanroep in de wachtrij. Wanneer de verwerking is voltooid, slaat SageMaker de inferentieresultaten op in de Amazon S3-locatie (S3OutputPath) die is opgegeven tijdens de configuratie van het asynchrone inferentie-eindpunt.

Voor onze use-case geven de gevolgtrekkingsresultaten aan of een machineonderdeel waarschijnlijk zal falen of niet, op basis van de sensormetingen.

SageMaker stuurt ook een succes- of foutmelding met Amazon SNS. Als u bijvoorbeeld een email abonnement voor de succes- en fout-SNS-onderwerpen (gespecificeerd in de asynchrone SageMaker-inferentie-eindpuntconfiguratie), kan een e-mail worden verzonden telkens wanneer een inferentieverzoek wordt verwerkt. De volgende schermafbeelding toont een voorbeeld van een e-mail uit het SNS-succesonderwerp.

Voor toepassingen in de echte wereld kunt u SNS-meldingen integreren met andere services, zoals: Amazon Simple Queue-service (Amazon SQS) en Lambda voor aanvullende nabewerking van de gegenereerde inferenties of integratie met andere downstream-applicaties, op basis van uw vereisten. Voor ons gebruiksscenario voor voorspellend onderhoud kunt u bijvoorbeeld een Lambda-functie aanroepen op basis van een SNS-melding om de gegenereerde inferentie van Amazon S3 te lezen, deze verder te verwerken (zoals aggregatie of filtering) en workflows te starten, zoals het verzenden van werkorders voor reparatie van apparatuur aan technici.

Opruimen

Wanneer u klaar bent met het testen van de stapel, verwijdert u de bronnen (met name de Kinesis-gegevensstroom, Glue-streamingtaak en SNS-onderwerpen) om onverwachte kosten te voorkomen.

Voer de volgende code uit om uw stapel te verwijderen:

sam delete nrt-streaming-inference

Verwijder ook de bronnen zoals SageMaker-eindpunten door de sectie opschonen in het notitieblok ModelTraining-Evaluation-and-Deployment te volgen.

Conclusie

In dit bericht hebben we een gebruiksscenario voor voorspellend onderhoud gebruikt om te demonstreren hoe verschillende services zoals Kinesis, AWS Glue en SageMaker kunnen worden gebruikt om een ​​bijna realtime inferentiepijplijn te bouwen. We raden u aan deze oplossing te proberen en ons te laten weten wat u ervan vindt.

Als je vragen hebt, deel ze dan in de comments.

Over de auteurs

Rahul Sharma is Solutions Architect bij AWS Data Lab en helpt AWS-klanten bij het ontwerpen en bouwen van AI/ML-oplossingen. Voordat hij bij AWS kwam, heeft Rahul een aantal jaren in de financiële en verzekeringssector gewerkt en klanten geholpen bij het bouwen van data- en analytische platforms.

Pat Reilly is architect in het AWS Data Lab, waar hij klanten helpt bij het ontwerpen en bouwen van dataworkloads om hun bedrijf te ondersteunen. Voordat hij bij AWS kwam, overlegde Pat bij een AWS-partner en bouwde hij AWS-gegevensworkloads in verschillende sectoren.