Ir al contenido principal

Data Vault 2.0 - Arquitectura - Hashing

Una de las introducciones más importantes de data vault 2.0, con respecto a su primera versión, es la el reemplazo de llaves subrogadas auto incrementales para dar paso a llaves hash derivados de llaves de los conceptos de negocio.

En su segunda versión, data vault introduce este tipo de llaves para eliminar la interdependencia de carga de las entidades. Dicho de otra forma, se permite que todas las entidades se carguen de forma paralela, solamente limitado para la cantidad de recursos del que dispones. 

Además remueve algunas complicaciones adcionales:
  • Generar la misma llave ante eventos de re-procesamiento
  • Sincronizar múltiples ambientes
  • Distribuir datos en ambientes massive parallel procesing
  • Compatibilidad con bases de datos NoSQL
  • Comparación de cambios en registros (Hash Diff)
No explicaré como funcionan este tipo de funciones. Aquí puedes lanzarte a la búsqueda para entender md5 o sha1. Se recomienda utilizar algoritmos hash ampliamente conocidos para asegurar que todas las plataformas brindan soporte.

Estas funciones dependen de la representación binaria del texto para generar su representación hexadecimal, por tanto, es necesario establecer de forma explícita lo siguiente (con criterio asegurando que no modifique el sentido semántico):
  • Charset a utf8
  • Trim para remover espacios al inicio y al final del texto
  • Remover caracteres no visibles como saltos de línea
  • Tipos de datos, longitud, escala y precisión. Distintas combinaciones pueden resultar en distintas representaciones en hash por su almacenaje binario
  • Formato de fechas deben estar todas en ISO8601
  • Formato de números sin separador de miles y punto para separar decimales
  • Todo el texto en mayúsculas
  • NULL siempre representarlos un texto vacío
  • Siempre utilizar un pipe como delimitador para concatenar varios textos
  • Mantener el mismo orden en que se presentan en la tabla los distintos atributos

Los hash tienen un riesgo inherente de colisión. Significa que dos representaciones de texto distintos, generan el mismo resultado. La posibilidad de ocurrencia suele ser tan bajo que se ignora por completo, sin embargo, la dinámica para afrontar este problema consiste en:
  1. Concatenar un nuevo texto al final para modificar el resultado
  2. Cambiar el algoritmo que se utiliza md5 -> sha1

El almacenamiento se suele utilizar un char(32) que es compatible con la mayoría de plataformas convirtiendo la representación a caracteres de texto. Sin embargo, es posible para generar mayor eficiencia el almacenar en binary(16) pero se pierde compatibilidad entre plataformas.

Existen algunas ideas sobre no utilizar hash y utilizar las llaves de negocio directamente como identificadores de las entidades, y aún cuando para los hubs es probable que los hash sean más extensos que 32 caracteres, al pasar a los links generalmente será al contrario.

Siguiente: | Indice