Glosario de Data Engineering para IA

Los términos que aparecen una y otra vez en el Curso de Data Engineering para IA y en cualquier conversación seria sobre pipelines de datos. Como todo glosario de la academia, crece con cada bloque nuevo.

La tesis y el mapa

Data-centric (centrado en datos) — El enfoque que pregunta “¿qué mejora de los datos mejora el resultado?” en vez de “¿qué modelo?”. Con los modelos siendo commodity, es la palanca que suele rendir más — y la tesis del curso: el pipeline es el foso. Se desarrolla en los datos son el 80%.

Pipeline de datos — El flujo que lleva datos desde donde nacen hasta donde se usan, con cinco etapas: fuentes → ingesta → almacenamiento → transformación → servicio. Lo que lo distingue de un script: reintenta, valida, avisa y es reproducible. Se desarrolla en el mapa.

OLTP (online transaction processing) — Las bases operativas que procesan las transacciones del negocio (el CRM, el ERP). Las fuentes típicas del pipeline — y los sistemas que la extracción no debe castigar.

SLA de frescura — El acuerdo de qué tan viejo puede ser el dato para cada consumidor: el reporte mensual tolera días; la feature de fraude, milisegundos. La vara contra la que se elige el ritmo de todo el pipeline.

El crudo es sagrado — El principio rector: la capa bronce guarda el dato exactamente como llegó, porque las transformaciones se rehacen y la fuente olvida. Su excepción con nombre: la PII, cuya retención es política, no conveniencia.

Idempotencia (de pipeline) — Que correr la misma carga dos veces no duplique datos — con claves de partición y escrituras que reemplazan. La propiedad que permite re-correr sin miedo; y re-correr sin miedo es la mitad de operar.

Backfill — Re-procesar el pasado (cargar lo histórico, re-correr enero tras el bug) con el pipeline normal parametrizado por ventanas — no con un script especial. Se vuelve rutina en orquestación.

Ingesta

Extracción incremental — Pedir solo lo que cambió desde la última corrida, con una watermark (marca de agua: el punto hasta donde llegaste) y solape de seguridad. La alternativa adulta al full extract que muere con el volumen. Se desarrolla en ingesta.

CDC (Change Data Capture) — Leer el diario de transacciones de la base (el WAL/binlog) en vez de consultarla: cada inserción, cambio y borrado como evento, con carga casi nula sobre la fuente. Debezium es el estándar open source; típicamente emite hacia Kafka.

Kafka — El bus de eventos distribuido: topics particionados y persistentes donde los productores publican y cada consumidor lee a su ritmo con su offset (marcador de posición propio). Sus rasgos: retención re-leíble (rebobinar es backfill), orden por partición, throughput masivo y desacople — el mismo topic alimenta consumidores que se multiplican con los casos de uso.

Batch vs. streaming — La decisión de ritmo, tomada por el SLA del consumidor: batch por defecto, micro-batch (cada 5-15 min) cuando apriete, streaming solo cuando segundos de retraso cambian una decisión y alguien puede actuar en segundos. El streaming es un compromiso de operación 24/7, no una configuración.

Almacenamiento

Parquet — El formato columnar estándar: valores de cada columna juntos, comprimidos por tipo, con estadísticas que permiten saltar bloques. La razón de que consultar terabytes cueste centavos — y la regla: de plata en adelante, todo es Parquet particionado. Se desarrolla en lake, warehouse y lakehouse.

Arrow — El formato columnar en memoria: el idioma común con el que pandas, Spark, DuckDB y compañía intercambian datos sin re-serializar.

Partición — Organizar los archivos por la dimensión de filtro real (casi siempre fecha: fecha=2026-09-06/) para que las consultas toquen solo lo suyo. Sin partición se escanea la historia; con partición por milisegundo, millones de archivos diminutos la matan igual.

Data lake / warehouse / lakehouse — Las tres casas: archivos baratos sin garantías (lake), tablas administradas con garantías y costo (warehouse), y la síntesis dominante — el lake con un formato de tabla encima: lakehouse, archivos de centavos con modales de warehouse.

