La arquitectura de datos define cómo una organización obtiene, organiza, transforma, protege y distribuye sus datos para utilizarlos en aplicaciones, análisis y decisiones de negocio. Relaciona fuentes, modelos, flujos, sistemas y reglas de acceso en un diseño que permite entender cómo funciona la información y cómo debe evolucionar.
Una arquitectura útil permite responder preguntas concretas: de dónde procede un indicador, cuánto tarda en actualizarse, quién puede consultarlo, qué ocurre si falla una carga y qué esfuerzo requiere incorporar una nueva necesidad. Su calidad se comprueba en esas condiciones de uso, además de en su representación técnica.
Esta guía desarrolla los componentes esenciales, las diferencias entre warehouse, lake y lakehouse, el papel de Medallion, data mesh y data fabric, y los criterios para elegir plataformas y modernizar un entorno existente.
Contenido de la guía
- ¿Qué resuelve la arquitectura de datos?
- Componentes y recorrido de la información
- Data warehouse, data mart, data lake y lakehouse
- Arquitectura Medallion y capas de preparación
- Data mesh, data fabric y datos como producto
- Cloud, migración y soberanía
- ¿Cómo elegir una plataforma de datos?
- Rendimiento SQL y operación
- Cómo diseñar y modernizar la arquitectura
- Arquitectura de datos preparada para IA
- Ejemplo de diseño y criterios de aceptación
- Preguntas frecuentes
- Recursos descargables y lecturas de contexto
¿Qué resuelve la arquitectura de datos?
La arquitectura establece cómo se conectan las necesidades del negocio con las capacidades que hacen utilizables los datos. Su alcance incluye decisiones lógicas, como definir entidades y relaciones, y decisiones físicas, como distribuir almacenamiento y procesamiento.
Por ejemplo, un grupo empresarial puede necesitar comparar ventas entre países. El diseño debe resolver cómo recibe los datos de cada sistema, cómo reconoce productos equivalentes, qué moneda utiliza para comparar y cómo mantiene el histórico cuando cambian las clasificaciones comerciales.
La definición de arquitectura de datos de IBM sitúa el recorrido desde la recopilación hasta el consumo dentro de ese marco. Para aplicarlo a una empresa, conviene distinguir tres decisiones:
- Estrategia: qué resultados se quieren conseguir y qué iniciativas tienen prioridad.
- Arquitectura: cómo organizar las capacidades, los datos y sus conexiones para conseguirlos.
- Implementación: cómo configurar, desarrollar y operar la solución elegida.
Si las prioridades todavía no están claras, conviene definir la estrategia de datos y su hoja de ruta. La arquitectura necesita esos criterios para valorar qué complejidad, disponibilidad y coste tienen sentido.
¿Qué significa que una arquitectura sea flexible?
La flexibilidad consiste en poder incorporar cambios sin rehacer innecesariamente todo el sistema. Requiere límites claros entre componentes, definiciones comprensibles y mecanismos para gestionar dependencias. Añadir más herramientas no garantiza esa capacidad.
Una señal práctica es saber qué consumidores se verían afectados si cambia un campo de origen. Otra es poder añadir una fuente sin duplicar en cada informe la misma lógica de transformación. Los beneficios de una arquitectura de datos moderna en la nube deben evaluarse con ejemplos de ese tipo y con sus costes de operación.
Componentes y recorrido de la información
El recorrido habitual va desde las fuentes hasta las aplicaciones y personas que utilizan la información. Puede combinar distintos caminos según la latencia, el volumen y las reglas de cada uso.
- Fuentes. Sistemas operativos, archivos, aplicaciones, documentos o eventos que producen los datos.
- Ingesta e integración. Mecanismos para recibir información, registrar cambios y coordinar los flujos.
- Almacenamiento. Entornos donde conservar datos, históricos y versiones según su finalidad.
- Preparación y modelado. Validación, transformación y organización de la información para usos concretos.
- Acceso y consumo. Consultas, modelos semánticos, informes, APIs y aplicaciones analíticas o de IA.
- Operación y control. Seguimiento de calidad, seguridad, trazabilidad, costes e incidencias en todo el recorrido.
No todos los casos necesitan cada componente como servicio independiente. La guía de Microsoft sobre arquitecturas de big data describe componentes lógicos y distintos tipos de procesamiento. El diseño concreto debe ajustarlos a los requisitos, evitando convertir una arquitectura de referencia en una lista obligatoria de productos.
Procesamiento por lotes y por eventos
El procesamiento por lotes agrupa datos y los trata según una planificación. El procesamiento de eventos atiende cambios conforme llegan, con las condiciones de latencia y entrega que soporte la solución.
La frecuencia debe elegirse según la decisión que se quiere mejorar. Un cierre mensual y una alerta operativa no necesitan la misma actualización. Reducir latencia puede exigir más capacidad, supervisión y tratamiento de errores, incluidos duplicados y eventos que llegan fuera de orden.
También conviene distinguir ETL, que transforma antes de cargar en el destino previsto, de ELT, que carga antes de transformar en ese entorno. Para desarrollar la relación con las cargas transaccionales y analíticas, se puede consultar las diferencias entre ETL, OLAP y OLTP en data warehousing.
Recurso descargable: se incluyen las buenas prácticas para la integración de datos al revisar los flujos que conectan las fuentes con la plataforma.