El tiempo de generación de informes en Excel se está agotando rápidamente: la tendencia de herramientas convenientes para presentar y analizar información es visible en todas las áreas. Durante mucho tiempo hemos discutido dentro de la digitalización de la creación de informes y hemos elegido el sistema de visualización y análisis de autoservicio de Tableau. Alexander Bezugly, jefe del departamento de soluciones analíticas y de informes del Grupo M. Video-Eldorado, habló sobre la experiencia y los resultados de la construcción de un tablero de combate.Debo decir de inmediato que no se realizó todo lo planeado, pero la experiencia fue interesante, espero que les sea útil también. Y si a alguien se le ocurren ideas sobre cómo mejorar, estaré muy agradecido por los consejos e ideas.
Debajo del corte sobre lo que encontramos y lo que aprendimos.
Por donde empezamos
"M. Video-Eldorado" tiene un modelo de datos bien desarrollado: información estructurada con la profundidad de almacenamiento requerida y una gran cantidad de informes de forma fija (consulte
este artículo para más detalles). De estos, los analistas hacen tablas dinámicas o correos formateados en Excel, o hermosas presentaciones en PowerPoint para 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, de hecho, una tabla dinámica sobre el motor OLAP). Pero esta herramienta no fue capaz de cerrar las necesidades de todos los usuarios, la mayoría de ellos continuaron utilizando información procesada adicionalmente por analistas.
Nuestros usuarios finales se dividen en tres categorías:
Alta gerencia . Solicita información en una forma bien presentada y claramente comprensible.
Gestión media , usuarios avanzados. Interesado en investigar datos y capaz de generar informes de forma independiente con herramientas. Se convirtieron en los usuarios clave de informes analíticos en SAP Analysis.
Usuarios masivos . No está interesado en el autoanálisis de datos, use informes con un grado limitado de libertad, en el formato de boletines y tablas dinámicas en Excel.
Nuestra idea era cubrir las necesidades de todos los usuarios y darles una herramienta conveniente única. Decidieron comenzar con la alta gerencia. Necesitaban paneles de control convenientes para analizar los resultados comerciales clave. Entonces, comenzamos con Tableau y para empezar elegimos dos áreas: ventas minoristas y ventas en línea con una profundidad y amplitud de análisis limitadas, que cubrirían aproximadamente el 80% de los datos solicitados por la alta gerencia.
Como los usuarios de los paneles eran de alta dirección, apareció otro KPI adicional del producto: la velocidad de respuesta. Nadie esperará 20-30 segundos hasta que se actualicen los datos. La navegación tuvo que encajar en 4-5 segundos, y fue mejor hacer ejercicio al instante. Y, por desgracia, no logramos esto.
Así es como se veía nuestro diseño de tablero básico:
La idea clave es combinar los principales controladores de KPI, de los cuales hay 19 al final, a la izquierda y presentar su dinámica y un desglose de los atributos principales a la derecha. La tarea parece sencilla, la visualización es lógica y comprensible, hasta que entras en los detalles.
Detalle 1. Volumen de datos
La tabla de ventas principal para el año ocupa unos 300 millones de filas. Dado que es necesario reflejar la dinámica del último y el año anterior, la cantidad de datos sobre las ventas reales es de aproximadamente mil millones de líneas. Y la información sobre los datos planificados y una unidad de ventas en línea también se almacenan por separado. Por lo tanto, aunque utilizamos la base de datos en memoria de SAP HANA en memoria, la velocidad de consulta con la selección de todos los indicadores durante una semana desde el almacenamiento actual sobre la marcha fue de aproximadamente 15-20 segundos. La solución a este problema se sugiere a sí misma: materialización de datos adicional. Pero también tiene dificultades, sobre ellas a continuación.
Parte 2. Indicadores no aditivos
Tenemos muchos KPI vinculados a la cantidad de cheques. Y este indicador es un COUNT DISTINCT del número de líneas (encabezados de recibo) y muestra diferentes cantidades según los atributos seleccionados. Por ejemplo, cómo se debe considerar este indicador y su derivada:
Para la exactitud de los cálculos, puede:
- Realice el cálculo de tales indicadores sobre la marcha en el almacenamiento;
- Calcule la cantidad total de datos en Tableau, es decir previa solicitud, en Tableau, proporcione todos los datos para los filtros seleccionados en la granularidad de la posición de verificación;
- Para hacer un escaparate materializado en el que todos los indicadores se calcularán en todas las variantes de muestras dando diferentes resultados no aditivos.
Está claro que en el ejemplo UTE1 y UTE2 son atributos materiales que representan la jerarquía del producto. Esto no es algo estático, a través de él pasa la gestión dentro de la empresa, porque diferentes grupos de productos son responsables de diferentes gerentes. Tuvimos muchas revisiones globales de esta jerarquía, cuando todos los niveles cambiaron, cuando se revisaron las correlaciones y los cambios constantes de puntos, cuando un grupo se mueve de un nodo a otro. En los informes ordinarios, todo esto se considera sobre la marcha desde los atributos del material, en el caso de materialización de estos datos, es necesario desarrollar un mecanismo para rastrear dichos cambios y sobrecargar automáticamente los datos históricos. Una tarea muy no trivial.
Detalle 3. Comparación de datos
Este artículo es similar al anterior. La conclusión es que cuando se analiza una empresa, es habitual 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 en la semana 32, si seleccionamos datos para el mes, por ejemplo, mayo, esta comparación mostrará la dinámica en abril.
Comparación con el año pasado.Aquí la advertencia principal es que cuando se compara por día y por semana, no está tomando el mismo día del último año, es decir no puedes simplemente poner el año actual menos uno. Tienes que ver el día comparado de la semana. Y al comparar meses, por el contrario, debe tomar exactamente el mismo día calendario del año pasado. También hay matices con los años bisiestos. En los repositorios de origen, toda la información se distribuye por día, no hay campos separados con semanas, meses, años. Por lo tanto, para obtener una porción analítica completa en el panel, es necesario considerar no un período, por ejemplo, una semana, sino 4 semanas, y luego estos datos deben compararse, reflejar la dinámica, las desviaciones. En consecuencia, esta lógica de formar comparaciones en dinámica también se puede implementar en Tableau o en el lateral de la tienda. Sí, y por supuesto, sabíamos y pensábamos sobre estos detalles en la etapa de diseño, pero su impacto en el rendimiento del tablero final fue difícil de predecir.
Con la introducción del tablero, seguimos un largo camino ágil. Nuestra tarea consistía en proporcionar una herramienta de trabajo con los datos necesarios para realizar las pruebas lo más rápido posible. Por lo tanto, fuimos a sprints y comenzamos a minimizar el trabajo en el lado del almacenamiento actual.
Parte 1. Fe en el cuadro
Para simplificar el soporte de TI e implementar cambios rápidamente, decidimos hacer la lógica para calcular indicadores no aditivos y comparar períodos pasados en Tableau.
Etapa 1. Todo en vivo, sin mejoras de escaparatismo.
En este punto, conectamos Tableau a los escaparates actuales y decidimos ver cómo se contará la cantidad de cheques en un año.
Resultado:La respuesta fue deprimente: 20 minutos. Destilación de datos de red, alta carga en Tableau. Nos dimos cuenta de que la lógica con métricas no aditivas debe implementarse en HANA. Esto no nos asustó mucho, ya teníamos una experiencia similar con BO y Analysis y pudimos crear exhibiciones rápidas en HANA que producen indicadores no aditivos calculados correctamente. Ahora quedaba por ajustarlos bajo Tableau.
Etapa 2. Ajustamos las ventanas, sin materialización, todo está sobre la marcha.
Hicimos un nuevo escaparate por separado, que sobre la marcha produjo los datos necesarios para TABLEAU. En general, obtuvimos un buen resultado, redujimos el tiempo de formación de todos los indicadores en una semana a 9-10 segundos. Y, sinceramente, esperábamos que en Tableau el tiempo de respuesta del tablero fuera de 20-30 segundos en la primera apertura y luego debido al caché de 10 a 12, que en general sería adecuado para nosotros.
Resultado:Primer tablero abierto: 4-5 minutos
Cualquier clic: 3-4 minutos
Nadie esperaba tal aumento adicional al trabajo del escaparate.
Parte 2. Inmersión en Tableau
Etapa 1. Análisis de rendimiento de Tableau y ajuste rápido
Comenzamos a analizar en qué gasta Tableau la mayor parte del tiempo. Y para esto hay un conjunto de herramientas bastante bueno, que, por supuesto, es más Tableau. El principal problema que identificamos fueron las consultas SQL muy complejas que Tableau creó. Se asociaron principalmente con:
- transposición de datos. Dado que Tableau no tiene herramientas para transponer conjuntos de datos, para construir el lado izquierdo del tablero con una vista detallada de todos los KPI, tuvimos que crear una tabla a través de mayúsculas y minúsculas. El tamaño de las consultas SQL en la base de datos alcanzó los 120,000 caracteres.
- la elección del período de tiempo. Dicha consulta a nivel de base de datos tardó más en compilarse que en ejecutarse:
Es decir Solicitud de procesamiento de 12 segundos + 5 segundos de ejecución.
Decidimos simplificar la lógica de los cálculos en el lado de Tableau y transferir una parte más de los cálculos al escaparate y al nivel de la base de datos. Trajo buenos resultados.
Primero, realizamos la transposición sobre la marcha, realizamos una unión externa completa en la etapa final del cálculo VIEW, de acuerdo con este enfoque descrito en el wiki
Transpose - Wikipedia, la enciclopedia libre y
Matriz elemental - Wikipedia, la enciclopedia libre .
Es decir, creamos una tabla de ajuste: la matriz de transposición (21x21) y obtuvimos todos los indicadores en un desglose fila por línea.
Fue:
Se convirtió en:
El DB en sí apenas pasa tiempo transponiéndose a sí mismo. La solicitud de todos los indicadores para la semana se cumplió como antes en aproximadamente 10 segundos. Pero, por otro lado, la flexibilidad en términos de construir un tablero de instrumentos mediante un indicador específico, es decir, para el lado derecho del tablero donde se presenta la dinámica y un desglose detallado de un indicador específico, el escaparate funcionó en 1-3 segundos antes, porque la consulta se realizó en un indicador, y ahora la base de datos siempre seleccionó todos los indicadores y filtró el resultado antes de devolver el resultado a Tableau.
Como resultado, la velocidad del tablero se redujo en casi 3 veces.
Resultado:- 5 segundos: análisis de paneles, visualizaciones
- 15-20 segundos: preparación para la compilación de consultas con ejecución de precalculaciones en Tableau
- 35-45 segundos: compilación de consultas SQL y su ejecución secuencial paralela en Hana
- 5 segundos: resultados de procesamiento, clasificación, recálculo de visualizaciones en Tableau
- Por supuesto, tales resultados no se adaptaron al negocio, y continuamos optimizando.
Etapa 2. Lógica mínima en Tableau, materialización completa.
Entendimos que era imposible construir un tablero con un tiempo de respuesta de varios segundos en una ventana de la tienda que funcionó durante 10 segundos, y consideramos opciones para materializar datos en el lado de la base de datos específicamente para el tablero requerido. Pero ante el problema global descrito anteriormente: indicadores no aditivos. No pudimos lograr que, al cambiar los filtros o los escaneos, Tableau cambiara flexiblemente entre diferentes escaparates y niveles calculados para diferentes jerarquías de productos (en el ejemplo, tres consultas sin UTE, con UTE1 y UTE2 forman resultados diferentes). Por lo tanto, decidimos simplificar el tablero, abandonar la jerarquía del producto en el tablero y ver qué tan rápido puede ser en la versión simplificada.
Entonces, en esta última etapa, armamos un repositorio separado en el que se transpusieron todos los KPI. En el lado de la base de datos, cualquier solicitud a dicho repositorio se cumple 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 pasa Tableau consiste en:
- 0,3 segundos - análisis de paneles y compilación de consultas SQL
- 1.5-3 seg. - ejecución de consultas SQL en Hana para visualizaciones básicas (comienza en paralelo con el punto 1)
- 1.5-2 seg. - renderizado, recálculo de visualizaciones
- 1.3 segundos - ejecución de consultas SQL adicionales para obtener valores de filtro relevantes (marca, división, ciudad, tienda), análisis de resultados
Para resumir
Nos gustó la herramienta Tableau en términos de visualización. En la etapa de creación de prototipos, examinamos varios elementos de visualización y los encontramos en bibliotecas, incluidas segmentaciones complejas de varios niveles y cascada de controladores múltiples.
Al presentar paneles con indicadores clave de ventas, nos encontramos con dificultades de rendimiento que aún no podíamos superar. Pasamos más de dos meses y obtuvimos un tablero funcionalmente incompleto, cuya velocidad de respuesta está al borde de lo permisible. Y para mí, concluimos:
- Tableau no sabe cómo trabajar con grandes cantidades de datos. Si en el modelo de datos original tiene más de 10 GB de datos (aproximadamente 200 millones de líneas X 50), el panel de control se ralentiza considerablemente, de 10 segundos a varios minutos por clic. Experimentamos con live-connect y extract. La velocidad del trabajo es comparable.
- Restricción cuando se usan varios almacenamientos (conjuntos de datos). No hay forma de indicar la relación de los conjuntos de datos utilizando herramientas estándar. Si utiliza soluciones alternativas para conectar conjuntos de datos, esto afectará en gran medida el rendimiento. En nuestro caso, consideramos la opción de materializar datos en cada sección deseada de representaciones, y en estos conjuntos de datos materializados para hacer el cambio con guardar los filtros seleccionados previamente, esto resultó imposible de hacer en Tableau.
- En Tableau, no es posible hacer parámetros dinámicos. No puede usar el parámetro que se usa para filtrar el conjunto de datos en el extracto, ya sea durante la conexión en vivo, para completar el resultado de otra selección del conjunto de datos o el resultado de otra consulta SQL, solo entrada de usuario nativo o constante.
- Limitaciones asociadas con la creación de un panel con elementos OLAP | PivotTable.
En MSTR, SAP SAC, SAP Analysis, si agrega un conjunto de datos a un informe, todos los objetos en él están conectados entre sí de manera predeterminada. En Tableau esto no es así, la conexión debe configurarse manualmente. Probablemente sea más flexible, pero para todos nuestros paneles de instrumentos, este es un requisito obligatorio para los elementos, por lo que se trata de un costo laboral adicional. Además, si realiza filtros relacionados para que, por ejemplo, al filtrar una región, la lista de ciudades se limite solo a las ciudades de esta región, recibirá inmediatamente consultas consecutivas a la base de datos o extracto, lo que ralentiza notablemente el tablero. - Restricciones de funciones. Tanto sobre el extracto como MÁS QUE sobre el conjunto de datos de Live-connecta no puede hacer conversiones masivas. Esto se puede hacer a través de Tableau Prep, pero esta es una mano de obra adicional y otra herramienta que necesita ser estudiada y mantenida. Usted, por ejemplo, no puede transponer datos, hacer que se unan. Lo que se cierra a través de transformaciones en columnas o campos individuales que deben seleccionarse a través de mayúsculas y minúsculas y si esto genera consultas SQL muy complejas, en las que la base de datos pasa la mayor parte del tiempo compilando el texto de la consulta. Estas rigideces de los instrumentos tuvieron que resolverse a nivel de tienda, lo que conduce a un almacenamiento más complicado, cargas adicionales y transformaciones.
No pusimos fin a Tableau. Pero como una herramienta que puede construir paneles industriales y una herramienta con la que puede reemplazar y digitalizar todo el sistema de informes corporativos de la compañía, Tableau no se considera.
Ahora estamos desarrollando activamente un tablero similar en otra herramienta y, en paralelo, estamos tratando de revisar la arquitectura del tablero en Tableau para simplificarlo aún más. Si la comunidad está interesada, le informaremos sobre los resultados.
También estamos esperando sus ideas o consejos sobre cómo Tabeau puede construir tableros rápidos sobre volúmenes de datos tan grandes, porque también tenemos un sitio web donde hay muchos más datos que en el comercio minorista.