Data Vault – Hash Keys

BI Geek / Arquitecturas  / Data Vault – Hash Keys

Data Vault – Hash Keys

Como ocurrió con las técnicas del modelado dimensional y normalizado, en las que se ha visto una fuerte evolución desde los primeros papers publicados hasta las últimas concepciones de los mismos, el método Data Vault ha sufrido también su propia evolución desde que Dan Linstedt diese a conocer en el año 2000 sus primeras publicaciones. Entre las novedades que trajo consigo la aparición del Data Vault 2.0, que entró en escena en 2013, como son la incorporación de las tecnologías Big Data en el entorno del Data Warehouse, la convivencia con fuentes NoSQL y la introducción de buenas prácticas, en este artículo nos vamos a centrar en la sustitución de las claves surrogadas (números secuenciales) por códigos hash.

Las primeras preguntas que nos vienen a la cabeza son directas, ¿por qué utilizar códigos hash en lugar de las tan ampliamente usadas claves surrogadas? ¿cuáles son sus ventajas?

  • Los códigos hash identifican de manera única un registro, evitando el uso generalizado de claves surrogadas que estarán repetidas para cada tabla y no tienen vinculación exclusiva con un registro.
  • Se crean en el proceso de carga de la capa de staging, evitando el uso de lookups (mayor requerimiento I/O que la generación de códigos hash) para recuperar claves desde otras estructuras durante los aprovisionamientos del DW.
  • Se estandariza la precisión de las claves en todas las estructuras, facilitando las tareas de diseño y construcción del data warehouse.
  • Uso de “hash diff values”: las comparaciones de registros mediante códigos hash son más rápidas que a través de campos descriptivos. Esto agiliza la carga de satellites y la comprobación de cambios en registros de cara a actualizar vigencias.
  • Evita errores en la asignación de números secuenciales y en las querys sobre dichos secuenciales en entornos particionados y ante posibles problemas de sincronización en tecnologías Big Data.

 

Algunas recomendaciones básicas a la hora de generar los códigos de negocio o hash keys (HK) son las siguientes:

  • Estandarizar el uso de una determinada codificación de caracteres (UTF-8). Distintas codificaciones pueden generar distintos códigos hash para un mismo dato.
  • Convertir los campos a string antes de la generación de la HK para evitar problemas entre sistemas o comparaciones: diferentes tipos de datos, longitudes y precisiones pueden representar un mismo valor, pero se almacenan bajo valores binarios. diferentes, lo que generará distintos códigos hash.
  • Eliminar espacios iniciales y finales en cadenas string.
  • Usar un estándar al convertir las fechas en string para evitar resultados distintos ante un mismo registro. Se recomienda el formato ISO8601.
  • El uso de mayúsculas y minúsculas puede afectar al hash final. Por ello, una buena práctica es convertir todos los string a mayúsculas de manera previa al cálculo del HK.
  • La representación binaria de los valores null puede variar según el sistema o tecnología que lo haya generado. Se recomienda convertirlos en literales vacíos.
  • Uso de separadores a la hora de concatenar campos.
  • Estandarizar el uso de un separador de decimales concreto.
  • En caso de trabajar con caracteres de control se recomienda eliminarlos o convertirlos a vacíos.

Resulta vital establecer todas estas premisas en la fase inicial de diseño del proyecto, de forma que exista un documento básico de consulta al alcance de todo el equipo de trabajo.

Los algoritmos recomendados para el cálculo de los códigos hash son MD5 y SHA-1:

  • MD5 (message-digest algorithm 5): introducido en 1992 reemplazando al MD4, es un algoritmo de reducción criptográfico de 128 bits cuya salida es un valor  de 32 dígitos hexadecimal. Es  ampliamente usado a la hora de comprobar que algún archivo no haya sido modificado.
  • SHA (Secure hash algorithm): Es una familia de algoritmos creada en 1993 por el  Instituto Nacional de Estándares y Tecnología. En 1995 fue publicada una nueva versión, SHA-1, utilizándose como estándar en la generación de códigos hash seguros y reemplazando al MD5 por cuestiones de seguridad.

Un punto a tener en cuenta a la hora de elegir un algoritmo u otro es la problemática conocida como “hash collision” (colisión de códigos hash). Este es un problema real presente en el uso de códigos hash, consistente en el riesgo de que dos registros diferentes generen un código hash común. Las funciones hash comprimen una entrada de datos, teóricamente ilimitada en cuanto a longitud, generando un valor de longitud concreta. Esto puede generar que un mismo valor hash se genere para dos entradas de longitud diferente. Resultan evidentes los problemas que esto puede generar en un data warehouse, por ejemplo que distintos productos tengan una misma clave de cruce.

Entre los principales algoritmos de generación de códigos hash, CRC-32, MD5 y SHA-1, el menos recomendado es el primero por su alta probabilidad de generar códigos similares ante diferentes entradas en función de sus longitudes. El de menor riesgo es el SHA-1, sin embargo, es una función que no está disponible en todas las herramientas utilizadas en entornos Data Warehouse. Es por ello que la función más utilizada es MD5.

