Una arquitectura de data lake organiza cómo una empresa ingiere, almacena, transforma, gobierna y consume datos estructurados, semiestructurados y no estructurados. Su diseño no debe empezar por elegir una nube: debe partir de los casos de uso, fuentes, niveles de calidad, seguridad y SLA del dato. El objetivo es convertir información dispersa en activos reutilizables para analítica e IA.
At MAIA by Scanda abordamos este problema desde Data Intelligence: integrar múltiples fuentes, gestionar calidad, MDM y gobierno, y habilitar una arquitectura moderna que permita convertir los datos existentes en decisiones confiables. Nuestro documento maestro establece precisamente que Data Intelligence debe entrar cuando existen fuentes inconsistentes que frenan iniciativas de IA o BI.
Definiciones taxonómicas
1. Data lake
Repositorio de datos diseñado para conservar grandes volúmenes de información de diferentes tipos y procedencias, incluidos datos estructurados, semiestructurados y no estructurados. A diferencia de un data warehouse tradicional, puede preservar información en estado cercano al original para transformarla posteriormente según cada caso de uso.
Microsoft identifica los data lakes especialmente con escenarios de analítica exploratoria, ciencia de datos y machine learning, donde conservar información raw y aplicar esquemas durante su procesamiento ofrece flexibilidad frente a modelos exclusivamente estructurados.
2. Pipeline de datos
Conjunto de procesos que transportan información desde los sistemas fuente hasta las capas de almacenamiento y consumo. Puede operar por lotes (batch), eventos, CDC (Change Data Capture) o streaming.
Un pipeline empresarial no debería limitarse a “mover archivos”. Debe incorporar, según el caso:
- trazabilidad del origen;
- validación de esquema;
- controles de calidad;
- tratamiento de errores;
- transformación;
- observabilidad;
- reglas de seguridad;
- manejo de cambios en las fuentes.
3. Catálogo de datos
Capa que registra metadatos técnicos y de negocio para saber qué datos existen, dónde están, de dónde provienen, quién puede utilizarlos y qué significan.
AWS, por ejemplo, incorpora un catálogo centralizado en su arquitectura de referencia para desacoplar productores y consumidores, compartir metadatos y facilitar funciones de gobierno y auditoría.
Tabla comparativa: capas de una arquitectura de data lake
Una implementación puede utilizar diferentes nombres y no está obligada a seguir exactamente tres capas. Sin embargo, separar progresivamente los datos según su nivel de procesamiento y confianza es un patrón ampliamente utilizado. Microsoft describe capas raw, cleansed y curated; Databricks utiliza los términos bronze, silver y gold. Microsoft Learn
| Capa | Estado del dato | Procesamiento principal | Consumidor típico | Riesgo si está mal diseñada |
| Raw / Bronze | Cercano al origen | Ingesta y metadatos mínimos | Ingeniería de datos, auditoría | Perder trazabilidad o impedir reprocesamiento |
| Cleansed / Silver | Validado y estandarizado | Calidad, deduplicación, tipificación, integración | Analistas, data scientists, ingeniería | KPIs contradictorios y modelos alimentados con información inconsistente |
| Curated / Gold | Listo para negocio | Reglas, agregaciones y modelos de consumo | BI, IA, aplicaciones, negocio | Decisiones basadas en métricas ambiguas |
| Catálogo y gobierno | Transversal | Metadatos, linaje, permisos y políticas | TI, datos, seguridad, compliance | Exposición, duplicidad y falta de accountability |
Databricks documenta que Bronze conserva información raw para auditoría y reprocesamiento; Silver realiza limpieza, deduplicación, validación y normalización; y Gold prepara información y agregaciones orientadas al consumo del negocio.
La distinción es importante: las capas representan niveles de confianza y propósito, no simplemente carpetas con nombres distintos.
Cuerpo técnico
H2: Los componentes que debe tener una arquitectura de data lake empresarial
Un data lake productivo necesita más que almacenamiento de objetos. En MAIA by Scanda recomendamos evaluar al menos siete componentes.
1. Fuentes de datos
Primero debe inventariarse qué produce información y con qué características.
Las fuentes pueden incluir:
- ERP y CRM;
- aplicaciones empresariales;
- bases SQL y NoSQL;
- APIs;
- archivos CSV, Excel, JSON y XML;
- documentos;
- dispositivos IoT;
- telemetría;
- sistemas industriales;
- logs;
- imágenes, audio y video;
- fuentes externas.
La pregunta crítica no es únicamente “¿podemos conectarnos?”, sino:
¿Qué decisión de negocio utilizará estos datos y con qué frecuencia necesita recibirlos?
Una fuente que actualiza inventario cada cinco minutos y un histórico financiero mensual no necesitan el mismo patrón de ingesta.
H2: 2. Capa de ingesta
La ingesta transporta los datos desde las fuentes hacia el lake.
Aquí deben tomarse tres decisiones.
Batch vs. streaming
Batch es apropiado cuando el negocio tolera latencia de minutos u horas. Streaming tiene sentido cuando el valor de la información disminuye rápidamente con el tiempo.
No todo necesita tiempo real.
Convertir cada pipeline en streaming “porque podemos hacerlo” puede aumentar infraestructura, operación y monitoreo sin generar retorno adicional.
La decisión correcta se expresa como un SLA del dato:
- ¿Cuánto puede tardar desde que ocurre el evento hasta que está disponible?
- ¿Qué pierde el negocio si llega 5 minutos, 1 hora o 24 horas después?
- ¿Cuánto cuesta reducir esa latencia?
Ahí aparece el business case.
H2: 3. Almacenamiento y separación por capas
El almacenamiento debe permitir conservar el dato original y transformarlo progresivamente.
Raw / Bronze: conservar antes de transformar
En esta zona deben mantenerse los datos con mínima alteración, acompañados de metadatos como origen, fecha de carga o identificador del proceso.
Esto tiene una razón económica además de técnica: si una transformación cambia, el dato original permite reconstruir las capas posteriores sin volver a extraer toda la información desde los sistemas fuente.
Databricks señala precisamente la capacidad de reconstruir capas posteriores a partir de Bronze como una ventaja del patrón.
Cleansed / Silver: construir confianza reutilizable
Aquí ocurre buena parte del trabajo que determina si el lake terminará siendo un activo o un pantano de datos.
Normalmente incluye:
- eliminación de duplicados;
- tratamiento de nulos;
- estandarización de formatos;
- validación de esquemas;
- homologación de identificadores;
- reglas de calidad;
- resolución de registros tardíos;
- integración entre fuentes;
- enriquecimiento;
- manejo de cambios de esquema.
Databricks ubica explícitamente estas actividades en Silver y recomienda no escribir directamente desde la ingesta a esta capa, precisamente para aislar problemas de esquema y registros corruptos.
Curated / Gold: publicar productos de datos
Gold responde una pregunta diferente:
¿Qué necesita consumir el negocio?
Puede contener:
- ventas por región;
- margen por cliente;
- rotación de inventario;
- comportamiento por tienda × SKU;
- indicadores financieros;
- features para machine learning;
- datasets para agentes de IA;
- modelos dimensionales para BI.
En esta capa, una métrica crítica debe tener definición y responsable. “Ventas”, “cliente activo” o “margen” parecen conceptos obvios… hasta que Finanzas, Comercial y Operaciones llevan tres cifras distintas a la misma junta.
H2: 4. Catálogo, metadatos y linaje
Una arquitectura de datos no está gobernada porque exista un repositorio central.
Debe poder responder:
- ¿Quién es dueño de este dataset?
- ¿De qué sistema proviene?
- ¿Cuándo fue actualizado?
- ¿Qué transformaciones recibió?
- ¿Qué dashboards o modelos dependen de él?
- ¿Contiene información sensible?
- ¿Quién puede consultarlo?
- ¿Qué ocurriría si cambia su esquema?
AWS plantea el catálogo centralizado precisamente como un punto donde consumidores pueden descubrir y acceder a información de diferentes productores, y donde también pueden aplicarse controles de gobierno y auditoría.
Sin catálogo, un data lake almacena datos. Con catálogo, empieza a administrarlos como activos.
H2: 5. Data Quality: medir antes de confiar
La calidad no debe revisarse únicamente al construir el proyecto.
Debe convertirse en un proceso continuo.
Métricas recomendadas
Dependiendo del dataset:
- completitud;
- unicidad;
- exactitud;
- consistencia;
- validez;
- oportunidad o freshness;
- volumen esperado;
- porcentaje de registros rechazados.
Por ejemplo, un pipeline puede técnicamente estar “verde” porque terminó correctamente y, al mismo tiempo, haber recibido 40% menos transacciones que el promedio histórico.
Infraestructura disponible no equivale a información confiable.
En el modelo de MAIA by Scanda, AI Data es un componente transversal del CoE, e incorpora una plataforma gobernada con Data Quality, Data as a Service y capa semántica.
H2: 6. Seguridad y gobierno desde el diseño
Un error frecuente es construir primero el lake y “ponerle seguridad” después.
Debe ocurrir al revés.
La arquitectura debe definir desde el inicio:
- identidad;
- RBAC;
- mínimo privilegio;
- clasificación;
- cifrado en tránsito y reposo;
- segregación de ambientes;
- logs;
- auditoría;
- retención;
- tratamiento de información sensible;
- políticas para datos utilizados por modelos de IA.
Esto cobra todavía más relevancia cuando el data lake alimentará agentes o modelos generativos.
Nuestro principio en MAIA by Scanda es sencillo: la IA no corrige automáticamente un dato mal gobernado; puede amplificar su exposición. Nuestro marco de preparación contempla inventario y clasificación de información sensible, corrección de permisos heredados, fuentes mapeadas e identidades y privilegios validados antes de habilitar nuevos casos de IA.
H2: 7. Capa de consumo: diseñar desde la decisión hacia atrás
El último componente determina buena parte de los anteriores.
Los consumidores pueden ser:
- dashboards;
- data warehouses;
- analítica avanzada;
- aplicaciones;
- APIs;
- científicos de datos;
- modelos predictivos;
- RAG;
- agentes de IA;
- automatizaciones.
AWS incluye analítica, consulta, consumo y Data Science/AI/ML como funciones diferenciadas dentro de una arquitectura moderna de datos.
Por eso recomendamos diseñar desde el resultado hacia el dato, no al revés.
Por ejemplo:
Decisión: reducir inventario inmovilizado
↓
KPI: rotación y días de inventario por SKU
↓
Producto de datos: inventario + ventas + pedidos + catálogo
↓
Transformaciones: homologación SKU/tienda, calidad y reglas de negocio
↓
Fuentes: ERP + POS + e-commerce + WMS.
El data lake deja entonces de ser “infraestructura de TI” y adquiere una relación explícita con capital de trabajo y EBITDA.
H2: Las 6 decisiones de diseño que deben tomarse antes de construir
1. Centralizar todo vs. priorizar dominios
No es necesario migrar cada dato de la organización antes de producir valor.
Conviene empezar por las fuentes necesarias para un caso concreto y ampliar posteriormente.
En MAIA by Scanda trabajamos con una lógica similar: primero demostramos valor y después justificamos una inversión mayor. El documento maestro establece que el business case debe construirse con datos reales del cliente y que el PoV funciona como compuerta antes del escalamiento.
2. ETL vs. ELT
ETL transforma antes de cargar al repositorio destino.
ELT carga primero y aprovecha la capacidad de procesamiento de la plataforma para transformar posteriormente.
En arquitecturas modernas de lake/lakehouse, ELT puede ofrecer mayor flexibilidad porque conserva información raw y permite producir diferentes representaciones posteriores.
No obstante, la elección debe considerar privacidad, volumen, regulación y costo de procesamiento.
3. Schema-on-read vs. schema-on-write
El data lake permite posponer parte del modelado hasta el consumo, pero eso no significa “guardar cualquier cosa sin estructura”.
La arquitectura debe decidir en qué momento se convierte la flexibilidad en un contrato de datos.
Un patrón razonable es:
flexibilidad en Raw → control en Silver → semántica de negocio en Gold.
4. Cloud, híbrido u on-premise
La elección depende de:
- soberanía;
- regulación;
- latencia;
- conectividad;
- volumen;
- costo de transferencia;
- seguridad;
- infraestructura existente.
En nuestro modelo operativo podemos iniciar cloud-first para acelerar el primer resultado y mantener una ruta hacia on-premise cuando soberanía o seguridad lo requieren; el documento maestro contempla mantener información sensible local y exponer únicamente versiones agregadas cuando el caso lo permita.
5. Arquitectura propietaria vs. abierta
Una decisión de largo plazo es cuánto depende la plataforma de servicios exclusivos de un proveedor.
Formatos abiertos, desacoplamiento entre almacenamiento y cómputo y componentes reemplazables pueden reducir lock-in, aunque también pueden aumentar complejidad operativa.
No existe una respuesta universal.
La pregunta ejecutiva es:
¿cuánto costaría mover este dato o workload dentro de tres años?
6. Retener todo vs. administrar el ciclo de vida
“Storage barato” no significa “storage gratis”.
Cada dataset debe tener políticas de:
- retención;
- archivado;
- eliminación;
- frecuencia de acceso;
- tiering;
- replicación;
- respaldo.
Guardar indefinidamente información sin consumidor ni requisito regulatorio convierte el crecimiento del lake en crecimiento del OPEX.
H2: Arquitectura de referencia de un data lake
Una arquitectura conceptual puede visualizarse así:
Sistemas fuente
ERP · CRM · POS · IoT · APIs · archivos · documentos · logs
↓
Ingesta
Batch · CDC · Streaming · APIs
↓
Raw / Bronze
Dato original + metadatos + histórico
↓
Cleansed / Silver
Calidad · deduplicación · estandarización · MDM · integración
↓
Curated / Gold
KPIs · modelos de negocio · features · productos de datos
↓
Consumo
BI · Analytics · ML · GenAI · agentes · aplicaciones · automatización
Y atravesando toda la arquitectura:
Catálogo + linaje + identidad + seguridad + calidad + observabilidad + gobierno.
La arquitectura de referencia importa menos por los nombres de las cajas que por los contratos entre ellas: propietario, esquema, calidad, latencia, seguridad y consumidor.
H2: Cómo saber si el data lake está generando valor
No recomendamos evaluar un data lake por terabytes almacenados.
Eso mide ocupación, no resultado.
En MAIA by Scanda utilizamos métricas más cercanas a la capacidad real de decisión. Nuestro documento maestro propone, entre otras, porcentaje de fuentes integradas al catálogo maestro, tiempo de un dato a una decisión, costo por caso de uso en producción y resultado de negocio atribuido a IA.
Un tablero ejecutivo podría incluir:
| Métrica | Qué revela | Impacto empresarial |
| % de fuentes críticas integradas | Cobertura real | Menos reconciliación manual |
| % de reglas de calidad cumplidas | Confianza | Menor riesgo de decisiones incorrectas |
| Freshness / latencia | Velocidad | Tiempo dato → decisión |
| Incidentes de calidad | Estabilidad | Menos reproceso |
| Costo por pipeline/dominio | Eficiencia | Control del OPEX |
| Tiempo para incorporar una nueva fuente | Escalabilidad | Time-to-value |
| Productos de datos con dueño | Government | Accountability |
| Casos de IA en producción sobre la plataforma | Aprovechamiento | Retorno de la inversión |
Una señal particularmente útil es el número de versiones de una misma cifra. Si cada área continúa llevando su propio Excel y el consejo recibe números diferentes, la organización todavía no tiene una fuente operativa de verdad, aunque técnicamente posea un data lake. Esta misma señal forma parte del tablero de diagnóstico de MAIA.
H2: ¿Qué errores convierten un data lake en un “data swamp”?
Los principales no suelen ser de almacenamiento.
Son de diseño y operación:
- cargar información sin un caso de uso;
- no conservar linaje;
- no asignar propietarios;
- permitir que cada área vuelva a limpiar los mismos datos;
- crear pipelines sin observabilidad;
- duplicar datasets sin contratos;
- mezclar información raw y certificada;
- aplicar permisos únicamente a nivel de infraestructura;
- ignorar el costo de cómputo y transferencia;
- no definir cuándo un dato puede alimentar un modelo de IA.
El patrón de capas intenta evitar precisamente esto: la calidad y estructura deben aumentar progresivamente mientras el dato avanza hacia su consumo.
En otras palabras: el problema no es que el lake crezca; el problema es que crezca más rápido que la capacidad de entenderlo y gobernarlo.
Conclusión Predictiva
Durante los próximos ciclos de modernización, la diferencia no estará simplemente entre empresas que “tienen un data lake” y empresas que no lo tienen. Estará entre organizaciones capaces de convertir datos raw en productos gobernados y reutilizables y aquellas que continúen reconstruyendo integraciones, definiciones y reglas de calidad para cada nuevo proyecto.
La presión aumentará con la IA generativa y los agentes: cada nuevo caso necesitará información identificable, accesible, confiable, gobernada y suficientemente actualizada.
Por eso, en MAIA by Scanda no vemos la arquitectura de datos como un proyecto previo a la IA que se termina y se archiva. La vemos como una capacidad operativa.
Nuestro enfoque de Data Intelligence integra gestión de información, MDM, Data Governance, calidad, integración multi-fuente, analytics, Data as a Service e hiperautomatización. La meta no es acumular datos: es habilitar decisiones confiables y una arquitectura capaz de sostener los siguientes casos de analítica, automatización e IA.
CTA final de MAIA
Tus datos no necesitan otro repositorio. Necesitan una arquitectura que permita decidir.
Si hoy tu organización integra manualmente información de varios sistemas, mantiene diferentes versiones de una misma cifra o quiere implementar IA sin saber si sus datos están preparados, el primer paso no debería ser comprar otra plataforma.
At MAIA by Scanda podemos evaluar tus fuentes, calidad, integración y gobierno para identificar qué arquitectura necesitas y qué caso de uso justifica construirla. Nuestro enfoque parte del resultado de negocio y construye el business case con tus propios datos, antes de escalar la inversión.
Conversemos sobre tu arquitectura de datos y definamos qué necesitas habilitar primero para llevar analítica e IA a producción.
FAQ
1. ¿Necesito tener todos mis datos limpios antes de construir un data lake?
No. Precisamente una arquitectura por capas permite conservar información raw y aplicar calidad progresivamente. Lo importante es identificar qué fuentes necesita primero el caso de negocio, definir reglas de calidad y evitar que información no validada llegue a consumidores que esperan datos certificados.
2. ¿Un data lake reduce costos frente a un data warehouse?
No automáticamente. Puede ofrecer almacenamiento flexible y separar almacenamiento, procesamiento y consumo, pero el TCO depende de ingesta, cómputo, transferencia, retención, herramientas, gobierno y operación. Para un CFO, la comparación correcta no es únicamente costo por TB: debe incluir costo por producto de datos y valor generado por sus casos de uso.
3. ¿Cómo saber si nuestra empresa necesita un data lake?
Es una opción especialmente relevante cuando existen múltiples fuentes y tipos de datos, se necesita conservar histórico detallado o se planean workloads de analítica avanzada, machine learning o IA. Microsoft recomienda este patrón particularmente para analítica exploratoria, data science y ML.
En MAIA by Scanda, una señal comercial clara es encontrar múltiples fuentes inconsistentes que estén frenando BI o IA; ese es precisamente uno de los escenarios de entrada definidos para Data Intelligence.
Español 
English