Rendimiento

Hoy vamos a viajar al pasado para recuperar un artículo de Ralph Kimball escrito en 2001 pero que aún, 23 años después, sigue estando muy presente. El artículo recoge los 12 errores más comunes (y más perjudiciales) que se cometen a la hora de diseñar un DataWareHouse (DWH). Si ya tienes experiencia en este tipo de entornos vas a notar que son errores que a menudo podemos cometer pero que necesariamente tenemos que corregir al poco tiempo. En estos entornos no valen las cosas a medias, para un buen rendimiento es necesario hacer las cosas bien desde el principio o la bola crecerá tanto que será ingestionable.

¿Qué es un DWH?

Empecemos por el principio, un almacén de datos, datawarehouse o DWH es un sistema diseñado para almacenar y, posteriormente, analizar datos. No es un sistema cualquiera y tiene sus particularidades ya que en él, vamos a integrar todos los datos de los distintos orígenes de nuestra organización, incluso de orígenes externos. Por ejemplo, en nuestro DWH tendremos los datos de nuestra aplicación de ventas, contabilidad, tienda web y, en ocasiones, incluso la base de datos de artículos de nuestros proveedores.

Los DWH se caracterizan por contener grandes cantidades de información histórica permitiendo a los analistas de datos realizar análisis temporales y crear predicciones de tendencias a futuro. Como podrás imaginar, para que todo esto funcione, tiene que estar todo muy organizado, estructurado y optimizado para el acceso y análisis rápido de la información. Gracias a procesos ETL (extracción, transformación y carga por sus siglas en inglés) vamos a cargar las tablas de dimensiones y de hechos del modelo de estrella de nuestro DWH,

Errores comunes cuando creamos un DWH

Ahora si, después de esta pequeña introducción vamos al lío, estos son los doce errores más comunes definidos por Kimball.

Error 12: Incluir campos de texto en tablas de hechos para filtrar u ordenar

En un modelo dimensional, las tablas de hecho y de dimensiones se diferencian por contener indicadores numéricos y atributos respectivamente. A veces, la clasificación de un dato puede ser ambigua, como la hora de una venta o el nombre del transportista que nos entrega un pedido. En caso de duda, os recomiendo evitar textos largos en las tablas de hecho para optimizar el espacio y el rendimiento, y considerar como dimensión cualquier dato compartido entre varias tablas de hecho. Al fin y al cabo el almacenamiento es barato en precio pero costoso a la hora de leerlo, las tablas de hechos pueden llegar a tener millones de registros y debemos evitar poner en ellas cualquier texto que pueda ser común a varias tablas o registros. Eso será siempre una dimensión.

Error 11: Escatimar en la información de nuestras dimensiones para ahorrar espacio.

La información es poder y aunque en este momento podamos pensar que no necesitamos ciertos datos y que podemos prescindir de ellos siempre es importante guardarlos por si en un futuro los necesitamos. Esa es la idea detrás de las primeras capas bronce de los data lakes pero, llevado al caso que nos ocupa, en nuestro DWH es una buena idea almacenar esa información si se refiere a dimensiones. El tamaño de las tablas de dimensiones con cientos o pocos miles de registros será despreciable al lado de las grandes tablas de hechos con millones de registros por lo que no debemos preocuparnos por ese aspecto. Otra cosa será que saquemos los datos en la capa de presentación si no se nos solicita pero tenerlo siempre será una buena idea.

Error 10: Dividir las jerarquías y en varias dimensiones

Las dimensiones se agrupan en jerarquías que tienen una relación de uno a muchos. En un país existen muchas provincias y en cada una de esas provincias muchas poblaciones. Cada población a su vez tiene muchos clientes. Podemos pensar en que es una buena idea tener las tablas normalizadas como nos enseñaron en la universidad y crear una tabla por cada una de esas dimensiones.

Eso es lo idea para un modelo transaccional pero cuando hablamos de un DWH donde las lecturas priman sobre las escrituras y el almacenamiento, en la última capa de nuestro DWH el modelo debe ser puramente de estrella y no de copo de nieve por lo que en una sola tabla para esa jerarquía. Es importante aquí destacar de esta última frase la referencia a esa última capa que consumen los reportes ya que nuestro DWH tendrá otras capas inferiores donde sí tendremos normalizados los datos.

Error 9: No enfrentar las dimensiones lentamente cambiantes

Ya explicamos en nuestro artículo sobre el modelo de estrella lo que es una dimensión de variación lenta o lentamente cambiante. Es importante que anticipemos estos cambios desde el inicio del diseño de nuestro modelo o en un futuro tendremos problemas. Por ejemplo, no os imagináis el caos que se me montó una vez a mi cuando un NIE de un cliente extranjero cambió a DNI al obtener la nacionalidad y yo no había pensado que ese dato era cambiante. 

Error 8: No crear foreign keys específicas en tu DWH

En ocasiones podemos pensar que un valor intrínseco de nuestras dimensiones puede actuar como clave y cometemos el error de no crear una clave dedicada para esos registros. Sin embargo, a la larga eso puede llegar a ser un problema y para evitarlo es aconsejable crear nuestros propios identificadores numéricos para los registros de nuestras dimensiones y enlazar con ellos las tablas de hechos. Pensad en el ejemplo del error anterior, el NIE o DNI puede parecer un identificador personal válido pero cuando no lo es puede ser un verdadero quebradero de cabeza. 

Error 7: Añadir dimensiones a la tabla de hechos del DWH

Esto puede parecer básico, pero si ya os habéis enfrentado a varios modelos de DWH sabréis que es más común de lo que parece. En un modelo de estrella todas las dimensiones deben estar en sus tablas de dimensiones y las tablas de hechos solo deben tener relación con esas dimensiones o jerarquía. Caer en este error nos llevará a un mayor tamaño de nuestra tabla de hechos lo que repercutirá directamente en el consumo de E/S de nuestras consultas y empeorará el rendimiento.  

Conclusión

Hemos visto la mitad de los errores más comunes descritos por Kimball, como el artículo si no iba a quedar muy grande vamos a dejar los 6 siguientes errores (y los más graves) para una segunda parte. Espero que os esté gustando, que os sea de utilidad y por supuesto que a partir de ahora no caigáis en estos errores. Si al leer esto has pensado en algo que tienes mal en tu DWH solucionalo antes de que sea tarde, vas a ver que, a la larga, la ganancia es sustancial. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!