Tipos de data warehouse: guía completa de arquitecturas y casos de uso

Un almacén de datos (data warehouse) es un repositorio centralizado que recopila, organiza y almacena datos estructurados de toda la organización para que los analistas y científicos de datos puedan realizar consultas complejas, generar informes y dar soporte a las cargas de trabajo de inteligencia de negocios (BI). A diferencia de las bases de datos operacionales diseñadas para el procesamiento de transacciones, un almacén de datos está diseñado para cargas de trabajo analíticas: combinar datos de múltiples fuentes, conservar datos históricos a lo largo de los años y ofrecer la base gobernada que requiere la toma de decisiones estratégicas.

Comprender los diferentes tipos de almacenes de datos es esencial antes de comprometerse con cualquier plataforma o migración. Cada tipo refleja un equilibrio arquitectónico distinto entre escala, latencia, costo y alcance del tema. Esta guía cubre los principales tipos de almacenes de datos, desde los almacenes de datos empresariales (EDW) tradicionales hasta las arquitecturas de lakehouse modernas, y ofrece una orientación clara sobre cuándo elegir cada uno de ellos.

Los tres tipos principales de almacenes de datos

En este campo se reconocen tres tipos principales de almacenes de datos que constituyen la base de la arquitectura de datos moderna: el almacén de datos empresarial (EDW), el data mart y el almacén de datos operacionales (ODS). Más allá de estos, las organizaciones también implementan almacenes de datos en la nube, almacenes de datos virtuales, almacenes de datos híbridos y plataformas de lakehouse, según los requisitos de la carga de trabajo, el volumen de datos y la complejidad de la gobernanza.

Cada tipo difiere en cómo almacena los datos, quién es su propietario, qué latencia admite y qué consultas analíticas gestiona mejor. La elección correcta depende de sus fuentes de datos, la estructura de su equipo, sus requisitos de calidad de datos y los casos de uso analíticos que necesite respaldar.

Almacén de datos empresarial (EDW)

Un almacén de datos empresarial (EDW) es el tipo de almacén de datos más completo, diseñado para servir como la única fuente de verdad autorizada para toda una organización. Un EDW integra datos de todas las unidades de negocio principales (ventas, finanzas, operaciones, recursos humanos, sistemas de gestión de relaciones con el cliente [CRM] y sistemas de gestión de inventario) en un único almacén de datos centralizado, gobernado por estándares de calidad de datos y controles de acceso consistentes.

Arquitectura y alcance

La característica que define a un almacén de datos empresarial es su alcance en toda la organización. Los datos de múltiples fuentes pasan por procesos de extracción, transformación y carga (ETL) antes de llegar al almacén, donde las reglas de negocio, la limpieza de datos y la validación garantizan la consistencia entre los equipos. El resultado es un repositorio gobernado donde cada analista consulta la misma versión de los datos de negocio, independientemente de su departamento.

Los EDW suelen implementar una arquitectura de tres niveles. El nivel inferior gestiona las fuentes de datos y los procesos ETL que ingieren y transforman los datos brutos de los sistemas operacionales. El nivel intermedio alberga un servidor OLAP que hace que los datos sean accesibles para el análisis multidimensional. El nivel superior ofrece herramientas de front-end (paneles e informes de BI) donde los usuarios de negocio analizan los datos. Este diseño por capas separa la complejidad de la ingesta del rendimiento analítico, lo que permite optimizar cada nivel de forma independiente.

Cuándo elegir un EDW

Un EDW es la base adecuada cuando su organización necesita análisis a nivel empresarial, informes de cumplimiento normativo o una única fuente de verdad a través de unidades de negocio que actualmente operan en silos de datos. Las organizaciones con requisitos complejos de gobernanza de datos (como empresas de servicios financieros que gestionan informes regulatorios, organizaciones de atención médica que administran datos de pacientes o grandes fabricantes que integran datos de la cadena de suministro y producción) son las que más se benefician de la gobernanza centralizada que proporciona un EDW.

El principal desafío de los almacenes de datos tradicionales es la escalabilidad. A medida que crece el volumen de datos, los formatos de tabla propietarios y las configuraciones de hardware fijas hacen que las implementaciones de EDW locales sean costosas de escalar. Muchas organizaciones que se enfrentan a esta limitación están migrando a arquitecturas en la nube o de lakehouse que conservan el modelo de gobernanza de un EDW al tiempo que eliminan el límite de la infraestructura.

