Há cerca de quatro anos, mudamos nosso sistema de relatórios do Oracle para o SAP Hana. Hoje, ele armazena cerca de 10.000 tabelas, 38.000 pessoas a usam e mais de 5.000 processos de carregamento ocorrem diariamente. No momento, nosso complexo, no qual o sistema funciona, consiste em 8 servidores com 14 TB de memória. Todos os dias, o sistema de relatórios processa 1,5 pb de dados. Ao mesmo tempo, Hana era cerca de 20 vezes mais produtivo que Oracle, DB2 e MySQL. E hoje quero dizer como, no âmbito da integração da M.Video e Eldorado, aumentamos ainda mais o desempenho do sistema de relatórios, que otimizações fizemos.
Carregar
Hoje, dos milhares de relatórios criados pelo sistema, apenas 10 geram 70% da carga total. O relatório mais pesado no banco de dados Hana é o Weekly Bussines Review. Ele dura 30 minutos e consome 4 TB de memória. 90% de todos os relatórios são gerados pelo contact center: criamos um serviço que, quando um cliente liga por seu número de telefone, abre automaticamente um relatório e mostra ao operador todo o histórico de compras do chamador e sua interação com a empresa.
Modelo de dados
O modelo de dados chave no qual a maior parte dos relatórios é criada contém 1.500 tabelas. A maioria deles são tabelas de referência. Usando esse modelo, você pode analisar qualquer direção da empresa. Um exemplo é a visualização de um modelo de dados criado usando o designer do Universe. É verdade que reflete apenas um décimo do nosso sistema.
Desempenho
No momento da fusão da M.Video e da Eldorado, a quantidade de dados nos dois sistemas de relatório era de aproximadamente 10 TB: 7 TB no BW no sistema HANA M.Video, 2 TB no BW no HANA Eldorado e 1 TB dados adicionais no HADOOP (dados históricos). Ao combinar os sistemas, tínhamos limitações de hardware: o complexo M. Video consistia em 6 nós (2 TB cada), incluindo um backup. Este sistema pode ser expandido para um máximo de 8 nós, dos quais um backup.
Em preparação para a fusão, assumimos que a quantidade total de todos os dados chegaria a 13 TB. Portanto, com base nas recomendações da SAP, precisávamos de um sistema de 16 nós de 2 TB cada, incluindo dois nós de backup. Além disso, um nó precisava ser alocado como nó principal, o qual, com esse volume de informações, assumiria as funções de gerenciamento. Ou seja, para a operação correta, foi necessário implantar 13 nós.
Como você pode ver, os recursos disponíveis categoricamente não são suficientes. E esse foi o primeiro desafio.
A segunda principal dificuldade antes da fusão foi que a velocidade do sistema geralmente não atendia às necessidades dos negócios. O principal motivo foi o grande número de chamadas simultâneas no banco de dados. Do ponto de vista do sistema, parecia uma bola de neve, o que poderia levar ao congelamento e à interrupção de parte dos processos, ou até a despejos globais de “falta de memória” nos nós.
Ficou claro que, sem melhorias significativas, um aumento duplo na quantidade de dados nos relatórios (para duas marcas) levaria a um agravamento aproximadamente duplo da situação.
Portanto, decidimos otimizar o sistema nas seguintes áreas:
- Relatórios Aceleração dos relatórios mais críticos e com mais recursos e revisão do modelo de dados.
- Repositório . Otimização de arquivamento e armazenamento.
- Downloads . Simplifique o procedimento e altere a programação de download.
A abordagem geral da otimização foi a seguinte:
Primeiro, realizamos uma análise em todas as direções, identificamos as causas dos problemas e, em seguida, analisamos os recursos do sistema com os recursos necessários. Também tentamos imediatamente automatizar esse processo o máximo possível para que, no futuro, possamos identificar rapidamente as causas dos problemas e restaurar rapidamente o desempenho.
O que fizemos:
- Mudou a configuração dos servidores de aplicativos ABAP: o número de instâncias, o uso efetivo da tecnologia NUMA e o número ideal de fluxos de trabalho.
- Aplicamos os parâmetros ideais do HANA e do sistema operacional Linux.
- Analisamos a diminuição no consumo de CPU.
- Analisamos o consumo de RAM em todo o intervalo de tempo observado.
- Analisamos a ocorrência de OOM no HANA.
- Analisamos a ocorrência de bloqueios no sistema e a disponibilidade de recursos do sistema para operações de espera (espera).
- Analisamos o equilíbrio dos dados, levando em consideração a redistribuição e repartição dos dados para a solução SCANA-OUT HANA.
- Analisamos as causas dos lixões ABAP que afetam a operação de cadeias críticas.
Com base nos resultados, foram compilados relatórios de desempenho e instruções para que, no futuro, fosse possível determinar independentemente gargalos no sistema e intervalos de tempo de pico.
Que resultados foram alcançados:
Vários relatórios otimizados O SAP BO começou a trabalhar
muitas vezes mais rapidamente e consumir
centenas de vezes menos memória .
Aqui estão alguns exemplos impressionantes de como o sistema atende incorretamente às condições de seleção e como criar consultas corretamente no HANA.
Os problemas foram revelados ao filtrar por objetos não materializados, especialmente (!) Ao usar indicadores
COUNT DISTINCT (um CD pode ser gravado no nível do Universo e em uma função no CV).
Mesmo se você excluir o CD da consulta, a primeira opção ainda será executada 20 vezes mais lenta que a segunda e, com um CD, a velocidade é mais de 500 vezes maior.
Um caso especial de uso de objetos não materializados em filtros: filtros compostos de dois ou mais objetos, por exemplo, colando uma semana e um ano:
As consultas com filtros colados não funcionam tão lentamente quanto a conversão para uma data, mas ainda diminuem as consultas (cerca de 2 a 3 vezes).
Para coletar estatísticas sobre a operação do sistema de relatórios, carregando processos e cadeias, desenvolvemos o seguinte esquema:
Ao mesmo tempo, adicionamos um comentário especial aos relatórios com o nome do relatório. Assim, podemos comparar a carga de diferentes partes do sistema e comparar o período com o período.
Planos
Temos muitos planos para o desenvolvimento da funcionalidade comercial e uma revisão substancial da ferramenta de visualização de dados. A tendência global em que estamos participando ativamente é integrar o sistema de relatórios ao paradigma da transformação digital.
Como assim?
Quando nosso sistema de relatórios era jovem, os usuários costumavam nos procurar com solicitações semelhantes: "Automatize a construção de um relatório que mostre quanto lucro líquido esta ou aquela loja ou toda a empresa receberam".
Então eles começaram a nos procurar com pedidos de um algoritmo que construísse um plano ou previsão de lucro líquido, dependendo de fatores específicos.
E hoje chegamos à conclusão de que os usuários desejam conhecer a previsão exata do lucro líquido. Temos todos os dados necessários para o desenvolvimento de algoritmos de previsão e existem especialistas em análise de dados que podem criar modelos de aprendizado de máquina. Como você sabe, isso requer quantidades realmente grandes de dados; portanto, uma das principais tendências no desenvolvimento de nosso sistema de relatórios é a transição para a análise e criação de modelos baseados em big data.
Algumas palavras sobre nossa equipe
Hoje, as grandes empresas estão cada vez mais introduzindo sistemas de previsão baseados em algoritmos de aprendizado de máquina desenvolvidos pelo próprio sistema. Há dois anos, criamos um centro de competência no campo de análise de dados do Digital Retail Data Science Center, e este ano temos um grupo de engenheiros de dados. Estamos introduzindo um novo sistema para processar e analisar big data. E precisamos de pessoas da equipe nos departamentos de suporte, desenvolvimento e análise de dados aplicada.
Se você estiver interessado nessas áreas, se sentir a força em si mesmo - seja bem-vindo! Você encontrará trabalhos interessantes e difíceis, às vezes estressantes, mas sempre criativos.
