Crea una soluzione di manutenzione predittiva con Amazon Kinesis, AWS Glue e Amazon SageMaker

Le organizzazioni creano e utilizzano sempre più soluzioni basate sull'apprendimento automatico (ML) per una varietà di casi d'uso e problemi, tra cui la manutenzione predittiva delle parti della macchina, i consigli sui prodotti basati sulle preferenze dei clienti, la profilazione del credito, la moderazione dei contenuti, il rilevamento delle frodi e altro ancora. In molti di questi scenari, l'efficacia ei vantaggi derivati ​​da queste soluzioni basate su ML possono essere ulteriormente migliorati quando possono elaborare e ricavare informazioni da eventi di dati quasi in tempo reale.

Sebbene il valore aziendale ei vantaggi delle soluzioni basate su ML quasi in tempo reale siano ben consolidati, l'architettura richiesta per implementare queste soluzioni su larga scala con affidabilità e prestazioni ottimali è complicata. Questo post descrive come puoi combinare Cinesi amazzonica, Colla AWSe Amazon Sage Maker per creare una soluzione di ingegneria delle funzionalità e inferenza quasi in tempo reale per la manutenzione predittiva.

Panoramica dei casi d'uso

Ci concentriamo su un caso d'uso della manutenzione predittiva in cui i sensori implementati sul campo (come apparecchiature industriali o dispositivi di rete) devono essere sostituiti o rettificati prima che diventino difettosi e causino tempi di fermo. I tempi di inattività possono essere costosi per le aziende e possono portare a una scarsa esperienza del cliente. La manutenzione predittiva basata su un modello ML può anche aiutare ad aumentare i regolari cicli di manutenzione programmati, informando quando una parte della macchina in buone condizioni non deve essere sostituita, evitando così costi inutili.

In questo post, ci concentriamo sull'applicazione dell'apprendimento automatico a un set di dati sintetico contenente guasti della macchina dovuti a caratteristiche come temperatura dell'aria, temperatura di processo, velocità di rotazione, coppia e usura degli utensili. Il set di dati utilizzato proviene da Archivio dati UCI.

Il guasto della macchina consiste in cinque modalità di guasto indipendenti:

• Guasto usura utensile (TWF)
• Guasto della dissipazione del calore (HDF)
• Interruzione di alimentazione (PWF)
• Fallimento da sovraccarico (OSF)
• Fallimento casuale (RNF)

L'etichetta di errore della macchina indica se la macchina si è guastata per un determinato punto dati se una delle modalità di errore precedenti è vera. Se almeno una delle modalità di errore è vera, il processo ha esito negativo e l'etichetta di errore della macchina è impostata su 1. L'obiettivo del modello ML è identificare correttamente i guasti della macchina, in modo da poter avviare un'azione di manutenzione predittiva a valle.

Panoramica della soluzione

Per il nostro caso d'uso della manutenzione predittiva, assumiamo che i sensori del dispositivo trasmettano varie misurazioni e letture sulle parti della macchina. La nostra soluzione prende quindi una porzione di dati in streaming ogni volta (micro-batch) ed esegue l'elaborazione e l'ingegneria delle funzionalità per creare funzionalità. Le funzionalità create vengono quindi utilizzate per generare inferenze da un modello ML addestrato e distribuito in tempo quasi reale. Le inferenze generate possono essere ulteriormente elaborate e consumate dalle applicazioni a valle, per intraprendere le azioni appropriate e avviare attività di manutenzione.

Il diagramma seguente mostra l'architettura della nostra soluzione complessiva.

La soluzione consiste sostanzialmente nelle seguenti sezioni, che sono spiegate in dettaglio più avanti in questo post:

