El Poder de los Grafos: Cómo Itaú Innovó al Basar Su Base de Datos de Miles de Millones de Documentos de Clientes en Amazon Neptune Para Realizar Búsquedas en Milisegundos

Por Roberto Perillo, arquitecto de soluciones empresariales en AWS Brasil; Andressa Fernandes, Staff Engineer de Itaú-Unibanco S.A. y Thiago Wagner Caleme, Group Tech Manager de Itaú-Unibanco S.A.

En esta entrada de blog, exploramos la solución adoptada en IU Docs, el sistema de Itaú responsable de la información sobre los documentos de los clientes y su relación. También exploramos Amazon Neptune, la base de datos de AWS que almacena datos en formato grafo y desempeña un papel fundamental en la solución IU Docs. Al momento de escribir este blog post, IU Docs, a través de Neptune, permite realizar búsquedas de datos, procesos y documentos de clientes en milisegundos en un grafo con más de dos mil millones de vértices.

Introducción

Las soluciones de software casi siempre requieren almacenar datos. La primera opción que suele venir a la mente es la base de datos relacional. Esto puede deberse a que estas bases de datos fueron las primeras en utilizarse ampliamente en la industria. El primer artículo académico sobre el modelo relacional, titulado “A Relational Model of Data for Large Shared Data Banks”, se publicó en 1970, pero las bases de datos relacionales no comenzaron a utilizarse ampliamente en la industria hasta finales de la década de 1980. Desde entonces, ha sido uno de los modelos más utilizados.

Además, el modelo relacional permite representar innumerables posibilidades. Por ejemplo, podemos representar grafos, pares clave-valor, familias de columnas, documentos (actualmente, todas las bases de datos relacionales modernas ofrecen el tipo de datos JSON) y series temporales. Esto lo convierte en el modelo más versátil. Cabe destacar que, si bien esto es cierto, no siempre será el más adecuado para el caso en cuestión.

Si representamos un grafo en una sola tabla, las búsquedas comenzarán a ralentizarse en cuanto la tabla tenga varios miles de registros. En caso de que el problema esté inherentemente relacionado con el par clave-valor, Amazon DynamoDB permite recuperar registros en tan solo una fracción de milisegundo cuando se recuperan utilizando la clave principal, independientemente del número de elementos de la tabla, lo que proporciona un rendimiento superior al del modelo relacional casi en el 100 % de los casos.

En AWS, creemos en la idea de bases de datos diseñadas específicamente para cada propósito. Cada base de datos presenta sus propios escenarios donde podría ser más adecuada. Por ejemplo, al considerar DynamoDB, es esencial modelar los datos de forma que faciliten su recuperación, pero esto no siempre es posible.

En cuanto a las capacidades de DynamoDB, por un lado, ofrece la recuperación de datos basada en la clave principal en un solo milisegundo. Por otro lado, existen búsquedas que no son posibles en DynamoDB, como full text search, o que pueden realizarse mediante GSIs (Global Secondary Indexes), lo que aumenta el costo final de DynamoDB.

Uno de los escenarios donde vimos grafos en la naturaleza del problema fue IU Docs. Pero antes de hablar de IU Docs, exploremos el concepto de grafos y cómo funciona Neptune.

El Grafo Como Estructura de Datos

Aunque no lo veamos, los grafos están presentes en nuestras vidas constantemente. De hecho, en nuestro sector, existen casos que se relacionan más con los grafos, por una simple convención. Por ejemplo, los casos que asociamos naturalmente con grafos incluyen la detección de fraudes, las redes sociales y los perfiles de clientes, pero eso no significa que los grafos se limiten a estos. Si nos detenemos a pensarlo, las relaciones entre cualquier cosa que exista en el universo pueden representarse mediante grafos.

Grafo es una estructura matemática creada por el matemático Leonhard Euler en 1736, y su motivación fue el problema de los siete puentes de Königsberg. El problema era que, en algún momento de la década de 1730, alguien planteó el siguiente reto: ¿sería posible recorrer Königsberg pasando por todos los puentes, pero solo una vez por cada uno de ellos?

Fue entonces cuando, para resolver este problema, Euler creó la Teoría de Grafos y demostró que dicho recorrido no era posible, ya que el lugar carecía de las características necesarias. Para que el recorrido fuera posible, tendría que haber cero o dos puntos de tierra (que serían los puntos de inicio y fin del recorrido) desde los que partiera un número impar de puentes, lo cual no era el caso en Königsberg. La ruta en un grafo en la que todas las aristas se recorren exactamente una vez se denomina Ciclo Euleriano.

