Byg en forudsigelig vedligeholdelsesløsning med Amazon Kinesis, AWS Glue og Amazon SageMaker

Organisationer bygger og bruger i stigende grad maskinlæringsdrevne løsninger (ML) til en række forskellige anvendelsessager og problemer, herunder forudsigelig vedligeholdelse af maskindele, produktanbefalinger baseret på kundepræferencer, kreditprofilering, indholdsmoderering, opdagelse af svindel og meget mere. I mange af disse scenarier kan effektiviteten og fordelene fra disse ML-drevne løsninger forbedres yderligere, når de kan behandle og udlede indsigt fra datahændelser i næsten realtid.

Selvom forretningsværdien og fordelene ved ML-drevne løsninger i næsten realtid er veletablerede, er den nødvendige arkitektur for at implementere disse løsninger i stor skala med optimal pålidelighed og ydeevne kompliceret. Dette indlæg beskriver, hvordan du kan kombinere Amazon Kinesis, AWS Limog Amazon SageMaker at bygge en funktionsteknologi og inferensløsning næsten i realtid til forudsigelig vedligeholdelse.

Brug case oversigt

Vi fokuserer på en forudsigelig vedligeholdelsesbrug, hvor sensorer, der er installeret i marken (såsom industrielt udstyr eller netværksenheder), skal udskiftes eller rettes, før de bliver defekte og forårsager nedetid. Nedetid kan være dyrt for virksomheder og kan føre til dårlig kundeoplevelse. Forudsigende vedligeholdelse drevet af en ML-model kan også hjælpe med at øge de regelmæssige tidsplanbaserede vedligeholdelsescyklusser ved at informere, når en maskindel i god stand ikke bør udskiftes, og dermed undgå unødvendige omkostninger.

I dette indlæg fokuserer vi på at anvende maskinlæring på et syntetisk datasæt, der indeholder maskinfejl på grund af funktioner som lufttemperatur, procestemperatur, rotationshastighed, drejningsmoment og værktøjsslid. Det anvendte datasæt er hentet fra UCI Data Repository.

Maskinfejl består af fem uafhængige fejltilstande:

• Tool Wear Failure (TWF)
• Varmeafledningsfejl (HDF)
• Strømsvigt (PWF)
• Overbelastningsfejl (OSF)
• Tilfældig fejl (RNF)

Maskinfejletiketten angiver, om maskinen har fejlet for et bestemt datapunkt, hvis nogen af ​​de foregående fejltilstande er sande. Hvis mindst en af ​​fejltilstandene er sande, mislykkes processen, og maskinfejlsetiketten er sat til 1. Målet for ML-modellen er at identificere maskinfejl korrekt, så en forudsigelig vedligeholdelseshandling nedstrøms kan igangsættes.

Løsningsoversigt

For vores forudsigelige vedligeholdelsesbrug antager vi, at enhedssensorer streamer forskellige målinger og aflæsninger om maskindele. Vores løsning tager derefter et stykke streaming data hver gang (mikro-batch), og udfører behandling og funktionsudvikling for at skabe funktioner. De oprettede funktioner bruges derefter til at generere slutninger fra en trænet og implementeret ML-model i næsten realtid. De genererede slutninger kan viderebehandles og forbruges af downstream-applikationer for at træffe passende handlinger og igangsætte vedligeholdelsesaktivitet.

Følgende diagram viser arkitekturen af ​​vores samlede løsning.

Løsningen består i store træk af følgende sektioner, som forklares i detaljer senere i dette indlæg:

• Streaming af datakilde og indtagelse - Vi bruger Amazon Kinesis datastrømme at indsamle streamingdata fra feltsensorerne i stor skala og gøre dem tilgængelige for videre behandling.
• Funktionsteknik næsten i realtid – Vi bruger AWS Glue-streamingjob til at læse data fra en Kinesis-datastrøm og udføre databehandling og funktionsudvikling, før vi gemmer de afledte funktioner i Amazon Simple Storage Service (Amazon S3). Amazon S3 giver en pålidelig og omkostningseffektiv mulighed for at gemme store mængder data.
• Modeltræning og implementering – Vi bruger AI4I-forudsigende vedligeholdelsesdatasæt fra UCI Data Repository til at træne en ML-model baseret på XGBoost-algoritmen ved hjælp af SageMaker. Vi implementerer derefter den trænede model til et SageMaker asynkron inferens-endepunkt.
• ML-inferens i næsten realtid – Efter at funktionerne er tilgængelige i Amazon S3, skal vi generere slutninger fra den installerede model i næsten realtid. SageMaker asynkrone inferens-endepunkter er velegnede til dette krav, fordi de understøtter større nyttelaststørrelser (op til 1 GB) og kan generere inferenser inden for få minutter (op til maksimalt 15 minutter). Vi bruger S3-begivenhedsmeddelelser til at køre en AWS Lambda funktion til at påkalde et SageMaker asynkront inferensslutpunkt. SageMaker asynkrone inferens-endepunkter accepterer S3-lokationer som input, genererer slutninger fra den implementerede model og skriver disse slutninger tilbage til Amazon S3 i næsten realtid.