• Streaming di origine dati e importazione - Noi usiamo Flussi di dati di Amazon Kinesis per raccogliere dati in streaming dai sensori di campo su larga scala e renderli disponibili per ulteriori elaborazioni.
• Progettazione di funzionalità quasi in tempo reale – Utilizziamo i lavori di streaming di AWS Glue per leggere i dati da un flusso di dati Kinesis ed eseguire l'elaborazione dei dati e la progettazione delle funzionalità, prima di archiviare le funzionalità derivate in Servizio di archiviazione semplice Amazon (Amazon S3). Amazon S3 offre un'opzione affidabile ed economica per archiviare grandi volumi di dati.
• Formazione e distribuzione del modello – Utilizziamo il set di dati di manutenzione predittiva AI4I dell'UCI Data Repository per addestrare un modello ML basato sull'algoritmo XGBoost utilizzando SageMaker. Distribuiamo quindi il modello addestrato a un endpoint di inferenza asincrona SageMaker.
• Inferenza ML quasi in tempo reale – Dopo che le funzionalità sono disponibili in Amazon S3, è necessario generare inferenze dal modello distribuito quasi in tempo reale. Gli endpoint di inferenza asincrona di SageMaker sono adatti a questo requisito perché supportano dimensioni di payload maggiori (fino a 1 GB) e possono generare inferenze in pochi minuti (fino a un massimo di 15 minuti). Usiamo le notifiche degli eventi S3 per eseguire un AWS Lambda funzione per richiamare un endpoint di inferenza asincrona SageMaker. Gli endpoint di inferenza asincrona di SageMaker accettano posizioni S3 come input, generano inferenze dal modello distribuito e scrivono queste inferenze su Amazon S3 quasi in tempo reale.

Il codice sorgente per questa soluzione si trova su GitHub. La soluzione è stata testata e dovrebbe essere eseguita in us-east-1.

Usiamo un file AWS CloudFormazione modello, distribuito utilizzando Modello di applicazione serverless AWS (AWS SAM) e notebook SageMaker per implementare la soluzione.

Prerequisiti

Per iniziare, come prerequisito, devi avere il CLI SAM, Python 3e PIP installato. Devi avere anche il Interfaccia della riga di comando di AWS (AWS CLI) configurato correttamente.

Distribuisci la soluzione

Puoi usare AWS CloudShell per eseguire questi passaggi. CloudShell è una shell basata su browser preautenticata con le credenziali della tua console e include strumenti operativi e di sviluppo comuni preinstallati (come AWS SAM, AWS CLI e Python). Pertanto, non è richiesta alcuna installazione o configurazione locale.

• Iniziamo creando un bucket S3 in cui archiviamo lo script per il nostro processo di streaming AWS Glue. Esegui il seguente comando nel tuo terminale per creare un nuovo bucket:

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

• Prendere nota del nome del bucket creato.

• Successivamente, cloniamo localmente il repository di codice, che contiene il modello CloudFormation per distribuire lo stack. Esegui il seguente comando nel tuo terminale:

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

• Vai alla directory sam-template:

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

• Esegui il comando seguente per copiare lo script del lavoro AWS Glue (da glue_streaming/app.py) nel bucket S3 che hai creato:

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

• Ora puoi procedere con la creazione e la distribuzione della soluzione, tramite il modello CloudFormation tramite AWS SAM. Esegui il seguente comando:

sam deploy --guided

• Fornisci argomenti per la distribuzione come il nome dello stack, la regione AWS preferita (us-east-1), E GlueScriptsBucket.

Assicurati di fornire lo stesso bucket S3 che hai creato in precedenza per il bucket S3 dello script AWS Glue (parametro GlueScriptsBucket nella schermata seguente).

Dopo aver fornito gli argomenti richiesti, AWS SAM avvia la distribuzione dello stack. La schermata seguente mostra le risorse create.

Dopo che lo stack è stato distribuito correttamente, dovresti visualizzare il messaggio seguente.

• Nella console AWS CloudFormation, apri lo stack (per questo post, nrt-streaming-inference) fornito durante la distribuzione del modello CloudFormation.
• Sulla Risorse scheda, prendere nota dell'ID istanza del notebook SageMaker.

