Crie uma solução de manutenção preditiva com Amazon Kinesis, AWS Glue e Amazon SageMaker

As organizações estão cada vez mais criando e usando soluções baseadas em aprendizado de máquina (ML) para uma variedade de casos de uso e problemas, incluindo manutenção preditiva de peças de máquinas, recomendações de produtos com base nas preferências do cliente, perfil de crédito, moderação de conteúdo, detecção de fraude e muito mais. Em muitos desses cenários, a eficácia e os benefícios derivados dessas soluções baseadas em ML podem ser ainda mais aprimorados quando elas podem processar e obter insights de eventos de dados quase em tempo real.

Embora o valor comercial e os benefícios das soluções baseadas em ML quase em tempo real estejam bem estabelecidos, a arquitetura necessária para implementar essas soluções em escala com confiabilidade e desempenho ideais é complicada. Este post descreve como você pode combinar Amazon Kinesis, Cola AWS e Amazon Sage Maker para construir uma solução de engenharia de recursos e inferência quase em tempo real para manutenção preditiva.

Visão geral do caso de uso

Nós nos concentramos em um caso de uso de manutenção preditiva em que os sensores implantados em campo (como equipamentos industriais ou dispositivos de rede) precisam ser substituídos ou retificados antes que se tornem defeituosos e causem tempo de inatividade. O tempo de inatividade pode ser caro para as empresas e pode levar a uma experiência ruim do cliente. A manutenção preditiva alimentada por um modelo ML também pode ajudar a aumentar os ciclos regulares de manutenção baseados em cronograma, informando quando uma peça da máquina em boas condições não deve ser substituída, evitando assim custos desnecessários.

Neste post, nos concentramos em aplicar o aprendizado de máquina a um conjunto de dados sintético contendo falhas de máquina devido a recursos como temperatura do ar, temperatura do processo, velocidade de rotação, torque e desgaste da ferramenta. O conjunto de dados usado é proveniente do Repositório de Dados UCI.

A falha da máquina consiste em cinco modos de falha independentes:

• Falha de Desgaste da Ferramenta (TWF)
• Falha de dissipação de calor (HDF)
• Falha de energia (PWF)
• Falha por sobretensão (OSF)
• Falha Aleatória (RNF)

A etiqueta de falha da máquina indica se a máquina falhou para um determinado ponto de dados se algum dos modos de falha anteriores for verdadeiro. Se pelo menos um dos modos de falha for verdadeiro, o processo falha e o rótulo de falha da máquina é definido como 1. O objetivo do modelo de ML é identificar as falhas da máquina corretamente, para que uma ação de manutenção preditiva downstream possa ser iniciada.

Visão geral da solução

Para nosso caso de uso de manutenção preditiva, assumimos que os sensores do dispositivo transmitem várias medições e leituras sobre as peças da máquina. Nossa solução então pega uma fatia de dados de streaming a cada vez (micro-lote) e executa o processamento e a engenharia de recursos para criar recursos. Os recursos criados são usados ​​para gerar inferências de um modelo de ML treinado e implantado quase em tempo real. As inferências geradas podem ser processadas e consumidas por aplicativos downstream, para tomar as ações apropriadas e iniciar a atividade de manutenção.

O diagrama a seguir mostra a arquitetura de nossa solução geral.

A solução consiste amplamente nas seguintes seções, que são explicadas em detalhes mais adiante neste post:

• Fonte e ingestão de dados de streaming - Nós usamos Fluxos de dados do Amazon Kinesis para coletar dados de streaming dos sensores de campo em escala e disponibilizá-los para processamento adicional.
• Engenharia de recursos quase em tempo real – Usamos trabalhos de streaming do AWS Glue para ler dados de um stream de dados do Kinesis e realizar processamento de dados e engenharia de recursos, antes de armazenar os recursos derivados em Serviço de armazenamento simples da Amazon (Amazônia S3). O Amazon S3 oferece uma opção confiável e econômica para armazenar grandes volumes de dados.
• Treinamento e implantação do modelo - Usamos o conjunto de dados de manutenção preditiva AI4I do UCI Data Repository para treinar um modelo de ML baseado no algoritmo XGBoost usando o SageMaker. Em seguida, implantamos o modelo treinado em um endpoint de inferência assíncrona do SageMaker.
• Inferência de ML quase em tempo real – Depois que os recursos estiverem disponíveis no Amazon S3, precisamos gerar inferências do modelo implantado quase em tempo real. Os endpoints de inferência assíncrona do SageMaker são adequados para esse requisito porque oferecem suporte a tamanhos de carga útil maiores (até 1 GB) e podem gerar inferências em minutos (até um máximo de 15 minutos). Usamos notificações de eventos do S3 para executar um AWS Lambda para invocar um endpoint de inferência assíncrona do SageMaker. Os endpoints de inferência assíncrona do SageMaker aceitam locais do S3 como entrada, geram inferências do modelo implantado e gravam essas inferências de volta no Amazon S3 quase em tempo real.

