O tempo de relatórios em Excel está rapidamente desaparecendo — a tendência por ferramentas convenientes de apresentação e análise de informações é evidente em todos os setores. Já discutimos internamente a digitalização da construção de relatórios e escolhemos o sistema de visualização e análise self-service Tableau. Alexander Bezugly, chefe do departamento de soluções analíticas e relatórios do Grupo 'M.Video-Eldorado', compartilhou a experiência e os resultados da construção de um dashboard operacional.
Direi de imediato que nem tudo o que foi pensado foi possível realizar, mas a experiência foi interessante, espero que também seja útil para vocês. E se alguém tiver ideias sobre como poderia ter sido feito melhor — seria muito grato pelas sugestões e ideias.
Abaixo, falaremos sobre o que enfrentamos e o que aprendemos.
Como começamos
No 'M.Video-Eldorado', existe um modelo de dados bem elaborado: informações estruturadas com a profundidade de armazenamento necessária e uma enorme quantidade de relatórios em formato fixo (veja mais detalhes ). Com isso, os analistas produzem ou tabelas dinâmicas ou envios formatados em Excel, ou belas apresentações em PowerPoint para os usuários finais.
Cerca de dois anos atrás, em vez de relatórios em formato fixo, começamos a criar relatórios analíticos no SAP Analysis (um complemento do Excel, na verdade — uma tabela dinâmica sobre um mecanismo OLAP). Mas essa ferramenta não conseguiu atender às necessidades de todos os usuários, a maioria continuou a usar informações processadas adicionalmente pelos analistas.
Nossos usuários finais se dividem em três categorias:
Alta gerência. Solicita informações de forma bem apresentada e visualmente compreensível.
Média gerência, usuários avançados. Estão interessados em explorar dados e são capazes de construir relatórios de forma independente quando possuem as ferramentas. Eles se tornaram os principais usuários de relatórios analíticos no SAP Analysis.
Usuários em massa. Não estão interessados em analisar dados de forma independente, usam relatórios com um grau limitado de liberdade, em formato de envios e tabelas dinâmicas em Excel.
Nossa ideia era atender às necessidades de todos os usuários e fornecer uma única ferramenta conveniente. Começamos com a alta administração. Eles precisavam de painéis úteis para analisar os principais resultados de negócios. Assim, iniciamos com o Tableau e escolhemos duas áreas: indicadores de vendas no varejo e online, com uma profundidade e abrangência limitadas de análise, que cobrissem cerca de 80% dos dados solicitados pela alta administração.
Como os usuários dos dashboards eram a alta administração, surgiu outro KPI adicional do produto – a velocidade de resposta. Ninguém vai esperar 20-30 segundos para que os dados sejam atualizados. A navegação precisava ser concluída em 4-5 segundos, de preferência instantaneamente. E nisso, infelizmente, não conseguimos sucesso.
Assim era o layout do nosso dashboard principal:
A ideia chave era reunir os principais impulsionadores de KPI, que somaram 19 no total, à esquerda e apresentar sua dinâmica e quebra por principais atributos à direita. A tarefa parece simples, a visualização lógica e compreensível, até que mergulhamos nos detalhes.
Detalhe 1. Volume de dados
A tabela principal de vendas do ano contém cerca de 300 milhões de linhas. Como é necessário refletir também a dinâmica do ano passado e do antepenúltimo ano, o volume de dados apenas das vendas reais é de cerca de 1 bilhão de linhas. Além disso, as informações sobre dados planejados e um bloco de vendas online são armazenadas separadamente. Portanto, mesmo utilizando a DB SAP HANA em memória, a velocidade do pedido para selecionar todos os indicadores de uma semana a partir dos atuais repositórios em tempo real era de cerca de 15-20 segundos. A solução para esta tarefa parece óbvia – uma materialização adicional dos dados. Mas também existem armadilhas nessa abordagem, que explicaremos abaixo.
Detalhe 2. Indicadores não aditivos
Muitos de nossos KPIs estão relacionados ao número de recibos. E esse indicador é o COUNT DISTINCT do número de linhas (cabeçalhos dos recibos) e mostra diferentes somas dependendo dos atributos escolhidos. Para exemplificar, como este indicador e os derivados dele devem ser calculados:
Para a correção dos cálculos, é possível:
- Realizar o cálculo desses indicadores em tempo real no repositório;
- Realizar o cálculo sobre todo o volume de dados no Tableau, ou seja, ao solicitar no Tableau, fornecer todos os dados pelos filtros escolhidos na granularidade das posições dos recibos;
- Criar uma vitrine materializada, na qual todos os indicadores serão calculados em todas as variantes de seleção, dando resultados não aditivos diferentes.
É claro que no exemplo UTE1 e UTE2 são atributos do material que representam a hierarquia de produtos. Isso não é uma coisa estática, pois a gestão dentro da empresa é realizada por meio deles, já que diferentes grupos de produtos são gerenciados por diferentes gerentes. Tivemos muitas revisões globais dessa hierarquia, quando todos os níveis mudaram, quando as interconexões foram reavaliadas, assim como mudanças pontuais constantes, quando um grupo passa de um nó para outro. Em relatórios comuns, tudo isso é calculado em tempo real a partir dos atributos do material, no caso da materialização desses dados, é necessário desenvolver um mecanismo para rastrear tais mudanças e reprocessar automaticamente dados históricos. É uma tarefa bastante não trivial.
Item 3. Comparação de dados
Este item é semelhante ao anterior. A essência é que, na empresa, ao analisar, é comum formar vários níveis de comparação com o período anterior:
Comparação com o período anterior (dia a dia, semana a semana, mês a mês)
Nesta comparação, presume-se que, dependendo do período selecionado pelo usuário (por exemplo, a 33ª semana do ano), devemos mostrar a dinâmica em relação à 32ª semana. Se escolhemos dados de um mês, por exemplo, maio, essa comparação mostraria a dinâmica em relação a abril.
Comparação com o ano passado
Aqui, o ponto principal é que, ao comparar por dias e semanas, você não pega o mesmo dia do ano passado, ou seja, não pode simplesmente subtrair um ano do ano atual. Você deve observar o dia da semana que está sendo comparado. Por outro lado, ao comparar meses, é necessário pegar exatamente o mesmo dia calêndario do ano passado. Também existem particularidades com anos bissextos. Nas fontes de dados, todas as informações estão distribuídas por dias; não há campos separados para semanas, meses ou anos. Portanto, para obter uma análise completa no painel, é preciso considerar não apenas um período, como uma semana, mas 4 semanas, e depois comparar esses dados, refletindo a dinâmica e as variações. Assim, essa lógica de formação de comparações dinâmicas pode ser implementada tanto no Tableau quanto do lado da vitrine. Sim, conhecíamos e pensávamos nisso desde a fase de planejamento, mas era difícil prever seu impacto no desempenho do painel final.
Na implementação do painel, seguimos um longo caminho Agile. Nossa tarefa era fornecer um instrumento funcional com os dados necessários para testes o mais rapidamente possível. Por isso, avançamos em sprints e nos baseamos na minimização do trabalho do lado do armazenamento atual.
Parte 1. A fé no Tableau
Para simplificar o suporte de TI e permitir a rápida implementação de mudanças, decidimos implementar a lógica de cálculo de indicadores não aditivos e a comparação de períodos passados no Tableau.
Etapa 1. Tudo em Live, sem personalizações nas vitrines.
Nesta etapa, conectamos o Tableau às vitrines atuais e decidimos ver como seria calculado o número de recibos por um ano.
Resultado:
A resposta foi desanimadora – 20 minutos. A transferência de dados pela rede, juntamente com a alta carga no Tableau, nos fez perceber que a lógica de indicadores não aditivos precisava ser implementada no HANA. Isso não nos assustou muito; já tínhamos experiência semelhante com BO e Analysis e sabíamos como construir vitrines rápidas no HANA que fornecem indicadores não aditivos calculados corretamente. Agora, só precisávamos adaptá-las ao Tableau.
Etapa 2. Ajustamos as vitrines, sem materialização, tudo em tempo real.
Criamos uma nova vitrine separada, que gerava os dados necessários para o TABLEAU em tempo real. De modo geral, conseguimos um bom resultado, reduzindo o tempo de formação de todos os indicadores de uma semana para 9-10 segundos. E, honestamente, esperávamos que, no Tableau, o tempo de resposta do dashboard fosse de 20-30 segundos na primeira abertura e, em seguida, devido ao cache, de 10 a 12, o que nos satisfaria.
Resultado:
Primeira abertura do dashboard: 4-5 minutos
Qualquer clique: 3-4 minutos
Ninguém esperava tal incremento no funcionamento da vitrine.
Parte 2. Mergulho no Tableau
Etapa 1. Análise de desempenho do Tableau e ajuste rápido
Começamos a analisar em que o Tableau estava gastando a maior parte do tempo. E para isso existe um bom conjunto de ferramentas, o que, claro, é um ponto positivo do Tableau. O principal problema que identificamos foram as consultas SQL muito complexas que o Tableau gerava. Elas estavam relacionadas principalmente a:
— transposição de dados. Como o Tableau não tem ferramentas para transpor datasets, para construir a parte esquerda do dashboard com uma representação detalhada de todos os KPIs, tivemos que criar uma tabela via case. O tamanho das consultas SQL no banco de dados alcançava 120.000 caracteres.
— seleção do período de tempo. Essa consulta a nível de banco de dados levava mais tempo para compilar do que para executar:
Ou seja, o processamento da consulta: 12 segundos + 5 segundos de execução.
Decidimos simplificar a lógica de cálculos no lado do Tableau e transferir mais uma parte dos cálculos para a vitrine e o nível do banco de dados. Isso trouxe bons resultados.
Primeiro, realizamos a transposição em tempo real, através de full outer join na etapa final de cálculo da VIEW, de acordo com essa abordagem descrita na wiki e .
Ou seja, criamos uma tabela de configuração – uma matriz de transposição (21x21) e obtivemos todos os indicadores em uma divisão linha a linha.
Era:
Tornou-se:
A transposição da base de dados consome quase nenhum tempo. A consulta para todos os indicadores em uma semana continuou a ser executada em cerca de 10 segundos. No entanto, perdeu-se a flexibilidade na construção do painel para um indicador específico, ou seja, para a parte direita do painel onde é apresentada a dinâmica e a detalhamento de um determinado indicador, antes a vitrine processava em 1-3 segundos, pois a consulta era realizada para um único indicador, mas agora o banco de dados sempre seleciona todos os indicadores e filtra o resultado antes de devolvê-lo ao Tableau.
Como resultado, a velocidade de operação do painel reduziu-se quase em 3 vezes.
Resultado:
- 5 seg — parsing do painel, visualizações
- 15-20 seg — preparação para a compilação das consultas com a execução dos pré-cálculos no Tableau
- 35-45 seg — compilação das consultas SQL e execução simultânea e sequencial delas no Hana
- 5 seg — processamento dos resultados, ordenação, recálculo das visualizações no Tableau
- Claro, tais resultados não eram satisfatórios para o negócio, e continuamos a otimização.
Etapa 2. Mínima lógica no Tableau, completa materialização
Entendemos que construir um painel com tempo de resposta de alguns segundos em uma vitrine que funciona em 10 segundos é impossível, e consideramos opções de materialização dos dados no lado do banco de dados especificamente para o painel necessário. Mas encontramos um problema global, descrito acima – indicadores não aditivos. Não conseguimos fazer com que ao alterar filtros ou desagregações, o Tableau alternasse de maneira flexível entre diferentes vitrines e níveis, pré-calculados para diferentes hierarquias de produtos (no exemplo, três consultas sem UTE, com UTE1 e UTE2 geram resultados diferentes). Portanto, decidimos simplificar o painel, renunciar à hierarquia de produtos no painel e ver quão rápido ele poderia ser em uma versão simplificada.
Assim, nesta última etapa, montamos um armazenamento separado, onde armazenamos todos os KPIs em formato transposto. No lado do banco de dados, qualquer consulta a esse armazenamento é executada em 0,1 – 0,3 segundos. No painel, obtivemos os seguintes resultados:
Primeira abertura: 8-10 segundos
Qualquer clique: 6-7 segundos
O tempo que o Tableau consome é composto por:
- 0,3 seg. — parsing do painel e compilação das consultas SQL
- 1,5-3 seg. — execução das consultas SQL no Hana para as principais visualizações (iniciada paralelamente ao item 1)
- 1,5-2 seg. — renderização, recálculo de visualizações
- 1,3 seg. — execução de consultas SQL adicionais para obter valores relevantes dos filtros (Marca, Divisão, Cidade, Loja), análise de resultados
Se resumirmos brevemente
Gostamos da ferramenta Tableau em termos de visualização. Na fase de layout, consideramos diferentes elementos de visualização e encontramos todos eles nas bibliotecas, incluindo segmentações complexas de múltiplos níveis e gráficos waterfall multilaterais.
Ao implementar dashboards com os principais indicadores de vendas, enfrentamos dificuldades de desempenho que ainda não conseguimos superar. Gastamos mais de dois meses e conseguimos um dashboard funcionalmente incompleto, cuja velocidade de resposta está no limite do aceitável. E chegamos às seguintes conclusões:
- O Tableau não consegue trabalhar com grandes volumes de dados. Se o seu modelo de dados inicial tiver mais de 10 GB de dados (cerca de 200 milhões x 50 linhas), o dashboard desacelera seriamente — de 10 segundos a vários minutos por clique. Experimentamos tanto com live-connect quanto com extract. A velocidade de operação é comparável.
- Limitação ao usar múltiplos repositórios (datasets). Não há como especificar a relação entre datasets por meio de ferramentas padrão. Se forem usadas soluções alternativas para conectar datasets, isso afetará significativamente o desempenho. No nosso caso, consideramos a opção de materializar dados em cada fatia necessária das visualizações e fazer alterações nesses datasets materializados, mantendo os filtros previamente selecionados — isso se revelou impossível de fazer no Tableau.
- No Tableau, não é possível criar parâmetros dinâmicos. Você não pode preencher um parâmetro que é usado para filtrar um dataset no extract ou durante o live-connect com o resultado de outra seleção de dataset ou resultado de outra consulta SQL, apenas com a entrada nativa do usuário ou uma constante.
- Limitações relacionadas à construção de dashboards com elementos OLAP|Tabela Resumida.
No MSTR, SAP SAC e SAP Analysis, ao adicionar um conjunto de dados ao relatório, todos os objetos estão interconectados por padrão. No Tableau, isso não ocorre, a conexão deve ser configurada manualmente. Isso pode ser mais flexível, mas para todos os nossos dashboards isso é uma exigência obrigatória para os elementos – portanto, resulta em uma carga de trabalho adicional. Além disso, se você criar filtros interconectados, para que, por exemplo, ao filtrar por região, a lista de cidades seja restrita apenas às cidades dessa região, você imediatamente se depara com consultas sequenciais ao banco de dados ou extrações, o que desacelera significativamente o dashboard. - Restrições nas funções. Tanto sobre a extração quanto, AINDA MAIS, sobre o conjunto de dados de Live-connect não é possível realizar transformações em massa. Isso pode ser feito através do Tableau Prep, mas isso representa uma carga de trabalho adicional e mais uma ferramenta que precisa ser estudada e mantida. Por exemplo, você não pode transpor dados ou unir dados com eles mesmos. Isso é restringido através de transformações em colunas ou campos individuais, que devem ser escolhidos por meio de case ou if, gerando consultas SQL muito complexas, nas quais o banco de dados gasta a maior parte do tempo compilando o texto da consulta. Essas inflexibilidades da ferramenta tiveram que ser resolvidas no nível da vitrine, o que leva a uma complexidade adicional no armazenamento, cargas e transformações extras.
Não descartamos o Tableau. Mas como uma ferramenta capaz de construir dashboards industriais e um meio pelo qual podemos substituir e digitalizar todo o sistema de relatório corporativo da empresa, o Tableau não é considerado.
Atualmente, estamos ativamente desenvolvendo um dashboard semelhante em outra ferramenta e, paralelamente, tentando revisar a arquitetura do dashboard no Tableau para simplificá-lo ainda mais. Se a comunidade estiver interessada, compartilharemos os resultados.
Também estamos aguardando suas ideias ou sugestões sobre como construir dashboards rápidos no Tableau sobre volumes tão grandes de dados, pois temos um site onde os dados são muito mais volumosos do que no varejo.
Fonte: habr.com
