Apache Spark 4.2 vs Databricks en 2026: Arquitectura, Rendimiento y Preguntas de Entrevista

Apache Spark 4.2 y Databricks representan dos caminos hacia el procesamiento distribuido de datos en 2026. Spark ofrece máxima flexibilidad como framework de código abierto, mientras que Databricks envuelve Spark en una plataforma lakehouse completamente administrada con mejoras propietarias. Comprender las diferencias entre estas opciones es esencial para las entrevistas de data engineering y las decisiones arquitectónicas.

Apache Spark 4.2: Nuevas Características y Arquitectura

Apache Spark 4.2, lanzado el 14 de julio de 2026, introduce varias características que transforman el funcionamiento de los pipelines de datos. Las adiciones más significativas se enfocan en la captura de datos de cambio, integración con IA y cargas de trabajo de streaming.

Auto CDC y la Cláusula CHANGES

Spark 4.2 hace que la captura de datos de cambio (CDC) sea nativa del motor. Anteriormente, el seguimiento de cambios en los datos requería soluciones personalizadas que involucraban timestamps, comparaciones de hash o herramientas CDC externas. La nueva característica Auto CDC maneja esto automáticamente.

-- changes-query.sql
-- Consultar cambios en una tabla Delta desde la versión 10
SELECT * FROM orders CHANGES SINCE VERSION 10;

-- Rastrear cambios dentro de una ventana temporal
SELECT * FROM customers 
CHANGES BETWEEN TIMESTAMP '2026-07-01' AND TIMESTAMP '2026-07-15';

La cláusula CHANGES retorna filas con columnas de metadatos que indican si cada fila fue insertada, actualizada o eliminada. Esto elimina la necesidad de mantener infraestructura CDC separada para la mayoría de los casos de uso.

Metric Views: Capa Semántica Nativa

Los Metric Views crean definiciones de negocio gobernadas directamente en Spark SQL. Los equipos definen métricas una sola vez, asegurando cálculos consistentes a través de dashboards, reportes y aplicaciones de IA.

-- metric-views.sql
-- Definir una vista métrica para cálculos de ingresos
CREATE METRIC VIEW monthly_revenue AS
SELECT 
    DATE_TRUNC('month', order_date) AS month,
    SUM(amount) AS total_revenue,
    COUNT(DISTINCT customer_id) AS unique_customers,
    SUM(amount) / COUNT(DISTINCT customer_id) AS revenue_per_customer
FROM orders
WHERE status = 'completed'
GROUP BY DATE_TRUNC('month', order_date);

-- Consultar la vista métrica
SELECT * FROM monthly_revenue WHERE month >= '2026-01-01';

Los Metric Views imponen consistencia en los cálculos. Cuando el equipo de finanzas consulta monthly_revenue, obtiene los mismos números que el equipo de data science construyendo modelos ML.

Modo Tiempo Real para PySpark

Spark 4.2 introduce el Modo Tiempo Real, simplificando los flujos de trabajo de streaming en PySpark. Esta característica reduce la carga operacional de la gestión de checkpoints y la recuperación ante fallos.

# streaming_pipeline.py
from pyspark.sql import SparkSession
from pyspark.sql.functions import col, window

spark = SparkSession.builder.appName("RealTimeOrders").getOrCreate()

# Habilitar Modo Tiempo Real para streaming simplificado
orders_stream = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "kafka:9092") \
    .option("subscribe", "orders") \
    .option("realtimeMode", "true") \
    .load()

# Agregar órdenes en ventanas de 5 minutos
aggregated = orders_stream \
    .withWatermark("event_time", "10 minutes") \
    .groupBy(window(col("event_time"), "5 minutes"), col("region")) \
    .agg({"amount": "sum", "order_id": "count"})

# Escribir a Delta Lake
aggregated.writeStream \
    .format("delta") \
    .outputMode("append") \
    .option("checkpointLocation", "/checkpoints/orders") \
    .toTable("order_aggregates")

