16.2. Definición Area Stage. Tecnicas ETL.

Area de Stage.

Como ya indicamos anteriormente, vamos a disponer de un area de Stage para la orquestación de los procesos de carga de nuestro DW. Esta area es un espacio orientado a almacenar la información proveniente de nuestro sistema operacional o de otras fuentes, con una vida temporal o no, que será el punto de partida de los procesos de depuración, transformación y carga en el DW. El enfoque va a ser el siguiente:

• Carga de datos de dimensiones: tendremos unas tablas persistentes en el area de stage. Cuando realizamos la carga de las dimensiones, se extrae la información de los origenes de datos y se deposita sin realizar niguna transformación en las tablas de stage. A partir de ahí se lanzaran los procesos que llenaran el DW, pero ya trabajando siempre en local. De esta forma, siempre nos vamos a guardar un histórico o foto de los datos tal y como nos los trajimos. Incluso se podrían preparar procesos de carga que reprocesasen una de las fotos de las dimensiones (o volver a lanzar el proceso de carga sin volver a acceder al sistema operacional, en el caso de que se haya producido cualquier problema). Cada lote de registros de las dimensiones traidos tendrá una clave única, además de la fecha y hora de extracción. Esta información nos puede ser util para los procesos de debug que tengamos que realizar en el caso de comportamientos inesperados o erroneos.

Esquema Area Stage

• Carga de datos de hechos: el origen de los hechos de venta está en los pedidos de nuestro sistema operacional. Para agilizar el proceso, vamos a replicar la información de las tablas implicadas en el area de Stage. Pero borraremos en cada procesamiento todo el contenido referente a pedidos, pues no es una información de la que nos interese tener ningún registro. Por tanto, en este caso estaremos trabajando con un area de stage temporal.

El area de Stage la vamos a tener en una base de datos paralela, utilizando Mysql. Este enfoque es solo un ejemplo de como podemos orquestar los procesos y que alternativas podemos plantear para cada casuistica. Por ejemplo, puede ser que tengamos muy poca ventana de tiempo para extraer los datos y nos interese realizar una extracción masiva sin procesamiento para luego continuar con el resto de procesos desvinculados del sistema origen. También puede ser que la extracción de datos se haga a través de ficheros Dump, que transportaremos hasta el sistema ETL y preferamos cargarlos en un lugar temporal antes de procesarlos. Como veis, habrá muchas cosas a tener en cuenta antes de decidir los pasos a seguir y como montar el sistema (ventana de tiempo, volumenes de información, tipo de extracción del sistema origen, etc).

Algunas técnicas ETL.

El termino ETL es solo una categorización muy amplia de las actividades de integración de datos. Para cada uno de los procesos principales, podemos identificar varias actividades (cada una con sus correspondientes técnicas).

Para la extracción de datos, podemos indicar:

• Captura de cambios en los datos: comprende las tareas de identificar los cambios en los datos de los sistemas origen. En muchos casos, la extracción de datos se limita a la porción de datos que ha cambio desde la última extracción, aunque en otras ocasiones incluira la extracción de toda la información de un periodo(los pedidos de una semana o el inventario a una fecha). El proceso de identificar los datos que han cambiado se suele llamar CDC (Change Date Capture). Las tecnicas a utilizar pueden ser analizar los registros de cambios de los datos (como en Sap, que tiene implementado en muchos sitios un historial de modificaciones de los datos), o trabajando con claves secuenciales.
• Data Staging: no siempre es efectivo o posible procesar inmediatamente los datos extraidos. A menudo, es aconsejable almacenarlos temporalmente antes de las transformaciones (como vamos a hacer nosotros en nuestro ejemplo con la creación del area de stage). Podemos pensar en el caso de que un sistema operacional en el que no esta permitido por temas de rendimientos y disponibilidad el lanzamiento de procesos contra la base de datos. En ese caso, extraeremos los datos de la forma mas eficaz y rapida posible sin procesamiento y la cargaremos en el area de stage, que nos servira como un buffer intermedio entre el sistema operacional y nuestro DW.

Para la transformación, podriamos enumerar:

• Validación de datos: verificación de la corrección de los datos y filtrado de los datos erroneos. Aunque estemos trabajando con aplicaciones que validan los datos y los ficheros maestros, no podemos asegurar que la información sea correcta. Por tanto sera necesario realizar este proceso (utilizando el data profiling que vimos anteriormente, por ejemplo). Esto seguramente permita arreglar errores y partir de unos datos limpios.
• Limpieza de datos: correción de los datos incorrectos o incompletos. Los datos incorrectos podrían ser rechazados, aunque puede resultar mas útil etiquetarlos de una forma determinada para luego sean mas faciles de identificar y de corregir.
• Decodificación y renombrado: conversión de la información de los códigos de los sistemas operacionales a otros mas descriptivos, fáciles de usar o recordar. Podemos incluir aquí la normalización de la información que puede tener diferentes construcciones según el sistema origen.
• Agregación: en ocasiones, la agregación de la información  para estar disponible en los sistemas de análisis se elabora como parte de los procesos de transformación.
• Generación claves y gestión: los registros nuevos o modificados en las dimensiones requieren una gestión de claves, que han de ser generadas y gestionadas. Ademas esas nuevas claves que identifican los registros tendrán que ser tenidas en cuenta en las tablas de hechos.

Pueden existir otros muchisimas tareas asociadas a la transformación de datos, siendo las vistas las mas habituales.

En el proceso de carga, hay dos actividades principales:

• Carga y mantenimiento de dimensiones: las dimensiones no suelen ser estaticas (excepto la dimensión tiempo), y por tanto hay que gestionar todos los procesos de actualización y mantenimiento de los datos dentro los procesos de integración.
• Carga de tablas de hechos: es uno de los procesos mas importantes dentro de los procesos de construccion de un DW.