O código-fonte desta solução está localizado em GitHub. A solução foi testada e deve ser executada em us-east-1.

Nós usamos um Formação da Nuvem AWS modelo, implantado usando Modelo de aplicativo sem servidor da AWS (AWS SAM) e notebooks SageMaker para implantar a solução.

Pré-requisitos

Para começar, como pré-requisito, você deve ter o CLI SAM, Python 3 e PIP instalado. Você também deve ter o Interface de linha de comando da AWS (AWS CLI) configurado corretamente.

Implante a solução

Você pode usar AWS CloudShell para executar essas etapas. O CloudShell é um shell baseado em navegador que é pré-autenticado com suas credenciais do console e inclui ferramentas comuns de desenvolvimento e operações pré-instaladas (como AWS SAM, AWS CLI e Python). Portanto, nenhuma instalação ou configuração local é necessária.

• Começamos criando um bucket do S3 onde armazenamos o script para nosso trabalho de streaming do AWS Glue. Execute o seguinte comando em seu terminal para criar um novo bucket:

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

• Anote o nome do bucket criado.

• Em seguida, clonamos o repositório de código localmente, que contém o modelo do CloudFormation para implantar a pilha. Execute o seguinte comando no seu terminal:

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

• Navegue até o diretório sam-template:

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

• Execute o seguinte comando para copiar o script de trabalho do AWS Glue (de glue_streaming/app.py) para o bucket do S3 que você criou:

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

• Agora você pode prosseguir com a construção e implantação da solução, por meio do modelo CloudFormation via AWS SAM. Execute o seguinte comando:

sam deploy --guided

• Forneça argumentos para a implantação, como o nome da pilha, a região da AWS preferida (us-east-1), E GlueScriptsBucket.

Certifique-se de fornecer o mesmo bucket do S3 que você criou anteriormente para o bucket do S3 do script do AWS Glue (parâmetro GlueScriptsBucket na captura de tela a seguir).

Depois de fornecer os argumentos necessários, o AWS SAM inicia a implantação da pilha. A captura de tela a seguir mostra os recursos criados.

Depois que a pilha for implantada com êxito, você deverá ver a seguinte mensagem.

• No console do AWS CloudFormation, abra a pilha (para esta postagem, nrt-streaming-inference) que foi fornecido ao implantar o modelo do CloudFormation.
• No Recursos guia, observe o ID da instância do notebook SageMaker.

• No console do SageMaker, abra esta instância.

A instância do notebook SageMaker já tem os notebooks necessários pré-carregados.

Navegue até a pasta de notebooks e abra e siga as instruções dentro dos notebooks (Data_Pre-Processing.ipynb e ModelTraining-Evaluation-and-Deployment.ipynb) para explorar o conjunto de dados, realizar pré-processamento e engenharia de recursos e treinar e implantar o modelo em um endpoint de inferência assíncrona do SageMaker.

Fonte e ingestão de dados de streaming

O Kinesis Data Streams é um serviço de streaming de dados em tempo real sem servidor, escalável e durável que você pode usar para coletar e processar grandes streams de registros de dados em tempo real. O Kinesis Data Streams permite capturar, processar e armazenar fluxos de dados de várias fontes, como dados de log de infraestrutura de TI, logs de aplicativos, mídia social, feeds de dados de mercado, dados de fluxo de cliques da Web, dispositivos e sensores de IoT e muito mais. Você pode provisionar um stream de dados do Kinesis no modo sob demanda ou no modo provisionado, dependendo da taxa de transferência e dos requisitos de dimensionamento. Para mais informações, veja Escolhendo o modo de capacidade do fluxo de dados.

Para nosso caso de uso, assumimos que vários sensores estão enviando medições como temperatura, velocidade de rotação, torque e desgaste da ferramenta para um fluxo de dados. O Kinesis Data Streams atua como um funil para coletar e ingerir fluxos de dados.

