O tempo para informar en Excel está a desaparecer rapidamente: a tendencia cara a ferramentas convenientes para presentar e analizar información é visible en todas as áreas. Levamos moito tempo discutindo internamente a dixitalización dos informes e escollemos o sistema de visualización e análise de autoservizo de Tableau. Alexander Bezugly, xefe do departamento de solucións analíticas e informes do Grupo M.Video-Eldorado, falou sobre a experiencia e os resultados da construción dun panel de control de combate.
Enseguida direi que non se fixo todo o que estaba previsto, pero a experiencia foi interesante, espero que tamén vos sexa útil. E se alguén ten algunha idea sobre como se podería facer mellor, estaríalle moi agradecido polos seus consellos e ideas.
Debaixo do corte móstrase o que atopamos e o que aprendemos.
Por onde empezamos?
M.Video-Eldorado ten un modelo de datos ben desenvolvido: información estruturada coa profundidade de almacenamento necesaria e un gran número de informes de formato fixo (ver máis detalles ). A partir destes, os analistas fan táboas dinámicas ou boletíns con formato en Excel, ou fermosas presentacións de PowerPoint para usuarios finais.
Hai uns dous anos, en lugar de informes de formato fixo, comezamos a crear informes analíticos en SAP Analysis (un complemento de Excel, esencialmente unha táboa dinámica sobre o motor OLAP). Pero esta ferramenta non foi capaz de satisfacer as necesidades de todos os usuarios; a maioría continuou utilizando información procesada adicionalmente polos analistas.
Os nosos usuarios finais divídense en tres categorías:
Alta dirección. Solicita información de forma ben presentada e claramente comprensible.
Mandos medios, usuarios avanzados. Interesado na exploración de datos e capaz de crear informes de forma independente se hai ferramentas dispoñibles. Convertéronse nos principais usuarios dos informes analíticos en SAP Analysis.
Usuarios masivos. Non lles interesa analizar datos de forma independente, utilizan informes cun grao de liberdade limitado, en formato de boletíns e táboas dinámicas en Excel.
A nosa idea era cubrir as necesidades de todos os usuarios e darlles unha única ferramenta cómoda. Decidimos comezar pola alta dirección. Necesitaban paneis de mando fáciles de usar para analizar os principais resultados empresariais. Entón, comezamos con Tableau e primeiro escollemos dúas direccións: indicadores de venda polo miúdo e en liña con profundidade e amplitude de análise limitadas, que cubrirían aproximadamente o 80% dos datos solicitados pola alta dirección.
Dado que os usuarios dos paneis eran a alta dirección, apareceu outro KPI adicional do produto: a velocidade de resposta. Ninguén esperará 20-30 segundos para que se actualicen os datos. A navegación debería realizarse en 4-5 segundos, ou mellor aínda, ao instante. E nós, por desgraza, non conseguimos isto.
Este é o deseño do noso panel principal:
A idea fundamental é combinar os principais indicadores de KPI, dos cales eran 19 en total, á esquerda e presentar a súa dinámica e desglose por atributos principais á dereita. A tarefa parece sinxela, a visualización é lóxica e comprensible, ata mergullarse nos detalles.
Detalle 1. Volume de datos
A nosa táboa principal de vendas anuais ocupa uns 300 millóns de filas. Dado que é necesario reflectir a dinámica do ano pasado e do ano anterior, só o volume de datos sobre as vendas reais é duns 1 millóns de liñas. A información sobre os datos planificados e o bloque de vendas en liña tamén se almacenan por separado. Polo tanto, aínda que utilizamos o DB SAP HANA en memoria columnar, a velocidade da consulta coa selección de todos os indicadores durante unha semana desde o almacenamento actual sobre a marcha foi duns 15-20 segundos. A solución a este problema suxire por si mesma: materialización adicional de datos. Pero tamén ten trampas, máis sobre elas a continuación.
Detalle 2. Indicadores non aditivos
Moitos dos nosos KPI están vinculados ao número de recibos. E este indicador representa COUNT DISTINCT do número de filas (comprobación de cabeceiras) e mostra diferentes cantidades dependendo dos atributos seleccionados. Por exemplo, como se debe calcular este indicador e a súa derivada:
Para facer os seus cálculos correctos, pode:
- Calcula tales indicadores sobre a marcha no almacenamento;
- Realiza cálculos sobre todo o volume de datos en Tableau, é dicir. previa solicitude en Tableau, proporcione todos os datos segundo os filtros seleccionados na granularidade da posición do recibo;
- Crear un escaparate materializado no que se calcularán todos os indicadores en todas as opcións de mostra que dean diferentes resultados non aditivos.
Está claro que no exemplo UTE1 e UTE2 son atributos materiais que representan a xerarquía do produto. Isto non é algo estático, a xestión dentro da empresa realízase a través dela, porque Distintos xestores son responsables de diferentes grupos de produtos. Tivemos moitas revisións globais desta xerarquía, cando todos os niveis cambiaron, cando se revisaron as relacións e cambios constantes de puntos, cando un grupo se movía dun nodo a outro. No informe convencional, todo isto calcúlase sobre a marcha a partir dos atributos do material; no caso de materializar estes datos, é necesario desenvolver un mecanismo para rastrexar tales cambios e recargar automaticamente os datos históricos. Unha tarefa moi pouco trivial.
Detalle 3. Comparación de datos
Este punto é semellante ao anterior. A conclusión é que ao analizar unha empresa, é habitual establecer varios niveis de comparación co período anterior:
Comparación co período anterior (día a día, semana a semana, mes a mes)
Nesta comparación, suponse que dependendo do período seleccionado polo usuario (por exemplo, a semana 33 do ano), deberíamos mostrar a dinámica ata a semana 32; se seleccionamos os datos dun mes, por exemplo, maio. , entón esta comparación mostraría a dinámica ata abril.
Comparación co ano pasado
O matiz principal aquí é que ao comparar por día e por semana, non estás tomando o mesmo día do ano pasado, é dicir. non podes poñer só o ano actual menos un. Debes mirar o día da semana que estás a comparar. Ao comparar meses, pola contra, cómpre tomar exactamente o mesmo día natural do ano pasado. Tamén hai matices cos anos bisestos. Nos repositorios orixinais, toda a información distribúese por día; non hai campos separados con semanas, meses ou anos. Polo tanto, para obter unha sección transversal analítica completa no panel, cómpre contar non un período, por exemplo unha semana, senón 4 semanas, e despois comparar estes datos, reflectir a dinámica, as desviacións. En consecuencia, esta lóxica para xerar comparacións en dinámicas tamén se pode implementar en Tableau ou no escaparate. Si, e por suposto que coñeciamos e pensamos nestes detalles na fase de deseño, pero era difícil prever o seu impacto no rendemento do cadro de mandos final.
Ao implementar o panel, seguimos o longo camiño Agile. A nosa tarefa consistía en proporcionar unha ferramenta de traballo cos datos necesarios para realizar as probas o máis rápido posible. Por iso, fomos en sprints e partimos de minimizar o traballo no lado do almacenamento actual.
Parte 1: Fe en Tableau
Para simplificar o soporte de TI e implementar cambios rapidamente, decidimos facer a lóxica para calcular indicadores non aditivos e comparar períodos pasados en Tableau.
Etapa 1. Todo está en directo, sen modificacións de ventás.
Nesta fase, conectamos Tableau aos escaparates actuais e decidimos ver como se calcularía o número de recibos dun ano.
Resultado:
A resposta foi deprimente - 20 minutos. Transferencia de datos a través da rede, alta carga en Tableau. Démonos conta de que a lóxica con indicadores non aditivos debe ser implementada en HANA. Isto non nos asustou moito, xa tiñamos unha experiencia similar con BO e Análise e soubemos construír vitrinas rápidas en HANA que producen indicadores non aditivos calculados correctamente. Agora só quedaba axustalos a Tableau.
Etapa 2. Afinamos as vitrinas, sen materialización, todo sobre a marcha.
Creamos un novo escaparate separado que produciu os datos necesarios para TABLEAU sobre a marcha. En xeral, obtivemos un bo resultado; reducimos o tempo de xeración de todos os indicadores nunha semana a 9-10 segundos. E sinceramente esperabamos que en Tableau o tempo de resposta do panel sería de 20-30 segundos na primeira apertura e despois debido á caché de 10 a 12, o que en xeral nos conveña.
Resultado:
Primeiro panel aberto: 4-5 minutos
Calquera clic: 3-4 minutos
Ninguén esperaba tal aumento adicional no traballo do escaparate.
Parte 2. Mergullo en Tableau
Fase 1. Análise do rendemento do cadro e axuste rápido
Comezamos a analizar onde pasa Tableau a maior parte do seu tempo. E hai ferramentas bastante boas para iso, o que, por suposto, é un plus de Tableau. O principal problema que identificamos foron as complexas consultas SQL que estaba a construír Tableau. Estaban asociados principalmente a:
- Transposición de datos. Dado que Tableau non ten ferramentas para transpoñer conxuntos de datos, para construír o lado esquerdo do panel cunha representación detallada de todos os KPI, tivemos que crear unha táboa mediante un caso. O tamaño das consultas SQL na base de datos alcanzou os 120 caracteres.
- elección do período de tempo. Tal consulta a nivel de base de datos levou máis tempo compilar que executar:
Eses. procesamento da solicitude 12 segundos + 5 segundos de execución.
Decidimos simplificar a lóxica de cálculo no lado de Tableau e mover outra parte dos cálculos ao nivel de escaparate e base de datos. Isto trouxo bos resultados.
Primeiro, fixemos a transposición sobre a marcha, fixémola a través dunha unión externa completa na fase final do cálculo VIEW, segundo este enfoque descrito na wiki и .
É dicir, fixemos unha táboa de configuración: unha matriz de transposición (21x21) e recibimos todos os indicadores nun desglose fila por fila.
Foi:
Converteuse en:
Case non se dedica tempo á propia transposición da base de datos. A solicitude de todos os indicadores da semana continuou procesándose nuns 10 segundos. Pero, por outra banda, perdeuse flexibilidade á hora de construír un cadro de mandos baseado nun indicador específico, é dicir. para o lado dereito do panel, onde se presentan a dinámica e a desglose detallada dun indicador específico, anteriormente a xanela de visualización funcionaba en 1-3 segundos, porque a solicitude baseouse nun indicador, e agora a base de datos sempre seleccionaba todos os indicadores e filtraba o resultado antes de devolver o resultado a Tableau.
Como resultado, a velocidade do panel diminuíu case 3 veces.
Resultado:
- 5 segundos: analizando paneis, visualizacións
- 15-20 segundos: preparación para compilar consultas coa realización de cálculos previos en Tableau
- 35-45 seg: compilación de consultas SQL e a súa execución secuencial paralela en Hana
- 5 segundos: procesamento de resultados, clasificación, recalculación de visualizacións en Tableau
- Por suposto, tales resultados non se adaptaron ao negocio e seguimos coa optimización.
Etapa 2. Lóxica mínima en Tableau, materialización completa
Entendemos que era imposible construír un panel de control cun tempo de resposta de varios segundos nun escaparate que se executa durante 10 segundos e consideramos opcións para materializar datos no lado da base de datos especificamente para o panel necesario. Pero atopamos un problema global descrito anteriormente: os indicadores non aditivos. Non puidemos asegurarnos de que ao cambiar os filtros ou os desgloses, Tableau cambiase de forma flexible entre diferentes escaparates e niveis deseñados previamente para diferentes xerarquías de produtos (no exemplo, tres consultas sen UTE, con UTE1 e UTE2 xeran resultados diferentes). Por iso, decidimos simplificar o panel, abandonar a xerarquía de produtos no panel e ver o rápido que podería ser nunha versión simplificada.
Entón, nesta última etapa, montamos un repositorio separado no que engadimos todos os KPI en forma transposta. No lado da base de datos, calquera solicitude para este almacenamento procédese en 0,1 - 0,3 segundos. No panel recibimos os seguintes resultados:
Primeira apertura: 8-10 segundos
Calquera clic: 6-7 segundos
O tempo empregado por Tableau consiste en:
- 0,3 seg. — análise de panel e compilación de consultas SQL
- 1,5-3 seg. — execución de consultas SQL en Hana para visualizacións principais (execútase en paralelo co paso 1)
- 1,5-2 seg. — renderizado, recálculo de visualizacións
- 1,3 seg. — execución de consultas SQL adicionais para obter valores de filtro relevantes (marca, división, cidade, tenda), analizando resultados
Para resumilo brevemente
Gustounos a ferramenta Tableau desde a perspectiva da visualización. Na fase de creación de prototipos, consideramos varios elementos de visualización e atopamos todos nas bibliotecas, incluíndo a segmentación complexa de varios niveis e a fervenza de varios controladores.
Mentres implementamos paneis con indicadores clave de vendas, atopamos dificultades de rendemento que aínda non puidemos superar. Pasamos máis de dous meses e recibimos un panel funcionalmente incompleto, cuxa velocidade de resposta está a piques de ser aceptable. E sacamos conclusións por nós mesmos:
- Tableau non pode funcionar con grandes cantidades de datos. Se no modelo de datos orixinal tes máis de 10 GB de datos (aproximadamente 200 millóns X 50 filas), entón o panel de control diminuirase seriamente - de 10 segundos a varios minutos por cada clic. Experimentamos tanto coa conexión en directo como coa extracción. A velocidade de funcionamento é comparable.
- Limitación ao utilizar varios almacenamentos (conxuntos de datos). Non hai forma de indicar a relación entre conxuntos de datos utilizando medios estándar. Se usas solucións alternativas para conectar conxuntos de datos, isto afectará moito o rendemento. No noso caso, consideramos a opción de materializar os datos en cada sección de vista requirida e de activar estes conxuntos de datos materializados conservando os filtros seleccionados anteriormente; isto resultou imposible de facer en Tableau.
- Non é posible crear parámetros dinámicos en Tableau. Non pode encher un parámetro que se utiliza para filtrar un conxunto de datos nun extracto ou durante a conexión en directo co resultado doutra selección do conxunto de datos ou o resultado doutra consulta SQL, só a entrada de usuario nativa ou unha constante.
- Limitacións asociadas á creación dun panel con elementos OLAP|PivotTable.
En MSTR, SAP SAC, SAP Analysis, se engade un conxunto de datos a un informe, todos os obxectos del están relacionados entre si de forma predeterminada. Tableau non ten isto; a conexión debe configurarse manualmente. Probablemente sexa máis flexible, pero para todos os nosos paneis este é un requisito obrigatorio para os elementos, polo que se trata de custos laborais adicionais. Ademais, se realizas filtros relacionados para que, por exemplo, ao filtrar unha rexión, a lista de cidades se limite só ás cidades desta rexión, inmediatamente acabas con consultas sucesivas á base de datos ou Extracto, o que ralentiza notablemente o panel de control. - Limitacións nas funcións. Non se poden facer transformacións en masa nin no extracto nin, ESPECIALMENTE, no conxunto de datos de Live-connecta. Isto pódese facer a través de Tableau Prep, pero é un traballo adicional e outra ferramenta para aprender e manter. Por exemplo, non pode transpoñer datos nin unilos consigo mesmo. O que se pecha mediante transformacións en columnas ou campos individuais, que deben seleccionarse mediante maiúsculas ou se, e isto xera consultas SQL moi complexas, nas que a base de datos pasa a maior parte do seu tempo compilando o texto da consulta. Esta inflexibilidade da ferramenta tivo que resolverse a nivel de escaparate, o que leva a un almacenamento máis complexo, descargas adicionais e transformacións.
Non renunciamos a Tableau. Pero non consideramos Tableau como unha ferramenta capaz de construír paneis industriais e unha ferramenta coa que substituír e dixitalizar todo o sistema de informes corporativos dunha empresa.
Agora estamos desenvolvendo activamente un panel de control similar noutra ferramenta e, ao mesmo tempo, intentamos revisar a arquitectura do panel en Tableau para simplificalo aínda máis. Se a comunidade está interesada, contarémosche os resultados.
Tamén esperamos as túas ideas ou consellos sobre como en Tabeau podes construír paneis de mando rápidos sobre volumes de datos tan grandes, porque temos un sitio web onde hai moitos máis datos que no comercio polo miúdo.
Fonte: www.habr.com