• Sulla console SageMaker, apri questa istanza.

L'istanza del notebook SageMaker ha già i notebook richiesti precaricati.

Passare alla cartella dei taccuini e aprire e seguire le istruzioni all'interno dei taccuini (Data_Pre-Processing.ipynb ed ModelTraining-Evaluation-and-Deployment.ipynb) per esplorare il set di dati, eseguire la preelaborazione e la progettazione delle funzionalità, nonché addestrare e distribuire il modello a un endpoint di inferenza asincrona SageMaker.

Streaming di origine dati e importazione

Kinesis Data Streams è un servizio di streaming di dati in tempo reale senza server, scalabile e durevole che puoi utilizzare per raccogliere ed elaborare grandi flussi di record di dati in tempo reale. Kinesis Data Streams consente di acquisire, elaborare e archiviare flussi di dati da una varietà di fonti, come dati di registro dell'infrastruttura IT, registri delle applicazioni, social media, feed di dati di mercato, dati del flusso di clic Web, dispositivi e sensori IoT e altro ancora. È possibile eseguire il provisioning di un flusso di dati Kinesis in modalità su richiesta o in modalità con provisioning a seconda dei requisiti di throughput e scalabilità. Per ulteriori informazioni, vedere Scelta della modalità di capacità del flusso di dati.

Per il nostro caso d'uso, assumiamo che vari sensori inviino misurazioni come temperatura, velocità di rotazione, coppia e usura dell'utensile a un flusso di dati. Kinesis Data Streams funge da imbuto per raccogliere e acquisire flussi di dati.

Usiamo il Generatore di dati Amazon Kinesis (KDG) più avanti in questo post per generare e inviare dati a un flusso di dati Kinesis, simulando i dati generati dai sensori. I dati del flusso di dati sensor-data-stream vengono acquisiti ed elaborati utilizzando un processo di streaming AWS Glue, di cui parleremo in seguito.

Progettazione di funzionalità quasi in tempo reale

Lavori di streaming di AWS Glue forniscono un modo conveniente per elaborare i dati in streaming su larga scala, senza la necessità di gestire l'ambiente di elaborazione. AWS Glue ti consente di eseguire operazioni di estrazione, trasformazione e caricamento (ETL) sui dati in streaming utilizzando lavori in esecuzione continua. L'ETL di streaming di AWS Glue è basato sul motore di streaming strutturato Apache Spark e può importare flussi da Kinesis, Apache Kafka e Streaming gestito da Amazon per Apache Kafka (AmazonMSK).

Il processo ETL di streaming può utilizzare sia le trasformazioni integrate di AWS Glue che le trasformazioni native di Apache Spark Structured Streaming. Puoi anche usare Spark ML e MLLib librerie nei lavori AWS Glue per un'elaborazione più semplice delle funzionalità utilizzando librerie helper prontamente disponibili.

Se lo schema dell'origine dati in streaming è predeterminato, puoi specificarlo in una tabella di AWS Data Catalog. Se non è possibile determinare in anticipo la definizione dello schema, è possibile abilitare il rilevamento dello schema nel processo ETL di streaming. Il lavoro determina quindi automaticamente lo schema dai dati in entrata. Inoltre, puoi utilizzare il Registro dello schema di AWS Glue per consentire il rilevamento, il controllo e l'evoluzione centralizzati degli schemi del flusso di dati. Puoi integrare ulteriormente Schema Registry con Data Catalog per utilizzare facoltativamente schemi archiviati in Schema Registry durante la creazione o l'aggiornamento di tabelle o partizioni AWS Glue nel Data Catalog.

Per questo post, creiamo una tabella Catalogo dati AWS Glue (sensor-stream) con il nostro flusso di dati Kinesis come origine e definire lo schema per i dati dei nostri sensori.

