🗄️ Data Warehouses | Data Engineering Notes #2
Del esquema normalizado al esquema estrella: simplificando consultas analíticas.
Hola, soy Antony Henao, y esta es la segunda entrada de Data Engineering Notes, una serie en la que exploro y comparto los conceptos clave de Data Engineering basándome en mis notas de preparación de clases del bootcamp data engineering.
En el artículo anterior hablamos de la historia de data engineering y sus 5 hitos más revelantes, desde la creación de las bases de datos hasta los Lakehouses.
Hoy vamos a dar un paso más y explorar en detalle los conceptos fundamentales alrededor de los Data Warehouses.
Nota: Este post contiene enlaces afiliados de Amazon. Si compras alguno de los libros a través de ellos, estarás apoyando este proyecto sin costo adicional para ti.
1. ¿Qué diferencia a un Data Warehouse de una base de datos?
Una base de datos tradicional está optimizada para transacciones en tiempo real (Online Transaction Processing—OLTP), enfocándose principalmente en operaciones de escritura frecuentes, como insertar, actualizar y eliminar registros.
Por ejemplo, pensemos en Uber. Cada vez que abres la aplicación y solicitas un servicio, se generan datos que se almacenan, usualmente, en bases de datos OLTP.
Estos datos incluyen el punto de partida, tipo de servicio (confort, XL, etc.), tiempo de espera, información del conductor, entre otros. Bases de datos como MySQL o PostgreSQL son ejemplos típicos para estos casos de uso, almacenando la información en esquemas normalizados y utilizando almacenamiento basado en filas para optimizar operaciones rápidas y transaccionales.
En contraste, un Data Warehouse (DW) está optimizado para el análisis de datos históricos (Online Analytical Processing—OLAP).
Estos sistemas están diseñados principalmente para consultas complejas e intensivas en lectura, tales como agregaciones, reportes históricos o análisis de tendencias. Por ejemplo, un equipo de análisis en Uber podría utilizar un DW para evaluar cuántos viajes hubo en cada ciudad durante el último trimestre, analizar patrones de demanda en distintas horas del día o evaluar el desempeño de campañas promocionales.
Los DWs suelen almacenar la información en esquemas desnormalizados, utilizando almacenamiento columnar. Este tipo de almacenamiento permite consultas analíticas mucho más rápidas y eficientes, especialmente cuando se manejan grandes volúmenes de datos históricos.
En resumen, mientras las bases de datos OLTP priorizan operaciones rápidas y transaccionales, los Data Warehouses están diseñados para facilitar análisis detallados y eficientes de grandes cantidades de datos históricos.
Si quieres saber más acerca de la diferencia de cómo funciona las bases de datos orientadas por filas vs las orientas por columnas, te recomiendo este recurso: Row vs Column Oriented Databases.
2. Normalización vs. Desnormalización
En las bases de datos OLTP es común guardar los datos de forma normalizada.
La normalización es una propuesta surge para solucionar problemas como la redundancia de datos, dificultades en las actualizaciones y mantener la integridad.
Por ejemplo, supongamos que tenemos una tabla de órdenes de productos…
El problema de esta tabla es que se repiten datos innecesariamente, por ejemplo, el nombre y el email del cliente. Esto no es eficiente en bases de datos OLTP. Si quisiera actualizar el e-mail de un cliente, debería hacerlo en múltiples lugares, lo cual genera procesos adicionales e ineficientes para la aplicación.
Lo que propone el proceso de normalización es dividir grandes tablas en varias más pequeñas y relacionadas. De esta forma, la tabla anterior podría dividirse en 3 tablas distintas, permitiendo que una actualización, como cambiar el email de un cliente, se realice en un único lugar.
La normalización es una metodología útil en los procesos OLTP. Sin embargo, en contextos analíticos como un Data Warehouse, la normalización puede complicar el acceso a la información, ya que se requieren múltiples joins entre tablas para obtener los datos necesarios.
En contexto analíticos los cruces de tablas (joins) suelen ser las operaciones costosas dado el volumen de datos y por como funcionan los sistemas distribuidos. Esto es algo que se trata de evitar (o minimizar) a todas costa en los sistemas analíticos.
Por ejemplo, supongamos el siguiente esquema de base de datos…
Obtener información específica como el proveedor de un producto comprado por un cliente podría requerir varios joins, volviendo la consulta lenta y costosa en grandes volúmenes de datos…
Y esto es justo lo que queremos evitar, es por eso que surge el proceso inverso: la desnormalización.
3. Modelado Dimensional (Star Schema)
La desnormalización es el proceso inverso a la normalización.
Si la normalización busca reducir la redundancia de datos y separar los datos en múltiples tablas, la desnormalización promueve cierta redundancia para disminuir el número de tablas y joins necesarios en consultas analíticas.
En los años 90 Ralph Kimball propuso el modelado dimensional o esquema estrella (Star Schema) como una metodología de normalización que consiste en una tabla central llamada Fact Table (tabla de hechos) rodeada por tablas auxiliares denominadas Dimensiones.
Fact Table: Es la tabla principal que almacena métricas resultantes de un proceso de negocio (ej. ventas totales, unidades vendidas).
Dimensiones: Son tablas que describen atributos relacionados con las métricas(productos, clientes, tiendas, fechas).
Siguiendo con el ejemplo anterior, una tabla de hechos luciría de la siguiente manera:
Ahora, los datos más relevantes de una orden se centralizan en la tabla de hechos. Este esquema simplifica drásticamente las consultas, ya que reduce el número de joins necesarios.
Si te interesa aprender más acerda de modelado dimensional, te recomiendo leer al menos los cuatro primeros capítulos de The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling.
4. ¿Hasta dónde desnormalizar?
El arte del modelado dimensional consiste en encontrar el equilibrio adecuado en la desnormalización.
La normalización (3NF) es útil para bases de datos OLTP, pero difícil de consultar en grandes volúmenes.
Kimball (Star Schema) propone un grado intermedio de desnormalización.
Sin embargo, también han surgido otras propuestas como One Big Table (OBT), donde se propone la máxima desnormalización, donde toda la información está en una única tabla.
Cada enfoque tiene sus ventajas y desventajas dependiendo del contexto y las preguntas de negocio que se busque responder….
“Todos los modelos están errados, pero algunos son útiles.” George Box.
5. Proveedores
En términos de proveedores de Data Warehouses, Amazon Redshift fue el primero en alcanzar una adopción masiva en la nube, revolucionando el mercado por su rendimiento y facilidad de escalabilidad.
Posteriormente, Snowflake emergió como una alternativa fuerte, destacando por su arquitectura nativa en la nube y flexibilidad en modelos de precios y desempeño.
Otros proveedores importantes en el mercado incluyen: Google BigQuery y Azure Synapse
Recursos Adicionales
Nota: Los siguientes links contienen enlaces afiliados de Amazon. Si compras alguno de los libros a través de ellos, estarás apoyando este proyecto sin costo adicional para ti.
Próximamente
La próxima semana entraremos más a fondo en Data Lakes y Lakehouses.
Si te interesa seguir esta serie, asegúrate de suscribirte a The LATAM Engineer. Durante la ejecución de mi bootcamp, cada semana compartiré los temas que vayamos discutiendo.
Gracias por leer!
Hasta la próxima,
Antony 🙏.