16. Procesos ETL. Escenarios para el diseño de los procesos.

En una entrada anterior del blog hicimos un repaso de las herramientas ETL, viendo cual era su cometido, las características que debería de tener una herramienta de ese tipo, enumerando igualmente los productos comerciales y open source mas conocidos.

Llega el momento de profundizar un poco mas antes de abordar la construcción de los procesos de carga de nuestro DW pero utilizando, esta vez, Pentaho Data Integration (Kettle). En la serie de ejemplos anteriores utilizamos Talend Open Studio con exito para la construcción de procesos y vimos que era una herramienta muy completa y potente, y con un gran futuro por delante por todos los recursos que se estan utilizando en su desarrollo.

Procesos ETL utilizando Talend

Introducción.

Los sistemas o procesos ETL (Extact-Transform-Load) son la base de la construcción de cualquier sistema Data Warehouse (aunque ademas puedan ser utilizados para otros muchisimos cometidos). Un sistema bien diseñado extrae la información de los sistemas origen, asegura la calidad y consistencia de los datos, homogeniza los datos de sistemas divergentes para que puedan ser utilizados de una forma conjunta (procesando y transformando la información si es necesario) y finalmente genera los datos en el formato apropiado para que puedan ser utilizados por las herramientas de análisis.

Como bien dice Ralph Kimball en su libro «The Datawarehouse ETL Toolkit«, los sistemas ETL construyen o «se cargan» un Data Warehouse. La construcción de un sistema este tipo es una actividad que no esta en primera linea de fuego y no es visible para los usuarios finales, pero facilmente consume el 70% de las necesidades de recursos para el desarrollo y mantenimiento de un sistema DW. Ademas, estos procesos no son solamente un mero traspaso de información de un sistema o otro. Son mucho mas, pues pueden dar un valor significativo a los datos. Unos procesos mal definidos, mal validados, pueden cargarse un sistema de BI impecablemente diseñado, pero mal alimentado por unos procesos mal construidos.

El proceso de construcción de un sistema ETL puede ser extraordinariamente exigente y complejo, estando ademas limitado por muchos aspectos, como pueden ser los requerimientos, los formatos y deficiencias de los datos de origen, las habilidades del personal disponible, las necesidades de los usuarios finales, el presupuesto del proyecto, las ventanas de tiempo para los procesos de actualización, etc. Teniendo en cuenta esto, no se debe nunca despreciar la importacia, el tiempo y recursos que se han de utilizar para su construcción.

Los requerimientos afectan a como va a ser nuestro sistema ETL.

Existen diferentes elementos que van a afectar en como va ser o como vamos a construir nuestro sistema ETL. Los mas importantes son los requerimientos. La elección de uno o varios procesos de negocio, las dimensiones e indicadores que vamos a analizar, su granuralidad, etc., van a determinar cosas tan dispares como los origenes de datos que vamos a tener que utilizar,la forma de procesar la información, la complejidad de los procesos, etc. Esto nos va a hacer darnos cuenta de lo importante que son dichos requerimientos y su correcta definicion en todas las tareas que realizemos a continuación, incluyendo la definición de la arquitectura de nuestros procesos ETL. Ademas el estudio de los sistema origen debe permitir añadir nuevas funcionalidades que pueden no haber sido tenidas en cuenta antes.

Otros elementos que van a influir en mayor o menor medida serán:

