Si empezara de cero

Qué priorizaría aprender en Data Engineering

Mauro Loprete

2026-02-22

Spark de Ideas

La chispa de la ingeniería de datos en español

Mauro Loprete

Data Engineer

Yendo por el MVP

Si arrancara de cero

¿qué priorizaría aprender en Data Engineering?

Para un perfil de ingeniero de datos

La pirámide: de abajo hacia arriba

La idea es simple: hay un orden lógico para aprender. Python y SQL son la base, sin eso no podés hacer nada. Después Spark para escalar, dbt para modularizar, y Databricks como plataforma. No es que uno sea más importante que otro, sino que cada nivel se apoya en el anterior.

1

Python: la base de todo

No estoy hablando de print("Hola mundo")

Acá arrancamos con Python, pero ojo — no es el Python de un curso introductorio. Es el Python que usás todos los días en data engineering: leer archivos, parsear configs, modelar datos, testear.

Python — lo que realmente necesitás

• Estructuras de datos: listas, diccionarios, sets, tuplas
• Funciones y decoradores: composición de funciones
• Manejo de archivos: JSON, CSV, YAML, Parquet
• Entornos virtuales: venv, pip, pyproject.toml
• Testing básico: pytest

El 80% de lo que hacés en data es manipular estructuras.

Esto es lo que necesitás para el día a día. No hace falta ser experto en todo, pero sí tener soltura. Lo de testing con pytest es clave — muchos data engineers no testean nada y después pagan las consecuencias en producción.

Python — dataclasses

from dataclasses import dataclass
from typing import List, Optional

@dataclass
class DataProduct:
    name: str
    owner: str
    tables: List[str]
    sla_hours: Optional[int] = None

Python — dataclasses

from dataclasses import dataclass
from typing import List, Optional

@dataclass
class DataProduct:
    name: str
    owner: str
    tables: List[str]
    sla_hours: Optional[int] = None

    def is_critical(self) -> bool:
        return self.sla_hours is not None and self.sla_hours <= 4

# Leer config, parsear, validar — el 60% del laburo real
with open("products.json") as f:
    products = [DataProduct(**p) for p in json.load(f)]

critical = [p for p in products if p.is_critical()]

Dataclasses son la opción por defecto. Antes de escribir un diccionario para modelar algo, pensá si no es mejor una dataclass. Tenés autocompletado, type hints, y el código queda mucho más legible. El ejemplo de leer un JSON y convertirlo a objetos tipados es algo que hacemos todo el tiempo.

Python — inmutabilidad

El problema de los objetos mutables:

@dataclass
class Config:
    host: str
    port: int
    timeout: int = 30

config = Config("db.prod.internal", 5432)

Python — inmutabilidad

El problema de los objetos mutables:

@dataclass
class Config:
    host: str
    port: int
    timeout: int = 30

config = Config("db.prod.internal", 5432)

# Función B modifica la config sin que te des cuenta
def add_debug_settings(config):
    config.host = "localhost"  # ← cambió producción

connect(config)           # → "db.prod.internal:5432" ✓
add_debug_settings(config)
connect(config)           # → "localhost:5432" ← BUG

Este es un bug real que vi en producción. Una función auxiliar modificaba la config y afectaba a todo el pipeline. El problema es que Python por defecto te deja mutar todo. En data engineering, donde pasás configs y DataFrames entre funciones, esto es una fuente constante de bugs silenciosos.

Python — la solución: frozen

@dataclass(frozen=True)
class Config:
    host: str
    port: int
    timeout: int = 30

config = Config("db.prod.internal", 5432)

config.host = "localhost"  # ← FrozenInstanceError

# Si necesitás una versión modificada, creás una nueva:
from dataclasses import replace
debug_config = replace(config, host="localhost", timeout=999)

print(config.host)        # → "db.prod.internal"
print(debug_config.host)  # → "localhost"

Crear en vez de mutar — la forma más segura de trabajar con datos.

frozen=True te protege en tiempo de ejecución. Si alguien intenta modificar el objeto, explota con un error claro. Y si necesitás una variante, usás replace() que te crea una copia nueva. Es el mismo principio de inmutabilidad que usa Spark internamente con los DataFrames.

