¡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.
