Tutorial: Cómo implementar cambios en los paneles de AI/BI de forma segura y a escala con paquetes de automatización declarativa

La idea de que una reunión de junta directiva comience con un dashboard lleno de errores debería quitarle el sueño a los equipos de analítica. Lo mismo ocurre al descubrir, a posteriori, que un plan de contratación, el lanzamiento de un producto o un pronóstico de ingresos se basaron en una métrica incorrecta. O que un equipo de soporte emitió demasiados reembolsos porque un dashboard representaba de forma errónea el historial de compras de un cliente.

Estos fallos rara vez se deben a un mal análisis. Como cualquier sistema de producción, a menudo surgen de la actualización manual de los dashboards a medida que evolucionan los modelos de datos y los requisitos, sin control de versiones, sin un proceso de revisión confiable o sin una forma repetible de promover los cambios entre entornos.

Este artículo de blog plantea un argumento sencillo: los dashboards de nivel de producción que impulsan el negocio deben gestionarse con la misma disciplina que el código de producción. Dado que Databricks AI/BI se ejecuta en la misma Data Intelligence Platform que sus canalizaciones de datos y su capa de gobernanza, los equipos también pueden aplicar esas mismas prácticas de producción (control de versiones, configuración específica del entorno y despliegue controlado) a los dashboards.

Para concretar esto, presentaremos cómo los analistas pueden utilizar las capacidades de nivel de producción de Databricks sin cambiar la forma en que crean sus dashboards en el día a día.

Específicamente, mostraremos cómo este flujo le permite:

• Revisar y aprobar cada cambio en un dashboard
• Realizar un seguimiento del historial de un dashboard y vincular los cambios de código con los requisitos del negocio
• Revertir un dashboard a una versión anterior

Requisitos previos

Este flujo de trabajo requiere una configuración de infraestructura única que la mayoría de las organizaciones ya tienen implementada. Si aún no la tiene, pida ayuda a su grupo interno de DevOps o IT para configurarla:

• Al menos dos espacios de trabajo de Databricks (por ejemplo, un espacio de trabajo de desarrollo y otro de producción) para crear, probar y desplegar dashboards
• Carpetas respaldadas por Git en Databricks (AWS | Azure | GCP), utilizadas para controlar las versiones de las definiciones de los dashboards
• Declarative Automation Bundles (DABs) (AWS | Azure | GCP) configurados para el proyecto

Introducción: Un flujo de trabajo estructurado para implementar cambios en los dashboards de forma segura

Analizaremos un escenario realista: usted es propietario de un dashboard de Sales Performance que los líderes de Finanzas y Ventas utilizan semanalmente. Comenzó como un proyecto de pasantía creado directamente en un espacio de trabajo, pero ha evolucionado con el tiempo y ahora se utiliza en varias revisiones ejecutivas.

Un cambio de prioridades a partir de una reunión de la junta directiva trae consigo un nuevo requisito: Finanzas ahora necesita realizar un seguimiento de los importes de ventas comprometidos y no comprometidos, reemplazando una única métrica de ventas agregada, y el dashboard debe reflejar la nueva definición antes de la próxima revisión del pronóstico.

Estos valores influyen directamente en decisiones comerciales reales, incluidos los cálculos de compensaciones y bonificaciones, así que llevemos este dashboard a una ruta de despliegue disciplinada por primera vez.

Paso 1: Agregar el dashboard a un Declarative Automation Bundles

Antes de comenzar el proceso, trabaje con su grupo de IT para configurar algunas herramientas de código básicas: un repositorio de Git con un 'Declarative Automation Bundles' vacío y algunos scripts de CI/CD para desplegar automáticamente el bundle.

Un repositorio de Git es una herramienta para realizar un seguimiento de los cambios en los archivos. Para comenzar, debemos conectarlo a Databricks para poder rastrear los cambios en la configuración del dashboard. Desde el espacio de trabajo de Databricks, cree una carpeta de Git y pegue la URL del repositorio en el cuadro de diálogo de configuración. Esto hace que Databricks reconozca el repositorio y nos permite agregarle el dashboard en el siguiente paso.