Python — Pydantic para validación

from pydantic import BaseModel, field_validator

class DataContract(BaseModel):
    name: str
    owner: str
    sla_hours: int
    columns: list[str]

    @field_validator("sla_hours")
    @classmethod
    def sla_must_be_positive(cls, v):
        if v <= 0:
            raise ValueError("SLA debe ser mayor a 0")
        return v

# Valida automáticamente al crear:
contract = DataContract(
    name="transactions", owner="backend-team",
    sla_hours=4, columns=["id", "amount", "date"]
)

Pydantic es para cuando necesitás validación. Un data contract, un schema de API, una configuración que viene de un YAML externo. La diferencia con dataclass es que Pydantic valida al crear el objeto — si el SLA es negativo, te lo dice ahí mismo en vez de fallar 3 horas después en producción.

Python — ¿cuándo usar cada tipo?

Situación	Tipo
Modelo de datos simple (mayoría)	@dataclass
Config que no debe cambiar	@dataclass(frozen=True)
Resultado liviano, desempaquetable	NamedTuple
Parsing JSON/YAML con validación	Pydantic BaseModel
Lógica de negocio compleja	Clase tradicional
Dato descartable, se usa una vez	dict

Arrancá con @dataclass. Si necesitás inmutabilidad → frozen=True. Si necesitás validación → Pydantic.

Esta tabla es la cheat sheet. La regla es simple: arrancá siempre con dataclass. Solo subí de complejidad cuando lo necesitás. El error más común es usar clases tradicionales con herencia para todo, o peor, diccionarios para todo.

2

SQL: el lenguaje que nunca muere

+50 años y sigue siendo el más usado en datos

SQL lleva más de 50 años y sigue siendo el lenguaje más usado en datos. Databricks, Snowflake, BigQuery — todos usan SQL como interfaz principal. No importa qué herramienta uses, vas a necesitar SQL.

SQL — lo que tenés que dominar

• Window functions: ROW_NUMBER(), LAG(), LEAD(), RANK()
• CTEs: queries legibles, no anidados de 200 líneas
• JOINs: CROSS, ANTI, SEMI — no solo INNER y LEFT
• Aggregations: HAVING, GROUPING SETS
• Subqueries correlacionadas: para saber cuándo evitarlas

Cuando dominás window functions, resolvés en una query lo que antes te llevaba 3 scripts de Python.

Las window functions son lo que separa a alguien que sabe SQL básico de alguien que lo domina. ROW_NUMBER, LAG, LEAD — con eso resolvés el 80% de los problemas analíticos. Los CTEs hacen que las queries sean legibles en vez de tener subqueries anidados imposibles de mantener.

SQL — ejemplo real

WITH daily_sales AS (
    SELECT
        customer_id,
        sale_date AS sale_day,
        SUM(amount) AS daily_total,
        COUNT(*) AS txn_count
    FROM sales
    WHERE status = 'COMPLETED'
    GROUP BY 1, 2
),
ranked AS (
    SELECT *,
        ROW_NUMBER() OVER (
            PARTITION BY customer_id
            ORDER BY daily_total DESC
        ) AS rn,
        LAG(daily_total) OVER (
            PARTITION BY customer_id
            ORDER BY sale_day
        ) AS prev_day_total
    FROM daily_sales
)
SELECT customer_id, sale_day, daily_total,
    prev_day_total,
    ROUND((daily_total - prev_day_total)
          / prev_day_total * 100, 2) AS pct_change
FROM ranked WHERE rn <= 5
ORDER BY customer_id, rn

Este ejemplo es real. Primero agrupamos por día con un CTE, después aplicamos ROW_NUMBER para rankear y LAG para comparar con el día anterior. Fíjense cómo con 3 funciones resolvemos ranking + comparación temporal. Sin window functions esto serían múltiples queries o un script de Python.

3

Spark: pensar en distribuido

No es “pandas grande” — es un paradigma distinto

