Última actualización: 2026-11-11

Contenido de esta página

• ¿Qué es un data lake?
• Arquitectura de un data lake: las zonas bronze, silver y gold
• Formatos de archivo en un data lake: Parquet, Avro, ORC, CSV y JSON
• Un experimento: la misma tabla en CSV y en Parquet
• El pantano de datos: cómo un lago se vuelve inservible
• ¿Cuándo conviene un data lake y cuándo no?
• Lo que esta guía deja por fuera
• El lago no ahorra el trabajo: lo aplaza

Los satélites de observación de la Tierra de la NASA, la agencia espacial de Estados Unidos, no entregan un solo archivo. Entregan una escalera. El primer peldaño, el nivel 0, son los datos crudos a la resolución completa del instrumento [1]. En cada nivel siguiente, esos datos se convierten en parámetros y formatos más útiles para quien los estudia [1].

Esa escalera mostró su valor con MODIS, un sensor que va en los satélites Terra y Aqua [2]. Hubo problemas en el nivel 1B, el de los datos ya llevados a unidades del instrumento [1][2]. Esos defectos afectaban, en distinto grado, a los productos de atmósfera de los niveles 2 y 3, que se derivan de ellos [2].

La respuesta fue rehacer la serie. Se generó una colección nueva y mejorada para todos los productos MODIS del primer nivel y para los superiores del equipo de atmósfera [2].

Según el propio equipo, ese reprocesamiento empezó el 28 de septiembre de 2017 y terminó el 7 de marzo de 2018 [2].

Lo que sigue es lectura mía, no de la NASA. Rehacer los peldaños de arriba solo es posible si alguien conservó los de abajo.

Esa es la idea de un data lake, o lago de datos. Se guarda el dato como llegó y la forma se decide después, cuando aparece la pregunta.

¿Qué es un data lake?

Un data lake es un depósito central donde una organización guarda grandes volúmenes de datos en su formato original. No obliga a ordenarlos antes en tablas con columnas fijas. Caben tablas de un sistema de ventas, archivos de texto con registros de una página web, fotos o grabaciones de audio. La estructura se decide cuando alguien los va a leer.

Tres proveedores de nube publican su definición, y no dicen exactamente lo mismo. Las citas de esta página están en inglés en el original y son traducción propia.

Proveedor	Cómo define el data lake	Qué subraya
Amazon Web Services	Un repositorio centralizado para guardar todos los datos, estructurados y no estructurados, a cualquier escala, «tal como están», sin tener que estructurarlos primero [3]	No hace falta saber de antemano qué preguntas se harán [3]
Microsoft (guía de arquitectura)	Un repositorio de almacenamiento que guarda grandes volúmenes de datos en su formato nativo y crudo [4]	Incluye datos estructurados, semiestructurados y no estructurados, de muchas fuentes [4]
Microsoft (servicio de almacenamiento)	Un repositorio único y centralizado para todos los datos, que se guardan crudos o nativos, por lo general como archivos [5]	No hay que adaptar los datos a una estructura existente [5]
Google Cloud	Un repositorio centralizado, escalable y seguro, diseñado para guardar, procesar y analizar grandes cantidades de datos en su formato nativo [6]	Mete el procesamiento y el análisis dentro de la definición [6]

Las diferencias no son de fondo, pero sí de alcance. En su primera frase, Amazon y Microsoft definen el lago como un lugar para guardar. Google lo define también como un lugar para trabajar los datos. Microsoft, por su parte, resuelve esa tensión aparte: dice que una solución moderna de lago tiene dos componentes, el almacenamiento y el procesamiento [4].

Hay otro matiz. La definición de Amazon habla de datos estructurados y no estructurados [3]. Microsoft y Google añaden los semiestructurados [4][6]. Son los que traen cierta organización interna sin ser una tabla, como un archivo JSON, un formato de texto que guarda cada dato junto a su nombre [4][9].

Schema-on-read y schema-on-write: quién paga por la estructura

El esquema es la lista de columnas de una tabla, con el tipo de dato que admite cada una. La diferencia entre un lago y un almacén de datos está en el momento en que se impone ese esquema. Y en quién carga con el trabajo de imponerlo.

