Data Lake vs. Cloud Data Warehouse: una guía práctica para científicos de datos

Un data lake es un repositorio centralizado que almacena datos sin procesar en su formato nativo (estructurados, semiestructurados y no estructurados) utilizando almacenamiento de objetos en la nube de bajo costo. A diferencia de un cloud data warehouse, que impone un esquema predefinido antes de poder cargar los datos, un data lake aplica la estructura solo en el momento de la lectura, lo que brinda a los científicos de datos y a los ingenieros de datos la máxima flexibilidad para trabajar con diversos tipos de datos sin necesidad de una transformación previa. Ambas arquitecturas residen en la infraestructura de la nube, pero responden a preguntas fundamentalmente diferentes sobre cómo recopilar, procesar y recuperar datos a escala.

Esta guía está escrita para científicos de datos, ingenieros de datos y líderes de analítica que necesitan un marco de decisión práctico, no un discurso de ventas de un proveedor. Al finalizar, comprenderá las diferencias clave entre un data lake y un cloud data warehouse, cuándo un data lakehouse cierra esa brecha y cómo elegir la arquitectura de almacenamiento de datos adecuada para sus cargas de trabajo específicas.

Resumen rápido de recomendaciones

Antes de profundizar en los aspectos técnicos, aquí tiene la guía práctica que la mayoría de los equipos necesitan de antemano.

Elija un data lake cuando su necesidad principal sea almacenar datos sin procesar y en múltiples formatos a escala de petabytes para machine learning, ciencia de datos o futuros casos de uso de analítica que aún no se hayan definido. Los data lakes ofrecen escalabilidad a un costo por gigabyte menor que los cloud data warehouses y admiten todo tipo de datos sin requerir un esquema antes de la ingesta.

Elija un cloud data warehouse cuando su carga de trabajo se centre en consultas SQL rápidas y concurrentes sobre datos empresariales estructurados: dashboards, informes financieros, estados de cuenta de clientes y analítica operativa, donde la baja latencia de las consultas y la alta concurrencia importan más que la flexibilidad de almacenamiento.

Elija un data lakehouse cuando su organización ejecute cargas de trabajo tanto de machine learning como de business intelligence y necesite una plataforma unificada que elimine la duplicación de datos entre un lake y un warehouse. Los lakehouses ofrecen soporte para transacciones ACID directamente en el almacenamiento del lake, lo que los convierte en la opción predeterminada y práctica para la mayoría de las plataformas de datos modernas.

¿Qué es un data lake?

Un data lake es un repositorio centralizado diseñado para almacenar todos sus datos (estructurados, semiestructurados y no estructurados) en su formato original y sin procesar hasta que se necesiten para el análisis. Los data lakes surgieron específicamente para hacer frente a la explosión de las necesidades de almacenamiento de datos no estructurados que las bases de datos relacionales tradicionales y los data warehouses no podían albergar de manera económica.

La característica definitoria de un data lake es que acepta datos de inmediato utilizando la metodología Extract, Load, Transform (ELT), aplicando el esquema en la lectura (schema-on-read) en lugar del esquema en la escritura (schema-on-write). Esto significa que los ingenieros de datos pueden ingestar archivos de registro (logs), eventos JSON, imágenes, videos, flujos de sensores y tablas de bases de datos en el mismo sistema sin definir primero cómo se consultarán esos datos. Los científicos de datos obtienen acceso directo a los datos sin procesar en cualquier formato en el que hayan llegado, lo cual es esencial para la ingeniería de características (feature engineering) y el desarrollo de modelos de machine learning.

Los cloud data lakes suelen ejecutarse en servicios de almacenamiento de objetos: Amazon S3, Azure Data Lake Storage (ADLS) y Google Cloud Storage, que proporcionan una capacidad prácticamente ilimitada. Los data lakes pueden almacenar petabytes de información sin limitaciones fijas, y el costo por gigabyte es sustancialmente menor que el del almacenamiento propietario utilizado por los data warehouses heredados. Esta escalabilidad a un menor costo por gigabyte convierte a los data lakes en la opción práctica para el almacenamiento de big data donde el volumen es la principal preocupación.

Los data lakes admiten todos los tipos de datos: exportaciones de bases de datos estructuradas, formatos semiestructurados como JSON y Parquet, y contenido totalmente no estructurado como corpus de texto, audio e imágenes. Esta amplitud los convierte en la zona de aterrizaje natural para cualquier organización que necesite conservar datos sin procesar para futuras analíticas, incluidos los casos de uso que aún no se han definido en el momento de la ingesta.

