Stack de BI explorado, no adoptado

stack/ en la raíz del repo trivasa-bi-dev contiene scaffolding de un stack de BI adicional — Superset, Lightdash, un Postgres standalone (todos vía docker-compose), más proyectos boilerplate de Evidence.dev y dbt — que se probó en algún punto pero no se adoptó: no corre en producción, no hay dashboards reales construidos, y buena parte del contenido es la plantilla/ejemplo por defecto de cada herramienta sin modificar.

Qué hay en cada carpeta

  • stack/superset/, stack/lightdash/ — docker-compose.yml con secreto/contraseña de ejemplo hardcodeados (trivasa-secret-123, trivasa123) — configuración de prueba, no lista para producción tal cual.
  • stack/postgres/ — otro Postgres standalone vía docker-compose (puerto 5432), distinto del warehouse real trivasa_dw documentado en Warehouse Postgres (que corre en localhost:5433) — no confundir los dos si se retoma este stack.
  • stack/trivasa-evidence/ — proyecto Evidence.dev sin modificar salvo una página (pages/ventas.md) con SQL de ejemplo contra un schema trivasa.ventas que no corresponde al esquema real (raw.*) del warehouse documentado — experimento aislado, no conectado a nada vigente.
  • stack/trivasa_dbt/ — proyecto dbt scaffold (dbt init sin modelos propios) — consistente con lo ya documentado en Convención de esquemas: no existe ningún modelo dbt real todavía, todo el trabajo de BI vive en raw + lógica Python/SQL ad-hoc.

Por qué se documenta si no está en uso

Para que una sesión futura que encuentre estas carpetas no asuma que son infraestructura viva ni pierda tiempo tratando de conectarlas a datos reales — y para no reinstalar/reconfigurar herramientas ya evaluadas sin revisar primero si vale la pena retomarlas. Metabase sigue apareciendo como opción real de destino en varios reportes (ver Trazabilidad Consumo Interno); Lightdash y Evidence quedaron solo como exploración sin seguimiento.

Actualización 2026-08-07: Superset sí se adoptó, pero no este scaffold

stack/superset/ (el docker-compose.yml con secretos de ejemplo descrito arriba) ya no existe en el repo — se borró en la limpieza que también generó esta página. Sin embargo, hoy corre un Superset real en producción en ctunlinux (superset.frento.com.mx), desde un clon completo y actualizado del repo oficial apache/superset en trivasa-bi-dev/superset/ (no la carpeta stack/superset/ de este documento) con su propio docker-compose.yml. Es un deployment distinto y posterior al que describe esta página — no se confirmó qué dashboards o fuentes de datos tiene configurados; pendiente de documentar en su propia página si se sigue usando.

Actualización 2026-08-09: Lightdash y dbt sí se adoptaron, pero no este scaffold

Mismo patrón que Superset arriba: stack/lightdash/ y stack/trivasa_dbt/ (los descritos en esta página, con secretos de ejemplo y sin modelos propios) siguen sin uso. Pero hoy corre un Lightdash real en producción en ctunlinux (dash.frento.com.mx), desde un proyecto dbt propio en trivasa-bi-dev/dbt/trivasa_dbt/ (no stack/trivasa_dbt/) y un docker-compose.yml independiente en trivasa-bi-dev/lightdash/ (no stack/lightdash/) — con 3 dashboards reales sobre trivasa_dw. Ver Lightdash y Dashboards demo con Lightdash.

Evidence.dev sigue sin adoptarse — nada cambió en stack/trivasa-evidence/.

Cierre 2026-08-09: el Superset real (no el stack/) también se decomisionó

El Superset de producción que documenta la actualización 2026-08-07 de arriba (trivasa-bi-dev/superset/, no stack/superset/) se eliminó por completo el 2026-08-09 — contenedores, imágenes y la carpeta entera del repo (463MB). Sí tenía contenido real (un dashboard “Compras” conectado a TRIVASADB vía SQL Server, no solo datos de ejemplo), pero seguía siendo dev sin nada en producción — se borró sin backup por decisión explícita. Detalle en ctunlinux § Docker.

Con esto, del stack de BI original de esta página solo sigue vivo Metabase (ya estaba en producción antes de que existiera este documento) y Lightdash — Superset pasó por scaffold → producción real → decomisionado, todo documentado en esta misma página como referencia de por qué no volver a levantar stack/superset/ ni trivasa-bi-dev/superset/ sin revisar primero si vale la pena.

Véase también