ETL y Late Arriving Dimensions

 

Las cargas de datos (ETL, de Extract-Tranformation-Load en inglés), permiten mover datos de un sistema informático a otro. Durante este proceso, es habitual realizar modificaciones tanto en los datos (limpieza, estandarización de formatos, etc.) como en el modelo de datos (paso de un modelo transaccional a uno dimensional).

El diseño e implementación de una ETL es una tarea compleja. Existen una gran cantidad de situaciones a tener en cuenta para que ésta sea robusta y eficiente, y proporcione el resultado deseado.

Una de estas situaciones a tener en cuenta es la de la que se produce al cargar datos en un Data Warehouse, cuando una dimensión no está disponible en el momento de procesar un registro de una tabla de hechos. Es lo que se conoce en inglés como Late Arriving Dimension.

Late Arriving Dimension

La ejecución de una ETL, a grandes rasgos, procesa inicialmente las dimensiones para finalizar con las tablas de hechos. De esta manera, al procesar éstos, disponemos de los registros de las dimensiones referenciados en éstos.

Hasta aquí, perfecto. Sin embargo, ¿qué sucede cuando un escenario no es perfecto?

Una ETL simple obtiene todos los datos de un mismo origen. En este caso, es lógico pensar que dimensiones y hechos pueden ser tratados como una única unidad de información atómica. Por tanto, o bien todos los datos se obtendrán en la fase de extracción, o ninguno de ellos. En este último caso, al producirse un error en la extracción de datos, no tendremos ni dimensiones ni hechos. Y ese caso se solucionará restaurando el acceso al sistema origen de los datos.

Sin embargo, en una ETL que obtenga datos de diferentes orígenes, puede darse la situación en que la extracción de uno de ellos no sea posible, mientras que no haya ningún problema con los otros. En este caso, si no hemos podido obtener una dimensión, es posible que los registros de hechos hagan referencia a registros de dimensión que no hayan sido procesados en el sistema. Por tanto, ese registro de hechos no podrá enlazar a la información correcta.

Diseño complejo

Ante una situación así, debemos plantearnos diferentes soluciones en función del escenario.

La primera cuestión a plantearse es: ¿Es necesario disponer de toda la información para poder cargar los datos?

Si éste es el caso, la ETL debería finalizar con error. El siguiente paso sería solucionar el acceso a los datos. Y finalizaríamos ejecutando la ETL nuevamente para así poder cargar todos los datos en el sistema destino.

En caso contrario, procederíamos a cargar el registro de la tabla de hechos, referenciando un registro de dimensión donde únicamente las claves primaria y natural estuviesen informadas con información real (el resto serían valores por defecto). En el futuro, al cargar el registro de dimensión, modificaríamos ese registro inicial.

Pero habría que tener en cuenta también si esa dimensión requiere cambios en el tiempo (Slowly Changing Dimension Type 2, según la metodología Kimball). En ese caso, el proceso de inserción de una nueva versión de la dimensión no debería producirse inicialmente, ya que esta situación dejaría los registros de hechos referenciando a una versión incompleta de la dimensión.

Otra situación especial ocurre cuando no existe un único origen de datos para la confección de una dimensión. Es decir, a pesar de disponer de un maestro para una dimensión, ésta es enriquecida con datos provenientes de otros sistemas origen. La situación es similar a la anteriormente citada con los registros de hechos, pero no es exactamente la misma.

Conclusión

Una ETL debe ser robusta y tiene que proporcionar información correcta y consistente.

En un mundo ideal, todo funcionará siempre a la perfección. Sin embargo, eso es una utopía. La realidad es que a lo largo del tiempo sucederán situaciones de riesgo que una ETL debe tener controladas.

La mitigación de estas situaciones de riesgo es responsabilidad del arquitecto de la ETL. Un buen diseño debe ser capaz de sobreponerse a situaciones no habituales (que no inesperadas), alineando el comportamiento de la ETL a los requerimientos de ésta.

El caso de las Late Arriving Dimensions es uno de estos riesgos a controlar en una ETL. De ello depende que los usuarios puedan disponer o no de información para tomar sus decisiones en el día a día.

Carga de datos en BI vs. Big Data

 

Uno de los componentes clave de todo sistema analítico es la carga de datos. Durante este proceso, los datos generados en los sistemas origen son cargados en el repositorio de datos analítico para su posterior análisis.