Mucha gente viene de pandas y piensa que Spark es lo mismo pero más grande. No. Spark es computación distribuida — tus datos están repartidos en múltiples nodos y eso cambia completamente cómo tenés que pensar.

Spark — lo esencial

• Lazy evaluation: nada se ejecuta hasta collect(), count(), write()
• Particiones: datos distribuidos — coalesce(1) en 500GB mata el cluster
• Shuffle: la operación más cara — cada JOIN, GROUP BY puede generar uno
• Broadcast joins: tabla chica (< 10MB) → broadcasteala
• Catalyst optimizer: optimiza tu plan… si usás funciones nativas

Estos 5 conceptos son el core de Spark. Si entendés lazy evaluation, particiones y shuffle, ya estás por encima del 80% de la gente que usa Spark. Lo del Catalyst optimizer es clave: si usás funciones nativas, Spark puede optimizar tu query. Si usás UDFs, no puede.

Spark — funciones nativas vs UDF

from pyspark.sql import functions as F
from pyspark.sql.window import Window
# Bien: funciones nativas de Spark
df = (
    spark.read.table("sales.transactions")
    .filter(F.col("status") == "completed")
    .withColumn(
        "running_total",
        F.sum("amount").over(
            Window.partitionBy("customer_id")
            .orderBy("transaction_date")
            .rowsBetween(Window.unboundedPreceding,
                         Window.currentRow)
        )
    )
)

Fíjense que acá estamos usando F.col, F.sum, Window — todo API nativa de Spark. Esto es lo que el optimizador entiende y puede pushdown, reordenar, paralelizar. El running total con window function es un caso de uso super común en pipelines financieros.

Spark — la diferencia clave

Serde overhead: serialización JVM ↔︎ Python fila por fila = lento.

Este gráfico muestra la diferencia fundamental. Con funciones nativas, Spark habla directamente con la JVM y Catalyst optimiza todo. Con UDFs, cada fila tiene que ir de la JVM a Python, ejecutar tu función, y volver. Esa serialización/deserialización (serde) es lo que mata el rendimiento. En el lab pueden ver el benchmark con números reales.

Spark — wrapper functions ≠ UDFs

# Wrapper: usa API nativa — Spark la entiende y optimiza
def add_revenue_flag(df, threshold=1000):
    return df.withColumn(
        "high_revenue",
        F.when(F.col("amount") > threshold, True)
         .otherwise(False)
    )

# UDF: Python puro — fila por fila, sin optimización
@udf(returnType=BooleanType())
def high_revenue_udf(amount):
    return amount > 1000

Si no te queda otra, usá Pandas UDFs — procesan por batch, no fila por fila.

Esto es super importante: un wrapper function NO es una UDF. Un wrapper usa la API nativa internamente, Spark lo entiende y optimiza. Una UDF es Python puro que corre fila por fila. Si realmente necesitás una UDF — por ejemplo para llamar a una API externa o usar una librería que no tiene equivalente en Spark — usá Pandas UDFs que procesan por batch y son mucho más eficientes.

4

dbt: SQL con ingeniería de software

Modularidad, testing, documentación, linaje

dbt le trajo ingeniería de software al mundo SQL. Antes las transformaciones SQL eran scripts sueltos sin tests, sin documentación, sin versionamiento. dbt cambió eso completamente.

dbt — por qué importa

• Modularidad: cada modelo es un SELECT, se referencian con { ref() }
• Testing: not_null, unique, relationships, tests custom
• Documentación: se genera automáticamente desde YAML
• Linaje: sabés qué modelo depende de qué
• Versionamiento: todo es código, todo va a Git

Lo de ref() es genial — en vez de hardcodear nombres de tablas, referenciás otros modelos y dbt arma el DAG automáticamente. Sabés exactamente qué depende de qué, y si algo cambia, sabés qué se ve afectado. Los tests son first-class citizens: not_null, unique, valores aceptados.

dbt — modelo + tests

