Desde 2016, AWS incluye Quicksight como su servicio de Business Intelligence (BI). Quicksight facilita el análisis empresarial gracias a la sencillez que ofrece en la generación de visualizaciones y tableros interactivos, y a su alta capacidad para el análisis en tiempo real de los datos. A pesar de ello, se siguen encontrando grandes dificultades cuando llega el momento de promocionar los objetos generados en Quicksight (análisis, dashboards y conjuntos de datos) entre entornos o entre cuentas. No hay un método sencillo donde el analista de datos que ha generado los análisis y los dashboards de Quicksight en un entorno de desarrollo pueda promocionar esos análisis/dashboards al entorno productivo.
Este artículo tratará de explicar una propuesta desarrollada para solucionar este problema, debido a que aparece de forma recurrente en aquellos proyectos en los que se trabaja con entornos multicuenta con Amazon Quicksight. Esta solución ha sido validada en entornos productivos por un analista de datos, certificando, de esta forma, su funcionamiento en la mayoría de casos, y detectando aquellos en los que su funcionamiento no ha sido el esperado.
Desarrollo de la solución
Para implementar esta solución se ha hecho uso de boto3, el SDK de AWS para python. Boto3 es una biblioteca de python que facilita la comunicación con los distintos servicios de AWS, y en este caso, se ha utilizado para interactuar con el servicio de Amazon Quicksight a través de su API. Esta API permite realizar operaciones CRUD con los distintos objetos de Quicksight, por lo que facilita el objetivo de migrar los conjuntos de datos, análisis y dashboard de una cuenta origen de AWS a una cuenta destino.
Al realizar la migración de objetos de Quicksight entre entornos, es importante seguir un orden específico debido a la presencia de dependencias entre ellos. Por ejemplo, un análisis dependerá de los conjuntos de datos que utiliza.
Durante el proceso de migración, se tomarán los objetos de la cuenta origen y, mediante la API de Quicksight, serán transformados en objetos JSON, para desde estos objetos JSON poder crear objetos Quicksight en la cuenta destino.
El primero de los objetos que se debe migrar y crear en la cuenta de destino son los data sources1. Los data sources son conexiones a la fuente de datos subyacente, que puede ser una base de datos relacional, una base de datos NoSQL u otro tipo de fuente de datos. Es necesario que estos existan en la cuenta de destino antes de migrar los conjuntos de datos, ya que tienen como referencia el identificador único de los data source.
Para migrar estos objetos de Quicksight hay que comprobar qué data sources existen en la cuenta de origen, lo que se puede realizar mediante el método list_data_source; luego recorrer cada uno de estos data source de la cuenta origen para comprobar su configuración (con el método describe_data_source). Y finalmente, crearlo en la cuenta destino, a través del método create_data_source.
Es importante que al crear el data source en la cuenta de destino se utilice el mismo identificador único (DataSourceId) que en la cuenta de origen, ya que esto facilitará posteriormente la creación de los conjuntos de datos, al no tener que modificar el ID del data source que referencian.
Con los data sources migrados, se pueden migrar los conjuntos de datos. Esta migración se realiza de la misma forma que la anterior. Primero se comprueba qué conjuntos de datos existen en la cuenta de origen (list_data_sets); posteriormente se comprueba su configuración (describe_data_set), y una vez se conoce su configuración, se pueden crear en la cuenta de destino utilizando el método create_data_set2. Una vez creados los conjuntos de datos, para que los usuarios de la cuenta destino puedan visualizarlos desde la consola hay que actualizar sus permisos utilizando el método update_data_set_permissions.
Finalmente, para migrar los análisis y los dashboards de la cuenta de origen a la cuenta de destino, es necesario seguir un procedimiento diferente al utilizado previamente con los data sources y data sets. Esto se debe a que la API de Quicksight, al convertir el análisis en un objeto de tipo JSON con el método describe_analysis, da como resultado un objeto JSON que no es compatible con el método create_analysis, ya que este método encuentra problemas de validez de formato. Para solucionar este inconveniente, se debe hacer uso de un template de Quicksight, que actuará como comodín, facilitando la creación de los análisis y dashboard en la cuenta destino.
Este template se creará a partir de cada uno de los análisis que se quieran migrar, por lo tanto se tendrá un template por análisis. El método create_template necesita como parámetros el arn del análisis a partir del cual se va a crear el template y una lista con los arn de los conjuntos de datos que utiliza este análisis. Estos datos pueden obtenerse a través del método describe_analysis. Con el template creado, se tienen que conceder al usuario raíz de la cuenta destino los permisos quicksight:DescribeTemplate y quicksight:UpdateTemplatePermissions. Y, de esta forma, se podrá crear el análisis y el dashboard en la cuenta destino a partir del template. Para ello se tiene que hacer uso de los métodos create_analysis y create_dashboard, que ,como se indica en el diagrama, hacen uso del parámetro SourceEntity. Este parámetro es un diccionario con un campo para el arn del template y otro para una lista de arn de los conjuntos de datos de la cuenta destino que utiliza el análisis, o dashboard, que se está creando.
Una vez creado tanto el análisis como el dashboard, simplemente queda actualizar los permisos de estos para que aquellos usuarios, o roles, que necesiten puedan visualizarlos en la consola y realizar modificaciones sobre ellos.
La solución que se ha planteado se encarga de realizar una primera migración de aquellos objetos de Quicksight que no existen en la cuenta destino. Pero se puede añadir un condicional que compruebe si existe el objeto de Quicksight antes de crearlo. Y, en caso afirmativo el objeto se actualizará mediante los métodos update_data_set, update_template, update_analysis y update_dashboard. De esta forma se podrán desarrollar nuevas versiones de los análisis y dashboards de quicksight y migrarlos al entorno productivo cuando la versión sea estable.
Qué debes tener en cuenta
Durante la fase de validación del proceso de migración de dashboards, hubo algunos aspectos en los que la migración de los elementos contenía alguna diferencia con respecto al informe original.
Este es el caso de la migración de documentos que contienen pestañas. Uno de los análisis contenía tres pestañas, de las cuales solo dos de ellas se decidieron publicar en el dashboard del entorno de desarrollo. Tras realizar la migración y comprobar el resultado en el entorno de producción, el dashboard mostraba las tres pestañas de las que constaba el análisis, de forma que la selección de pestañas a mostrar en el dashboard no se había transferido durante la migración.
También algunos visuales que formaban parte de los análisis mostraron pequeñas diferencias en los colores utilizados. Esto se daba especialmente en aquellos casos en los que el color a utilizar para un valor concreto se había seleccionado de forma manual, sin que el hexacolor formara parte del tema principal utilizado para el resto del análisis.
Por último, se debe tener en cuenta que aquellas opciones activadas con posterioridad a la creación del dashboard no se heredan tras la migración. Opciones como compartir el documento con “Todos los usuarios de la cuenta” o activar el “Detectable en Quicksight” se deben realizar directamente sobre el dashboard ya migrado, aunque ya estuvieran activadas en el informe original, ya que son opciones que no forman parte del análisis a partir del cual se crea el dashboard.
Conclusiones
Mediante el uso del SDK de AWS para Python, boto3, y la API de Quicksight, se ha facilitado a los analistas de datos el proceso de migración de conjuntos de datos, análisis y dashboards de manera efectiva en entornos multicuenta de AWS.
La migración de objetos de Quicksight entre entornos ha sido una tarea compleja pero gracias a la solución propuesta y validada en entornos productivos, se ha logrado generar un mecanismo automatizable, fiable y eficiente.
AWS está trabajando activamente en la optimización de este proceso, con el objetivo de facilitar cada uno de los pasos que hay que seguir para lograr esta migración de recursos de Quicksight. Mientras tanto, esta solución permitirá amenizar la espera y asegurar un correcto funcionamiento de todo el engranaje.
(1)Los data sources se pueden configurar de forma independiente en la cuenta destino sin necesidad de realizar la migración. Pero si se opta por este método, entonces se debe contar con algún tipo de equivalencia entre los identificadores únicos (ID) de los data sources de la cuenta origen y los creados en la cuenta destino. Ya que es un campo indispensable para la migración de los conjuntos de datos.
(2)Durante el desarrollo de la solución se tuvo que resolver una dependencia entre algunos conjuntos de datos entre sí. Esto se debía a que los dashboards de Quicksight que se utilizaban hacía uso de la seguridad a nivel de fila (RLS), para filtrar los datos en función de los permisos de cada usuario. Y, por este motivo, algunos conjuntos de datos tenían una dependencia con aquel que marcaba la restricción a nivel de fila, por lo tanto este conjunto de datos tuvo que ser migrado en primer lugar.
Imagen: Unsplash | Shahadat Rahman
Data Analyst in Keepler: “Problem solver, especially ones related to data and technology. Always focused on improving, being updated and sharing what I've learned. If you love to analyze sports based on data, we will be great friends :)”
I am a technology enthusiast. I enjoy learning, which allows me to step out of my comfort zone to face new challenges. I am currently focused on learning about the cloud and AI, so Keepler is an ideal partner.
0 comentarios