O Poder dos Grafos: Como o Itaú Inovou ao Basear Sua Base de Bilhões de Documentos de Clientes no HAQM Neptune Para Realizar Buscas em Milissegundos

Por Roberto Perillo, arquiteto de soluções enterprise da AWS Brasil; Andressa Fernandes, Staff Engineer do Itaú-Unibanco S.A. e Thiago Wagner Caleme, Group Tech Manager do Itaú-Unibanco S.A.

Neste blog post, exploramos a solução adotada no IU Docs, o sistema do Itaú responsável por informações referentes a documentos de clientes e como eles se relacionam. Exploramos também o HAQM Neptune, o banco de dados da AWS que armazena dados em formato de grafo, e que desempenha papel fundamental na solução do IU Docs. No momento da escrita deste blog post, o IU Docs, por meio do Neptune, permite efetuar pesquisas referentes a dados de clientes, processos e documentos, em milissegundos em um grafo com mais de dois bilhões de vértices.

Introdução

Soluções de software quase sempre precisam armazenar dados. A primeira opção que normalmente nos vem à mente é o banco de dados relacional. Isso talvez se dê pelo fato de que esses bancos foram os primeiros a serem largamente utilizados na indústria. O primeiro trabalho acadêmico referente ao modelo relacional entitulado “A Relational Model of Data for Large Shared Data Banks” foi publicado em 1970, mas os bancos relacionais começaram a ser massivamente utilizados pela indústria somente no fim da década de 80. E, desde então, é um dos modelos mais utilizados.

Além disso, o modelo relacional nos permite representar inúmeras possibilidades. Por exemplo, no modelo relacional, pode-se representar grafos, chave-valor, famílias de colunas, documentos (atualmente, todos os bancos de dados modernos relacionais oferecem o tipo de dados JSON) e séries temporais. Isso faz com que o modelo relacional seja o modelo mais versátil. A observação é que, ainda que isso seja uma verdade, nem sempre o modelo relacional vai ser o mais adequado para o caso que se tem.

Considerando um caso em que estejamos representando um grafo, se o grafo for representado em uma única tabela, as pesquisas começarão a apresentar lentidão tão logo a tabela tenha alguns milhares de registros. Em um caso em que o problema seja inerentemente referente a chave-valor, o HAQM DynamoDB permite recuperar registros na casa do dígito único de milissegundo quando a recuperação do registro se dá por meio da chave primária, não importando a quantidade de ítens na tabela, o que dará uma performance melhor do que o modelo relacional quase 100% do tempo.

Na AWS, acreditamos na ideia de bancos de dados de propósito específico. Cada banco de dados possui situações em que seu uso pode ser mais indicado. Por exemplo, ao considerar o DynamoDB, é fundamental modelar os dados de forma a facilitar a recuperação, mas nem sempre isso é possível. Por um lado, ele oferece recuperação de dados a partir da chave primária em um dígito de milissegundo. Por outro, há pesquisas que não são possíveis de serem feitas no DynamoDB, como full-text search, ou que podem ser feitas por meio de GSIs (Global Secondary Indexes), o que aumenta o custo final do DynamoDB.

E uma das situações em que enxergamos grafos na natureza do problema foi o IU Docs. Mas antes de falarmos sobre o IU Docs, vamos explorar a ideia de grafos e como o Neptune funciona.

Grafo Como Estrutura de Dados

Ainda que não vejamos, os grafos estão presentes o tempo todo nas nossas vidas. De fato, na nossa indústria, há casos que estão mais relacionados a grafos, mas por uma simples questão de convenção. Por exemplo, casos que naturalmente relacionamos a grafos incluem detecção de fraudes, redes sociais e perfis de clientes, mas isso não significa que os grafos se limitem a esses casos. Se pararmos para pensar, os relacionamentos entre quaisquer coisas que existam no universo podem ser representado por meio de grafos.

Um grafo é uma estrutura matemática criada pelo matemático Leonhard Euler, em 1736, e o que o motivou foi O Problema das Sete Pontes de Königsberg. O problema era: em algum momento da década de 1730, alguém lançou o seguinte desafio: seria possível fazer um passeio por Königsberg passando por todas as pontes, mas passando somente uma vez por cada uma das sete pontes?

