Casos prácticos - Español
Un ejemplo de un análisis particularmente problemático
on - edited on by
AlteryxAdvocacy
Una situación inusual de análisis de archivos de texto en la que era necesario implementar reglas de análisis dinámicas en cada línea de un archivo grande de datos, con distintas lógicas de análisis para cada línea, determinada por la clase de registro de esa línea.
El departamento de finanzas de T-Mobile se enfrentó a un desafío único al intentar analizar los grandes archivos de texto que recibían todos los días de la compañía de procesamiento de tarjetas de crédito. Estos archivos contienen datos sobre las transacciones realizadas con tarjetas de crédito de TODAS las tiendas de T-Mobile pero, cada línea del archivo contiene distintas reglas de mapeo según la clase de registro de ese ítem. Por eso, mientras que una línea puede tener 3 caracteres en la primera columna y 13 en la siguiente, la segunda línea puede tener dos columnas con 8 caracteres en cada una. Sin los típicos elementos disponibles para delimitar (pestañas, comas, pipes, entre otros), necesitaba encontrar una solución que adaptara dinámicamente la forma en la que cada línea de archivo se analizaba según su clase de registro.
Describe la solución funcional:
Para resolver este desafío, revisé la documentación proporcionada por la compañía de procesamiento de tarjetas de crédito y determiné que, mientras las reglas eran distintas para cada línea del archivo, había una lógica establecida según la clase de registro (un código de 3 dígitos cerca del inicio de cada registro). Por ejemplo, cada clase de registro 100 seguía el siguiente patrón de caracteres por campo: 8-6-3-19-4-10-11-11-11-2-6-3-4-4-4-79, y cada clase de registro 361 seguía el siguiente patrón de caracteres por campo: 1-3-4-9-3-8-9-14-1-8-19-8-98..., etc.
El primer paso fue crear el documento de mapeo de archivos (utilicé un archivo de Excel por si más adelante necesitaba realizar cambios en el mapeo) que contenía 4 campos: clase de registro, descripción de clase de registro, largo del campo y nombre del campo (los nombres de los campos eran distintos para cada clase de registro). Esto se utilizaría en el flujo de trabajo de Alteryx tanto para dividir cada línea de datos en una cantidad de campos adecuada (con el número adecuado de caracteres en cada uno) como para nombrar estos campos cuando los datos de salida se hayan escrito para separar tablas en el archivo de Excel.
NOTA: Una modificación posterior en este flujo de trabajo creo otro nivel de complejidad cuando me pidieron que delimitara la salida a ciertos campos (distintos para cada clase de registro) junto con la información del archivo sintetizada. Sin embargo, dado que ya tenía los archivos y las cabeceras asignadas a cada registro, fue muy sencillo seleccionar los campos que necesitábamos y generar ese subconjunto más pequeño y sintetizado.
El segundo paso fue crear el flujo de trabajo para incluir la información de mapeo e implementarla en cada registro según la clase de registro. Usé una herramienta de filas múltiples para crear números de columnas, luego gire la información para que los números de las columnas fueran cabeceras con el número de caracteres por campo que se mostraban en cada línea según la clase de registro.
Una vez incorporados los datos que mostraban los números de caracteres por campo, cambié de lugar la información y luego sinteticé todo mediante la función de concatenar, configurada de la siguiente manera:
Esto creó un patrón que podría usarse en las fórmulas RegEx, parecidas a las siguientes:
(.{8})(.{5})(.{8})(.{6})(.{8})(.{5})(.{20})(.{30})(.{6})(.{4})(.{4})(.{6})(.{7})(.{7})(.{4})(.{5})(.{10})(.{42})
Esta fórmula traía 8 caracteres para el primer campo, 5 caracteres para el segundo campo, etc. De esta forma, cada campo podría analizarse en el número correcto de caracteres según esa clase de registro.
Luego establecí un patrón de reemplazo según el número de campos que utilizaban los datos en el archivo. Por ejemplo, si se usaban 10 campos, buscaba el número máximo de campo (10), utilizaba Generar filas para crear campos del 1 al 10 y concatenaba esa lista para crear “$1|$2|$3|$4|$5|$6|$7|$8|$9|$10”. Esto se utilizaría en la fórmula RegEx como la salida, lo cual agregaría un delimitador entre cada uno de los campos según la lógica de mapeo.
Al incorporar este patrón en los datos de transacción, pude crear la siguiente fórmula RegEx:
Ahora que ya hemos analizado los datos en la cantidad correcta de campos por clase de registro, pude incorporar los nombres de los campos del archivo original de mapeo.
Fue necesario preparar los datos un poco mas para combinar algunos de los registros; por ejemplo, las clases de registro 100 y 101 se tuvieron que combinar para crear el grupo completo de campos para esa transacción. Al utilizar varias herramientas en la categoría de transformación (una de mis armas secretas fue la herramienta Crear columnas), pude unir esos registros relacionados y crear una versión final de los datos que contenían los campos básicos para la salida: identificación de registro, clase de registro, número de columna, nombre de campo y datos.
El último paso de esta solución fue generar los registros en un archivo de Excel con pestañas para cada clase de registro (dado que los nombres de los campos cambiarían para cada uno, no pude generar los resultados en una sola salida). Al crear un macro de lotes que procesaban cada clase de registro, una por una, y generaban los resultados en su propia pestaña en la salida de Excel, pude implementar los nombres de las columnas según la asignación para esa clase de registro.
Uno de los mayores beneficios de este flujo de trabajo es que no solo resolvió lo que parecía ser un problema de análisis imposible para este caso práctico relacionado con el procesamiento de tarjetas de crédito, sino que también es un flujo de trabajo repetible y flexible que puede utilizarse para cualquier situación de análisis fuera de lo común, sin tener que realizar grandes modificaciones. Además del departamento de finanzas, los demás departamentos que también lidian con situaciones de procesamiento de datos similares podrían adaptarlo fácilmente y convertirlo en una herramienta valiosa para todo T-Mobile.
La gran cantidad de datos que hubiera sido necesario procesar manualmente hizo que esto fuera una tarea abrumadora. Sin embargo, con este flujo de trabajo flexible de Alteryx, podemos elegir si queremos procesar los registros de forma diaria, semanal o mensual. La cantidad de datos dejó de ser un factor, ya que puede ejecutarse a través de este flujo de trabajo en tan solo unos segundos. Además, desarrollar una solución totalmente funcional llevó muy poco tiempo: establecí un borrador del trabajo en unas horas y desde esa etapa inicial, le he hecho solo algunas pequeñas correcciones. Sin la flexibilidad de esta solución de Alteryx, probablemente estaríamos considerando adquirir un programa costoso, desarrollado a la medida por una f