Kildekoden til denne løsning er placeret på GitHub. Løsningen er testet og bør køres i us-east-1.

Vi bruger en AWS CloudFormation skabelon, implementeret ved hjælp af AWS serverløs applikationsmodel (AWS SAM) og SageMaker notebooks til at implementere løsningen.

Forudsætninger

For at komme i gang skal du som forudsætning have SAM CLI, Python 3og PIP installeret. Du skal også have AWS kommandolinjegrænseflade (AWS CLI) konfigureret korrekt.

Implementer løsningen

Du kan bruge AWS CloudShell at køre disse trin. CloudShell er en browserbaseret shell, der er forhåndsgodkendt med dine konsollegitimationsoplysninger og inkluderer forudinstallerede fælles udviklings- og driftsværktøjer (såsom AWS SAM, AWS CLI og Python). Derfor kræves ingen lokal installation eller konfiguration.

• Vi begynder med at lave en S3-bøtte, hvor vi gemmer scriptet til vores AWS Glue-streamingjob. Kør følgende kommando i din terminal for at oprette en ny bøtte:

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

• Noter navnet på den oprettede spand.

• Dernæst kloner vi kodelageret lokalt, som indeholder CloudFormation-skabelonen til at implementere stakken. Kør følgende kommando i din terminal:

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

• Naviger til sam-skabelonbiblioteket:

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

• Kør følgende kommando for at kopiere AWS Glue-jobscriptet (fra glue_streaming/app.py) til den S3-bøtte, du oprettede:

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

• Du kan nu gå videre med opbygningen og implementeringen af ​​løsningen gennem CloudFormation-skabelonen via AWS SAM. Kør følgende kommando:

sam deploy --guided

• Angiv argumenter for implementeringen, såsom staknavnet, foretrukne AWS-region (us-east-1), Og GlueScriptsBucket.

Sørg for, at du leverer den samme S3-spand, som du oprettede tidligere til AWS Glue script S3-spanden (parameter GlueScriptsBucket i det følgende skærmbillede).

Når du har angivet de påkrævede argumenter, starter AWS SAM stakimplementeringen. Følgende skærmbillede viser de oprettede ressourcer.

Når stakken er implementeret med succes, bør du se følgende meddelelse.

• På AWS CloudFormation-konsollen skal du åbne stakken (for dette indlæg, nrt-streaming-inference), der blev leveret, da CloudFormation-skabelonen blev implementeret.
• På Ressourcer fanen, bemærk SageMaker notebook-forekomst-id'et.

• Åbn denne instans på SageMaker-konsollen.

SageMaker notebook-forekomsten har allerede de påkrævede notebooks forudindlæst.

Naviger til mappen notesbøger og åbn og følg instruktionerne i notesbøgerne (Data_Pre-Processing.ipynb , ModelTraining-Evaluation-and-Deployment.ipynb) for at udforske datasættet, udføre forbehandling og feature engineering og træne og implementere modellen til et SageMaker asynkront inferensslutpunkt.

Streaming af datakilde og indtagelse

Kinesis Data Streams er en serverløs, skalerbar og holdbar datastreamingtjeneste i realtid, som du kan bruge til at indsamle og behandle store datastrømme i realtid. Kinesis Data Streams muliggør opsamling, behandling og lagring af datastrømme fra en række forskellige kilder, såsom IT-infrastrukturlogdata, applikationslogfiler, sociale medier, markedsdatafeeds, web-klikstrømsdata, IoT-enheder og sensorer og mere. Du kan klargøre en Kinesis-datastrøm i on-demand-tilstand eller klargjort tilstand afhængigt af gennemløbs- og skaleringskravene. For mere information, se Valg af datastrømkapacitetstilstand.

