Amazon Web Services • Codeoscopic https://codeoscopic.com/es/ Embracing Technology Tue, 17 Jan 2023 09:43:13 +0000 es hourly 1 https://wordpress.org/?v=7.0 Asegurando la veracidad, integridad y disponibilidad de la información a través del dato único https://codeoscopic.com/es/asegurando-la-veracidad-integridad-y-disponibilidad-de-la-informacion-a-traves-del-dato-unico/#utm_source=rss&utm_medium=rss&utm_campaign=asegurando-la-veracidad-integridad-y-disponibilidad-de-la-informacion-a-traves-del-dato-unico Tue, 17 Jan 2023 09:00:49 +0000 https://codeoscopic.com/?p=23191 Aprende cómo el Workspace de Codeoscopic soluciona los problemas de veracidad, integridad y disponibilidad de la información utilizando Aurora Serverless v2 de Amazon Web Services y Apache Kafka con nuestro sistema de dato único que permite compartir toda la información en tiempo real entre las aplicaciones de Codeoscopic Workspace

The post Asegurando la veracidad, integridad y disponibilidad de la información a través del dato único first appeared on Codeoscopic.

]]>

  • Aprende cómo el Workspace de Codeoscopic soluciona los problemas de veracidad, integridad y disponibilidad de la información utilizando Aurora Serverless v2 de Amazon Web Services y Apache Kafka.

    • Es muy común necesitar la misma información en las diferentes herramientas que utilizamos en nuestro día a día. Almacenamos datos de clientes en nuestro ERP, nuestro CRM, nuestro teléfono móvil, etc. Pero… ¿Qué pasa cuando, por ejemplo, un cliente contrata una póliza nueva? ¿Y si cambia de teléfono? ¿Nos acordaremos de actualizarlo en todas las aplicaciones? De no ser así, el día que queramos hacer uso de esos datos puede que no obtengamos la información correcta.
    La solución a la integridad de los datos consiste en centralizar toda la información compartida entre las aplicaciones en un único lugar: Codeoscopic “Agora”
    La solución a este problema consiste en centralizar toda la información compartida entre las aplicaciones en un único lugar, el cual hemos llamado en Codeoscopic “Agora”. Aunque a nivel de concepto parece algo sencillo, surgieron una serie de retos que tuvimos que solucionar. Por un lado, era necesario que esa información siempre estuviera disponible. No podía afectar el nivel de uso de las aplicaciones al rendimiento de Agora. Cada vez habría más información, ya que en el Workspace se generan y actualizan diariamente decenas de miles de proyectos. A esto había que sumarle la enorme cantidad de consultas diarias generadas por los usuarios de las más de 1700 corredurías que trabajan con nosotros. Centrándonos en los números, cada día se realizan alrededor de 15.000 multi-cotizaciones (contra múltiples aseguradoras) sobre una media de 6 aseguradoras lo que determina unos 60 precios diferentes por cotización (cada aseguradora devuelve varias modalidades de producto comercial). Esto son 900.000 precios al día, lo que supone que al mes recolectamos alrededor de 25 millones de precios diferentes. De esta cantidad de oferta, se emiten una media de 2.750 pólizas diarias (que representan a lo largo del mes unos 15 millones de Euros de primas emitidas). Como ejemplo, la producción en Avant2 Sales Manager de Autos representa más de un 20% de toda la nueva producción de Autos del Canal Corredor de toda España (por cualquier medio: tarificadores, páginas de la aseguradoras, etc, etc…)
    La producción en Avant2 Sales Manager de Autos representa más de un 20% de toda la nueva producción de Autos del Canal Corredor de toda España
    Además, en nuestro negocio existen picos de uso de las aplicaciones en horario comercial. Una arquitectura clásica de servidor local nos hubiera llevado a tener una máquina sobredimensionada para poder atender esos picos, algo impensable a nivel de costes y escalabilidad. Por tanto, la solución de Groucho Marx de “más madera” para poder solventar la situación no era viable. Analizando los servicios de bases de datos relacionales (RDS) disponibles en Amazon Web Services, decidimos utilizar Aurora Serverless v2, un servicio de base de datos relacional que permite el escalado automático bajo demanda. Una tecnología que nos permitía superar este primer reto ajustando los costes a las necesidades en tiempo real.
    Imagen 1: Cotizaciones diarias por hora del ramo de Autos.
    Por otro lado, cuando se actualizaba o se introducía información nueva en cualquiera de las aplicaciones, al trasladar esa información a Agora ésta debería de informar al resto de los cambios. Después de realizar varias pruebas de concepto, decidimos utilizar Apache Kafka, un proyecto de código abierto que tiene como objetivo la intermediación de mensajes bajo el patrón de publicación-suscripción, es decir, nos permite realizar streaming para que Agora notifique en tiempo real los cambios que se han producido en el dato único al resto de servicios interesados en esa información.
    Imagen 2: Esquema de flujo de operaciones e infraestructura.
    ¡Y con esto ya tenemos nuestro potente sistema de dato único que permite compartir toda la información en tiempo real entre las aplicaciones de Codeoscopic Workspace, con capacidad ilimitada y optimizando costes!
    Javier Barrachina Project manager Middleware and Architecture
     

    The post Asegurando la veracidad, integridad y disponibilidad de la información a través del dato único first appeared on Codeoscopic.

    ]]>         Encontrando una póliza entre millones de datos en cuestión segundos https://codeoscopic.com/es/como-acceder-a-millones-de-datos-en-diez-segundos/#utm_source=rss&utm_medium=rss&utm_campaign=como-acceder-a-millones-de-datos-en-diez-segundos Thu, 22 Dec 2022 07:08:15 +0000 https://codeoscopic.com/?p=22092 Aprende cómo Versus Analytics hace uso del servicio Athena de Amazon Web Services para recuperar una emisión de una compañía concreta sobre millones de datos.

    The post Encontrando una póliza entre millones de datos en cuestión segundos first appeared on Codeoscopic.

    ]]>

  • Aprende cómo Versus Analytics hace uso del servicio Athena de Amazon Web Services para recuperar una emisión de una compañía concreta sobre millones de datos.

    • ¡Datos, datos datos! No puedo hacer ladrillos sin arcilla. Esta frase que decía el famoso investigador Sherlock Holmes en sus novelas muestra la importancia de los datos en cualquier empresa. En Codeoscopic se generan cientos de miles de datos cada día que atraviesan un proceso de limpieza hasta que se convierten en información valiosa. Pero entonces nos hicimos una pregunta: ¿Cómo podemos acceder a millones de datos en un tiempo razonable? La respuesta la encontramos en Amazon Athena. Amazon Athena es un servicio que permite realizar consultas SQL sobre ficheros. Es la herramienta fundamental sobre la que se cimentan algunos módulos como el de Perfiles de riesgo en nuestra aplicación Versus Analytics. Sin embargo, por sí sola, Athena no nos ofrecía el rendimiento excepcional que buscábamos para nuestra aplicación.
    Imagen 1: nuestro data lake en su fase inicial con millones de datos para explotar.
    Nuestro objetivo era recuperar una emisión de una compañía concreta en un mar de más de 50 millones de datos
    Estábamos buscando una aguja en un pajar. Nuestro objetivo era recuperar una emisión de una compañía concreta en un mar de más de 50 millones de datos. El primer paso que dimos fue el de poner un poco de orden en nuestro data lake. Para ello dividimos nuestros datos en particiones de forma que fuera más fácil y rápido acceder a la información que nos interesaba. Una partición es como una sección en la biblioteca, si buscas un libro de terror, vas a la sección de terror a encontrarlo. Si nuestra emisión fuese del ramo de hogar, Athena ahora iría a buscarla a la partición de hogar, ignorando millones de datos de otros ramos que no nos interesan y agilizando enormemente el tiempo de la consulta. La mejora fue notable, pero no estábamos del todo satisfechos, así que continuamos optimizando nuestros sistemas.
    Imagen 2: un data lake particionado, acceder a la información que queremos ahora es más rápido.
    Cada tabla del catálogo de datos de nuestro data lake tiene varias columnas: fecha, matrícula, compañía… Así hasta más de 100 columnas que contienen información acerca del riesgo. Cuando Athena va a buscar los datos lo hace escaneando todas las columnas, pero no siempre queremos ver toda la información. El siguiente paso de optimización que realizamos fue el de cambiar el formato de fichero en el que almacenamos la información por uno que se llama Parquet. Se trata de un formato de fichero columnar, es decir, que cuando se haga una consulta, de todas las columnas que tenga el fichero se escanearán únicamente aquellas columnas que sean relevantes.
    Imagen 3: de toda la información que contiene un fichero parquet, sólo escaneamos aquella que nos interesa.
    Conseguimos que nuestra aplicación pueda realizar consultas sobre millones de datos en menos de 10 segundos
    ¡Conseguido! Gracias a estas optimizaciones, conseguimos que nuestra aplicación pueda realizar consultas sobre millones de datos en menos de 10 segundos.
    Raúl Franco Versus Project Manager

    The post Encontrando una póliza entre millones de datos en cuestión segundos first appeared on Codeoscopic.

    ]]>