-- models/staging/stg_transactions.sql
WITH source AS (
    SELECT * FROM {{ source('raw', 'transactions') }}
),
cleaned AS (
    SELECT
        transaction_id,
        customer_id,
        CAST(amount AS DECIMAL(18,2)) AS amount,
        CAST(transaction_date AS DATE) AS transaction_date,
        UPPER(TRIM(status)) AS status
    FROM source
    WHERE transaction_id IS NOT NULL
)
SELECT * FROM cleaned

dbt — modelo + tests

# models/staging/stg_transactions.yml
version: 2
models:
  - name: stg_transactions
    description: "Transacciones limpias del core bancario"
    columns:
      - name: transaction_id
        tests: [not_null, unique]
      - name: amount
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0
              max_value: 1000000
      - name: status
        tests:
          - accepted_values:
              values: ['COMPLETED', 'PENDING', 'FAILED']

Miren el YAML de tests. Con 10 líneas tenés: validación de not_null, unique, rango de valores y valores aceptados. En un pipeline de PySpark eso serían 50 líneas de asserts manuales. dbt además genera documentación automática de todo esto.

dbt — ¿cuándo dbt y cuándo PySpark?

Caso	Herramienta
Transformaciones SQL (limpieza, joins, agg)	dbt
Lógica con APIs externas	PySpark
ML pipelines	PySpark + MLflow
Archivos no estructurados (JSON, XML)	PySpark
Modelos dimensionales (Kimball)	dbt
Streaming / near-real-time	Structured Streaming

Si tu transformación es SQL puro, usá dbt. Si necesitás lógica compleja, PySpark.

La pregunta que siempre hacen: ¿cuándo uso dbt y cuándo PySpark? La regla es simple: si tu transformación se puede expresar en SQL puro — limpieza, joins, aggregations, modelos dimensionales — usá dbt. Si necesitás llamar APIs, hacer ML, procesar archivos no estructurados o streaming — PySpark. No son excluyentes, se complementan.

5

Databricks: la plataforma que lo une todo

No es solo “Spark en la nube”

Databricks es mucho más que Spark en la nube. Es una plataforma completa de datos con gobernanza, orquestación, serving, y herramientas de desarrollo. Hay que aprender a usar la plataforma, no solo el motor de procesamiento.

Databricks — lo que priorizaría

1. Unity Catalog — gobernanza de 3 niveles: catalog.schema.table
2. Lakeflow Declarative Pipelines — Bronze → Silver → Gold con expectations
3. Databricks Asset Bundles — infra como código, todo en YAML + Git
4. Workflows — orquestación nativa con triggers y retry
5. SQL Warehouses — serverless para analistas y dashboards

Estos 5 son los que priorizaría. Unity Catalog es fundamental — sin gobernanza no hay data platform seria. LDP para pipelines de calidad. DABs para infra como código — el próximo Databricks Tips va a profundizar en esto. Workflows para orquestación. Y SQL Warehouses para que los analistas consulten sin tocar clusters.

Databricks — desde el día 1

-- Crear catalog y schema
CREATE CATALOG IF NOT EXISTS analytics;
CREATE SCHEMA IF NOT EXISTS analytics.sales;

-- Tabla con Liquid Clustering
CREATE TABLE analytics.sales.transactions (
    transaction_id BIGINT,
    customer_id BIGINT,
    amount DECIMAL(18,2),
    transaction_date DATE
)
USING DELTA
CLUSTER BY (transaction_date, customer_id);

-- Gobernanza básica
GRANT USE CATALOG ON CATALOG analytics TO `analysts`;
GRANT USE SCHEMA ON SCHEMA analytics.sales TO `analysts`;
GRANT SELECT ON TABLE analytics.sales.transactions TO `analysts`;

Desde el día 1 deberías pensar en catalog.schema.table. Liquid Clustering es una mejora enorme sobre el particionamiento clásico — Databricks optimiza los archivos automáticamente. Y los GRANTs son gobernanza básica: quién puede ver qué. Todo esto es SQL, no necesitás Python para configurarlo.

BONUS

Los notebooks NO son para producción

El error más común — y el que más cuesta corregir

