Bygg en lösning för förutsägande underhåll med Amazon Kinesis, AWS Glue och Amazon SageMaker

Organisationer bygger och använder alltmer maskininlärning (ML)-drivna lösningar för en mängd olika användningsfall och problem, inklusive förutsägande underhåll av maskindelar, produktrekommendationer baserade på kundpreferenser, kreditprofilering, innehållsmoderering, bedrägeriupptäckt och mer. I många av dessa scenarier kan effektiviteten och fördelarna från dessa ML-drivna lösningar förbättras ytterligare när de kan bearbeta och härleda insikter från datahändelser i nästan realtid.

Även om affärsvärdet och fördelarna med ML-drivna lösningar i nästan realtid är väletablerade, är arkitekturen som krävs för att implementera dessa lösningar i stor skala med optimal tillförlitlighet och prestanda komplicerad. Det här inlägget beskriver hur du kan kombinera Amazon Kinesis, AWS-limoch Amazon SageMaker att bygga en funktionsteknik och slutledningslösning nästan i realtid för prediktivt underhåll.

Använda fallöversikt

Vi fokuserar på ett förutsägande underhållsanvändningsfall där sensorer som används i fält (som industriell utrustning eller nätverksenheter), behöver bytas ut eller åtgärdas innan de blir felaktiga och orsakar stillestånd. Driftstopp kan vara dyrt för företag och kan leda till dålig kundupplevelse. Förutsägande underhåll som drivs av en ML-modell kan också hjälpa till att utöka de regelbundna schemabaserade underhållscyklerna genom att informera när en maskindel i gott skick inte ska bytas ut, vilket undviker onödiga kostnader.

I det här inlägget fokuserar vi på att tillämpa maskininlärning på en syntetisk datauppsättning som innehåller maskinfel på grund av funktioner som lufttemperatur, processtemperatur, rotationshastighet, vridmoment och verktygsslitage. Datauppsättningen som används är hämtad från UCI Data Repository.

Maskinfel består av fem oberoende fellägen:

• Verktygsslitagefel (TWF)
• Värmeavledningsfel (HDF)
• Strömavbrott (PWF)
• Överbelastningsfel (OSF)
• Random Failure (RNF)

Maskinfelsetiketten indikerar om maskinen har misslyckats för en viss datapunkt om något av de föregående fellägena är sant. Om åtminstone ett av fellägena är sant, misslyckas processen och maskinfelsetiketten sätts till 1. Målet för ML-modellen är att identifiera maskinfel korrekt, så att en nedströms förutsägande underhållsåtgärd kan initieras.

Lösningsöversikt

För vårt prediktiva underhållsanvändningsfall antar vi att enhetssensorer streamar olika mätningar och avläsningar om maskindelar. Vår lösning tar sedan en bit strömmande data varje gång (mikrobatch) och utför bearbetning och funktionsutveckling för att skapa funktioner. De skapade funktionerna används sedan för att generera slutsatser från en tränad och distribuerad ML-modell i nästan realtid. De genererade slutsatserna kan vidarebearbetas och konsumeras av nedströmsapplikationer, för att vidta lämpliga åtgärder och initiera underhållsaktivitet.

Följande diagram visar arkitekturen för vår övergripande lösning.

Lösningen består i stort sett av följande avsnitt, som förklaras i detalj senare i det här inlägget:

• Strömmande datakälla och intag - Vi använder Amazon Kinesis dataströmmar att samla in strömmande data från fältsensorerna i stor skala och göra den tillgänglig för vidare bearbetning.
• Funktionsteknik nästan i realtid – Vi använder AWS Glue-strömningsjobb för att läsa data från en Kinesis-dataström och utföra databearbetning och funktionsutveckling, innan vi lagrar de härledda funktionerna i Amazon enkel lagringstjänst (Amazon S3). Amazon S3 ger ett pålitligt och kostnadseffektivt alternativ för att lagra stora datamängder.
• Modellutbildning och implementering – Vi använder datauppsättningen AI4I för prediktivt underhåll från UCI Data Repository för att träna en ML-modell baserad på XGBoost-algoritmen med SageMaker. Vi distribuerar sedan den tränade modellen till en SageMaker asynkron slutpunktsslutpunkt.
• ML slutledning i nästan realtid – Efter att funktionerna är tillgängliga i Amazon S3 måste vi generera slutsatser från den utplacerade modellen i nästan realtid. SageMaker asynkrona slutpunkter för slutpunkter är väl lämpade för detta krav eftersom de stöder större nyttolaststorlekar (upp till 1 GB) och kan generera slutsatser inom några minuter (upp till maximalt 15 minuter). Vi använder S3 händelseaviseringar för att köra en AWS Lambda funktion för att anropa en SageMaker asynkron slutpunkt slutpunkt. SageMaker asynkrona slutpunkter för slutpunkter accepterar S3-platser som indata, genererar slutsatser från den distribuerade modellen och skriver tillbaka dessa slutsatser till Amazon S3 i nästan realtid.