El Modo Tiempo Real maneja la gestión de checkpoints internamente, reduciendo el código boilerplate y la complejidad operacional para aplicaciones de streaming.

Arquitectura de la Plataforma Databricks en 2026

Databricks extiende Spark con características propietarias que abordan requisitos empresariales. La plataforma combina Delta Lake, Unity Catalog, Mosaic AI y el nuevo motor OLTP Lakebase en un lakehouse integrado.

Unity Catalog: Gobernanza Centralizada

Unity Catalog proporciona control de acceso granular sobre todos los activos de datos. La seguridad a nivel de columna, los filtros de fila y el enmascaramiento de datos se aplican consistentemente a través de consultas SQL, notebooks y trabajos de entrenamiento ML.

-- unity-catalog-policies.sql
-- Otorgar acceso de lectura a columnas específicas
GRANT SELECT (customer_id, order_date, product_id) 
ON TABLE sales.orders 
TO `analyst-team`;

-- Crear política de seguridad a nivel de fila
CREATE ROW FILTER policy_regional_access 
ON sales.orders 
AS (region STRING) -> region = current_user_region();

-- Aplicar el filtro
ALTER TABLE sales.orders SET ROW FILTER policy_regional_access ON (region);

Con Spark autoadministrado, funcionalidad equivalente requiere integrar Apache Ranger para control de acceso, Apache Atlas para metadatos y soluciones personalizadas para seguimiento de linaje.

Economía del Cómputo Serverless

El SQL serverless de Databricks elimina los costos de inactividad de clusters. SQL Serverless cuesta $0.70 por DBU en AWS Premium, pero para cargas de trabajo BI esporádicas, los costos totales frecuentemente resultan 20-35% menores que SQL Pro porque las horas de inactividad desaparecen.

| Tipo de Cómputo | Tasa DBU (AWS Premium) | Ideal Para | |-----------------|------------------------|------------| | Jobs Classic | $0.15 | ETL batch, procesamiento nocturno | | Jobs Serverless | $0.28 | Cargas variables, horarios impredecibles | | SQL Pro | $0.55 | Consultas BI sostenidas, patrones predecibles | | SQL Serverless | $0.70 | Consultas esporádicas, dashboards bajo demanda | | Model Serving | $0.08 | Endpoints de inferencia ML |

El balance es directo: serverless cobra una prima de 20-40% en DBU versus cómputo classic, pero elimina los costos de arranque e inactividad de clusters que pueden dominar el gasto total para cargas variables.

Comparación de Arquitectura para Preparación de Entrevistas

Las entrevistas de data engineering frecuentemente exploran las compensaciones entre Spark autoadministrado y plataformas administradas como Databricks. La siguiente comparación cubre los temas de entrevista más comunes.

Gestión de Clusters y Escalamiento

Spark autoadministrado requiere configuración explícita de clusters. Los equipos eligen tipos de instancia, configuran políticas de autoescalamiento y manejan interrupciones de instancias spot.

# spark_cluster_config.py
from pyspark import SparkConf

conf = SparkConf() \
    .setAppName("ProductionETL") \
    .set("spark.executor.instances", "10") \
    .set("spark.executor.cores", "4") \
    .set("spark.executor.memory", "16g") \
    .set("spark.dynamicAllocation.enabled", "true") \
    .set("spark.dynamicAllocation.minExecutors", "2") \
    .set("spark.dynamicAllocation.maxExecutors", "50") \
    .set("spark.shuffle.service.enabled", "true")

Databricks abstrae gran parte de esta complejidad. Las políticas de cluster imponen estándares organizacionales, y las instancias optimizadas con Photon seleccionan automáticamente configuraciones apropiadas.

Linaje de Datos y Observabilidad

Databricks Unity Catalog rastrea el linaje automáticamente a través de tablas, notebooks y modelos ML. Cada operación de lectura y escritura crea una traza auditable.

Con Spark autoadministrado, el seguimiento de linaje requiere herramientas adicionales. Los enfoques comunes incluyen integración con Apache Atlas o construcción de soluciones personalizadas usando listeners de Spark.