• Data Profiling: cuando nos ponemos a analizar los datos de los sistemas origen nos encontraremos sorpresas, seguramente debido a que nunca se establecio ningún control o mecanismo para asegurar la calidad de dichos datos en los sistemas operacionales o en cualquier otro origen de datos. La información no tiene la calidad deseada y eso puede ser un incoveniente a la hora de construir el sistema de análisis. Para ello emplearemos técnicas de Data Profiling, que con metodos analiticos revisan los datos para obtener una comprensión completa de su contenido, estructura y calidad. Esto nos permitirá analizar grandes volumenes de información y descubrir todo tipo de cuestiones que deberan de abordarse (y tenerse en cuenta en el diseño del ETL). Imaginaros el caso de que la fuente de información no tenga la calidad esperada y ello puedo obligarnos a buscar otro origen de datos para cubrir los requerimientos. Si las técnicas de data profiling se hubieran aplicado en los sistemas origen, seguramente no se producira ningún tipo de problema. En caso contrario, deberemos seguramente eliminar el contenido de determinados campos, corregir valores corruptos, revisar errores manualmente para decidir como corregirlos, etc, etc, lo que puede complicar los procesos o obligarnos a incluir pasos para realizar el tratamiento de esos casos excepcionales.
• Requerimientos de seguridad: aunque habitualmente los mecanismos de seguridad para acceder a los datos estan establecidos en las aplicaciones de análisis mediante roles de usuario, de forma que cada uno de ellos solo deberá de acceder al nivel de información para el que este autorizado. En los sistemas ETL, habrá que establecer también los mecanismos oportunos para evitar accesos no deseados o perdida de información, que en muchos casos puede ser muy delicada.
• Data Integration: la información a lo largo de los sistemas es deseable que sea homogenea e integrada. Cuando hablamos de un ERP, esto suele ser habitual, pero no va a ser asi en todos los sistemas. A nivel de procesos ETL, esta integración de datos se referira a la hora de construir las dimensiones conformadas (los atributos comunes a lo largo de diferentes procesos de negocio), utilizando convenios de nombrado de campos, estructuras de datos o tipos, dominios de valores, etc. Lo mismo para el diseño de los indicadores, que deberán de ser construidos con criterios comunes.
• Frecuencias de actualización: la frecuencia con la que la información del DW deberá de ser actualizada desde los sistemas operacionales también puede influir significativamente en los procesos de actualización y su estructura.
• Habilidades disponibles en la organización: a la hora de construir y diseñar un sistema ETL hemos de tener en cuenta quien va a gestionar posteriormente el sistema. Sus habilidades, conocimientos habrán de ser tenidos en cuenta a la hora de seleccionar las herramientas, lenguajes de programación, etc. También podra influir el hecho de disponer ya de determinadas herramientas licenciadas para la construcción de procesos. Por ejemplo, si los procesos ETL se desarrollan en C++, sería conveniente disponer de un técnico que dominará ese lenguaje de cara a al posterior mantenimiento del sistema.
• Presupuesto: el presupuesto economico para desarrollar un proyecto, los plazos, los precios del hardware, licencias, herramientas pueden influir también en las decisiones que se tomen, y por tanto, afectarán también a la forma de construir el sistema ETL.
• Otros elementos a considerar: procesos batch vs procesos online, automatización de procesos, etc.

Arquitectura del sistema. Herramienta ETL vs Desarrollos a medida.

Una de las decisiones mas importantes que se va a tomar cuando se construyen los procesos ETL es la elección de una arquitectura. Ademas, es una decisión que hay que tomar en un momento inicial del proyecto y que puede condicionarlo en muchos aspectos. Basicamente, podemos plantear dos escenarios o arquitecturas diferentes (aunque en ocasiones podría darse el caso de que se complementasen):