Foi então que, para resolver esse problema, Euler criou a Teoria dos Grafos, e provou que tal passeio não era possível, pois o local não tinha as características necessárias. Para que o passeio fosse possível, deveria haver zero ou dois pontos de terra (que seriam os pontos de início e fim do passeio) de onde saíssem um número ímpar de pontes, o que não era o caso de Königsberg. Denomina-se Caminho Euleriano o percurso em um grafo em que todas as arestas são percorridas exatamente uma vez.

Um grafo G(V, E) é um conjunto não vazio de vértices, que podem possuir metadados e que se relacionam a outros vértices por meio de arestas. As arestas também podem possuir metadados, e podem ou não ser direcionadas. Os vértices representam abstrações do mundo real, como usuários em uma aplicação, documentos, livros, discos ou instrumentos musicais, por exemplo, e as arestas representam as relações entre essas abstrações. No exemplo abaixo, temos um grafo não direcionado que representa como poderiam ser os relacionamentos entre bandas, músicos e seus respectivos instrumentos.

Figura 1. Um grafo em que são ilustrados os relacionamentos entre bandas, músicos e seus respectivos instrumentos.

No grafo de exemplo apresentado acima, podemos inferir algumas informações sobre as bandas e os músicos ilustrados. Por exemplo, Jimmy Page começou a tocar com a Gibson Les Paul Standard em 1969, e no Led Zeppelin em 1968, então, a primeira guitarra que ele usou no Led Zeppelin não era uma Gibson (foi uma Fender Telecaster). David Gilmour entrou no Pink Floyd somente dois anos depois da fundação do Pink Floyd, substituindo Syd Barret. A escolha dos vértices, quais serão suas propriedades, a ligação entre os vértices e as propriedades dessas ligações depende muito do que se quer representar. No grafo acima, poderíamos ter também vértices para representar os discos de cada banda, por exemplo.

Provavelmente, os leitores mais inclinados ao SQL devem estar dizendo algo como “eu consigo representar a mesma estrutura em um banco de dados relacional”, e isso é verdade. O detalhe é que representar a mesma estrutura em um modelo relacional seria muito mais “burocrático”. Precisaríamos ter tabelas para representar bandas, músicos, países, estilos musicais, guitarras e gêneros de rock, mais várias outras para representar as relações entre as abstrações e suas propriedades. E se quiséssemos adicionar os discos das bandas, precisaríamos de ainda mais tabelas para representar os discos e suas relações. Representar como abstrações se relacionam se torna muito mais fácil no modelo de grafos.

Outra questão que poderemos ter diz respeito a performance. Por exemplo, se quisermos representar em uma tabela no modelo relacional uma estrutura de “pais e filhos” (como uma árvore de diretórios, por exemplo), poderíamos ter uma chave estrangeira referenciando a chave primária da própria tabela, o que implicaria em queries recursivas, que tem performance ruim nos bancos relacionais já quando a tabela tem alguns milhares de registros. Ou precisaríamos modelar o banco como mencionado acima, com uma tabela para cada abstração e n tabelas para representar os relacionamentos entre as abstrações e as propriedades desses relacionamentos, e caso quiséssemos adicionar outras propriedades aos relacionamentos, precisaríamos também alterar as estruturas das tabelas. Ou seja, lidar com os relacionamentos no modelo relacional é muito mais complexo.

Grafos são particularmente úteis quando queremos extrair conhecimento das abstrações do mundo real por meio dos relacionamentos entre essas abstrações. É por isso que grafos têm uma aderência tão grande a casos como prevenção a fraudes ou redes sociais. Por meio de grafos, podemos responder perguntas como: quem são os amigos dos meus amigos? Quais produtos os compradores de um determinado produto também compraram? Qual o melhor caminho entre dois pontos? Como um dado conjunto de microservices está organizado? Quais produtos os compradores de um dado produto também visualizaram? Quais aplicações seriam impactadas se um dado componente ficasse fora? Em quais jogos um determinado gamer deu like? Quais guitarristas, além de mim, gostam de Led Zeppelin?

Um autor e pesquisador que fez contribuições extremamente relevantes a Teoria dos Grafos foi Edsger Dijkstra, que ganhou o Turing Award de 1972 por diversas contribuições à ciência da computação, entre elas O Algoritmo de Dijkstra, que permite encontrar o caminho mais curto entre dois pontos em um grafo. Por exemplo, poderíamos ter em um grafo n vértices representando esquinas em uma cidade e arestas representando as ruas que levam a essas esquinas. As arestas poderiam ter propriedades que representariam as distâncias entre cada esquina e, aplicando o Algoritmo de Dijkstra, poderíamos encontrar o caminho mais curto entre duas esquinas quaisquer dessa cidade.

