Preguntas de entrevista Ingeniero de datos

Empiezo por entender el SLA: ¿qué tan actualizados deben estar los datos, y cuál es el coste de un fallo del pipeline aguas abajo? Esas dos respuestas orientan cada decisión arquitectónica. Para la fiabilidad, construyo pipelines idempotentes siempre que sea posible, de modo que volver a ejecutar un trabajo tras un fallo produzca el mismo resultado sin duplicar datos. Uso checkpointing para trabajos de larga duración para que los fallos no reinicien desde el principio. Añado controles de calidad de datos en cada etapa: validación de esquema en la ingestión, comprobaciones de recuento de filas entre etapas, y detección de anomalías en las métricas clave en la salida. Para la escalabilidad, separo el cómputo del almacenamiento para escalarlos independientemente, y diseño para el procesamiento incremental en lugar de recargas completas. La observabilidad se integra desde el principio: cada pipeline emite metadatos de ejecución.

La calidad de los datos no es una preocupación separada del diseño del pipeline; forma parte de él. Mi enfoque tiene tres capas. Primero, validación de esquema y tipo en la ingestión: si los datos upstream cambian de forma inesperadamente, quiero que el pipeline falle de forma visible en el punto de entrada en lugar de propagar datos incorrectos silenciosamente. Segundo, comprobaciones de reglas de negocio entre etapas: recuentos de filas que difieren significativamente de la ejecución anterior, tasas de nulos por encima de un umbral en campos obligatorios, o fallos de integridad referencial. Tercero, monitoreo en la salida: sigo las métricas de negocio clave a lo largo del tiempo y alerto cuando se salen de los rangos esperados. Cuando se detecta un problema de calidad, prefiero poner en cuarentena los registros afectados y continuar procesando datos limpios en lugar de detener todo el pipeline.

Empiezo por el requisito de negocio, no por la tecnología. La pregunta clave es: ¿cuál es la latencia máxima aceptable entre que ocurre un evento y que está disponible para análisis? Si la respuesta son horas o días, el procesamiento por lotes es casi siempre más sencillo y rentable. Si la respuesta son minutos o segundos, el streaming se vuelve necesario. Más allá de la latencia, considero la complejidad operativa: los sistemas de streaming son significativamente más difíciles de depurar, reproducir y mantener que los trabajos batch. Para la mayoría de los casos de uso analíticos en los que he trabajado, el micro-batch (ejecutándose cada pocos minutos con Spark Structured Streaming o Flink) ofrece una latencia aceptable a un coste operativo mucho menor. Solo me comprometo con una arquitectura de streaming pura cuando el requisito de latencia genuinamente no puede cumplirse con micro-batch.

Las herramientas de IA han cambiado algunas partes de mi flujo de trabajo de forma práctica. Para escribir y revisar SQL, especialmente funciones de ventana complejas o consultas de optimización, la IA me ayuda a iterar más rápido y detecta patrones que podría pasar por alto. Para escribir documentación de pipelines y entradas del diccionario de datos, la IA redacta contenido que luego reviso y ajusto, lo que ahorra tiempo significativo en una tarea que los ingenieros suelen saltarse. Donde la IA se ha vuelto genuinamente útil es en la detección de anomalías en las salidas del pipeline: en lugar de escribir reglas de umbral codificadas, puedo usar modelos estadísticos para señalar cuándo una métrica se comporta de forma inusual dado su patrón histórico. Soy cuidadoso al usar IA para el diseño de esquemas o las decisiones de modelado de datos, porque esas decisiones tienen consecuencias a largo plazo y el modelo no tiene el contexto de negocio completo.

Un trabajo ETL diario que alimentaba nuestro modelo de atribución de marketing falló silenciosamente: se completó sin errores pero produjo un resultado parcial debido a un timeout en una de las llamadas a la API fuente. El equipo de marketing ejecutó su análisis semanal de gasto con datos incompletos y detectó la discrepancia ellos mismos dos días después. Cuando se escaló el problema, diagnostiqué la causa raíz en aproximadamente una hora: el timeout de la API estaba demasiado bajo y el trabajo no tenía validación del recuento de registros al final. Solucioné el problema inmediato aumentando el timeout y volviendo a ejecutar el rango de fechas afectado. Luego añadí una comprobación del recuento de filas en la etapa final y una alerta que se activa si el recuento de filas de salida cae por debajo del 90% de la media de siete días. La parte más difícil fue reconstruir la confianza con el equipo de marketing.

