Zero-Copy: El fin de ETL y el futuro de la IA

Es el sucio secreto del auge de la IA: los modelos son brillantes, pero las tuberías son antiguas.

Construyes un modelo de transformador de última generación. Protege los clústeres de GPU H100. Pero luego espera 24 horas para que se ejecute la canalización ETL (Extracción, Transformación, Carga) para que su modelo pueda realmente ver los nuevos datos de ventas. Cuando se ejecuta la inferencia, el cliente ya ha abandonado.

Este es el “impuesto a la fricción de datos” y está acabando con el ROI de la IA.

En 2025, la industria finalmente estará arreglando las tuberías. Los equipos de ingeniería están pasando de la era del almacenamiento de datos a la era de las plataformas de datos unificadas, específicamente arquitecturas construidas en torno a una filosofía de “copia cero”. Si está construyendo sistemas de inteligencia artificial, debe comprender por qué copiar datos se está convirtiendo en un antipatrón arquitectónico.

La física del problema: por qué ETL escala mal

Para comprender por qué es importante la copia cero, hay que observar la ineficiencia de las pilas tradicionales.

En una empresa estándar, los datos viven efectivamente en “pozos de gravedad”: Salesforce para CRM, SAP para ERP, AWS S3 para registros. Para analizar estos datos, los ingenieros históricamente construían canalizaciones para copiarlos físicamente desde el origen A al destino B (normalmente un almacén de datos como Redshift o Snowflake).

Esto introduce una ecuación de latencia fundamental:

$$\text{Latency} = T_{extract} + T_{transfer} + T_{load} + T_{indexing}$$

Cada vez que copias datos, introduces:

1. Latencia: el problema de los “datos obsoletos”. Si el oleoducto funciona todas las noches, la IA siempre estará 24 horas por detrás de la realidad.
2. Costo: las empresas pagan costos de almacenamiento específicos por el duplicado. Es posible almacenar 1 PB de datos; almacenar 5 copias (Raw, Bronze, Silver, Gold, Warehouse) es exorbitante.
3. Gastos generales de serialización: el costo de CPU de estandarizar JSON/CSV en Parquet/Avro (SerDes) consume enormes cantidades de computación que podrían usarse para inferencia.
4. Deriva: el esquema en la Fuente A cambia (p. ej., un desarrollador cambia el nombre de user_id a uuid), lo que interrumpe la canalización hacia el Destino B.

Dataversity advierte que la mala calidad de los datos, a menudo derivada de estos frágiles canales, podría causar que el 60% de los proyectos de IA se abandonen durante el próximo año. La solución no son tuberías más rápidas; son no tuberías.

La evolución de la gravedad de los datos

Para apreciar la revolución de copia cero, es útil mapear la trayectoria de la arquitectura de datos durante las últimas dos décadas. La industria ha oscilado entre el acoplamiento y el desacoplamiento.

Fase 1: El Monolito (1990-2010)

Al principio existía la base de datos Oracle. El almacenamiento y la computación estaban estrechamente vinculados. Si deseaba realizar una consulta más rápida, compraba una caja más grande. Era consistente y rápido (cumplía con ACID), pero no podía escalar horizontalmente. Se atragantó con el volumen de datos a escala web.

Fase 2: El Lago de Datos / El “Pantano” (2010-2018)

La era Hadoop introdujo HDFS. La filosofía era “Esquema en lectura”. Simplemente descargue todos los registros JSON en un almacenamiento económico y descúbralo más tarde. Esto resolvió el problema del costo de almacenamiento pero creó un “pantano”. El rendimiento de las consultas fue terrible y, sin transacciones, la integridad de los datos desapareció. Los modelos de IA entrenados con estos datos frecuentemente alucinaban porque los datos de entrada eran basura o estaban incompletos.

Fase 3: El almacén en la nube (2018-2023)

Snowflake y BigQuery separaron el almacenamiento (S3/GCS) de la computación. Este fue un gran avance. Podría escalar el almacenamiento infinitamente y poner en marcha clústeres informáticos según demanda. Sin embargo, el formato todavía era propietario. Para usar Snowflake, tenías que COPY INTO Snowflake. Los datos estaban encerrados en sus microparticiones. Aún tenías que mover los bytes.

Fase 4: La casa del lago de copia cero (2024+)

Este es el punto de inflexión actual. Los datos permanecen en S3, pero en formatos abiertos (como Apache Iceberg). El motor informático (Snowflake, Spark, Trino, Dremio) visita los datos donde reside. No hay COPY INTO. Sólo hay SELECT * FROM.

Análisis técnico profundo: cómo funciona realmente la copia cero

“Copia cero” es un nombre inapropiado. Los bits existen en algún disco en alguna parte. Sin embargo, desde el punto de vista arquitectónico, significa que el sistema no mueve los bytes al proceso; trae los permisos de cálculo a los bytes (o específicamente, comparte los punteros).

Los “formatos de tabla abiertos” modernos como Apache Iceberg, Delta Lake y Apache Hudi son los facilitadores aquí. Permiten que diferentes motores informáticos examinen los mismos archivos en el almacenamiento de objetos sin necesidad de “poseerlos”.

La capa de metadatos

