Créez une solution de maintenance prédictive avec Amazon Kinesis, AWS Glue et Amazon SageMaker

Les organisations construisent et utilisent de plus en plus des solutions basées sur l'apprentissage automatique (ML) pour une variété de cas d'utilisation et de problèmes, y compris la maintenance prédictive des pièces de machine, les recommandations de produits basées sur les préférences des clients, le profilage de crédit, la modération de contenu, la détection de fraude, etc. Dans bon nombre de ces scénarios, l'efficacité et les avantages tirés de ces solutions basées sur le ML peuvent être encore améliorés lorsqu'elles peuvent traiter et extraire des informations à partir d'événements de données en temps quasi réel.

Bien que la valeur commerciale et les avantages des solutions de ML en temps quasi réel soient bien établis, l'architecture requise pour mettre en œuvre ces solutions à grande échelle avec une fiabilité et des performances optimales est compliquée. Cet article décrit comment vous pouvez combiner Amazon Kinésis, Colle AWSet Amazon Sage Maker pour créer une solution d'ingénierie et d'inférence de fonctionnalités en temps quasi réel pour la maintenance prédictive.

Présentation des cas d'utilisation

Nous nous concentrons sur un cas d'utilisation de maintenance prédictive où les capteurs déployés sur le terrain (tels que les équipements industriels ou les périphériques réseau) doivent être remplacés ou rectifiés avant qu'ils ne deviennent défectueux et ne provoquent des temps d'arrêt. Les temps d'arrêt peuvent être coûteux pour les entreprises et peuvent entraîner une mauvaise expérience client. La maintenance prédictive alimentée par un modèle ML peut également aider à augmenter les cycles de maintenance réguliers basés sur un calendrier en informant quand une pièce de machine en bon état ne doit pas être remplacée, évitant ainsi des coûts inutiles.

Dans cet article, nous nous concentrons sur l'application de l'apprentissage automatique à un ensemble de données synthétiques contenant des pannes de machine dues à des caractéristiques telles que la température de l'air, la température du processus, la vitesse de rotation, le couple et l'usure de l'outil. Le jeu de données utilisé provient du Référentiel de données de l'UCI.

La défaillance de la machine se compose de cinq modes de défaillance indépendants :

• Défaillance d'usure d'outil (TWF)
• Échec de la dissipation thermique (HDF)
• Panne de courant (PWF)
• Échec de surcharge (OSF)
• Échec aléatoire (RNF)

L'étiquette de défaillance de la machine indique si la machine est en panne pour un point de données particulier si l'un des modes de défaillance précédents est vrai. Si au moins un des modes de défaillance est vrai, le processus échoue et l'étiquette de défaillance de la machine est définie sur 1. L'objectif du modèle ML est d'identifier correctement les défaillances de la machine, afin qu'une action de maintenance prédictive en aval puisse être lancée.

Vue d'ensemble de la solution

Pour notre cas d'utilisation de maintenance prédictive, nous supposons que les capteurs de l'appareil diffusent diverses mesures et lectures sur les pièces de la machine. Notre solution prend ensuite une tranche de données en continu à chaque fois (micro-lot) et effectue le traitement et l'ingénierie des fonctionnalités pour créer des fonctionnalités. Les fonctionnalités créées sont ensuite utilisées pour générer des inférences à partir d'un modèle ML formé et déployé en temps quasi réel. Les inférences générées peuvent être traitées ultérieurement et consommées par des applications en aval, pour prendre les mesures appropriées et lancer une activité de maintenance.

Le schéma suivant montre l'architecture de notre solution globale.

La solution se compose en gros des sections suivantes, qui sont expliquées en détail plus loin dans cet article :