Usamos o Gerador de dados do Amazon Kinesis (KDG) posteriormente nesta postagem para gerar e enviar dados para um stream de dados do Kinesis, simulando dados sendo gerados por sensores. Os dados do fluxo de dados sensor-data-stream são ingeridos e processados ​​usando um trabalho de streaming do AWS Glue, que discutiremos a seguir.

Engenharia de recursos quase em tempo real

Trabalhos de streaming do AWS Glue fornecem uma maneira conveniente de processar dados de streaming em escala, sem a necessidade de gerenciar o ambiente de computação. O AWS Glue permite que você execute operações de extração, transformação e carregamento (ETL) em dados de streaming usando trabalhos em execução contínua. O ETL de streaming do AWS Glue é criado no mecanismo Apache Spark Structured Streaming e pode ingerir streams do Kinesis, Apache Kafka e Amazon Managed Streaming para Apache Kafka (Amazônia MSK).

O trabalho de ETL de streaming pode usar transformações internas do AWS Glue e transformações nativas do Apache Spark Structured Streaming. Você também pode usar o Spark ML e MLLib bibliotecas em tarefas do AWS Glue para facilitar o processamento de recursos usando bibliotecas auxiliares prontamente disponíveis.

Se o esquema da fonte de dados de streaming for pré-determinado, você poderá especificá-lo em uma tabela do AWS Data Catalog. Se a definição do esquema não puder ser determinada antecipadamente, você poderá habilitar a detecção de esquema no trabalho de ETL de streaming. O trabalho determina automaticamente o esquema dos dados recebidos. Além disso, você pode usar o Registro de esquema AWS Glue para permitir descoberta central, controle e evolução de esquemas de fluxo de dados. Você pode integrar ainda mais o Schema Registry com o Data Catalog para usar opcionalmente esquemas armazenados no Schema Registry ao criar ou atualizar tabelas ou partições do AWS Glue no Data Catalog.

Para esta postagem, criamos uma tabela do AWS Glue Data Catalog (sensor-stream) com nosso fluxo de dados do Kinesis como origem e defina o esquema para nossos dados de sensor.

Criamos um dataframe dinâmico do AWS Glue a partir da tabela do Data Catalog para ler os dados de streaming do Kinesis. Também especificamos as seguintes opções:

• Um tamanho de janela de 60 segundos, para que o trabalho do AWS Glue leia e processe dados em janelas de 60 segundos
• A posição inicial TRIM_HORIZON, para permitir a leitura dos registros mais antigos no stream de dados do Kinesis

Também usamos Spark MLlib's StringIndexer transformador de recursos para codificar o tipo de coluna de string em índices de rótulo. Essa transformação é implementada usando o Spark ML Pipelines. Pipelines Spark ML fornecem um conjunto uniforme de APIs de alto nível para algoritmos de ML para facilitar a combinação de vários algoritmos em um único pipeline ou fluxo de trabalho.

Usamos a API foreachBatch para invocar uma função chamada processBatch, que por sua vez processa os dados referenciados por esse dataframe. Veja o seguinte código:

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

A função processBatch executa as transformações especificadas e particiona os dados no Amazon S3 com base no ano, mês, dia e ID do lote.

Também particionamos novamente as partições do AWS Glue em uma única partição para evitar ter muitos arquivos pequenos no Amazon S3. Ter vários arquivos pequenos pode prejudicar o desempenho da leitura, porque amplifica a sobrecarga relacionada à busca, abertura e leitura de cada arquivo. Finalmente, escrevemos os recursos para gerar inferências em um prefixo (recursos) no bucket do S3. Veja o seguinte código:

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

Treinamento e implantação de modelo

O SageMaker é um serviço de ML totalmente gerenciado e integrado que permite que cientistas de dados e engenheiros de ML criem, treinem e implantem modelos de ML de maneira rápida e fácil.

No notebook Data_Pre-Processing.ipynb, primeiro importamos o conjunto de dados AI4I Predictive Maintenance do UCI Data Repository e realizamos a análise exploratória de dados (EDA). Também realizamos engenharia de recursos para tornar nossos recursos mais úteis para treinar o modelo.