Iceberg / Delta Lake — Los dos grandes formatos de tabla abiertos: la capa de metadatos sobre Parquet que aporta transacciones ACID, evolución de esquema, time travel (consultar la tabla como era en una fecha — la reproducibilidad de datasets resuelta en la capa de datos) y lectura desde cualquier motor.

Arquitectura medallón — Las capas de refinamiento progresivo: bronce (crudo intacto), plata (limpio y conformado), oro (agregado y listo para consumir). No son burocracia: separan lo irrecuperable de lo confiable de lo consumible.

Data swamp (pantano de datos) — El lake degenerado: archivos que nadie entiende, sin dueños ni garantías. El formato de tabla da las garantías técnicas; el orden sigue siendo trabajo (dueños, calidad, catálogo).

Transformación

ETL vs. ELT — El orden de las letras: transformar antes de cargar (ETL, el clásico de almacén caro) vs. cargar el crudo y transformar dentro con el motor del almacén (ELT, el moderno). ELT por defecto; ET(L) solo con razón nombrable — como enmascarar PII antes de persistir. Se desarrolla en ELT y dbt.

dbt (data build tool) — El estándar de la transformación ELT: cada transformación es un modelo (un SELECT en un archivo), las dependencias se declaran con ref(), y de ahí salen el orden de ejecución, el linaje dibujado, los tests declarativos y la documentación. El SQL con modales de software.

DAG (grafo dirigido acíclico) — El grafo de dependencias — entre modelos de dbt, entre tareas del orquestador. La estructura que permite ejecutar en orden y reconstruir solo lo afectado.

Staging → intermediate → marts — El patrón de capas de dbt sobre el medallón: staging limpia (1:1 con la fuente, sin negocio), intermediate concentra las reglas de negocio (en un lugar, no en cada consumidor), marts sirve por dominio. Y la regla del curso: los datasets de IA son marts — con tests, linaje y versión.

Materialización incremental — El modelo dbt que procesa solo lo nuevo en cada corrida — la watermark dentro de la transformación. Esencial cuando la historia es grande.

Orquestación y calidad

Orquestador — El director del pipeline: dependencias explícitas, reintentos con política, backfill de rutina, visibilidad y alertas. Lo que el cron no da. Airflow (el estándar veterano, DAGs de tareas), Dagster (el giro: orquestar assets) y Prefect (el pythonista pragmático). Se desarrolla en orquestación.

Asset — La unidad mental de Dagster: el dato que debe existir y estar fresco (“la tabla stg_correos”, “el índice del RAG”), del que se derivan las corridas. Habla el idioma de los consumidores de IA: la pregunta nunca es “¿corrió el paso 4?” sino “¿está fresco el dataset?”.

Las cuatro capas de calidad — Esquema (¿tiene la forma?), reglas de negocio (¿valores posibles?), distribuciones (¿se parece a ayer?) y frescura/volumen (¿llegó completo?). Las dos primeras son determinísticas y van en cada build; las estadísticas detectan la deriva que ningún not_null ve. Se desarrolla en calidad y contratos.

Great Expectations (GX) — El framework dedicado de calidad: expectativas declarativas que llegan donde los tests de dbt no (distribuciones, rangos, comparaciones) y validan también fuera de dbt — las fronteras: el crudo al entrar, el dataset antes de servirse.

Frenar vs. avisar — La decisión por chequeo según lo que cueste propagar el error: frena lo que corrompería el oro o entrenaría basura; avisa la señal de investigación. Cien frenos = pipeline que nunca corre; cero = basura en producción.

Contrato de datos (data contract) — El acuerdo explícito con la fuente: esquema versionado, garantías de frescura y volumen, aviso de cambios con plazo, responsables con nombre. Convierte “cambiaron el campo sin avisar” en incidente con dueño. Sin cultura para el contrato: validación unilateral de la frontera de entrada, siempre.

Datos para IA

Guía de anotación — El documento que define cada etiqueta con ejemplos y — lo valioso — los casos limítrofes resueltos. Se escribe iterando; sin ella, el desacuerdo entre anotadores lo cobra. Se desarrolla en etiquetado.

