Un Data Warehouse es un repositorio de datos que se integra por registros de varias fuentes de datos para un procesamiento analítico en línea (OLAP). Permite realizar consultas lógicas, crear modelos predictivos precisos e identificar tendencias dentro de los datos de la organización. Esto quiere decir que el Data Warehouse debe cubrir con los requisitos de todas las etapas de las unidades de negocio existentes en la organización.
El diseño del Data Warehouse es un proceso complejo, largo y propenso a errores. Sumado a que las funciones analíticas unidades de negocio suelen cambiar con el paso del tiempo, lo que se traduce en cambios en los requerimientos del sistema.
El objetivo de un Data Warehouse es la extracción, transformación y carga (ETL) de registros de múltiples fuentes organizadas en un solo lugar.
Esquema de un flujo de Data Warehouse
A continuación se mencionan algunos de los errores más comunes al diseñar un Data Warehouse:
1. Los orígenes de datos no definen el modelado del DWH
El Data Warehouse tiene como principal objetivo resolver preguntas sobre el negocio, por lo cual el modelado de el Data Warehouse debe ser en función a los requerimientos de los usuarios y negocio.
Al modelar el DWH conforme a los sistemas de origen, el resultado podría reflejarse en un Data Warehouse deficiente que no logra resolver de manera optima las consultas del negocio.
2. Recaudación de requisitos
Al diseñar un Data Warehouse el primer paso es la recopilación de requisitos. Donde se deberán de identificar los requisitos para los informes y análisis del usuario, el hardware, desarrollo, testing, implementación y capacitación de los usuarios.
Dentro de este paso el mayor error es no desarrollar un plan de recuperación ante desastres que puedan surgir. El plan se debe considerar dentro de la recaudación de requisitos para que pueda responder rápidamente a las amenazas directas o indirectas al Data Warehouse.
3. Granularidad
Durante el modelado de datos, uno de los errores más comunes es no contemplar el nivel de granularidad.
La granularidad le podrá proporcionar finalidad a las consultas, es decir, el nivel de detalle que se podrá obtener de información.
No obstante, tener la importancia de granularidad representa el detalle al que se desea almacenar la información sobre el negocio al que se está analizando, desde una jerarquía de alto nivel a un nivel más bajo.
4. Diseñar para necesidades especificas
Al diseñar el modelo de datos resulta común que se enfoque en las necesidades específicas de los reportes. Esto genera consecuencias, ya que no permite la adaptabilidad del modelo para requerimientos futuros.
Lo mejor sería identificar entidades genéricas que permitan una mayor adaptabilidad a todo tipo de requerimiento de información y sin la necesidad de adecuar el diseño del DWH.
5. El diseño no depende únicamente del área de TI
El diseño e implementación del Data Warehouse no debe considerarse como un proyecto exclusivo de TI. El área de TI no conoce de todas las áreas de negocio, y eso puede llegar a limitar los alcances. Lo ideal es que el diseño y proceso del DWH se cuantifique; si no en el rendimiento monetario de las inversiones, por lo menos en términos de crecimiento de la organización, el cual se definirá con apoyo de KPI´s.
El crecimiento se puede ver y medir en términos de mayor uso del sistema de BI y un uso eficaz de los datos. Lo que significa una mayor eficacia, fluidez de las operaciones y en los altos mandos.
6. Desorden
Iniciar a modelar sin tener un plan de trabajo establecido, puede generar inconsistencias que demorarán la finalización del DWH.
Se recomienda modelar en iteraciones para asegurar que cada parte o sub parte se encuentren desarrollados en su totalidad y de manera correcta. Para que de esta forma el resultado obtenido no cuente con errores de calidad o estructura.
7. Mentalidad de cascada
Es común pensar que el flujo de trabajo de un proyecto es en cascada, lo que significa que solo hasta que se termine con una tarea se puede iniciar la siguiente. En el diseño de DWH esto no es posible, ya que normalmente se requiere que el diseño de los datos sea trabajando mientras se desarrollan y son adaptados a los modelos de datos.
Contar con una lista de tareas específica para cada uno de los integrantes del equipo generará que el proyecto sea más rápido de desarrollar.
8. Cerrarse a las funciones predeterminadas
Si bien es importante contar con las funciones de los usuarios ya establecidas, también es relevante considerar nuevos usuario y accesos.
Al requerir tener accesos a los datos y para evitar caer en desordenamiento de las funciones ya establecidas, se recomienda la implementación de un gobierno de datos para definir responsables y roles para los procesos relacionados al manejo de datos.
9. Ignorar la calidad de los datos
Todos los datos deben ser precisos y limpios. De no ser así, es muy probable que en la salida se muestren discrepancias, culpando al diseño y proceso del Data Warehouse.
El control de la calidad de los datos también se gobierna durante el uso. La empresa puede señalar los errores que se presenten, para que el diseño del Data Warehouse promueva procesos sólidos de gobierno de datos que mantengan los datos limpios.
10. Implementar el DWH con datos innecesarios
Identificar lo que será útil es una de las grandes dificultades del diseño. Integrar datos innecesarios u ambiguos tiene consecuencias tecnológicas importantes, especialmente en cuanto a los volúmenes de datos. Debido al volumen se pueden presentar discrepancias, reflejado en la información que se muestra y en el tiempo de respuesta en la extracción.
La calidad de los datos debe ser una prioridad. Las prácticas sólidas de gobierno de datos garantizan que los datos se mantengan limpios, promoviendo el cumplimiento de las reglas y regulaciones.
11. Descuido al crear la capa de metadatos
Un mal diseño de los metadatos podría implicar desorden y poco entendimiento por parte de los usuarios.
Los metadatos son la conexión entre los modelos de datos, el ETL y el BI. Frecuentemente la capa de metadatos solo es utilizada para ajustarse a documentación desordenada y datos con poca utilidad a futuro.
A las tablas y/o columnas es necesario agregar comentarios o descripciones. Cuando los usuarios llegan a rechazar informes de BI por información que no se logra descifrar, el problema se concentra en los modelos de datos, los cuales carecen de descripciones sencillas de comprender, además de una nomenclatura incoherente.
Esto se puede evitar manteniendo una estrategia de metadatos única en la etapa de modelado de datos.
12. No actualizar las capas dependientes del DWH
La actualización del Data Warehouse y el cubo OLAP es de suma importancia para un buen rendimiento del sistema.
Una vez se actualice el Data Warehouse, queda poco tiempo para realizar la actualización del cubo OLAP, dado que si no se hace se podrían marcar errores y el rendimiento del sistema disminuiría.
Dedicar un tiempo para evaluar la ruta de generación de cubos OLAP más eficaz puede reducir o prevenir problemas de rendimiento después de que el Data Warehouse entre en funcionamiento.
12. No actualizar la información
Al tratar con información almacenada en un Data Warehouse es de gran importancia que los reportes, dashboards y/o contenido dependiente se mantenga actualizado de forma periódica. Al no actualizar los datos, la información reflejada podría ser obsoleta o imprecisa.
13. El tamaño del Data Warehouse no define el éxito del proyecto
Se definirá como un proyecto exitoso, cuando el Data Warehouse funcione de manera eficiente. Se debe otorgar a los usuarios una toma de decisiones con resultados satisfactorios.
Buscar realizar un proyecto con tecnología capaz de procesar grandes cantidades de datos en poco tiempo es algo común, pero en realidad cuanto más pequeño el almacén, es mejor.
Un Data Warehouse pequeño suele brindar beneficios como:
- Menor costo.
- Escalamiento más sencillo.
- Mejor navegación.
- Funcionamiento más práctico.
En un inicio el diseño del Data Warehouse debe satisfacer las necesidades actuales de la empresa. Y conforme se vaya requiriendo, ir agregando los datos adicionales.
14. No tomar importancia a la transformación de datos
Los datos procedentes de distintas fuentes, por lo regular deben limpiarse y normalizarse para que puedan tener sentido y concuerden entre ellos.
Algunos ejemplos sobre las deficiencia o fallas entre los datos de distintas fuentes son:
- Diferencia de zona horaria.
- Puede no existir una relación clave entre las fuentes de datos.
- Los valores de búsqueda no se encuentran normalizados o estandarización (US = Estados Unidos = USA).
Al ignorar este paso en el diseño del Data Warehouse, los datos serán complicados de trabajar, presentarán incoherencias y los responsables de la toma de decisiones perderán la confianza en su fiabilidad.
15. Terminar el DWH no es el final
El Data Warehouse tiene dentro de sus objetivos proporcionar a la empresa una toma de decisiones efectiva. El ciclo de vida del DWH está totalmente relacionado con las evoluciones de la empresa y del mercado.
Acciones como nuevos usuarios, accesos, nuevas áreas o ramas requieren de constantes regulaciones y/o optimizaciones por lo que se deberá de contar con un mantenimiento u optimización periódica para evitar errores en un futuro.
16. Falta de etapa de pruebas
Omitir la etapa de pruebas puede provocar retrasos en la implementación o finalización del Data Warehouse.
Se deber iniciar la etapa de pruebas o garantía de calidad una vez que el sistema se ha desarrollado con los requisitos solicitados, esto generará que el equipo exponga y resuelva los errores que se muestren antes del lanzamiento.
El Data Warehouse es propenso a errores al ser un proceso extenso y complejo.
Al diseñar, se debe tener en cuenta distintos factores que disminuirán el nivel de errores, como lo es diseñar pensando en el futuro de la organización, contar con el equipo adecuado (BI, TI y responsables de las áreas con datos involucrados), protección de la capa de metadatos y priorizar las funciones prácticas antes que lo estético.
De este modo y tomando en cuenta los principales errores mencionados anteriormente, se puede diseñar un Data Waterhouse con mayor probabilidad de éxito.
Otros temas de interés:
2 comentarios en “Errores al diseñar un Data Warehouse”