Há diversos algoritmos que podem ser aplicados a um determinado grafo, como algoritmos de centralidade e similaridade, mas duas categorias que se destacaram na academia são os algoritmos de busca em largura (ou BFS, Breadth-First Search) e os de busca em profundidade (ou DFS, Depth-First Search). No caso do algoritmo proposto por Dijkstra, o caminho mais curto é encontrado utilizando-se pesos nas arestas, enquanto na busca em largura pode-se encontrar o menor caminho sem pesos nas arestas. Então, o algoritmo de Dijkstra encontra o caminho de menor peso entre dois pontos, enquanto o algoritmo de BFS encontra o de menor quantidade de arestas entre dois pontos.

O BFS visita um vértice inicial, depois os vértices vizinhos, depois os vizinhos dos vizinhos, e assim por diante. O DFS visita um vértice inicial, depois um vértice vizinho, depois o vizinho do vizinho, e assim por diante até não haver mais nós a serem visitados no caminho percorrido. O valor do BFS está na descoberta de caminhos mínimos, enquanto o DFS está na detecção de ciclos no grafo, o que é útil em diversas situações, como deteção de fraudes, por exemplo.

HAQM Neptune: O Banco de Dados da AWS Orientado a Grafos

Para problemas em que as informações possuem dados e conexões, e as conexões em si também possuem metadados, o banco de dados da AWS é o HAQM Neptune. O Neptune é um serviço totalmente gerenciado pela AWS que suporta criptografia em repouso e em trânsito, possui integração com outros serviços da AWS, pode ser utilizado de forma global e é otimizado para que seja possível encontrar informações na ordem de milissegundos em grafos que possuam bilhões de dados.

Para o armazenamento dos dados, o Neptune suporta dois formatos de grafos, que são os baseados em propriedades e os baseados em URIs. No formato de propriedades, pode-se utilizar as linguagens de query Gremlin, do Apache TinkerPop (o framework, ou conjunto de artefatos, para se trabalhar com grafos baseados em propriedades, como o Gremlin Server, a linguagem Gremlin e drivers JDBC) e openCypher. O formato de URIs pode ser criado utilizando-se RDF e pode-se utilizar a linguagem de query SPARQL para a realização de consultas.

O Neptune também oferece a possibilidade de realização de backups contínuos e, assim como nos bancos de dados do HAQM RDS, também é possível se trabalhar com até 15 réplicas de leitura e endpoints customizados. Um cluster Neptune é formado pela instância de escrita, até 15 réplicas de leitura, e o volume de escrita, distribuído em 3 AZs. E assim como acontece com o HAQM Aurora, o armazenamento também é externo às instâncias do cluster Neptune, o que permite que a capacidade de computação e armazenamento sejam escalados de forma independente um do outro.

Fazem parte da família Neptune o HAQM Neptune Database, HAQM Neptune ML, que é a integração entre o Neptune e o HAQM Sagemaker e que torna possível utilizar redes neurais baseadas em grafos, em conjunto com a Deep Graph Library ou o GraphStorm, para realizar previsões em tempo real na medida que os dados são inseridos no Neptune Database, e o HAQM Neptune Analytics, que foi anunciado no re:Invent de 2023.

Enquanto o Neptune Database tem os recursos de um cluster, armazenamento, backups e réplicas de leitura, o Neptune Analytics armazena grafos em memória de forma a favorecer análises nesses grafos por meio de algoritmos como clustering, similarity, centrality, path finding e vector similarity. Através de um único endpoint, é possível criar um grafo, carregá-lo e executar queries analíticas. No momento da escrita deste blog post, somente o openCypher é suportado como linguagem de query pelo Neptune Analytics. E pelo fato de que o Neptune Analytics é otimizado para cargas de trabalho analíticas, ele oferece alta velocidade para carregamento e leitura de dados.

