Data Lake (Lago de Datos)

Definición

Un data lake es un repositorio de almacenamiento centralizado diseñado para contener datos crudos de cualquier tipo — estructurados (tablas relacionales, archivos CSV), semi-estructurados (JSON, XML, Parquet) y no estructurados (imágenes, audio, texto libre, logs) — a escala casi ilimitada. A diferencia de un data warehouse, donde los datos deben transformarse y cumplir un esquema predefinido antes de ser cargados, el data lake acepta datos en su formato original y aplica el esquema en el momento de la consulta. Este principio se denomina "schema-on-read" y es la propiedad definidora de la arquitectura de lago.

El data lake resuelve un problema fundamental que existía antes de su adopción masiva: la necesidad de modelar y estructurar los datos antes de almacenarlos obligaba a los equipos de datos a tomar decisiones de diseño antes de entender plenamente los casos de uso analíticos. Con el data lake, los datos se ingestan primero y se modelan después — cuando ya hay claridad sobre las preguntas que necesitan respuesta. Esta flexibilidad tiene un costo: sin disciplina de gobierno, el lago rápidamente se convierte en un "data swamp" donde los datos existen pero son inaccesibles, no confiables o directamente desconocidos para los usuarios que los necesitarían.

Cómo se estructura un data lake

La arquitectura de un data lake se organiza típicamente en zonas que representan distintos niveles de procesamiento y confiabilidad de los datos. La zona de aterrizaje (landing zone o raw zone) contiene datos tal como llegaron de las fuentes — sin modificaciones, con timestamps de ingesta, en los formatos originales. La zona de procesamiento (processed o curated zone) contiene datos limpios y transformados, con validaciones aplicadas, deduplicados y listos para consulta. La zona de consumo (consumption zone) contiene conjuntos de datos listos para uso analítico, frequentemente en formato Parquet columnar optimizado para lectura.

Ejemplo práctico

Una empresa de retail omnicanal en Ciudad de México con presencia en línea y tiendas físicas opera el siguiente data lake sobre Amazon S3: en la raw zone ingesta en tiempo real los logs de transacciones del POS (Point of Sale) en formato JSON, los eventos de comportamiento del sitio web en formato CSV comprimido, las imágenes de productos del catálogo y los registros de conversaciones del centro de atención al cliente. El volumen total ingresado mensualmente es de aproximadamente 2.8 TB. Este volumen haría prohibitivamente costoso almacenar todo en un data warehouse columnar como BigQuery o Snowflake.

El equipo de datos de la empresa procesa diariamente los logs de transacciones en la curated zone, generando tablas Parquet limpias que se cargan en el data warehouse para análisis de ventas e inventario. Las imágenes de productos se mantienen en el lago para el modelo de recomendación visual que el equipo de ML entrenó sobre esos datos. Los registros de conversaciones permanecen en el lago para análisis de sentimiento periódico. El costo mensual del almacenamiento S3 para los 2.8 TB es aproximadamente USD $65 — una fracción del costo equivalente en warehouse. Este es el caso de uso central del data lake: almacenamiento barato y flexible para datos heterogéneos, con procesamiento selectivo hacia capas más estructuradas según la necesidad.

Análisis en profundidad

El concepto de data lake fue formalizado por James Dixon, CTO de Pentaho, en 2010, como respuesta a las limitaciones del data mart — que solo almacena datos procesados y modelados para un dominio específico. La promesa original era simple: almacenar todo, siempre, en su formato nativo, a un costo mínimo, y procesar lo que sea necesario cuando sea necesario. Esta promesa fue ampliamente adoptada entre 2012 y 2018, impulsada por el ecosistema Hadoop (HDFS, Hive, Spark) y luego por el almacenamiento en la nube con S3 de AWS y GCS de Google Cloud.

Entre 2018 y 2022, el paradigma del data lake enfrentó críticas crecientes. La promesa de la flexibilidad del schema-on-read resultó ser, en la práctica, una deuda técnica diferida: los equipos de datos descubrieron que aplicar el esquema en el momento de la consulta era costoso en tiempo de procesamiento y propenso a errores cuando los formatos de fuente cambiaban sin aviso. Los data lakes sin gobierno se convirtieron en data swamps en organizaciones de todos los tamaños — incluyendo empresas con inversiones millonarias en infraestructura de datos. El dato más citado es que el 73% de los datos almacenados en data lakes nunca fueron consultados en las primeras implementaciones empresariales.