Contexto de los cloud data warehouses y las bases de datos relacionales

Un cloud data warehouse es una base de datos analítica gestionada y optimizada para consultas SQL de alta concurrencia sobre datos estructurados y listos para el negocio. A diferencia de una base de datos relacional diseñada para cargas de trabajo transaccionales (insertar y actualizar filas individuales en tiempo real), un cloud data warehouse está diseñado para cargas de trabajo analíticas que escanean grandes volúmenes de datos históricos para generar agregados, informes y dashboards.

Los cloud data warehouses imponen un modelo de esquema en la escritura (schema-on-write): los datos deben limpiarse, tipificarse y adaptarse a un esquema predefinido antes de poder cargarse. Esta restricción es la fuente tanto de la mayor fortaleza del warehouse como de su limitación más significativa. Dado que cada fila de cada tabla se ajusta a una estructura conocida, el almacenamiento en columnas y las técnicas de aceleración de consultas (como predicate pushdown, zone maps y almacenamiento en caché de resultados) se pueden aplicar de forma agresiva, lo que ofrece el rendimiento de consultas de menos de un segundo que los usuarios de negocios y los analistas de datos esperan de los dashboards.

Los principales proveedores de cloud data warehouses, incluidos Amazon Redshift, Google BigQuery, Snowflake y Databricks Lakehouse, han desacoplado el cómputo del almacenamiento, lo que significa que la capacidad de consulta puede escalar independientemente de los datos almacenados. Esta arquitectura admite cargas de trabajo de alta concurrencia en las que cientos de usuarios ejecutan consultas simultáneas sin conflictos. Para los casos de uso de business intelligence (informes de ingresos, estados de cuenta de clientes, analítica de inventario), el cloud data warehouse sigue siendo la opción dominante porque el rendimiento de las consultas y la consistencia de los datos son innegociables.

Donde los cloud data warehouses tienen dificultades es con los tipos de datos que no se ajustan a un modelo relacional: texto no estructurado, flujos de sensores sin procesar, embeddings de imágenes y registros de eventos semiestructurados. Cargar estos datos en un warehouse requiere un trabajo de transformación sustancial y, a menudo, da como resultado que los datos se descarten o se aproximen para ajustarse a un esquema, lo que afecta la integridad que requieren las cargas de trabajo de machine learning.

Arquitectura de data lake y soluciones de almacenamiento

La arquitectura de data lake suele organizarse en tres zonas, cada una de las cuales representa un nivel progresivamente más alto de calidad de datos y preparación para el negocio.

Zona sin procesar (capa Bronze)

La zona sin procesar es el área de aterrizaje inicial para los datos ingestados desde sistemas de origen externos. Los datos llegan en su formato nativo (exportaciones de bases de datos, respuestas de API, eventos de streaming, archivos planos) y se escriben en el almacenamiento de objetos con una transformación mínima. El objetivo es la fidelidad: preservar el registro original para que todo el pipeline se pueda volver a ejecutar desde el principio si cambia la lógica posterior. Se agregan metadatos, marcas de tiempo de carga e identificadores de origen, pero los datos en sí no se modifican.

Zona depurada (capa Silver)

En la zona depurada, los datos sin procesar se cotejan, se fusionan y se adaptan para obtener una vista empresarial unificada. Se aplican controles de calidad de datos, se resuelven los registros duplicados y se combinan los datos de múltiples fuentes en entidades coherentes: clientes, transacciones, productos. Esta capa admite el análisis exploratorio, los informes ad-hoc y la experimentación de ciencia de datos sin exponer datos sin procesar a los consumidores posteriores.

Zona curada (capa Gold)

La zona curada contiene agregados a nivel empresarial listos para producción y preparados para el consumo por parte de dashboards, analítica operativa y modelos de machine learning. Los datos de esta capa han superado todos los filtros de calidad y están organizados en estructuras listas para el consumo (esquemas de estrella, tablas anchas, métricas preagregadas) que admiten consultas de alto rendimiento. La arquitectura de medallón, que formaliza las capas Bronze, Silver y Gold como distintas etapas del pipeline, es el patrón más adoptado para organizar la arquitectura de data lake.