• Schema-on-write (esquema al escribir). La estructura se define antes de guardar, y los datos se transforman al entrar [4]. Paga quien carga los datos: diseña las tablas, limpia y transforma antes de que nadie consulte.
• Schema-on-read (esquema al leer). Los datos se guardan en su estado original y se transforman solo cuando se necesitan [4]. Paga quien consulta: cada lectura tiene que interpretar los datos crudos.

Microsoft lo traduce a costos. En el lago, el almacenamiento sale más barato y el gasto de cómputo aparece cuando los datos se procesan o se consultan [4]. Como la transformación ocurre al consultar, la respuesta tarda más [4]. Amazon pone el acento en la otra cara: se ahorra el tiempo de definir estructuras, esquemas y transformaciones antes de guardar [3].

Nada de eso es gratis. El costo de la estructura no desaparece en el lago. Cambia de dueño y de momento.

El almacén de datos es la opción contraria, la del esquema al escribir. Cómo funciona por dentro se explica en la guía del data warehouse.

Arquitectura de un data lake: las zonas bronze, silver y gold

Un lago bien organizado no es un solo montón de archivos. Se reparte en zonas o capas, y cada una guarda los datos en un grado distinto de limpieza. Microsoft describe tres capas comunes: cruda (bronze, o bronce), depurada (silver, o plata) y curada (gold, u oro) [4]. A ese diseño por capas se le llama arquitectura medallón [4][7].

Zona	Qué entra	Qué transformación se hace	Quién la lee
Cruda (bronze)	Los datos como llegan de las fuentes, en su formato original [4][7]	Mínima. Se puede añadir de dónde vino cada registro, como el nombre del archivo de origen [7]	Los procesos que alimentan la zona siguiente, no los analistas ni los científicos de datos [7]. También ingenieros de datos y equipos de auditoría [7]
Depurada (silver)	Lo que sale de la zona cruda; Databricks desaconseja cargarla directo desde la fuente [7]	Limpieza, validación y eliminación de duplicados [7]. Conserva al menos una versión de cada registro sin agregar [7]	Ingenieros de datos, analistas que necesitan el detalle y científicos de datos [7]
Curada (gold)	Lo que sale de la zona depurada [7]	Agregación y modelado de los datos según las áreas del negocio [4][7]	Analistas de negocio, científicos de datos, tableros, informes y directivos [4][7]

Fuente: guía de arquitectura de Microsoft y documentación de Databricks [4][7].

La tabla deja ver para qué sirve el orden. Si un error aparece en la zona curada, se puede rehacer desde la depurada. Si el error está en la depuración, queda la zona cruda intacta. Es la escalera de la NASA, aplicada a una empresa.

¿Las zonas son un estándar o una convención?

Son una convención. Databricks, que documenta la arquitectura medallón para su plataforma, lo dice de forma explícita: seguirla «es una buena práctica recomendada, pero no un requisito» [7]. Microsoft las presenta como capas «comunes» de una arquitectura típica [4].

Los nombres tampoco coinciden del todo. Microsoft llama curada a la capa gold [4]. Databricks describe sus tres capas como cruda, validada y enriquecida [7]. Así que dos documentos de la misma industria no le ponen el mismo nombre a la misma etapa. Lo que importa es que cada zona tenga una regla clara de qué entra y quién la lee.

Databricks añade una precisión útil. Como la capa gold modela un área de negocio, algunos clientes crean varias, por ejemplo para recursos humanos, finanzas y tecnología [7].

Formatos de archivo en un data lake: Parquet, Avro, ORC, CSV y JSON

El formato de archivo decide cuánto cuesta guardar y leer cada dato del lago. Hay dos familias. Los formatos por filas guardan un registro completo detrás de otro. Los formatos por columnas guardan juntos todos los valores de una misma columna.

Piense en una planilla de notas de un colegio. Guardarla por filas es tener una hoja por estudiante, con todas sus materias. Guardarla por columnas es tener una hoja por materia, con las notas de todos. Si el rector solo quiere el promedio de matemáticas, la segunda forma le ahorra hojear el resto.