Til vores brug antager vi, at forskellige sensorer sender målinger såsom temperatur, rotationshastighed, drejningsmoment og værktøjsslid til en datastrøm. Kinesis Data Streams fungerer som en tragt til at indsamle og indtage datastrømme.

Vi bruger Amazon Kinesis Data Generator (KDG) senere i dette indlæg for at generere og sende data til en Kinesis-datastrøm, der simulerer data, der genereres af sensorer. Dataene fra datastrømmen sensor-data-stream indtages og behandles ved hjælp af et AWS Glue-streamingjob, som vi diskuterer herefter.

Funktionsteknik næsten i realtid

AWS Glue streaming job giver en bekvem måde at behandle streamingdata i stor skala uden behov for at administrere computermiljøet. AWS Glue giver dig mulighed for at udføre udtræk, transformation og indlæsning (ETL) operationer på streaming af data ved hjælp af kontinuerligt kørende job. AWS Glue streaming ETL er bygget på Apache Spark Structured Streaming-motoren og kan indtage streams fra Kinesis, Apache Kafka og Amazon administrerede streaming til Apache Kafka (Amazon MSK).

Streaming ETL-jobbet kan bruge både AWS Glue indbyggede transformationer og transformationer, der er native til Apache Spark Structured Streaming. Du kan også bruge Spark ML og MLLib biblioteker i AWS Lim-job for lettere funktionsbehandling ved hjælp af let tilgængelige hjælpebiblioteker.

Hvis skemaet for streamingdatakilden er forudbestemt, kan du angive det i en AWS Data Catalog-tabel. Hvis skemadefinitionen ikke kan bestemmes på forhånd, kan du aktivere skemadetektion i streaming-ETL-jobbet. Jobbet bestemmer derefter automatisk skemaet ud fra de indgående data. Derudover kan du bruge AWS Lim Schema Registry at tillade central opdagelse, kontrol og udvikling af datastrømsskemaer. Du kan yderligere integrere skemaregistret med datakataloget for valgfrit at bruge skemaer gemt i skemaregistret, når du opretter eller opdaterer AWS Glue-tabeller eller -partitioner i datakataloget.

Til dette indlæg opretter vi en AWS Glue Data Catalog-tabel (sensor-stream) med vores Kinesis-datastrøm som kilde og definere skemaet for vores sensordata.

Vi opretter en AWS Glue dynamisk dataramme fra Data Catalog-tabellen for at læse streamingdataene fra Kinesis. Vi angiver også følgende muligheder:

• En vinduesstørrelse på 60 sekunder, så AWS Glue-jobbet læser og behandler data i 60 sekunders vinduer
• Udgangspositionen TRIM_HORIZON, for at tillade læsning fra de ældste poster i Kinesis-datastrømmen

Vi bruger også Spark MLlib's StringIndexer funktionstransformer til at indkode strengkolonnetypen til etiketindekser. Denne transformation er implementeret ved hjælp af Spark ML Pipelines. Spark ML Pipelines levere et ensartet sæt API'er på højt niveau til ML-algoritmer for at gøre det nemmere at kombinere flere algoritmer i en enkelt pipeline eller arbejdsgang.

Vi bruger foreachBatch API til at påkalde en funktion ved navn processBatch, som igen behandler de data, som denne dataramme refererer til. 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})

Funktionen processBatch udfører de specificerede transformationer og opdeler dataene i Amazon S3 baseret på år, måned, dag og batch-id.

Vi ompartitionerer også AWS Glue-partitionerne i en enkelt partition for at undgå at have for mange små filer i Amazon S3. At have flere små filer kan hæmme læseydelsen, fordi det forstærker overheaden i forbindelse med at søge, åbne og læse hver fil. Vi skriver endelig funktionerne for at generere slutninger til et præfiks (funktioner) 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()))

Modeltræning og implementering

SageMaker er en fuldt administreret og integreret ML-tjeneste, der gør det muligt for datavidenskabsmænd og ML-ingeniører hurtigt og nemt at bygge, træne og implementere ML-modeller.

I Data_Pre-Processing.ipynb notesbogen, vi importerer først AI4I Predictive Maintenance-datasættet fra UCI Data Repository og udfører eksplorativ dataanalyse (EDA). Vi udfører også feature engineering for at gøre vores funktioner mere nyttige til træning af modellen.

For eksempel har vi inden for datasættet en funktion ved navn type, som repræsenterer produktets kvalitetstype som L (lav), M (medium) eller H (høj). Fordi dette er kategorisk træk, skal vi kode det, før vi træner vores model. Vi bruger Scikit-Learns LabelEncoder til at opnå dette:

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