Un grafo G(V, E) es un conjunto no vacío de vértices, que puede tener metadatos y que se relacionan con otros vértices mediante aristas. Las aristas también pueden tener metadatos y pueden o no estar dirigidas. Los vértices representan abstracciones del mundo real, como usuarios en una aplicación, documentos, libros, discos o instrumentos musicales, por ejemplo, y las aristas representan las relaciones entre estas abstracciones. En el siguiente ejemplo, tenemos un grafo no dirigido que representa cómo podrían ser las relaciones entre bandas, músicos y sus respectivos instrumentos.

Figura 1. Un grafo que ilustra las relaciones entre bandas, músicos y sus respectivos instrumentos.

En el grafo de ejemplo anterior, podemos inferir información sobre las bandas y los músicos ilustrados. Por ejemplo, Jimmy Page empezó a tocar con la Gibson Les Paul Standard en 1969 y con Led Zeppelin en 1968, por lo que la primera guitarra que usó en Led Zeppelin no fue una Gibson (fue una Fender Telecaster). David Gilmour se unió a Pink Floyd tan solo dos años después de su fundación, sustituyendo a Syd Barrett. La elección de los vértices, sus propiedades, la conexión entre ellos y las propiedades de estas conexiones dependen en gran medida de lo que se quiera representar. En el grafo anterior, también podríamos tener vértices para representar los álbumes de cada banda, por ejemplo.

Los lectores más inclinados a SQL probablemente digan algo como: “Puedo representar la misma estructura en una base de datos relacional”, y es cierto. El detalle es que representar la misma estructura en un modelo relacional sería mucho más burocrático. Necesitaríamos tablas para representar bandas, músicos, países, estilos musicales, guitarras y géneros de rock, además de varias más para representar las relaciones entre las abstracciones y sus propiedades. Si quisiéramos añadir los álbumes de las bandas, necesitaríamos aún más tablas para representar los álbumes y sus relaciones. Representar cómo se relacionan las abstracciones entre sí es mucho más sencillo en el modelo de grafos.

Otro problema que podríamos tener es el rendimiento. Por ejemplo, si quisiéramos representar una estructura de “padres e hijos” (como un árbol de directorios, por ejemplo) en una tabla del modelo relacional, podríamos tener una clave foránea que haga referencia a la clave principal de la propia tabla, lo que implicaría consultas recursivas, cuyo rendimiento en bases de datos relacionales es bajo, incluso cuando la tabla tiene varios miles de registros. O necesitaríamos modelar la base de datos como se mencionó anteriormente, con una tabla para cada abstracción y n tablas para representar las relaciones entre las abstracciones y las propiedades de estas relaciones. Si quisiéramos añadir otras propiedades a las relaciones, también necesitaríamos cambiar las estructuras de las tablas. En otras palabras, gestionar las relaciones en el modelo relacional es mucho más complejo.

Los grafos son particularmente útiles cuando queremos extraer conocimiento de abstracciones del mundo real a través de las relaciones entre estas. Por eso son tan útiles en casos como la prevención del fraude o las redes sociales. Mediante grafos, podemos responder a preguntas como: ¿quiénes son los amigos de mis amigos? ¿Qué productos compraron también los compradores de un producto determinado? ¿Cuál es la mejor ruta entre dos puntos? ¿Cómo se organiza un conjunto determinado de microservicios? ¿Qué productos vieron también los compradores de un producto determinado? ¿Qué aplicaciones se verían afectadas si se excluyera un componente determinado? ¿Qué juegos le gustaban a un jugador determinado? ¿A qué guitarristas, además de mí, les gustaba Led Zeppelin?

Un autor e investigador que realizó contribuciones sumamente relevantes a la teoría de grafos fue Edsger Dijkstra, quien ganó el Turing Award en 1972 por varias contribuciones a la informática, incluyendo el algoritmo de Dijkstra, que permite encontrar el camino más corto entre dos puntos en un grafo. Por ejemplo, podríamos tener n vértices en un grafo que representan las esquinas de una ciudad y aristas que representan las calles que conducen a estas esquinas. Las aristas podrían tener propiedades que representen las distancias entre cada esquina y, al aplicar el algoritmo de Dijkstra, podríamos encontrar el camino más corto entre dos esquinas cualesquiera de esa ciudad.

