El diseño de procesos ETL es una de las tareas más importantes dentro de todas las que se llevan a cabo al construir un data warehouse. Se trata de una actividad compleja, que requiere mucho tiempo y consume la mayor parte de los esfuerzos y recursos de implementación del proyecto de data warehouse.
Créditos fotográficos: GuidoVrola
Para contener los costes asociados a los procesos ETL y aumentar su rentabilidad, hay que poner el foco en la comprensión de tres áreas principales: el área de origen, el área de destino y el área de mapeo (procesos ETL); y, además, tener claras algunas cuestiones que suelen quedar en el aire. Son las relacionadas con la elección de los mecanismos de captura de datos modificados, el momento de recurrir a los repositorios y la integración de datos.
Sistema de captura de datos modificados en procesos ETL. La comprensión de los sistemas fuente
Al poner en marcha los procesos ETL para una carga histórica inicial del data warehouse, la captura de datos modificados (Change Data Capture: CDC) no es motivo de preocupación. Su relevancia no puede compararse a la que un sistema de este tipo adquirirá en los subsiguientes ciclos ETL.
El motivo es que, mientras que los cambios en el contenido de los datos de origen no son importantes, ya que se está cargando todos los datos desde un punto en el tiempo muy concreto, de ahí en adelante; en las cargas iterativas, sucede lo contrario: es un asunto crítico.
En la práctica, la mayoría de las tablas del almacén de datos son tan grandes que no se pueden actualizar durante cada ciclo ETL. Por esta razón, es importante que los procesos ETL puedan transferir al data warehouse sólo los cambios relevantes sufridos por los datos de origen desde la última actualización, es decir, los datos que han sido modificados desde la última carga. Para conseguirlo es preciso poder aislar esos datos. Y en eso consiste el CDC.
Pero construir un buen sistema de captura de datos modificados no es tan fácil como parece y los motivos son:
- El sistema de CDC debe construirse a prueba de fallos, para asegurarse de que todos los datos modificados puedan ser identificados.
- Muchas veces las actualizaciones de las tablas del sistema de origen tienen lugar fuera de la propia aplicación y eso complica la consistencia en los resultados.
- Es difícil escoger la estrategia a aplicar.
Un error aquí resultará en resultados inconsistentes, problemas costosos y falta de confianza en la información. Dentro de los procesos ETL, todo lo relativo a la captura de los datos modificados está lejos de ser una tarea trivial y obliga a ganar en conocimiento acerca de los sistemas de datos de origen. Sólo a través de la comprensión de estas fuentes, el equipo encargado de la extracción, transformación y carga será capaz de completar el proyecto con resultados satisfactorios.
Procesos ETL: cuándo hay que dejar los datos en el repositorio
En el entorno de data warehousing actual, es muy posible que las herramientas ETL establezcan una conexión directa con la base de datos de origen. A partir de ahí, lo normal es que extraigan y transfieran los datos a través de la herramienta ETL elegida para aplicar in memory cualquier transformación que se precise. Finalmente, sólo faltaría escribirla una sola vez en el destino, ya en su tabla de almacenamiento de datos correspondiente.
No obstante, desde un punto de vista de rendimiento, esta capacidad puede ser poco rentable. Especialmente cuando se trata de RDBMS, los procesos ETL así planteados podrían resultar demasiado costosos.
Minimizar el gasto asociado al proyecto ETL es una cuestión de diseño. Y, precisamente en una decisión como la de recurrir a un repositorio en diferentes momentos de los procesos ETL, se encuentra la clave, no sólo para reducir costes, sino también para aprovecharse de ciertas ventajas.
Las razones detrás de la inclusión de un repositorio en el plan de ETL tienen que ver con:
- Se desea un punto de recuperación, que permitiría el reinicio en el caso de que el trabajo de ETL fallase, por ejemplo, si se produjera una interrupción en la conexión entre el entorno de origen y los procesos ETL.
- Se quiere optimizar la efectividad del sistema CDC. Y ello requiere una comparación de la copia actual de la tabla de origen con la copia anterior de la misma tabla, algo que sólo puede llevarse a cabo cuando los datos se han copiado físicamente en otro lugar, el repositorio.
- Resulta importante evitar que los procesos ETL bloqueen bases de datos en el sistema de origen, dificultando el funcionamiento normal del sistema. Esto es algo que podría suceder si se tratase de un proyecto de larga ejecución y que podría evitarse con la copia de datos, por ejemplo, en disco.
- Es preciso realizar una copia de toda la información sujeta a traslado, puesto que la organización necesita presentar los datos inmediatamente después de la extracción con fines de archivo. Se trata de algo habitual en muchas compañías y está relacionado con cuestiones de cumplimiento normativo o de auditoría.
Dónde y cómo debe llevarse a cabo la integración de datos en los procesos ETL
Los procesos ETL de éxito son los que se han planteado desde una profunda comprensión de los sistemas de origen y en base a una completa visión de los de destino. Precisamente esta visibilidad tiene que ver con la integración.
La integración de datos:
- Significa llegar a un acuerdo sobre el significado de los datos desde la perspectiva de dos o más bases de datos.
- Busca asegurar el funcionamiento de todos los sistemas al unísono y son problemas.
- Permite que el análisis en el data warehouse se lleve a cabo combinando datos procedentes de fuentes diversas.
La visión 360 grados es un objetivo común para muchas organizaciones y que, para alcanzarse, debe extender sus raíces a los sistemas de transacción, los procesos ETL que mueven los datos antes de su llegada al data warehouse.
Es en esos procesos cuando la integración de datos se origina, puesto que en ese momento quedan definidos dimensiones y hechos. Se establecen atributos de dimensión comunes a través de tablas de hechos separadas. En otras palabras, se establecen acuerdos sobre métricas comunes de negocio, como pueden ser los KPIs, a través de bases de datos separadas, de manera que estos números puedan ser comparados matemáticamente para calcular diferencias y ratios. De esta manera, el reporting puede profundizar en base a cualquiera de los atributos del datode forma consistente, fiable e integrada.