Creiamo un frame di dati dinamico AWS Glue dalla tabella Data Catalog per leggere i dati in streaming da Kinesis. Specifichiamo anche le seguenti opzioni:

• Una finestra di 60 secondi, in modo che il lavoro AWS Glue legga ed elabori i dati in finestre di 60 secondi
• La posizione di partenza TRIM_HORIZON, per consentire la lettura dei record più vecchi nel flusso di dati Kinesis

Usiamo anche Spark MLlib Indicizzatore di stringhe trasformatore di funzionalità per codificare il tipo di colonna di stringa in indici di etichetta. Questa trasformazione viene implementata utilizzando Spark ML Pipelines. Condutture Spark ML fornire un set uniforme di API di alto livello per gli algoritmi ML per semplificare la combinazione di più algoritmi in un'unica pipeline o flusso di lavoro.

Usiamo l'API foreachBatch per invocare una funzione denominata processBatch, che a sua volta elabora i dati a cui fa riferimento questo dataframe. Vedere il codice seguente:

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

La funzione processBatch esegue le trasformazioni specificate e partiziona i dati in Amazon S3 in base a anno, mese, giorno e ID batch.

Inoltre, ripartizioniamo le partizioni AWS Glue in un'unica partizione, per evitare di avere troppi file di piccole dimensioni in Amazon S3. La presenza di diversi file di piccole dimensioni può ostacolare le prestazioni di lettura, poiché amplifica il sovraccarico relativo alla ricerca, all'apertura e alla lettura di ciascun file. Infine, scriviamo le funzionalità per generare inferenze in un prefisso (caratteristiche) all'interno del bucket S3. Vedere il codice seguente:

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

Formazione e implementazione del modello

SageMaker è un servizio ML completamente gestito e integrato che consente ai data scientist e agli ingegneri ML di creare, addestrare e distribuire modelli ML in modo rapido e semplice.

All'interno del notebook Data_Pre-Processing.ipynb, prima importiamo il set di dati AI4I Predictive Maintenance dall'UCI Data Repository ed eseguiamo l'analisi dei dati esplorativi (EDA). Eseguiamo anche l'ingegneria delle funzionalità per rendere le nostre funzionalità più utili per l'addestramento del modello.

Ad esempio, all'interno del set di dati, abbiamo una funzionalità denominata tipo, che rappresenta il tipo di qualità del prodotto come L (bassa), M (media) o H (alta). Poiché questa è una caratteristica categoriale, dobbiamo codificarla prima di addestrare il nostro modello. Usiamo LabelEncoder di Scikit-Learn per ottenere questo:

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

Dopo che le funzionalità sono state elaborate e i set di dati di test e treno curati sono stati generati, siamo pronti per addestrare un modello ML per prevedere se la macchina si è guastata o meno in base alle letture del sistema. Formiamo un modello XGBoost, utilizzando l'algoritmo integrato di SageMaker. XGBoost può fornire buoni risultati per più tipi di problemi di ML, inclusa la classificazione, anche quando i campioni di addestramento sono limitati.

Lavori di formazione SageMaker fornire un modo potente e flessibile per addestrare modelli ML su SageMaker. SageMaker gestisce l'infrastruttura di calcolo sottostante e fornisce più opzioni tra cui scegliere, per diversi requisiti di formazione del modello, in base al caso d'uso.

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

Quando la formazione del modello è completa e la valutazione del modello è soddisfacente in base ai requisiti aziendali, possiamo iniziare la distribuzione del modello. Per prima cosa creiamo una configurazione dell'endpoint con l'opzione dell'oggetto AsyncInferenceConfig e utilizzando il modello addestrato in precedenza:

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

Quindi creiamo un endpoint di inferenza asincrona SageMaker, utilizzando la configurazione dell'endpoint che abbiamo creato. Dopo il provisioning, possiamo iniziare a invocare l'endpoint per generare inferenze in modo asincrono.

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

Inferenza quasi in tempo reale

