Dashboards demo con Lightdash

Encargo puntual: levantar Lightdash desde cero y poblarlo con dashboards reales sobre trivasa_dw, para tener un demo funcional de BI self-service más allá de Metabase/Superset. Cubre las tres piezas que se construyeron — el proyecto dbt, el despliegue de Lightdash, y los 3 dashboards — y los dos bugs que aparecieron después de que todo ya estaba “funcionando”.

Proyecto dbt: de raw.* a modelos explorables

Lightdash no navega tablas crudas — necesita un proyecto dbt con dimensiones y métricas anotadas para construir sus “explores”. No existía ninguno real (confirmado en Stack de BI explorado, no adoptado), así que se construyó desde cero en trivasa-bi-dev/dbt/trivasa_dbt/: 14 modelos de staging (1:1 con raw.*, solo renombrado de columnas) y 6 marts con métricas de negocio ya definidas — inventario de tablas y detalle de por qué fct_movimientos es vista y no tabla en Lightdash § Proyecto dbt.

Los 6 marts cubren cuatro dominios: compras (fct_compras, fct_ordenes_compra), inventario (fct_existencias, fct_movimientos), catálogo de producto (dim_producto) y gasto fiscal (fct_gastos_cfdi, sobre raw_sat.cfdi_recibidos).

Despliegue de Lightdash: la parte que no salió a la primera

Resumen — detalle exhaustivo (comandos exactos, tiempos, tamaños de capa) en sources/trivasa/lightdash-dashboards-demo/despliegue-cierre.md, referenciado desde README del directorio.

• El pull de la imagen (14.1GB) falló dos veces antes de completar. Primero con un error real de containerd/overlayfs al extraer la capa de node_modules (UtimesNanoAt: no such file or directory) bajo presión de memoria; después porque el tag :latest cambió de versión en Docker Hub a mitad de la segunda descarga, invalidando el caché ya bajado. Se resolvió liberando RAM del host antes del tercer intento: se decomisionó Authentik (no estaba en uso) y se quitó un contenedor minio standalone (experimento fallido, sin relación con lightdash-minio) — ver ctunlinux § Docker para el inventario actualizado.
• Conectar el warehouse necesitó sslmode: disable en dos lugares distintos (el proyecto de Lightdash y ~/.dbt/profiles.yml del CLI) porque postgres-dw no tiene SSL habilitado y ambos clientes lo negocian por default — ver Lightdash § Conexión a trivasa_dw.
• No existe endpoint de API para crear el primer usuario/organización de forma documentada en esta versión (1.107.0) — se reversó desde las rutas compiladas del propio contenedor (dist/generated/routes.js) y el bundle del frontend. Todos los endpoints usados, con su body exacto, en sources/trivasa/lightdash-dashboards-demo/api-referencia.md.

Los 3 dashboards

Todos en el space “Trivasa” (a7a60416-2048-4f79-9ec4-3b447864b25f), creados por API con datos reales de trivasa_dw (no datos de ejemplo) — 17 gráficas en total, layout de grid automático (Lightdash lo calcula solo, no se especificó posición por tile):

Dashboard	Fuente (mart)	Gráficas
Compras	fct_compras	Total comprado y # de compras (big number), tendencia mensual (barras), top proveedores (pie), compras por sucursal (barras horizontales)
Inventario y Movimientos	fct_existencias + fct_movimientos	Valor de inventario y existencia disponible (big number), movimientos por mes (línea de área), valor por categoría (pie), valor por almacén (barras horizontales), top productos por costo movido (tabla)
Gastos y Facturación (CFDI)	fct_gastos_cfdi	Total gastado, # facturas e IVA total (big number), gasto por mes (barras), gasto por tipo de comprobante (pie), top emisores (tabla)

Marcados como favoritos (⭐) para acceso rápido — la pantalla “Welcome” con pinned items de Lightdash es una función de Enterprise que no está disponible en este deployment (sin licencia); confirmado por error de runtime Unable to initialize service 'projectHomepageService' — no factory or provider al intentar usarla vía API. Favoritos es el sustituto real en la edición gratuita.

Bugs encontrados después del despliegue

Los dos aparecieron en producción, ya con el link compartido — ninguno estaba presente al momento de crear los dashboards, ambos por acciones posteriores sobre el mismo contenedor/proyecto:

1. getaddrinfo EAI_AGAIN postgres-dw — el contenedor lightdash perdió la conexión a la red postgres-warehouse_default al recrearse (cambio de SECURE_COOKIES para poder autenticar por API, ver Lightdash § gotcha SECURE_COOKIES). La conexión a esa red se había hecho a mano (docker network connect), no declarada en el docker-compose.yml — cualquier recreación del contenedor la perdía. Fix permanente: declarar ambas redes en el compose (ver Lightdash § Red).
2. relation "analytics_marts.fct_movimientos" does not exist — fct_movimientos se cambió a vista durante el despliegue original (por espacio en disco) pero nunca se volvió a correr dbt run después del cambio — solo lightdash deploy, que compila el proyecto pero no ejecuta nada contra Postgres. La vista física nunca se creó hasta que se detectó el error en el dashboard en vivo. Ver Lightdash § Cómo desplegar un cambio de modelo para el flujo correcto (dos pasos, no uno).
3. fct_movimientos inflaba 4.28M filas reales a 90.4M — bug de join, no de despliegue: el left join contra stg_almacen usaba solo almacen_id, pero esa tabla es una relación almacén × sucursal (un mismo almacén aparece hasta 40 veces). Se detectó al depurar por qué el dashboard de Inventario nunca terminaba de renderizar como imagen — ver Carrusel de dashboards para TV § El verdadero motivo para el diagnóstico completo y el fix (agregar sucursal_id al join).

Véase también

• Lightdash — referencia operativa del servicio: arquitectura, conexión, credenciales, flujo de despliegue de un modelo nuevo.
• Warehouse Postgres trivasa_dw — la fuente de datos de los 6 marts.
• Carrusel de dashboards para TV — los 3 dashboards de esta página, rotando en una sola pantalla, más el fix del bug #3 de arriba.
• sources/trivasa/lightdash-dashboards-demo/ — cierre técnico completo, ver README del directorio.