Archivo de la categoría: Base de Datos

Data Warehousing: Kimball vs Inmon, Data Vault y Virtualización

Dos formas completamente diferentes de enfocar el mismo problema. Dos formas no del todo contrapuestas y ambas válidas. Quizá el enfoque departamental de Kimball es un generador de Silos y es quizá por esto que desde la perspectiva del framework de DAMA se habla mucho más de Inmon y de su CIF (Corporate Information Factory)

En el desarrollo conceptual del data warehousing, se destacan dos figuras prominentes: Ralph Kimball y Bill Inmon (que he tenido la suerte de entrevistar hace unas semanas). Aunque ambas perspectivas comparten objetivos similares, difieren considerablemente en sus enfoques metodológicos, dando lugar a dos filosofías distintas en el diseño de estrategias de datos.

La visión de Kimball se fundamenta en la premisa de que los procesos de negocio deben dictar la arquitectura del datawarehouse. Parte de la premisa de la existencia previa de datos, ya sea en forma de datamarts organizados de manera más o menos estructurada, los cuales sirven como la base para la construcción del datawarehouse futuro.

Que sea rápido… y departamentalizado

Para Kimball, la velocidad en el procesamiento de datos destinados a la toma de decisiones es primordial. Por ende, estructura el datawarehouse conforme a patrones dimensionales, con el objetivo de agilizar las consultas y ofrecer una organización más intuitiva y natural de los datos para los usuarios.

La arquitectura propuesta por Kimball se caracteriza por ser una aproximación «bottom-up», donde se parte de los datos y procesos existentes para modelar el datawarehouse de manera que se adapte a ellos. Esta metodología prioriza la eficiencia temporal y la representación intuitiva de los datos sobre la normalización.

Esencialmente el modelo dimensional de Kimball se apoya en el modelo estrella donde las dimensiones no están normalizadas. Si de un lado su construcción resulta más rápida y sencilla puede generar problemas de redundancia.

El esquema en estrella es capaz de filtrar datos a partir de información denormalizada para satisfacer las necesidades de almacenamiento de datos. Se genera una clave única asociada a cada tabla de hechos para identificar cada fila. Este esquema permite realizar cálculos y agregaciones de manera rápida, como el total de ingresos obtenidos y la cantidad total de artículos vendidos al final de cada mes. Estos detalles pueden filtrarse según sea necesario mediante consultas apropiadas. El esquema en estrella se centra en la medición de eventos que incluyen valores numéricos finitos, que se vinculan a claves externas relacionadas con las tablas de dimensiones. Existen varios tipos de tablas de hechos que contienen valores a nivel atómico. Por ejemplo, la tabla de hechos de transacciones almacena datos sobre eventos específicos, como ventas y días festivos, mientras que los hechos de registro incluyen períodos específicos, como información de cuenta al final del año o cada trimestre. Por otro lado, las tablas dimensionales proporcionan datos detallados sobre los atributos o registros que se encuentran en la tabla central.

Que sea conformado y normalizado y a ser posible por entidades primarias

Por otro lado, el enfoque de su colega Inmon, reconocido como el pionero del concepto de data warehouse, presenta una estrategia «top-down» en la resolución del problema. En este enfoque, el primer paso en el desarrollo del datawarehouse consiste en establecer una estructura de datos en tercera forma normal (3FN), completamente normalizada y depurada. Los datos que ingresan a esta estructura suelen ser depurados previamente en un «área de carga» antes de ser integrados en el datawarehouse normalizado. Esto supone otro proceso ETL.

A partir de esta estructura central, se pueden crear datamarts que organicen de manera más lógica y, si se desea, multidimensional, la información contenida en el datawarehouse principal. Esta metodología, como se puede apreciar, es más organizada pero menos flexible que la anterior, ya que aquí es la estructura y la normalización de los datos lo que dicta el proceso de trabajo en lugar de los procesos de negocio existentes.