O Neptune Analytics é uma das opções para armazenamento de embeddings, utilizados em knowledge bases do HAQM Bedrock, que é o recurso do Bedrock que permite a técnica de Retrieval-Augmented Generation. Ou seja, o Neptune Analytics também pode ser utilizado como um vector database, que são bancos de dados que armazenam embeddings. Um embedding codifica um determinado dado (estruturado ou não) como um vetor de n dimensões (no caso do Neptune Analytics, até 65.535 dimensões) de valores reais, o que permite representar diversas características desse dado (que pode ser uma palavra, por exemplo), como significado e semântica.

O Projeto IU Docs

O projeto surgiu no Itaú em 2015 com a necessidade de centralizar os repositórios com os documentos de clientes e melhorar a jornada de contratação de novos produtos, além de garantir um reuso dos documentos enviados pelos clientes.

O IU Docs é a solução de Gestão de Documentos e Conteúdos (ECM: Enterprise Content Management) do Itaú que atende a uma gama jornadas e produtos, e visa melhorar a guarda segura e assertiva na busca de conteúdos para nossos consumidores (atendimento, backoffice, agências, jurídico e auditoria). O objetivo do produto é ter maior centralidade no cliente, por meio de melhores indexações dos conteúdos e melhor qualidade dos dados armazenados.

No IU Docs, o conteúdo é definido como a combinação de um documento (seja ele eletrônico, físico ou digital) e seus metadados. O documento contém a informação principal, enquanto os metadados fornecem detalhes adicionais que facilitam a busca, categorização e gerenciamento do documento.

Na arquitetura inicial, inclusive pelas características dos dados em serem muito ligados, optou-se pelo modelo relacional, que atendeu bem a necessidade até então.

Em 2023, a equipe do IU Docs enfrentou o desafio de modernizar a plataforma, incluindo a melhoria da experiência do usuário, a implementação de funcionalidades avançadas de busca e categorização como uma visão cliente e taxonômica, e o aumento da segurança e conformidade dos dados armazenados.

Foi construída uma nova arquitetura baseada em eventos e CQRS (Command Query Responsibility Segregation), mantendo os dados transacionais em um DynamoDB e especializando as pesquisas em um banco apartado, uma vez que temos mais de 250 metadados diferentes para indexação e a base é viva.

Além da indexação do conteúdo em si na plataforma, também se indexa onde ele está sendo utilizado no banco e qual é o processo (jornada interna) responsável por ele. O processo também possui os próprios metadados que podem ou não serem os mesmos que os do conteúdo.

A plataforma oferece três tipos de pesquisa: a pesquisa visão conteúdo, a pesquisa visão processo e a visão cliente. A pesquisa visão conteúdo recebe os parâmetros de tipo conteúdo e em quais metadados do conteúdo a pesquisa vai se basear. Analogamente, a pesquisa visão processos recebe o tipo do processo e os metadados do processo. Por fim, a pesquisa visão cliente recebe apenas a indexação do cliente e retorna todos os conteúdos e processos que esse cliente possui indexado.

A Arquitetura do IU Docs

O fluxo dos conteúdos na plataforma começa pela captura do conteúdo. As responsabilidades são divididas entre contas AWS que representam cada domínio funcional da jornada. No caso do IU Docs, os domínios são Captura, Gerenciamento, Busca e Recuperação, como mostra o desenho da solução abaixo.

Figura 2. A Arquitetura do IU Docs.

A API de Captura recebe um payload (1) com informações do conteúdo, como tipo do conteúdo, metadados, processo, quantidade de arquivos. A API armazena essas informações em uma tabela DynamoDB. Após a informação do conteúdo, o usuário envia individualmente as informaçoes dos arquivos (3) tais quais o tipo do arquivo, mimetype, SHA-256 e a API devolve a URL pré-assinada do S3 (5) para a realização do upload do binário direto no bucket.

Uma vez que o binário é recebido, inicia-se um processo de validação do arquivo (6). Uma função Lambda valida se o mimetype é válido e dentro do domínio de mimetypes aceitos, o hash do arquivo para garantir a integridade, entre outras validações. Quando o arquivo é aprovado, atualiza-se o status do conteúdo e arquivo dentro da tabela e o binário é transferido do S3 de Staging para o S3 de replicação (7). Quando o status é atualizado, um stream do DynamoDB Streams disponibiliza um evento para uma função Lambda (8) e essa função envia o JSON com todas as informações do conteúdo e arquivo para um Kafka corporativo (mandate de comunicação cross account dentro do Itaú) para replicar os dados para a conta de Manager.