Källkoden för denna lösning finns på GitHub. Lösningen har testats och bör köras i us-east-1.

Vi använder en AWS molnformation mall, distribuerad med hjälp av AWS serverlös applikationsmodell (AWS SAM) och SageMaker bärbara datorer för att distribuera lösningen.

Förutsättningar

För att komma igång måste du som en förutsättning ha SAM CLI, python 3och PIP installerat. Du måste också ha AWS-kommandoradsgränssnitt (AWS CLI) korrekt konfigurerad.

Distribuera lösningen

Du kan använda AWS CloudShell för att köra dessa steg. CloudShell är ett webbläsarbaserat skal som är förautentiserat med dina konsoluppgifter och inkluderar förinstallerade vanliga utvecklings- och driftsverktyg (som AWS SAM, AWS CLI och Python). Därför krävs ingen lokal installation eller konfiguration.

• Vi börjar med att skapa en S3-hink där vi lagrar skriptet för vårt AWS Glue-streamingjobb. Kör följande kommando i din terminal för att skapa en ny hink:

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

• Anteckna namnet på den skapade hinken.

• Därefter klonar vi kodförrådet lokalt, som innehåller CloudFormation-mallen för att distribuera stacken. Kör följande kommando i din terminal:

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

• Navigera till sam-mallkatalogen:

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

• Kör följande kommando för att kopiera AWS Glue-jobbskriptet (från glue_streaming/app.py) till S3-hinken du skapade:

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

• Du kan nu gå vidare med att bygga och distribuera lösningen genom CloudFormation-mallen via AWS SAM. Kör följande kommando:

sam deploy --guided

• Ange argument för distributionen som stacknamnet, föredragen AWS-region (us-east-1), Och GlueScriptsBucket.

Se till att du tillhandahåller samma S3-hink som du skapade tidigare för AWS Glue script S3-hink (parameter GlueScriptsBucket i följande skärmdump).

När du har angett de nödvändiga argumenten startar AWS SAM stackdistributionen. Följande skärmdump visar resurserna som skapats.

När stacken har distribuerats framgångsrikt bör du se följande meddelande.

• På AWS CloudFormation-konsolen öppnar du stacken (för det här inlägget, nrt-streaming-inference) som tillhandahålls när CloudFormation-mallen distribueras.
• På Resurser fliken, notera SageMaker-anteckningsbokens instans-ID.

• Öppna den här instansen på SageMaker-konsolen.

SageMaker-anteckningsbokförekomsten har redan de nödvändiga anteckningsböckerna förinstallerade.

Navigera till mappen anteckningsböcker och öppna och följ instruktionerna i anteckningsböckerna (Data_Pre-Processing.ipynb och ModelTraining-Evaluation-and-Deployment.ipynb) för att utforska datamängden, utföra förbearbetning och funktionsteknik samt träna och distribuera modellen till en SageMaker asynkron slutpunktsslutpunkt.

Strömmande datakälla och intag

Kinesis Data Streams är en serverlös, skalbar och hållbar dataströmningstjänst i realtid som du kan använda för att samla in och bearbeta stora strömmar av dataposter i realtid. Kinesis Data Streams möjliggör insamling, bearbetning och lagring av dataströmmar från en mängd olika källor, såsom IT-infrastrukturloggdata, applikationsloggar, sociala medier, marknadsdataflöden, webbklickströmsdata, IoT-enheter och sensorer med mera. Du kan tillhandahålla en Kinesis-dataström i on-demand-läge eller provisionerat läge beroende på genomströmnings- och skalningskrav. För mer information, se Välja dataströmskapacitetsläge.

För vårt användningsfall antar vi att olika sensorer skickar mätningar som temperatur, rotationshastighet, vridmoment och verktygsslitage till en dataström. Kinesis Dataströmmar fungerar som en tratt för att samla in och mata in dataströmmar.