El almacenamiento de objetos es la base de las tres zonas. Formatos como Apache Parquet y Apache ORC proporcionan codificación en columnas que reduce el espacio de almacenamiento y acelera los escaneos analíticos. Los formatos abiertos desacoplan los datos del motor de procesamiento de cualquier proveedor único, lo que permite que múltiples herramientas consulten los mismos archivos sin necesidad de copiarlos.

Costos de almacenamiento de datos y escalabilidad

Las comparaciones de costos entre los data lakes y los cloud data warehouses deben tener en cuenta tanto el almacenamiento como el cómputo por separado, ya que las arquitecturas modernas desacoplan ambos componentes.

El almacenamiento de data lake en niveles de almacenamiento de objetos en la nube resulta significativamente más económico que el almacenamiento propietario de los warehouses, a menudo por un orden de magnitud en el precio por gigabyte sin procesar. Para las organizaciones que almacenan grandes volúmenes de datos históricos o sin procesar que se consultan con poca frecuencia, los niveles de almacenamiento frío (Amazon S3 Glacier, Azure Archive) reducen aún más los costos, aunque con una mayor latencia de recuperación. Los data lakes son más rentables que los data warehouses precisamente porque el almacenamiento de objetos se diseñó para ofrecer durabilidad y escala, no rendimiento de consultas.

Los cloud data warehouses aplican precios por consulta o por unidad de cómputo, lo que los hace rentables para cargas de trabajo regulares y de alto valor, pero costosos para consultas ad-hoc o exploratorias en grandes conjuntos de datos. Los modelos de precios de pago por uso en los cloud data warehouses modernos ayudan (se paga por las consultas ejecutadas en lugar de por un tamaño de clúster fijo), pero el costo por terabyte de datos procesados sigue siendo sustancialmente mayor que el del almacenamiento en el lake.

La implicación práctica es que las decisiones sobre la arquitectura de almacenamiento de datos rara vez son opciones excluyentes. Muchas organizaciones almacenan todos los datos en un lago por rentabilidad y luego mueven selectivamente conjuntos de datos seleccionados a un almacén para BI de alta concurrencia. El costo de duplicación de mantener dos copias (una en el lago y otra en el almacén) es el principal motor detrás de la adopción de un lakehouse.

Machine learning y analítica avanzada para científicos de datos

Los data lakes se crearon para el machine learning. La capacidad de almacenar datos brutos en su formato nativo significa que los científicos de datos pueden acceder a la fidelidad total de los datos históricos (no a un subconjunto preagregado o limitado por un esquema), lo cual es esencial para entrenar modelos de alta calidad.

La ingeniería de características para machine learning requiere transformaciones iterativas y exploratorias en diversos tipos de datos. Un científico de datos que entrena un modelo de detección de fraudes necesita registros de transacciones en bruto, datos de huellas dactilares de dispositivos, secuencias de comportamiento e historial de cuentas, la mayoría de los cuales no se ajustan perfectamente a un esquema relacional. Los data lakes proporcionan una consistencia de datos central en varias aplicaciones, al tiempo que conservan el formato en bruto que requieren las pipelines de ML.

Los data lakes se integran de forma nativa con las herramientas de ciencia de datos y analítica avanzada. Apache Spark, el estándar de facto para ML distribuido a escala, lee directamente del almacenamiento de objetos utilizando formatos abiertos. Las bibliotecas de Python utilizadas para el entrenamiento de modelos (PyTorch, TensorFlow, scikit-learn) acceden al almacenamiento del lago a través de las mismas API compatibles con S3. Los ingenieros de datos pueden ejecutar pipelines de datos en streaming que alimentan características en tiempo real a los modelos sin tener que mover los datos a un sistema independiente.

Los almacenes de datos en la nube contribuyen a los flujos de trabajo de ML principalmente en la fase de inferencia y puntuación. Una vez que se entrena un modelo, la puntuación operativa en tablas estructuradas del almacén (como ejecutar una predicción de abandono en una tabla de clientes o puntuar clientes potenciales en una exportación de CRM) se beneficia de la optimización de consultas e indexación del almacén. Una arquitectura de ML madura coloca el almacén de características en el límite: la computación de características en bruto ocurre en el lago, mientras que las tablas de características listas para servir se materializan en un formato accesible tanto para el almacén como para la capa de servicio del modelo.

Cargas de trabajo de analítica de datos y BI