IAA (inter-annotator agreement, acuerdo entre anotadores) — La coincidencia entre anotadores sobre el mismo subconjunto (medida con kappa y parientes). Su lectura correcta: IAA bajo = tarea mal definida (se arregla la guía). Y marca el techo realista del modelo.

Active learning — Etiquetar lo que más enseña: entrenar → puntuar lo no etiquetado → anotar donde el modelo duda (incertidumbre) y donde cubre espacio nuevo (diversidad) → repetir. Paga con presupuesto caro y volumen grande; para lotes chicos, el muestreo estratificado simple da la mitad del beneficio gratis.

Fuga train/test (leakage) — Ejemplos casi idénticos en entrenamiento y evaluación: la métrica se infla y producción decepciona. Su versión temporal — entrenar con valores del futuro — se llama fuga temporal y se previene con point-in-time. La dedup corre antes del split.

MinHash + LSH — El estándar de deduplicación difusa a escala: cada documento reducido a una firma que preserva similitud, y el hashing sensible a localidad agrupando candidatos sin comparar todos contra todos. La palanca de calidad número uno de los corpus LLM: lo casi-igual sobre-representa, memoriza y fuga. Se desarrolla en datos para LLM.

PII scrubbing — La etapa de pipeline (no la promesa) que detecta datos personales (patrones + NER; Presidio como estándar) y los enmascara con placeholders consistentes antes de entrenar — la estructura entrena, el dato no. Con verificación de residuo en la aduana, porque la detección nunca es perfecta.

Datos sintéticos — Ejemplos generados por un LLM: resuelven clases raras, privacidad y arranque — y cobran en diversidad (la voz única del generador). Reglas: mezclados con real, con variedad forzada, deduplicados, y evaluados contra un test 100% real.

Re-indexación incremental — El corazón del pipeline RAG a escala: estado del índice con hash por chunk, diff en cada corrida, y solo lo distinto se re-embebe (20-100× menos factura que el re-embebido total). Exige chunking estable y el modelo de embeddings versionado como parte del estado. Se desarrolla en el pipeline del RAG.

Permisos en el índice — Las ACLs viajando como metadatos del chunk y el retrieval filtrando por el usuario que pregunta. Sin esto, el RAG es una escalada de privilegios con interfaz conversacional — y los borrados sin propagar, deuda legal indexada.

Training/serving skew — El bug más caro del ML aplicado: la feature calculada de una forma para entrenar y de otra para servir, divergiendo en silencio. Se resuelve definiendo una vez y sirviendo a ambos caminos. Se desarrolla en features.

Feature store — La pieza que implementa esa idea: tienda offline (historia completa, para entrenar), tienda online (el valor actual en milisegundos, para predecir) y registro con dueños. Se justifica con predicción online de baja latencia; para modelos batch, tus features son marts y la maquinaria extra es logo.

Point-in-time correctness — Armar datasets históricos con el valor de cada feature como era en el momento del evento, no el actual. La defensa contra la fuga temporal — la más difícil de ver a ojo, porque el dataset se ve normal.

Gobernanza

Catálogo de datos — La respuesta a “¿qué existe y qué significa?”: tablas con descripción, dueño y clasificación, buscables. Se siembra en los YAML de dbt; las plataformas (DataHub, OpenMetadata) agregan cuando la escala humana lo pide. Se desarrolla en gobernanza.

Linaje (lineage) — De qué desciende cada dato (hacia atrás: auditoría y debugging) y quién depende de él (hacia adelante: análisis de impacto antes de cambiar). Se cosecha de los ref() y los assets; OpenLineage lo unifica entre herramientas. Para IA: la cadena consultable modelo → dataset → fuentes.

Clasificación de datos — Etiquetar qué contiene cada dato (público/interno/confidencial/restringido) como metadato del que se derivan las reglas de acceso y enmascaramiento. Los consumidores de IA heredan la clasificación de sus insumos — el dataset de correos confidenciales es confidencial.