Existen varios algoritmos que se pueden aplicar a un grafo dado, como los de centralidad y similitud, pero dos categorías que han destacado en el ámbito académico son los algoritmos de búsqueda en amplitud (BFS) y de búsqueda en profundidad (DFS). En el caso del algoritmo propuesto por Dijkstra, el camino más corto se encuentra utilizando pesos en las aristas, mientras que en la búsqueda en amplitud se puede encontrar el camino más corto sin pesos en las aristas. Así, el algoritmo de Dijkstra encuentra la ruta con el menor peso entre dos puntos, mientras que el algoritmo BFS encuentra la ruta con el menor número de aristas entre dos puntos.

BFS visita un vértice inicial, luego los vértices vecinos, luego los vecinos de los vecinos, y así sucesivamente. DFS visita un vértice inicial, luego un vértice vecino, luego los vecinos de los vecinos, y así sucesivamente hasta que no queden nodos por visitar en la ruta tomada. El valor de BFS reside en encontrar las rutas más cortas, mientras que DFS reside en detectar ciclos en el grafo, lo cual es útil en diversas situaciones, como por ejemplo, la detección de fraudes.

Amazon Neptune: La Base de Datos Orientada a Grafos de AWS

Para problemas donde la información contiene datos y conexiones, y estas a su vez contienen metadatos, la base de datos de AWS es Amazon Neptune. Neptune es un servicio completamente administrado por AWS que admite cifrado en reposo y en tránsito, se integra con otros servicios de AWS, se puede usar globalmente y está optimizado para encontrar información en milisegundos en grafos con miles de millones de datos.

Para el almacenamiento de datos, Neptune admite dos formatos de grafos: basados en propiedades y basados en URI. En el formato de propiedades, se pueden utilizar los lenguajes de consulta Gremlin, Apache TinkerPop (el marco o conjunto de artefactos para trabajar con grafos basados ​​en propiedades, como Gremlin Server, el lenguaje Gremlin y los controladores JDBC) y OpenCypher. El formato URI se puede crear mediante RDF y se puede utilizar el lenguaje de consulta SPARQL para realizar consultas.

Neptune también ofrece la posibilidad de realizar backups continuos y, al igual que con las bases de datos de Amazon RDS, es posible trabajar con hasta 15 réplicas de lectura y endpoints personalizados. Un cluster de Neptune consta de la instancia de escritura, hasta 15 réplicas de lectura y el volumen de escritura, distribuidos en 3 zonas de disponibilidad (AZ). Al igual que con Amazon Aurora, el almacenamiento también es externo a las instancias del cluster de Neptune, lo que permite escalar la capacidad de computación y almacenamiento de forma independiente.

La familia Neptune incluye Amazon Neptune Database, Amazon Neptune ML (integración entre Neptune y Amazon SageMaker que permite el uso de redes neuronales basadas en grafos, junto con Deep Graph Library o GraphStorm, para realizar predicciones en tiempo real a medida que se insertan datos en Neptune Database) y Amazon Neptune Analytics, anunciado en re:Invent 2023.

Mientras que Neptune Database cuenta con los recursos de un cluster, almacenamiento, copias de seguridad y réplicas de lectura, Neptune Analytics almacena grafos en memoria para facilitar su análisis mediante algoritmos como clusterización, similitud, centralidad, búsqueda de rutas y similitud vectorial. A través de un único endpoint, es posible crear un grafo, cargarlo y ejecutar consultas analíticas. Al momento de escribir este blog post, Neptune Analytics solo admite openCypher como lenguaje de consulta. Además, dado que Neptune Analytics está optimizado para cargas de trabajo analíticas, ofrece alta velocidad de carga y lectura de datos.

Neptune Analytics es una de las opciones para almacenar incrustaciones, utilizada en las bases de conocimiento de Amazon Bedrock. Esta función de Bedrock habilita la técnica de Retrieval-Augmented Generation. En otras palabras, Neptune Analytics también puede utilizarse como base de datos vectorial, es decir, bases de datos que almacenan incrustaciones. Una incrustación codifica un dato (estructurado o no) como un vector n-dimensional (en el caso de Neptune Analytics, hasta 65.535 dimensiones) de valores reales, lo que permite representar diversas características de esos datos (que podrían ser una palabra, por ejemplo), como el significado y la semántica.

El Proyecto IU Docs

El proyecto se creó en Itaú en 2015 con la necesidad de centralizar los repositorios de documentos de los clientes y optimizar el proceso de contratación de nuevos productos, además de garantizar la reutilización de los documentos enviados por los clientes.