# custom_lineage_listener.py
from pyspark import SparkContext
from pyspark.sql import SparkSession

class LineageListener:
    def __init__(self, spark: SparkSession):
        self.spark = spark
        
    def track_read(self, table_name: str, query_id: str):
        # Registrar operación de lectura en el almacén de linaje
        lineage_record = {
            "operation": "read",
            "table": table_name,
            "query_id": query_id,
            "timestamp": datetime.now().isoformat(),
            "user": self.spark.sparkContext.sparkUser()
        }
        self._persist_lineage(lineage_record)
    
    def track_write(self, table_name: str, query_id: str, row_count: int):
        # Registrar operación de escritura con conteo de filas afectadas
        lineage_record = {
            "operation": "write",
            "table": table_name,
            "query_id": query_id,
            "rows_affected": row_count,
            "timestamp": datetime.now().isoformat()
        }
        self._persist_lineage(lineage_record)

Opciones de Capa de Almacenamiento

Ambos enfoques soportan formatos de tabla abiertos. Delta Lake se originó en Databricks pero es completamente de código abierto. Apache Iceberg proporciona una alternativa con fuerte soporte comunitario.

| Característica | Delta Lake | Apache Iceberg | |----------------|------------|----------------| | Transacciones ACID | Sí | Sí | | Time Travel | Sí | Sí | | Evolución de Esquema | Sí | Sí | | Evolución de Partición | Limitada | Completa | | Particionamiento Oculto | No | Sí | | Integración Principal | Databricks | Múltiples motores |

Para un análisis más profundo de estos formatos, consulta la comparación Delta Lake vs Apache Iceberg.

Preguntas de Entrevista Comunes

Las siguientes preguntas aparecen frecuentemente en entrevistas de data engineering. Cada pregunta incluye el contexto que buscan los entrevistadores y marcos de respuesta estructurados.

Pregunta 1: ¿Cuándo elegir Spark autoadministrado sobre Databricks?

Lo que evalúan los entrevistadores: Conciencia de costos, madurez operacional y comprensión de restricciones organizacionales.

Marco de respuesta sólido:

• Predictibilidad de costos: Spark autoadministrado elimina cargos por DBU. Para organizaciones con cargas de trabajo constantes y predecibles ejecutándose 24/7, el gasto de capital en instancias reservadas frecuentemente cuesta menos que precios basados en consumo.
• Soberanía de datos: Algunas industrias requieren que los datos permanezcan on-premises o en jurisdicciones específicas. Los despliegues autoadministrados en infraestructura dedicada satisfacen estos requisitos.
• Experiencia existente: Equipos con fuertes capacidades de operaciones Kubernetes y Spark pueden preferir la flexibilidad de despliegues autoadministrados.
• Cargas multi-motor: Organizaciones usando Spark junto con Presto, Flink o motores personalizados se benefician de gestión unificada de clusters a través de YARN o Kubernetes.

Pregunta 2: ¿Cómo optimiza Databricks el rendimiento de Spark?

Lo que evalúan los entrevistadores: Comprensión del Delta Engine, Photon y optimizaciones específicas de la plataforma.

Puntos clave a cubrir:

• Photon: Motor de ejecución vectorizado nativo en C++ que reemplaza el motor Spark SQL basado en JVM para operaciones soportadas. Proporciona aceleración de 2-8x para cargas intensivas en escaneo y agregación.
• Delta Cache: Capa de caché basada en SSD que acelera lecturas repetidas desde almacenamiento en la nube.
• Adaptive Query Execution: Versión mejorada del AQE de Spark con optimizaciones adicionales para manejo de data skew y selección de estrategias de join.
• Optimización IO: Optimización automática de disposición de datos, incluyendo Z-ordering y compactación de archivos.

Pregunta 3: Explicar las compensaciones del cómputo serverless

Lo que evalúan los entrevistadores: Habilidades de modelado de costos y comprensión de características de cargas de trabajo.