Vi använder Amazon Kinesis Data Generator (KDG) senare i det här inlägget för att generera och skicka data till en Kinesis-dataström, som simulerar data som genereras av sensorer. Data från dataströmmen sensor-data-ström tas in och bearbetas med hjälp av ett AWS Glue-strömningsjobb, som vi diskuterar härnäst.

Funktionsteknik nästan i realtid

AWS Glue streaming jobb ger ett bekvämt sätt att behandla strömmande data i stor skala, utan att behöva hantera datormiljön. AWS Glue låter dig utföra extrahera, transformera och ladda (ETL) operationer på strömmande data med kontinuerligt körande jobb. AWS Glue streaming ETL är byggd på Apache Spark Structured Streaming-motorn och kan ta emot strömmar från Kinesis, Apache Kafka och Amazon Managed Streaming för Apache Kafka (Amazon MSK).

Det strömmande ETL-jobbet kan använda både AWS Glue inbyggda transformationer och transformeringar som är inbyggda i Apache Spark Structured Streaming. Du kan också använda Spark ML och MLLib bibliotek i AWS Limjobb för enklare funktionsbearbetning med hjälp av lättillgängliga hjälpbibliotek.

Om schemat för den strömmande datakällan är förutbestämt kan du ange det i en AWS Data Catalog-tabell. Om schemadefinitionen inte kan fastställas i förväg kan du aktivera schemadetektering i det strömmande ETL-jobbet. Jobbet bestämmer sedan automatiskt schemat från inkommande data. Dessutom kan du använda AWS Glue Schema Registry för att möjliggöra central upptäckt, kontroll och utveckling av dataströmsscheman. Du kan ytterligare integrera schemaregistret med datakatalogen för att valfritt använda scheman lagrade i schemaregistret när du skapar eller uppdaterar AWS Glue-tabeller eller -partitioner i datakatalogen.

För det här inlägget skapar vi en AWS Glue Data Catalog-tabell (sensor-stream) med vår Kinesis-dataström som källa och definiera schemat för våra sensordata.

Vi skapar en dynamisk AWS Glue-dataram från Data Catalog-tabellen för att läsa streamingdata från Kinesis. Vi specificerar även följande alternativ:

• En fönsterstorlek på 60 sekunder, så att AWS Glue-jobbet läser och bearbetar data i 60-sekunders fönster
• Utgångsläget TRIM_HORIZON, för att tillåta läsning från de äldsta posterna i Kinesis dataström

Vi använder även Spark MLlib's StringIndexer funktionstransformator för att koda strängkolumntypen till etikettindex. Denna transformation implementeras med hjälp av Spark ML Pipelines. Spark ML Pipelines tillhandahålla en enhetlig uppsättning API:er på hög nivå för ML-algoritmer för att göra det lättare att kombinera flera algoritmer till en enda pipeline eller arbetsflöde.

Vi använder foreachBatch API för att anropa en funktion som heter processBatch, som i sin tur bearbetar data som refereras av denna dataram. Se följande kod:

# 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 utför de specificerade transformationerna och partitionerar data i Amazon S3 baserat på år, månad, dag och batch-ID.

Vi partitionerar också om AWS Glue-partitionerna till en enda partition för att undvika att ha för många små filer i Amazon S3. Att ha flera små filer kan försämra läsprestanda, eftersom det förstärker kostnaderna för att söka, öppna och läsa varje fil. Vi skriver äntligen funktionerna för att generera slutsatser till ett prefix (funktioner) i S3-hinken. Se följande kod:

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

Modellutbildning och distribution

SageMaker är en helt hanterad och integrerad ML-tjänst som gör det möjligt för datavetare och ML-ingenjörer att snabbt och enkelt bygga, träna och distribuera ML-modeller.

Inom anteckningsboken Data_Pre-Processing.ipynb, vi importerar först AI4I Predictive Maintenance dataset från UCI Data Repository och utför utforskande dataanalys (EDA). Vi utför också funktionsteknik för att göra våra funktioner mer användbara för att träna modellen.

Inom datasetet har vi till exempel en funktion som heter typ, som representerar produktens kvalitetstyp som L (låg), M (medium) eller H (hög). Eftersom detta är en kategorisk funktion måste vi koda den innan vi tränar vår modell. Vi använder Scikit-Learns LabelEncoder för att uppnå detta:

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