SageMaker inferenza asincrona gli endpoint offrono la possibilità di accodare le richieste di inferenza in entrata ed elaborarle in modo asincrono quasi in tempo reale. Questo è l'ideale per le applicazioni che hanno richieste di inferenza con dimensioni del payload maggiori (fino a 1 GB), possono richiedere tempi di elaborazione più lunghi (fino a 15 minuti) e hanno requisiti di latenza quasi in tempo reale. L'inferenza asincrona ti consente inoltre di risparmiare sui costi ridimensionando automaticamente il conteggio delle istanze a zero quando non ci sono richieste da elaborare, quindi paghi solo quando l'endpoint sta elaborando le richieste.

Puoi creare un endpoint di inferenza asincrona SageMaker simile a come crei un endpoint di inferenza in tempo reale e specificare inoltre il AsyncInferenceConfig oggetto, durante la creazione della configurazione dell'endpoint con il campo EndpointConfig nell'API CreateEndpointConfig. Il diagramma seguente mostra il flusso di lavoro di inferenza e il modo in cui un endpoint di inferenza asincrona genera un'inferenza.

Per richiamare l'endpoint di inferenza asincrona, il payload della richiesta deve essere archiviato in Amazon S3 e il riferimento a questo payload deve essere fornito come parte della richiesta InvokeEndpointAsync. Al momento della chiamata, SageMaker mette in coda la richiesta per l'elaborazione e restituisce un identificatore e una posizione di output come risposta. Al momento dell'elaborazione, SageMaker inserisce il risultato nella posizione di Amazon S3. Puoi opzionalmente scegliere di ricevere notifiche di successo o errore con Servizio di notifica semplice Amazon (SNS Amazon).

Testare la soluzione end-to-end

Per testare la soluzione, completare i seguenti passaggi:

• Nella console AWS CloudFormation, apri lo stack che hai creato in precedenza (nrt-streaming-inference).
• Sulla Uscite scheda, copia il nome del bucket S3 (EventsBucket).

Questo è il bucket S3 in cui il nostro processo di streaming AWS Glue scrive le funzionalità dopo la lettura e l'elaborazione dal flusso di dati Kinesis.

Successivamente, impostiamo le notifiche degli eventi per questo bucket S3.

• Sulla console Amazon S3, vai al bucket EventsBucket.
• Sulla Properties scheda, nel Notifiche di eventi sezione, scegliere Crea notifica evento.

• Nel Nome dell'evento, accedere invoke-endpoint-lambda.
• Nel Prefisso, accedere features/.
• Nel Suffisso, accedere .csv.
• Nel Tipi di eventi, selezionare Tutti gli oggetti creano eventi.

• Nel Nei Dintorni, selezionare Funzione Lambda.
• Nel Funzione Lambdae scegli la funzione invoke-endpoint-asynch.
• Scegli Salvare le modifiche.

• Nella console AWS Glue, apri il lavoro GlueStreaming-Kinesis-S3.
• Scegli Esegui lavoro.

Successivamente utilizziamo il Kinesis Data Generator (KDG) per simulare i sensori che inviano dati al nostro flusso di dati Kinesis. Se è la prima volta che usi il KDG, fai riferimento a Panoramica per la configurazione iniziale. Il KDG fornisce un modello CloudFormation per creare l'utente e assegnare autorizzazioni sufficienti per utilizzare il KDG per l'invio di eventi a Kinesis. Corri il Modello CloudFormation all'interno dell'account AWS che stai utilizzando per creare la soluzione in questo post. Dopo aver impostato il KDG, accedi e accedi al KDG per inviare eventi di test al nostro flusso di dati Kinesis.

• Usa la regione in cui hai creato il flusso di dati Kinesis (us-east-1).
• Nel menu a discesa, scegli il flusso di dati sensor-data-stream.
• Nel Record al secondo sezione, selezionare costante e inserisci 100.
• Deseleziona Comprimi record.
• Nel Modello di registrazione, utilizzare il seguente modello:

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