• Herramienta ETL: uso de herramientas diseñadas para la construcción de un sistema ETL. Estan especializadas en este ambito y suelen incluir alguna o todas de las siguientes características:
  • Conectividad / capacidades de Adaptación (con soporte a origenes y destinos de datos): habilidad para conectar con un amplio rango de tipos de estructura de datos, que incluyen bases de datos relacionales y no relacionales, variados formatos de ficheros, XML, aplicaciones ERP, CRM o SCM, formatos de mensajes estandar (EDI, SWIFT o HL7), colas de mensajes, emails, websites, repositorios de contenido o herramientas de ofimatica.
  • Capacidades de entrega de datos: habilidad para proporcionar datos a otras aplicaciones, procesos o bases de datos en varias formas, con capacidades para programación de procesos batch, en tiempo real o mediante lanzamiento de eventos.
  • Capacidades de transformación de datos: habilidad para la transformación de los datos, desde transformaciones básicas (conversión de tipos, manipulación de cadenas o calculos simples), transformaciones intermedias (agregaciones, sumarizaciones, lookups) hasta transformaciones complejas como analisis de texto en formato libre o texto enriquecido.
  • Capacidades de Metadatos y Modelado de Datos: recuperación de los modelos de datos desde los origenes de datos o aplicaciones, creación y mantenimiento de modelos de datos, mapeo de modelo fisico a lógico, repositorio de metados abierto (con posiblidad de interactuar con otras herramientas), sincronización de los cambios en los metadatos en los distintos componentes de la herramienta, documentación, etc.
  • Capacidades de diseño y entorno de desarrollo: representación grafica de los objetos del repositorio, modelos de datos y flujos de datos, soporte para test y debugging, capacidades para trabajo en equipo, gestion de workflows de los procesos de desarrollo, etc.
  • Capacidades de gestión de datos (calidad de datos, data profiling, etc.).
  • Adaptación a las diferentes plataformas hardware y sistemas operativos existentes: Mainframes (IBM Z/OS), AS/400, HP Tandem, Unix, Wintel, Linux, Servidores Virtualizados, etc.
  • Las operaciones y capacidades de administración: habilidades para gestion, monitorización y control de los procesos de integración de datos, como gestión de errores, recolección de estadisticias de ejecución, controles de seguridad, etc.
  • La arquitectura y la integración: grado de compactación, consistencia e interoperabilidad de los diferentes componentes que forman la herramienta de integración de datos (con un deseable minimo número de productos, un unico repositorio, un entorno de desarrollo común, interoperabilidad con otras herramientas o via API), etc.
  • Capacidades SOA.

• Desarrollos a medida: los procesos ETL se desarrollan utilizando desarrollos a medida en un lenguaje de programación especifico. Algunas de las ventajas de utilizar los lenguajes de programación pueden ser:
  • Herramientas de Debug: que permiten verificar procesos y datos.
  • Reutilización de código ya existente. Diseño de código consistente a traves de las características de los lenguajes orientados a objetos.
  • Uso de recursos humanos internos especializados en el lenguaje.
  • Flexibilidad a la hora de construir los procesos y abordar cualquier tipo de tarea que ofrecen los lenguajes de programación.

La elección de un enfoque u otro va a determinar de una forma muy profunda el diseño del sistema ETL. Una herramienta ETL tiene muchisimas ventajas, tal y como hemos visto al enumerar sus características, y su continua evolución hace que cada día sea plantee menos la opción de los desarrollos a medida. Aunque esta opción tampoco se puede descartar nunca, pues en algunos casos puede ser necesario para realizar procesos muy complejos donde sacar partido a la flexibilidad de un lenguaje de programación especifico.

Implementación de Procesos ETL.

Como explica muy bien Kimball en su libro, los procesos ETL son similares a un restaurante y su cocina. En el comedor, los comensales degustan los platos como lo harian los analistas de negocio con los datos utilizando sus correspondientes herramientas de análisis. Puertas atras, en el interior, en la cocina, se preparan los platos, se analizan y limpian los ingredientes, desechando aquellos que no estan en condiciones, se trocean,  se cocinan, hasta elaborarlos tal y como serán presentados a los clientes.

El area de Staging según Kimball

De forma similar, el area de Stage sera lo mismo para nuestro DW. Es un lugar al que solo acceden las personas especializadas en la integración de datos, fuera del alcance de los usuarios. Allí los datos son extraidos, depurados, limpiados, conformados y normalizados, manipulados o calculados, y preparados para ser cargados en el DW donde podrán ser accedidos por los usuarios para realizar análisis con las diferentes herramientas de las que dispongan.

