Descargue un PDF de este Artículo
Un elemento fundamental en un proyecto de BI es el Data Warehouse, lo que implica la existencia de un proceso ETL que lo alimente desde los diferentes orígenes. Para realizar este proceso, SQL Server incluye una herramienta llamada Integration Services (SSIS) que nos será de gran ayuda para la realización de dichos procesos. Daremos un paseo por un proyecto de SSIS comentando las características más destacables, haciendo consideraciones de diseño y rendimiento, y mostrando los componentes más usados.
Introducción
En primer lugar, quiero aclarar que vamos a abordar este capítulo partiendo de que nuestro proyecto de BI se va a realizar con las herramientas que nos propor-ciona SQL Server concretamente. No quiero que el lector se lleve a engaño al ver una perspectiva que considere muy focalizada en herramientas tras leer el capítulo. Así que lo anticipo en estas primeras líneas, ese es el objetivo, focalizarnos en SQL Server, sus herramientas y mis experiencias con ellas. Si el lector necesita información más conceptual, hay multitud de información sobre diseño, construcción y carga de un Data Warehouse. Para ello le recomiendo que lea las publicaciones de dos grandes gurús en esta materia, Ralph Kimball y Bill Inmon.
En la mayor parte de los proyectos de BI, tenemos un componente funda-mental, que es nuestro Data Warehouse o Data Mart. En él dispondremos de los datos sobre los que se van a centrar las consultas de los usuarios. También va a ser-vir como fuente de datos para la carga de los cubos de Analysis Services y para la explotación de la información desde herramientas de analíticas y de reporting.
Ahora vamos abordar la realización de procesos de ETL utilizando Integration Services, partiendo de la premisa de que nuestros orígenes de datos serán bases de datos relacionales (SQL Server, Oracle, MySQL, u otra), y de que contaremos con un Staging Area y con un DataMart, siendo ambas, bases de datos almacenadas en SQL Server. Y aplicando una serie de buenas prácticas que hemos ido recopilando en base a nuestra experiencia.
¿Qué es Integration Services?
Integration Services es una herramienta que apareció con SQL Server 2005, dando un salto radical con respecto a las herramientas proporcionadas por versiones anteriores. Pasemos a incluir la propia definición que hace el fabricante de ella:
“Microsoft Integration Services es una plataforma para la creación de solu-ciones empresariales de transformaciones de datos e integración de datos. Integra-tion Services sirve para resolver complejos problemas empresariales mediante la copia o descarga de archivos, el envío de mensajes de correo electrónico como respuesta a eventos, la actualización de almacenamientos de datos, la limpieza y minería de datos, y la administración de objetos y datos de SQL Server. Los paquetes pueden funcionar por separado o conjuntamente con otros paquetes para hacer frente a las complejas necesidades de la empresa. Integration Services puede extraer y transformar datos de muchos orígenes distintos, como archivos de datos XML, archivos planos y orígenes de datos relacionales, y, posteriormente, cargarlos en uno o varios destinos.
Integration Services contiene un variado conjunto de tareas y transformacio-nes integradas, herramientas para la creación de paquetes y el servicio Integration Services para ejecutar y administrar los paquetes. Las herramientas gráficas de Inte-gration Services se pueden usar para crear soluciones sin escribir una sola línea de código. También se puede programar el amplio modelo de objetos de Integration Services para crear paquetes mediante programación y codificar tareas personaliza-das y otros objetos de paquete.”
Como se indica en la definición anterior, no es sólo una herramienta para ETL, sino que también tiene una serie de tareas orientadas a la administración que serán utilizadas por los DBA’s.
Por último, quiero destacar que este tipo de herramientas son muy potentes. Los desarrollos con ellas son muy rápidos, y nos permiten crear una gran cantidad de procesos en reducidos periodos de tiempo de desarrollo e implantación. Es muy sencillo crear un nuevo paquete que mueva y transforme datos a un nuevo destino, luego de ese destino hacer nuevos procesos para los cuales sea su origen de datos, y así sucesivamente, sin un buen diseño previo del objetivo global a conseguir y de las dependencias que se van creando entre ellos. Por ello, considero que esta herra-mienta puede ser un arma de doble filo: bien usada nos puede ayudar tremenda-mente a generar dichos procesos, coordinar su ejecución, y manejar las cadenas de dependencia entre ellos. Pero utilizarla sin un previo diseño y análisis de todo lo an-terior, puede crearnos un grave problema, incluso podemos llegar al punto de que el tocar simple proceso puede ser muy costoso, por las dependencias e implicaciones que tiene con otros procesos y que les haría dejar de funcionar correctamente. En este sentido, creo que podemos aplicar la famosa frase “una imagen vale más que mil palabras”:
Como ha podido comprobar, Integration Services es una herramienta muy completa y con muchas funcionalidades, e incluso con ciertos riesgos si no hacemos un uso apropiado de ella.
Integration Services como herramienta ETL
A partir de este momento nos vamos a centrar en sus características como herramienta ETL, y más concretamente en el uso de sus flujos de datos, estudiando el caso particular en el que tanto el origen como el destino son bases de datos rela-cionales. Vamos a utilizar Integration Services para implementar una serie de proce-sos de Extracción, Transformación, Limpieza y Carga de datos en nuestro DataMart, pasando éstos por un área de Staging.
Carga del Staging Area
Comencemos haciendo una serie de recomendaciones y marcando unas pau-tas que debemos tener en cuenta cada vez que abordemos una carga de datos, y para las cuales nos será de gran utilidad disponer de un área de staging:
para conseguir una máxima escalabilidad y para afectar lo mínimo posible al rendimiento de los servidores transaccionales que van a ser nuestros orígenes de datos, debemos consumir de ellos los mínimos recursos posibles, y centrar el consumo de dichos recursos en el servidor que se encarga de realizar los procesos ETL.
es muy importante saber dónde, cuándo y quién ha realizado cada cambio. Para ello deberemos, además de realizar los propios procesos de extracción y de obtención de diferencias entre el origen y el destino, de ir almacenando todos los cambios que nos encontremos, para, en un momento dado, poder seguir la pista de cualquier dato y de los cambios que ha sufrido.
siempre es una alternativa mucho más óptima tener una tabla delta, que tenga registradas las operaciones de inserción, actualización y borrado que se han ido produciendo en el origen, y aplicar esos cambios en el destino. Este proceso es mucho más eficiente, y por supuesto, consume muchos menos recursos en origen y destino, que hacer una lectura de dicho origen, compararlo con el destino, y obtener de ahí las diferencias para seguidamente aplicarlas al destino. Hay ciertos sistemas que ya nos permiten gene-rar este tipo de tablas, pero si no es así en nuestro caso, siempre po-demos generarlas en nuestros procesos ETL.
otro punto que no debemos olvidar en ningún momento, es que en este tipo de procesos, el objetivo no es solamen-te traer los datos al destino y hacer ciertas transformaciones. Es muy importante llevar a cabo una serie de tareas de limpieza de datos y detección de incoherencias. Si por ejemplo nos encontramos con un código de artículo del que nos llega una venta, pero aún no está en nuestro sistema. Si podemos hacer ciertas correcciones sobre datos que tenemos la certeza de que no son correctos, o simplemente no entrarlos al destino y dejarlos en algún lugar para que alguien los re-vise.
Veamos muy brevemente, mediante una serie de imágenes, un ejemplo de carga de una tabla en el área de Staging:
En este caso, disponemos de una columna en el origen de datos que nos in-dica la fecha de última modificación realizada en cada fila. Lo cual debemos aprove-char en el diseño de nuestro proceso, leyendo del origen sólo las filas que han cam-biado desde la última ejecución correcta de dicho proceso. Esto implica que debe-remos dividir nuestro proceso en dos bloques, el que se encarga de realizar las in-serciones y modificaciones, y el que se encarga de los borrados, con el fin de evitar que considere filas eliminadas en nuestro destino aquellas que no hemos leído del origen, porque no han sido modificadas desde nuestro último proceso de carga.
Carga del DataMart
Antes de adentrarnos en los procesos, vamos a recordar brevemente una se-rie de conceptos fundamentales que tenemos que tener en cuenta tanto en el diseño de nuestros Data Marts o Data Warehouses, como en la implementación de los procesos ETL:
Carga de dimensiones:
las dimensiones lentamente cambiantes permiten varias formas de registrar la modificación de los datos a lo largo del tiempo. Cuando ocurren estos cambios, puede que queramos registrar un historial de cambios o simplemente so-breescribir los valores anteriores. Sobre este tema hay varias estrate-gias, aunque aquí nos vamos a limitar a contar las dos que son utiliza-das con mayor frecuencia
es el tipo más básico, y consiste simplemente en sobreescribir en la dimensión los cambios producidos en origen, sin dejar ningún tipo de historial de lo ocurrido, sólo tendremos la última versión.
consiste en ir registrando historial de cambios, generando una nueva fila por cada versión de cam-bios que vaya apareciendo. Para ello hay que añadir unas co-lumnas adicionales que permitan registrar el periodo de vi-gencia de cada versión y una clave que las identifique (clave subrogada), ya que la clave de origen (clave de negocio) deja de ser única al repetirse en cada una de las versiones almace-nadas.
Carga de hechos:
un proceso de Lookup, consiste en el acceso mediante una clave a una tabla para que nos devuelva otras columnas de dicha ta-bla para la clave consultada. En el caso de las cargas de las tablas de hechos, como lo que obtenemos del origen son las claves de negocio (por ejemplo el código de artículo vendido), tendremos que acceder mediante un proceso de Lookup a la dimensión Artículo para obtener para cada clave de negocio, su correspondiente clave subrogada acorde al momento temporal en que se produce dicho hecho.
a veces nos llegan claves que hacen referencia a otras tablas, cuya clave no se encuentra en la tabla. Bien por proble-mas de integridad, o simplemente por la periodicidad que nos llegan los datos de ambas tablas. Por ejemplo, puede que nos llegue una venta de un artículo que no está en nuestra tabla de artículos, bien porque en la base de datos no hay integridad referencial declarativa, o porque tenemos un sistema distribuido y, aunque nos ha llegado la venta, tenemos pendiente que nos llegue el artículo. En ese caso, y para poder tener todas las filas de ventas, debemos crear una fila en la tabla de artículos, sólo con los datos que tenemos, y dejarla marca-da como pendiente de completar, para que posteriormente, cuando recibamos dicho artículo, completemos las columnas que hemos de-jado pendientes.
Veamos muy brevemente, mediante una serie de imágenes, un ejemplo de carga de una tabla de dimensiones en el DataMart, a partir de una tabla Delta:
En este caso estamos leyendo los datos de un área de staging, en la que he-mos incluido información de cada ejecución del proceso ETL, con el fin de que si no podemos realizar la carga del DataMart, podamos luego ir haciendo las cargas en el mismo orden que se produjeron en el área de staging. También hemos dividido el proceso en dos, por un lado las actualizaciones de datos basadas en conjuntos, y por otro lado las inserciones de nuevas filas.
Sobre el Autor
Salvador Ramos (twitter, blog) Consultor, Formador y Mentor en una amplia variedad de aplicaciones de negocio. Especializado en proyectos de Business Intelligence, bases de datos relacionales y diseño de Data Warehouses utilizando Microsoft SQL Server. Siempre interesado en proyectos de migración a SQL Server.