Preguntas de entrevista Data Engineer

¿Cuál es la diferencia entre ETL y ELT, y por qué ganó ELT?

ETL transforma los datos antes de cargarlos al warehouse, lo que tenía sentido cuando el storage y el cómputo del warehouse eran caros y rígidos. ELT carga datos crudos primero y transforma dentro del warehouse usando su propio motor. ELT ganó para analytics porque los warehouses de cloud hicieron el cómputo elástico y lo separaron del storage, así que mantener datos crudos te deja re-derivar modelos cuando los requisitos cambian en vez de reingestar desde sistemas fuente que ya no controlas.

¿Qué es un star schema y cuándo no usarías uno?

Un star schema tiene una tabla de hechos central de eventos con medidas numéricas, rodeada de tablas de dimensión desnormalizadas describiendo el contexto. Está optimizado para consultas analíticas: pocos joins, agregación predecible, fácil para herramientas de BI. Lo saltarías para un caso de uso puramente de event-streaming, para data science genuinamente exploratorio sobre eventos crudos, o cuando el warehouse es lo bastante columnar como para que una tabla ancha desnormalizada rinda mejor y cueste menos mantener.

Explica las slowly changing dimensions, particularmente Type 2.

Un SCD maneja atributos que cambian con el tiempo, como un cliente que se muda de ciudad. Type 1 sobreescribe el valor viejo, perdiendo historia. Type 2 inserta una fila nueva con fechas de validez y una bandera de actual, así un hecho unido por la surrogate key refleja el atributo como era en el momento del evento. Eso es lo que te deja responder "cuáles fueron las ventas por región el año pasado" correctamente en vez de reatribuir ventas viejas a la región nueva del cliente.

¿Qué son las window functions y dónde le ganan a un GROUP BY?

Una window function calcula sobre un conjunto de filas relacionadas con la fila actual sin colapsarlas, así mantienes el detalle a nivel de fila junto al agregado. Eso las hace la herramienta correcta para totales acumulados, ranking dentro de una partición, comparar una fila contra el promedio del grupo, y comparaciones lag/lead entre eventos consecutivos. Un GROUP BY te forzaría a agregar y luego unir de vuelta al detalle — más código, más shuffling, y más fácil de hacer mal.

¿Qué significa que un pipeline sea idempotente, y por qué importa?

Idempotente significa que correr la misma tarea para el mismo período dos veces produce el mismo resultado en vez de duplicar datos. Importa porque los reintentos son inevitables — una tarea falla a la mitad, alguien vuelve a correr ayer, un backfill se superpone con una corrida programada. Las implementaciones usuales son borrar y reescribir la partición destino, o un merge con clave en una clave de negocio en vez de un insert ciego. Los pipelines que solo funcionan si corren exactamente una vez se rompen la primera vez que se reintentan.

¿Cómo diseñas un DAG de Airflow que sea seguro para backfill?

Cada tarea debería parametrizarse por la fecha de ejecución lógica en vez de "ahora", así una corrida para una fecha vieja lee y escribe los datos de esa fecha. Las tareas deben ser idempotentes, así una re-corrida sobreescribe su propia partición. Configura reintentos sensatos con backoff, y usa max_active_runs y pools para que un backfill de dos años no sature el warehouse y mate de hambre a las corridas de producción. Las dependencias entre DAGs son más seguras expresadas como verificaciones de disponibilidad de datos que como horarios adivinados.

¿Qué es un shuffle en Spark y por qué es costoso?

Una transformación angosta como map o filter funciona dentro de una partición, así que no necesita movimiento de datos. Una transformación amplia como groupBy, join o repartition requiere que filas con la misma clave terminen en el mismo executor, lo que significa escribir datos intermedios a disco y moverlos por la red — eso es un shuffle. Domina el runtime del job, así que el tuning significa reducir shuffles: hacer broadcast del lado pequeño de un join, filtrar antes de unir, y elegir un particionado que coincida con cómo consultas.

¿Qué es data skew y cómo lo manejas?

Skew es cuando una clave tiene una porción desproporcionada de filas, así que una sola tarea procesa la mayoría de los datos mientras el resto del cluster está inactivo — el job se ve 99% terminado por una hora. Lo detectas en la Spark UI como una tarea con un input mucho más grande que sus pares. Los remedios incluyen salar la clave caliente para dividirla entre particiones, hacer broadcast de la tabla más pequeña para evitar el shuffle join por completo, y manejar claves calientes conocidas por separado de la cola larga.

¿Por qué Parquet en vez de CSV o JSON, y qué agrega el particionado?

Parquet es columnar y comprimido, así que una consulta que lee tres de cuarenta columnas lee solo esas columnas, y lleva un schema y estadísticas de columna que dejan a los motores saltarse row groups por completo. CSV y JSON fuerzan un escaneo completo y re-parseo cada vez. Particionar por una columna que filtras, usualmente fecha, deja al motor saltarse directorios enteros, pero sobre-particionar crea millones de archivos pequeños y el overhead de metadata entonces cuesta más de lo que ahorra.

¿Qué significa realmente el procesamiento exactly-once en streaming?

La entrega exactly-once verdadera no es lograble de punta a punta; lo que los sistemas dan es procesamiento effectively-once, significando que se pueden entregar duplicados pero el resultado observable es como si cada mensaje contara una vez. Eso se logra con escrituras idempotentes, deduplicación en una clave de mensaje, o sinks transaccionales que confirman offsets y salida atómicamente. Afirmar exactly-once sin decir qué mecanismo lo hace verdad es una bandera roja común en entrevistas.

¿Cómo manejas los datos que llegan tarde?

Primero decide la semántica: ¿el registro se asigna al momento en que pasó el evento o al momento en que lo recibiste? Event time usualmente es correcto para analytics pero requiere que el pipeline reabra y reescriba una partición ya publicada. Los watermarks definen cuánto esperas antes de tratar una ventana como cerrada, y cualquier cosa más tarde va a un camino de corrección o una tabla dedicada de llegadas tardías. El error de diseño es descartar datos tardíos silenciosamente, porque los números entonces difieren de la fuente y nadie sabe por qué.

¿Cómo testeas la calidad de datos, y qué revisas?

Los tests corren como pasos del pipeline que fallan ruidosamente en vez de como dashboards que nadie lee. Las verificaciones estándar son frescura, volumen de conteo de filas contra expectativas, unicidad de claves, not-null en columnas requeridas, integridad referencial entre hecho y dimensión, y rangos o enumeraciones aceptados. Herramientas como dbt tests o Great Expectations formalizan esto. La decisión de diseño importante es qué fallos bloquean tareas downstream y cuáles solo alertan, porque bloquear en cada anomalía entrena a la gente a ignorar las alertas.