El enfoque de Inmon se apoya es encialmente en el esquema copo de nieve donde las dimensiones están normalizadas.

El esquema de copo de nieve requiere poco espacio en disco, lo cual es una ventaja significativa. Este modelo no es relativamente fácil de implementar aunque presenta una estructura modular y a las tablas de dimensiones bien definidas. Las tablas de dimensiones suelen contener al menos dos atributos para definir información en múltiples niveles de granularidad. Sin embargo, debido a la presencia de múltiples tablas de dimensiones y relaciones más complejas, el rendimiento del esquema de copo de nieve tiende a ser inferior en comparación con el esquema en estrella. A pesar de esto, el esquema de copo de nieve ofrece el más alto nivel de integridad de datos y baja redundancia gracias a su enfoque en la normalización de datos.

Donde tiramos…

¿Cuál es la preferible? No se puede afirmar que una sea superior a la otra; simplemente, cada una enfatiza diferentes aspectos en el diseño de un datawarehouse. Kimball representa la orientación hacia el usuario final, la flexibilidad y la rápida disponibilidad de la información. Por otro lado, Inmon destaca por su enfoque en el diseño meticuloso y el cumplimiento de normas que aseguren la precisión, integración y coherencia de los datos.

Con el tiempo, los profesionales del data warehousing han aprendido a combinar ambas tendencias en modelos híbridos que incorporan lo mejor de ambas soluciones. Estos modelos suelen cerrar el ciclo de vida de la información mediante procesos ETL (Extract, Transform, Load) y utilizan estructuras dimensionales para representar la información de manera que facilite su explotación.

Las diferencias entre los enfoques de Inmon y Kimball en el desarrollo de un Data Warehouse son notables y van más allá de simplemente variaciones en la estructura interna y el alcance. Estas diferencias afectan también a la intención y el propósito subyacentes de cada modelo.

El enfoque de Inmon se caracteriza por su orientación «top-down», donde se prioriza la construcción de un almacén de datos altamente normalizado y depurado desde el principio. Este enfoque busca asegurar la precisión y coherencia de los datos, estableciendo una sólida base estructural sobre la cual se pueden desarrollar datamarts y otras estructuras de información.

Por otro lado, el enfoque de Kimball es más «bottom-up», centrándose en la rápida disponibilidad de la información para la toma de decisiones. Kimball aboga por estructuras dimensionales que se adapten a las necesidades específicas de los usuarios finales, lo que permite una mayor flexibilidad y agilidad en la explotación de los datos.

En este debate también se encuentra el concepto de Data Vault, que es una metodología de modelado de datos que se ha vuelto popular en los últimos años. El enfoque de Data Vault se centra en la escalabilidad, la flexibilidad y la trazabilidad de los datos. Utiliza una estructura de modelado específica que consiste en hubs, enlaces y satélites, lo que permite una fácil adaptación a los cambios en los requisitos de negocio y una mayor capacidad para rastrear el historial y la procedencia de los datos.

Dicho esto, afirmar que uno de estos enfoques es «correcto» o «incorrecto» sería demasiado simplista. En lugar de eso, es importante comprender las fortalezas y debilidades de cada enfoque y seleccionar el que mejor se ajuste a las necesidades y objetivos específicos de cada proyecto de Data Warehouse. En muchos casos, la combinación de elementos de diferentes enfoques, como lo hacen los modelos híbridos, puede resultar ser la opción más adecuada para obtener los mejores resultados.

El Data Vault

 

El Data Vault es una metodología de modelado de datos diseñada para proporcionar una estructura flexible y escalable en entornos de data warehousing. Se caracteriza por su enfoque en la gestión de datos históricos, la trazabilidad y la capacidad para adaptarse a cambios en los requisitos empresariales. En un modelo de Data Vault, los datos se organizan en tres tipos principales de componentes:

 

Hubs: Representan entidades de negocio fundamentales y actúan como puntos centrales para conectar datos relacionados. Los hubs contienen claves de negocio y son la base para la integración y la trazabilidad de los datos.

 