Eso es lo que promete el formato columnar. ORC es uno de esos formatos. Su documentación lo explica así: guardar los datos por columnas «permite que el lector lea, descomprima y procese solo los valores que necesita la consulta actual» [12].

Formato	Cómo organiza los datos	¿Guarda el esquema dentro del archivo?	Uso típico
CSV	Por filas, en texto: cada registro va en su propia línea [8]	Solo los nombres, en una línea de encabezado opcional [8]	Intercambiar y convertir datos entre programas de hojas de cálculo [8]
JSON	Texto con objetos: pares de nombre y valor [9]	Cada valor va junto al nombre de su campo [9]	Datos semiestructurados, junto con XML (otro formato de texto, con etiquetas) y los archivos de registro [4]
Avro	Objetos guardados en bloques, que pueden ir comprimidos [10]	Sí: el esquema viaja con los datos [10]	Serializar datos, es decir, convertirlos en bytes para guardarlos o enviarlos entre programas [10]
Parquet	Por columnas, agrupadas en bloques de filas [11]	Sí, en los metadatos del archivo [11]	Guardar y consultar datos con eficiencia en herramientas de análisis [11]
ORC	Por columnas, en bloques que se pueden leer por separado [12]	Sí: es un formato que se describe a sí mismo [12]	Cargas de trabajo del ecosistema Hadoop, el sistema para repartir datos entre muchas máquinas [12]

Fuente: especificaciones y documentación oficial de cada formato [8]–[12].

Dos detalles de la tabla merecen explicación. Los metadatos son los datos sobre los datos: dónde empieza cada columna, cuántas filas hay, de qué tipo es cada valor. Parquet los escribe al final del archivo, y el lector los consulta primero para saber qué partes leer [11].

Avro resuelve un problema distinto. Su documentación dice que, cuando se leen datos Avro, el esquema con que se escribieron está siempre presente [10]. Por eso cada dato se escribe sin información extra por valor, y la serialización resulta rápida y compacta [10].

¿Qué se paga al escribir en formato columnar?

El formato columnar se lee barato, pero alguien tiene que ordenarlo al escribir. El escritor de ORC elige la codificación más adecuada para cada tipo de dato y arma un índice interno mientras escribe el archivo [12]. Parquet admite comprimir cada columna con un método distinto [11].

Ese trabajo tiene un efecto práctico. Un archivo Parquet no se lee con un editor de texto: es un formato binario, hecho para que lo lea un programa [13]. Un CSV, en cambio, lo entiende cualquier persona con un editor de texto.

Un experimento: la misma tabla en CSV y en Parquet

La diferencia entre filas y columnas se puede medir en un computador cualquiera. El código escribe la misma tabla en los dos formatos y lee una sola columna de cada uno. Usa Python con pandas 3.1.1, la librería para trabajar tablas en Python [13], y pyarrow 26.0.1, la que lee y escribe Parquet [14].

Los datos son sintéticos: un millón de ventas inventadas, con una semilla fija para que cualquiera obtenga la misma tabla.

# Experimento: la misma tabla en CSV y en Parquet.
# Datos SINTÉTICOS (inventados), con semilla fija para que cualquiera los reproduzca.
import os, time, statistics
import numpy as np
import pandas as pd

rng = np.random.default_rng(seed=2026)   # semilla fija
n = 1_000_000                            # un millón de filas

tabla = pd.DataFrame({
    "id_venta": np.arange(n),
    "fecha": pd.Timestamp("2025-01-01") + pd.to_timedelta(rng.integers(0, 365, n), unit="D"),
    "ciudad": rng.choice(["Bucaramanga", "Cúcuta", "Pasto", "Neiva", "Montería"], n),
    "producto": rng.choice(["arroz", "panela", "café", "aceite", "lentejas"], n),
    "unidades": rng.integers(1, 20, n),
    "precio": rng.integers(1_000, 30_000, n),
})
tabla["total"] = tabla["unidades"] * tabla["precio"]

def cronometrar(funcion, repeticiones=5):
    """Corre la función varias veces y devuelve la mediana en segundos."""
    tiempos = []
    for _ in range(repeticiones):
        inicio = time.perf_counter()
        funcion()
        tiempos.append(time.perf_counter() - inicio)
    return statistics.median(tiempos)

