Sistema de reportes escalables para múltiples clientes (Amazon Quicksight)
Implementar una herramienta de Business Intelligence (BI) es fundamental para el análisis y la visualización de los datos. Para facilitarte la puesta en marcha, sin importar el lenguaje de programación, te contamos el enfoque que tomamos en La Haus para implementarla dentro de nuestra aplicación.
Contexto
Dentro de los diferentes productos que tenemos en La Haus, existe una aplicación llamada IMS (Inventory Management System) que permite gestionar diferentes inmuebles y su disponibilidad, realizar cotizaciones, implementar sistema de notificaciones, hacer integraciones a CRM, entre otras funcionalidades.
Esta aplicación web, donde el backend es una API en Ruby on Rails y el frontend en VueJS con base de datos Postgres, es usada tanto por el equipo de La Haus como por las constructoras.
El IMS guarda información muy valiosa para nuestros usuarios, como avance de sus proyectos, cotizaciones realizadas y total de ventas; así que es crucial contar con reportes para facilitar la lectura y el análisis. De esta manera, nació la iniciativa de montar un módulo de reportes.
Planeación
1. Se aterriza la necesidad y definición del alcance
- Nuestros usuarios son las constructoras, las cuales varían en tamaño, tipos de proyectos y formas de trabajar. Pero vimos que podíamos tener unos informes transversales y que serían de utilidad para todos
- Los reportes tienen que estar embebidos en el IMS para evitar que los usuarios tengan que salir a una aplicación externa. De esta manera, además, generamos una mejor experiencia, un mayor uso de la herramienta y podemos medir las interacciones.
- La información debe estar sincronizada en el menor tiempo posible porque algunas constructoras la requieren actualizada cada día
- La información debe ser restringida, tanto entre constructoras e, incluso, entre el equipo interno por tratarse de información de uso exclusivo.
- Los reportes son para todos los usuarios del IMS, es decir, que si una constructora tiene 50 empleados, en diferentes ciudades y salas de ventas, todos deberían tener la posibilidad de ver los reportes correspondientes.
2. Definición técnica
2.1 Fuente de datos:
Recolectar información, sacar contadores y filtrar son acciones que requieren de un esfuerzo pesado sobre la base de datos (Postgres en nuestro caso). Por esto, la primera definición fue sacar los datos de una réplica de postgres para no afectar el rendimiento de la de producción.
2.2 Gráficos:
Opción 1: Se evaluaron diferentes herramientas de JS para generar los gráficos (echarts, highcharts, d3). Sin embargo esta opción genera un gran esfuerzo desde el equipo de ingeniería, porque estas librerías simplemente se encargan de construir los gráficos pero las consultas y el procesamiento para cada gráfico genera una dependencia de tecnología para cualquier cambio (Agregar un filtro, quitar un variable, cambiar de uno etc) A pesar de eso, es un camino rápido y podremos ir entregando gráficos de manera progresiva
Opción 2: Evaluar herramientas de BI que se pudieran embeber dentro de la aplicación. Esta opción permitía que los reportes fueran más administrables y el esfuerzo del equipo de ingeniería sería grande en un comienzo -mientras se realiza la integración-, pero después sería poco o nulo.
a. Tableau: Dentro de La Haus tenemos un equipo de datos que utiliza tableau para la generación de reportes. Es una herramienta amigable, usable, personalizable, rápida y que permite embeber los reportes dentro del IMS. El equipo ya lo conocía y ya se estaba pagando. El gran inconveniente es el costo, cada usuario de tableau tiene un valor y por la cantidad de usuarios que tenemos en el IMS, no era rentable sacarle un usuario de tableau a los usuarios del IMS
b. PowerBI es amigable, fácil de usar (No tanto como tableau pero es muy bueno), mas económico que tableau pero el sistema de cobro es igual, es por usuarios y el valor no es rentable.
Tanto tableau como PowerBI almacenan la información internamente para sacar sus reportes, es más un proceso de sincronización cuando se conecta la base de datos y extrae la información, entonces sin importar cuánto estén usando los reportes la base de datos no se ve afectada
c. DataStudio (Google) no es tan amigable como tableau y PowerBI pero se puede embeber y es gratis. El problema con DataStudio es que no guarda la información, es una conexión directa con la base de datos y la segmentación de información por constructora implicaba tener una base de datos independiente para cada constructora y tener que generar el mismo dashboard con diferentes conexiones a base de datos, por este motivo es poco escalable.
d. AWS QuickSight: No es tan amigable ni personalizable como las anteriores, pero cumple con las necesidades para nuestro caso. Se puede embeber, se puede restringir la data, guarda la información de manera interna, el costo es razonable.
El sistema de usuario de QuickSight los divide en dos roles, el usuario autor que arma los dashboard y el usuario lector que puede ver los reportes e ingresar al mismo tiempo desde diferentes dispositivos. El cobro de quicksight es por demanda (cada vez que se ve un reporte y con un límite de 30 minutos por vista — conocido como una sesión) y con la ventaja de tener un tope de 5 USD mensuales por lector, es decir que desde la sesión número 18 no tiene costo al mes.
Entonces el caso de uso utilizado fue crear un usuario lector por constructora y cada usuario del IMS termina usando el usuario lector de su constructora. Dando un costo máximo de 5 USD por constructora para usar los reportes y para los usuarios IMS es transparente que están compartiendo una cuenta, ya que ven el reporte embebido y pueden ingresar simultáneamente.
Tomamos la decisión de probar AWS Quicksight y hacer una prueba de concepto. Para mirar esfuerzo y viabilidad
3. Prueba de concepto
Se hizo un ejercicio muy sencillo, se tomó una de las réplicas de la base de datos (Postgres) y se conectó una de las tabla a QuickSight (real_estates)
Después se configuró un dashboard muy simple.
Dado que nuestro backend está en Ruby on Rails, para generar el link de embeber nos apoyamos de una gema oficial de AWS para el SDK de Quicksight aws-sdk-quicksight y pusimos el iframe en un html sencillo
AWS tiene un SDK para los siguientes lenguajes JavaScript, Python, PHP, .NET, Ruby, Java, Go, Node.js, C++
4. Validación
Se presentó la prueba de concepto en el espacio de Study Group que tenemos en La Haus, donde se validaron escenarios e implicaciones de usar quicksight. En esta sección contamos con varios analistas de datos (Incluido nuestro Líder de BI — Davidecheverri), desarrolladores senior y nuestro CTO (Santiago García)
Ejecución
Como tenemos un usuario por constructora, decidimos agregar 2 campos tipo string a nuestra entidad de empresas (constructoras):
- dashboard_code: Donde ponemos el identificador del dashboard a mostrar, de esta manera podemos tener uno diferente para cada empresa o dejarle el dashboard genérico.
- dashboard_user: Es el usuario de QuickSight e identificador para restringir los datos y solo mostrar información de esa constructora
Se conectó a Quicksight una réplica y se configuraron 2 dataset (fuente de datos):
- Uno se conectaba con la tabla de empresas y armaba un conjunto de datos con el dashboard_user y el id con el fin de tener un dataset donde quede ligado el usuario de Quicksight con el id nuestro de las empresas
- Otro donde se armaba un conjunto de datos con la información necesaria para los reportes y en cada fila se incluye el id de la empresa
De esta manera, usamos el primer dataset como reglas de restricción a las filas del segundo dataset, entonces la información va estar segmentada por empresa.
Se construyó el dashboard con los gráficos generales que veíamos que generan valor a todos nuestros usuarios del IMS. Para esta tarea nos ayudó Maria Alejandra Carranza Sierra que es nuestra analista de datos dentro del equipo IMS
Se utilizó la gema aws-sdk-quicksight y se agregó una función para generar el link a embeber por empresa:
En el frontend usamos el paquete amazon-quicksight-embedding-sdk y creamos una función que hace la petición al backend y renderiza el dashboard en un div, en este caso con el id=”qs_dashboard”
Resultados
- La implementación, en cuanto a desarrollo, fue muy fácil, el contar con la gema para el backend y el paquete de node para frontend convirtió la integración con Quicksight en una tarea sencilla.
- Desde la primera versión se generó impacto positivo y uso de los reportes.
3. Con el uso de los reportes salieron diferentes mejoras y nuevos gráficos que se pudieron hacer sin que nadie del equipo de desarrollo tuviera que intervenir, ya que los dashboard son administrables desde la página de AWS Quicksight.
4. Se puede trabajar en el dashboard y solo cuando se le da la opción de publicar se ven reflejados en la parte web, dejando realizar diferentes pruebas sin afectar a los usuarios.
5. La herramienta de Quicksight, paulatinamente ha mejorado y creado nuevas funcionalidades que permiten generar reportes más robustos al contemplar diferentes fuentes de datos, otorgando al usuario final una visión crítica en la toma de decisiones.
6. Después de este proceso, nuestra recomendación es seguir un proceso de planeación y validación antes de ejecutar proyectos grandes. En un comienzo pensamos que era mejor crear reportes con desarrollo a utilizar una herramienta de BI por el esfuerzo que podia llevar.
Cualquier duda o sugerencia me pueden escribir a estebanarango@lahaus.com y con el mayor de los gustos responderé.