Data marts

Un data mart es un subconjunto de un almacén de datos específico para un tema, limitado a un solo departamento, función empresarial o dominio analítico. Mientras que un EDW sirve a toda la organización, un data mart sirve a un público específico: el equipo de marketing, el departamento de finanzas o una operación de ventas regional. Los data marts almacenan datos en formatos optimizados para consultas e informes específicos que ejecuta un equipo en particular, utilizando normalmente diseños de esquema en estrella o copo de nieve desnormalizados que minimizan la complejidad de las combinaciones (joins).

Data marts dependientes e independientes

Los data marts se dividen en dos patrones arquitectónicos. Un data mart dependiente extrae datos de un EDW existente, heredando los estándares de gobernanza y calidad de datos del repositorio central. Este es el enfoque recomendado cuando ya existe un EDW, ya que evita definiciones de métricas conflictivas entre departamentos.

Un data mart independiente ingiere datos directamente de los sistemas de origen sin pasar por un EDW. Los marts independientes son más rápidos de crear, pero conllevan riesgos: cada mart puede aplicar reglas de negocio diferentes, lo que genera informes inconsistentes entre las unidades de negocio, precisamente el tipo de silos de datos que la arquitectura de almacén de datos busca eliminar.

Cuándo crear un data mart

Cree un data mart cuando un equipo específico tenga requisitos analíticos que no justifiquen esperar a una implementación completa de EDW, cuando el rendimiento de las consultas en un subconjunto de datos necesite una optimización independiente o cuando la propiedad departamental de los datos sea un requisito de gobernanza. Los data marts funcionan especialmente bien para el análisis de datos de ventas, la atribución de marketing y los informes financieros, casos de uso donde el dominio de datos está bien definido y el público está concentrado.

Almacén de datos operacionales (ODS)

Un almacén de datos operacionales (ODS) es un tipo de almacén de datos diseñado para informes casi en tiempo real y la toma de decisiones operacionales, posicionado entre las bases de datos transaccionales y el EDW analítico. Mientras que un EDW almacena datos históricos acumulados a lo largo de los años, un ODS contiene datos operacionales actuales y recientes (normalmente actualizados a intervalos que van de minutos a horas) optimizados para consultas que reflejan el estado actual del negocio en lugar de las tendencias a largo plazo.

El papel del ODS en la arquitectura de datos

Los sistemas operacionales como las plataformas CRM, los sistemas de gestión de inventario y las plataformas de procesamiento de pedidos generan datos transaccionales de forma continua, pero no están diseñados para consultas analíticas. Ejecutar informes complejos en una base de datos transaccional de producción ralentiza las operaciones que soporta. El ODS resuelve esto replicando los datos operacionales en un entorno separado donde los analistas pueden consultarlos sin afectar a los sistemas de origen.

Un ODS integra datos de múltiples fuentes operacionales, aplica una transformación ligera para estandarizar los formatos y pone a disposición los datos operacionales integrados para la generación de informes. No reemplaza al EDW: el análisis de tendencias históricas y las consultas de planificación estratégica siguen perteneciendo al almacén de datos. El ODS se encarga de cuestiones operacionales urgentes: niveles de inventario actuales, rendimiento de ventas del mismo día, casos activos de soporte al cliente.

Almacén de datos virtual

Un almacén de datos virtual, a veces llamado almacén de datos federado, no consolida físicamente los datos en una única ubicación de almacenamiento. En su lugar, crea una capa de abstracción lógica que consulta los datos in situ a través de múltiples sistemas de origen, presentando esos sistemas dispares como un entorno analítico unificado.

Los almacenes virtuales se basan en la tecnología de federación de consultas para enviar las consultas a los sistemas de origen y agregar los resultados en la capa de presentación. Este enfoque elimina el costo de almacenamiento y de infraestructura ETL de la consolidación física, y proporciona un tiempo de obtención de valor más rápido al analizar los datos que ya existen en las bases de datos operacionales sin tener que moverlos. La limitación principal es el rendimiento de las consultas: las consultas complejas que requieren combinar grandes conjuntos de datos en múltiples sistemas introducen una latencia significativa porque cada consulta debe recuperar datos de sistemas que no están diseñados para cargas de trabajo analíticas.