# 1. Escribir la misma tabla en los dos formatos
t_csv_esc = cronometrar(lambda: tabla.to_csv("ventas.csv", index=False), 3)
t_pq_esc = cronometrar(lambda: tabla.to_parquet("ventas.parquet", index=False), 3)

# 2. Leer UNA sola columna ("total") de cada archivo
t_csv_lee = cronometrar(lambda: pd.read_csv("ventas.csv", usecols=["total"]))
t_pq_lee = cronometrar(lambda: pd.read_parquet("ventas.parquet", columns=["total"]))

# 3. Comprobar que las dos lecturas traen exactamente los mismos números
iguales = pd.read_csv("ventas.csv", usecols=["total"])["total"].equals(
    pd.read_parquet("ventas.parquet", columns=["total"])["total"])

mb = lambda ruta: os.path.getsize(ruta) / 1_000_000
print(f"Filas: {n:,}  | columnas: {tabla.shape[1]}")
print(f"Tamaño en disco   CSV: {mb('ventas.csv'):6.1f} MB   Parquet: {mb('ventas.parquet'):6.1f} MB")
print(f"Escribir (s)      CSV: {t_csv_esc:6.2f}      Parquet: {t_pq_esc:6.2f}")
print(f"Leer 'total' (s)  CSV: {t_csv_lee:6.3f}     Parquet: {t_pq_lee:6.3f}")
print(f"¿Mismos valores en ambas lecturas? {iguales}")

En mi máquina, con estos datos sintéticos, el resultado fue este. Es un computador con Windows 11, procesador Intel y Python 3.11.15.

Medida	CSV	Parquet
Tamaño en disco	49,0 MB	13,6 MB
Tiempo para escribir la tabla (mediana)	3,39 s	0,48 s
Tiempo para leer solo la columna «total» (mediana)	0,149 s	0,023 s

Las dos lecturas trajeron exactamente los mismos valores. Una segunda corrida dio cifras muy parecidas.

El archivo Parquet ocupó menos, en parte porque pandas lo comprime por defecto con un método llamado Snappy [13]. Y leyó la columna más rápido porque fue directo a ella, mientras el CSV tuvo que recorrer todas las líneas del texto.

Un resultado contradice la intuición de que ordenar por columnas encarece la escritura. Escribir Parquet también fue más rápido. Lo más probable es que convertir un millón de números a texto le cueste más a pandas que codificarlos en binario, pero no lo medí por separado. Con otros datos, otra máquina u otra librería, las proporciones cambian. No tome estas cifras como una ley.

El segundo hallazgo cabe en cuatro líneas. El CSV solo sabe los nombres de sus columnas; el Parquet sabe también el tipo de cada una [14].

# ¿Qué sabe cada archivo de sí mismo?
import pyarrow.parquet as pq

# El CSV solo trae, en su primera línea, los nombres de las columnas
with open("ventas.csv", encoding="utf-8") as archivo:
    print(archivo.readline().strip())

# El Parquet guarda el esquema: cada columna con su tipo de dato
print(pq.read_schema("ventas.parquet").remove_metadata())

La salida:

id_venta,fecha,ciudad,producto,unidades,precio,total
id_venta: int64
fecha: timestamp[us]
ciudad: large_string
producto: large_string
unidades: int64
precio: int64
total: int64

En esa salida, int64 es un número entero, timestamp es una fecha con hora y large_string es texto. Quien abre el CSV tiene que adivinar que «2025-11-07» es una fecha. El Parquet ya lo dice. Ese es el esquema al leer en pequeño: el CSV deja todo el trabajo de interpretación para quien consulta.

El pantano de datos: cómo un lago se vuelve inservible

Un pantano de datos, o data swamp, es un lago donde la información está guardada pero ya nadie la encuentra ni confía en ella. Amazon lo describe como el reto principal de esta arquitectura: los datos crudos se guardan sin supervisión de su contenido [3]. Sin mecanismos para catalogarlos y protegerlos, escribe, los datos no se pueden encontrar ni son confiables, y el resultado es un «pantano de datos» [3].