IU Docs es la solución de Gestión de Documentos y Contenido (ECM: Gestión de Contenido Empresarial) de Itaú, que abarca diversos procesos y productos, y tiene como objetivo mejorar el almacenamiento seguro y asertivo de las búsquedas de contenido para nuestros clientes (servicio al cliente, back office, agencias, departamento legal y auditoría). El objetivo del producto es una mayor orientación al cliente, mediante una mejor indexación del contenido y una mayor calidad de los datos almacenados.

En IU Docs, el contenido se define como la combinación de un documento (ya sea electrónico, físico o digital) y sus metadatos. El documento contiene la información principal, mientras que los metadatos proporcionan detalles adicionales que facilitan la búsqueda, categorización y gestión del documento.

En la arquitectura inicial, debido a la alta interconexión de los datos, se optó por el modelo relacional, que satisfacía adecuadamente la necesidad hasta entonces.

En 2023, el equipo de IU Docs se enfrentó al reto de modernizar la plataforma, lo que incluyó mejorar la experiencia del usuario, implementar funciones avanzadas de búsqueda y categorización, como una vista de cliente y taxonómica, y aumentar la seguridad y el cumplimiento normativo de los datos almacenados.

Se construyó una nueva arquitectura basada en eventos y CQRS (Command Query Responsibility Segregation), que mantiene los datos transaccionales en una base de datos DynamoDB y especializa las búsquedas en una base de datos independiente, ya que contamos con más de 250 metadatos diferentes para indexar y la base de datos está activa.

Además de indexar el contenido en la plataforma, también indexamos dónde se utiliza en la base de datos y qué proceso (recorrido interno) es responsable de él. El proceso también tiene sus propios metadatos, que pueden coincidir o no con el contenido.

La plataforma ofrece tres tipos de búsqueda: búsqueda de vista de contenido, búsqueda de vista de proceso y búsqueda de vista de cliente. La búsqueda de vista de contenido recibe los parámetros del tipo de contenido y los metadatos del contenido en los que se basará la búsqueda. De igual forma, la búsqueda de vista de proceso recibe el tipo de proceso y sus metadatos. Finalmente, la búsqueda de la vista del cliente recibe únicamente la indexación del cliente y devuelve todo el contenido y los procesos que este ha indexado.

La Arquitectura de IU Docs

El flujo de contenido en la plataforma comienza con la captura de contenido. Las responsabilidades se dividen entre las cuentas de AWS que representan cada dominio funcional del recorrido. En el caso de IU Docs, los dominios son Captura, Gestión, Búsqueda y Recuperación, como se muestra en el diseño de la solución a continuación.

Figura 2. La arquitetura de IU Docs.

La API de captura recibe una carga útil (1) con información de contenido, como el tipo de contenido, los metadatos, el proceso y la cantidad de archivos. La API almacena esta información en una tabla de DynamoDB. Tras proporcionar la información de contenido, el usuario envía individualmente la información del archivo (3), como el tipo de archivo, el tipo MIME y SHA-256, y la API devuelve la URL prefirmada de S3 (5) para cargar el binario directamente al bucket.

Una vez recibido el binario, se inicia un proceso de validación del archivo (6). Una función Lambda valida si el tipo MIME es válido y se encuentra dentro del dominio de tipos MIME aceptados, el hash del archivo para garantizar la integridad, entre otras validaciones. Una vez aprobado el archivo, el contenido y el estado del archivo se actualizan en la tabla, y el binario se transfiere de S3 Staging a S3 Replication (7). Cuando se actualiza el estado, un “stream” de DynamoDB Streams pone un evento a disposición de una función Lambda (8), que envía el JSON con todo el contenido y la información de los archivos a un Kafka corporativo (norma de comunicación entre cuentas dentro de Itaú) para replicar los datos en la cuenta de administrador.

La cuenta de administración es el repositorio final de los datos, tanto binarios como lógicos. Esta cuenta es responsable de todo el ciclo de vida del contenido, ya sean actualizaciones de datos mediante API, ciclo de vida en S3 o su posible purga. También es responsable del contenido que requiere algún tipo de verificación. Una vez que el evento se publica en el Kafka corporativo, se activa una función Lambda (9) que almacena los datos en una nueva tabla de DynamoDB. A través de un flujo de DynamoDB (10), el contenido activo se filtra y se envía a la cuenta de búsqueda a través de otro Kafka corporativo.