Este es un tema que me apasiona. Los notebooks son geniales para explorar, pero son un desastre en producción. Lo he visto en todos lados — pipelines enteros corriendo en notebooks sin tests, sin code review, sin módulos. Y después cuando algo falla, nadie sabe por qué.

Notebooks — el problema real

Notebooks — cómo se hace bien

La regla: si algo corre más de una vez, no debería estar en un notebook.

El flujo correcto: explorás en un notebook, cuando la lógica funciona la extraés a un módulo .py, le escribís tests con pytest, lo deployás con DABs y CI/CD, y el notebook original queda como documentación. El notebook no desaparece, pero deja de ser el código de producción.

Notebooks — el código que sí va a producción

# src/transformations/clean_sales.py
def clean_transactions(df):
    return (
        df
        .filter(F.col("transaction_id").isNotNull())
        .withColumn("amount",
            F.col("amount").cast("decimal(18,2)"))
        .withColumn("status",
            F.upper(F.trim(F.col("status"))))
        .filter(F.col("amount") > 0)
    )

# tests/test_clean_sales.py
def test_clean_removes_nulls(spark):
    input_df = spark.createDataFrame([
        (1, 100.0, "completed"),
        (None, 200.0, "pending"),
    ], ["transaction_id", "amount", "status"])
    result = clean_transactions(input_df)
    assert result.count() == 1

Miren la diferencia: la función de transformación es pura — recibe un DataFrame, devuelve un DataFrame. Se puede testear fácilmente con un DataFrame de prueba. El test verifica que los nulls se eliminan. Esto es lo que va a producción: código testeable, modular, sin estado compartido.

El roadmap: en qué orden

Este es el roadmap sugerido de 9 meses. Python y SQL primero — mínimo 2-3 meses para tener soltura. Después Spark, que requiere entender un paradigma nuevo. dbt y Databricks pueden ir en paralelo si ya tenés la base. La especialización viene al final: streaming, ML, arquitectura. No intenten hacer todo al mismo tiempo.

Lo que NO priorizaría

• Airflow — Databricks Workflows cubre el 90% de los casos
• Kafka — Auto Loader + Structured Streaming resuelve la mayoría
• Kubernetes — sabé lo básico, no te metas en ese rabbit hole
• Todos los clouds a la vez — elegí uno y dominalo

Los conceptos se transfieren. No necesitás aprenderlos todos al mismo tiempo.

Esto es importante: no estoy diciendo que estas herramientas no sirvan. Airflow es genial, Kafka es fundamental en ciertos contextos. Pero si estás arrancando, no las necesitás todavía. Dominá los fundamentos primero. Los conceptos se transfieren — si sabés orquestar con Databricks Workflows, aprender Airflow después es mucho más fácil.

Lo más importante

Construí algo.

Agarrá un dataset público, armá un pipeline de punta a punta, deployalo, rompelo, arreglalo.

Eso vale más que 10 cursos.

Este es el mensaje final y el más importante. Construir algo real te enseña más que cualquier curso. Agarrá un dataset público, armá un pipeline completo: ingesta, transformación, tests, deploy. Rompelo, arreglalo. Eso es experiencia real.

Links y recursos

• Episodio del podcast — la charla completa
• Notebooks del episodio — ejecutalos en Databricks Free Edition
• Fundamentals of Data Engineering — el mejor libro para arrancar
• dbt Learn — curso gratuito oficial
• Databricks Academy — cursos oficiales

Estos son los links. El libro de Reis y Housley es el mejor para arrancar en data engineering. dbt Learn es gratuito y excelente. Y Databricks Academy tiene cursos oficiales — algunos gratuitos. Los notebooks del episodio están en GitHub para que los ejecuten en Free Edition.

Material disponible

A partir de ahora, las slides, notebooks y recursos de cada episodio van a estar en mi página web y en GitHub.

spark-de-ideas-labs — notebooks para ejecutar en Databricks Free Edition

Blog con contenido expandido + slides para revisar a tu ritmo.

Spark de Ideas

Gracias por escuchar

Spotify Web

Ya disponible: Databricks Tips #1 — Asset Bundles Cada miércoles un nuevo tip — el próximo: #2 Delta Lake