Microsoft llega a la misma conclusión por otro camino. Sin un catálogo adecuado, los lagos pueden degenerar en pantanos, donde la información valiosa existe pero es inaccesible o se malinterpreta [4].

El remedio no exige una política completa. Exige un mínimo que se cumpla siempre:

1. Un catálogo. Un inventario que diga qué conjunto de datos hay, de dónde viene y qué significa cada campo. Amazon lo pone entre los requisitos para que el lago sea utilizable [3].
2. Control de acceso. Quién puede leer y quién puede escribir en cada zona [3].
3. Validación y seguimiento de la calidad. Sin ellos, las cargas con errores o incompletas comprometen la confiabilidad de todo el lago [4].
4. Originales intactos. Los archivos de origen se conservan sin modificar cuando la auditoría o la recuperación dependen de ellos, y las copias optimizadas se escriben aparte [4].
5. Una regla de retención. Una política que borre las copias procesadas o duplicadas cuando ya nadie los necesita para consultar, recuperar o cumplir una norma [4].

Quién es el dueño de cada dato y cómo se documenta su recorrido es materia del gobierno de datos.

¿Cuándo conviene un data lake y cuándo no?

Un data lake conviene cuando los datos son muchos, muy variados y todavía no se sabe qué preguntas se les harán. No conviene cuando las preguntas ya están claras y los datos llegan en tablas ordenadas. Esta es la lista de señales, sacada de lo que dicen los propios proveedores.

Señales a favor:

1. Datos de muchos tipos. Fotos, audio, registros de aplicaciones y tablas en un mismo lugar. El lago los maneja de forma nativa; un almacén exige formatos estructurados [4].
2. Exploración y aprendizaje automático. Microsoft recomienda el lago para el análisis exploratorio, la ciencia de datos avanzada y el aprendizaje automático, el que entrena programas con ejemplos [4].
3. Flujos continuos de datos. Sensores conectados a internet o eventos que llegan sin pausa, que deben guardarse a gran escala sin un esquema previo [4].
4. Archivo de largo plazo. Conservar datos históricos o crudos por auditoría o por exigencia regulatoria [4].

Señales en contra:

1. Informes repetidos sobre datos ordenados. Para eso está optimizado el almacén de datos, con respuestas más rápidas sobre datos ya procesados [4][6].
2. Respuestas que no pueden esperar. En el lago, la transformación ocurre al consultar, y eso aumenta la demora [4].
3. Una organización sin capacidad para administrarlo. Administrar grandes volúmenes de datos crudos exige infraestructura sólida, procesamiento distribuido y un manejo cuidadoso de los costos [4].

El último punto es el que más pesa en una empresa mediana o en una entidad territorial. Un lago necesita a alguien que lo cuide todos los días. Sin esa persona, la lista de señales a favor deja de importar.

Hay un camino intermedio que Microsoft documenta: el lago como fuente de un almacén de datos. Los datos crudos llegan al lago y desde ahí pasan al almacén, que con su propio motor los convierte en tablas estructuradas [4]. Cuando el volumen obliga a repartir el trabajo entre muchas máquinas, entra el terreno del big data.

Lo que esta guía deja por fuera

Cuatro temas vecinos tendrán desarrollo propio. El lakehouse, un enfoque que combina el almacenamiento crudo del lago con el rendimiento de consulta del almacén [4], y con él tecnologías como Delta Lake. La comparación detallada entre lago y almacén, punto por punto. Los servicios de almacenamiento de cada nube y cómo se cobran. Y la ingesta, es decir, cómo llegan los datos al lago desde sus fuentes.

Todo eso pertenece al oficio más amplio de la ingeniería de datos, que construye los caminos por donde viajan los datos.

El lago no ahorra el trabajo: lo aplaza

Lo digo como opinión, no como dato. En Colombia y en buena parte de la región, el riesgo no es que falte un lago. Es montar uno porque suena moderno y descubrir un año después que nadie sabe qué hay adentro.