Por exemplo, dentro do conjunto de dados, temos um recurso chamado type, que representa o tipo de qualidade do produto como L (baixo), M (médio) ou H (alto). Como esse é um recurso categórico, precisamos codificá-lo antes de treinar nosso modelo. Usamos o LabelEncoder da Scikit-Learn para conseguir isso:

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

Depois que os recursos são processados ​​e os conjuntos de dados de treinamento e teste selecionados são gerados, estamos prontos para treinar um modelo de ML para prever se a máquina falhou ou não com base nas leituras do sistema. Treinamos um modelo XGBoost, usando o algoritmo integrado SageMaker. XGBoostName pode fornecer bons resultados para vários tipos de problemas de ML, incluindo classificação, mesmo quando as amostras de treinamento são limitadas.

Trabalhos de treinamento do SageMaker fornecem uma maneira poderosa e flexível de treinar modelos de ML no SageMaker. O SageMaker gerencia a infraestrutura de computação subjacente e fornece várias opções para escolher, para diversos requisitos de treinamento de modelo, com base no caso de 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 o treinamento do modelo estiver concluído e a avaliação do modelo for satisfatória com base nos requisitos de negócios, podemos iniciar a implantação do modelo. Primeiro criamos uma configuração de endpoint com a opção de objeto AsyncInferenceConfig e usando o modelo treinado anteriormente:

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

Em seguida, criamos um endpoint de inferência assíncrona do SageMaker, usando a configuração de endpoint que criamos. Depois de provisionado, podemos começar a invocar o endpoint para gerar inferências de forma assíncrona.

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

Inferência quase em tempo real

SageMaker inferência assíncrona endpoints fornecem a capacidade de enfileirar solicitações de inferência recebidas e processá-las de forma assíncrona quase em tempo real. Isso é ideal para aplicativos que têm solicitações de inferência com tamanhos de carga útil maiores (até 1 GB), podem exigir tempos de processamento mais longos (até 15 minutos) e têm requisitos de latência quase em tempo real. A inferência assíncrona também permite que você economize custos ao dimensionar automaticamente a contagem de instâncias para zero quando não houver solicitações a serem processadas, de modo que você só pague quando seu endpoint estiver processando solicitações.

Você pode criar um endpoint de inferência assíncrona do SageMaker semelhante a como você cria um endpoint de inferência em tempo real e especificar adicionalmente o AsyncInferenceConfig objeto, ao criar sua configuração de endpoint com o campo EndpointConfig na API CreateEndpointConfig. O diagrama a seguir mostra o fluxo de trabalho de inferência e como um endpoint de inferência assíncrona gera uma inferência.

Para invocar o endpoint de inferência assíncrona, a carga útil da solicitação deve ser armazenada no Amazon S3 e a referência a essa carga precisa ser fornecida como parte da solicitação InvokeEndpointAsync. Após a chamada, o SageMaker enfileira a solicitação para processamento e retorna um identificador e um local de saída como resposta. Ao processar, o SageMaker coloca o resultado no local do Amazon S3. Você pode optar por receber notificações de sucesso ou erro com Serviço de notificação simples da Amazon (Amazônia SNS).

Teste a solução de ponta a ponta

Para testar a solução, conclua as seguintes etapas:

• No console do AWS CloudFormation, abra a pilha que você criou anteriormente (nrt-streaming-inference).
• No Saídas guia, copie o nome do bucket do S3 (EventsBucket).

Este é o bucket do S3 no qual nosso trabalho de streaming do AWS Glue grava recursos após a leitura e o processamento do fluxo de dados do Kinesis.

Em seguida, configuramos notificações de eventos para esse bucket do S3.

• No console do Amazon S3, navegue até o bucket EventsBucket.
• No Propriedades guia, no Notificações de eventos seção, escolha Criar notificação de evento.

• Escolha Nome do evento, entrar invoke-endpoint-lambda.
• Escolha Prefixo, entrar features/.
• Escolha Sufixo, entrar .csv.
• Escolha Tipos de eventos, selecione Todos os eventos de criação de objetos.

• Escolha Destino, selecione Função lambda.
• Escolha Função lambda, e escolha a função invoke-endpoint-asynch.
• Escolha Salvar as alterações .

• No console do AWS Glue, abra o trabalho GlueStreaming-Kinesis-S3.
• Escolha Executar trabalho.