• Source de données de streaming et ingestion - Nous utilisons Flux de données Amazon Kinesis pour collecter des données en continu à partir des capteurs de terrain à grande échelle et les rendre disponibles pour un traitement ultérieur.
• Ingénierie des fonctionnalités en temps quasi réel – Nous utilisons les tâches de streaming AWS Glue pour lire les données d'un flux de données Kinesis et effectuer le traitement des données et l'ingénierie des fonctionnalités, avant de stocker les fonctionnalités dérivées dans Service de stockage simple Amazon (Amazon S3). Amazon S3 offre une option fiable et économique pour stocker de gros volumes de données.
• Formation et déploiement de modèles – Nous utilisons l'ensemble de données de maintenance prédictive AI4I du référentiel de données UCI pour former un modèle ML basé sur l'algorithme XGBoost à l'aide de SageMaker. Nous déployons ensuite le modèle formé sur un point de terminaison d'inférence asynchrone SageMaker.
• Inférence ML en temps quasi réel – Une fois les fonctionnalités disponibles dans Amazon S3, nous devons générer des inférences à partir du modèle déployé en temps quasi réel. Les points de terminaison d'inférence asynchrone SageMaker sont bien adaptés à cette exigence car ils prennent en charge des tailles de charge utile plus importantes (jusqu'à 1 Go) et peuvent générer des inférences en quelques minutes (jusqu'à un maximum de 15 minutes). Nous utilisons les notifications d'événements S3 pour exécuter un AWS Lambda pour invoquer un point de terminaison d'inférence asynchrone SageMaker. Les points de terminaison d'inférence asynchrone SageMaker acceptent les emplacements S3 en entrée, génèrent des inférences à partir du modèle déployé et réécrivent ces inférences dans Amazon S3 en temps quasi réel.

Le code source de cette solution se trouve sur GitHub. La solution a été testée et devrait être exécutée dans us-east-1.

Nous utilisons un AWS CloudFormation modèle, déployé à l'aide Modèle d'application sans serveur AWS (AWS SAM) et des blocs-notes SageMaker pour déployer la solution.

Pré-requis

Pour commencer, comme prérequis, vous devez avoir le CLI SAM, Python 3et PIP installée. Vous devez également avoir le Interface de ligne de commande AWS (AWS CLI) configuré correctement.

Déployez la solution

Vous pouvez utiliser AWS Cloud Shell pour exécuter ces étapes. CloudShell est un shell basé sur un navigateur qui est pré-authentifié avec les informations d'identification de votre console et inclut des outils de développement et d'exploitation communs préinstallés (tels qu'AWS SAM, AWS CLI et Python). Par conséquent, aucune installation ou configuration locale n'est requise.

• Nous commençons par créer un compartiment S3 dans lequel nous stockons le script pour notre tâche de streaming AWS Glue. Exécutez la commande suivante dans votre terminal pour créer un bucket :

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

• Notez le nom du bucket créé.

• Ensuite, nous clonons le référentiel de code localement, qui contient le modèle CloudFormation pour déployer la pile. Exécutez la commande suivante dans votre terminal :

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

• Accédez au répertoire sam-template :

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

• Exécutez la commande suivante pour copier le script de tâche AWS Glue (depuis glue_streaming/app.py) vers le compartiment S3 que vous avez créé :

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

• Vous pouvez maintenant poursuivre la construction et le déploiement de la solution, via le modèle CloudFormation via AWS SAM. Exécutez la commande suivante :

sam deploy --guided

• Fournissez des arguments pour le déploiement tels que le nom de la pile, la région AWS préférée (us-east-1), Et GlueScriptsBucket.

Assurez-vous de fournir le même compartiment S3 que celui que vous avez créé précédemment pour le compartiment S3 de script AWS Glue (paramètre GlueScriptsBucket dans la capture d'écran suivante).

Une fois que vous avez fourni les arguments requis, AWS SAM démarre le déploiement de la pile. La capture d'écran suivante montre les ressources créées.

Une fois la pile déployée avec succès, vous devriez voir le message suivant.

• Sur la console AWS CloudFormation, ouvrez la pile (pour cet article, nrt-streaming-inference) fourni lors du déploiement du modèle CloudFormation.
• Sur le Ressources , notez l'ID d'instance de bloc-notes SageMaker.

• Sur la console SageMaker, ouvrez cette instance.

L'instance de bloc-notes SageMaker contient déjà les blocs-notes requis préchargés.

Accédez au dossier des blocs-notes et ouvrez et suivez les instructions dans les blocs-notes (Data_Pre-Processing.ipynb ainsi que ModelTraining-Evaluation-and-Deployment.ipynb) pour explorer l'ensemble de données, effectuer le prétraitement et l'ingénierie des fonctionnalités, et entraîner et déployer le modèle sur un point de terminaison d'inférence asynchrone SageMaker.

Source de données de streaming et ingestion

Kinesis Data Streams est un service de diffusion de données en temps réel sans serveur, évolutif et durable que vous pouvez utiliser pour collecter et traiter de grands flux d'enregistrements de données en temps réel. Kinesis Data Streams permet de capturer, de traiter et de stocker des flux de données provenant de diverses sources, telles que les données de journal d'infrastructure informatique, les journaux d'application, les médias sociaux, les flux de données de marché, les données de parcours de navigation Web, les appareils et capteurs IoT, etc. Vous pouvez provisionner un flux de données Kinesis en mode à la demande ou en mode provisionné en fonction des exigences de débit et de mise à l'échelle. Pour plus d'informations, voir Choix du mode de capacité du flux de données.

Pour notre cas d'utilisation, nous supposons que divers capteurs envoient des mesures telles que la température, la vitesse de rotation, le couple et l'usure de l'outil à un flux de données. Kinesis Data Streams agit comme un entonnoir pour collecter et ingérer des flux de données.

Nous utilisons les Générateur de données Amazon Kinesis (KDG) plus loin dans cet article pour générer et envoyer des données à un flux de données Kinesis, simulant les données générées par des capteurs. Les données du flux de données sensor-data-stream sont ingérées et traitées à l'aide d'une tâche de streaming AWS Glue, dont nous parlerons ensuite.

Ingénierie des fonctionnalités en temps quasi réel

Tâches de streaming AWS Glue offrent un moyen pratique de traiter les données en continu à grande échelle, sans avoir à gérer l'environnement de calcul. AWS Glue vous permet d'effectuer des opérations d'extraction, de transformation et de chargement (ETL) sur des données de streaming à l'aide de tâches exécutées en continu. L'ETL de streaming AWS Glue est basé sur le moteur de streaming structuré Apache Spark et peut ingérer des flux de Kinesis, Apache Kafka et Amazon Managed Streaming pour Apache Kafka (AmazonMSK).

La tâche ETL de streaming peut utiliser à la fois les transformations intégrées AWS Glue et les transformations natives d'Apache Spark Structured Streaming. Vous pouvez également utiliser Spark ML et MLLib bibliothèques dans les tâches AWS Glue pour faciliter le traitement des fonctionnalités à l'aide de bibliothèques d'assistance facilement disponibles.

Si le schéma de la source de données de streaming est prédéterminé, vous pouvez le spécifier dans une table AWS Data Catalog. Si la définition de schéma ne peut pas être déterminée au préalable, vous pouvez activer la détection de schéma dans la tâche ETL de streaming. Le travail détermine ensuite automatiquement le schéma à partir des données entrantes. De plus, vous pouvez utiliser le Registre de schémas AWS Glue pour permettre la découverte, le contrôle et l'évolution centralisés des schémas de flux de données. Vous pouvez également intégrer le registre de schémas au catalogue de données pour utiliser éventuellement des schémas stockés dans le registre de schémas lors de la création ou de la mise à jour de tables ou de partitions AWS Glue dans le catalogue de données.

Pour cet article, nous créons une table AWS Glue Data Catalog (sensor-stream) avec notre flux de données Kinesis comme source et définir le schéma de nos données de capteur.

Nous créons une trame de données dynamique AWS Glue à partir de la table Data Catalog pour lire les données de streaming de Kinesis. Nous spécifions également les options suivantes :

• Une taille de fenêtre de 60 secondes, afin que la tâche AWS Glue lise et traite les données dans des fenêtres de 60 secondes
• Le poste de départ TRIM_HORIZON, pour permettre la lecture des enregistrements les plus anciens du flux de données Kinesis

Nous utilisons également Spark MLlib's Indexeur de chaînes transformateur de fonctionnalités pour coder le type de colonne de chaîne dans les index d'étiquettes. Cette transformation est implémentée à l'aide de Spark ML Pipelines. Pipelines Spark ML fournir un ensemble uniforme d'API de haut niveau pour les algorithmes ML afin de faciliter la combinaison de plusieurs algorithmes dans un seul pipeline ou flux de travail.

Nous utilisons l'API foreachBatch pour invoquer une fonction nommée processBatch, qui à son tour traite les données référencées par cette trame de données. Voir le code suivant :

# 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 fonction processBatch effectue les transformations spécifiées et partitionne les données dans Amazon S3 en fonction de l'année, du mois, du jour et de l'ID de lot.

Nous repartitionnons également les partitions AWS Glue en une seule partition, pour éviter d'avoir trop de petits fichiers dans Amazon S3. Le fait d'avoir plusieurs petits fichiers peut entraver les performances de lecture, car cela amplifie la surcharge liée à la recherche, à l'ouverture et à la lecture de chaque fichier. Nous écrivons enfin les fonctionnalités pour générer des inférences dans un préfixe (fonctionnalités) dans le compartiment S3. Voir le code suivant :

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

Formation et déploiement de modèles

SageMaker est un service ML entièrement géré et intégré qui permet aux data scientists et aux ingénieurs ML de créer, former et déployer rapidement et facilement des modèles ML.

Dans le bloc-notes Data_Pre-Processing.ipynb, nous importons d'abord l'ensemble de données de maintenance prédictive AI4I à partir du référentiel de données UCI et effectuons une analyse exploratoire des données (EDA). Nous effectuons également l'ingénierie des fonctionnalités pour rendre nos fonctionnalités plus utiles pour la formation du modèle.

Par exemple, dans l'ensemble de données, nous avons une caractéristique nommée type, qui représente le type de qualité du produit comme L (faible), M (moyen) ou H (élevé). Comme il s'agit d'une caractéristique catégorique, nous devons l'encoder avant de former notre modèle. Nous utilisons LabelEncoder de Scikit-Learn pour y parvenir :

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

Une fois les fonctionnalités traitées et les ensembles de données d'entraînement et de test sélectionnés, nous sommes prêts à entraîner un modèle ML pour prédire si la machine a échoué ou non en fonction des lectures du système. Nous formons un modèle XGBoost à l'aide de l'algorithme intégré SageMaker. XGBoost peut fournir de bons résultats pour plusieurs types de problèmes de ML, y compris la classification, même lorsque les échantillons d'apprentissage sont limités.

Emplois de formation SageMaker offrent un moyen puissant et flexible de former des modèles ML sur SageMaker. SageMaker gère l'infrastructure de calcul sous-jacente et fournit plusieurs options à choisir, pour diverses exigences de formation de modèles, en fonction du cas d'utilisation.

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

Lorsque la formation du modèle est terminée et que l'évaluation du modèle est satisfaisante en fonction des besoins de l'entreprise, nous pouvons commencer le déploiement du modèle. Nous créons d'abord une configuration de point de terminaison avec l'option d'objet AsyncInferenceConfig et en utilisant le modèle formé précédemment :

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

Nous créons ensuite un point de terminaison d'inférence asynchrone SageMaker, en utilisant la configuration de point de terminaison que nous avons créée. Une fois qu'il est provisionné, nous pouvons commencer à appeler le point de terminaison pour générer des inférences de manière asynchrone.

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

Inférence en temps quasi réel

SageMaker inférence asynchrone Les points de terminaison offrent la possibilité de mettre en file d'attente les demandes d'inférence entrantes et de les traiter de manière asynchrone en temps quasi réel. Ceci est idéal pour les applications qui ont des demandes d'inférence avec des tailles de charge utile plus importantes (jusqu'à 1 Go), peuvent nécessiter des temps de traitement plus longs (jusqu'à 15 minutes) et ont des exigences de latence en temps quasi réel. L'inférence asynchrone vous permet également de réduire les coûts en mettant à l'échelle automatiquement le nombre d'instances à zéro lorsqu'il n'y a pas de requêtes à traiter, de sorte que vous ne payez que lorsque votre point de terminaison traite les requêtes.

Vous pouvez créer un point de terminaison d'inférence asynchrone SageMaker similaire à la façon dont vous créez un point de terminaison d'inférence en temps réel et spécifier en plus le AsyncInferenceConfig objet, lors de la création de votre configuration de point de terminaison avec le champ EndpointConfig dans l'API CreateEndpointConfig. Le diagramme suivant montre le workflow d'inférence et comment un point de terminaison d'inférence asynchrone génère une inférence.

Pour appeler le point de terminaison d'inférence asynchrone, la charge utile de la demande doit être stockée dans Amazon S3 et une référence à cette charge utile doit être fournie dans le cadre de la demande InvokeEndpointAsync. Lors de l'appel, SageMaker met la demande en file d'attente pour traitement et renvoie un identifiant et un emplacement de sortie en réponse. Lors du traitement, SageMaker place le résultat dans l'emplacement Amazon S3. Vous pouvez éventuellement choisir de recevoir des notifications de réussite ou d'erreur avec Service de notification simple d'Amazon (Amazon SNS).

Testez la solution de bout en bout

Pour tester la solution, procédez comme suit :

• Sur la console AWS CloudFormation, ouvrez la pile que vous avez créée précédemment (nrt-streaming-inference).
• Sur le Sortie , copiez le nom du compartiment S3 (EventsBucket).

Il s'agit du compartiment S3 dans lequel notre tâche de streaming AWS Glue écrit des fonctionnalités après lecture et traitement à partir du flux de données Kinesis.

Ensuite, nous configurons les notifications d'événements pour ce compartiment S3.

• Sur la console Amazon S3, accédez au compartiment EventsBucket.
• Sur le Propriétés onglet, dans le Notifications d'événement section, choisissez Créer une notification d'événement.

• Pour Nom de l'événement, Entrer invoke-endpoint-lambda.
• Pour Préfixe, Entrer features/.
• Pour Suffixe, Entrer .csv.
• Pour Types d'événements, sélectionnez Tous les objets créent des événements.

• Pour dentaire, sélectionnez Fonction Lambda.
• Pour Fonction Lambda, et choisissez la fonction invoke-endpoint-asynch.
• Selectionnez Enregistrer les modifications.

• Sur la console AWS Glue, ouvrez la tâche GlueStreaming-Kinesis-S3.
• Selectionnez Exécuter le travail.

Ensuite, nous utilisons le générateur de données Kinesis (KDG) pour simuler des capteurs envoyant des données à notre flux de données Kinesis. Si c'est la première fois que vous utilisez le KDG, reportez-vous à Vue d’ensemble pour la configuration initiale. Le KDG fournit un modèle CloudFormation pour créer l'utilisateur et attribuer juste assez d'autorisations pour utiliser le KDG pour envoyer des événements à Kinesis. Exécutez le Modèle CloudFormation dans le compte AWS que vous utilisez pour créer la solution dans cet article. Une fois le KDG configuré, connectez-vous et accédez au KDG pour envoyer des événements de test à notre flux de données Kinesis.

• Utilisez la région dans laquelle vous avez créé le flux de données Kinesis (us-east-1).
• Dans le menu déroulant, choisissez le flux de données sensor-data-stream.
• Dans le Enregistrements par seconde section, sélectionnez Constante et entrez 100.
• Désélectionner Compresser les enregistrements.
• Pour Modèle d'enregistrement, utilisez le modèle suivant :

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

• Cliquez Envoyer des données pour commencer à envoyer des données au flux de données Kinesis.

La tâche de streaming AWS Glue lit et extrait un micro-lot de données (représentant les lectures de capteur) du flux de données Kinesis en fonction de la taille de fenêtre fournie. Le travail de diffusion en continu traite et exécute ensuite l'ingénierie des fonctionnalités sur ce micro-lot avant de le partitionner et de l'écrire dans les fonctionnalités de préfixe du compartiment S3.

Au fur et à mesure que les nouvelles fonctionnalités créées par la tâche de streaming AWS Glue sont écrites dans le compartiment S3, une fonction Lambda (invoke-endpoint-asynch) est déclenché, ce qui appelle un point de terminaison d'inférence asynchrone SageMaker en envoyant une demande d'invocation pour obtenir des inférences à partir de notre modèle ML déployé. Le point de terminaison d'inférence asynchrone met en file d'attente la demande d'appel asynchrone. Lorsque le traitement est terminé, SageMaker stocke les résultats d'inférence dans l'emplacement Amazon S3 (S3OutputPath) qui a été spécifié lors de la configuration du point de terminaison d'inférence asynchrone.

Pour notre cas d'utilisation, les résultats d'inférence indiquent si une pièce de la machine est susceptible de tomber en panne ou non, en fonction des lectures des capteurs.

SageMaker envoie également une notification de réussite ou d'erreur avec Amazon SNS. Par exemple, si vous configurez un Abonnement par courrier électronique pour les rubriques SNS de réussite et d'erreur (spécifiées dans la configuration du point de terminaison d'inférence asynchrone SageMaker), un e-mail peut être envoyé chaque fois qu'une demande d'inférence est traitée. La capture d'écran suivante montre un exemple d'e-mail de la rubrique SNS success.

Pour les applications du monde réel, vous pouvez intégrer les notifications SNS à d'autres services tels que Service Amazon Simple Queue (Amazon SQS) et Lambda pour un post-traitement supplémentaire des inférences générées ou une intégration avec d'autres applications en aval, en fonction de vos besoins. Par exemple, pour notre cas d'utilisation de maintenance prédictive, vous pouvez appeler une fonction Lambda basée sur une notification SNS pour lire l'inférence générée à partir d'Amazon S3, la traiter plus avant (comme l'agrégation ou le filtrage) et lancer des workflows tels que l'envoi d'ordres de travail pour réparation d'équipement aux techniciens.

Nettoyer

Lorsque vous avez terminé de tester la pile, supprimez les ressources (en particulier le flux de données Kinesis, la tâche de streaming Glue et les rubriques SNS) pour éviter des frais inattendus.

Exécutez le code suivant pour supprimer votre pile :

sam delete nrt-streaming-inference

Supprimez également les ressources telles que les points de terminaison SageMaker en suivant la section de nettoyage dans le bloc-notes ModelTraining-Evaluation-and-Deployment.

Conclusion

Dans cet article, nous avons utilisé un cas d'utilisation de maintenance prédictive pour montrer comment utiliser divers services tels que Kinesis, AWS Glue et SageMaker pour créer un pipeline d'inférence en temps quasi réel. Nous vous encourageons à essayer cette solution et dites-nous ce que vous en pensez.

Si vous avez des questions, partagez-les dans les commentaires.

À propos des auteurs

Rahul Sharma est architecte de solutions chez AWS Data Lab, aidant les clients AWS à concevoir et à créer des solutions AI/ML. Avant de rejoindre AWS, Rahul a passé plusieurs années dans le secteur de la finance et de l'assurance, aidant les clients à créer des plateformes de données et d'analyse.

Pat Reilly est architecte au AWS Data Lab, où il aide les clients à concevoir et à créer des charges de travail de données pour soutenir leur entreprise. Avant AWS, Pat était consultant chez un partenaire AWS, créant des charges de travail de données AWS dans divers secteurs.