El esquema al leer es una promesa con letra menuda. Promete que no hay que decidir hoy la forma de los datos. No promete que alguien la vaya a decidir mañana.

La NASA rehízo su serie de MODIS [2]. Mi lectura es que fue posible porque su escalera tenía peldaños con nombre y especificaciones revisadas por la propia agencia [1]. Un lago sin catálogo, sin zonas y sin dueño no es una escalera. Es un sótano. Si su organización no puede sostener ese orden, un almacén de datos bien hecho le servirá más que el lago más grande.

Preguntas frecuentes

¿Cómo se dice data lake en español? En español se dice lago de datos. En esta guía, data lake y lago de datos se usan como sinónimos; repositorio es la palabra que repiten los proveedores para describirlo [3][6].

¿Un data lake es una base de datos? No en el sentido habitual. Una base de datos relacional impone tablas y tipos antes de guardar. Un lago guarda archivos, por lo general tal como llegan, y deja la estructura para el momento de la lectura [4][5]. Puede contener tablas, pero también fotos o audio.

¿Qué ejemplos de data lake hay? Microsoft enumera usos comunes [4]. Uno es reunir en un solo repositorio datos de servicios en la nube, sensores y sistemas propios. Otros son procesar datos de gran volumen, entrenar modelos de inteligencia artificial, alimentar tableros y archivar datos por cumplimiento normativo [4]. La serie de niveles de la NASA no es un lago, pero sigue la misma lógica de guardar lo crudo [1].

¿Qué significan bronze, silver y gold? Son los nombres de tres capas de calidad dentro de un lago o de una plataforma de datos. Bronze guarda lo crudo, silver lo validado y gold lo listo para el negocio [7]. Databricks los recomienda como buena práctica, sin exigirlos [7].

¿Qué formato conviene usar en un data lake? Depende de la consulta. Si se leen pocas columnas de tablas grandes, un formato columnar como Parquet u ORC suele ahorrar lectura, porque va directo a la columna pedida [11][12]. Si los datos viajan entre programas registro por registro, Avro está pensado para eso [10].

Referencias