Las cargas de trabajo de inteligencia de negocios (BI) (paneles de control, informes programados, consultas ad-hoc de analistas de negocios) tienen requisitos que diferieren fundamentalmente del machine learning. Los usuarios de BI necesitan respuestas de baja latencia (menos de un segundo para la carga de paneles), resultados consistentes entre usuarios concurrentes y datos que reflejen las definiciones comerciales acordadas, no valores de origen en bruto.

Los almacenes de datos en la nube están diseñados específicamente para estos requisitos. El almacenamiento en columnas, la caché de resultados y las vistas materializadas garantizan que las consultas comunes de los paneles devuelvan resultados en milisegundos, incluso a medida que crecen los datos. El control de acceso detallado permite a los analistas de datos consultar los datos de su departamento sin exponer registros confidenciales de otras unidades de negocio. Los usuarios de negocios pueden ejecutar SQL directamente en tablas estructuradas sin necesidad de comprender las opciones de almacenamiento de datos subyacentes o los formatos de archivo.

Los data lakes pueden servir cargas de trabajo de BI a través de motores de consulta SQL (Apache Hive, Presto, Trino, Spark SQL), pero tradicionalmente ofrecían un rendimiento de consulta inferior en comparación con los almacenes diseñados específicamente. La flexibilidad del esquema en la lectura (schema-on-read) conlleva una sobrecarga de planificación de consultas que se hace evidente bajo una alta concurrencia. Para paneles en tiempo real e inteligencia de negocios de alta concurrencia, la opción adecuada es un almacén de datos en la nube o un lakehouse con una capa SQL de alto rendimiento.

Los datos en streaming para paneles en tiempo real son cada vez más comunes: lecturas de sensores, flujos de clics de sitios web, eventos de pago. Tanto los data lakes como los almacenes de datos en la nube admiten la ingesta en streaming a través de conectores a Kafka, Kinesis y sistemas similares, pero el soporte del lago para pipelines de datos en streaming sin restricciones de esquema lo convierte en la zona de aterrizaje más natural para flujos de eventos de alta velocidad y esquema variable.

Diferencias clave: Data lakes frente a almacenes de datos en la nube

La siguiente comparación cubre las dimensiones que más importan en las decisiones de arquitectura.

Modelo de esquema

Los data lakes utilizan el esquema en la lectura (schema-on-read): la estructura se aplica cuando se consultan los datos, no cuando se escriben. Cualquier tipo de datos se puede ingestar de inmediato sin un diseño previo. Los almacenes de datos en la nube requieren un esquema en la escritura (schema-on-write): los datos deben ajustarse a una estructura predefinida antes de cargarse, lo que impone la calidad de los datos pero ralentiza la ingesta y limita la flexibilidad. Esta distinción impulsa la mayoría de las demás diferencias a continuación.

Rendimiento de las consultas

Los almacenes de datos en la nube ofrecen un rendimiento de consultas superior para cargas de trabajo estructuradas basadas en SQL, especialmente bajo una alta concurrencia. Los motores de columnas diseñados específicamente, el almacenamiento en caché inteligente y las optimizaciones de compilación de consultas producen respuestas de menos de un segundo para los patrones de BI comunes. Los motores de consulta de data lakes tradicionales son más lentos para SQL concurrente, pero han mejorado sustancialmente con los motores vectorizados modernos. Los data lakes siguen siendo más rápidos para el procesamiento por lotes a gran escala y las cargas de trabajo de entrenamiento de ML, donde el cómputo del almacén sería prohibitivamente costoso.

Gobernanza de datos y madurez de la preparación

Los almacenes de datos en la nube tienen una gobernanza integrada más madura: los controles de acceso a nivel de tabla y columna, el registro de auditoría, el seguimiento del linaje de datos y los tipos de datos obligatorios son características estándar. Los data lakes tradicionales requieren herramientas adicionales (catálogos de datos, capas de gestión de metadatos, sistemas de control de acceso externos) para alcanzar una madurez de gobernanza equivalente. La brecha se ha reducido significativamente con servicios de catálogo como Unity Catalog, pero los almacenes siguen teniendo ventaja para las organizaciones con requisitos de cumplimiento estrictos.

Costo por terabyte

Los data lakes almacenan datos a un costo por terabyte sustancialmente menor que los almacenes de datos en la nube, a menudo entre 10 y 100 veces más barato, según el nivel de almacenamiento y la frecuencia de las consultas. Para grandes volúmenes de datos, datos históricos e ingesta en bruto, la ventaja de costo del lago es decisiva. Para los datos comerciales preparados y consultados con frecuencia, el rendimiento del almacén justifica su mayor costo.

