O tempo para relatórios em Excel está desaparecendo rapidamente - a tendência para ferramentas convenientes para apresentação e análise de informações é visível em todas as áreas. Há muito tempo que discutimos internamente a digitalização dos relatórios e escolhemos o sistema de visualização e análise de autoatendimento Tableau. Alexander Bezugly, chefe do departamento de soluções analíticas e relatórios do Grupo M.Video-Eldorado, falou sobre a experiência e os resultados da construção de um painel de combate.
Direi desde já que nem tudo o que foi planejado foi concretizado, mas a experiência foi interessante, espero que seja útil para você também. E se alguém tiver alguma ideia sobre como isso poderia ser feito melhor, ficaria muito grato por seus conselhos e ideias.
Abaixo do corte está o que encontramos e o que aprendemos.
Por onde começamos?
M.Video-Eldorado possui um modelo de dados bem desenvolvido: informações estruturadas com a profundidade de armazenamento necessária e uma grande quantidade de relatórios em formato fixo (veja mais detalhes ). A partir deles, os analistas criam tabelas dinâmicas ou boletins informativos formatados em Excel, ou lindas apresentações em PowerPoint para usuários finais.
Há cerca de dois anos, em vez de relatórios em formato fixo, começamos a criar relatórios analíticos no SAP Analysis (um complemento do Excel, essencialmente uma tabela dinâmica sobre o mecanismo OLAP). Mas esta ferramenta não foi capaz de satisfazer as necessidades de todos os utilizadores, a maioria continuou a utilizar informação adicionalmente processada por analistas.
Nossos usuários finais se enquadram em três categorias:
Alta administração. Solicita informações de maneira bem apresentada e claramente compreensível.
Administração média, usuários avançados. Interessado na exploração de dados e capaz de criar relatórios de forma independente se houver ferramentas disponíveis. Eles se tornaram os principais usuários de relatórios analíticos no SAP Analysis.
Usuários em massa. Não têm interesse em analisar dados de forma independente, utilizam relatórios com grau de liberdade limitado, em formato de newsletters e tabelas dinâmicas em Excel.
Nossa ideia era atender às necessidades de todos os usuários e fornecer-lhes uma ferramenta única e conveniente. Decidimos começar pela alta administração. Eles precisavam de painéis fáceis de usar para analisar os principais resultados de negócios. Então, começamos com o Tableau e primeiro escolhemos duas direções: indicadores de vendas no varejo e online com profundidade e amplitude de análise limitadas, que cobririam aproximadamente 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 - velocidade de resposta. Ninguém esperará 20 a 30 segundos para que os dados sejam atualizados. A navegação deveria ter sido feita em 4-5 segundos ou, melhor ainda, instantaneamente. E nós, infelizmente, não conseguimos isso.
Esta é a aparência do layout do nosso painel principal:
A ideia chave é combinar os principais drivers de KPI, dos quais eram 19 no total, à esquerda e apresentar sua dinâmica e distribuição por atributos principais à direita. A tarefa parece simples, a visualização é lógica e compreensível, até você mergulhar nos detalhes.
Detalhe 1. Volume de dados
Nossa tabela principal de vendas anuais ocupa cerca de 300 milhões de linhas. Dado que é necessário reflectir a dinâmica do ano passado e do ano anterior, o volume de dados apenas sobre as vendas reais é de cerca de mil milhões de linhas. As informações sobre os dados planejados e o bloco de vendas on-line também são armazenadas separadamente. Portanto, embora tenhamos usado o banco de dados colunar na memória SAP HANA, a velocidade da consulta com a seleção de todos os indicadores por uma semana do armazenamento atual em tempo real foi de cerca de 1 a 15 segundos. A solução para este problema surge por si mesma - materialização adicional de dados. Mas também tem armadilhas, mais sobre elas a seguir.
Detalhe 2. Indicadores não aditivos
Muitos de nossos KPIs estão vinculados ao número de recebimentos. E este indicador representa COUNT DISTINCT do número de linhas (verificar cabeçalhos) e mostra valores diferentes dependendo dos atributos selecionados. Por exemplo, como este indicador e sua derivada devem ser calculados:
Para fazer seus cálculos corretos, você pode:
- Calcule esses indicadores rapidamente no armazenamento;
- Execute cálculos em todo o volume de dados no Tableau, ou seja, mediante solicitação no Tableau, disponibilizar todos os dados conforme filtros selecionados na granularidade da posição do recebimento;
- Crie uma vitrine materializada na qual todos os indicadores serão calculados em todas as opções de amostra que dão diferentes resultados não aditivos.
Fica claro que no exemplo UTE1 e UTE2 são atributos de materiais que representam a hierarquia do produto. Isso não é algo estático; a gestão dentro da empresa se dá por meio dela, porque Diferentes gerentes são responsáveis por diferentes grupos de produtos. Tivemos muitas revisões globais dessa hierarquia, quando todos os níveis mudaram, quando os relacionamentos foram revisados, e mudanças constantes de pontos, quando um grupo passou de um nó para outro. Nos relatórios convencionais, tudo isso é calculado instantaneamente a partir dos atributos do material, no caso de materialização desses dados é necessário desenvolver um mecanismo para rastrear tais alterações e recarregar automaticamente os dados históricos. Uma tarefa nada trivial.
Detalhe 3. Comparação de dados
Este ponto é semelhante ao anterior. O resultado final é que ao analisar uma empresa, costuma-se 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, assume-se que dependendo do período selecionado pelo usuário (por exemplo, a 33ª semana do ano), devemos mostrar a dinâmica até a 32ª semana; se selecionamos dados de um mês, por exemplo, maio , então essa comparação mostraria a dinâmica até abril.
Comparação com o ano passado
A principal ressalva aqui é que ao comparar por dia e por semana, você não está pegando o mesmo dia do ano passado, ou seja, você não pode simplesmente colocar o ano atual menos um. Você deve observar o dia da semana que está comparando. Ao comparar meses, ao contrário, é necessário considerar exatamente o mesmo dia do ano passado. Também existem nuances nos anos bissextos. Nos repositórios originais, todas as informações são distribuídas por dia; não há campos separados com semanas, meses ou anos. Portanto, para obter um corte analítico completo no painel, é necessário contar não um período, por exemplo uma semana, mas 4 semanas, e então comparar esses dados, refletir a dinâmica, os desvios. Dessa forma, essa lógica de geração de comparações em dinâmica também pode ser implementada tanto no Tableau quanto na vitrine. Sim, e claro que sabíamos e pensávamos nestes detalhes na fase de design, mas era difícil prever o seu impacto no desempenho do painel final.
Ao implementar o dashboard, seguimos o longo caminho do Agile. Nossa tarefa era fornecer uma ferramenta de trabalho com os dados necessários para testes o mais rápido possível. Portanto, partimos em sprints e começamos minimizando o trabalho no lado do armazenamento atual.
Parte 1: Fé no Tableau
Para simplificar o suporte de TI e implementar mudanças rapidamente, decidimos fazer a lógica de cálculo de indicadores não aditivos e comparação de períodos anteriores no Tableau.
Etapa 1. Tudo está ativo, sem modificações nas janelas.
Nesta fase, conectamos o Tableau às vitrines atuais e decidimos ver como seria calculado o número de recebimentos de um ano.
Resultado:
A resposta foi deprimente – 20 minutos. Transferência de dados pela rede, alta carga no Tableau. Percebemos que a lógica com indicadores não aditivos precisa ser implementada no HANA. Isso não nos assustou muito, já tínhamos experiência semelhante com BO e Análise e sabíamos como construir vitrines rápidas em HANA que produzissem indicadores não aditivos calculados corretamente. Agora só faltava ajustá-los ao Tableau.
Etapa 2. Afinamos as vitrines, sem materialização, tudo na hora.
Criamos uma nova vitrine separada que produziu os dados necessários para o TABLEAU instantaneamente. No geral obtivemos um bom resultado, reduzimos o tempo de geração de todos os indicadores em uma semana para 9 a 10 segundos. E honestamente esperávamos que no Tableau o tempo de resposta do painel fosse de 20 a 30 segundos na primeira abertura e depois devido ao cache de 10 a 12, o que em geral nos serviria.
Resultado:
Primeiro painel aberto: 4-5 minutos
Qualquer clique: 3-4 minutos
Ninguém esperava tal aumento adicional no trabalho da vitrine.
Parte 2. Mergulhe no Tableau
Etapa 1. Análise de desempenho do Tableau e ajuste rápido
Começamos a analisar onde o Tableau passa a maior parte do tempo. E existem ferramentas muito boas para isso, o que, claro, é uma vantagem do Tableau. O principal problema que identificamos foram as consultas SQL muito complexas que o Tableau estava criando. Eles estavam associados principalmente a:
— transposição de dados. Como o Tableau não possui ferramentas para transposição de datasets, para construir o lado esquerdo do dashboard com uma representação detalhada de todos os KPIs, tivemos que criar uma tabela utilizando um caso. O tamanho das consultas SQL no banco de dados atingiu 120 caracteres.
- escolha do período de tempo. Essa consulta no nível do banco de dados levava mais tempo para compilar do que para executar:
Aqueles. processamento de solicitação 12 segundos + 5 segundos de execução.
Decidimos simplificar a lógica de cálculo no lado do Tableau e mover outra parte dos cálculos para a vitrine e o nível do banco de dados. Isto trouxe bons resultados.
Primeiro, fizemos a transposição dinamicamente, através de uma junção externa completa na fase final do cálculo do VIEW, de acordo com esta abordagem descrita no wiki и .
Ou seja, fizemos uma tabela de configuração - uma matriz de transposição (21x21) e recebemos todos os indicadores discriminados linha por linha.
Foi:
Tornou-se:
Quase nenhum tempo é gasto na transposição do banco de dados em si. A solicitação de todos os indicadores da semana continuou a ser processada em cerca de 10 segundos. Mas, por outro lado, perdeu-se flexibilidade em termos de construção de um dashboard baseado num indicador específico, ou seja, para o lado direito do painel, onde são apresentadas a dinâmica e o detalhamento de um indicador específico, anteriormente a janela do display funcionava em 1-3 segundos, pois a solicitação era baseada em um indicador e agora o banco de dados sempre selecionava todos os indicadores e filtrava o resultado antes de retornar o resultado ao Tableau.
Como resultado, a velocidade do painel diminuiu quase 3 vezes.
Resultado:
- 5 segundos – análise de painéis, visualizações
- 15 a 20 segundos - preparação para compilar consultas com pré-cálculos no Tableau
- 35-45 seg - compilação de consultas SQL e sua execução sequencial paralela em Hana
- 5 segundos – processamento de resultados, classificação e recálculo de visualizações no Tableau
- É claro que esses resultados não agradaram ao negócio e continuamos a otimização.
Etapa 2. Lógica mínima no Tableau, materialização completa
Entendemos que era impossível construir um painel com tempo de resposta de vários segundos em uma vitrine que funcionasse por 10 segundos e consideramos opções para materializar 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 foi possível garantir que, ao alterar filtros ou detalhamentos, o Tableau alternasse com flexibilidade entre diferentes vitrines e níveis pré-projetados para diferentes hierarquias de produtos (no exemplo, três consultas sem UTE, com UTE1 e UTE2 geram resultados diferentes). Portanto, decidimos simplificar o dashboard, abandonar a hierarquia de produtos no dashboard e ver o quão rápido isso poderia ser em uma versão simplificada.
Assim, nesta última etapa, montamos um repositório separado no qual adicionamos todos os KPIs de forma transposta. Do lado do banco de dados, qualquer solicitação para esse tipo de armazenamento é processada em 0,1 a 0,3 segundos. No painel recebemos os seguintes resultados:
Primeira abertura: 8 a 10 segundos
Qualquer clique: 6 a 7 segundos
O tempo gasto pelo Tableau consiste em:
- 0,3 seg. — análise de painel e compilação de consultas SQL
- 1,5-3 seg. — execução de consultas SQL em Hana para visualizações principais (executada em paralelo com a etapa 1)
- 1,5-2 seg. — renderização, recálculo de visualizações
- 1,3 seg. — execução de consultas SQL adicionais para obter valores de filtro relevantes (Marca, Divisão, Cidade, Loja), análise de resultados
Para resumir brevemente
Gostamos da ferramenta Tableau do ponto de vista da visualização. Na fase de prototipagem, consideramos vários elementos de visualização e os encontramos em bibliotecas, incluindo segmentação complexa de vários níveis e cascata de vários drivers.
Na implementação de dashboards com os principais indicadores de vendas, encontramos dificuldades de desempenho que ainda não conseguimos superar. Passamos mais de dois meses e recebemos um painel funcionalmente incompleto, cuja velocidade de resposta está quase aceitável. E tiramos conclusões por nós mesmos:
- O Tableau não consegue trabalhar com grandes quantidades de dados. Se no modelo de dados original você tiver mais de 10 GB de dados (aproximadamente 200 milhões x 50 linhas), o painel ficará seriamente lento - de 10 segundos a vários minutos para cada clique. Experimentamos conexão ao vivo e extração. A velocidade operacional é comparável.
- Limitação ao usar vários armazenamentos (conjuntos de dados). Não há como indicar a relação entre conjuntos de dados usando meios padrão. Se você usar soluções alternativas para conectar conjuntos de dados, isso terá um grande impacto no desempenho. No nosso caso, consideramos a opção de materializar os dados em cada seção de visualização necessária e fazer alterações nesses conjuntos de dados materializados, preservando os filtros previamente selecionados - isso acabou sendo impossível de fazer no Tableau.
- Não é possível criar parâmetros dinâmicos no Tableau. Você não pode preencher um parâmetro usado para filtrar um conjunto de dados em uma extração ou durante a conexão ao vivo com o resultado de outra seleção do conjunto de dados ou o resultado de outra consulta SQL, apenas a entrada do usuário nativo ou uma constante.
- Limitações associadas à construção de um painel com elementos OLAP|PivotTable.
No MSTR, SAP SAC, SAP Analysis, se você adicionar um conjunto de dados a um relatório, todos os objetos nele serão relacionados entre si por padrão. O Tableau não tem isso; a conexão deve ser configurada manualmente. Isto é provavelmente mais flexível, mas para todos os nossos painéis este é um requisito obrigatório para elementos - portanto, são custos de mão-de-obra adicionais. Além disso, se você fizer filtros relacionados para que, por exemplo, ao filtrar uma região, a lista de cidades fique limitada apenas às cidades desta região, você imediatamente acaba com consultas sucessivas ao banco de dados ou Extrato, o que retarda visivelmente o painel. - Limitações nas funções. As transformações em massa não podem ser feitas nem na extração nem, ESPECIALMENTE, no conjunto de dados do Live-connecta. Isso pode ser feito por meio do Tableau Prep, mas é um trabalho adicional e outra ferramenta para aprender e manter. Por exemplo, você não pode transpor dados ou juntá-los a si mesmos. O que é fechado através de transformações em colunas ou campos individuais, que devem ser selecionados através de case ou if, e isso gera consultas SQL muito complexas, nas quais o banco de dados passa a maior parte do tempo compilando o texto da consulta. Essa inflexibilidade da ferramenta teve que ser resolvida no nível da vitrine, o que leva a um armazenamento mais complexo, downloads adicionais e transformações.
Não desistimos do Tableau. Mas não consideramos o Tableau uma ferramenta capaz de construir painéis industriais e uma ferramenta para substituir e digitalizar todo o sistema de relatórios corporativos de uma empresa.
Agora estamos desenvolvendo ativamente um painel semelhante em outra ferramenta e, ao mesmo tempo, tentando revisar a arquitetura do painel no Tableau para simplificá-lo ainda mais. Se a comunidade estiver interessada, iremos informá-lo sobre os resultados.
Também estamos aguardando suas idéias ou conselhos sobre como no Tabeau você pode construir painéis rápidos sobre volumes tão grandes de dados, porque temos um site onde há muito mais dados do que no varejo.
Fonte: habr.com