Série Blog de novas perspectivas - 3 Principais desafios do SAP HANA Embedded Analytics

Principais desafios da Analytics Embedded Analytics da SAP HANA

Bem-vindo à série de blogs TruQua's New Perspectives. Esta série de blogs fornece uma plataforma para nossos consultores compartilharem suas perspectivas, insights e experiências sobre tecnologias emergentes, como SAP HANA e SAP Analytics Cloud.

Nesta semana vamos conversar com Laura Rossi. Laura é consultora da TruQua, especializada no uso dos recursos de análise incorporada do SAP HANA para fornecer um enorme relatório e valor de planejamento no SAP S / 4HANA e SAP Analytics Cloud (SAC). Hoje, Laura e eu discutiremos três principais desafios do SAP HANA que os clientes enfrentam e como superá-los.

Esses desafios vêm de implementações maduras nas quais o TruQua foi contratado pela primeira vez após a ativação para ajudar o cliente. Queremos cobrir não apenas a correção, mas também a causa raiz dos problemas apresentados e como garantimos que os desafios do cliente não retornassem.

Desafio 1 - Enorme produtividade da HANA

JS Irick: Sem hipérbole, o HANA é a ferramenta pela qual muitos cientistas de dados e analistas financeiros esperaram a carreira inteira. O HANA manipula facilmente o Universal Journal - bilhões de registros com colunas 300 +, condensando centenas de tabelas de ERP em uma única estrutura plana.

Com esse poder excepcional, há risco - no caso de um compromisso, descobrimos que uma única consulta exigia 700 Gigabytes de memória; em outro cliente, bilhões de registros foram passados ​​para a camada SAP NetWeaver, ameaçando repetidamente a estabilidade produtiva.

Do ponto de vista de desenvolvimento e teste, como você recomenda que os clientes aproveitem efetivamente os pontos fortes da HANA?

Laura Rossi: Como você mencionou, o JS, HANA tem capacidade para processar tabelas massivas em questão de segundos, permitindo aos usuários criar visualizações grandes e complexas de seus dados, adicionar cálculos, filtrar, reformatar etc. e armazená-las como uma única estrutura plana. No entanto, o fato de que pode criar consultas grandes e complexas não significa necessariamente que devemos aproveitar esse poder a cada passo. As ineficiências aumentam rapidamente, o que leva ao tipo de memória que sobrecarrega e falha nos sistemas, especialmente se estamos falando de sandbox ou de cenários de teste com alocações limitadas de memória. No meu cliente mais recente, uma única consulta ineficiente conseguiu desacelerar nosso sistema de desenvolvimento muito visivelmente até que o identificássemos e redesenhamos. Algumas horas de redesenho da consulta culpada converteram uma consulta muito lenta e com um travamento frequente em um processo que agora é executado em cerca de um minuto.

Certos requisitos de modelagem exigem consultas grandes e que consomem memória, com as quais o HANA pode lidar. O importante é não combinar demandas desnecessárias em torno das demandas reais e necessárias. Ninguém deseja esperar os minutos do 15 para executar uma consulta que possa ser realizada no 1.5.

Além disso, algumas otimizações são simples e baseadas em princípios clássicos de design de banco de dados. Por exemplo, em vez de colocar várias associações externas para atribuir detalhes esparsos, o mesmo cenário pode ser dividido em casos diferentes, com base em como a atribuição muda, quais atributos se aplicam, quais não se aplicam e como eles são gerenciados com associações internas e filtros. Se um critério de seleção complexo exigir uma junção ou uma transposição, vale a pena gastar algum tempo para avaliar se outra forma de detalhe ou cálculo pode servir ao mesmo objetivo. Dessa forma, quando um requisito precisa ser tratado e requer uma grande quantidade de memória, estamos inserindo essas demandas de memória no modelo mais enxuto e eficiente possível, em vez de aumentar a ineficiência.

JS Irick: Você mencionou um ponto realmente interessante aqui, que é o conflito fundamental entre "visões de finalidade" e "visão como data warehouse". O primeiro pode sobreviver a um ou dois problemas de filtragem, mas o posterior requer perfeição em toda a pilha. Além das vantagens semânticas óbvias do uso das visualizações do Core Data Service (CDS), o próprio fato de colocarem mais trilhos de proteção e rigor nas visualizações da HANA os torna uma opção muito atraente para garantir a estabilidade.

De uma perspectiva pragmática, sou um grande defensor do volume produtivo (não dados, mas volume) no desenvolvimento. Para consultas complexas, você precisa realmente ver o impacto.