Los almacenes de datos virtuales funcionan mejor para análisis exploratorios, informes a pequeña escala o situaciones en las que las restricciones regulatorias impiden el movimiento de datos. Rara vez son la arquitectura adecuada para consultas analíticas de gran volumen o cargas de trabajo de IA que requieren procesamiento de datos a gran escala.

Almacenes de datos en la nube

Los almacenes de datos en la nube se alojan en plataformas en la nube (como AWS, Microsoft Azure, Google Cloud y otras) y ofrecen capacidades de almacén de datos como servicios totalmente gestionados. Las organizaciones que ejecutan almacenes de datos en la nube no aprovisionan ni mantienen hardware físico; el proveedor de la nube gestiona la infraestructura mientras la organización se centra en la ingesta, el modelado y el análisis de datos.

Ventajas de la implementación en la nube

La ventaja más significativa de los almacenes de datos en la nube es la escalabilidad elástica. Los almacenes de datos locales tradicionales requieren que las organizaciones dimensionen el hardware para la carga máxima, lo que resulta en un aprovisionamiento excesivo durante las operaciones normales. Los almacenes en la nube escalan automáticamente los recursos de cómputo y almacenamiento según la demanda en un modelo de pago por uso, de modo que las organizaciones pagan por lo que utilizan. La implementación en la nube también acelera el tiempo de obtención de valor: mientras que las implementaciones locales pueden tardar meses desde la adquisición hasta la producción, un almacén de datos en la nube se puede aprovisionar y comenzar a cargar datos en cuestión de horas.

Costos de salida y preparación para la migración

Los data warehouses en la nube presentan ventajas y desventajas que las organizaciones deben evaluar. Las tarifas de salida de datos (cargos por transferir datos fuera de la red de un proveedor de la nube) pueden llegar a ser significativas a gran escala. Las organizaciones que operan con varios proveedores de la nube se enfrentan a una mayor complejidad a la hora de gestionar la integración de datos, las políticas de seguridad y los marcos de gobernanza en diferentes plataformas.

Antes de migrar a un data warehouse en la nube, evalúe el volumen de datos que saldrá de la plataforma, analice los formatos de datos abiertos que reducen la dependencia de un solo proveedor (vendor lock-in) y confirme que las capacidades de gobernanza y seguridad de la plataforma de destino cumplan con sus requisitos de conformidad.

Data warehouses híbridos y modernos

Un data warehouse híbrido combina capacidades de almacenamiento de datos locales (on-premises) y en la nube, lo que permite a las organizaciones mantener los datos confidenciales o regulados en sus propios centros de datos, al tiempo que aprovechan la escalabilidad de la nube para el procesamiento analítico de demanda variable.

Características de un data warehouse moderno

Un data warehouse moderno amplía el modelo de almacenamiento tradicional de varias formas significativas. No solo admite datos estructurados en esquemas predefinidos, sino también datos semiestructurados y no estructurados. Separa el cómputo del almacenamiento, lo que permite que cada uno se escale de forma independiente y reduce el costo del procesamiento de datos a gran escala. Se integra con pipelines de datos en streaming para reducir la latencia, admite formatos de datos abiertos para evitar la dependencia de un solo proveedor y ofrece conexiones nativas para cargas de trabajo de machine learning e IA, junto con las herramientas tradicionales de BI y generación de informes.

Los data warehouses modernos también incorporan capacidades sólidas de linaje de datos, lo que permite realizar un seguimiento de los datos desde sus sistemas de origen, a través de cada paso de transformación, hasta su punto de consumo final. Este linaje es esencial para la gobernanza y el aseguramiento de la calidad de los datos: cuando un analista cuestiona un número en un informe, la documentación del linaje permite al equipo de datos rastrear exactamente cómo se calculó ese número.

Arquitectura de data lake y lakehouse

Un data lake almacena datos brutos en su formato original sin esquemas predefinidos, aceptando datos estructurados, semiestructurados y no estructurados de cualquier origen. A diferencia de un data warehouse, que requiere que los datos pasen por procesos ETL y se ajusten a un esquema definido antes de poder almacenarse y consultarse, un data lake aplica el esquema en la lectura (schema on read): el esquema se aplica en el momento de la consulta, no en la ingesta. Esta flexibilidad hace que los data lakes sean ideales para almacenar grandes volúmenes de datos brutos para la exploración en machine learning y ciencia de datos.