Formatos y tipos de datos admitidos

Los data lakes admiten todos los tipos de datos: exportaciones relacionales estructuradas, JSON y XML semiestructurados, texto no estructurado, imágenes, audio y archivos binarios. Los almacenes están optimizados para datos estructurados almacenados en tablas de bases de datos y ofrecen un soporte nativo limitado o nulo para datos no estructurados y semiestructurados. El almacenamiento de datos diversos (archivos de registro junto con transacciones financieras y metadatos de imágenes) es un caso de uso típico de un lago.

Perfiles de usuario principales

Los ingenieros de datos y los científicos de datos son los usuarios principales de los entornos de data lakes: necesitan acceso directo a todos los datos en su formato nativo para el desarrollo de pipelines y el entrenamiento de modelos. Los analistas de datos y los usuarios de negocios son los principales consumidores de los almacenes de datos en la nube: necesitan datos limpios, confiables y de respuesta rápida para consultas SQL e informes. Los lakehouses de datos sirven a ambos perfiles desde una única plataforma, que es la razón principal de su rápida adopción.

Data lakehouses: uniendo lagos y almacenes

Un data lakehouse es una arquitectura de plataforma de datos que combina el almacenamiento flexible y de bajo costo de un data lake con las capacidades de gestión de datos y el rendimiento de consultas de un almacén de datos, en un único sistema unificado. El lakehouse elimina el costo operativo más caro de la arquitectura de dos sistemas: mantener una copia separada de los datos preparados en el almacén.

La capa de almacenamiento transaccional es la innovación clave. Los formatos de tabla abiertos (Delta Lake, Apache Iceberg y Apache Hudi) añaden soporte para transacciones ACID directamente al almacenamiento de objetos. Las transacciones ACID garantizan que cada operación de escritura se realice correctamente por completo o se revierta por completo, lo que evita la corrupción de datos por escrituras concurrentes. Esta garantía, que los almacenes de datos han proporcionado durante décadas, históricamente no estaba disponible en los data lakes. Los lakehouses proporcionan soporte para transacciones ACID para la confiabilidad de los datos, al tiempo que conservan el formato abierto y la estructura de costos del lago.

Delta Lake es el formato de tabla de lakehouse más adoptado. Almacena datos en archivos Parquet en el almacenamiento de objetos en la nube y mantiene un registro de transacciones que registra cada cambio de esquema, inserción, actualización y eliminación. La capacidad de Time Travel (consultable desde SQL) permite a los científicos de datos y auditores leer cualquier instantánea histórica de una tabla. La compactación automática de archivos y los índices de omisión de datos aceleran el rendimiento de las consultas sin necesidad de ajustes manuales. Delta Lake es una tecnología común utilizada en las arquitecturas de lakehouse porque es de código abierto, independiente de la nube y se integra de forma nativa con Apache Spark y motores SQL.

Apache Iceberg y Apache Hudi ofrecen capacidades similares con diferentes ventajas y desventajas de diseño. Iceberg ofrece una evolución de esquema más sólida y particionamiento oculto para cargas de trabajo analíticas complejas. Hudi se especializa en upserts a nivel de registro y patrones de ingesta en streaming. Los tres formatos son cada vez más interoperables a través de estándares abiertos como Apache XTable.

Para 2025, los lakehouses representarán más de la mitad de las cargas de trabajo de analítica empresarial, impulsados por la simplicidad operativa de gestionar una sola plataforma en lugar de sincronizar un lago y un almacén. Para las organizaciones que crean una nueva plataforma de datos, el lakehouse es la opción predeterminada más práctica.

Patrones de integración con bases de datos relacionales y data marts

Comprender dónde se ubican el data lake y el almacén de datos en la nube en relación con otros sistemas aclara cuándo utilizar cada uno.

Las bases de datos relacionales de procesamiento de transacciones en línea (OLTP) — MySQL, PostgreSQL, Oracle — siguen siendo el sistema de registro para las aplicaciones operativas. Están optimizadas para cargas de trabajo transaccionales con un alto volumen de escritura: gestión de pedidos, seguimiento de inventario y autenticación de usuarios. Las cargas de trabajo analíticas no deben ejecutarse directamente en bases de datos OLTP porque la carga de las consultas compite con las transacciones de la aplicación. El patrón estándar consiste en replicar los datos OLTP en el lago o almacén mediante la captura de datos modificados (CDC), una técnica que transmite los cambios a nivel de fila desde la base de datos de origen como eventos sin afectar el rendimiento operativo.