Migramos nuestra base de datos transaccional principal de un esquema Postgres monolítico a un nuevo esquema que admitía multi-tenancy, manteniendo el sistema en producción durante todo el proceso. El reto era que nuestros pipelines de analytics, herramientas de reporting y tres microservicios aguas abajo dependían todos del esquema antiguo. Mi enfoque fue ejecutar los esquemas antiguo y nuevo en paralelo durante seis semanas, escribiendo en ambos y leyendo desde el antiguo mientras se validaba el nuevo. Construí un trabajo de reconciliación que se ejecutaba cada noche y comparaba los recuentos de filas y los agregados clave entre los dos esquemas, alertando ante cualquier divergencia. La migración de cada consumidor se hizo de forma incremental: analytics primero (menor riesgo), luego el reporting, luego los microservicios. La migración completa tardó diez semanas sin pérdida de datos ni tiempo de inactividad.

Un trabajo Spark nocturno que agregaba datos de actividad de usuarios tardaba seis horas en completarse, adentrándose en el horario laboral y retrasando los dashboards de los que dependía el equipo de producto. Perfilé el trabajo y encontré tres problemas: una join con mucho shuffle que no aprovechaba los broadcast joins para una pequeña tabla de lookup, un escaneo completo de tabla en una tabla particionada porque el filtro de partición se aplicaba después del escaneo, y un paso de salida que escribía miles de archivos pequeños. Reemplacé la join grande por un broadcast join (la tabla de lookup era inferior a 100 MB), empujé el filtro de partición al paso de lectura, y unifiqué la salida en un número razonable de archivos. El tiempo de ejecución bajó de seis horas a menos de 45 minutos. La corrección del filtro de partición sola representó la mayor parte de la ganancia, reduciendo los datos escaneados al 3% de la tabla completa.

Un data warehouse almacena datos estructurados y procesados optimizados para consultas analíticas. Aplica esquema en escritura, lo que significa que los datos se transforman y validan antes de entrar en el warehouse. Un data lake almacena datos brutos en su formato original, estructurado o no, y aplica esquema en lectura. Es más barato para almacenar grandes volúmenes y más flexible para análisis exploratorio o casos de uso de ML donde no se conocen los patrones de acceso de antemano. La respuesta práctica: la mayoría de las organizaciones necesitan ambos. El data lake contiene datos brutos e intermedios; el data warehouse contiene datos curados, listos para que los analistas los consulten directamente. El patrón que más he usado es la arquitectura medallion (capas raw, clean, curated) donde la capa curated es el warehouse y las capas anteriores viven en almacenamiento de objetos.

Empiezo por entender quién va a consultar estos datos y cómo. Los analistas y las herramientas de BI tienden a querer tablas amplias y desnormalizadas, fáciles de unir y rápidas de consultar. Los científicos de datos tienden a querer acceso a tablas más granulares. Para la mayoría de los casos analíticos uso un modelo dimensional (tablas de hechos y dimensiones) porque es bien conocido, funciona bien con almacenamiento columnar, y facilita la adición de nuevas dimensiones sin romper las consultas existentes. Evito los esquemas muy normalizados en la capa analítica porque el coste de los joins añade complejidad para los analistas. También pienso en las dimensiones de cambio lento desde el principio: si un cliente cambia de segmento, ¿las consultas quieren ver en qué segmento estaba en el momento del evento, o su segmento actual? Esa decisión debe tomarse en el momento del modelado.

Empezaría cuestionando si realmente necesita ser en tiempo real. Si la respuesta es sí, mi arquitectura tendría cuatro capas. Ingestión: los eventos fluyen desde los sistemas fuente a una cola de mensajes como Kafka o Pub/Sub, que desacopla productores de consumidores y ofrece capacidad de reproducción. Procesamiento de stream: un trabajo Flink o Spark Structured Streaming lee desde la cola, aplica transformaciones y agregaciones, y escribe resultados en la capa de servicio. Servicio: un almacén analítico rápido como ClickHouse, Druid o BigQuery maneja la carga de consultas de dashboards o aplicaciones. Monitoreo: el pipeline emite métricas de lag y alerto si el lag supera el objetivo. Las partes en las que más tiempo invierto desde el principio son el diseño del esquema en el punto de ingestión y decidir exactamente qué estado necesita mantenerse en el procesador de stream.