1. NASA Earthdata. Data Processing Levels — los productos de datos de EOSDIS se procesan en niveles del 0 al 4; el nivel 0 son datos crudos a la resolución completa del instrumento y en niveles superiores se convierten en parámetros y formatos más útiles; los datos L1B son datos L1A procesados a unidades del instrumento. NASA Earthdata: Data Processing Levels — Consultada: 2026-11-11.
2. NASA, MODIS Atmosphere Team. Collection 6.1 (061) — la nueva colección 6.1 para todos los productos MODIS de nivel 1 y los de nivel 2 y 3 del equipo de atmósfera respondió a problemas del nivel 1B de la colección 6, que afectaban en distinto grado a los productos derivados; el reprocesamiento empezó el 28 de septiembre de 2017 y terminó el 7 de marzo de 2018. NASA MODIS Atmosphere: Collection 6.1 — Consultada: 2026-11-11.
3. Amazon Web Services. What is a data lake? — repositorio centralizado para todos los datos estructurados y no estructurados a cualquier escala, guardados «as-is», sin estructurarlos primero; ahorro del tiempo de definir estructuras, esquemas y transformaciones; no hace falta saber qué preguntas se harán; catalogar y proteger los datos; sin esos mecanismos, los datos no se encuentran ni son confiables y resulta un «data swamp». AWS: What is a data lake? — Consultada: 2026-11-11.
4. Microsoft. What is a data lake?, Azure Architecture Center (última actualización: 6 de noviembre de 2026) — definición; schema-on-read frente a schema-on-write; usos comunes; dos componentes (almacenamiento y procesamiento); capas comunes raw (bronze), cleansed (silver) y curated (gold), llamadas arquitectura medallón; cuándo usar un lago; el lago como fuente de un almacén; tabla de latencia, transformación y costos; retos (complejidad, integridad, calidad, catálogo y «data swamps»); conservar originales, compactar, archivar y borrar con política de retención. Microsoft Learn: What is a data lake? — Consultada: 2026-11-11.
5. Microsoft. Introduction to Azure Data Lake Storage (última actualización: 3 de julio de 2026) — un data lake es un repositorio único y centralizado para datos estructurados y no estructurados, sin adaptarlos a una estructura existente, guardados en formato crudo o nativo, por lo general como archivos o como objetos binarios. Microsoft Learn: Introduction to Azure Data Lake Storage — Consultada: 2026-11-11.
6. Google Cloud. What is a Data Lake? — repositorio centralizado, escalable y seguro para guardar, procesar y analizar grandes cantidades de datos estructurados, semiestructurados y no estructurados en su formato nativo; el almacén tradicional está optimizado para informes repetibles y análisis SQL estructurado. Google Cloud: What is a Data Lake? — Consultada: 2026-11-11.
7. Databricks. What is the medallion lakehouse architecture? (última actualización: 29 de octubre de 2026) — capas bronze (raw), silver (validated) y gold (enriched); «Following the medallion architecture is a recommended best practice but not a requirement»; qué pasa y quién usa cada capa; bronze no está pensada para analistas ni científicos de datos; silver se construye desde bronze, con limpieza, validación y deduplicación; la capa gold modela dominios de negocio y algunos clientes crean varias. Databricks: Medallion lakehouse architecture — Consultada: 2026-11-11.
8. Shafranovich, Y. RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files, IETF (2005) — cada registro va en una línea aparte; la línea de encabezado con los nombres de los campos es opcional. IETF: RFC 4180 — Consultada: 2026-11-11.
9. Bray, T. (ed.). RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format, IETF (2017) — un objeto es un conjunto de pares de nombre y valor; cuatro tipos primitivos. IETF: RFC 8259 — Consultada: 2026-11-11.
10. Apache Avro. Documentation y Specification — sistema de serialización de datos; al leer datos Avro, el esquema con que se escribieron está siempre presente, lo que permite guardar cada dato sin información adicional por valor; el esquema se guarda con el archivo; los objetos se guardan en bloques que pueden ir comprimidos. Apache Avro: Documentation · Apache Avro: Specification — Consultada: 2026-11-11.
11. Apache Parquet. Overview, Motivation, Concepts y File Format, con la definición Thrift del formato — formato de archivo de datos de código abierto, orientado a columnas, diseñado para guardar y recuperar datos con eficiencia; compresión especificable por columna; grupos de filas con un fragmento por columna; los metadatos se escriben después de los datos y el lector los consulta primero; los metadatos del archivo incluyen el esquema. Apache Parquet: Overview · Apache Parquet: Motivation · Apache Parquet: File Format · Apache Parquet: parquet.thrift — Consultada: 2026-11-11.
12. Apache ORC. Background (documentación) — formato columnar que se describe a sí mismo y conoce los tipos, diseñado para cargas de trabajo de Hadoop; «Storing data in a columnar format lets the reader read, decompress, and process only the values that are required for the current query»; el escritor elige la codificación por tipo y construye un índice interno al escribir; bloques (stripes) independientes. Apache ORC: Documentation — Consultada: 2026-11-11.
13. pandas. pandas.DataFrame.to_parquet, pandas.read_parquet y pandas.read_csv, documentación de pandas 3.1.1 — escribe en el formato binario Parquet, con compresión Snappy por defecto; lectura de columnas seleccionadas con columns y usecols. pandas: DataFrame.to_parquet · pandas: read_parquet · pandas: read_csv — Consultada: 2026-11-11.
14. Apache Arrow. Releases y pyarrow.parquet.read_schema — versión 26.0.1 publicada el 3 de noviembre de 2026; función para leer el esquema de un archivo Parquet. Apache Arrow: Releases · Apache Arrow: pyarrow.parquet.read_schema — Consultada: 2026-11-11.

Cómo investigamos esta página

• Pregunta que responde: Qué es un lago de datos, quién paga la estructura al leer o al escribir, cómo se ordena por zonas, qué formatos usa y cuándo conviene.
• Fuentes: identificadas 35 → incluidas 14
• Criterios de inclusión: documentación oficial de proveedores y de proyectos de código abierto, normas técnicas y páginas de la NASA; sin blogs, foros ni enciclopedias.
• Fecha de corte de los datos: 2026-11-11