El tiempo de informes en Excel está desapareciendo rápidamente; se observa una tendencia hacia herramientas cómodas para la presentación y análisis de información en todos los campos. Hemos estado discutiendo durante mucho tiempo la digitalización de la creación de informes y elegimos el sistema de visualización y análisis autogestionado Tableau. Alexander Bezugly, jefe del departamento de soluciones analíticas e informes del Grupo "M.Video-Eldorado", compartió experiencias y resultados sobre la creación de un panel de control operativo.
Digo de inmediato, no todo lo que se planeó se pudo realizar, pero la experiencia fue interesante, espero que también les pueda resultar útil. Y si alguien tiene ideas sobre cómo se podría haber hecho mejor, agradecería mucho los consejos y las ideas.
Abajo se habla sobre lo que encontramos y lo que aprendimos.
Por dónde empezamos
En "M.Video-Eldorado" existe un modelo de datos bien elaborado: información estructurada con la profundidad de almacenamiento requerida y una enorme cantidad de informes de forma fija (ver más detalles ). De ellos, los analistas crean bien tablas dinámicas o envíos formateados en Excel, o presentaciones atractivas en PowerPoint para los usuarios finales.
Hace aproximadamente dos años, en lugar de informes de forma fija, comenzamos a crear informes analíticos en SAP Analysis (un complemento para Excel, en esencia, una tabla dinámica sobre un motor OLAP). Pero esta herramienta no pudo satisfacer las necesidades de todos los usuarios; la mayoría siguió utilizando la información procesada por los analistas.
Nuestros usuarios finales se dividen en tres categorías:
Alta dirección. Solicitan información de manera bien presentada y fácil de entender.
Gerentes intermedios, usuarios avanzados. Están interesados en el análisis de datos y son capaces de generar informes de forma autónoma si tienen las herramientas. Son ellos quienes se convirtieron en los usuarios clave de los informes analíticos en SAP Analysis.
Usuarios masivos. No están interesados en el análisis autónomo de datos, utilizan informes con un grado limitado de libertad, en forma de envíos y tablas dinámicas en Excel.
Nuestra idea era atender las necesidades de todos los usuarios y proporcionarles una herramienta única y conveniente. Decidimos comenzar con la alta dirección. Necesitaban paneles accesibles para analizar los principales resultados de negocio. Así, comenzamos con Tableau y, en un principio, elegimos dos áreas: las métricas de ventas en retail y online, con un análisis limitado en profundidad y amplitud, que cubriría aproximadamente el 80% de los datos solicitados por la alta dirección.
Dado que los usuarios de los paneles eran la alta dirección, surgió un KPI adicional para el producto: la velocidad de respuesta. Nadie va a esperar 20-30 segundos mientras se actualizan los datos. La navegación debía completarse en 4-5 segundos, o mejor aún, funcionar de manera instantánea. Lamentablemente, no conseguimos lograrlo.
Así es como se veía el diseño de nuestro panel principal:
La idea clave es combinar los principales impulsores de KPI, que en total sumaron 19, a la izquierda y presentar su dinámica y desglose según los principales atributos a la derecha. La tarea parece sencilla, la visualización lógica y clara, hasta que te sumerges en los detalles.
Detalle 1. Volumen de datos
La tabla principal de ventas del año ocupa aproximadamente 300 millones de filas. Dado que es necesario reflejar la dinámica con respecto al año pasado y al anterior, el volumen de datos solo para ventas reales es de alrededor de 1 mil millones de filas. Además, se almacena por separado la información sobre datos planificados y un bloque de ventas en línea. Por lo tanto, a pesar de que utilizamos la base de datos in-memory columnar SAP HANA, la velocidad de la consulta seleccionando todas las métricas para una semana desde los almacenes actuales era de aproximadamente 15-20 segundos. La solución a este problema parece evidente: materialización adicional de datos. Pero también hay trampas en ello, que se describen a continuación.
Detalle 2. Indicadores no aditivos
Muchos de nuestros KPI están vinculados al número de recibos. Este indicador representa un COUNT DISTINCT de la cantidad de filas (encabezados de recibos) y muestra diferentes sumas dependiendo de los atributos seleccionados. Para ilustrar, así es como este indicador y sus derivados deberían ser calculados:
Para garantizar la corrección de los cálculos se puede:
- Realizar el cálculo de dichos indicadores al instante en el almacén;
- Realizar el cálculo sobre todo el volumen de datos en Tableau, es decir, en una consulta a Tableau entregar todos los datos según los filtros seleccionados a nivel de posición de los recibos;
- Crear una vitrina materializada que calcule todos los indicadores en todas las variantes de muestreo, que den diferentes resultados no aditivos.
Es claro que en el ejemplo UTE1 y UTE2 son atributos del material que representan la jerarquía de productos. No es algo estático, a través de esto se gestiona dentro de la empresa, ya que diferentes gerentes son responsables de diferentes grupos de productos. Hemos realizado muchas revisiones globales de esta jerarquía, donde cambiaron todos los niveles, se revisaron las interrelaciones, así como cambios puntuales constantes, cuando un grupo pasa de un nodo a otro. En los informes estándar, todo esto se calcula al instante a partir de los atributos del material, en caso de materialización de estos datos, es necesario desarrollar un mecanismo para rastrear tales cambios y recargar automáticamente los datos históricos. Es una tarea bastante no trivial.
Detalle 3. Comparación de datos
Este punto es similar al anterior. La esencia es que en la empresa, durante el análisis, se tiende a formar varios niveles de comparación con el período anterior:
Comparación con el período anterior (día a día, semana a semana, mes a mes)
En esta comparación se supone que, dependiendo del período elegido por el usuario (por ejemplo, la semana 33 del año), debemos mostrar la dinámica respecto a la semana 32; si hubiéramos elegido datos del mes, por ejemplo, de mayo, esta comparación mostraría la dinámica respecto a abril.
Comparación con el año pasado
Aquí la clave es que al comparar por días y por semanas no tomas el mismo día del año pasado, es decir, no puedes simplemente poner el año actual menos uno. Debes observar el mismo día de la semana en la comparación. Por otro lado, al comparar meses, necesitas tomar exactamente el mismo día del calendario del año pasado. También hay consideraciones con los años bisiestos. En los almacenes originales, toda la información está distribuida por días, no hay campos separados para semanas, meses o años. Por lo tanto, para obtener un análisis completo en el panel, necesitarás contar no un solo período, por ejemplo una semana, sino 4 semanas, y luego comparar estos datos para reflejar la dinámica y las desviaciones. Por lo tanto, esta lógica de formación de comparación dinámica también se puede implementar ya sea en Tableau o en el lado del front-end. Y, por supuesto, conocíamos y pensábamos en estos detalles desde la fase de diseño, pero fue difícil pronosticar su impacto en el rendimiento del tablero final.
Al implementar el tablero, seguimos un largo camino ágil. Nuestra tarea era proporcionar lo más rápido posible una herramienta funcional para pruebas con los datos necesarios. Por lo tanto, trabajamos en sprints y nos enfocamos en minimizar el trabajo en el almacén actual.
Parte 1. La Creencia en Tableau
Para simplificar el soporte de TI y la rápida implementación de cambios, decidimos hacer la lógica de cálculo de indicadores no aditivos y la comparación de períodos anteriores en Tableau.
Etapa 1. Todo en Vivo, sin mejoras de front-end.
En esta etapa, conectamos Tableau a las vitrinas actuales y decidimos observar cómo se calcularía el número de recibos en un año.
Resultado:
La respuesta fue desalentadora: 20 minutos. La transferencia de datos a través de la red, alta carga en Tableau. Nos dimos cuenta de que la lógica de indicadores no aditivos necesitaba implementarse en HANA. Esto no nos asustó mucho, ya que ya teníamos experiencia con BO y Analysis y sabíamos cómo construir vitrinas rápidas en HANA que proporcionan correctamente los indicadores no aditivos. Ahora solo quedaba ajustarlas para Tableau.
Etapa 2. Afinamos las vitrinas, sin materialización, todo al vuelo.
Hemos creado una nueva vitrina separada, que proporcionaba los datos requeridos para TABLEAU al instante. En general, logramos un buen resultado, reduciendo el tiempo de formación de todos los indicadores de una semana a 9-10 segundos. Honestamente, esperábamos que en Tableau el tiempo de respuesta del tablero fuera de 20-30 segundos en la primera apertura y luego, gracias a la caché, de 10 a 12, lo que en general nos hubiera satisfecho.
Resultado:
Primeras aperturas del tablero: 4-5 minutos
Cualquier clic: 3-4 minutos
Nadie esperaba tal mejora en el rendimiento de la vitrina.
Parte 2. Inmersión en Tableau
Etapa 1. Análisis del rendimiento de Tableau y ajuste rápido
Comenzamos a analizar en qué gastaba Tableau la mayor parte del tiempo. Y para esto hay herramientas bastante buenas, lo cual es sin duda una ventaja de Tableau. El principal problema que identificamos fueron las consultas SQL muy complejas que construía Tableau. Estas estaban principalmente relacionadas con:
— la transposición de datos. Como Tableau no tiene herramientas para transponer datasets, tuvimos que formar una tabla a través de case para construir la parte izquierda del tablero con una representación detallada de todos los KPI. El tamaño de las consultas SQL en la BD alcanzaba los 120 000 caracteres.
— la selección del período de tiempo. Esta consulta a nivel de BD tomaba más tiempo en compilar que en ejecutar:
Es decir, procesamiento de la consulta 12 segundos + 5 segundos de ejecución.
Decidimos simplificar la lógica de cálculos en el lado de Tableau y trasladar otra parte de los cálculos a la vitrina y al nivel de la BD. Esto trajo buenos resultados.
Primero hicimos la transposición al instante, utilizándola a través de un full outer join en la etapa final del cálculo de VIEW, según este enfoque, descrito en wiki y .
Es decir, creamos una tabla de configuración: una matriz de transposición (21x21) y obtuvimos todos los indicadores en desgloses por fila.
Antes:
Después:
La transposición de la base de datos no consume prácticamente tiempo. La consulta por todos los indicadores de la semana todavía se procesaba en aproximadamente 10 segundos. Sin embargo, se perdió flexibilidad en la construcción del tablero para indicadores específicos, es decir, en la parte derecha del tablero donde se presenta la dinámica y el desglose detallado de un indicador específico. Anteriormente, el dataset se procesaba en 1-3 segundos, ya que la consulta se centraba en un único indicador, pero ahora la base de datos siempre selecciona todos los indicadores y filtra los resultados antes de devolverlos a Tableau.
Como resultado, la velocidad de trabajo del tablero se redujo casi a la mitad.
Resultado:
- 5 seg — análisis del tablero, visualizaciones
- 15-20 seg — preparación para la compilación de consultas con la ejecución de precálculos en Tableau
- 35-45 seg — compilación de consultas SQL y su ejecución secuencial-paralela en Hana
- 5 seg — procesamiento de resultados, ordenación, recálculo de visualizaciones en Tableau
- Por supuesto, tales resultados no satisfacían al negocio, y continuamos con la optimización.
Fase 2. Mínima lógica en Tableau, total materialización.
Entendíamos que construir un tablero con un tiempo de respuesta de unos pocos segundos en una vista que actualmente toma 10 segundos era imposible, y consideramos opciones para materializar datos del lado de la base de datos específicamente para el tablero requerido. Pero nos encontramos con un problema global, descrito anteriormente: indicadores no aditivos. No pudimos hacer que al cambiar filtros o desplegables, Tableau alternara de manera flexible entre diferentes vistas y niveles, precalculados para distintas jerarquías de productos (en el ejemplo, tres consultas sin UTE, con UTE1 y UTE2 generan diferentes resultados). Por lo tanto, tomamos la decisión de simplificar el tablero, renunciando a la jerarquía de productos en el tablero y ver qué tan rápido podría ser en una versión simplificada.
Así, en esta última etapa, recopilamos un almacén separado, en el que almacenamos en forma transpuesta todos los KPI. Desde la base de datos, cualquier consulta a este tipo de almacén se ejecuta en 0,1 – 0,3 segundos. En el tablero obtuvimos los siguientes resultados:
Primera apertura: 8-10 segundos
Cualquier clic: 6-7 segundos
El tiempo que gasta Tableau se compone de:
- 0,3 seg. — análisis del tablero y compilación de consultas SQL
- 1,5-3 seg. — ejecución de consultas SQL en Hana para las principales visualizaciones (se inicia en paralelo con el punto 1)
- 1,5-2 seg. — renderizado, recálculo de visualizaciones
- 1,3 seg. — ejecución de consultas SQL adicionales para obtener valores relevantes de filtros (Marca, División, Ciudad, Tienda), análisis de resultados
Si resumimos brevemente
Nos gustó la herramienta Tableau en términos de visualización. En la etapa de maquetación, examinamos varios elementos de visualización y todos los encontramos en las bibliotecas, incluidas segmentaciones complejas y multi-controladores de waterfall.
Al implementar tableros con indicadores clave de ventas, enfrentamos dificultades de rendimiento que aún no hemos podido superar. Pasamos más de dos meses y obtuvimos un tablero funcionalmente incompleto, cuya velocidad de respuesta está al límite de lo aceptable. Y hemos llegado a las siguientes conclusiones:
- Tableau no puede trabajar con grandes volúmenes de datos. Si en el modelo de datos original tienes más de 10 GB de datos (aproximadamente 200 millones x 50 filas), el tablero se ralentiza gravemente, tardando entre 10 segundos y varios minutos por cada clic. Experimentamos tanto con live-connect como con extractos. La velocidad de funcionamiento es comparable.
- Limitación al usar múltiples almacenes (datasets). No hay forma estándar de establecer la relación entre datasets. Si se utilizan soluciones alternativas para vincular datasets, esto afectará considerablemente el rendimiento. En nuestro caso, consideramos la opción de materializar datos en cada vista necesaria y en estos datasets materializados realizar alternancias conservando los filtros seleccionados anteriormente; esto resultó ser imposible de hacer en Tableau.
- En Tableau no es posible crear parámetros dinámicos. No puedes llenar un parámetro, que se usa para filtrar el dataset en el extracto o al realizar live-connect, con el resultado de otra selección del dataset o el resultado de otra consulta SQL, solo con la entrada nativa del usuario o una constante.
- Limitaciones relacionadas con la construcción de tableros con elementos OLAP|Tablas dinámicas.
En MSTR, SAP SAC, SAP Analysis, si agregas un conjunto de datos al informe, todos los objetos están interconectados por defecto. En Tableau, esto no sucede; la conexión debe configurarse manualmente. Probablemente esto sea más flexible, pero para todos nuestros dashboards es un requisito obligatorio para los elementos, por lo que implica un esfuerzo adicional. Además, si estás haciendo filtros vinculados, para que, por ejemplo, al filtrar por región la lista de ciudades se limite solo a ciudades de esa región, te enfrentas de inmediato a consultas secuenciales a la base de datos o al extracto, lo que ralentiza notablemente el dashboard. - Limitaciones en las funciones. Tanto sobre el extracto como MÁS AÚN sobre el conjunto de datos de Live-connecta no se pueden realizar transformaciones masivas. Esto se puede hacer a través de Tableau Prep, pero eso significa trabajo adicional y otro instrumento que hay que aprender y mantener. Por ejemplo, no puedes transponer datos, ni hacer un join consigo mismo. Esto se cierra a través de transformaciones de columnas o campos individuales, que deben seleccionarse a través de case o if, lo que genera consultas SQL muy complejas, donde la base de datos pasa la mayor parte del tiempo compilando el texto de la consulta. Estas inflexibilidades del instrumento tuvieron que resolverse a nivel de la vitrina, lo que lleva a la complejidad del almacenamiento, cargas adicionales y transformaciones.
No hemos descartado Tableau. Pero como herramienta capaz de construir dashboards industriales y medio para reemplazar y digitalizar todo el sistema de informes corporativos de la empresa, no lo consideramos.
Actualmente estamos desarrollando activamente un dashboard similar en otra herramienta y paralelamente estamos intentando revisar la arquitectura del dashboard en Tableau para simplificarla aún más. Si a la comunidad le interesa, contaremos sobre los resultados.
También esperamos sus ideas o consejos sobre cómo en Tableau se pueden construir dashboards rápidos sobre volúmenes de datos tan grandes, ya que tenemos un sitio donde hay muchos más datos que en el comercio minorista.
Fuente: habr.com
