Continuando con la idea introducida en el primer tutorial de Knime, aquí ya no se está contemplando el nivel de iniciación. Hay que complicar las cosas un poco, aun siguiendo con la lógica anterior. Knime es una plataforma a la que se le pueden dar muchos usos y en este caso en particular será utilizada, de nuevo, como una herramienta ETL. En el capítulo anterior se veía cómo mediante Knime se puede acceder a las marañas de datos disponibles para posteriormente mostrar información relevante. En este capítulo van a complicarse un poco las cosas. Se introducen ficheros con distinta estructura, loops y “flow variables”. Todo esto para tratar la información y tener un resultado cohesivo.
En este tutorial se utilizarán bases de datos de negocio. Es decir, no tratadas y relativamente más complejas de lo que pueden ser las descargadas desde entornos como el INE o, como en la última ocasión, DATADISTA.
LA BASE
En este ejercicio hay que dedicarle un tiempo a la preparación del fichero, ya que no es tan sencillo como en el tutorial anterior. Aquí se va a utilizar una trazabilidad de llamadas de diferentes campañas. Esto suma alrededor de un millón y medio de líneas, en diferentes ficheros, desde comienzos de octubre. El tiempo de procesado es superior al habitual, por lo que hay que buscar la manera para que las cargas sean eficientes. Este es el principal problema. Numéricamente, se dispone de alrededor de 50 ficheros, a los que se suma uno cada día.
Estos ficheros tienen alrededor de 25 hojas distintas cada uno. Se adjunta un pantallazo de cómo se ve un fichero tipo. Por obvias razones hay información censurada pero la estructura general es como sigue.
Además, no todos los ficheros tienen las mismas columnas ni las mismas hojas. Es decir, cada fichero, aunque tienen la misma granularidad (entendiendo por esto el nivel de agrupación), tiene estructuras diferentes. Este es el segundo problema. El tercer problema es hacer que la lectura de los ficheros sea lo más automática posible.
LA CARGA
Esta parte es la que más prueba y error requiere, ya que tenemos que solventar los tres problemas mencionados anteriormente. Como ya se ha comentado en el tutorial anterior, Knime tiene una gran variedad de capacidades a la hora de hacer la carga de los datos, pero hay que saber configurar los nodos cuando se trata de diferentes archivos. En el caso de que haya muchos ficheros con una sola hoja en la que la estructura fuese siempre la misma, con un solo nodo sería suficiente. Especificar la ruta y marcar la opción para que lea el contenido de la carpeta en el Excel Reader es rápido y sencillo.
Esta no es la situación en este ejercicio. Aquí hay muchos documentos en una sola ruta, pero la estructura es variable, por lo que hay que indicarle a Knime que tenga esto en cuenta. Para hacer esto, hay un nodo llamado Read Excel Sheet Names, al que se le puede indicar la ruta en la que se desea trabajar. Una vez ejecutado, este nodo leerá los nombres de las hojas de los documentos Excel, devolviendo una tabla con el Path del fichero leído y todas las hojas que hay dentro del mismo.
En este caso en particular, un requerimiento del departamento de Operaciones es tener disponibles los ficheros de trazabilidad de cada campaña por separado para poder acceder a ellos de forma independiente. Para escoger de forma independiente cada campaña, se filtra la tabla generada por el Read Excel Sheet Names. De esta forma se consigue una tabla con todas las rutas en las que hay la hoja específica que se haya elegido sobre la cual trabajar.
A continuación, vienen los componentes importantes para que la ejecución de todos los ficheros pase de las 5 horas iniciales a unos pocos minutos. Se envía la tabla filtrada a un nodo llamado Table Row To Variable Loop Start, que envía todos los Paths que esta contiene a una Flow Variable.
Las Flow Variable pueden entenderse como un parámetro, es decir, un factor que define numérica o cualitativamente un conjunto de condiciones. Pueden usarse para una gran variedad de operaciones. Indicar rutas de lectura de archivos, especificar nombres de ficheros, hacer agrupaciones dentro de las bases de datos, sobrescribir celdas… Estos parámetros aportan una gran flexibilidad para la automatización de tareas. Además, introducen un nuevo tipo de conexión entre nodos, que se representa mediante el conector rojo que se ve en el siguiente pantallazo.
Para continuar, la tabla de Flow Variables se envía directamente al lector de Excel, que configura la ruta de lectura mediante la variable y un par de opciones convenientes. La primera página de configuración se vería como a continuación. Es importante tener en cuenta que la configuración, a diferencia de lo mencionado antes, está especificando que solo lea un fichero. Esto es porque las rutas de los ficheros ya están configuradas mediante el Path de la Flow Variable. Combinado con que escoja la hoja de forma automática, agilizará tremendamente la carga de datos.
Pero con esto no es suficiente. Ha de tenerse en cuenta la diferente estructura de los ficheros. Los lectores en Knime tienen más opciones que permiten tener en cuenta diferentes esquemas. En la opción de ajustes avanzados puede escogerse una opción que prepara al lector precisamente para esta ejecución dentro de un loop, entre otras opciones.
Una vez configurado el lector, se ajusta el final del loop y ya estaría lista la ejecución.
El resultado que se obtiene tras la ejecución es la agrupación de, hasta el momento, 47 archivos. Más de un millón y medio de filas y una nueva columna que indica el número de loops que se han realizado, desde el 0. Esto está bien, pero es importante ser capaces de diferenciar las campañas, así que hay que añadir unos pocos nodos al flujo, cuyo resultado final se ve a continuación.
LOS NOMBRES
Los nodos GroupBy y Table Column to Variable sirven para extraer el nombre de la campaña y convertir dicho nombre en una variable. Esta variable se pasa al nodo Constant Value Column, cuyo funcionamiento consiste en generar una columna para toda la tabla de datos. Esta columna puede especificarse a mano o, como en este caso, usando una Flow Variable para automatizar el nombre.
Para terminar, se escribe el fichero en la ruta deseada. El lugar donde volcar la información aquí es la misma desde la que se leen los archivos originales. Por lo tanto, la ruta también puede automatizarse, ya que está disponible en el Path inicial. Se añade un nodo String Manipulation, mediante el que se pueden modificar valores de cadena. Aquí se concatena el Path con el nombre del fichero deseado, que dará como resultado la ruta deseada en formato String.
Se convierte la String a formato Path y una vez se tiene convertido el Path en una Flow Variable, se alimenta un escritor de todos los que tiene Knime. Excel, CSV, Keras, H2O, JSON, Google… Aquí, con un CSV Writer es suficiente. El resultado final son 25 ficheros CSV escritos y preparados para el tratamiento en unos 3-4 minutos. Las pruebas iniciales llevaban alrededor de 5 horas. Solo para cargar los ficheros.
EL TRATAMIENTO
En lo que se refiere al tratamiento, la velocidad y facilidad también son bastante destacables. Lo único que es necesario es añadir un nodo Concatenate, que permite juntar todos estos ficheros tratados y los convierte en uno. El tiempo que tarda Knime en esta tarea es prácticamente cero, ya que el software puede guardar en la memoria lo procesado previamente. Este nodo devuelve, por ahora, una tabla de 12 columnas y 1.636.631 filas. Como en el tutorial anterior, para hacer un informe relativamente presentable, lo único que hay que hacer es tratar la información, agruparla y prácticamente está lista para generar el cuadro de mando. En este caso en particular es interesante añadir una agrupación de tipificaciones de llamadas.
Para esto, se genera una tabla con el nodo GroupBy y se añaden solo los cierres. Visualizando todos los cierres distintos, mediante un nodo Table Creator se generan las agrupaciones correspondientes para cada cierre, que se agrupa en diferentes categorías. Sistema, No asegurable, No interesado, Venta… En función del negocio habrá diferentes categorías. Para enlazar esta tabla con los millones de filas, lo único que hay que hacer es añadir un nodo Cell Replacer, con una configuración como la que se muestra a continuación. Esto añade una nueva columna llamada GRUPO_CIERRE, mediante la cual ya puede agruparse para reducir información.
Se configura otro GroupBy y se reduce una base de datos de más de un millón de filas para tener un resultado final de 120.425. Es decir, se ha reducido un 93% del tamaño original de la tabla sin grandes pérdidas de información. Y, una vez configurado y contrastado que el flujo no presenta problemas, es un tipo de tarea con mantenimiento casi mínimo. Lo conseguido puede acabar convirtiéndose en un cuadro de mando, en informes diarios, en archivos planos, en todo al mismo tiempo… todo en función de la necesidad del analista y, por supuesto, del negocio.