Efter at funktionerne er behandlet, og de kurerede tog- og testdatasæt er genereret, er vi klar til at træne en ML-model for at forudsige, om maskinen fejlede eller ej baseret på systemaflæsninger. Vi træner en XGBoost-model ved hjælp af den indbyggede SageMaker-algoritme. XGBoost kan give gode resultater for flere typer ML-problemer, herunder klassificering, selv når træningsprøver er begrænsede.

SageMaker uddannelse job give en kraftfuld og fleksibel måde at træne ML-modeller på SageMaker. SageMaker administrerer den underliggende computerinfrastruktur og leverer flere indstillinger at vælge imellem, til forskellige modeluddannelseskrav baseret på brugssagen.

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 modeluddannelsen er afsluttet, og modelevalueringen er tilfredsstillende baseret på forretningskravene, kan vi begynde modelimplementeringen. Vi opretter først en slutpunktskonfiguration med AsyncInferenceConfig-objektindstillingen og bruger den tidligere trænede 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},
},)

Vi opretter derefter et SageMaker asynkront inferensslutpunkt ved at bruge den slutpunktskonfiguration, vi oprettede. Efter det er klargjort, kan vi begynde at kalde slutpunktet for at generere inferenser asynkront.

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

Nær-realtidsslutning

SageMaker asynkron inferens endepunkter giver mulighed for at sætte indgående slutningsanmodninger i kø og behandle dem asynkront i næsten realtid. Dette er ideelt til applikationer, der har slutningsanmodninger med større nyttelaststørrelser (op til 1 GB), kan kræve længere behandlingstider (op til 15 minutter) og har krav til ventetid næsten i realtid. Asynkron inferens giver dig også mulighed for at spare på omkostningerne ved automatisk at skalere instansantallet til nul, når der ikke er nogen anmodninger at behandle, så du kun betaler, når dit slutpunkt behandler anmodninger.

Du kan oprette et SageMaker asynkront inferensslutpunkt svarende til, hvordan du opretter et realtidsslutningsslutpunkt og desuden angive AsyncInferenceConfig objekt, mens du opretter din slutpunktskonfiguration med feltet EndpointConfig i CreateEndpointConfig API. Følgende diagram viser inferensarbejdsgangen, og hvordan et asynkront inferensendepunkt genererer en inferens.

For at påkalde det asynkrone inferensslutpunkt, skal anmodningens nyttelast lagres i Amazon S3, og reference til denne nyttelast skal angives som en del af InvokeEndpointAsync-anmodningen. Ved påkaldelse sætter SageMaker anmodningen i kø for behandling og returnerer en identifikator og outputplacering som et svar. Efter behandling placerer SageMaker resultatet i Amazon S3-lokationen. Du kan valgfrit vælge at modtage succes- eller fejlmeddelelser med Amazon Simple Notification Service (Amazon SNS).

Test ende-til-ende-løsningen

For at teste løsningen skal du udføre følgende trin:

• På AWS CloudFormation-konsollen skal du åbne den stak, du oprettede tidligere (nrt-streaming-inference).
• På Udgange fanen, kopier navnet på S3-bøtten (EventsBucket).

Dette er S3-bøtten, som vores AWS Glue-streamingjob skriver funktioner til efter læsning og behandling fra Kinesis-datastrømmen.

Dernæst konfigurerer vi begivenhedsnotifikationer for denne S3-bøtte.

• På Amazon S3-konsollen skal du navigere til bøtten EventsBucket.
• På Ejendomme fanebladet i Begivenhedsmeddelelser sektion, skal du vælge Opret begivenhedsmeddelelse.

• Til Begivenhedsnavn, gå ind invoke-endpoint-lambda.
• Til Præfiks, gå ind features/.
• Til Suffiks, gå ind .csv.
• Til Begivenhedstyper, Vælg Alle objekter skaber begivenheder.

• Til Bestemmelsessted, Vælg Lambda funktion.
• Til Lambda funktion, og vælg funktionen invoke-endpoint-asynch.
• Vælg Gem ændringer.

• Åbn jobbet på AWS Glue-konsollen GlueStreaming-Kinesis-S3.
• Vælg Kør job.