Un Declarative Automation Bundles es una forma de agrupar archivos de código (en este caso, un dashboard). Si el repositorio ya contiene un bundle, se detecta automáticamente y se puede abrir con el icono de la flecha. De lo contrario, se puede crear un nuevo bundle desde el menú Crear en la carpeta de Git.

Dentro del editor de Asset Bundles, puede agregar componentes nuevos y existentes al bundle que actualmente está vacío. Para incluir el dashboard, abra el menú Agregar y seleccione Agregar dashboard existente. Después de agregarlo, verá que el dashboard aparece dentro de la carpeta src como parte del bundle.

A partir de este momento, el dashboard se gestiona como un recurso desplegable, lo que facilita la promoción del mismo dashboard en los espacios de trabajo de desarrollo, prueba y producción.

Finalmente, haga commit del dashboard en el repositorio. Esto captura el estado actual del dashboard como una línea base y establece un punto de partida claro para rastrear y revisar cambios futuros.

Verá que el dashboard se agregó al repositorio, junto con algunos archivos de configuración generados automáticamente (que terminan en .yml). Estos archivos describen cómo se debe desplegar el dashboard en diferentes entornos; no es necesario que los edite.

Agregue una nota breve que describa lo que hizo en el campo mensaje de commit, luego seleccione Commit y Push. Esto crea un punto de control para el dashboard (un estado que se sabe que es correcto al que puede volver más tarde) para que los cambios futuros se puedan comparar, revisar y desplegar de forma segura.

Paso 2: Actualizar el dashboard

Ahora que se ha realizado el commit del dashboard existente, puede comenzar a realizar cambios en él sin afectar lo que ya está en producción, y Git rastreará los cambios específicos que haya realizado.

La práctica general es crear una rama de Git: una versión del dashboard en la que trabajar sin afectar a los demás. Puede hacerlo a través del botón Crear rama y luego asignarle un nombre descriptivo como su nombre, la función o un número de ticket asociado con el cambio. Piense en esto como una versión privada para su actualización: puede editar, probar y perfeccionar el dashboard libremente y luego decidir por separado cuándo están listos sus cambios para ser revisados y desplegados.

¡Ahora puede realizar los cambios en el dashboard! En este caso, modificará la cifra de ventas en la esquina superior izquierda para agregar contadores de ventas tanto comprometidas como no comprometidas (se eligieron azul y rojo en negrita para mayor visibilidad).

Notará que nada cambia en la experiencia de creación: realice estos cambios como lo haría normalmente utilizando el editor de la UI del dashboard.

Una vez que el dashboard se vea correctamente en desarrollo, estará listo para continuar y llevar los cambios a producción. Utilice el mismo botón de Git en la parte superior como antes para registrar estos cambios con un mensaje de commit corto.

Paso 3: Revisar el cambio

A continuación, desbloqueará otra ventaja clave de este flujo de trabajo: un espacio para que otros revisen los cambios y ofrezcan comentarios antes de que el cambio llegue a producción. Requerir la revisión de una segunda persona es una práctica recomendada general, pero, lo que es igual de importante, crea un espacio de bajo riesgo para debatir ideas, validar suposiciones y perfeccionar el cambio antes de que afecte a los informes.

Para iniciar la revisión, cree una Pull Request (PR) en su proveedor de Git, que es básicamente una página de revisión para la actualización del dashboard. El revisor puede ver exactamente qué cambió, dejar comentarios para que los resuelva y aprobar la actualización una vez que todo se vea bien.

Durante la revisión, el dashboard de producción permanece sin cambios. El proceso solo avanza una vez que se atienden los comentarios y se aprueba el cambio.