Enlaces (Links): Establecen las relaciones entre los hubs y representan las asociaciones entre entidades de negocio. Los enlaces contienen claves foráneas que conectan dos o más hubs, permitiendo el modelado de relaciones complejas entre los datos.

 

Satélites: Almacenan atributos descriptivos adicionales relacionados con los hubs y enlaces. Los satélites contienen información detallada sobre los datos, como metadatos, fechas de validez y cualquier otra información contextual relevante.

 

El diseño en forma de Data Vault facilita la escalabilidad y la flexibilidad al permitir la incorporación de nuevos datos y cambios en los requisitos empresariales sin tener que modificar la estructura básica del modelo. Además, su enfoque en la trazabilidad y la gestión de datos históricos lo hace especialmente adecuado para entornos donde es crucial mantener un registro detallado de la evolución de los datos a lo largo del tiempo.

 

El ETL como cuello de botella

 

Cualquier enfoque queramos utilizar siempre nos toparemos con los problemas derivados de los procesos ETL.

 

Minimizar los procesos ETL (Extracción, Transformación y Carga) en datawarehousing puede ser beneficioso para reducir la complejidad y los costos asociados con la gestión de datos. Aquí hay algunas ideas para lograrlo:

 

Incrementar la integración en la fuente: En lugar de extraer datos de múltiples fuentes y luego transformarlos para la carga en el almacén de datos, se puede trabajar en integrar los datos en la misma fuente. Esto implica implementar estándares de integración de datos en las aplicaciones fuente para garantizar la coherencia y la calidad de los datos antes de que se extraigan.

 

Utilizar estructuras de datos flexibles: Emplear modelos de datos flexibles y dinámicos, como el Data Vault, que permiten agregar nuevas fuentes de datos con facilidad y minimizan la necesidad de transformaciones complejas durante el proceso ETL.

 

Automatizar la limpieza y transformación de datos: Utilizar herramientas de calidad de datos y transformación de datos para automatizar tareas como la limpieza, normalización y enriquecimiento de datos. Esto reduce la dependencia de procesos manuales y acelera el flujo de datos a través del proceso ETL.

 

Implementar cambios incrementales: En lugar de realizar extracciones completas de datos cada vez, implementar estrategias de extracción incremental (delta) o de cambio de datos (CDC) para identificar y cargar sólo los datos que han cambiado desde la última ejecución del proceso ETL. Esto reduce la cantidad de datos que se procesan y carga en cada ciclo de ETL.

 

Optimizar el rendimiento de las consultas: Diseñar modelos de datos eficientes y utilizar técnicas de indexación y particionamiento para optimizar el rendimiento de las consultas en el almacén de datos. Esto puede reducir la necesidad de realizar transformaciones complejas durante el proceso de carga.

 

Utilizar herramientas ETL de alto rendimiento: Emplear herramientas ETL de alto rendimiento y escalables que puedan manejar grandes volúmenes de datos de manera eficiente y procesar transformaciones complejas en paralelo para acelerar el proceso ETL.

 

La virtualización: no mover datos más bien consultarlos…

 

La virtualización de datos es una tecnología que puede desempeñar un papel significativo en la reducción o eliminación de los procesos ETL en data warehousing. Al aprovechar la virtualización de datos, las organizaciones pueden acceder y combinar datos de múltiples fuentes en tiempo real, sin necesidad de replicar o mover físicamente los datos a un almacén centralizado. Esto significa que los datos permanecen en su ubicación original y se integran de manera virtual en una capa de abstracción, lo que elimina la necesidad de realizar extracciones y transformaciones complejas.

 

La virtualización de datos permite a los usuarios acceder a los datos de manera transparente y unificada, independientemente de su ubicación física o formato subyacente. Esto significa que los procesos ETL tradicionales, que implican la extracción de datos de múltiples fuentes, su transformación y carga en un almacén de datos centralizado, pueden ser reemplazados por consultas virtuales que acceden y combinan los datos según sea necesario, en tiempo real.

 