La desventaja es la confiabilidad. Sin la aplicación de controles de calidad de datos que proporcionan los procesos ETL, los data lakes pueden acumular datos inconsistentes, duplicados o mal documentados en los que los analistas no pueden confiar para la generación de informes de BI gobernados.

El lakehouse como solución unificada

Un data lakehouse combina la flexibilidad y la rentabilidad de un data lake con las capacidades de gestión de datos de un data warehouse. Un lakehouse almacena datos en formatos abiertos en el almacenamiento de objetos en la nube, y luego añade una capa de gobernanza y metadatos transaccionales que aplica transacciones ACID, evolución de esquemas, restricciones de calidad de datos y time travel (la capacidad de consultar los datos tal como existían en cualquier punto histórico).

El resultado es una plataforma única donde los ingenieros de datos ejecutan pipelines de ETL, los analistas de datos realizan consultas SQL en tablas gobernadas y los científicos de datos acceden a datos brutos y con ingeniería de características (feature-engineered) para el entrenamiento de modelos, todo sin mover datos entre sistemas. La arquitectura de medallón, común en las implementaciones de lakehouse, organiza los datos en capas de bronce (datos brutos), plata (validados e integrados) y oro (curados y listos para el consumo), mejorando progresivamente la calidad de los datos en cada etapa. La capa de oro se asigna directamente a los data marts y a las capas de servicio de EDW que ya operan los almacenes tradicionales, lo que hace que la transición sea familiar desde el punto de vista de la arquitectura.

Arquitectura y almacenamiento de data warehouses

Independientemente del modelo de implementación, la arquitectura de un data warehouse refleja el mismo principio fundamental: los datos deben separarse de las aplicaciones que los generan, limpiarse e integrarse mediante un proceso gobernado, y almacenarse en formatos optimizados para consultas analíticas en lugar de escrituras transaccionales.

Diseño de almacenamiento y esquemas

Los data warehouses modernos separan el cómputo del almacenamiento, lo que permite que cada dimensión se escale de forma independiente. Los sistemas de almacenamiento guardan los datos en formatos columnares que minimizan los datos escaneados durante las consultas analíticas: una consulta que afecta solo a tres columnas de cincuenta lee únicamente el equivalente a esas tres columnas, en lugar de escanear cada fila en su totalidad.

El diseño del esquema influye significativamente en el rendimiento de las consultas. El esquema en estrella organiza los datos en torno a una tabla de hechos central (que contiene eventos medibles como transacciones de ventas o sesiones web) rodeada de tablas de dimensiones que describen las entidades involucradas (clientes, productos, períodos de tiempo). Las uniones (joins) en un esquema en estrella son simples y rápidas. El esquema en copo de nieve normaliza aún más las tablas de dimensiones, lo que reduce la redundancia de almacenamiento a costa de una mayor complejidad en las uniones. Un esquema en galaxia comparte tablas de dimensiones entre varias tablas de hechos, lo que admite consultas analíticas que abarcan diferentes procesos de negocio.

Los esquemas en estrella son la opción más común para los data marts y la capa de oro de un lakehouse porque priorizan el rendimiento de lectura. El esquema adecuado depende del volumen de datos, los patrones de actualización y la complejidad de las consultas analíticas que el esquema deba admitir.

Tipos de datos en un data warehouse

Históricamente, los data warehouses han almacenado datos estructurados: filas y columnas con tipos de datos y esquemas predefinidos, provenientes de bases de datos relacionales, plataformas CRM, sistemas financieros y sistemas de gestión de inventario. Los datos estructurados son fáciles de consultar con SQL estándar y se integran sin problemas en los pipelines de ETL.

Datos estructurados, semiestructurados y no estructurados

Los datos semiestructurados no se ajustan a un esquema relacional rígido, pero contienen marcadores organizativos que permiten analizarlos: los documentos JSON, los archivos XML, los registros de log y los datos de clickstream entran en esta categoría. Muchas plataformas de data warehouse modernas admiten tipos de datos semiestructurados nativos, lo que permite que las consultas SQL naveguen por estructuras anidadas sin necesidad de aplanar los datos previamente.