Los procesos en el area de Staging pueden incluir o no un almacenamiento de datos (aunque sea temporal), cuestión que dependera de como se diseñen los procesos, de los volumenes de información o de otras cuestiones. Básicamente, tenemos 4 tipos de pasos en esta area:

• Extracción: los datos son extraidos de los sistemas origen, que pueden ser tanto bases de datos, como ficheros (estructurados o no) u otros origenes. Los procesos de extracción pueden ser a veces el lugar idóneo para realizar las primeras acciones sobre los datos, como formateo, conversiones de tipos, conversión de juegos de caracteres, etc.
• Depuración: en esta etapa de los procesos ETL se procesa la calidad de los datos, revisando valores válidos, consistencia, eliminación de valores redundantes, chequeo de reglas complejas, etc. Puede ser necesaria la intervención humana en determinados casos.
• Conformación/normalización: la información es unificada, conformada y normalizada. Los indicadores y ratios son calculados de una forma racional, lo mismo que los atributos de las dimensiones, para que esten unificados y en todos los sitios donde aparezcan tengan la misma estructura y el mismo significado.
• Entrega: la información esta preparada para ser analizada. Se entrega al DW para que las herramientas de análisis puedan utilizarla, en los formatos idoneos para dicha tarea.

Creación o no de un Area de Datos en el Stage.

La decisión de almacenar los datos fisicamente en el area de Stage o no (y realizar su procesamiento en memoria) es una elección de diseño a la hora de construir los procesos ETL. Muchas veces puede ser la busqueda de un equilibrio entre el procesamiento en memoria o disco, o la busqueda de la forma más rapida de extraer la información de los sistemas origen para luego procesarla de una forma independiente, o la posibilidad de relanzar los procesos en el caso de que haya algún problema, lo que determine esta elección.

Teniendo en cuenta esto, pueden ser razones de peso para tener esta area de almacenamiento intermedio las siguientes:

• Recuperabilidad: los datos son almacenados en el area stage una vez son extraidos del sistema origen. A partir de ahí, se lanzan los procesos de transformación. En el caso de que haya algún problema, estas tablas de staging nos permiten recuperar y relanzar los procesos sin volver a interferir en los sistemas operacionales (esto solo tendrá sentido cuando los volumenes de información sean lo suficientemente grandes).
• Backup: nos pueden permitir disponer de backups de los datos en un punto determinado, lo que nos puede permitir relanzar procesos o recuperar situaciones en un punto anterior en el tiempo.
• Auditoria: el area de stage nos puede permitir realizar auditoria o verificación de procesos, así como realizar comprobaciones en como estaban los datos antes y despues de los procesos (igualmente sin recurrir a los sistemas origen).

Ejemplo de sistema ETL con almacenamiento en el area de Stage

En nuestro caso, vamos a construir un area de stage que será un punto intermedio de almacenamiento de la información a procesar antes de su carga en el DW. El area de Stage puede ser procesada de muchas maneras, desde ser limpiada cada vez que comienza un proceso de extracción y ser un mero lugar temporal donde realizar los procesos, hasta ser persistente y accesible para repetir procesos de carga o para validación. Normalmente se utiliza un enfoque hibrido según el tipo de procesos a realizar.

El area de Stage es un area reservada donde solo podran acceder los procesos ETL (en ningun caso los usuarios), y deberá de estar debidamente dimensionada para contener los volumenes de información necesarios, según el tipo de persistencia de los datos en ella que hayamos elegido.

A continuación, vamos a repasar algunas formas de analizar y documentar los origenes de información, como paso previo a la realización de cualquier tipo de proceso ETL. Despues definiremos y documentaremos nuestra area Stage y detallaremos posteriormente algunas técnicas ETL para el tratamiento de determinadas situaciones, para pasar finalmente al diseño de los procesos.