Al eliminar la necesidad de replicar y mover grandes volúmenes de datos, la virtualización de datos reduce significativamente la complejidad y el costo asociado con los procesos ETL. Además, al permitir el acceso en tiempo real a los datos, la virtualización de datos puede mejorar la agilidad y la capacidad de respuesta de las organizaciones ante los cambios en los requisitos de negocio y las fuentes de datos. En resumen, la virtualización de datos ofrece una alternativa eficaz para minimizar o incluso eliminar los procesos ETL en datawarehousing, al tiempo que proporciona una integración de datos ágil y flexible.

 

ETL, CDC, ELT y DELT(TM)

Una de las cosas más fascinante que he encontrado dentro de IRION es sin duda el enfoque Declarativo. Es algo tan sencillo y tan potente. En años de Data Management siempre me he topado con problemáticas de gestión de datos. De procesos de extracción, de manos en la masa de datos, proyectos interminables, lentos, procesos de cargas sin fin, etc. 

 

Este artículo es fruto de mi afán de entender las cosas bien. Quería aclararme bien mi storytelling para la introducción de Irion en el mercado Español. Lo más bonito de mi trabajo es el aprendizaje que cada día los diferentes clientes y proyectos me aportan. Pero vamos con orden ¿que es un enfoque declarativo? Volviendo a mis antiguos apuntes de programación “Los programas se pueden clasificar por el paradigma del lenguaje que se use para producirlos. Los principales paradigmas son: imperativos, declarativos y orientación a objetos.” Sin ir mucho más lejos, SQL es declarativo, lanzar una query quiere decir quiero obtener un resultado concreto no me interesa saber de qué forma lo haces a nivel interno ya que los programas que usan un lenguaje declarativo especifican las propiedades que la salida debe conocer y no especifican cualquier detalle de implementación. El ejemplo más típico es el de la Paella, si voy a comer una a un restaurante simplemente pido “una paella”, no comunicó al camarero que quiero que se vayan sofriendo pollo y conejo con algo de ajo, aceite y romero, para luego poner las verduras, para luego poner el tomate el pimienton, todo ello con el caldo para luego verter el arroz… No somos expertos de cualquier cosa (aunque mi paella debido a los años de vida en Valencia no está nada mal por ser italiano) y cuando no llegamos a algo o no sabemos hacer algo delegamos en trabajo en alguien que sepa hacerlo mejor, más rápido y más bueno (sobre todo si de paella se trata).

 

Pero nosotros nos ocupamos de datos, muchos datos, estructurados, no estructurados en una gran cantidad de fuentes externas, de proveniencia histórica o reciente. Datos que tenemos que Gobernar y tener bien aseados a nivel de calidad. Datos que tenemos que rectificar, reconciliar, mantener historicizados. Datos que tenemos que “documentar” porque es el regulador que nos lo impone y de ellos tenemos que tener una trazabilidad total y el proceso tiene que ser repetible. Hasta ayer, hoy todo esto se nos hacía muy complejo, estos datos tenían que limpiarse, adaptarse, extraerse, copiarse, y por ello existen diferentes enfoques el más histórico y utilizado ha sido el ETL.

 

ETL Extract Transform Load

 

Ya hemos hablado largo y tendido de todas las problemáticas de los procesos ETL en otro artículo. Justo para introducir el tema, ETL son las siglas de Extract-Transform-Load. El término ETL describe el proceso de mover datos y hacer manipulaciones con ellos. Las herramientas ETL suelen tener funciones de conexión a múltiples plataformas de datos y aplican transformaciones a los datos en la memoria. Después, presumiblemente, el resultado se registra en algún lugar. Los algoritmos ETL también pueden escribirse en la mayoría de los lenguajes de programación modernos, pero muchas organizaciones consideran que esta opción es menos preferible debido a la sobrecarga que supone escribir el código desde cero y a la complejidad desconocida del soporte posterior. 

 