Em seguida, usamos o Kinesis Data Generator (KDG) para simular sensores que enviam dados para nosso stream de dados do Kinesis. Se esta é a primeira vez que você usa o KDG, consulte Visão geral para a configuração inicial. O KDG fornece um modelo do CloudFormation para criar o usuário e atribuir permissões suficientes para usar o KDG para enviar eventos ao Kinesis. Execute o Modelo CloudFormation na conta da AWS que você está usando para criar a solução nesta postagem. Depois que o KDG estiver configurado, faça login e acesse o KDG para enviar eventos de teste para nosso stream de dados do Kinesis.

• Use a região na qual você criou o stream de dados do Kinesis (us-east-1).
• No menu suspenso, escolha o fluxo de dados sensor-data-stream.
• No Registros por segundo seção, selecione constante e digite 100.
• Desmarcar Compactar registros.
• Escolha Modelo de registro, use o seguinte modelo:

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

• Clique Enviar dados para começar a enviar dados para o stream de dados do Kinesis.

O trabalho de streaming do AWS Glue lê e extrai um microlote de dados (representando leituras do sensor) do fluxo de dados do Kinesis com base no tamanho da janela fornecido. O trabalho de streaming processa e executa a engenharia de recursos nesse microlote antes de particioná-lo e gravá-lo nos recursos de prefixo no bucket do S3.

À medida que os novos recursos criados pelo trabalho de streaming do AWS Glue são gravados no bucket do S3, uma função do Lambda (invoke-endpoint-asynch) é acionado, que invoca um endpoint de inferência assíncrona do SageMaker enviando uma solicitação de invocação para obter inferências de nosso modelo de ML implantado. O endpoint de inferência assíncrona enfileira a solicitação de chamada assíncrona. Quando o processamento é concluído, o SageMaker armazena os resultados da inferência no local do Amazon S3 (S3OutputPath) que foi especificado durante a configuração do terminal de inferência assíncrona.

Para nosso caso de uso, os resultados da inferência indicam se uma peça da máquina provavelmente falhará ou não, com base nas leituras do sensor.

O SageMaker também envia uma notificação de sucesso ou erro com o Amazon SNS. Por exemplo, se você configurar um assinatura de email para os tópicos de SNS de sucesso e erro (especificados na configuração do ponto de extremidade de inferência assíncrona do SageMaker), um email pode ser enviado sempre que uma solicitação de inferência for processada. A captura de tela a seguir mostra um email de amostra do tópico de sucesso do SNS.

Para aplicativos do mundo real, você pode integrar notificações SNS com outros serviços, como Serviço de fila simples da Amazon (Amazon SQS) e Lambda para pós-processamento adicional das inferências geradas ou integração com outros aplicativos downstream, com base em seus requisitos. Por exemplo, para nosso caso de uso de manutenção preditiva, você pode invocar uma função do Lambda com base em uma notificação do SNS para ler a inferência gerada do Amazon S3, processá-la posteriormente (como agregação ou filtragem) e iniciar fluxos de trabalho, como enviar ordens de serviço para reparação de equipamentos aos técnicos.

limpar

Quando terminar de testar a pilha, exclua os recursos (especialmente o fluxo de dados do Kinesis, o trabalho de streaming do Glue e os tópicos do SNS) para evitar cobranças inesperadas.

Execute o seguinte código para excluir sua pilha:

sam delete nrt-streaming-inference

Exclua também os recursos, como pontos de extremidade do SageMaker, seguindo a seção de limpeza no bloco de anotações ModelTraining-Evaluation-and-Deployment.

Conclusão

Nesta postagem, usamos um caso de uso de manutenção preditiva para demonstrar como usar vários serviços, como Kinesis, AWS Glue e SageMaker, para criar um pipeline de inferência quase em tempo real. Nós encorajamos você a experimentar esta solução e nos dizer o que você pensa.

Se você tiver alguma dúvida, compartilhe-a nos comentários.

Sobre os autores

Rahul Sharma é arquiteto de soluções no AWS Data Lab, ajudando os clientes da AWS a projetar e criar soluções de IA/ML. Antes de ingressar na AWS, Rahul passou vários anos no setor financeiro e de seguros, ajudando clientes a criar plataformas analíticas e de dados.

Pat Reilly é arquiteto no AWS Data Lab, onde ajuda os clientes a projetar e criar cargas de trabalho de dados para dar suporte a seus negócios. Antes da AWS, Pat foi consultor de um parceiro da AWS, criando cargas de trabalho de dados da AWS em vários setores.