A conta de Management é o repositório final dos dados, seja o binário quanto os dados lógicos. Essa conta é responsável por todo o ciclo de vida do conteúdo, seja atualização de dados via API, ciclo de vida no S3 até eventual expurgo. Ela também é responsável pelos conteúdos que precisam passar por algum tipo de conferência. Uma vez que o evento é postado no Kafka corporativo, uma função Lambda (9) é disparada e essa função armazena os dados em uma nova tabela DynamoDB. Através de um DynamoDB Streams (10), os conteúdos ativos são filtrados e enviados para a conta de Search através de outro Kafka corporativo.

A conta de Search é responsável pelo fluxo final dessa jornada, que são a busca e recuperação dos conteúdos armazenados na plataforma. A função Lambda neptune-sync (11) recebe os eventos dos conteúdos ativos, e armazena os dados no Neptune. Através da API de Pesquisa (12), é possível fazer a recuperação dos dados. Para recuperar os binários, utilizamos o HAQM Cloudfront (13). Optamos pelo uso do Cloudfront para termos o mesmo padrão de URL assinada seja para os binários existentes no S3 (fluxo atual) quanto para os binários existentes nos repositórios legados (ambiente Itaú) que não são compatíveis com URL pré-assinada, integrando-se via API.

Ajustes Realizados no Dimensionamento do Cluster

Quando o Neptune subiu inicialmente, estimou-se para o fluxo inicial 3 maquinas db.r5.2xlarge. A medida que a ingestão de dados aumentou na conta (4MM por dia), foram recuperadas a partir do HAQM CloudWatch algumas métricas de tempo de inserção e constatou-se que o tempo de inserção em alto volume havia aumentado drasticamente em relação a quando o número de inserts era baixo.

Figura 3. Instância de escrita com baixo número de inserts.

Com uma instância de escrita do tipo db.r5.2xlarge, o tempo de inserção de cada nó com 800 funções Lambda em paralelo (fluxo de 4MM por dia) era de mais de 3 segundos, ou seja, em um baixo volume de escrita, o tempo médio era de 0.4 segundos, e em alto volume de escrita, o tempo passou para mais de 3 segundos.

Figura 4. Instância de escrita com alto volume de inserts.

Diante disso, optou-se por aumentar o poder de processamento da máquina de escrita para uma máquina db.r5d.4xlarge. Depois do aumento, o tempo de inserção de cada nó com até 800 funções Lambda em paralelo (fluxo de 14MM por dia) passou para menos de 0,1 segundo.

Figura 5. Instância de escrita com alto volume de inserts após recapacity.

A Motivação Pelo Uso do HAQM Neptune

Inicialmente, foram estudados alguns bancos de dados para facilitar nos conceitos de pesquisa, e a equipe do IU Docs se aprofundou no HAQM Opensearch, principalmente pelo poder de indexação do texto.

Dados esses cenários, calculou-se a infraestrutura que seria necessária para o Opensearch. O Opensearch precisa de shards de até 30 Gb para se ter uma boa performance e baixa latência. Com isso, seria necessário um cluster com mais de 190 servidores pela volumetria. O hard limit de um cluster é de 200 servidores, além do custo que se teria com a infraestrutura.

Foi feito um levantamento entre as principais soluções que poderiam atender às necessidades do projeto, o que resultou na tabela abaixo, com comparativos entre as features e tecnologias (dados de 2023).

Figura 6. Um comparativo entre as opções de bancos de dados para o IU Docs.

Figura 7. Um comparativo de preços entre as opções de bancos de dados para o IU Docs.

Após discussões com o nosso time de engenharia e com o apoio da AWS, chegou-se a escolha pelo Neptune. O Neptune é a escolha devido ao alto poder de indexação das propriedades, diferentes tipos de vértices e alto grau de relacionamento das informações dos documentos, além de ser uma opção muito mais econômica. Optou-se por se utilizar um grafo baseado em propriedades, o que possibilita a pesquisa de dados no grafo por meio da linguagem Gremlin.

O Grafo do IU Docs

O schema do grafo do IU Docs é definido da seguinte forma:

Figura 8. O schema do grafo do IU Docs.

Por exemplo, em uma abertura de conta, é necessário se recepcionar documentos como RG – documento de identificação, comprovante de endereço e o contrato de abertura de conta.