• Clicchi Invia dati per iniziare a inviare dati al flusso di dati Kinesis.

Il processo di streaming di AWS Glue legge ed estrae un micro-batch di dati (che rappresentano le letture dei sensori) dal flusso di dati Kinesis in base alle dimensioni della finestra fornite. Il processo di streaming quindi elabora ed esegue la progettazione delle funzionalità su questo micro-batch prima di partizionarlo e scriverlo nelle funzionalità del prefisso all'interno del bucket S3.

Quando le nuove funzionalità create dal processo di streaming di AWS Glue vengono scritte nel bucket S3, una funzione Lambda (invoke-endpoint-asynch) viene attivato, che richiama un endpoint di inferenza asincrona SageMaker inviando una richiesta di chiamata per ottenere inferenze dal nostro modello ML distribuito. L'endpoint di inferenza asincrona accoda la richiesta di chiamata asincrona. Al termine dell'elaborazione, SageMaker archivia i risultati dell'inferenza nella posizione Amazon S3 (S3OutputPath) specificato durante la configurazione dell'endpoint di inferenza asincrona.

Per il nostro caso d'uso, i risultati dell'inferenza indicano se è probabile che una parte della macchina si guasti o meno, in base alle letture del sensore.

SageMaker invia anche una notifica di successo o errore con Amazon SNS. Ad esempio, se hai impostato un abbonamento e-mail per gli argomenti SNS di successo ed errore (specificati all'interno della configurazione dell'endpoint di inferenza asincrona di SageMaker), è possibile inviare un'e-mail ogni volta che viene elaborata una richiesta di inferenza. La schermata seguente mostra un messaggio di posta elettronica di esempio dall'argomento di successo SNS.

Per le applicazioni del mondo reale, puoi integrare le notifiche SNS con altri servizi come Servizio Amazon Simple Queue (Amazon SQS) e Lambda per la postelaborazione aggiuntiva delle inferenze generate o l'integrazione con altre applicazioni a valle, in base ai tuoi requisiti. Ad esempio, per il nostro caso d'uso della manutenzione predittiva, puoi invocare una funzione Lambda basata su una notifica SNS per leggere l'inferenza generata da Amazon S3, elaborarla ulteriormente (come aggregazione o filtraggio) e avviare flussi di lavoro come l'invio di ordini di lavoro per riparazione attrezzature ai tecnici.

ripulire

Al termine del test dello stack, elimina le risorse (in particolare il flusso di dati Kinesis, il processo di Glue streaming e gli argomenti SNS) per evitare addebiti imprevisti.

Esegui il codice seguente per eliminare lo stack:

sam delete nrt-streaming-inference

Elimina anche le risorse come gli endpoint SageMaker seguendo la sezione di pulizia nel notebook ModelTraining-Evaluation-and-Deployment.

Conclusione

In questo post, abbiamo utilizzato un caso d'uso della manutenzione predittiva per dimostrare come utilizzare vari servizi come Kinesis, AWS Glue e SageMaker per creare una pipeline di inferenza quasi in tempo reale. Ti invitiamo a provare questa soluzione e facci sapere cosa ne pensi.

Se hai domande, condividile nei commenti.

Circa gli autori

Rahul Sharma è un Solutions Architect presso AWS Data Lab, che aiuta i clienti AWS a progettare e creare soluzioni AI/ML. Prima di entrare in AWS, Rahul ha trascorso diversi anni nel settore finanziario e assicurativo, aiutando i clienti a creare piattaforme di dati e analitiche.

Pat Reilly è un architetto in AWS Data Lab, dove aiuta i clienti a progettare e creare carichi di lavoro di dati per supportare la loro attività. Prima di AWS, Pat si è consultato presso un partner AWS, costruendo carichi di lavoro di dati AWS in una varietà di settori.