No obstante, un caso de colisión podría ser problemático si sucede entre códigos de negocio de una misma tabla hub. Dado que cada hub almacena tipologías de códigos de negocio diferentes (clientes, productos, contratos, etc), para que esto suceda, la volumetría de una misma tabla hub debería ser tan alta que, en palabras de Dan Linstedt, resulta más probable que caiga un meteorito sobre nuestro Data Warehouse a que se sufra un problema de colisión de códigos hash empleando el algoritmo MD5. No obstante, si se tiene la opción de emplear el SHA-1 no hay razones para no hacerlo, más allá de que las necesidades de almacenamiento de los códigos generados por este algoritmo sean superiores a las del MD5 (40 bytes frente a 32 bytes).

Las recomendaciones de Dan Linstedt son comenzar usando el algoritmo MD5 por su bajo riesgo de generar colisión de códigos hash. Aun así, se pueden implementar sistemas de control que detecten posibles ocurrencias de colisión para, en tal caso, sustituir el algoritmo MD5 por el SHA-1.

La siguiente tabla muestra la probabilidad de ocurrencia de una colisión en función del número de registros contenidos en una misma tabla (billón y trillón americano).

Data Vault - Hash Keys (hash-collision)

Las precisiones necesarias para almacenar este tipo de códigos hash son muy superiores a las empleadas con claves surrogadas, basadas en números secuenciales, por lo que, además de requerir mayores necesidades de espacio, ralentizan los cruces entre estructuras. Sin embargo, las ventajas de su uso, como los rendimientos obtenidos en los aprovisionamientos, contrarrestan estas desventajas. En cuanto a qué tipo de dato seleccionar para contener estos códigos, se ha de evitar emplear el varchar. Estos códigos hash se utilizan como claves de cruce, obteniendo mayores rendimientos cuando se emplean campos de longitud fija.

 

A continuación, se expone el papel de los hash keys en los distintos tipos de estructuras del data warehouse:

 

Tablas hub

El código hash de este tipo de tablas, utilizado como clave primaria y campo de cruce con las tablas link y satellites, se generará empleando como entrada el campo que almacena la clave de negocio.

Tablas Links

Estas tablas almacenan la relación entre distintas claves de negocio. Sin embargo, no almacenan las claves de negocio en sí mismas, sino los códigos hash que referencian dichas claves de negocio a sus correspondientes tablas hub. En este sentido, el código hash que identifica cada registro de una tabla link (clave primaria) estará generado utilizando como entrada la concatenación de las claves de negocio referenciadas en cada registro, en lugar de los códigos hash presentes en dichos registros. No se recomienda calcular códigos hash partiendo de otros códigos hash.

La fórmula empleada para el cálculo sería la siguiente:  HashKey = Hash(UpperCase(Trim(BK1) d Trim(BK2) Trim(BKn)))

BK será la clave de negocio y d el separador utilizado para las concatenaciones. En este punto, habrá que tener en cuenta las adecuaciones y estándares definidos previamente, tal y como se ha comentado con anterioridad.

Satellites

Como ya se ha expuesto en el artículo introductorio al Data Vault, las tablas satellites aportan el contexto de las claves de negocio contenidas en las tablas hub y de las relaciones entre claves de negocio contenidas en las tablas link, almacenando los campos cualitativos y cuantitativos que los definen. Es por ello que la clave primaria de las tablas satellites estará compuesta por la hash key que identifica la clave de negocio (en caso de ser un satellite de una tabla hub) o la relación (en caso de ser un satellite de una tabla link) más la fecha de carga “Load Date”. Esto es así porque en estas tablas se almacena el histórico relacionado con claves de negocio y relaciones entre claves.

Es por lo comentado que, en el caso de satellites, la clave primaria no estará formada por una clave hash generada con el contenido del registro que identifica, como en el caso de hubs y links, sino por la clave hash ya generada en dichas tablas. Sin embargo, los satellites pueden contener un campo opcional (recomendado) llamado Hash Diff. Éste será generado con la concatenación de los valores descriptivos de la tabla y la clave de negocio o relación de claves de negocio que contextualiza y su finalidad es la detección de cambios a la hora de aprovisionar el DW. De esta manera, no será necesario comparar cada columna de las tablas satellites con el flujo de datos de la capa de staging para detectar si el registro ha sufrido cambios, sino que solamente se cruzará por este Hash Diff, mejorando considerablemente el rendimiento y los tiempos de carga.

Es importante no olvidar incluir como entrada de la función hash las claves de negocio a las que la tabla satellite se refiere, ya que si solamente tomamos los campos descriptivos contenidos en el satellite podría darse el caso de que diferentes claves de negocio contengan campos descriptivos iguales, lo que generaría dos códigos hash idénticos. En este caso, durante el aprovisionamiento del DW, el segundo registro con Hash Diff idéntico sería descartado por estar presente en la tabla, lo que provocaría que una determinada clave de negocio o relación entre claves de negocio se quede sin conexión a la tabla Satellite.

Nota: Los campos Data Vault (fechas de control, record source, etc) no serán considerados como entrada en la generación de códigos hash.

 

En el próximo artículo de esta serie trataremos el aprovisionamiento de un Data Warehouse Data Vault, donde volveremos a repasar el uso de los códigos hash de las estructuras de este tipo de repositorio de datos.