La cuenta de búsqueda es responsable del flujo final de este proceso, que consiste en la búsqueda y recuperación del contenido almacenado en la plataforma. La función Lambda neptune-sync (11) recibe eventos del contenido activo y almacena los datos en Neptune. La API de búsqueda (12) permite recuperar los datos. Para recuperar los binarios, utilizamos Amazon CloudFront (13). Optamos por usar CloudFront para mantener el mismo estándar de URL firmada tanto para los binarios en S3 (flujo actual) como para los binarios en repositorios heredados (entorno de Itaú) que no admiten presigned URLs, integrándose mediante la API.

Ajustes en el Tamaño del Cluster

Cuando Neptune escaló inicialmente, se estimó que se necesitarían 3 máquinas db.r5.2xlarge para la afluencia inicial. A medida que la ingesta de datos en la cuenta aumentó (4 millones por día), se recuperaron algunas métricas de tiempo de inserción de Amazon CloudWatch y se descubrió que el tiempo de inserción con un volumen alto había aumentado drásticamente en comparación con cuando el número de inserciones era bajo.

Figura 3. Instancia de escritura con bajo número de inserciones.

Con una instancia de escritura db.r5.2xlarge, el tiempo de inserción de cada nodo con 800 funciones Lambda en paralelo (4 millones de solicitudes (requests) al día) fue superior a 3 segundos. Es decir, con un volumen de escritura bajo, el tiempo promedio fue de 0,4 segundos, y con un volumen de escritura alto, el tiempo aumentó a más de 3 segundos.

Figura 4. Instancia de escritura con alto volumen de inserciones.

Por consiguiente, se decidió aumentar la potencia de procesamiento de la máquina de escritura a una db.r5d.4xlarge. Tras el aumento, el tiempo de inserción de cada nodo con hasta 800 funciones Lambda en paralelo (14 millones de solicitudes (requests) al día) se redujo a menos de 0,1 segundos.

Figura 5. Instancia de escritura con alto volumen de inserciones tras lo redimensionamiento.

Motivación Para el Uso Del Amazon Neptune

Inicialmente, se estudiaron algunas bases de datos para facilitar los conceptos de búsqueda, y el equipo de IU Docs profundizó en Amazon OpenSearch, principalmente debido a su capacidad de indexación de texto.

Considerando estos escenarios, se calculó la infraestructura necesaria para OpenSearch. OpenSearch necesita fragmentos de hasta 30 GB para un buen rendimiento y baja latencia. Por lo tanto, se requeriría un cluster con más de 190 servidores debido al volumen. El límite máximo de un cluster es de 200 servidores, además del costo de la infraestructura.

Se realizó un estudio entre las principales soluciones que podrían satisfacer las necesidades del proyecto, lo que dio como resultado la siguiente tabla, con comparaciones entre características y tecnologías (datos de 2023).

Tras conversaciones con nuestro equipo de ingeniería y con el apoyo de AWS, optamos por Neptune. Se seleccionó Neptune por su alto poder de indexación de propiedades, sus diferentes tipos de vértices y su alto grado de interrelación con la información del documento, además de ser una opción mucho más económica. Optamos por un grafo basado en propiedades, que permite la búsqueda de datos en el grafo mediante el lenguaje Gremlin.

El Grafo de IU Docs

El esquema del grafo de IU Docs se define de la siguiente manera:

Figura 7. Schema del grafo de IU Docs.

Por ejemplo, al abrir una cuenta, es necesario recibir documentos como el documento de identidad (DNI), el comprobante de domicilio y el contrato de apertura.

El DNI puede indexarse con metadatos como tipo de contenido, número de DNI, nombre de la madre, nombre del cliente, fecha de emisión y fecha de vencimiento. El proceso al que se vinculó este DNI contendrá información como tipo de proceso, número de propuesta de apertura, número de sucursal, número de cuenta y número de banco.

En el caso de un contrato de apertura, se pueden indexar metadatos como tipo de contenido, número de propuesta de apertura, número de sucursal, número de cuenta y número de banco, los mismos que se indexan en el proceso.

Con los datos en cada vértice, el grafo podría representarse de la siguiente manera:

Figura 8. El grafo de IU Docs, con ejemplos de datos para cada vértice.

Conclusión