Efter att funktionerna har bearbetats och de kurerade tåg- och testdatauppsättningarna har genererats, är vi redo att träna en ML-modell för att förutsäga om maskinen misslyckades eller inte baserat på systemavläsningar. Vi tränar en XGBoost-modell med den inbyggda SageMaker-algoritmen. XGBoost kan ge bra resultat för flera typer av ML-problem, inklusive klassificering, även när träningsproverna är begränsade.

SageMaker utbildningsjobb tillhandahålla ett kraftfullt och flexibelt sätt att träna ML-modeller på SageMaker. SageMaker hanterar den underliggande beräkningsinfrastrukturen och tillhandahåller flera alternativ att välja mellan, för olika modellutbildningskrav, baserat på användningsfallet.

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 modellutbildningen är klar och modellutvärderingen är tillfredsställande utifrån affärskraven, kan vi påbörja modellimplementeringen. Vi skapar först en slutpunktskonfiguration med objektalternativet AsyncInferenceConfig och använder modellen som tränats tidigare:

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 skapar sedan en SageMaker asynkron slutpunktsslutpunkt med hjälp av den slutpunktskonfiguration vi skapade. Efter att den har tillhandahållits kan vi börja anropa slutpunkten för att generera inferenser asynkront.

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

Nästan realtids slutledning

SageMaker asynkron slutledning endpoints ger möjlighet att köa inkommande slutledningsförfrågningar och behandla dem asynkront i nästan realtid. Detta är idealiskt för applikationer som har slutledningsförfrågningar med större nyttolaststorlekar (upp till 1 GB), kan kräva längre bearbetningstider (upp till 15 minuter) och har krav på fördröjning i nästan realtid. Asynkron slutledning gör att du också kan spara på kostnader genom att automatiskt skala instansräkningen till noll när det inte finns några förfrågningar att behandla, så du betalar bara när din slutpunkt behandlar förfrågningar.

Du kan skapa en SageMaker asynkron slutpunkt slutpunkt som liknar hur du skapar en slutpunkt i realtid och dessutom specificera AsyncInferenceConfig objekt, medan du skapar din slutpunktskonfiguration med EndpointConfig-fältet i CreateEndpointConfig API. Följande diagram visar inferensarbetsflödet och hur en asynkron slutpunktsslutpunkt genererar en slutledning.

För att anropa den asynkrona slutpunkten, bör nyttolasten för begäran lagras i Amazon S3 och referens till denna nyttolast måste tillhandahållas som en del av InvokeEndpointAsync-förfrågan. Vid anrop ställer SageMaker begäran för bearbetning och returnerar en identifierare och utdataplats som ett svar. Vid bearbetning placerar SageMaker resultatet på Amazon S3-platsen. Du kan valfritt välja att få framgångs- eller felmeddelanden med Amazon enkel meddelandetjänst (Amazon SNS).

Testa end-to-end-lösningen

Gör följande för att testa lösningen:

• På AWS CloudFormation-konsolen öppnar du stacken du skapade tidigare (nrt-streaming-inference).
• På Utgångarna fliken, kopiera namnet på S3-hinken (EventsBucket).

Detta är S3-hinken som vårt AWS Glue-streamingjobb skriver funktioner till efter att ha läst och bearbetat från Kinesis-dataströmmen.

Därefter ställer vi in ​​händelseaviseringar för den här S3-hinken.

• På Amazon S3-konsolen, navigera till hinken EventsBucket.
• På Våra Bostäder fliken, i Händelsemeddelanden avsnitt väljer Skapa händelseavisering.

• För Event namn, stiga på invoke-endpoint-lambda.
• För Prefix, stiga på features/.
• För Ändelse, stiga på .csv.
• För Händelsetyper, Välj Alla objekt skapar händelser.

• För Destination, Välj Lambdafunktion.
• För Lambdafunktion, och välj funktionen invoke-endpoint-asynch.
• Välja Spara ändringar.

• Öppna jobbet på AWS Glue-konsolen GlueStreaming-Kinesis-S3.
• Välja Kör jobb.