La magia ocurre en los metadatos. En lugar de copiar una tabla de 10 TB, un sistema Zero-Copy comparte un archivo de manifiesto: una lista de punteros a los archivos Parquet que se encuentran en S3.

Cuando un ingeniero “clona” una base de datos en Snowflake o crea una sucursal en Dremio Arctic, el sistema no duplica los 10 TB. Duplica los metadatos (kilobytes) y los dirige a los mismos bloques de almacenamiento subyacentes.

La mecánica del aislamiento: Zero-Copy depende en gran medida del Aislamiento de instantáneas.

1. La Lista de manifiesto apunta a una “instantánea” específica (por ejemplo, instantánea S1).
2. La instantánea S1 apunta a un conjunto de archivos de manifiesto.
3. Los Archivos de Manifiesto apuntan a los Archivos de Datos reales (Parquet).

Cuando un modelo de IA comienza a entrenar a las 10:00 a. m., se fija en la instantánea S1. Si un trabajo ETL actualiza la tabla a las 10:05 a. m., crea una instantánea S2 (escribe nuevos archivos Parquet y un nuevo manifiesto). El modelo de IA continúa leyendo S1 sin interrupciones. No hay candados ni lectores que bloqueen a los escritores.

Optimización de envío de consultas: El motor analítico envía filtros a la base de datos de origen. Si la consulta solicita SELECT * WHERE region = 'Western-Region', el sistema de origen utiliza los metadatos para identificar qué microparticiones específicas contienen datos de la ‘Región Occidental’. Sólo devuelve esos bloques específicos. Esto reduce efectivamente la transferencia de red en órdenes de magnitud en comparación con un escaneo completo de la tabla.

El concepto “Unistore”

El objetivo final de Zero-Copy es la unificación de cargas de trabajo transaccionales (OLTP) y analíticas (OLAP), un concepto a menudo llamado HTAP (procesamiento híbrido transaccional/analítico).

Los paradigmas Unistore de Snowflake y Lakehouse de Databricks tienen como objetivo cerrar esta brecha. Imagine una aplicación minorista en la que una compra se escribe en una tienda transaccional. En un mundo tradicional, esa fila no aparecería en el almacén de análisis hasta el trabajo por lotes nocturno. En un mundo Unistore de copia cero, esa fila es inmediatamente visible para el motor analítico a través de una abstracción de tabla unificada.

Para la IA, esto cambia las reglas del juego. Los sistemas de recomendación pueden reaccionar al clic de un usuario dentro de la misma sesión, no solo al día siguiente.

La realidad de 2026: “Ecosistemas vivos”

Este cambio arquitectónico no se trata sólo de ahorrar espacio en disco. Se trata de agilidad organizacional.

La Perspectiva de Servicios Financieros para 2026 de Slalom predice un cambio de “soluciones estáticas y aisladas” a “ecosistemas vivos y adaptables” donde los datos fluyen libremente. Identifican Unified Data Foundations como el requisito previo para esto. Si la IA de detección de fraude de un banco tiene que esperar un trabajo por lotes nocturno, es inútil contra las amenazas de 2026 en tiempo real. El informe enfatiza que “la gobernanza permite tanto velocidad como confianza”, sugiriendo que la capa de metadatos se convertirá en el nuevo plano de control.

Las tendencias tecnológicas de McKinsey refuerzan esto, destacando que la “brecha de ejecución” en la IA es en gran medida un problema de disponibilidad de datos. Su análisis sugiere que las organizaciones capaces de actuar basándose en conocimientos en tiempo real tienen 1,6 veces más probabilidades de ver un crecimiento de dos dígitos. La capacidad de consultar datos “in situ” permite la creación de productos de datos que otros equipos pueden consumir instantáneamente sin la fricción de configurar nuevos canales.

El auge de la arquitectura de datos “sin cabeza”

A lo largo de 2026, los analistas esperan ver el predominio de las arquitecturas de datos “sin cabeza”. En este modelo, el almacenamiento y la capa semántica están completamente desacoplados de la herramienta de consumo.

• Almacenamiento: S3/Azure Blob (barato, infinito).
• Formato: Iceberg/Delta (Abierto, Transaccional).
• Catálogo: Catálogo Nessie/Unity (El “Cerebro” que realiza un seguimiento de los consejos).
• Calcular: Lo que quiera el usuario. El científico de datos utiliza PySpark; el Analista usa SQL; el director ejecutivo utiliza un panel de control. Todos ellos llegan a la misma Fuente Única de la Verdad.

Conclusión: La plataforma es el oleoducto

Para el ingeniero de datos, el conjunto de habilidades está cambiando. Escribir scripts ETL de PySpark eficientes para mover datos de A a B se está volviendo menos valioso que diseñar estrategias sólidas de gobernanza de metadatos. El valor no está en mover datos; se trata de hacer que los datos sean accesibles sin moverlos.

El oleoducto, tal como se entiende tradicionalmente, está muerto. Larga vida a la plataforma.

Fuentes (5)

• engineering.salesforce.com Zero Copy Revolutionizes Data Cloud
• slalom.com Financial Services Outlook 2026
• dataversity.net Data Management Trends 2026
• mckinsey.com Top Trends in Tech 2025
• arcadia.io Zero-Copy Data Lake