Llegó un momento en que nos dimos cuenta de era inutil repetir estos procesos de cargas, y las nuevas tecnologías y los nuevos enfoques nos han brindando el CDC (Change Data Capture)

 

CDC Change Data Capture

 

CDC es uno de los patrones ETL para copiar datos. Se utiliza para auditar cada cambio en un registro: ya sea que cambie alguno de los valores o que se elimine un registro. Antiguamente, este patrón se implementa con herramientas ETL comparando la última copia de los datos con el origen o comprobando la marca de tiempo de actualización del registro de origen. El rendimiento era pésimo y había una enorme posibilidad de perder algunas de las actualizaciones. Las herramientas de CDC han cambiado las cosas drásticamente, utilizan registros de transacciones para rastrear los cambios, por lo que ningún cambio pasa desapercibido, y ni siquiera afecta al rendimiento de la base de datos de origen. Hay dos métodos diferentes para detectar y recoger los cambios: el data el versionado, que evalúa las columnas que identifican las filas que han cambiado (por ejemplo, las columnas last-update- columnas de fecha y hora, columnas de número de versión, columnas de indicador de estado), o mediante lectura de registros que documentan los cambios y permiten replicarlos en sistemas secundarios. El CDC nos brindó muchas mejoras sobre todo en términos prestacionales, herramienta como Qlik ha hecho de CDC un mantra sobre todo cuando su producto ha querido salir del mundo OLAP. Pero… Llegó la nube y lo cambió todo, almacenamiento y cómputo de alta disponibilidad han creado un nuevo escenario. 

 

ELT Cargamos primero…

 

El enfoque ETL fue una vez necesario debido a los altos costos de la computación y el almacenamiento en las instalaciones. Con el rápido crecimiento de los almacenes de datos basados en la nube y la caída en picado de los costos de la computación y el almacenamiento basados en la nube, hay pocas razones para seguir haciendo la transformación antes de la carga en el destino final. De hecho, dar la vuelta a los dos permite a los analistas hacer un mejor trabajo de forma autónoma.

En pocas palabras ahora los analistas pueden cargar los datos antes de transformarlos, no tienen que determinar de antemano exactamente qué conocimientos quieren generar antes de decidir el esquema exacto que necesitan obtener y esta es una gran ventaja.

En su lugar, los datos de la fuente subyacente se replican directamente en un almacén de datos, que comprende una «única fuente de verdad». Los analistas pueden entonces realizar transformaciones en los datos según sea necesario. Los analistas siempre podrán volver a los datos originales y no sufrirán transformaciones que puedan haber comprometido la integridad de los datos. Esto hace que el proceso de inteligencia de negocio sea incomparablemente más flexible y seguro.

 

DELT(™)

 

Delt es una de las tecnologías propietarias de IRION. El motor orquesta y sincroniza el plan de procesamiento y control de datos con algoritmos inteligentes, lo que permite a los profesionales de la gestión de datos -que utilizan la plataforma Irion EDM®- trabajar en un entorno autoadaptativo y basado en metadatos.

Las ventajas principales son:

  • El enfoque declarativo permite al motor DELT™ alcanzar altos niveles de rendimiento al maximizar el paralelismo de las fases de procesamiento.
  • la arquitectura DELT™ está diseñada para trabajar eficazmente con grandes volúmenes de datos mediante motores orientados a conjuntos.
  • El ingeniero de datos se encarga de los aspectos semánticos de las soluciones delegando en la plataforma la gestión automática de las estructuras de datos.
  • la integración de motores con tecnologías heterogéneas, como Query, Script, Rule, R, Python, Masking, Profiling, permite utilizar la herramienta más adecuada para cada situación.

 

Un enfoque declarativo permite concentrarse en lo que se quiere obtener. Esto es lo que importa. 

 

 

 

SADAS desde Italia una alternativa columnar en DBMS con grandes cantidades de Datos

