Prompt y contexto
El DAU, los ingresos y la tasa de conversión difieren entre los reportes. Diseña una capa semántica gobernada para que los analistas, BI, las aplicaciones y los trabajos automatizados compartan las definiciones de métricas.
Analiza los contratos de métricas, el nivel de detalle de las entidades (entity grain), las dimensiones, los grafos de joins, la semántica temporal, las versiones, los permisos, el almacenamiento en caché, las pruebas de calidad y la migración. No asumas dbt o Looker; son opciones de implementación, no la respuesta. Las inconsistencias son un escenario ficticio de práctica.
Qué está evaluando el entrevistador
Definiciones consistentes
Convertir el nombre de una métrica en numerador, denominador, filtros, ventana de tiempo, deduplicación y dimensiones predeterminadas en lugar de otra consulta SQL copiada.
Nivel de detalle y joins
Identificar el nivel de detalle de la tabla de hechos, evitar la duplicación de muchos a muchos y rechazar combinaciones que no sean semánticamente componibles.
Gobernanza y cambio
Las definiciones necesitan control de versiones, revisión, obsolescencia (deprecation) y ventanas de compatibilidad. Los usuarios de BI no deben crear una segunda fuente de verdad.
Usabilidad
Una capa semántica necesita contratos legibles por máquinas y documentación para personas con propietarios, ejemplos y estado de calidad.
Preguntas para clarificar primero
- ¿Qué significan exactamente DAU, ingresos y conversión?
- ¿Los consumidores necesitan SQL, una API, un explorador de BI o gráficos incrustados?
- ¿Cuáles son los niveles de detalle de origen y las zonas horarias?
- ¿Pueden coexistir los valores casi en tiempo real y los finales revisados?
- ¿Los permisos se gestionan a nivel de conjunto de datos, fila, columna o dimensión?
- ¿Durante cuánto tiempo deben seguir siendo compatibles los reportes heredados?
Una respuesta de 30 segundos
“Definiría un contrato versionado que contenga nombre, descripción, numerador, denominador, filtros, granularidad de tiempo, zona horaria, nivel de detalle de la entidad, dimensiones, propietario, sensibilidad y estado de calidad. El motor de consultas utiliza un grafo de joins declarado y rechaza rutas inseguras de muchos a muchos o de niveles de detalle incompatibles.
Las definiciones se revisan en control de versiones, con una ventana para versiones anteriores y obsolescencia. Las APIs de SQL y los adaptadores de BI devuelven la versión de la definición y la frescura de los datos. Las pruebas cubren fixtures, conciliación, joins duplicados, latencia, permisos y regresiones históricas.”
Respuesta detallada paso a paso
Paso 1: Inventariar casos de uso
Enumera las consultas, la latencia y la precisión requeridas por los reportes, las alertas, los productos y los experimentos. Haz un piloto con dos o tres métricas de alto valor antes de migrar cada archivo SQL.
Paso 2: Escribir el contrato
Registra el nombre de la métrica, el significado de negocio, la medida, los filtros, la ventana de tiempo, la zona horaria, la entidad, las dimensiones, el propietario, la sensibilidad, la versión y el SLO de frescura.
Paso 3: Modelar el nivel de detalle y los joins
Declara la clave primaria y el nivel de detalle de cada modelo. Habilita únicamente los joins cuya cardinalidad y dirección de agregación sean seguras; preagrega, usa tablas puente o rechaza las rutas de muchos a muchos.
Paso 4: Manejar el tiempo y las revisiones
Define la hora del evento, la hora de procesamiento, la zona horaria, los datos tardíos y las reglas de revisión final. Los resultados casi en tiempo real deben exponer la frescura y el estado final.
Paso 5: Publicar y autorizar
Almacena las definiciones en control de versiones y publícalas tras la revisión del propietario y de la calidad de los datos. Autoriza conjuntos de datos, filas, columnas y dimensiones; audita el acceso a métricas sensibles. Establece una fecha límite de migración para las versiones antiguas.
Paso 6: Probar y servir
Utiliza fixtures, muestras de conciliación, comprobaciones de joins duplicados, pruebas de frescura, de nulos y de distribución. Devuelve valores a través de SQL, BI o APIs incrustadas junto con la versión, la zona horaria y el estado de calidad.
Respuesta modelo
“Haría un piloto con DAU e ingresos. Cada definición registra numerador, denominador, filtros, hora del evento, zona horaria, nivel de detalle de la entidad, dimensiones permitidas, propietario, sensibilidad, versión y frescura. El DAU debe indicar si deduplica personas o dispositivos; los ingresos deben definir el reconocimiento, reembolsos e impuestos.
La capa gestiona el nivel de detalle del modelo y un grafo de joins. Las rutas de muchos a muchos se preagregan o se rechazan. Las definiciones se revisan en Git y se prueban antes de publicarse; las versiones antiguas siguen disponibles durante una ventana de migración, y las respuestas incluyen la versión y la frescura. Los permisos cubren conjuntos de datos y dimensiones, con auditorías de acceso.
La validación incluye muestras de conciliación, conteos de duplicados, datos tardíos, zona horaria, permisos, frescura y regresión histórica. Migra primero los reportes de alto valor y explica las diferencias entre los resultados antiguos y los nuevos en lugar de reescribir cada consulta SQL a la vez.”
Errores comunes
- Almacenar solo el nombre de una métrica sin numerador, denominador y filtros.
- Usar una tabla ancha para ocultar diferentes niveles de detalle de los hechos.
- Permitir joins arbitrarios que dupliquen hechos.
- Mezclar la hora del evento, la hora de procesamiento y la zona horaria.
- Omitir versiones, propietarios, obsolescencia y ventanas de migración.
- Probar el éxito de la consulta sin la conciliación de resultados o frescura.
- Construir únicamente un complemento de BI sin un contrato legible por máquinas.
- Proteger el panel pero no las dimensiones subyacentes o la auditoría de consultas.
Preguntas de seguimiento
Pregunta de seguimiento 1: ¿Cómo evitas la duplicación de ingresos?
Declara el nivel de detalle y la clave única de los ingresos, preagrega a la entidad objetivo antes de los joins, rechaza rutas inseguras de muchos a muchos y concilia contra totales conocidos.
Pregunta de seguimiento 2: ¿Puede un cambio de definición romper a los usuarios aguas abajo?
Publica una nueva versión o un campo compatible, mantén la versión anterior hasta una fecha límite, incluye la versión en las respuestas y exige la aprobación del propietario y del consumidor.
Pregunta de seguimiento 3: ¿Cómo pueden coexistir los valores casi en tiempo real y los finales?
Devuelve el valor con frescura, marca de agua (watermark) y estado final. Los consumidores eligen la latencia y la semántica de revisión aceptables en lugar de tratar un valor provisional como datos financieros finales.
Pregunta de seguimiento 4: ¿Cómo autorizas las métricas?
Combina políticas de conjunto de datos, filas, columnas y dimensiones con el principio de menor privilegio. Registra el solicitante, la versión de la definición y la exportación, y luego audita periódicamente.
Pregunta de seguimiento 5: ¿Cómo demuestras que la capa crea valor?
Compara los conflictos de definición, el SQL duplicado, las diferencias de conciliación, el éxito de las consultas, la frescura, la adopción y los incidentes antes y después de la migración, mientras compruebas que los usuarios puedan explicar los resultados.