Los data marts son subconjuntos específicos de un almacén de datos o lago más grande, organizados para una función empresarial concreta: finanzas, marketing o cadena de suministro. Proporcionan conjuntos de datos depurados y precombinados que los analistas de negocios pueden consultar sin necesidad de comprender todo el modelo de datos empresarial. Los data marts siguen siendo relevantes en organizaciones donde los diferentes departamentos tienen requisitos de gobernanza divergentes o donde el aislamiento de consultas es necesario para el rendimiento. En una arquitectura de lakehouse, las tablas de la capa Gold cumplen eficazmente la función de data mart sin necesidad de un sistema físico independiente.

ETL (Extract, Transform, Load) es el patrón adecuado para la carga en sistemas de esquema en escritura (schema-on-write): las transformaciones se aplican antes de que los datos entren al almacén, lo que garantiza la conformidad con el esquema de destino. ELT (Extract, Load, Transform) es el patrón adecuado para sistemas de esquema en lectura (schema-on-read): los datos brutos llegan primero al lago y luego las transformaciones se aplican al momento de la consulta o en las etapas de la canalización. La mayoría de las plataformas de datos modernas utilizan ELT para la ingesta en el lago y luego aplican una depuración al estilo ETL para producir tablas de la capa Gold.

Seguridad, gobernanza y cumplimiento

La gobernanza de datos en un lago de datos en la nube requiere una inversión explícita que los sistemas de almacenamiento de datos proporcionan de forma predeterminada.

El control de acceso a nivel de archivo — que evita que usuarios no autorizados lean datos brutos en el almacenamiento de objetos — es el requisito fundamental. Los proveedores de la nube ofrecen políticas de acceso a nivel de bucket y de prefijo, pero los controles detallados a nivel de columna y fila requieren una capa de gobernanza adicional. Unity Catalog, la plataforma de gobernanza unificada de Databricks, ofrece políticas de seguridad a nivel de tabla, columna y fila en tablas de lagos y almacenes de datos desde una única interfaz, utilizando la sintaxis SQL DCL estándar que los administradores de bases de datos ya conocen.

El catálogo de datos y la gestión de metadatos son la segunda capa de gobernanza. Un catálogo realiza un seguimiento de qué tablas existen, cuáles son sus esquemas, quién es su propietario y cómo se produjeron: el linaje de datos desde el origen hasta el consumo. Sin un catálogo, los lagos de datos se convierten en pantanos de datos: repositorios donde los datos se acumulan sin documentación y los ingenieros pasan más tiempo buscando datos que analizándolos. El linaje automatizado — que realiza el seguimiento de la ruta de transformación desde la ingesta en Bronze, pasando por las uniones en Silver, hasta las agregaciones en Gold — es esencial para depurar canalizaciones, validar el cumplimiento y comprender el impacto de los cambios de esquema.

El cifrado es obligatorio para todos los datos en reposo y en tránsito. El almacenamiento de objetos en la nube cifra los datos en reposo de forma predeterminada mediante cifrado en el servidor, y el transporte siempre se cifra a través de TLS. Las organizaciones con requisitos más estrictos gestionan sus propias claves de cifrado mediante claves administradas por el cliente (CMK) a través de servicios de gestión de claves en la nube, lo que garantiza que ni siquiera el proveedor de la nube pueda descifrar los datos sin una autorización explícita.

Marco de decisión de migración y arquitectura

Elegir entre un lago de datos, un almacén de datos en la nube y un data lakehouse requiere hacer coincidir las capacidades arquitectónicas con los requisitos de la carga de trabajo.

Comience con una evaluación de idoneidad de la carga de trabajo. Catalogue sus cargas de trabajo analíticas por consumidor principal (científicos de datos, analistas, usuarios de negocios), tipos de datos requeridos (estructurados, semiestructurados, no estructurados), patrones de consulta (lotes, interactivos, streaming) y requisitos de latencia (segundos, minutos, horas). Las cargas de trabajo dominadas por informes SQL estructurados se asocian con almacenes de datos. Las cargas de trabajo que requieren diversos tipos de datos, entrenamiento de modelos de ML o flexibilidad futura se asocian con lagos. Las cargas de trabajo mixtas se asocian con lakehouses.