Aunque los cambios del dashboard se almacenan y rastrean como archivos de configuración en segundo plano, a menudo es difícil entender qué ha cambiado realmente. Por ello, la mayoría de los equipos utilizan una pequeña automatización para desplegar automáticamente una versión de prueba temporal del dashboard para su revisión cada vez que se abre una PR. De este modo, los revisores pueden ver las métricas, los cálculos y los diseños propuestos en contexto antes de que nada llegue a producción, y detectar problemas de lógica de datos o de la UI. El hecho de que el desarrollador o el revisor incluyan capturas de pantalla o enlaces al dashboard de prueba directamente en la PR también hace que los comentarios sean más rápidos y seguros.

Los revisores pueden agregar comentarios y aprobar, los cuales quedan registrados para que el cambio sea más fácil de entender más adelante.

Paso 4: Desplegar el dashboard en producción utilizando el bundle

Con el cambio aprobado, ya está listo para desplegar el dashboard en producción.

A menudo, los dashboards necesitan configuraciones diferentes en producción que en desarrollo; por ejemplo, apuntar a un catálogo o esquema de producción en lugar de a un conjunto de datos de desarrollo, o utilizar un SQL warehouse diferente.

La buena noticia es que estas diferencias se prevén y se gestionan como parte del proceso de despliegue.

Cuando agregó el dashboard al Asset Bundle, Databricks generó un pequeño archivo de configuración .yml que captura estos ajustes específicos del entorno. Este archivo le permite sobrescribir valores por entorno sin cambiar la lógica del propio dashboard. En nuestro caso, hemos especificado que el catálogo que utiliza el dashboard en producción debe ser diferente al de prueba, utilizando un valor ${variable} para el nombre del catálogo.

Finalmente, el archivo databricks.yml vincula todos los recursos del bundle y define qué catálogo se utiliza en cada entorno, lo que facilita la gestión de despliegues coherentes en los espacios de trabajo de desarrollo, prueba y producción.

Una vez que la Pull Request se aprueba y se fusiona en la rama principal, la automatización del despliegue se ejecuta y utiliza los valores específicos del entorno definidos en databricks.yml. El mismo código del dashboard se reutiliza en todos los espacios de trabajo, mientras que los ajustes como el catálogo, el esquema y el warehouse se aplican en función del entorno de destino. Esto elimina la necesidad de mantener copias separadas del dashboard para cada espacio de trabajo y garantiza que los cambios se comporten de forma predecible en todas partes.

En la mayoría de los proveedores de Git, podrá ver la automatización del despliegue en la pull request para poder supervisar el despliegue y confirmar cuándo se completa (o si surge algún problema). Si ocurre un problema, el despliegue se detiene sin afectar al dashboard de producción existente para permitirle solucionar el problema. Una vez que el despliegue finaliza con éxito, el dashboard actualizado estará activo en producción y listo para las partes interesadas.

Bonus 1: ¿Qué pasa si desea inspeccionar el historial?

Una vez que la actualización del dashboard está activa, es posible que necesite comprender el historial de qué cambió, cuándo y por qué. Una ventaja de este flujo es que el cambio ahora es trazable. En lugar de una edición única realizada directamente en un espacio de trabajo, aparece como una secuencia de versiones guardadas.

Cada entrada representa una actualización del dashboard, junto con el autor y la marca de tiempo. Puede abrir cualquier entrada para revisar los cambios y revertirla si es necesario.

Bonus 2: ¿Qué pasa si necesita revertir un cambio?

Incluso con una revisión y pruebas minuciosas, pueden surgir problemas, como un dashboard que no se carga o una definición de métrica que resulta ser incorrecta.

Dado que el dashboard se gestiona a través de este flujo de trabajo, puede volver a una versión que sepa que funciona correctamente utilizando el mismo proceso controlado que se empleó para desplegar la actualización.

Comience abriendo el historial de cambios del dashboard en el repositorio y localizando la actualización que desea deshacer. Desde allí, puede revisar qué se modificó para confirmar que está revirtiendo el cambio correcto antes de continuar.