Dernæst bruger vi Kinesis Data Generator (KDG) til at simulere sensorer, der sender data til vores Kinesis datastrøm. Hvis det er første gang, du bruger KDG, se Oversigt til den indledende opsætning. KDG'en giver en CloudFormation-skabelon til at oprette brugeren og tildele lige nok tilladelser til at bruge KDG'en til at sende begivenheder til Kinesis. Kør CloudFormation skabelon inden for den AWS-konto, du bruger til at bygge løsningen i dette indlæg. Når KDG er konfigureret, skal du logge ind og få adgang til KDG for at sende testhændelser til vores Kinesis-datastrøm.

• Brug den region, hvor du oprettede Kinesis-datastrømmen (us-east-1).
• Vælg datastrømmen i rullemenuen sensor-data-stream.
• I Rekorder i sekundet sektion, vælg Konstant og indtast 100.
• Fravælg Komprimer poster.
• Til Optag skabelon, brug følgende skabelon:

{
"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 Send data for at begynde at sende data til Kinesis-datastrømmen.

AWS Glue-streamingjobbet læser og udtrækker en mikrobatch af data (der repræsenterer sensoraflæsninger) fra Kinesis-datastrømmen baseret på den angivne vinduesstørrelse. Streamingjobbet behandler og udfører derefter funktionsudvikling på denne mikrobatch, før den partitioneres og skrives til præfiksfunktionerne i S3-bøtten.

Da nye funktioner, der er skabt af AWS Glue-streamingjobbet, skrives til S3-spanden, er en Lambda-funktion (invoke-endpoint-asynch) udløses, hvilket påkalder et SageMaker asynkront inferensslutpunkt ved at sende en invokationsanmodning for at få slutninger fra vores implementerede ML-model. Slutpunktet for asynkron inferens sætter anmodningen om asynkron påkaldelse i kø. Når behandlingen er færdig, gemmer SageMaker slutningsresultaterne på Amazon S3-lokationen (S3OutputPath), der blev specificeret under konfigurationen af ​​den asynkrone inferensslutpunkt.

For vores brugssag indikerer slutningsresultaterne, om en maskindel sandsynligvis vil fejle eller ej, baseret på sensoraflæsningerne.

SageMaker sender også en succes- eller fejlmeddelelse med Amazon SNS. Hvis du f.eks. opsætter en e-mail-abonnement for succes- og fejl-SNS-emner (specificeret i den asynkrone SageMaker-slutpunktskonfiguration), kan der sendes en e-mail, hver gang en inferensanmodning behandles. Følgende skærmbillede viser en prøve-e-mail fra SNS-succesemnet.

For applikationer i den virkelige verden kan du integrere SNS-meddelelser med andre tjenester som f.eks Amazon Simple Queue Service (Amazon SQS) og Lambda for yderligere efterbehandling af de genererede slutninger eller integration med andre downstream-applikationer, baseret på dine krav. For eksempel, for vores forudsigelige vedligeholdelsesbrug, kan du aktivere en Lambda-funktion baseret på en SNS-meddelelse for at læse den genererede slutning fra Amazon S3, behandle den yderligere (såsom aggregering eller filtrering) og starte arbejdsgange såsom at sende arbejdsordrer for reparation af udstyr til teknikere.

Ryd op

Når du er færdig med at teste stakken, skal du slette ressourcerne (især Kinesis-datastrømmen, Lim-streaming-job og SNS-emner) for at undgå uventede gebyrer.

Kør følgende kode for at slette din stak:

sam delete nrt-streaming-inference

Slet også ressourcerne såsom SageMaker-endepunkter ved at følge oprydningsafsnittet i Notebook'en ModelTraining-Evaluation-and-Deployment.

Konklusion

I dette indlæg brugte vi en forudsigelig vedligeholdelsesanvendelse til at demonstrere, hvordan man bruger forskellige tjenester såsom Kinesis, AWS Glue og SageMaker til at bygge en nær-realtids-inferenspipeline. Vi opfordrer dig til at prøve denne løsning og fortælle os, hvad du synes.

Hvis du har spørgsmål, så del dem i kommentarerne.

Om forfatterne

Rahul Sharma er Solutions Architect hos AWS Data Lab, der hjælper AWS-kunder med at designe og bygge AI/ML-løsninger. Før han kom til AWS, har Rahul tilbragt flere år i finans- og forsikringssektoren og hjulpet kunder med at bygge data- og analytiske platforme.

Pat Reilly er arkitekt i AWS Data Lab, hvor han hjælper kunder med at designe og opbygge dataarbejdsbelastninger til at understøtte deres forretning. Før AWS konsulterede Pat hos en AWS-partner og opbyggede AWS-dataarbejdsbelastninger på tværs af en række brancher.