Laura Rossi: Concordo. Novamente, no meu último cliente, tivemos a sorte de ter uma grande amostra de dados em um sistema sandbox com pouca memória. Estou chamando isso de sorte, porque permitiu à nossa equipe projetar mantendo a simplicidade e a eficiência desde o primeiro dia, em vez de criar tudo e otimizar. O problema com o HANA é que ele é poderoso o suficiente para provavelmente ainda executar a consulta ineficiente. Mas, novamente, isso não significa que deveria. Outro recurso útil é o console SQL do HANA, que permite analisar a demanda de memória ou o "custo de subárvore" de uma exibição e todos os seus subcomponentes.

Desafio 2 - Falta de "HANA Gurus"

JS Irick: Por quase 40 anos, a SAP foi independente de banco de dados, com as melhores práticas garantindo que os especialistas da SAP permanecessem na camada de aplicativos.

Esse firewall, que só foi possível graças à excelente camada de integração entre o NetWeaver e o banco de dados, desapareceu. Agora, temos um ambiente de desenvolvimento incomparável para dados financeiros semanticamente enriquecidos. Também temos equipes incrivelmente talentosas, com um profundo entendimento dos processos e necessidades de suas organizações, mas para quem o desenvolvimento de banco de dados foi intencionalmente bloqueado por duas gerações.

O que foi fundamental para você se tornar tão forte no desenvolvimento da HANA, e como você trabalha com equipes de clientes experientes para habilitá-las neste novo espaço?

Laura Rossi: Muito do cenário da SAP está evoluindo. O SAC e o S / 4HANA estão reformulando a forma como concebemos soluções e o que os clientes optam por priorizar. Então, eu argumentaria que agora é o melhor momento para começar a aprender e reaprender. Obviamente, o S / 4HANA é baseado no HANA, mas mesmo em um caso como o SAC, a conexão com um banco de dados HANA é fácil e pode aumentar significativamente os recursos de desempenho da solução de relatórios.

E embora seja verdade que não podemos aproveitar a quantidade de experiência disponível para outras soluções SAP mais antigas, as melhores práticas de análise de dados ainda podem ser adaptadas e aproveitadas nas melhores soluções de negócios para modelagem no HANA.

JS Irick: Eu amo a positividade! A parte mais gratificante de trabalhar em consultoria é ver as equipes de clientes com as quais você trabalha adquirir novas habilidades (e reconhecimento). "Agora é o melhor momento para começar a aprender e reaprender", diz tudo.

Em termos de por onde começar, de uma perspectiva funcional, eu sempre recomendo encontrar o próximo passo. Você não está querendo reinventar o FP&A, quer trazer novas habilidades para os seus conhecimentos existentes. Continue construindo seus pontos fortes. Do ponto de vista técnico, recomendo que os clientes aprendam da mesma maneira que aprendemos na TruQua. Você precisa aproveitar o visualizador de plano e entender realmente como a plataforma está executando suas consultas. Pequenos ajustes no nível da modelagem podem ter um impacto incrível. Você precisa entender onde os gargalos podem resolvê-los.

Laura Rossi: Definitivamente concordo com o visualizador de plano, é um ótimo lugar para começar a diagnosticar os aspectos de um redesenho que terá o impacto mais produtivo. Da mesma forma, entender a linhagem dos seus dados e em qual estágio de uma visualização ou modelo em que algum cálculo é realizado e por que provavelmente devem ser as primeiras etapas. Além disso, desde que tenhamos em mente um design enxuto, gosto de argumentar que quanto mais simples, melhor, tanto do ponto de vista de solução de problemas futuros quanto de uma perspectiva de escalabilidade.

Desafio 3 - As complexidades da transformação em tempo real

JS Irick: Eu não acho que seja muito difícil considerar o caminho do banco de dados para um relatório como um sistema fechado. O processo ETL (Extrair, Transformar, Carregar) e as diversas camadas de agregação, enriquecimento e conversão desapareceram com a mudança para o S / 4HANA e análises integradas, mas a complexidade não desapareceu, ainda está presente no CDS ou no HANA nativo Visualizações.

As perguntas de relatório padrão ainda existem, mas agora elas ficam em uma única exibição, em vez de em um diagrama de arquitetura complexo:

  • Como armazenamos dados em cache?
  • O que precisamos para persistir?
  • Como lidamos com a configuração?
  • Onde estão os pontos de extensibilidade para novos requisitos?
  • Como são tratadas as alterações de dados mestre / hierarquia?

Como você lida com esses desafios com os clientes e como garante que sua solução seja aquela que eles possam possuir e expandir?

Laura Rossi: De certa forma, acho que todas as perguntas que estamos abordando hoje se resumem aos mesmos princípios de um design enxuto e eficiente. Ser muito claro sobre os requisitos, o que pode ou não mudar, o que mudou historicamente e onde tudo reside é fundamental, portanto, nesse sentido, deve-se começar pelo básico: dar uma boa olhada no que é necessário e na aparência dos dados para dados reais atuais, planejamento e dados históricos.