La respuesta arquitectural a estas limitaciones fue el data lakehouse — una arquitectura que combina el almacenamiento barato del lago con las garantías del warehouse mediante formatos de tabla abiertos como Apache Iceberg, Delta Lake y Apache Hudi. Estos formatos añaden transacciones ACID, evolución de esquema, time-travel (consulta de datos históricos en un punto en el tiempo), y optimizaciones de índice sobre archivos Parquet en almacenamiento de objetos. El lakehouse se convirtió en el patrón dominante para nuevas arquitecturas analíticas desde 2022, con Databricks (Delta Lake), Apache Software Foundation (Iceberg, Hudi) y los principales cloud providers como principales impulsores.

En el contexto de LATAM, los data lakes presentan consideraciones particulares. Los costos de almacenamiento en la nube son relevantes pero manejables: S3 estándar en la región us-east-1 cuesta aproximadamente USD $0.023 por GB por mes, lo que hace que almacenar 10 TB cueste alrededor de USD $230 mensuales — razonable para cualquier empresa con operaciones digitales de mediana escala. El desafío mayor en LATAM no es el costo del almacenamiento sino la madurez del equipo de datos para gobernar el lago correctamente. Muchas empresas en México, Colombia y Chile implementan data lakes con tecnología cloud moderna pero sin los procesos de catalogación, ownership de dominio y monitoreo de calidad que hacen que el lago sea útil más allá de los primeros 12 meses.

La decisión de implementar un data lake puro versus un data lakehouse versus un data warehouse moderno depende de tres factores: volumen y heterogeneidad de datos, madurez del equipo de datos, y casos de uso prioritarios. Para empresas con volúmenes menores a 500 GB mensuales de datos analíticos y equipos de datos pequeños, un data warehouse moderno en la nube cubre la mayoría de los casos de uso con menor complejidad operacional. Para empresas con volúmenes mayores, datos no estructurados relevantes (imágenes, audio, texto libre) o casos de uso de ML que requieren datos crudos, el data lake o lakehouse es la arquitectura correcta. La clave no es la tecnología elegida sino la disciplina de gobierno que se establece desde el principio.

Errores frecuentes

• ✗

  Implementar un data lake sin catalogación desde el día uno. El error más común y costoso es construir el lago primero y agregar gobierno después. Sin un catálogo de datos que documente qué datos existen, quién es el owner, cuándo se actualizaron por última vez y qué significa cada campo, el data lake se convierte en data swamp en menos de 18 meses. Los datos siguen existiendo pero ningún usuario confía en ellos o sabe cómo encontrar lo que necesita. La catalogación retroactiva es entre tres y cinco veces más costosa que implementarla desde el inicio.

• ✗

  Almacenar todo sin política de retención ni clasificación. La flexibilidad del data lake genera la tentación de almacenar absolutamente todo sin criterio de retención, clasificación de sensibilidad ni política de acceso. El resultado es un repositorio que mezcla datos PII de clientes sin control de acceso con datos operacionales de bajo valor, generando riesgos de cumplimiento regulatorio (LFPDPPP en México, Habeas Data en Colombia) y costos de almacenamiento que crecen de forma no lineal. Toda ingesta de datos debe ir acompañada de clasificación de sensibilidad, policy de acceso, y política de retención explícita.

• ✗

  Confundir el data lake con el destino final en lugar de con un paso en el pipeline. El data lake es un repositorio de almacenamiento, no una plataforma analítica completa. Un error frecuente es asumir que implementar un data lake resuelve el problema de acceso a datos para los usuarios de negocio. Los usuarios de negocio no consultan el lago directamente: necesitan datos modelados, semánticamente claros y confiables, lo que requiere capas adicionales de transformación, modelado dimensional y una capa de presentación (BI, capa semántica) sobre el lago.

Cómo lo rastrea Fairview

Fairview se conecta a los datos donde residen — incluyendo fuentes que ya están en un data lake o en un data warehouse — sin requerir que el equipo migre o consolide su arquitectura de datos existente. Si la empresa tiene datos financieros en BigQuery, datos de CRM en Salesforce y datos históricos de ventas en S3, Fairview puede conectarse a cada fuente y generar una capa unificada de operating intelligence sobre ellas. La plataforma no reemplaza la infraestructura de datos de la empresa: la complementa añadiendo la capa de métricas operacionales, alertas automatizadas y Next Best Actions que los datos crudos por sí solos no producen. Para equipos que están evaluando si su data lake está generando valor operacional real — en lugar de simplemente existir como repositorio — Fairview ofrece una sesión de evaluación donde se examina el estado actual de la arquitectura de datos y se identifican los gaps de visibilidad operacional.

Preguntas frecuentes