Filtros de fecha en Apache Superset: soluciones alternativas

Apache Superset: Cómo Superar las Limitaciones del Filtro de Fecha en las Versiones 3.x–6.x

Apache Superset no permite vincular un filtro de fecha a una columna de tiempo específica a nivel de gráfico; su selección siempre es global para el conjunto de datos y se determina por el orden lexicográfico de los nombres de campo. Esto provoca problemas críticos en entornos de producción: cambios descontrolados en la lógica de negocio, conflictos entre paneles y regresiones ocultas cuando se modifica la columna de tiempo predeterminada. En este artículo, exploramos las razones arquitectónicas detrás de estas limitaciones, las soluciones alternativas probadas y las restricciones técnicas de las soluciones actuales.

Por qué Superset elige bot_profile__updated—y por qué eso es peligroso

Superset asigna automáticamente una columna de tiempo predeterminada al crear un conjunto de datos, basándose únicamente en el orden alfabético de las columnas con tipos TIMESTAMP, DATETIME o DATE. En el conjunto de datos messages, el campo bot_profile__updated termina primero en la clasificación lexicográfica entre bot_profile__updated, ts, created_at y updated_at. Este comportamiento está codificado en superset/datasets/models.py, donde el método get_default_time_column() utiliza sorted([col for col in dataset.columns if col.is_temporal]) sin considerar la semántica, el contexto empresarial ni los metadatos.

El riesgo clave es que cambiar la columna de tiempo predeterminada en un conjunto de datos afecta todos los gráficos y paneles que lo utilizan, incluso si lógicamente corresponden a diferentes ejes temporales. Por ejemplo:

• El gráfico “Actividad del bot” debería filtrarse por ts (el momento del evento);
• El gráfico “Actualizaciones del perfil” debería filtrarse por bot_profile__updated (el momento en que se actualizó la entidad);
• Ambos utilizan el mismo conjunto de datos messages.

Si un administrador cambia la columna de tiempo predeterminada a ts, el segundo gráfico comenzará a mostrar datos en el eje temporal equivocado—sin errores, registros ni advertencias. Una notificación amarilla en la interfaz simplemente recuerda a los usuarios este problema, pero no bloquea la operación.

Filtro de columna de tiempo: una solución funcional con limitaciones sistémicas

A partir de la versión 3.0, Superset introdujo el filtro Time Column, que muestra una lista desplegable de todas las columnas temporales del conjunto de datos y permite a los usuarios seleccionar una. Sin embargo, su implementación no es una solución, sino más bien una abstracción sobre el defecto existente:

• El valor seleccionado en el Filtro de columna de tiempo sobrescribe globalmente la default_time_column para todos los filtros de fecha en ese panel;
• Es imposible agregar dos filtros de fecha independientes (por ejemplo, “período del evento” y “período de procesamiento”)—ambos usarán el mismo valor seleccionado;
• El filtro no admite expresiones condicionales (WHERE ts BETWEEN ... AND ... AND updated_at > ...);
• Solo afecta el filtrado mediante WHERE, no las agregaciones en consultas SQL.

Esto lleva a un patrón de “proxy de filtro”, donde los desarrolladores se ven obligados a duplicar conjuntos de datos con diferentes default_time_columns para aislar la lógica. Este enfoque viola DRY, complica el mantenimiento y aumenta la carga sobre los metadatos.

Soluciones técnicas prácticas para desarrolladores intermedios y senior

Para garantizar una operación estable de Superset en producción, se recomiendan los siguientes enfoques:

• Creación de conjuntos de datos virtuales mediante SQL Lab

- Para cada contexto temporal único, crear un conjunto de datos SQL separado con un SELECT ... AS time_dimension FROM ... explícito;

- Fijar el nombre time_dimension como la única columna temporal para evitar ambigüedades;

- Ejemplo:

SELECT 
  ts AS time_dimension,
  user_id,
  event_type,
  payload
FROM messages
WHERE ts IS NOT NULL

• Uso de extra_json para la vinculación forzada

- En el editor de conjuntos de datos, especificar lo siguiente en el campo Extra JSON:

{"default_time_column": "ts"}

- Esto solo funciona si el campo correspondiente existe en columns.extra y requiere actualizaciones manuales cuando cambia el esquema;

• Parchear Dataset.get_default_time_column() en una imagen personalizada

- Añadir soporte para anotaciones mediante comentarios de base de datos (COMMENT ON COLUMN messages.ts IS 'time_dimension:primary');

- Analizar estos comentarios en get_default_time_column();

- Requiere integración CI/CD y pruebas de compatibilidad con nuevas versiones.

• Abandonar los filtros incorporados en favor de gráficos SQL parametrizados

- Mover todos los filtros temporales a las condiciones WHERE del gráfico utilizando {{ filter_values('date_range') }};

- Esto permite múltiples filtros independientes y condiciones complejas;

- La desventaja es perder la interfaz visual de filtros en la UI del panel.

Lo que importa

• Superset no distingue el propósito semántico de las columnas temporales: ts, created_at y updated_at se tratan como cadenas equivalentes para la ordenación.
• Cambiar la default_time_column en un conjunto de datos no es una operación segura—afecta instantáneamente a todos los gráficos dependientes sin ningún tipo de retroalimentación.
• El Filtro de columna de tiempo no es un mecanismo para vincularse a una columna específica; es un interruptor global de tiempo para todo el panel.
• Las versiones 5.x y 6.x no resuelven el problema raíz: la lógica para seleccionar el tiempo sigue en models.py, sin refactorización de la arquitectura de filtrado.
• La única forma confiable de lograr aislamiento es separar físicamente los conjuntos de datos o pasar a visualizaciones SQL parametrizadas.

En Apache Superset, el filtrado de fechas sigue siendo uno de los puntos más débiles de la arquitectura. La falta de soporte para múltiples ejes temporales a nivel de conjunto de datos, la dependencia rígida del orden lexicográfico de los nombres de campo y la ausencia de un mecanismo para anotar columnas hacen imposible modelar correctamente flujos de eventos con múltiples dimensiones temporales. Esto es especialmente crítico para análisis de IoT, transacciones financieras y registros de microservicios, donde cada registro contiene al menos tres marcas de tiempo: event_time, ingestion_time y processing_time. La comunidad ha propuesto una solución a través del issue #32496, pero aún no hay un PR que la implemente. Por ahora, la mejor práctica es diseñar conjuntos de datos de modo que cada uno contenga exactamente una columna temporal significativa, o abandonar los filtros incorporados en favor de soluciones controladas basadas en SQL.

— Editorial Team