SADAS es un DBMS columnar diseñado específicamente para aplicaciones de almacenamiento de datos: por lo que es optimizado para responder eficientemente a consultas complejas en grandes cantidades de datos (OLAP).

SADAS permite la mejora en el rendimiento OLAP entre 10 y 100 veces en comparación con el tradicional basada en filas DBMS: parte de estos resultados impresionantes provienen del modelo de columna en sí, pero la verdadera diferencia radica en estructuras específicas y los índices de propiedad que acelerar los tiempos de respuesta para las consultas más criticas.

SADAS es capaz de crear y administrar las estructuras descritas anteriormente mediante el análisis de los tipos de consultas realizadas con mayor frecuencia y de forma más dinámica la creación de estructuras adicionales: se deduce que el mismo tipo de solicitud es procesada más rápidamente después de un cierto tiempo de uso (Learn by Usage)

Todas las estructuras creadas por el motor de SADAS se de forma extremamente rápida con la función inteligente de carga.

SADAS no requiere gran potencia de cálculo, incluso cuando se enfrentan a complejos análisis sobre grandes cantidades de datos.

Que es un DBMS Columnar

Un DBMS orientado a columnas es un sistema de gestión de bases de datos (DBMS) que almacena el contenido de la columna en lugar de la fila. Esto tiene ventajas para los almacenes de datos y catálogos de la librerías donde los agregados se calculan sobre un gran número de elementos de datos similares. Podemos decir que SADAS se puede caracterizar por otro proyecto más del mundo denominado “NoSQL”. NoSQL es un término usado en informática para agrupar una serie de almacenes de datos no relacionales que no proporcionan garantías ACID. Normalmente no tienen esquemas fijos de tablas ni sentencias «join».

Es posible obtener algunos beneficios de la organización orientada a columnas y orientación de fila con cualquier base de datos. Nos referimos tanto a la facilidad de expresión de una estructura orientada a columnas y el foco en la optimización de las cargas de trabajo orientada a columnas. Este enfoque contrasta con la “row-oriented” o la “row store databases”  y bases de datos de correlación, que utilizan una estructura de almacenamiento basada en valores.

Tipología aplicaciones en SADAS

Es sobre todo la Banca a interesarse en esta tecnología lo demuestra Al Rajhi Bank que ha recientemente elegido SADAS para los procedimientos de enmascaramiento de datos.

SADAS trabaja también con Linux junto con las distribuciones más populares (Ubuntu, Suse, Debian, Red Hat, Fedora, etc.), Advanced Systems ha lanzado la versión de SADAS para AIX, el sistema operativo de IBM. AIX es un O.S. basados ​​en los procesadores con arquitectura big-endian, que es la arquitectura que pertenece a la familia de procesadores RISC de IBM. SADAS se ejecuta en AIX manteniendo todas sus características de velocidad: las pruebas se han registrado en algunos casos mejoras en el rendimiento hasta en un 25% en comparación con el sistema operativo Windows.

SADAS es compatible con la Suite de BI TARGIT ya que es posible cargar datos dentro el Servidor Enterprise de la Suite de BI Danesa.

Sobre Advanced Systems

Advanced Systems fue fundada en 1981, y tiene 25 años de experiencia en proveer soluciones para entornos de grandes bases de datos en la industria del software.

La sede Advanced Systems se encuentra en Nápoles, Italia. Su Centro de Investigación está oficialmente autorizada por MIUR (Ministerio de Investigación) y trabaja en estrecha colaboración con las principales universidades italianas en proyectos específicos relacionados con la tecnología de bases de datos.

Los clientes de sistemas avanzados se pueden encontrar en muchos sectores de mercado diferentes, que comparten el problema de la gestión eficiente de grandes cantidades de datos: esto incluye a las compañías telefónicas, los gobiernos, bancos e instituciones financieras.

Para informaciones:

http://www.sadasdb.com

info@sadasdb.com