Los datos no estructurados (imágenes, videos, documentos de texto libre, grabaciones de audio) no se pueden consultar directamente con SQL, pero son cada vez más importantes a medida que las organizaciones desarrollan capacidades de IA y machine learning. Las arquitecturas de lakehouse difuminan este límite, lo que permite almacenar y gestionar datos no estructurados junto con datos estructurados dentro de la misma plataforma.

La elección entre el esquema en la escritura (schema-on-write, que impone la estructura en la ingesta, como hacen los data warehouses tradicionales) y el esquema en la lectura (schema-on-read, que pospone la estructura hasta el momento de la consulta, como hacen los data lakes) refleja un equilibrio fundamental entre la consistencia de la calidad de los datos y la flexibilidad de la ingesta. La mayoría de las plataformas de datos maduras utilizan el esquema en la escritura para las tablas analíticas gobernadas y el esquema en la lectura para las zonas de datos exploratorios y brutos.

Fuentes de datos externas e integración

Los data warehouses rara vez se nutren de una sola fuente. Las implementaciones empresariales típicas integran datos de bases de datos operativas, sistemas CRM, plataformas ERP, herramientas de automatización de marketing, libros contables financieros, proveedores de datos externos y API externas. Gestionar la diversidad de estas fuentes de datos externas (cada una con su propio esquema, frecuencia de actualización y características de calidad de datos) es uno de los principales desafíos de la arquitectura de un data warehouse.

Antes de que los datos externos ingresen al data warehouse, deben validarse con respecto a los esquemas esperados y las reglas de calidad de datos. La validación detecta a tiempo problemas comunes: campos obligatorios faltantes, valores fuera de los rangos esperados y violaciones de integridad referencial. Detectar estos problemas en la ingesta es mucho menos costoso que descubrirlos después de que los datos se hayan propagado a los informes y paneles (dashboards). El enriquecimiento de datos (aumentar los datos ingeridos con contexto de tablas de referencia o conjuntos de datos externos) transforma los datos de origen brutos en los conjuntos de datos listos para el negocio que los analistas necesitan.

ETL frente a ELT y monitoreo de pipelines

El proceso de integración de datos determina cómo se mueven los datos desde los sistemas de origen hacia el data warehouse y cómo se transforman. ETL (extracción, transformación y carga) es el enfoque tradicional: los datos se extraen de las fuentes, se transforman en un entorno de procesamiento independiente y se cargan en su formato estructurado final. ELT (extracción, carga y transformación) invierte el orden: los datos brutos se cargan primero y luego se transforman dentro del data warehouse utilizando su propia capacidad de procesamiento. Los data warehouses modernos en la nube suelen preferir ELT porque el paso de transformación puede aprovechar las capacidades de procesamiento paralelo del data warehouse a un costo total menor. Para analizar más a fondo las implicaciones arquitectónicas, la comparación entre ELT y ETL aborda las principales ventajas y desventajas.

El monitoreo de los pipelines de datos garantiza que las tareas de ingesta se completen a tiempo, que los volúmenes de datos coincidan con las expectativas y que se superen los controles de calidad antes de que los datos se promuevan a producción. Los pipelines que fallan de forma silenciosa (que se completan sin errores pero producen resultados incorrectos) se encuentran entre los modos de falla más peligrosos en las operaciones de un data warehouse.

Seguridad y gobernanza de datos

La gobernanza y la seguridad de los datos son requisitos fundamentales para cualquier data warehouse, especialmente para las organizaciones que manejan datos confidenciales sujetos al cumplimiento normativo. Un data warehouse que no pueda demostrar quién accedió a qué datos, cuándo y con qué propósito no podrá satisfacer a los auditores ni mantener la confianza de los clientes cuyos datos almacena.

Control de acceso, cifrado y registro de auditoría

La seguridad de datos efectiva comienza con el control de acceso basado en roles (RBAC), que asigna permisos de acceso a datos a roles en lugar de a individuos, lo que hace que la gestión de accesos sea escalable en grandes organizaciones. Los controles de acceso deben operar a múltiples niveles: el nivel de catálogo, el nivel de tabla, el nivel de columna (fundamental para enmascarar información de identificación personal) y el nivel de fila (basado en la afiliación organizativa o la propiedad de los datos).