Därefter använder vi Kinesis Data Generator (KDG) för att simulera sensorer som skickar data till vår Kinesis dataström. Om detta är första gången du använder KDG, se Översikt för den första inställningen. KDG tillhandahåller en CloudFormation-mall för att skapa användaren och tilldela precis tillräckligt med behörigheter för att använda KDG för att skicka händelser till Kinesis. Springa det CloudFormation-mall inom AWS-kontot som du använder för att bygga lösningen i det här inlägget. Efter att KDG har ställts in, logga in och få tillgång till KDG för att skicka testhändelser till vår Kinesis-dataström.

• Använd regionen där du skapade Kinesis-dataströmmen (us-east-1).
• Välj dataströmmen i rullgardinsmenyn sensor-data-stream.
• I Rekord per sekund avsnitt, välj Konstant och ange 100.
• Avmarkera Komprimera poster.
• För Rekordmall, använd följande mall:

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

• Klicka Skicka data för att börja skicka data till Kinesis dataström.

AWS Glue-strömningsjobbet läser och extraherar en mikrobatch av data (som representerar sensoravläsningar) från Kinesis-dataströmmen baserat på den angivna fönsterstorleken. Strömningsjobbet bearbetar sedan och utför funktionsutveckling på denna mikrobatch innan den partitioneras och skriver den till prefixfunktionerna i S3-hinken.

Eftersom nya funktioner skapade av AWS Glue-streamingjobbet skrivs till S3-skopan, en Lambda-funktion (invoke-endpoint-asynch) utlöses, vilket anropar en SageMaker asynkron slutpunkt slutpunkt genom att skicka en anropsbegäran för att få slutsatser från vår distribuerade ML-modell. Den asynkrona slutpunkten ställer begäran om asynkron anrop i kö. När bearbetningen är klar lagrar SageMaker slutledningsresultaten på Amazon S3-platsen (S3OutputPath) som specificerades under den asynkrona slutpunktskonfigurationen.

För vårt användningsfall indikerar slutledningsresultaten om en maskindel sannolikt kommer att misslyckas eller inte, baserat på sensoravläsningarna.

SageMaker skickar också ett framgångs- eller felmeddelande med Amazon SNS. Till exempel, om du ställer in en e-postabonnemang för framgång och fel SNS-ämnen (specificerade i den asynkrona SageMaker slutpunktskonfigurationen), kan ett e-postmeddelande skickas varje gång en begäran om slutledning bearbetas. Följande skärmdump visar ett exempel på e-post från SNS framgångsämnet.

För verkliga applikationer kan du integrera SNS-aviseringar med andra tjänster som t.ex Amazon enkel kötjänst (Amazon SQS) och Lambda för ytterligare efterbearbetning av de genererade slutledningarna eller integration med andra nedströmsapplikationer, baserat på dina krav. Till exempel, för vårt förutsägande underhållsanvändningsfall, kan du anropa en Lambda-funktion baserad på en SNS-avisering för att läsa den genererade slutledningen från Amazon S3, vidarebehandla den (som aggregering eller filtrering) och initiera arbetsflöden som att skicka arbetsorder för reparation av utrustning till tekniker.

Städa upp

När du är klar med att testa stacken, ta bort resurserna (särskilt Kinesis-dataströmmen, Limströmningsjobbet och SNS-ämnen) för att undvika oväntade avgifter.

Kör följande kod för att radera din stack:

sam delete nrt-streaming-inference

Ta också bort resurser som SageMaker-slutpunkter genom att följa rensningsavsnittet i anteckningsboken ModelTraining-Evaluation-and-Deployment.

Slutsats

I det här inlägget använde vi ett prediktivt underhållsanvändningsfall för att visa hur man använder olika tjänster som Kinesis, AWS Glue och SageMaker för att bygga en slutledningspipeline i nästan realtid. Vi uppmuntrar dig att prova den här lösningen och låt oss veta vad du tycker.

Om du har några frågor, dela dem i kommentarerna.

Om författarna

Rahul Sharma är en lösningsarkitekt på AWS Data Lab och hjälper AWS-kunder att designa och bygga AI/ML-lösningar. Innan han började på AWS har Rahul tillbringat flera år inom finans- och försäkringssektorn och hjälpt kunder att bygga data- och analytiska plattformar.

Pat Reilly är en arkitekt i AWS Data Lab, där han hjälper kunder att designa och bygga dataarbetsbelastningar för att stödja deras verksamhet. Före AWS konsulterade Pat hos en AWS-partner och byggde upp AWS-dataarbetsbelastningar inom en mängd olika branscher.