Esta es una publicación invitada de Diego Benavides y Luis Bendezú, Arquitectos de Datos Senior, Dirección de Arquitectura de Datos en Belcorp.
Belcorp es una de las principales empresas de bienes de consumo envasados (CPG) que ofrece productos cosméticos en la región desde hace más de 50 años, distribuida en alrededor de 13 países de América del Norte, Central y del Sur (AMER). Nacida en Perú y con fábrica propia de productos en Colombia, Belcorp siempre se mantuvo a la vanguardia y adaptó su modelo de negocios de acuerdo a las necesidades de los clientes y fortaleció su estrategia con las tendencias tecnológicas, brindando cada vez una mejor experiencia al cliente. Enfocado en esto, Belcorp comenzó a implementar su propia estrategia de datos fomentando el uso de datos para la toma de decisiones. Con base en esta estrategia, el equipo de arquitectura de datos de Belcorp diseñó e implementó un ecosistema de datos que permite a los equipos de negocios y análisis consumir datos funcionales que utilizan para generar hipótesis y conocimientos que se materializan en mejores estrategias de marketing o productos novedosos. Esta publicación tiene como objetivo detallar una serie de mejoras continuas realizadas durante 2021 con el fin de reducir la cantidad de incidentes de plataforma reportados al cierre de 2020, optimizar los SLA requeridos por el negocio y ser más rentables al usar Amazon EMR, lo que se traduce en hasta un 30% de ahorro para la empresa.
Para mantenerse a la vanguardia, las empresas más fuertes han creado una estrategia de datos que les permite mejorar las principales estrategias comerciales, o incluso crear otras nuevas, utilizando los datos como motor principal. Como una de las principales empresas de bienes de consumo empaquetados (CPG) de la región, Belcorp no es una excepción, en los últimos años hemos estado trabajando para implementar la toma de decisiones basada en datos.
Sabemos que toda buena estrategia de datos está alineada con los objetivos comerciales y se basa en los principales casos de uso comercial. Actualmente, todos los esfuerzos de nuestro equipo se centran en los consumidores finales, y casi todas las iniciativas comerciales están relacionadas con la hiperpersonalización, la fijación de precios y la participación del cliente.
Para respaldar estas iniciativas, el departamento de arquitectura de datos proporciona servicios de datos como integración de datos, solo una fuente de la verdad, gobernanza de datos y marcos de calidad de datos, disponibilidad de datos, accesibilidad de datos y tiempo de comercialización optimizado, de acuerdo con los requisitos comerciales como otros grandes compañías. Para proporcionar capacidades mínimas para respaldar todos estos servicios, necesitábamos un ecosistema de datos escalable, flexible y rentable. Belcorp comenzó esta aventura hace un par de años utilizando servicios de AWS como Nube informática elástica de Amazon (Amazon EC2), AWS Lambda, AWS Fargate, EMR de Amazon, Amazon DynamoDBy Desplazamiento al rojo de Amazon, que actualmente alimentan con datos nuestras principales soluciones analíticas.
A medida que crecíamos, tuvimos que mejorar continuamente el diseño de nuestra arquitectura y el marco de procesamiento con respecto al volumen de datos y los requisitos de soluciones de datos más complejos. También tuvimos que adoptar marcos de control y calidad para garantizar la integridad de los datos, la calidad de los datos y los acuerdos de nivel de servicio (SLA). Como es de esperar, no es una tarea fácil y requiere su propia estrategia. A principios de 2021 y debido a los incidentes críticos que estábamos encontrando, la estabilidad operativa se vio afectada, impactando directamente en los resultados del negocio. La facturación también se vio afectada debido a que se incluyeron más cargas de trabajo nuevas y complejas, lo que provocó un aumento inesperado en los costos de la plataforma. En respuesta, decidimos centrarnos en tres desafíos:
- Estabilidad operativa
- Eficiencia de costo
- Acuerdos de nivel de servicio
Esta publicación detalla algunas acciones que llevamos a cabo durante 2021 sobre el marco de procesamiento de datos de Belcorp basado en Amazon EMR. También discutimos cómo estas acciones nos ayudaron a enfrentar los desafíos mencionados anteriormente, y también brindaron un ahorro económico a Belcorp, que fue la principal contribución del equipo de arquitectura de datos a la empresa.
Resumen de la solución
El ecosistema de datos de Belcorp está compuesto por siete pilares de capacidad clave (como se muestra en el siguiente diagrama) que definen nuestro diseño arquitectónico y nos brindan opciones más o menos tecnológicamente flexibles. Nuestra plataforma de datos se puede clasificar como parte de la segunda generación de plataformas de datos, como lo menciona Zhamak Dehghani en Cómo pasar de un lago de datos monolítico a una malla de datos distribuida. De hecho, tiene todas las limitaciones y restricciones de un enfoque Lakehouse como se menciona en el documento. Lakehouse: una nueva generación de plataformas abiertas que unifican el almacenamiento de datos y el análisis avanzado .
La plataforma de datos de Belcorp admite dos casos de uso principales. Por un lado, proporciona datos para ser consumidos mediante herramientas de visualización, fomentando el autoservicio. Por otro lado, proporciona datos funcionales a los usuarios finales, como científicos de datos o analistas de datos, a través de almacenes de datos distribuidos y almacenamiento de objetos más adecuados para prácticas analíticas avanzadas.
El siguiente diseño de referencia explica las dos capas principales encargadas de proporcionar datos funcionales para estos casos de uso. La capa de procesamiento de datos se compone de dos subcapas. El primero es Data Lake Integrator de Belcorp, que es una solución de Python interna integrada con un conjunto de servicios API REST a cargo de organizar todas las cargas de trabajo de datos y las etapas de datos dentro de los repositorios de análisis. También funciona como un punto de control para distribuir los recursos que se asignarán a cada trabajo de Amazon EMR Spark. La subcapa de procesamiento está compuesta principalmente por el clúster EMR, que se encarga de orquestar, rastrear y mantener todos los trabajos de Spark desarrollados con un marco Scala.
Para la capa de repositorio persistente, usamos Servicio de almacenamiento simple de Amazon (Amazon S3) almacenamiento de objetos como repositorio de datos para cargas de trabajo de análisis, donde hemos diseñado un conjunto de etapas de datos que tienen propósitos operativos y funcionales basados en el diseño de la arquitectura de referencia. Discutir el diseño del repositorio en más profundidad está fuera del alcance de esta publicación, pero debemos tener en cuenta que cubre todos los desafíos comunes relacionados con la disponibilidad de datos, la accesibilidad de los datos, la consistencia de los datos y la calidad de los datos. Además, logra todas las necesidades de Belcorp requeridas por su modelo de negocio, a pesar de todas las limitaciones y restricciones que heredamos del diseño mencionado anteriormente.
Ahora podemos dirigir nuestra atención al propósito principal de esta publicación.
Como mencionamos, experimentamos incidentes críticos (algunos de los cuales existían antes) y aumentos de costos inesperados a principios de 2021, lo que nos motivó a tomar medidas. La siguiente tabla enumera algunos de los principales temas que llamaron nuestra atención.
| Incidentes Reportados | Impacto |
| Retraso en trabajos de Spark en Amazon EMR | Las cargas de trabajo principales toman mucho tiempo |
| Retraso en el escalado automático de los nodos de Amazon EMR | Las cargas de trabajo toman mucho tiempo |
| Aumento en el uso computacional de Amazon EMR por nodo | Aumento de costos inesperado |
| Contenedores de recursos perdidos | Las cargas de trabajo procesan una gran caída de datos |
| Memoria y CPU sobreestimadas | Aumento de costos inesperado |
Para enfrentar estos problemas, decidimos cambiar de estrategia y comenzamos a analizar cada problema para identificar la causa. Definimos dos líneas de acción en base a tres retos que los líderes querían que trabajáramos. La siguiente figura resume estas líneas y desafíos.
La línea de acción de la arquitectura del lago de datos se refiere a todas las brechas arquitectónicas y características obsoletas que determinamos como parte de los principales problemas que generaban los incidentes. La línea de acción de mejores prácticas de desarrollo de Spark está relacionada con la solución de datos de Spark desarrollada que había estado causando inestabilidad debido a malas prácticas durante el ciclo de vida del desarrollo. Enfocados en estas líneas de acción, nuestros líderes definieron tres desafíos para disminuir la cantidad de incidentes y garantizar la calidad del servicio que brindamos: estabilidad operativa, costo-eficiencia y SLAs.
En base a estos desafíos, definimos tres KPI para medir el éxito del proyecto. Los incidentes de Jira nos permiten validar que nuestros cambios están teniendo un impacto positivo; la facturación por semana muestra a los líderes que parte de los cambios que aplicamos optimizarán gradualmente el costo; y el tiempo de ejecución proporciona a los usuarios comerciales un mejor tiempo de comercialización.
A continuación, definimos los próximos pasos y cómo medir el progreso. Con base en nuestro marco de monitoreo, determinamos que casi todos los incidentes que surgieron estaban relacionados con el procesamiento de datos y las capas persistentes del repositorio. Luego teníamos que decidir cómo resolverlos. Podríamos hacer arreglos reactivos para lograr la estabilidad operativa y no tener un impacto en el negocio, o podríamos cambiar nuestra forma habitual de trabajar, analizar cada problema y proporcionar una solución final para optimizar nuestro marco. Como puedes adivinar, decidimos cambiar nuestra forma de trabajar.
Realizamos un análisis preliminar para determinar los principales impactos y desafíos. Luego propusimos las siguientes acciones y mejoras en base a nuestras líneas de acción:
- Arquitectura del lago de datos – Rediseñamos el clúster EMR; ahora estamos usando nodos centrales y de tareas
- Prácticas recomendadas de desarrollo de Spark – Optimizamos los parámetros de Spark (memoria RAM, núcleos, CPU y número de ejecutor)
En la siguiente sección, explicamos en detalle las acciones y mejoras propuestas para lograr nuestros objetivos.
Acciones y mejoras
Como mencionamos en la sección anterior, el análisis realizado por el equipo de arquitectura dio como resultado una lista de acciones y mejoras que nos ayudarían a enfrentar tres desafíos: estabilidad operativa, un ecosistema de datos rentable y SLA.
Antes de continuar, es un buen momento para brindar más detalles sobre el marco de procesamiento de datos de Belcorp. Lo construimos basado en Apache Spark usando el lenguaje de programación Scala. Nuestro marco de procesamiento de datos es un conjunto de artefactos de Scala escalables, parametrizables y reutilizables que brindan a los equipos de desarrollo una herramienta poderosa para implementar canalizaciones de datos complejas, logrando los requisitos comerciales más complejos utilizando la tecnología Apache Spark. A través del marco Belcorp DevOps, implementamos cada artefacto en varios entornos que no son de producción. Luego pasamos a producción, donde el clúster de EMR lanza todas las rutinas utilizando los artefactos de Scala que hacen referencia a cada área conceptual dentro de la plataforma analítica. Esta parte del ciclo proporciona a los equipos cierto grado de flexibilidad y agilidad. Sin embargo, olvidamos, por un momento, la calidad del software que estábamos desarrollando utilizando la tecnología Apache Spark.
En esta sección, profundizamos en las acciones y mejoras que aplicamos para optimizar el marco de procesamiento de datos de Belcorp y mejorar la arquitectura.
Rediseño del clúster EMR
El diseño e implementación actuales del lago de datos de Belcorp no es la primera versión. Actualmente estamos en la versión 2.0 y, desde el comienzo de la primera implementación hasta ahora, hemos probado diferentes diseños de clústeres de EMR para implementar la capa de procesamiento de datos. Inicialmente, usamos un clúster fijo con cuatro nodos (como se muestra en la siguiente figura), pero cuando se lanzó la capacidad de escalado automático y aumentaron las cargas de trabajo de datos de Belcorp, decidimos moverlo allí para optimizar el uso de recursos y los costos. Sin embargo, un clúster EMR escalado automáticamente también tiene diferentes opciones. Puede elegir entre nodos principales y de tareas con un número mínimo y máximo de cada uno. Además, puede seleccionar instancias bajo demanda o de spot. También puede implementar una estrategia de asignación optimizada utilizando flotas de instancias de EMR para reducir la probabilidad de pérdida de instancias de spot. Para obtener más información acerca de las estrategias de asignación de recursos de Amazon EMR, consulte Mejoras de Spark para la elasticidad y la resiliencia en Amazon EMR y Optimización de Amazon EMR para la resiliencia y el costo con instancias de spot con capacidad optimizada.
Probamos todas estas capacidades, pero encontramos algunos problemas.
En primer lugar, aunque AWS ofrece muchas capacidades y funcionalidades en torno a Amazon EMR, si no tiene cierto grado de conocimiento sobre la tecnología que desea utilizar, es posible que encuentre muchos problemas a medida que surjan los casos de uso. Como mencionamos, decidimos utilizar el motor de procesamiento de datos Apache Spark a través de Amazon EMR como parte del ecosistema de datos de Belcorp, pero enfrentamos muchos problemas. Cada vez que aparecía un incidente, motivaba al equipo de arquitectos de datos a cargo para solucionarlo, como parte de las tareas operativas y de soporte. Casi todas estas correcciones reactivas estaban relacionadas con el cambio de configuración de Amazon EMR para probar diferentes alternativas con el fin de resolver estos incidentes de manera eficiente.
Descubrimos que casi todos los incidentes estaban relacionados con la asignación de recursos, por lo que probamos muchas opciones de configuración, como tipos de instancias, aumento de la cantidad de nodos, reglas personalizadas para el escalado automático y estrategias de flota. Esta última opción se utilizó para reducir la pérdida de nodos. A fines de 2020, validamos que un clúster de EMR con escalado automático habilitado con una capacidad mínima de tres nodos centrales bajo demanda las 24 horas del día, los 7 días de la semana y la capacidad de escalar hasta 25 nodos centrales bajo demanda nos proporcionó un procesamiento de datos estable plataforma. A principios de 2021, se implementaron trabajos de Spark más complejos como parte de las rutinas de procesamiento de datos dentro del clúster de EMR, lo que provocó nuevamente inestabilidad operativa. Además, la facturación aumentaba inesperadamente, lo que alertó a los líderes cuyo equipo necesitaba rediseñar el clúster de EMR para mantener una estabilidad operativa saludable y optimizar los costos.
Pronto nos dimos cuenta de que era posible reducir hasta un 40 % de la facturación actual utilizando instancias de spot, en lugar de mantener todos los nodos principales en consumo bajo demanda. Otra optimización de la infraestructura que queríamos aplicar era reemplazar varios nodos centrales con nodos de tareas, porque casi todas las cargas de trabajo de datos de Belcorp utilizan mucha memoria y usan Amazon S3 para leer los datos de origen y escribir el conjunto de datos resultante. La pregunta aquí era cómo hacer eso sin perder los beneficios del diseño actual. Para responder a esta pregunta, contamos con la orientación del equipo de cuentas de AWS y nuestro especialista en análisis y Big Data de AWS SA, con el fin de aclarar preguntas sobre lo siguiente:
- Implementación de Apache Spark en Amazon EMR
- Prácticas recomendadas de nodos principales y de tareas para entornos de producción
- Comportamiento de las instancias de spot en Amazon EMR
Definitivamente recomendamos abordar estos tres puntos principales antes de aplicar cualquier cambio porque, según nuestra experiencia previa, realizar modificaciones en la oscuridad puede generar una implementación de Amazon EMR costosa y de bajo rendimiento. Con eso en mente, rediseñamos el grupo EMR para utilizar Escalamiento administrado por EMR, que cambia automáticamente el tamaño de su clúster para obtener el mejor rendimiento al menor costo posible. Definimos un máximo de 28 unidades de capacidad con tres nodos centrales On-Demand siempre encendidos (24/7) para soportar cargas de trabajo de datos durante el día. Luego, establecemos un límite de escalado automático de seis núcleos bajo demanda para proporcionar capacidades HDFS mínimas para admitir los 22 nodos de tareas restantes compuestos por instancias de spot. Esta configuración final se basa en el consejo de los expertos de AWS de que tenemos al menos un nodo central para admitir seis nodos de tareas, manteniendo una proporción de 1:6. La siguiente tabla resume nuestro diseño de clúster.
| Política de escalado de clústeres | Escalamiento administrado de Amazon EMR habilitado |
Unidades mínimas de nodo (MinimumCapacityUnits) |
3 |
Unidades de nodo máximas (a) |
28 |
Límite bajo demanda (MaximumOnDemandCapacityUnits) |
6 |
Número máximo de nodos principales (MaximumCoreCapacityUnits) |
6 |
| Tipo de instancia | m4.10xlargo |
| Número de nodos primarios | 1 |
| Tipo de instancia de nodo principal | m4.4xlargo |
La siguiente figura ilustra nuestro diseño de clúster actual y actualizado.
Ajuste de parámetros de chispa
Como todo buen libro sobre Apache Spark Puedo decirle que el ajuste de parámetros de Spark es el tema principal que debe analizar antes de implementar una aplicación de Spark en producción.
Ajustar los parámetros de Spark es la tarea de configurar los recursos (CPU, memoria y número de ejecutores) para cada aplicación de Spark. En esta publicación, no nos enfocamos en los recursos de la instancia del controlador; nos enfocamos en los ejecutores porque ese es el principal problema que encontramos dentro de la implementación de Belcorp.
Después de aplicar mejoras en torno a la operación de unión y las estrategias de caché en el desarrollo de aplicaciones de Spark, nos dimos cuenta de que algunas de esas aplicaciones estaban asignadas con recursos sobreestimados en el clúster de EMR. Eso significa que las aplicaciones de Spark asignaron recursos, pero solo se usó el 30 % de los recursos. El siguiente informe de Ganglia ilustra la sobreestimación de la asignación de recursos para un trabajo de la aplicación Spark, que capturamos durante una de nuestras pruebas.
Una gran consecuencia de este comportamiento fue el despliegue masivo de nodos EMR que no se utilizaban correctamente. Eso significa que se aprovisionaron numerosos nodos debido a la función de escalado automático requerida por el envío de una aplicación Spark, pero gran parte de los recursos de estos nodos se mantuvieron libres. Mostramos un ejemplo básico de esto más adelante en esta sección.
Con esta evidencia, comenzamos a sospechar que necesitábamos ajustar los parámetros de Spark de algunas de nuestras aplicaciones Spark.
Como mencionamos en secciones anteriores, como parte del ecosistema de datos de Belcorp, construimos un Data Pipelines Integrator, que tiene la responsabilidad principal de mantener un control centralizado de las ejecuciones de cada aplicación Spark. Para ello, utiliza un archivo JSON que contiene la configuración de parámetros de Spark y realiza cada spark-submit usando el servicio Livy, como se muestra en el siguiente código de ejemplo:
Este archivo JSON contiene la configuración de parámetros de Spark de cada aplicación de Spark relacionada con un sistema interno y un país que enviamos al clúster de EMR. En el siguiente ejemplo, CM es el nombre del sistema y PE es el código de país del que proceden los datos:
El problema con este enfoque es que a medida que agregamos más aplicaciones, la gestión de estos archivos de configuración se vuelve más compleja. Además, teníamos muchas aplicaciones Spark configuradas con una configuración predeterminada que se definió hace mucho tiempo cuando las cargas de trabajo eran menos costosas. Entonces, se esperaba que algunas cosas cambiaran. En la siguiente figura se muestra un ejemplo de una aplicación Spark con parámetros no calibrados (usamos cuatro instancias de ejecutor solo para el ejemplo). En este ejemplo, nos dimos cuenta de que estábamos asignando ejecutores con muchos recursos sin seguir ninguna de las mejores prácticas de Spark. Esto estaba provocando el aprovisionamiento de ejecutores gordos (usando la jerga de Spark) asignando cada uno de ellos en al menos un nodo. Eso significa que si definimos que una aplicación Spark se envíe con 10 ejecutores, requerimos al menos 10 nodos del clúster y usamos 10 nodos para una sola ejecución, lo que fue muy costoso para nosotros.
Cuando se enfrenta a desafíos de ajuste de parámetros de Spark, siempre es una buena idea seguir los consejos de los expertos. Quizás uno de los consejos más importantes esté relacionado con la cantidad de núcleos ejecutores que debe usar en una aplicación Spark. Los expertos sugieren que un ejecutor debe tener hasta cuatro o cinco núcleos. Conocíamos esta restricción porque anteriormente desarrollamos aplicaciones Spark en el ecosistema de Hadoop debido a las restricciones de E/S de los sistemas de archivos de Hadoop. Es decir, si tenemos más núcleos configurados para un ejecutor, realizamos más operaciones de E/S en un solo nodo de datos de HDFS, y es bien sabido que HDFS se degrada debido a la alta concurrencia. Esta restricción no es un problema si usamos Amazon S3 como almacenamiento, pero la sugerencia permanece debido a la sobrecarga de la JVM. Recuerde, mientras tenga más tareas operativas, como operaciones de E/S, la JVM de cada ejecutor tiene más trabajo por hacer, por lo que la JVM se degrada.
Con estos hechos y hallazgos previos, nos dimos cuenta de que para algunas de nuestras aplicaciones Spark, estábamos usando solo el 30% de los recursos asignados. Necesitábamos recalibrar los parámetros del trabajo de Spark para asignar solo los recursos más adecuados y reducir significativamente el uso excesivo de los nodos EMR. La siguiente figura proporciona un ejemplo de los beneficios de esta mejora, donde podemos observar una reducción del 50 % de los nodos en función de nuestra configuración anterior.
Usamos los siguientes parámetros optimizados para optimizar la aplicación Spark relacionada con el sistema CM:
Resultados
En este post queríamos compartir el caso de éxito de nuestro proyecto para mejorar el ecosistema de datos de Belcorp, basado en dos líneas de acción y tres desafíos definidos por líderes que utilizan tecnologías de datos de AWS y plataformas propias.
Tuvimos claros nuestros objetivos desde el principio en base a los KPIs definidos, por lo que hemos podido validar que el número de incidentes JIRA reportados a finales de mayo de 2021 tuvo una reducción notable. Las siguientes cifras muestran una reducción de hasta un 75% respecto a meses anteriores, destacando marzo como pico crítico.
En función de esta reducción de incidentes, descubrimos que casi todas las rutinas de trabajos de Spark que se ejecutan en el clúster de EMR se beneficiaron de una optimización del tiempo de ejecución, incluidos los dos trabajos de Spark más complejos, con una reducción de hasta el 60 %, como se muestra en la siguiente figura.
Quizás el aporte más importante de las mejoras realizadas por el equipo esté directamente relacionado con la facturación por semana. Por ejemplo, el rediseño de Amazon EMR, las mejoras en la operación de combinación, la aplicación de las mejores prácticas de caché y el ajuste de parámetros de Spark, todo esto produjo una reducción notable en el uso de los recursos del clúster. Como sabemos, Amazon EMR calcula la facturación en función del tiempo que los nodos del clúster han estado encendidos, independientemente de si realizan algún trabajo. Entonces, cuando optimizamos el uso del clúster EMR, también optimizamos los costos que generamos. Como se muestra en la siguiente figura, solo en 2 meses, entre marzo y mayo, logramos una reducción de facturación de hasta un 40%. Estimamos que ahorraremos hasta un 26% de la facturación anual que se hubiera generado sin las mejoras.
Conclusión y próximos pasos
El equipo de arquitectura de datos está a cargo de las mejoras continuas del ecosistema de datos de Belcorp, y siempre enfrentamos el desafío de lograr la mejor arquitectura de su clase, crear mejores diseños de soluciones arquitectónicas, optimizar costos y crear la arquitectura más automatizada, flexible y eficiente. marcos escalables.
Al mismo tiempo, estamos pensando en el futuro de este ecosistema de datos: cómo podemos adaptarnos a las nuevas necesidades comerciales, generar nuevos modelos comerciales y abordar las brechas arquitectónicas actuales. Estamos trabajando ahora en la próxima generación de la plataforma de datos de Belcorp, basada en enfoques novedosos como productos de datos, redes de datos y casas de lagos. Creemos que estos nuevos enfoques y conceptos nos ayudarán a cubrir nuestras brechas arquitectónicas actuales en la segunda generación de nuestro diseño de plataforma de datos. Además, nos ayudará a organizar mejor los equipos comerciales y de desarrollo para obtener una mayor agilidad durante el ciclo de desarrollo. Pensamos en las soluciones de datos como un producto de datos y brindamos a los equipos un conjunto de componentes tecnológicos y marcos automatizados que pueden usar como bloques de construcción.
AGRADECIMIENTOS
Nos gustaría agradecer a nuestros líderes, especialmente a José Israel Rico, Director de Arquitectura de Datos Corporativos, y Venkat Gopalan, Director de Tecnología, Datos y Digital, quienes nos inspiran a centrarnos en el cliente, insisten en los más altos estándares y respaldan cada decisión técnica basada en en un mayor conocimiento del estado del arte.
Acerca de los autores
Diego Benavides es el Arquitecto de Datos Senior de Belcorp a cargo del diseño, la implementación y la mejora continua de la Arquitectura del Ecosistema de Datos Global y Corporativo. Tiene experiencia trabajando con big data y tecnologías de análisis avanzado en muchas áreas de la industria, como telecomunicaciones, banca y comercio minorista.
Luis Bendezú trabaja como ingeniero de datos sénior en Belcorp. Está a cargo de las mejoras continuas y de la implementación de nuevas características del lago de datos mediante una serie de servicios de AWS. También tiene experiencia como ingeniero de software, diseñando API, integrando muchas plataformas, desacoplando aplicaciones y automatizando trabajos manuales.
mar ortiz es un bioingeniero que trabaja como Arquitecto Asociado de Soluciones en AWS. Tiene experiencia trabajando con computación en la nube y diversas tecnologías como medios, bases de datos, computación y diseño de arquitectura distribuida.
Raúl Hugo es un arquitecto sénior de soluciones de AWS con más de 12 años de experiencia en compañías financieras de LATAM y compañías de telecomunicaciones globales como administrador de sistemas, ingeniero de DevOps y especialista en la nube.