Esta entrada de blog presenta el proyecto IU Docs, el sistema responsable de la gestión de los documentos de los clientes en Itaú. Este proyecto comenzó en 2015 debido a la necesidad de un repositorio único de documentos de clientes que ofreciera diversas formas de búsqueda. Inicialmente, el modelo relacional funcionó, pero pronto surgieron restricciones que dificultaron el avance del proyecto, lo que requirió una modernización de sus componentes arquitectónicos.

Tras varias discusiones, llegamos a Amazon Neptune. Neptune es la base de datos orientada a grafos de AWS. Los grafos son útiles cuando queremos inferir información a través de la relación entre las abstracciones. Actualmente, la familia Amazon Neptune consta de la base de datos Neptune, Neptune ML y Neptune Analytics, que puede utilizarse como base de datos vectorial para las bases de conocimiento de Amazon Bedrock.

Dado que IU Docs se centra en documentos, procesos y clientes, y dado que todos estos conceptos están relacionados y es necesario buscar en los datos, se convirtió en nuestra base de datos preferida. Tras implementar algunas pruebas de concepto (PoC), migramos la base de datos relacional a Neptune. Actualmente, el cluster Neptune de IU Docs cuenta con más de dos mil millones de vértices, y todas las consultas desde las cuatro vistas que ofrece la aplicación se pueden realizar en milisegundos.

Este contenido és una traduccíon del blog original en portugués (enlace acá).

Acerca de los Autores
	Roberto Perillo es un arquitecto de soluciones empresariales en AWS Brasil, especializado en sistemas serverless, que presta servicios a clientes del sector financiero y ha estado en la industria del software desde 2001. Trabajó durante casi 20 años como arquitecto de software y desarrollador Java antes de unirse a AWS en 2022. Es licenciado en Ciencia de la Computación, tiene una especialización en Ingeniería de Software y un máster también en Ciencia de la Computación. Un aprendiz eterno. En su tiempo libre, le gusta estudiar, tocar la guitarra y también ¡jugar a los bolos y al fútbol de mesa con su hijo, Lorenzo!
	Andressa Fernandes es especialista en ingeniería por Itaú Unibanco S.A. Licenciada en Matemática Computacional por la Unifesp. Trabaja desde hace 10 años creando plataformas modernizadas y especializadas en Gestión de Contenidos.
	Thiago Wagner Caleme opera desde hace 10 años desarrollando plataformas modernizadas y especializadas en Gestión de Contenidos, creando productos digitales combinando tecnologías On Premises y Cloud. Lidera un equipo de ingeniería de software responsable de crear arquitecturas modernas, desacopladas y escalables para soportar todo el volumen de contenido del Banco Itaú. Tiene formación en CDIA+ (Arquitecto Certificado de Imágenes de Documentos) y la certificación AWS Certified Solutions Architect – Associate.
Acerca de la Traductora
	Gabriela Guimarães se desempeña como gerente de programa en Fintach y fue participante del primer Programa de Aprendizaje de Tecnología – Edición Mujeres Negras de AWS. Licenciado en Análisis y Desarrollo de Sistemas y estudiante de Ciencia de la Computación. En su tiempo libre, también trabaja como traductora de publicaciones de blogs técnicos, combinando su interés por la tecnología y la comunicación.
Acerca de los Revisores
	Erika Nagamine es arquitecta de soluciones de datos en AWS. Tiene una sólida formación académica, con un título en Sistemas de Información, un posgrado en Administración de Bases de Datos, Ingeniería de Datos y una especialización en Minería de Datos Complejos de la Unicamp. Trabaja con clientes de varios segmentos y ha participado en más de 200 proyectos en Brasil y en todo el mundo. Actualmente cuenta con múltiples certificaciones en datos y computación en la nube, todas las certificaciones de AWS, y le encanta compartir conocimientos en las comunidades y dar conferencias en eventos técnicos destacados en Brasil y el mundo.
	Luiz Yanai es arquitecto de análisis senior en AWS y trabaja con clientes nativos de la nube y empresas financieras en su camino hacia el uso de datos. Tiene casi 20 años de experiencia en arquitectura y desarrollo de soluciones que involucran sistemas comerciales y de misión crítica, los últimos 5 años de los cuales han estado enfocados en la nube de AWS.
	Gonzalo Vásquez es Senior Solutions Architect de AWS Chile para clientes de los segmentos Independent software vendor (ISV) y Digital Native Business (DNB) de Argentina, Paraguay y Uruguay. Antes de sumarse a AWS, se desempeñó como desarrollador de software, arquitecto de sistemas, gerente de investigación y desarrollo y CTO en compañías basadas en Chile.