Então, pode-se indexar o RG com metadados como tipo do conteúdo, número do RG, número do CPF, nome da mãe, nome do cliente, data de emissão e data de validade, enquanto o processo a que esse RG foi atrelado terá informações como tipo do processo, número de proposta de abertura de conta, número da agência, número da conta, número do banco e número do CPF do cliente.

No caso de um contrato de abertura de conta, pode-se indexar metadados como tipo de conteúdo, número de proposta de abertura de conta, número da agência, número da conta, número do banco, número do CPF do cliente, os mesmos metadados que são indexados no processo.

Com os dados em cada vértice, o grafo poderia ser representado da seguinte forma:

Figura 9. O grafo do IU Docs, com exemplos de dados para cada vértice.

Conclusão

Este blog post apresenta o projeto IU Docs, que é o sistema responsável pela gestão de documentos de clientes no Itaú. Este é um projeto que começou em 2015, devido a necessidade de haver um repositório único de documentos de clientes e que oferecesse diversas formas de pesquisas. Inicialmente, o modelo relacional até funcionou, mas logo restrições começaram a aparecer, e que impediram o progresso do projeto, o que demandou uma modernização dos componentes da arquitetura do projeto.

Após uma série de discussões, chegamos ao HAQM Neptune. O Neptune é o banco de dados da AWS orientado a grafos. Grafos são úteis quando queremos inferir informações por meio de como abstrações se relacionam. Hoje, a família HAQM Neptune é composta pelo banco de dados Neptune, o Neptune ML e o Neptune Analytics, que pode ser utilizado como vector database de knowledge bases do HAQM Bedrock.

Pelo fato de que a natureza do IU Docs diz respeito a documentos, processos e clientes, como todos esses conceitos estão relacionados e como os dados precisam ser pesquisados, ele se tornou nossa opção principal de banco de dados. Após a implementação de algumas PoCs, migramos o banco de dados relacional para o Neptune. Hoje, o cluster Neptune do IU Docs possui mais de dois bilhões de vértices, e todas as queries das quatro visões oferecidas pela aplicação podem ser realizadas em milissegundos.

Sobre os Autores
	Roberto Perillo é arquiteto de soluções enterprise da AWS Brasil especialista em serverless, atendendo a clientes da indústria financeira, e atua na indústria de software desde 2001. Atuou por quase 20 anos como arquiteto de software e desenvolvedor Java antes de ingressar na AWS, em 2022. Possui graduação em Ciência da Computação, especialização em Engenharia de Software e mestrado também em Ciência da Computação. Um eterno aprendiz. Nas horas vagas, gosta de estudar, tocar guitarra, e também jogar boliche e futebol de botão com seu filho, Lorenzo!
	Andressa Fernandes é especialista em engenharia pelo Itau Unibanco S.A.. Graduada em Matemática Computacional pela Unifesp. Atua em há 10 anos criando plataformas modernizadas e especializadas em Gestão de Conteúdos.
	Thiago Wagner Caleme atua há 10 anos evoluindo plataformas modernizadas e especializadas em Gestão de Conteúdos, criando produtos digitais combinando tecnologias On Premisses e Cloud. Lidera um time de engenharia de software responsável por criar arquiteturas modernas, desacopladas e escaláveis para suportar toda a volumetria de conteúdos do Banco Itaú. Possui formação em CDIA+ (Certified Document Imaging Architect) e a certificação AWS Certified Solutions Architect – Associate.
Sobre os Revisores
	Erika Nagamine é arquiteta de soluções especialista em Dados na AWS. Tem formação acadêmica sólida, graduada em Sistemas de Informação, com pós graduação em Administração de Banco de Dados, Engenharia de Dados e especialização em mineração de Dados Complexos pela Unicamp. Atua com clientes de diversos segmentos e já participou de mais de 200 projetos no Brasil e no mundo. Atualmente múltiplas certificações em dados, computação em nuvem, todas as certificações AWS, e ama compartilhar conhecimento em comunidades e é palestrante em eventos técnicos de destaque em todo o Brasil e no mundo.
	Luiz Yanai é arquiteto especialista sênior em analytics na AWS atuando com clientes nativos na nuvem e empresas do ramo financeiro en suas jornadas para se tornarem data-driven. Possui quase 20 anos de experiência em arquitetura e desenvolvimento de soluções envolvendo sistemas empresariais e de missão crítica sendo que os últimos 5 anos estão focados na nuvem AWS.