Desde los detalles del cambio, siga el enlace de regreso a la página de revisión. Para revertir la actualización, seleccione Revert. Esto crea un nuevo cambio de "deshacer" que revierte solo esa actualización específica, restaurando el dashboard a su lógica anterior y manteniendo intacto el resto del historial del dashboard.

Una vez que el cambio se fusione en la rama principal, la misma automatización que implementó el dashboard en producción lo revertirá. Esto significa que puede responder a una interrupción o a un problema de cálculo de alto impacto en cuestión de minutos, sin eludir los controles que ya tiene implementados.

Bonus 3: ¿Qué pasa si sus fuentes de datos tienen una actualización?

La mayoría de los dashboards están estrechamente vinculados a sus fuentes de datos, lo que significa que las actualizaciones de un dashboard a menudo están estrechamente vinculadas a las actualizaciones en las canalizaciones. La buena noticia es que los Asset Bundles están diseñados para agrupar componentes relacionados en un solo paquete.

Esto garantiza que un cambio en el modelo de datos upstream nunca lo tome por sorpresa y, cuando los cambios de visualización requieran actualizaciones del modelo de datos, pueda implementar ambos cambios en un solo despliegue.

Conclusión

Tratar los dashboards de AI/BI como productos de datos de nivel de producción es esencial para tomar decisiones comerciales confiables y mitigar riesgos. En este flujo de trabajo, un pequeño conjunto de pasos adicionales hace que los cambios en el dashboard sean visibles, revisables y reversibles, sin cambiar la forma en que crea dashboards en el día a día.

Al administrar los dashboards con Git y Declarative Automation Bundles, los equipos establecen un flujo de trabajo rutinario y predecible para las actualizaciones: realizar el cambio, revisarlo, probarlo e implementarlo. El mismo proceso se aplica ya sea que la actualización sea un pequeño ajuste visual o un cambio significativo en la lógica de negocio.

Con la disciplina de despliegue adecuada, los cambios en el dashboard dejan de ser una fuente de riesgo y se convierten en una fuente confiable de información que evoluciona con el negocio, incluso en situaciones de gran importancia como una reunión de la junta directiva.

Más información y siguientes pasos

Si se siente inspirado y desea profundizar en los elementos utilizados en este flujo de trabajo, aquí tiene algunos recursos que son un buen lugar para continuar:

• 'Estrategia de ramificación' (AWS | Azure | GCP)
  Aprenda cómo se fusionan e implementan los cambios utilizando un modelo de ramificación que sigue las mejores prácticas.
• Declarative Automation Bundles (AWS | Azure | GCP)
  Aprenda cómo se utilizan los Asset Bundles para empaquetar e implementar recursos de Databricks de manera consistente en todos los entornos.
• CI/CD para el despliegue automatizado en Databricks (AWS | Azure | GCP)
  Aprenda cómo implementar CI/CD con scripts iniciales de GitHub Actions (AWS | Azure | GCP)
• Uso de Asset Bundles desde la UI del espacio de trabajo de Databricks (AWS | Azure | GCP)
  Aprenda a crear, editar y desplegar bundles directamente desde el espacio de trabajo.
• Carpetas respaldadas por Git en Databricks (AWS | Azure | GCP)
  Aprenda cómo funciona la integración de Git en Databricks y cómo encaja el control de versiones en los flujos de trabajo de análisis diarios.

Si está listo para dar el siguiente paso con Databricks AI/BI, puede elegir cualquiera de las siguientes opciones:

• Edición gratuita y de prueba: Obtenga experiencia práctica registrándose en nuestra edición gratuita o de prueba.
• Documentación: Profundice en los detalles con nuestra documentación.
• Página web: Visite nuestra página web para obtener más información.
• Demos: Vea nuestros videos de demostración, realice recorridos por el producto y obtenga tutoriales prácticos para ver AI/BI en acción.
• Capacitación: Comience con la capacitación gratuita sobre el producto a través de Databricks Academy.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original