Evalúe el costo junto con el rendimiento. Un almacén de datos existente puede funcionar de manera aceptable para las cargas de trabajo actuales, pero calcule el costo total, incluido el almacenamiento de datos brutos que residen en otros lugares, los costos de duplicación de datos y la sobrecarga de ingeniería de mantener las canalizaciones de sincronización. Para la mayoría de las organizaciones que almacenan más de unos pocos terabytes de datos brutos, la ventaja de costo de almacenamiento del lago se acumula significativamente con el tiempo.

Evalúe las habilidades de su equipo con honestidad. Los almacenes de datos en la nube tienen herramientas más accesibles para los equipos de análisis centrados en SQL. Los lagos de datos requieren una mayor inversión en ingeniería para el desarrollo de canalizaciones, la gestión de catálogos y las herramientas de gobernanza. Los lakehouses reducen la brecha, pero aún requieren conocimientos de Spark o un procesamiento distribuido equivalente para cargas de trabajo a gran escala.

Para las organizaciones que migran desde un almacén de datos tradicional, un enfoque por fases es lo más eficaz. En la etapa piloto, identifique una única carga de trabajo de alto valor — un caso de uso de ML específico o un tipo de datos que el almacén existente no gestione bien — y llévela al lago o lakehouse. Mida el costo real, el rendimiento y los resultados de gobernanza en comparación con el sistema existente antes de expandirse. Esto evita el modo de falla común de una migración de tipo "big-bang" que interrumpe el análisis de producción antes de que se valide la nueva arquitectura.

Elegir entre lago de datos, almacén de datos y lakehouse

El marco de decisión se simplifica en tres caminos basados en el tipo de carga de trabajo principal.

Si su carga de trabajo está dominada por el aprendizaje automático, la experimentación de ciencia de datos o el almacenamiento de grandes volúmenes de datos brutos o no estructurados, comience con un lago de datos. La eficiencia de costos y la flexibilidad de formato son ventajas decisivas, y puede agregar una capa de consulta SQL más adelante a medida que maduren las necesidades de generación de informes.

Si su carga de trabajo está dominada por análisis SQL estructurados, paneles de control de alta concurrencia e informes comerciales con requisitos estrictos de latencia, y sus datos ya están estructurados en el origen, un almacén de datos en la nube ofrece el mejor rendimiento por dólar para ese caso de uso específico.

Si su organización ejecuta ambos tipos de cargas de trabajo — o prevé ejecutar ambos en un plazo de 12 a 18 meses —, desarrolle sobre una arquitectura de lakehouse desde el principio. El costo de migrar más adelante una arquitectura madura de dos sistemas a un lakehouse unificado es sustancialmente mayor que construir sobre bases unificadas inicialmente.

En todos los casos, valide las suposiciones con un proyecto piloto antes de comprometerse con una migración completa. Defina métricas de éxito medibles antes de que comience el piloto: latencia de consulta en P95, costo por terabyte al mes, tiempo desde la ingesta de datos brutos hasta los datos listos para el análisis, y la proporción entre el mantenimiento de la canalización y el desarrollo de nuevas funciones. Estas métricas proporcionan una base objetiva para las decisiones de arquitectura que, de otro modo, se convertirían en debates organizacionales.

FAQs y conceptos erróneos comunes

¿Un lago de datos reemplaza a un almacén de datos en la nube en todos los casos?

Un lago de datos no reemplaza a un almacén de datos en la nube en todos los casos. Los lagos de datos destacan en el almacenamiento de datos brutos y multiformato a bajo costo y en el soporte de cargas de trabajo de aprendizaje automático, pero los lagos de datos tradicionales ofrecen un rendimiento de consulta más lento para cargas de trabajo SQL de alta concurrencia que los almacenes de datos diseñados específicamente para ello. Las organizaciones con requisitos maduros de inteligencia empresarial se benefician de un almacén de datos en la nube o de un lakehouse: una arquitectura unificada que proporciona un rendimiento de consulta de nivel de almacén de datos directamente sobre el almacenamiento del lago.

¿En qué se diferencia un lago de datos de una base de datos relacional tradicional?

Un lago de datos almacena datos brutos en su formato nativo en el almacenamiento de objetos sin un esquema predefinido, mientras que una base de datos relacional impone un esquema fijo, almacena datos estructurados en tablas de bases de datos y está optimizada para cargas de trabajo transaccionales: insertar y actualizar registros individuales. Los lagos de datos están diseñados para cargas de trabajo analíticas y de aprendizaje automático a escala de petabytes; las bases de datos relacionales están diseñadas para aplicaciones operativas que requieren transacciones ACID con baja latencia en filas individuales.