Los datos deben estar cifrados tanto en reposo como en tránsito. El cifrado en reposo protege contra el acceso no autorizado a los medios de almacenamiento; el cifrado en tránsito protege contra la interceptación a través de las redes. El registro de auditoría registra cada evento de acceso y modificación (quién consultó una tabla, cuándo y qué datos se devolvieron), lo que respalda las investigaciones de seguridad y las demostraciones de cumplimiento normativo. El seguimiento del linaje de datos, que rastrea los datos desde su origen a través de cada transformación hasta su punto de consumo, respalda tanto la gobernanza como el aseguramiento de la calidad de los datos.

Casos de uso de analítica de datos por tipo de almacén

Los diferentes tipos de almacenes de datos se asocian con diferentes cargas de trabajo analíticas, y comprender esta relación ayuda a las organizaciones a evitar el despliegue de una arquitectura optimizada para un tipo de carga de trabajo esperando que funcione en todos los casos de uso.

Asociación de la arquitectura con la carga de trabajo

Los almacenes de datos empresariales admiten la analítica estratégica: análisis de tendencias interanuales, informes multifuncionales, paneles ejecutivos e informes de cumplimiento que requieren la combinación de datos de múltiples dominios comerciales. Los data marts admiten la analítica departamental (rendimiento de ventas, atribución de marketing, informes de cierre financiero y segmentación de clientes), donde el alcance limitado de los datos agiliza el autoservicio. Los almacenes de datos operativos admiten la analítica operativa: monitoreo de las condiciones comerciales actuales y respuesta a eventos en tiempo real en entornos de comercio minorista, logística y servicios financieros.

Las arquitecturas de nube y lakehouse admiten analítica avanzada e AI: entrenamiento de modelos de machine learning a gran escala, canalizaciones de procesamiento de lenguaje natural y sistemas de recomendación. Estas cargas de trabajo requieren no solo datos estructurados gobernados, sino también los datos brutos y semiestructurados que solo una arquitectura de almacenamiento más flexible puede albergar.

BI, informes y analítica avanzada

Las herramientas de BI se conectan a los almacenes de datos para crear paneles e informes accesibles para usuarios comerciales que no escriben SQL. La integración de machine learning requiere que los científicos de datos accedan tanto a datos limpios y gobernados para la ingeniería de características como a datos históricos brutos para el entrenamiento de modelos. Las arquitecturas de lakehouse admiten ambos casos de uso en una sola plataforma, lo que elimina la sobrecarga de ingeniería de datos de mantener copias de datos separadas para las cargas de trabajo de BI y ML.

Elección y migración a una solución de almacén de datos

Seleccionar la solución de almacén de datos adecuada implica evaluar las opciones administradas por el proveedor frente a las autohospedadas, comprender las estructuras de costos y validar que una plataforma pueda admitir sus cargas de trabajo analíticas específicas a escala. Los servicios administrados por el proveedor se encargan de la gestión de la infraestructura, el escalado, el parcheo y la alta disponibilidad a cambio de cierto control operativo. Las opciones autohospedadas brindan a las organizaciones más flexibilidad para requisitos estrictos de residencia de datos o políticas de seguridad complejas, pero requieren que los equipos administren clústeres, coordinen actualizaciones y se encarguen de la planificación de la capacidad.

Evaluación de proveedores y factores de costo

Los costos del almacén de datos se dividen en tres categorías: costos de almacenamiento, costos de cómputo y costos de movimiento de datos. Los almacenes de datos en la nube modernos fijan los precios del almacenamiento y del cómputo por separado, lo que permite que cada uno se escale de forma independiente. Antes de comprometerse con una plataforma para cargas de trabajo de producción críticas, ejecute una prueba de concepto con sus datos y patrones de consulta reales; las pruebas de rendimiento sintéticas rara vez reflejan el rendimiento del mundo real con los volúmenes de datos que maneja.

Migración por fases y optimización de costos

La migración de un almacén de datos heredado a una plataforma moderna se beneficia de un enfoque por fases organizado por dominio comercial. Comience con un dominio que tenga requisitos de datos bien definidos y un propietario comercial motivado. Valide la migración frente a las pruebas de rendimiento de producción antes de proceder al siguiente dominio.

