Entrevista de Ingeniería de Datos: ¿Cómo comparten BI, notebooks y APIs una capa semántica gobernada?

Planteamiento y alcance

Una empresa descubre que “cliente activo”, “ingresos” y “retención” utilizan diferente SQL en distintos paneles de control (dashboards). Diseñe una capa semántica compartida por BI, notebooks, APIs y futuros agentes de automatización. Debe admitir dimensiones, granularidades temporales, filtros, permisos, versiones históricas y datos casi en tiempo real. Explique cómo evitar construir otra plataforma de reportes imposible de probar.

Qué está evaluando el entrevistador

Separe entidades, dimensiones, medidas, agregación y semántica de métricas antes de discutir sobre herramientas. Luego maneje la granularidad de los joins, el conteo duplicado, las zonas horarias y los datos tardíos. Trate una métrica como un contrato de producto versionado con definición, propietario, origen, granularidad admitida, estado de calidad y compatibilidad, no como un directorio de fragmentos de SQL.

Aclaraciones antes de responder

1. ¿Cuál es la granularidad de los hechos (fact grain)? Mezclar pedidos, líneas de pedido y eventos puede duplicar el conteo de ingresos.
2. ¿Qué dimensiones y granularidades temporales se necesitan? No todas las combinaciones son seguras; publique una matriz de soporte.
3. ¿Cuáles son los objetivos de frescura y consistencia? El streaming, el procesamiento por lotes diario (batch) y los datos de backfill tienen diferentes estados de visibilidad.
4. ¿Quién puede publicar definiciones y leer dimensiones sensibles? Los permisos de métricas no deben eludir la seguridad a nivel de fila o de columna.
5. ¿Deben ser reproducibles las definiciones históricas, o solo se necesita la definición actual? Esto determina el enrutamiento de versiones, las instantáneas (snapshots) y el costo de recálculo.

Diseño recomendado y derivación

Cree una entidad inmutable de definición de métrica: nombre, descripción, expresión de medida, agregación predeterminada, dimensiones, semántica temporal, filtros, origen, propietario, versión, estado y SLO de calidad. Una consulta hace referencia a un ID de métrica, dimensiones y ventana de tiempo; un compilador genera SQL o enruta a una tabla preagregada.

Antes de la compilación, verifique que las rutas de join sean únicas, la agregación coincida con la granularidad, los filtros se puedan enviar hacia abajo (push down) y el usuario tenga acceso a las columnas. Para recuentos distintos (distinct counts), ratios y métricas de ventana, registre el denominador, la clave de deduplicación y la política de nulos en lugar de permitir que cada herramienta adivine.

metric: active_customers
version: 3
owner: growth-data
source: mart_customer_daily
measure: count_distinct(customer_id)
dimensions: [plan, region]
time_grain: [day, week, month]
freshness_slo: 2h
status: published

Publique en dos vías: compare una versión nueva con la antigua en consultas en la sombra (shadow queries), luego expóngala a un conjunto pequeño de espacios de trabajo; bloquee la promoción cuando la diferencia supere un umbral. Las claves de caché deben incluir la versión de la métrica, dimensiones, filtros y la marca de agua de datos (watermark), o un cambio de versión puede leer un resultado antiguo. Establezca presupuestos, tiempos de espera (timeouts) y alternativas de respaldo preagregadas para consultas costosas.

Alternativas y compensaciones

Incrustar la lógica en cada herramienta de BI permite entregas rápidas pero bifurca las definiciones. Un único conjunto de datos físicos depurado es simple pero no puede expresar todas las granularidades o permisos. Una capa semántica central brinda consistencia y APIs reutilizables a costa de un compilador, gobernanza de versiones, mapeo de permisos y depuración. Un equipo pequeño puede comenzar con unas pocas métricas centrales y un solo consumidor antes de abrir el acceso a múltiples herramientas.

Modos de falla, límites y contraejemplos

• Definir los ingresos como sum(amount) ignorando reembolsos, impuestos, monedas y joins de pedidos duplicados.
• Permitir que una métrica lea tablas sin procesar arbitrarias, eludiendo los filtros de calidad y los permisos de columna.
• Cambiar el significado de una métrica sin una nueva versión, modificando silenciosamente los paneles de control históricos.
• Tratar la tasa de aciertos de caché (cache hit rate) como corrección ignorando las marcas de agua (watermarks), los eventos tardíos y la visibilidad de backfills.
• Generar una consulta de producto cartesiano para cada combinación de dimensiones; publique combinaciones no admitidas y ofrezca una agregación más segura en su lugar.

Lista de verificación de pruebas y verificación

Mantenga una consulta dorada (golden query) y un conjunto de datos fijo y pequeño para cada métrica. Pruebe la agregación, el denominador, la zona horaria, los nulos, los joins duplicados, los eventos tardíos y las diferencias de versión. Agregue pruebas de contrato de esquema, permisos, compilador y caché; compare los resultados y el costo frente a muestras de producción. Los filtros de publicación deben verificar la integridad de la definición, la frescura de la fuente, el SLO de calidad, el mapeo de permisos y las diferencias entre lo antiguo y lo nuevo.

Preguntas de seguimiento

¿Cómo maneja un cambio incompatible (breaking change) en la definición de una métrica?

Publique una nueva versión, conserve el enrutamiento para la versión anterior, marque una fecha de obsolescencia, notifique a los dependientes y elimínela solo después de la migración. Los informes históricos deben seleccionar la versión antigua para un recálculo reproducible; nunca reutilice un número de versión.

¿Cómo puede la capa servir datos casi en tiempo real y por lotes (batch)?

Haga que el origen y la marca de agua (watermark) formen parte de la definición, y devuelva el estado de frescura y completitud con cada resultado. Una fuente de streaming puede proporcionar un resultado provisional que el procesamiento por lotes concilie más tarde; ambas rutas deben compartir la semántica y las reglas de deduplicación.

¿Cómo evita que los agentes de lenguaje natural hagan un uso indebido de las métricas?

Exponga solo métricas publicadas, dimensiones admitidas y alcances autorizados, devolviendo un plan de consulta explicable y la versión de la definición. Rechace las solicitudes que no puedan probar la granularidad, el permiso o la frescura; no permita que un agente redacte libremente SQL de tablas sin procesar.