# cost_comparison.py
def estimate_monthly_cost(workload_type: str, daily_dbus: float, hours_active: float):
    """Comparar costos serverless vs classic."""
    
    # Tasas DBU (nivel AWS Premium)
    rates = {
        "sql_classic": 0.55,
        "sql_serverless": 0.70,
        "jobs_classic": 0.15,
        "jobs_serverless": 0.28
    }
    
    # Clusters classic incurren costos de inactividad
    cluster_hours_per_day = 10  # Cluster ejecuta 10h para 4h de trabajo real
    serverless_hours = hours_active  # Solo pagar por cómputo real
    
    classic_monthly = daily_dbus * cluster_hours_per_day * rates[f"{workload_type}_classic"] * 30
    serverless_monthly = daily_dbus * serverless_hours * rates[f"{workload_type}_serverless"] * 30
    
    return {
        "classic": classic_monthly,
        "serverless": serverless_monthly,
        "savings_percent": (classic_monthly - serverless_monthly) / classic_monthly * 100
    }

Serverless se adapta a cargas esporádicas e impredecibles. El cómputo classic gana para procesamiento sostenido y predecible donde los clusters operan cerca de su capacidad.

Pregunta 4: ¿Cómo se compara Auto CDC de Spark 4.2 con herramientas CDC tradicionales?

Lo que evalúan los entrevistadores: Comprensión de patrones de captura de datos de cambio y compensaciones operacionales.

Puntos de comparación:

La versión Apache Spark 4.2 incorpora CDC en el motor de consultas:

| Aspecto | Spark 4.2 Auto CDC | Debezium/Kafka | CDC Timestamp Custom | |---------|-------------------|----------------|----------------------| | Complejidad de Setup | Baja | Alta | Media | | Latencia Tiempo Real | Minutos | Segundos | Minutos a horas | | Carga Base Fuente | Ninguna | Lectura de logs | Basada en consultas | | Consultas Históricas | Integrado | Requiere retención | Limitada | | Evolución de Esquema | Automática | Configuración necesaria | Manual |

Auto CDC sobresale para cargas analíticas donde latencia de nivel de minutos es aceptable. Para requisitos sub-segundo, Debezium con Kafka permanece como el enfoque estándar.

Marco de Decisión Práctico

Usar este marco al evaluar Spark vs Databricks para una organización o proyecto específico.

Elegir Spark Autoadministrado Cuando:

• El equipo tiene experiencia existente en Spark y Kubernetes
• Las cargas de trabajo son predecibles y ejecutan continuamente
• Los datos deben permanecer on-premises o en regiones específicas
• La organización ya opera infraestructura de plataforma de datos
• La sensibilidad al costo supera la conveniencia operacional

Elegir Databricks Cuando:

• El time-to-production importa más que los costos por consulta
• El equipo carece de experiencia profunda en operaciones Spark
• Los requisitos de gobernanza y cumplimiento demandan trazas de auditoría
• Los flujos ML necesitan seguimiento de experimentos integrado y model serving
• Las cargas BI se benefician del escalamiento serverless

Para preparación de entrevistas sobre orquestación de pipelines Apache Airflow y patrones ETL, los módulos de preguntas de SharpSkill ofrecen práctica estructurada.

Conclusión

• Apache Spark 4.2 trae Auto CDC, Metric Views y Modo Tiempo Real como características nativas, reduciendo la necesidad de herramientas externas
• Databricks agrega gobernanza Unity Catalog, aceleración Photon y cómputo serverless sobre el fundamento de Spark
• Spark autoadministrado ofrece costos menores para cargas predecibles y máxima flexibilidad arquitectónica
• Databricks reduce la carga operacional y acelera el time-to-production para equipos sin experiencia Spark profunda
• El éxito en entrevistas requiere comprender tanto las diferencias técnicas como las compensaciones de negocio que guían la selección de plataforma
• La elección correcta depende de las capacidades del equipo, modelo de costos, requisitos de cumplimiento y características de las cargas de trabajo