Existen grandes diferencias conceptuales entre como los sistemas de Business Intelligence (BI) y los basados en Big Data cargan los datos en el repositorio analítico. En este artículo veremos estas diferencias para tres tipos de arquitectura:

  • BI tradicional
  • Micro cargas (como componente de un sistema BI basado en una Arquitectura Lambda)
  • Big Data

Factores que afectan a la arquitectura de una solución analítica

La decisión sobre qué arquitectura debe ser utilizada en una solución analítica, depende de las 3 V’s de las que hablamos en este artículo.

Por tanto, el volumen de datos generados en los sistemas origen, la variedad de datos y la latencia máxima para la explotación efectiva por parte de los usuarios, son los factores clave para decidir la arquitectura de una solución analítica y, por tanto, de la carga de datos.

Teniendo en cuenta estas tres variables, obtenemos la siguiente tabla, que nos muestra la arquitectura a utilizar en función de las 3 V’s:

Proceso de los datos: Batch vs. Streaming

La carga de datos puede realizarse, por lo que se refiere a cómo se procesan los datos, de dos maneras diferentes:

  • Batch: Los datos se acumulan en el sistema origen. En el momento de iniciarse la carga, estos datos acumulados se procesan a la vez.
  • Streaming: A medida que los datos son generados por el sistema origen, éstos son enviados para su proceso. El volumen de datos procesados depende de la frecuencia de generación de éstos. Este método de proceso de datos permite detectar patrones en los datos en tiempo real. Un ejemplo es el de la detección de fraude en compras online.

Para las tres arquitecturas anteriores, los tipos de proceso de datos que encontramos son:

ETL vs. ELT

Una carga de datos no es únicamente un movimiento de datos. Ésta suele ir acompañada de una transformación de los datos, ya sea en el modelo de datos (cómo se almacenan), en el valor de éstos (los datos pueden cambiar debido a estandardizaciones de valores, por ejemplo), etc.

Esta transformación requiere del uso de recursos del sistema y de tiempo. El objetivo a la hora de diseñar una carga de datos es que tanto el uso de recursos del sistema como del tiempo no supere el máximo establecido en cada caso.

En el caso de disponer de una ventana de tiempo limitada para la ejecución de una carga de datos, lo lógico es minimizar esas transformaciones, para aligerar el trabajo a realizar durante el proceso de los datos. Esta situación es extensible al escenario en el cual debemos procesar grandes cantidades de datos, ya que podríamos alargar el proceso más allá de la ventana de tiempo disponible.

Existen dos tipos de cargas de datos en función de cuándo se realiza la transformación de los datos:

  • ETL (Extraction – Transformation – Load): La transformación de los datos se realiza antes de la carga en el repositorio de datos. En este caso, al acabar la carga, los datos están disponibles en su estado final, listos para ser explotados por los usuarios finales.
  • ELT (Extraction – Load – Transformation): No existe transformación de datos (o en todo caso es mínima) antes de la carga en el repositorio de datos. Posteriormente, los datos son transformados mediante procesos de refinamiento de éstos. En este caso, los datos precisan de esa transformación posterior para poder ser explotados por los usuarios finales.

Para las tres arquitecturas anteriores, los tipos de carga de datos que encontramos según en qué momento se realiza la transformación de los datos son:

Es decir, en una solución Big Data, la transformación de los datos se realizará una vez cargados los datos en bruto en el repositorio de datos. Esta transformación se llevará a cabo mediante procesos de refinamiento de los datos, que irán añadiendo valor a éstos. Estos procesos pueden ser de calidad de datos, de enriquecimiento, analíticos, etc.

Conclusión

Existen grandes diferencias entre las cargas de datos de los sistemas BI y Big Data.

La carga de datos de un sistema BI (ya sea tradicional o con arquitectura Lambda), procesa los datos en modo batch, mientras que un sistema basado en Big Data puede utilizar cargas batch o basadas en streaming.

Cuando las transformaciones se hacen durante la carga y antes de dejar los datos en las tablas finales del repositorio de datos, se denomina ETL. Este tipo de cargas es el usado en los sistemas BI.

Cuando las transformaciones se realizan posteriormente a la carga de datos en el repositorio, éstas dotan a los datos de calidad, los refinan, los enriquecen y les proporcionan un valor añadido, se denomina ELT. Big Data usa este tipo de cargas.

Elegir el tipo de carga correcto para cada escenario es clave para el éxito de una solución analítica. De ello se deriva poder disponer de los datos para la toma de decisiones de manera efectiva. El hecho de utilizar una carga de datos errónea puede suponer el fracaso del proyecto de creación de una solución analítica.