Preguntas de Entrevista

Ambas son funciones de ventana (window functions). La diferencia ocurre cuando hay empates:

• RANK(): Deja un "hueco" en la numeración. Si dos filas empatan en el puesto 1, la siguiente fila recibe el puesto 3.
• DENSE_RANK(): NO deja huecos. Si dos filas empatan en el puesto 1, la siguiente fila recibe el puesto 2.

Ocurre cuando la distribución de la clave de join está muy desbalanceada (ej. el 90% de las filas tienen user_id = NULL o country = 'US'). Esto causa que un solo nodo de procesamiento reciba todo el trabajo, causando OOM (Out of Memory) o lentitud.

Soluciones:

• Filtrar los nulos o valores anómalos antes del join.
• "Salting": Agregar un número aleatorio a las claves de join en la tabla grande para distribuir el trabajo entre varios reducers.
• Si una tabla es muy pequeña, forzar un Broadcast Join (Map-Side Join).

Es una técnica en data warehousing para rastrear el historial de cambios de una dimensión a lo largo del tiempo. En lugar de sobrescribir el registro antiguo (SCD Tipo 1), se inserta una nueva fila.

Se requieren 3 columnas extra: valid_from (fecha inicio), valid_to (fecha fin), y is_active (booleano). Es vital cuando quieres recrear reportes del pasado (ej. "¿En qué estado vivía el cliente cuando compró esto hace 2 años?").

• Repartition: Realiza un full shuffle (movimiento de datos por la red entre todos los nodos). Crea particiones casi exactamente del mismo tamaño. Puede aumentar o disminuir el número. Es una operación muy costosa.
• Coalesce: Minimiza el movimiento de datos agrupando particiones existentes en el mismo nodo. Solo sirve para disminuir particiones.

Para reducir particiones antes de guardar un archivo sin hacer un shuffle, siempre usarías Coalesce. Sin embargo, si los datos originales estaban muy desbalanceados (skewed), el coalesce mantendrá ese desbalance, por lo que a veces Repartition es necesario antes de escribir en S3/HDFS para evitar archivos de distintos tamaños.

Es un caso clásico para una Arquitectura Lambda o Kappa. Una solución moderna (Kappa) sería:

1. Ingesta: La API envía los eventos a un topic de Apache Kafka o AWS Kinesis.
2. Tiempo Real (Serving): Apache Flink o Spark Structured Streaming lee de Kafka. Agrupa clics (tumbling windows de 1-2 segundos) y hace upsert de los contadores a una DB rápida como Redis o DynamoDB. El Dashboard lee directamente de Redis.
3. Almacenamiento Batch (Lakehouse): Otro proceso lee del mismo topic de Kafka usando Kafka Connect y usa un sink a Amazon S3 en formato Parquet (o usando Apache Iceberg).
4. ML (Analytics): Los Data Scientists usan Amazon Athena o Snowflake para consultar S3 sin afectar el sistema de tiempo real.