La separación de cómputo y almacenamiento es una de las palancas de optimización de costos más importantes en los almacenes de datos modernos. En las arquitecturas tradicionales, el cómputo y el almacenamiento se escalan juntos. Las arquitecturas de nube modernas desacoplan estas dimensiones, lo que permite a las organizaciones agregar almacenamiento sin aprovisionar cómputo adicional y escalar el cómputo para períodos de picos de consultas sin aumentar permanentemente los costos de almacenamiento. El escalado automático evita tanto el subaprovisionamiento durante los períodos pico como el sobreaprovisionamiento durante los períodos de inactividad.

Comparación de tipos de almacenes de datos

Preguntas frecuentes

¿Cuáles son los principales tipos de almacenes de datos?

Los tres tipos principales de almacenes de datos son el Enterprise Data Warehouse (EDW), el Data Mart y el Operational Data Store (ODS). Más allá de estos tipos principales, las organizaciones también implementan almacenes de datos basados en la nube, almacenes de datos virtuales, almacenes de datos híbridos que combinan almacenamiento local y en la nube, y arquitecturas de lakehouse que unifican la gobernanza del almacén con la flexibilidad del lago de datos. Cada tipo sirve para distintos casos de uso según el alcance de los datos, los requisitos de latencia y las cargas de trabajo analíticas.

¿Cuál es la diferencia entre un almacén de datos y un lago de datos?

Un almacén de datos almacena datos estructurados en esquemas predefinidos y aplica la calidad de los datos a través de procesos ETL antes de que se carguen los datos. Un lago de datos almacena datos brutos en su formato original (estructurados, semiestructurados o no estructurados) sin requerir un esquema predefinido en la ingesta. Los almacenes de datos están optimizados para consultas SQL analíticas complejas e informes de BI; los lagos de datos están optimizados para la flexibilidad y las cargas de trabajo de ciencia de datos y machine learning a gran escala. Un lakehouse combina ambos: almacena datos en formatos abiertos con la flexibilidad de un lago de datos, luego agrega una capa de gobernanza y transaccional con la confiabilidad de un almacén de datos.

¿Cuándo debería una organización utilizar un data mart en lugar de un EDW?

Un data mart es la opción correcta cuando un departamento específico necesita capacidades analíticas más rápido de lo que permite una implementación completa de EDW, cuando el rendimiento de las consultas en un dominio de datos limitado necesita una optimización independiente, o cuando la propiedad de los datos departamentales es un requisito de gobernanza. Los data marts son más efectivos como almacenes dependientes construidos sobre un EDW existente, extrayendo del repositorio central en lugar de realizar la ingesta directamente desde los sistemas de origen. La creación de data marts independientes sin un EDW central corre el riesgo de crear definiciones de métricas inconsistentes y silos de datos entre los equipos.

¿Qué es un Operational Data Store y en qué se diferencia de un almacén de datos?

Un Operational Data Store (ODS) contiene datos operativos actuales y casi actuales actualizados a intervalos que van desde minutos hasta horas, diseñado para informes operativos y toma de decisiones. Un almacén de datos acumula datos históricos a lo largo de los años y está optimizado para el análisis de tendencias, informes estratégicos y consultas multidimensionales complejas. El ODS llena la brecha de latencia entre los sistemas transaccionales operativos y el almacén, que puede actualizarse solo diariamente. Ambos sistemas a menudo se implementan juntos: el ODS respalda la visibilidad operativa del mismo día, mientras que el almacén respalda el análisis estratégico a largo plazo.

¿En qué se diferencian los almacenes de datos en la nube de los almacenes de datos locales?

Los almacenes de datos en la nube se hospedan en plataformas en la nube y ofrecen escalabilidad elástica, precios de pago por uso y una menor sobrecarga de gestión de infraestructura en comparación con las implementaciones locales. Los almacenes de datos locales tradicionales deben dimensionarse para la capacidad máxima, lo que a menudo resulta en un sobreaprovisionamiento significativo durante las operaciones normales. Los almacenes en la nube se escalan automáticamente y se pueden aprovisionar en horas. Las desventajas incluyen los costos de salida de datos a volúmenes altos, la dependencia de la disponibilidad de un proveedor de la nube y la complejidad de la gobernanza para las organizaciones que operan en múltiples plataformas en la nube.

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