Tratamiento SCD.

En la imagen podemos observar un algoritmo que puede sernos muy util para procesar las dimensiones donde hemos implementado el tratamiento de las SCD y estemos utilizando claves subrogadas. El planteamiento es muy sencillo. Realizamos la extracción de datos del sistema origen y vamos procesando cada uno de los registros que formaran la dimensión (una vez han sido depurados, transformados y normalizados), justo antes de realizar la carga. Podemos tener varios casos:

Algoritmo para el tratamiento de las SCD

• Nuevo registro: se le asociara una nueva clave subrogada a este, y se llenaran los campos de control de fechas de validez y el indicador de registro activo (también el numerador de versión, que empezara por 1).
• Registro no modificado: en el caso de que el registro no tenga ninguna modificación, lo ignoraremos y pasaremos al siguiente registro.
• Registro modificado:cuando el registro tiene alguna modificación en alguno de los campos, se pueden dar dos casos, al menos:
  • Campo modificado del tipo SCD 1 o 3: actualizamos el atributo de la dimensión. En este caso, no se va a generar un nuevo registro ni una nueva clave subrogada.
  • Campo modificado del tipo SCD 2: el cambio es en alguno de los campos que consideramos relevante. En este caso, se genera una nueva clave subrogada para el registro, y se llenan los correspondientes campos de fecha, versión y registro activo. Además, se ha de procesar el registro valido anterior, cerrando la fecha fin de validez al dia anterior a la validez inicial del nuevo registro, y desmarcando el flag de registro activo (pues deja de ser el registro actual).

Veremos que Kettle incorpora una parte del algoritmo (con el step Dimension lookup/update), al igual que lo hacia Talend con su componente tMySqlSCD de una forma completa (tal y como vimos en una entrada anterior).

Carga tabla hechos. Tener en cuenta claves subrogadas.

Cuando realizemos la carga de la tabla de hechos (normalmente despues de haber realizado el procesamiento y carga de las dimensiones de las que depende), habrá que tener en cuenta que hemos «dado el cambiazo» a los códigos originales del sistema operacional por los códigos inventados de las claves subrogadas. Por tanto, esto habrá que tenerlo en cuenta antes de realizar la inserción. En la imagen vemos una alternativa posible a la forma de procesar este aspecto:

Conversion a claves subrogadas en la tabla de Hechos

El paso consiste en, previamente a la inserción en la base de datos, vamos recorriendo las diferentes claves naturales y buscamos su clave alternativa (subrrogada) en la dimensión, realizando su sustitución. Para hacer la conversión nos valdremos de los periodos de validez que hemos incluido en el tratamiento de la dimensión lentamente cambiante, o en el caso de no tener un periodo de validez, nos puede vale el registro activo en el momento del proceso (este aspecto habrá que analizarlo bien antes de tomar una decisión).

Algunas recomendaciones previas al diseño de los procesos ETL. Metadatos y Nomenclatura.

Al igual que al definir nuestro modelo de datos o al realizar la identificación de los origenes de datos, es recomendable disponer dentro del sistema ETL un Metadatos y una nomenclatura bien definida que permitar una mejor gestión y comprensión de todo el sistema.

Por un lado, podemos documentar los diferentes procesos que tenemos de una forma general, incluyendo su proposito y los elementos que intervienen en cada job.

Documentación Jobs

Ademas, al construir los procesos, sería conveniente utilizar una nomenclatura unificada tanto para sus nombres como para los nombres de los componentes que los formaran, lo que puede permitir una mejor comprensión y mantenimiento posterior de los trabajos. Luego habrá que detallar cada proceso en particular e incluir en esa documentación todos los elementos que intervenienen en el proceso, todas las tareas que se realizan, incluyendo también información de los momentos de ejecución de cada proceso, las dependencias con otros procesos, las acciones a realizar en el caso de errores o parada, etc.

Os recomiendo sin duda para preparar todos estos aspectos  la lectura de libro The Data Warehouse ETL Toolkit de Ralph Kimball y Joe Caserta. En el se abordan muchisimos temas que podriamos tener en cuenta en la construcción de nuestros procesos ETL en los que no hemos entrado, como pueden ser:

• Técnicas de optimización a la hora de realizar las cargas: realizando ajustes en los  indices (incluso desactivandolos antes de las cargas), separando actualizaciones e inserciones, utilizando bulk loader (o cargadores masivos), desactivación del log de cambios de la base de datos (pues es superfluo en un sistema DW), desactivación de la verificación de claves foraneas durante las cargas, calculo de agregaciones fuera de la base de datos, etc.
• Particionado de tablas para mejorar el rendimiento del sistema.
• Lanzamiento de procesos batch, procesamiento en paralelo.
• Realizar cargas incrementales de los datos en lugar de cargas completas (será posible o no según el tipo de dimensión y el tipo de tabla de hechos).
• Borrado o ocultación de datos históricos que ya no se utilizan.
• Tratamiento de actualizaciones tardias en las tablas de hechos.
• Gestión de tablas de hechos agregadas, usando, por ejemplo, vistas materializadas.
• Uso de herramientas y utilidades de script para realizar parte de los procesos.
• Uso de centinelas para gestionar la correcta realización o no de procesos.
• Tecnicas de programación de tareas. Frecuencia de procesos de carga.
• Trabajar con un sistema de desarrollo y uno productivo al menos (aunque seria ideal disponer también de un sistema de Test intermedio).
• Trabajar con versiones de los procesos, de forma independiente para gestionar mejor los cambios.
• Documentación de procesos, etc., etc.