En este capítulo finalizaremos analizando cómo podemos integrar y utilizar todo lo aprendido para construir nuestros paquetes de Integration Services (SSIS) en SQL Server CodeName Denali CTP3 utilizando el nuevo componente Data Quality Services (DQS) para limpiar y clasificar nuestros flujos de datos.
SSDQS y su integración con SSIS
En la CTP3 de Denali encontramos un nuevo elemento en el cuadro de herramientas de SSIS, el componente DQS Cleansing. Correspondería a un proyecto de cleansing (limpieza de datos) que vimos en el anterior capítulo de esta serie, y se basa en una de las Knowledge Base (KB o base de conocimiento) que se encuentren publicadas en nuestro servidor DQS.
Este componente consulta una de nuestras KB publicadas y nos da como salida los resultados de sus comparaciones. A todos los efectos para el servidor DQS el componente de SSIS es un cliente, como también lo es SSDQS Studio. Podemos ver su posición en la arquitectura en el siguiente diagrama publicado por el equipo de desarrollo de DQS.
Como vemos en el diagrama, el componente se comunica con el servidor DQS, enviando filas y recogiendo los resultados que el motor DQS le devuelve. Si estamos utilizando Reference Data Services (RDS, a.k.a. bases de conocimiento en la nube) nuestras filas serán enviadas y analizadas allí.
Al arrastrar el componente a nuestro DataFlow, requerirá de una entrada de datos donde se encuentra al menos una columna que queramos limpiar. Una vez suministrada una entrada válida, abriremos la interfaz de configuración del componente y tendremos que suministrar una conexión a un servidor DQS válido y una base de conocimiento publicada (tanto si es local como registrada desde el DataMarket de Azure). Si tenemos bien configurado nuestro servidor, tendremos algo como esto:
Ahora, pasaremos a mapear los campos que queremos utilizar durante el proceso de limpieza de datos. Para ello, en la pestaña “Mapping” asociaremos los campos a los dominios que estén disponibles (“Available domains” en la Figura 3).
Aquí obtenemos una serie de columnas extra que nos añade el componente para darnos información sobre qué sucede con nuestros datos y qué resultados obtiene el componente al analizar éstos usando la base de conocimiento que le hemos indicado.
Las mapeos para cada columna y la definición de las mismas las vemos a continuación:
- Corrected Output Alias: Nombre de la columna con el nombre que DQS Component sugiere como corrección. Si el valor original ya es correcto, coincidirá con éste.
- Status Output Alias: Nombre de la columna que indica el estado del dato que estamos analizando. Puede ser “Correct”, “Incorrect” , “Invalid”, “Autosuggest” en el caso de las sugerencias de corrección, “Unknown” cuando DQS no reconoce los valores (valores nuevos) y “Corrected” para aquellos que ha corregido con una confianza mayor al 80%.
- Confidence Output Alias: Nombre de la columna que nos indica el valor de credibilidad que DQS le da a su análisis. Puede ir de 0 a 100.
- Reason Output Alias: Nombre de la columna que nos dice por qué DQS ha decidido ofrecernos las soluciones de corrección de datos para cada registro analizado.
En la pestaña de configuración avanzada, tenemos los siguientes elementos
- Estandarizar salida (Standarize output): Es la estandarización que controlamos también desde SSDQS Studio. Estandariza la salida dependiendo de las características del dominio que usemos para la limpieza de datos. La primera manera de estandarización es la conversión a mayúsculas o minúsculas, y la segunda es la corrección al valor inicial (o principal). Esto es importante cuando trabajamos con corrección por sinónimos.
- Columna de fiabilidad (Confidence): Habilita una columna extra en nuestro flujo de datos donde DQS nos da un valor que representa la fiabilidad que le otorga a la corrección que realiza al analizar nuestros datos contra la base de conocimiento dada (o la RDS en la nube).
- Columna de razón (Reason): En caso de que el valor corregido sea diferente al original, la columna que añade este checkbox nos da información de por qué DQS lo ha corregido. Puede, por ejemplo, ser inválido por las reglas del dominio o haber sido corregido por DQS al normalizar a mayúsculas.
- Datos añadidos (Appended Data): Cuando trabajamos con RDS, puede que este nos devuelva información adicional. Por ejemplo, si estamos analizando direcciones, puede que nos devuelva también los datos de geolocalización (Latitud/Longitud). Estos datos irían en la columna que podemos habilitar marcando este checkbox.
- Esquema de datos añadidos (Appended Data Schema): Si el RDS devolvió información adicional, este campo de esquema reflejará el esquema para la interpretación del dato (descripción de los campos de la información adicional separados por caracteres especiales, por ejemplo)
Aquí podemos observar algún concepto común a lo que ya existe y podemos haber usado en versiones anteriores de SSIS. Concretamente, la columna de fiabilidad representa el mismo concepto que tenemos en otros componentes de SSIS como son el Fuzzy Lookup y el Fuzzy Grouping, y por lo tanto podemos utilizarlo de manera parecida para filtrar o clasificar las correcciones que nos da DQS Component en función de la fiabilidad, por ejemplo. Sin embargo, DQS Component nos provee de más y mejor información respecto a nuestros datos.
Tenemos un ejemplo sencillo para ilustrar como quedaría un DQS Component conectado y listo para limpiar nuestros datos.
Hemos habilitado un DataViewer para analizar qué sale del componente. En este caso, vemos un ejemplo de dato corregido. Todos los registros que aparecen son correctos por ser valores que DQS ha encontrado en su dominio de Artistas, y “Anderson, Mark” se corrige como “Andersen, Mark”, que sí existe en el dominio y es similar en un 81,25% al valor encontrado en el flujo de datos entrante. Además, el componente nos marca que la razón de la corrección es una acción de limpieza efectuada por el motor DQS.
Para lidiar con toda la posible variedad de combinaciones de valores conocidos, inválidos, nuevos y demás podemos plantear un escenario en el que clasifiquemos nuestros resultados mediante un Conditional Split para decidir qué hacer con cada resultado.
Con unas condiciones como estas (o las que nosotros consideremos adecuadas, podríamos añadir clasificación usando los grados de fiabilidad, por ejemplo) quedaría un diagrama como el siguiente.
Desde aquí podríamos trabajar con los diferentes destinos para mantener nuestra Knowledge Base, utilizar tablas temporales como orígenes de componentes Lookup, generar una tabla de cambios (o tabla delta) para usarla como paso intermedio para su uso en una operación MERGE de TSQL posterior, mapear directamente a nuestras tablas los valores corregidos por el componente DQS o cualquier operación que nuestro sistema necesite y/o seamos capaces de imaginar.
Para un correcto proceso de limpieza es fundamental una buena base de conocimiento. Sin ella, cualquier operación que generemos después para gestionar nuestros datos no será fiable y no valdrá de nada todo el esfuerzo invertido, pues no podremos asegurar la solidez de nuestros datos resultantes. Por ello son muy importantes las técnicas descritas en los capítulos anteriores de esta serie, tanto aquellos “directos” (descubrimiento de conocimiento a partir de tablas o ficheros Excel maestros, consumo de RDS desde la nube, etc.) como los “indirectos” (los datos de supervivientes de un proyecto de matching para utilizar como fuente para un proceso de descubrimiento de conocimiento, por ejemplo).
Futuras características
El grupo de producto de DQS ha anunciado tanto en TechEd North America 2011 como en los foros de MSDN que esperan liberar un API para poder acceder a los entresijos de las bases de datos que se utilizan para los procesos de calidad de datos que hemos estado viendo en estos artículos. Esto permitirá la inclusión de una de las características más esperadas del producto, la posibilidad de utilizar los datos obtenidos de un proceso de limpieza de datos como el que nos ofrece el DQS Component para re-alimentar (añadir nuevos elementos considerados válidos) nuestra base de conocimiento (con los datos corregidos y nuevos, por ejemplo, o teniendo en cuenta el índice de fiabilidad) y hacerla prácticamente auto-mantenible.
También las dificultades que se pueden encontrar en la instalación y uso de DQS relacionado con el tamaño de los conjuntos de datos, referencias de ensamblados o uso de datos geoespaciales, por ejemplo, están en la lista de modificaciones a solucionar en la versión final del producto.
Conclusión
Es relativamente simple trabajar con el componente DQS para SSIS, con pocos pasos nos da mucha información sobre nuestros datos y nos permite limpiarlos de manera fácil e intuitiva. Como ya hemos comentado anteriormente, se hace importantísima la existencia de una base de conocimiento de calidad y adecuada a nuestras necesidades, y aunque no sería muy costoso construir una propia partiendo de unas pocas reglas básicas, si necesitamos una más compleja sí supondrá una inversión más importante:
- En tiempo de desarrollo y test hasta cubrir las necesidades del negocio
- Económica si existe una solución en la nube que queramos consumir y no sea gratuita (para consumos de producción del orden de cientos de miles de filas ahora mismo no existen soluciones gratuitas en el Data Market de Azure).
En futuras versiones veremos las posibilidades que abren las nuevas características que se puedan implementar y la corrección de algunas cuestiones propias de versiones previas que existen ahora mismo. Podremos entonces valorar por completo un producto que promete un gran abanico de alternativas y soluciones a los problemas de integridad y limpieza de datos que existen en la inmensa mayoría de los sistemas de almacenamiento de datos.
Enlaces relacionados
Data Quality Services FAQ: http://social.technet.microsoft.com/wiki/contents/articles/3919.aspx
Blog del equipo de desarrollo de DQS: http://blogs.msdn.com/b/dqs/
Data Quality Services Known Issues: http://social.technet.microsoft.com/wiki/contents/articles/3711.aspx#Data_Quality_Services
Charla de presentación de DQS en TechEd 2011: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DBI207