¿Cuál es la diferencia entre un lago de datos y un data lakehouse?

Un lago de datos almacena datos brutos en el almacenamiento de objetos sin garantías transaccionales, lo que hace que las escrituras concurrentes y la evolución del esquema sean complejas. Un data lakehouse añade una capa de formato de tabla abierta — como Delta Lake, Apache Iceberg o Apache Hudi — que proporciona soporte para transacciones ACID, aplicación de esquemas y monitoreo de la calidad de los datos directamente en el almacenamiento del lago. Los lakehouses ofrecen tanto la flexibilidad y la eficiencia de costos de un lago como la confiabilidad y el rendimiento de consultas de un almacén de datos sin requerir la duplicación de datos.

¿Cuándo debería utilizar un data mart en lugar de un lago de datos o un almacén de datos?

Utilice un data mart cuando una función empresarial específica — finanzas, marketing, operaciones de ventas — requiera un conjunto de datos depurado y precombinado optimizado para los patrones de consulta de esa función, y cuando sea necesario aislar ese conjunto de datos de la plataforma de datos empresarial más amplia por razones de gobernanza o rendimiento. En una arquitectura de lakehouse, las tablas de la capa Gold cumplen eficazmente la función de data mart, lo que reduce la necesidad de data marts físicos independientes y la complejidad de sincronización asociada.

¿Qué hace que un lago de datos se convierta en un "pantano de datos" y cómo puedo evitarlo?

Un data lake se convierte en un data swamp cuando los datos se acumulan sin una gestión de metadatos adecuada, controles de calidad de datos o gobernanza de acceso, lo que dificulta que los usuarios encuentren, confíen o accedan a los datos que necesitan. La prevención requiere tres controles: un catálogo de datos que documente los esquemas de las tablas, la propiedad y el linaje; controles de calidad de datos aplicados en cada etapa del pipeline (Bronze, Silver, Gold); y controles de acceso que eviten que las escrituras no autorizadas contaminen los conjuntos de datos curados. La arquitectura de medallón garantiza una progresión de calidad que mantiene los datos brutos aislados de las tablas de calidad de producción.

Apéndice: Patrones técnicos y herramientas

Ejemplos de arquitecturas de procesamiento por lotes (batch) y streaming. Un patrón de ingesta por lotes estándar carga diariamente las exportaciones del sistema de origen en el almacenamiento del data lake Bronze, aplica transformaciones de limpieza en Silver y materializa agregados Gold para el consumo de BI. Un patrón de streaming utiliza Apache Kafka o servicios de streaming de eventos en la nube para entregar eventos a Bronze casi en tiempo real, con actualizaciones incrementales en Silver y Gold impulsadas por frameworks de tablas de streaming. Ambos patrones se ejecutan en el mismo almacenamiento de data lake, y Delta Lake se encarga del aislamiento de transacciones entre los dos modos de ingesta.

Herramientas populares por capa. Para la ingesta: Lakeflow, Apache Kafka, servicios CDC nativos de la nube. Para la transformación: Apache Spark (PySpark, Spark SQL), dbt (para equipos centrados en SQL). Para la orquestación: Apache Airflow, servicios de flujo de trabajo nativos de la nube. Para análisis de SQL: Databricks Lakehouse, BigQuery, Snowflake, Amazon Redshift. Para la gobernanza: Unity Catalog, Apache Atlas, servicios de catálogo nativos de la nube. Para ML: MLflow, Apache Spark MLlib, servicios de entrenamiento de modelos nativos de la nube.

Plantillas de diseño de esquemas. Para las tablas de BI de la capa Gold, los esquemas en estrella de estilo Kimball (una tabla de hechos central rodeada de tablas de dimensiones) siguen siendo el estándar para el rendimiento de los dashboards. Las tablas de hechos contienen eventos (transacciones, sesiones, conversiones); las tablas de dimensiones contienen atributos de entidad (cliente, producto, tienda). Para las tablas de características de ML, las tablas desnormalizadas anchas con una fila por entidad y todas las características como columnas minimizan la complejidad de los joins durante el entrenamiento. Para el análisis de streaming, las tablas de eventos de solo anexar (append-only) con particionado por timestamp del evento permiten escaneos eficientes por rango de tiempo para dashboards en tiempo real.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original