Ayer mismo estaba intentando analizar unos data_types para completar una exportación al backend. La idea era sencilla, buscar para cada usuario la ultima información disponible en una tabla que representaba actualizaciones sobre su perfil. Como a su perfil podías “añadir”, “actualizar” y “eliminar” cosas, pues existian los tres tipos en la tabla. Para que la imaginemos mejor sería tal que así: user_id favorite_stuff operation metadata A Chocolate Add … A Chocolate Update … B Milk Remove … B Cornflakes Add … De tal manera que habría que combinar todos los eventos para saber cual es el perfil actual del usuario y aplicar cierta lógica. Sin embargo los eventos que habían llegado realmente eran así: Read more

Si trabajamos analizando los datos de una aplicación móvil es muy probable que esté integrado algún sistema para trackear los eventos de la app. Y entre ellos, uno de los más conocidos es Firebase. Estos eventos contienen mucha información útil y nos permiten por ejemplo saber, un usuario que se ha ido cuanto tiempo ha usado la aplicación o cuantos dias han pasado. O si realmente ha seguido el flujo de acciones que esperabamos (con un diagrama de sankey podríamos ver donde se han ido los usuarios). Read more

Como uno de los objetivos antes de cambiar de año quería empezar a dar visibilidad sobre el producto en el que estoy trabajando con un dashboard. Tras probar varias opciones, hemos optado por utilizar Quicksight para simplificar los procesos en aws y reducir nuestra infraestructura. Aún así, empezando un dashboard de cero, es muy difícil transmitir la información de forma clara. Es importante evitar que los usuarios vengan simplemente a expotar sus datos a csv para luego cargarlos en excel. Read more

Hace poco más de un mes cambié de trabajo y me encontré además con un cambio de stack considerable. Ahora estoy trabajando con aws + github + python. Y bueno, al margen de los cambios de conceptos y demás, me ha llevado bastante encontrar un flujo de trabajo que no me pareciera “frágil”. Lo primero y que me ha decepcionado bastante es que github no incluye soporte para hostear paquetes de python. Lo tendrá sí, pero sin fecha clara y por lo pronto parece que será despues de Junio de 2021. Read more

Sorprendentemente, hasta ahora, no había tenido la posibilidad de trabajar con data factory, sólo lo habia usado para algunas migraciones de datos. Sin embargo, tras estabilizar un proyecto y consolidar su nueva etapa, necesitabamos simplificar la solución implementada para migrar datos. Una representación sencilla de la arquitectura actual sería: En un flujo muy sencillo sería esto: La etl escribe un fichero csv con spark en un directorio de un blob storage. La primera function filtra los ficheros de spark que no son part- y se encarga de notificar a una function que actua de gateway para el batch con que fichero queremos enviar, el nombre original, el path y el nombre que queremos darle. Esta function de gateway se encarga de realizar las llamadas necesarias a la api de Azure para generar una tarea en el batch. El batch se encarga de comprimir el fichero y enviarlo al sftp del cliente, recuperando las credenciales según el tipo de fichero que se trate. Este proceso nos permitía trabajar con dos versiones del proyecto en lo que hacíamos la migración a la nueva versión. Ahora que la nueva versión ya está consolidada y hemos conseguido además que el cliente utilice un formato de compresión que podemos escribir directamente desde spark sin recurrir al batch, es el momento de cambiar la arquitectura de transferencia de datos. Read more

Hace unos días tuve la fortuna (o desgracia) de implementar la lógica más compleja de todo el dominio. El resultado, como esperaba, una etl que falaba por recursos constantementes. El problema: Caused by: org.apache.spark.SparkException: Could not execute broadcast in 300 secs. You can increase the timeout for broadcasts via spark.sql.broadcastTimeout or disable broadcast join by setting spark.sql.autoBroadcastJoinThreshold to -1 Lo primero fue revisar el plan de ejecución para ver que estaba sucediendo. Read more

A la hora de publicar reportes es común agrupar los datos por semanas. Otro motivo es alinearse con el negocio donde los cierres pueden producirse en días concretos, por ejemplo, un domingo. En esos casos si tenemos los datos particionados por días nos interesa saber a que domingo correspondería cada uno de los datos. Los que venimos de otros entornos tendemos a pensar en esas complicadas librerías de fechas (moment.js, jodatime, etc). Incluso alguien podría pensar en extraer los datos del dataframe y procesarlo en local. Read more

Uno de los mayores problemas de rendimiento que podemos encontrar en los datalake es tener que mover una enorme cantidad de ficheros pequeños, por el overhead que eso representa en las transacciones. Este post de databricks recomendada https://forums.databricks.com/questions/101/what-is-an-optimal-size-for-file-partitions-using.html que se crearan ficheros de 1GB parquet. Sin embargo mucha gente no sabe como detectar esto. Hace poco estuve jugando con un notebook y usando simplemente las herramientas del dbutils pude clasificar los ficheros que tenia en las entidades del datalake en múltiples categorías, así podría estimar cuantos ficheros había en un rango de tiempo. Read more