Depois disso, dividir a modelagem de visualizações em "camadas" baseadas em cenários ou casos de uso ajuda tanto do ponto de vista da rastreabilidade quanto da solução de problemas simples, além de manter a complexidade baixa. Em outras palavras, eu recomendo criar várias visualizações para diferentes aspectos do uso comercial e, em seguida, uma visualização do "nó superior" que combine o resultado dessas camadas menores. Uma visualização simples e eficiente com um caso de uso claro é mais fácil de desenvolver e expandir uma visualização grande e complexa que combina vários cenários de casos de uso.

JS Irick: Eu realmente gosto que você tenha apresentado uma arquitetura em camadas de uma perspectiva funcional. (também que você fez um aceno astuto para o desenvolvimento ágil / enxuto).

Um desenvolvedor precisa entender verdadeiramente o caso de uso do cliente, poder se comunicar com o usuário e desenvolver a necessidade, não o requisito. Para ir além, você precisa entender como as necessidades da empresa podem mudar ao longo do tempo, ou você terá uma solução quebradiça.

Há muitos lugares para deixar ganchos para extensão e configuração - front-end da Web, XSA, via camada BW, etc. Eu hesitaria em fazer uma regra rígida e rápida sobre onde esses pontos deveriam estar. O gerenciamento de mudanças de uma perspectiva técnica raramente recebe brilho, mas vale a pena manter o máximo possível "no idioma do cliente", por assim dizer.

Laura Rossi: Concordo. Pessoalmente, acho que entender o caso comercial e a "linguagem comercial" de tudo o que construí foi uma área em que tive que aprender mais enquanto trabalhava com o TruQua, e realmente valeu a pena. A melhor solução só pode brilhar se os usuários entenderem e precisarem dela. E, é claro, ter uma compreensão completa do caso de uso desde o início, poupa muito retrabalho nas perguntas e respostas. Por fim, a solução deve funcionar para o cliente.

Conclusão

JS Irick: Muito obrigado por compartilhar sua perspectiva hoje, Laura. As tecnologias emergentes no cenário da SAP - incluindo HANA, SAP Analytics Cloud, Leonardo e S / 4HANA estão fornecendo uma oportunidade para os consultores no início da carreira oferecerem um valor tremendo. Estou feliz por termos um pouco de tempo hoje para discutir como você está ajudando os clientes a vencer seus maiores desafios. Obrigado por compartilhar suas idéias, e estou ansioso para falar novamente em breve!

Laura Rossi: Obrigado pela oportunidade de compartilhar! Esse é definitivamente um momento emocionante para estar no ecossistema SAP e conversas como essa criam grandes oportunidades para o crescimento e o compartilhamento de idéias. Definitivamente, aprendi muito com todo mundo no TruQua, por isso é ótimo participar da conversa.

Sobre nossos colaboradores:

JS Irick tem o melhor emprego do mundo; trabalhando com uma equipe talentosa para solucionar os mais difíceis desafios de negócios. JS é um palestrante reconhecido internacionalmente nos tópicos de Machine Learning, SAP Planning, SAP S / 4HANA e desenvolvimento de software. Como diretor de ciência de dados e inteligência artificial da TruQua, JS criou as práticas recomendadas para implementações SAP nas áreas de SAP HANA, relatórios SAP S / 4HANA e personalização do SAP S / 4HANA.

Laura Rossi é consultora de SAP da TruQua, especializada na aplicação de ciência de dados ao planejamento e análise financeiros. Laura é altamente qualificada no desenvolvimento de aplicativos de banco de dados nativos para resolver não apenas os desafios atuais do cliente, mas antecipar e se adaptar aos seus objetivos futuros. O trabalho de Laura na "pilha de planejamento moderna" do SAP HANA, SAP S / 4HANA e SAP Analytics Cloud ajuda a fornecer uma base para o Planejamento Empresarial Colaborativo.

Obrigado por ler nossa primeira parcela em nossa Novas perspectivas série de blogs. Fique atento ao nosso próximo post, que contará com Andrew Xue, consultor da SAP e suas idéias sobre o Collaborative Enterprise Planning.

Para obter mais informações sobre os serviços e ofertas da TruQua, visite-nos online em www.truqua.com. Para ser notificado sobre futuras postagens do blog e ser incluído em nossa lista de e-mails, preencha o formulário abaixo.

Descubra como o TruQua pode levá-lo mais longe, mais rápido, juntos.

O que fazemos

Descubra como o TruQua pode levá-lo mais longe, mais rápido, juntos.

info@truqua.com
312.525.8787