Por Techopedia Staff, 25 de janeiro de 2017
Resumo: O anfitrião Eric Kavanagh discute a computação na memória e o SAP HANA com os convidados Dr. Robin Bloor, Dez Blanchfield e Bill Ellis da IDERA.
No momento, você não está logado. Faça o login ou inscreva-se para ver o vídeo.
Eric Kavanagh: Ok, senhoras e senhores. Olá e bem-vindo de volta mais uma vez. São quatro horas da manhã na quarta-feira e nos últimos dois anos, o que significa que é hora, mais uma vez, da Hot Technologies. Sim, de fato, meu nome é Eric Kavanagh, serei seu anfitrião na conversa de hoje.
E pessoal, vamos falar sobre algumas coisas legais hoje. Vamos mergulhar no mundo da memória, o título exato é "Para o futuro: uma rampa para a computação na memória". Hoje em dia, toda a raiva está presente e por um bom motivo, principalmente porque a memória é muito mais rápida do que depender de discos giratórios. O desafio, porém, é que você precisa reescrever muitos softwares. Porque o software de hoje, na maior parte, foi escrito com o disco em mente e isso realmente muda a arquitetura do aplicativo. Se você projetar o aplicativo para aguardar um disco giratório, faça as coisas de maneira diferente do que se tivesse todo esse poder da tecnologia na memória.
Há um ponto sobre o seu verdadeiramente, me bata no Twitter, @eric_kavanagh. Eu sempre tento acompanhar e também retuitar sempre que alguém me mencionar.
Como eu disse, estamos falando sobre a memória hoje, e especificamente sobre o SAP HANA. Você realmente passou o último ano conhecendo muito bem a comunidade SAP, e devo dizer que é um ambiente fascinante. Tiramos o chapéu para as pessoas que executam essa operação e estão na linha de frente, porque o SAP é uma operação incrivelmente boa. Eles são realmente muito bons em fazer negócios. Eles também são ótimos em tecnologia, é claro, e realmente investiram muito no HANA. Na verdade, eu me lembro - provavelmente foi há seis ou sete anos atrás - que estávamos trabalhando na Força Aérea dos EUA e contratamos alguém da SAP para nos dar uma rápida olhada no mundo da HANA e o que foi planejado. E para dizer o mínimo, o pessoal do SAP Labs dedicou muito tempo e esforço para entender como criar essa arquitetura que é completamente diferente, mais uma vez, dos ambientes tradicionais, porque você tem tudo na memória. Então, eles estão falando sobre fazer transações e análises nos mesmos dados na memória, em oposição à maneira tradicional, que é extrair, colocar em um cubo, por exemplo, analisar lá, versus transacional, que acontece de uma maneira muito diferente.
Este é um espaço interessante e, na verdade, descobriremos de outro fornecedor, o IDERA, um pouco sobre como tudo isso vai funcionar e o que é a rampa de acesso, francamente. Portanto, ouviremos o Dr. Robin Bloor, nosso analista-chefe aqui no The Bloor Group; Dez Blanchfield, nosso cientista de dados e, em seguida, o bom amigo Bill Ellis da IDERA. Então, com isso, vou entregar as chaves ao Dr. Robin Bloor, que irá levá-lo embora.
Dr. Robin Bloor: Sim, como Eric estava dizendo, o tempo em que fomos informados pela primeira vez pelo SAP HANA estava de volta há muitos anos, agora. Mas foi muito interessante, esse tempo em particular foi muito interessante. Tínhamos encontrado uma ou duas empresas que, de uma maneira ou de outra, ofereciam tecnologia em memória. Ficou bem claro que a memória viria. E realmente não foi até que a SAP se levantou e lançou o HANA de repente. Quero dizer, foi um choque quando vi a SAP fazer isso. Foi um choque, porque eu esperava que fosse de outro lugar. Eu esperava que fosse, você sabe, Microsoft ou Oracle ou IBM ou alguém assim. A ideia de que a SAP estava fazendo isso foi realmente muito surpreendente para mim. Suponho que não deveria ter sido porque a SAP é um dos fornecedores estratégicos e, basicamente, tudo o que acontece no setor vem de um deles.
De qualquer forma, todo o ponto sobre a memória, quer dizer, percebemos, costumávamos falar sobre isso, que assim que você realmente entra na memória - não se trata de colocar dados na memória, é de comprometer-se com o idéia de que a camada de memória é o registro do sistema - assim que você migra o registro do sistema para a memória, o disco começa a se tornar um meio de transferência de um tipo e se torna uma coisa diferente. E eu pensei que era muito emocionante quando isso começou a acontecer. Então, realmente, acabou o disco giratório. O disco giratório em breve estará disponível apenas em museus. Não tenho certeza de quanto tempo isso acontecerá, mas, basicamente, o disco de estado sólido está agora na curva da lei de Moore, já é dez vezes mais rápido que a ferrugem, como eles chamam agora, e logo será mais rápido ainda e isso significa que os casos de uso de disco ficam cada vez menos.
E o fato curioso, DBMS tradicional, na verdade, um monte de software tradicional foi construído para disco giratório, assumiu disco giratório. Ele possuía todos os tipos de recursos de nível físico que foram minuciosamente programados para explorar o disco giratório, tornando a recuperação de dados o mais rápido possível. E tudo isso está sendo lavado. Apenas desaparecendo, você sabe? E então, houve obviamente uma abertura muito - eu não sei, lucrativa, suponho, será no final - para um banco de dados em memória que tentou ocupar a posição que os grandes bancos de dados, Oracle e Microsoft, SQL Server e DB2 da IBM, ele ocupava o espaço na memória e foi muito interessante assistir ao avanço e fazer isso.
Vamos falar sobre a cascata de memória; vale a pena mencionar. É também, a razão de mencionar isso, a razão pela qual eu joguei isso realmente, foi apenas para deixar todo mundo saber, quando eu estou falando sobre memória aqui, todas essas camadas sobre as quais eu estou falando são de fato memória. Mas de repente você percebe que, quando olha para isso, é uma loja hierárquica, não é apenas memória. E, portanto, praticamente tudo o que aprendemos há muito, muito tempo sobre armazenamento hierárquico também se aplica. E isso também significa que qualquer banco de dados na memória precisa navegar por esse caminho, alguns apenas o percorrem na própria RAM, você sabe. E está ficando cada vez maior e maior e agora é medido em megabytes. Mas você tem o cache L1 cem vezes mais rápido que a memória, o cache L2 30 vezes mais rápido que a memória e o cache L3 cerca de 10 vezes mais rápido que a memória. Então, você sabe que há muita tecnologia - bem, uma quantidade razoável de tecnologia - adotou a estratégia de usar esses caches como uma espécie de espaço de armazenamento no caminho para executar as coisas, principalmente a tecnologia de banco de dados. Então, você sabe, essa é uma influência.
Então temos o surgimento do 3D XPoint e do PCM da IBM. E é quase a velocidade da RAM, é basicamente o que esses dois fornecedores estão ostentando. Os casos de uso provavelmente são diferentes. A experiência inicial com isso ainda está para ser concluída. Não sabemos como isso afetará o uso da RAM e a tecnologia do banco de dados na memória. Você tem RAM versus SSD. Atualmente, a RAM é cerca de 300 vezes mais rápida, mas, é claro, esse múltiplo está diminuindo. E SSD versus disco, que é cerca de 10 vezes mais rápido, se eu entendi. Então, esse é o tipo de situação que você tem. É uma loja hierárquica. Olhando de outra forma, na memória, é claro, é completamente diferente. Portanto, o diagrama superior mostra duas aplicações, ambas talvez acessando um banco de dados, mas certamente acessando dados sobre a oxidação da fiação. E a maneira como você realmente faz as coisas fluírem através da rede, dependendo de quais dependências existem, é ter ETL. Então, isso significa que, você sabe, os dados passam para a ferrugem giratória e depois saem da ferrugem giratória para ir a qualquer lugar e, para chegar a qualquer lugar, voltam à ferrugem giratória, que são três movimentos. E lembre-se de que a memória pode ser cem mil vezes mais rápida que o disco giratório, e você certamente percebe que pegar dados e colocá-los na memória torna tudo muito diferente.
Então, você pode ter pensado que o que aconteceria estaria na tela da tela aqui, você pode ter pensado que, de uma maneira ou de outra, o ETL iria de fato apenas passar de dados para dados na memória. Mas, na realidade, pode não fazer isso; na verdade, você pode ter a situação aqui, onde dois aplicativos podem realmente disparar a mesma memória. Certamente, um banco de dados na memória pode oferecer esse recurso, desde que você tenha o bloqueio e tudo o mais orquestrado em torno dele. Portanto, isso não altera apenas a velocidade das coisas, mas também altera a forma como você configura aplicativos e fluxos de dados inteiros.
Então, é um enorme tipo de impacto. Então, a memória é perturbadora, certo? E devemos entender isso pelo que eu disse. O processamento na memória atualmente é um acelerador, mas vai se tornar a norma. Ele será usado, sendo aplicado de acordo com o valor do aplicativo, e, portanto, é muito, muito interessante, que a SAP realmente saia com uma versão do software ERP que está na memória. E as melhorias de latência de até três ordens de magnitude são inteiramente possíveis e, na verdade, ainda mais do que isso é possível, dependendo de como você o faz. Então, você está obtendo grandes melhorias de velocidade entrando na memória. E o resultado, o S / 4 do SAP HANA - que eles lançaram, acho, bem, as pessoas dizem que ainda está sendo lançado, mas certamente foi lançado no ano passado - é uma mudança de jogo, dada a base de clientes da SAP. Quero dizer, existem 10.000 empresas por aí usando o ERP da SAP e praticamente todas são grandes empresas, você sabe. Então, a idéia de todos eles terem um incentivo para entrar na memória e usar seus fundamentos, porque o ERP quase sempre é aplicativos fundamentais que as empresas estão executando, é apenas uma grande mudança de jogo e será muito interessante. Mas é claro que tudo parece muito bom, mas precisa ser configurado de forma inteligente e precisa ser bem monitorado. Não é tão simples quanto parece.
Dito isto, acho que vou passar a bola para quem é esse cara? Oh, australiano, Dez Blanchfield.
Dez Blanchfield: Muito engraçado. Sempre um ato difícil de seguir, Dr. Robin Bloor. Obrigado por me receber hoje. Então, grande tópico, mas emocionante. Por isso, escolhi uma imagem que sempre me lembro quando pensava no data lake moderno e nos data warehouses corporativos, e nas minhas pequenas jóias de dados. Então aqui eu tenho esse belo lago cercado por montanhas e ondas saindo, e as ondas estão batendo sobre essas rochas. É assim que eu visualizo mentalmente como ela fica dentro de um grande lago de dados atualmente. As ondas são tarefas em lote e análises em tempo real são lançadas nos dados, sendo as pedras. E quando penso nisso como um lago físico, meio que me chama de alerta que, você sabe, a escala dos data warehouses que estamos construindo agora, a razão pela qual criamos essa cunhagem e o termo um data lake é que eles são muito grandes e profundos, e ocasionalmente você pode ter tempestades neles. E quando o fazemos, você sempre precisa resolver o que está criando a tempestade.
Então, no tema dessa coisa, para mim parece que essa chamada de sirene da computação em memória é realmente muito forte e por boas razões. Traz tantos ganhos comerciais e técnicos significativos. Essa é uma discussão por algumas horas em outro dia. Mas a mudança geral para a computação na memória, primeiro quero apenas cobrir como chegamos aqui e o que torna isso possível porque, de certa forma, define a base de onde alguns dos desafios podem estar primeiro e do que precisamos conhecer e em que pensamos, em nosso mundo de nos afastarmos do antigo disco giratório tradicional que contém dados e sermos paginados dentro e fora do disco, para a memória, a falta de memória e as CPUs, agora estamos apenas removendo quase uma dessas camadas inteiras, sendo o disco giratório. Porque lembre-se, nos primeiros dias da computação, arquitetonicamente, não nos mudamos por muito tempo do mainframe ou do mundo intermediário do que originalmente pensávamos como memória principal e armazenamento de bateria, você sabe.
Como o Dr. Robin Bloor disse, a abordagem que adotamos para mover dados pela arquitetura de computadores não mudou muito durante algum tempo, por algumas décadas, na verdade. Se você pensa no fato de que, tecnicamente, a computação moderna existe, se você perdoa o trocadilho, por cerca de 60 anos, você sabe, seis décadas e mais e é no sentido de que você pode compre uma caixa da prateleira, por assim dizer. A mudança para a nova arquitetura realmente veio à minha mente quando deixamos de pensar em mainframes e midrange, e arquiteturas principais de memória e armazenamento de bateria, para os corajosos ou os supercomputadores, especialmente os gostos de Seymour Cray, onde coisas como backplanes transversais tornou-se uma coisa. Em vez de apenas ter uma rota para mover dados pelo backplane ou pela placa-mãe, como é chamado atualmente. E a memória embutida, você sabe, atualmente, as pessoas não pensam no que realmente significa quando dizem DIMM e SIMM. Mas, o SIMM é uma memória inline única e o DIMM é uma memória dual inline e temos mais complexidade do que isso desde então e existem dezenas de tipos de memória diferentes para coisas diferentes: algumas para vídeo, outras apenas para aplicativos gerais, outras integradas em CPUs.
Portanto, houve essa grande mudança para uma nova maneira pela qual os dados foram armazenados e acessados. Estamos prestes a passar pela mesma mudança em outra geração inteira, mas não tanto no próprio hardware, mas na adoção do hardware na lógica de negócios e na camada de lógica de dados, e é outra grande mudança de paradigma em minha mente. .
Mas apenas brevemente como chegamos aqui. Quero dizer, a tecnologia de hardware melhorou e melhorou drasticamente. Passamos de ter CPUs e a ideia de um núcleo era um conceito bastante moderno. Nós tomamos como certo agora que nossos telefones têm dois ou quatro núcleos e nossos computadores têm dois ou quatro, ou até oito núcleos na área de trabalho e oito e 12 e mais, você sabe, os 16 e 32, mesmo na plataforma do servidor . Mas é realmente algo moderno que os núcleos se tornaram uma capacidade dentro das CPUs e passamos de 32 para 64 bits. Aconteceram algumas coisas importantes: obtivemos velocidades de clock mais altas em vários núcleos, para que pudéssemos fazer as coisas em paralelo e cada um desses núcleos pudesse executar vários threads. De repente, conseguimos executar muitas coisas nos mesmos dados ao mesmo tempo. O espaçamento de endereços de sessenta e quatro bits nos deu até dois terabytes de RAM, o que é um conceito fenomenal, mas é uma coisa agora. Essas arquiteturas de backplane de caminhos múltiplos, você sabe, placas-mãe, era uma vez, você só podia fazer as coisas em uma direção: para trás e para frente. E como nos dias em que a computação Cray e alguns dos designs de supercomputadores da época e agora em computadores de mesa e PCs comuns montados em prateleira, comuns, como desktop, porque na verdade, a maioria dos modernos Agora, os PCs passaram por essa era de micro desktops de mainframe, médio porte e os transformamos novamente em servidores.
E grande parte dessa capacidade de supercomputador, esse design de nível de supercomputador, foi empurrado para componentes comuns prontos para uso. Hoje em dia, você sabe a idéia de pegar PCs montados em rack muito baratos e colocá-los em racks às centenas, senão milhares, e executar software de código aberto neles como Linux e implantar o SAP HANA nele, você sabe, muitas vezes tomamos isso como garantido. Mas isso é uma coisa emocionante muito nova e vem com suas complexidades.
O software também melhorou, principalmente o gerenciamento de memória e o particionamento de dados. Não vou entrar em muitos detalhes sobre isso, mas se você observar a grande mudança nos últimos 15 anos ou menos, como a memória é gerenciada, principalmente os dados na RAM e como os dados são particionados na RAM, para que, como o Dr. Robin Bloor indicou anteriormente ou faça alusão, você sabe, as coisas possam ler e escrever ao mesmo tempo sem impactar uma à outra, em vez de ter tempos de espera. Muitos recursos muito poderosos, como compactação e criptografia no chip. A criptografia está se tornando uma coisa mais importante e não precisamos fazer isso necessariamente no software, na RAM, no espaço da CPU, agora que realmente acontece nativamente no chip. Isso acelera as coisas dramaticamente. E distribuímos o armazenamento e o processamento de dados, novamente, coisas que uma vez assumimos serem coisas de supercomputadores e processamento paralelo, agora assumimos isso como garantido no espaço de empresas como SAP HANA, Hadoop e Spark e assim por diante.
Portanto, o ponto principal é a computação de alto desempenho, que os recursos de HPC chegaram à empresa e agora a empresa está desfrutando dos benefícios que advêm dos ganhos em desempenho e espaço tecnológico, benefícios técnicos e ganhos comerciais, porque, você sabe, o tempo reduzido de valor é reduzido drasticamente.
Mas uso a imagem de uma história que li há algum tempo de um cavalheiro que construiu um gabinete para PC a partir de Lego, porque sempre me vem à mente quando penso em algumas dessas coisas. E é isso, parece uma ótima idéia no momento em que você começa a construí-lo, e então você passa pela metade do caminho e percebe que é realmente muito difícil juntar todos os pedaços de Lego e criar uma coisa sólida, sólida o suficiente colocar uma placa-mãe e assim por diante, criará um gabinete para um computador pessoal. E, eventualmente, você percebe que todos os pequenos pedaços não estão se encaixando direito e você precisa ter um pouco de cuidado com os pequenos pedaços que ficam juntos para torná-los sólidos. E é uma ideia muito fofa, mas é uma chamada de alerta quando você chega no meio do caminho e percebe: "Hmm, talvez eu devesse ter comprado um gabinete para PC de US $ 300, mas vou terminar agora e aprender algo com ele".
Para mim, é uma ótima analogia de como é criar essas plataformas muito complexas, porque é muito bom construí-las e acabar com um ambiente em que você tem roteadores, switches, servidores e racks. E você tem CPUs, RAM e sistema operacional agrupados. E você coloca algo como o HANA em cima para o processamento distribuído na memória, armazenamento e gerenciamento de dados. Você constrói a pilha do SAP em cima disso, obtém os recursos do banco de dados e carrega seus dados e sua lógica de negócios e começa a aplicar algumas leituras, gravações e consultas e assim por diante. Você precisa manter o controle das E / S e planejar as coisas, gerenciar as cargas de trabalho, a multilocação e assim por diante. Essa pilha se torna muito complexa, muito rapidamente. Essa é uma pilha complexa por si só, se estiver apenas em uma máquina. Multiplique isso por 16 ou 32 máquinas, tornando-se muito, muito trivial. Quando você multiplica centenas e, eventualmente, milhares de máquinas, passando de 100 terabytes para a escala de petabytes, é um conceito assustador e essas são as realidades com as quais estamos lidando agora.
Então, você acaba tendo algumas coisas que também ajudaram a mudar esse mundo, e esse espaço em disco ficou ridiculamente barato. Era uma vez que você gastava de 380 a 400 mil dólares em um gigabyte de disco rígido quando era um tambor enorme do tamanho de um - algo que precisava de uma empilhadeira para buscá-lo. Hoje em dia, reduz-se a, mais ou menos, um ou dois centavos por gigabyte de espaço em disco comum. E a RAM fez a mesma coisa. Essas duas curvas J nesses dois gráficos, a propósito, têm uma década cada, portanto, em outras palavras, estamos observando dois blocos de 10 anos, 20 anos de redução de preço. Mas eu as quebrei em duas curvas em J porque, eventualmente, a da direita se tornou uma linha pontilhada e você não podia ver os detalhes, então eu a redimensionei. Um gigabyte de RAM há 20 anos era algo na ordem de seis milhões e meio de dólares. Hoje em dia, se você paga mais de três ou quatro dólares por um gigabyte de RAM por hardware comum, está sendo roubado.
Essa queda significativa na redução de preços nas últimas duas décadas significa que agora podemos ir além do espaço em disco e entrar diretamente na RAM, não apenas no nível de megabytes, mas agora no nível de terabytes e tratar a RAM como se fosse um disco. O desafio disso, no entanto, era que a RAM era nativamente efêmera - isso significa algo que dura por um curto período de tempo -, então tivemos que criar formas de fornecer resiliência a esse espaço.
E, portanto, o que quero dizer aqui é que a computação na memória não é para os fracos de coração. Fazer malabarismos com esses dados na memória em grande escala e o processamento em torno deles é um desafio interessante; como indiquei anteriormente, não é para os fracos de coração. Portanto, uma coisa que aprendemos com essa experiência com a computação em memória de grande escala e alta densidade é que a complexidade que criamos gera riscos em várias áreas.
Mas vejamos isso do ponto de vista de monitoramento e resposta. Quando pensamos nos dados, eles começam no espaço em disco, ficam nos bancos de dados em discos, os empurramos para a memória. Quando estiver na memória e distribuído e houver cópias, podemos usar muitas cópias e, se houver alguma alteração, ela poderá ser refletida no nível da memória, em vez de ter que ligar e desligar o backplane em dois níveis diferentes, entra e sai da memória. Acabamos com essa plataforma de hardware em escala hiperativa que nos permite fazer isso agora. Quando falamos de hipercalibração, é mais difícil em níveis ridiculamente densos e em memória de alta densidade, contagens de CPUs e núcleos e threads muito altos. Agora, temos patologias de rede muito altamente complexas para dar suporte a isso, porque os dados precisam se mover pela rede em algum momento para passar entre os nós e os clusters.
Portanto, acabamos com a redundância de falhas do dispositivo se tornando um problema e precisamos monitorar os dispositivos e partes dele. Temos que ter redundância resiliente de falhas de dados incorporada nessa plataforma e monitorá-la. Temos que ter a resiliência de banco de dados distribuída incorporada, para monitorar a plataforma de banco de dados e empilhar dentro dela. Temos que monitorar o agendamento de processamento distribuído, o que está acontecendo em alguns processos até a pesquisa e a consulta, o caminho que a consulta toma e a maneira como a consulta está sendo estruturada e executada. Como é, alguém fez um SELECT * em "blah" ou realmente fez uma consulta muito inteligente e bem estruturada que lhes dará a quantidade mínima nominal de dados que atravessa a arquitetura no backplane? Temos cargas de trabalho multilocatárias, vários usuários e vários grupos executando a mesma ou várias cargas de trabalho e trabalhos em lotes e agendamento em tempo real. E temos essa mistura de processamento em lote e em tempo real. Algumas coisas acontecem regularmente - de hora em hora, diariamente, semanalmente ou mensalmente - outras estão sob demanda. Alguém pode estar sentado lá com um tablet que deseja fazer um relatório em tempo real.
E, novamente, chegamos a esse ponto, que a complexidade que surge neles não é apenas um desafio agora, é bastante assustadora. E temos essa realidade para verificar se um único problema de desempenho, apenas um problema de desempenho por si só, pode impactar todo o ecossistema. E assim, acabamos com esse desafio muito divertido de descobrir, bem, onde estão os impactos? E nós temos esse desafio: estamos sendo reativos ou proativos? Estamos assistindo a coisa em tempo real e vendo algo dar errado e reagir a ela? Ou já vimos alguma forma de tendência e percebemos que precisamos participar de forma proativa? Porque a chave é que todo mundo quer algo rápido, barato e fácil. Mas terminamos com esses cenários, o que eu gosto de me referir e minha linha favorita do enigma Donald Rumsfeld - que em minha mente se aplica a todos esses cenários de alta complexidade - e é isso que conhecemos conhecidos porque isso é algo nós projetamos e construímos e funciona como planejado. Temos incógnitas conhecidas porque não sabemos quem está executando o quê, quando e onde, se for sob demanda. E temos incógnitas desconhecidas e essas são as coisas que precisamos monitorar e verificar. Porque a realidade é, todos sabemos, você não pode gerenciar algo que não pode medir.
Portanto, para ter as ferramentas certas e a capacidade certa para monitorar nosso agendamento de CPU, procure tempos de espera, descubra por que as coisas estão tendo que esperar nas filas de agendamentos nos pipelines. O que está acontecendo na memória, que tipo de utilização está sendo executada, que tipo de desempenho estamos ficando sem memória? O material está sendo particionado corretamente, está sendo distribuído, temos nós suficientes mantendo cópias dele para lidar com as cargas de trabalho que estão sendo lançadas nele? O que está acontecendo com a execução de processos fora dos processos do sistema operacional? Os próprios trabalhos em execução, os aplicativos individuais e os daemons apoiando-os? O que está acontecendo dentro desses processos, particularmente a estruturação de consultas e como essas consultas estão sendo executadas e compiladas? E a saúde desses processos em toda a pilha? Você sabe, novamente, os tempos de espera, está agendando corretamente, está tendo que esperar, onde está esperando, está aguardando leituras de memória, E / S, CPU, E / S através da rede para o usuário final ?
E então, voltando ao ponto que acabei de mencionar rapidamente antes de encerrar, é isso, como estamos abordando a resolução de problemas e os tempos de resposta a eles? Estamos assistindo em tempo real e reagindo às coisas, que é o cenário menos ideal, mas mesmo assim, é melhor fazer isso do que não saber e ter o telefone da central de suporte e dizer que algo deu errado e precisamos rastrear isso ? Ou estamos fazendo isso de forma proativa e estamos olhando para o que está por vir? Então, em outras palavras, estamos vendo que estamos com pouca memória e precisamos adicionar mais nós? Estamos analisando tendências, planejando capacidade? E em tudo isso, estamos monitorando os tempos históricos de execução e pensando no planejamento da capacidade ou estamos assistindo em tempo real e reagendando proativamente e fazendo o balanceamento de carga? E estamos cientes das cargas de trabalho que estão sendo executadas em primeiro lugar? Sabemos quem está fazendo o que em nosso cluster e por quê?
Os cálculos na memória são muito poderosos, mas com esse poder é quase uma daquelas coisas, como uma arma carregada e você está jogando munição ao vivo. Você pode eventualmente dar um tiro no pé se não tomar cuidado. Portanto, esse poder da computação na memória significa apenas que podemos executar muito mais e mais rapidamente em conjuntos de dados discretos e muito distribuídos. Mas então isso tem uma demanda maior sendo direcionada aos usuários finais. Eles se acostumam com esse poder e querem isso. Eles não esperam mais que os trabalhos levem semanas para serem executados e os relatórios sejam exibidos em papel velho comum. Além disso, temos a manutenção diária em torno de correções, atualizações e upgrades. E se você pensa em processar 24 horas por dia, sete dias por semana, com computação na memória, gerenciar esses dados, gerenciar as cargas de trabalho, tudo está na memória, tecnicamente em plataforma efêmera, se começarmos a aplicar patches, atualizações e atualizações no lá, isso também traz uma série de outros desafios de gerenciamento e monitoramento. Precisamos saber o que podemos colocar offline, quando podemos atualizá-lo e quando o colocamos novamente online. E isso me leva ao meu ponto final, ou seja, que à medida que obtemos mais e mais complexidade nesses sistemas, não é algo que um humano possa fazer apenas chupando o polegar e puxando mais a orelha. Não há mais nenhuma espécie de sentimento de intestino. Nós realmente precisamos das ferramentas apropriadas para gerenciar e fornecer esse alto nível de desempenho no gerenciamento de computação e dados.
E com isso em mente, vou passar para o nosso amigo da IDERA e ouvir como eles enfrentaram esse desafio.
Bill Ellis: Muito obrigado. Estou compartilhando minha tela e aqui vamos nós. Portanto, é realmente humilhante considerar apenas toda a tecnologia e todas as pessoas que vieram antes de nós para disponibilizar essas coisas disponíveis em 2017. Falaremos sobre a análise de carga de trabalho do SAP HANA - basicamente, uma solução de monitoramento de banco de dados: abrangente, sem agente, fornece tempo real e cria um histórico, para que você possa ver o que aconteceu no passado. O SAP S / 4 HANA oferece o potencial de melhor, mais rápido e mais barato. Não estou dizendo que é barato, estou apenas dizendo que é menos caro. Tradicionalmente, o que aconteceu era que você teria uma instância principal de produção - provavelmente em execução no Oracle em uma loja maior, potencialmente SQL Server - e então você usaria esse processo ETL e teria várias versões da verdade . E isso é muito caro, porque você estava pagando por hardware, sistema operacional e licença Oracle para cada um desses ambientes individuais. Além disso, você precisaria ter pessoas para reconciliar uma versão da verdade com a próxima versão da verdade. E, portanto, esse processamento ETL de várias versões era apenas lento e muito, muito complicado.
E assim, o HANA, basicamente uma instância do HANA, pode potencialmente substituir todas essas outras instâncias. Portanto, é mais barato porque é uma plataforma de hardware, um sistema operacional, em vez de múltiplos. E assim, o S / 4 HANA, na verdade, muda tudo e basicamente você está olhando para a evolução do SAP do R / 2 para o R / 3, os vários pacotes de aprimoramento. Agora, o sistema legado está disponível até 2025, então você tem oito anos até ser realmente forçado a migrar. Embora vejamos pessoas, você sabe disso, porque sabem que está chegando e, eventualmente, você sabe, o ECC estará rodando no HANA e, portanto, você realmente precisa estar preparado para isso e entender a tecnologia.
Portanto, um banco de dados, sem processos ETL, sem cópias que devem ser reconciliadas. Então, mais uma vez, mais rápido, melhor e mais barato. HANA está na memória. A SAP fornece o software, você fornece o hardware. Não há tabelas agregadas. Uma das coisas que eles sugerem quando você pensa sobre isso é que não quer entrar nisso, vamos comprar o maior servidor disponível. Eles sugerem que você dimensione corretamente seu cenário SAP com antecedência e basicamente dizem que não migram 20 anos de dados. Eu acho que o arquivamento é algo que é subutilizado em TI, meio que em geral, não apenas nas lojas SAP. E a próxima coisa é que a SAP passou muito tempo reescrevendo seu código nativo para não usar SELECT *. SELECT * retorna todas as colunas da tabela e é particularmente caro em um banco de dados colunar. E, portanto, não é uma boa ideia para o SAP HANA. Portanto, para lojas com muita personalização, muitos relatórios, é algo que você deseja procurar e especificar nomes de colunas à medida que avança na migração de tudo para o HANA.
Gostamos de dizer que o HANA não é uma panacéia. Como todos os bancos de dados, todas as tecnologias, ele precisa ser monitorado e, como mencionado anteriormente, você precisa de números para gerenciar excesso, medição por medida. E uma das coisas de que falo na área do IDERA é que toda transação comercial interage com o sistema de registro e, neste caso, será o HANA. E assim, o HANA se torna a base para o desempenho de suas transações SAP, a experiência do usuário final. E assim, é vital que ele continue funcionando na velocidade máxima. Torna-se um ponto único de falha e, ao conversar com as pessoas, isso pode surgir onde você tem um usuário final e talvez esteja usando esses dados em tempo real e eles tenham uma consulta ad hoc que potencialmente não é bastante certo. Talvez eles não estejam ingressando em tabelas e tenham criado uma associação externa, um produto partidário e basicamente consumindo muitos recursos. Agora, o HANA reconhecerá isso eventualmente e matará essa sessão. E há a parte crucial da nossa arquitetura que permitirá capturar isso na história, para que você possa ver o que aconteceu no passado e reconhecer essas situações.
Então, vamos dar uma olhada na análise de carga de trabalho do SAP HANA. Esta é a versão 1, por isso estamos convidando você a se juntar a nós nessa jornada, e este é um produto da IDERA. É abrangente, mas simples. Tempo real com tendências. Integridade do host, integridade da instância. Nós rastreamos os estados de espera, as consultas SQL, consumidores de memória e serviços. Portanto, é assim que a GUI se parece e você pode ver imediatamente que está habilitado para a Web. Na verdade, eu abri esta solução em execução ao vivo no meu sistema. Há algumas coisas cruciais que você deseja dar uma olhada. Nós dividimos em áreas de trabalho diferentes. O tipo mais crucial é o que está acontecendo no nível do host a partir da utilização da CPU e da memória. Você definitivamente não quer chegar a um ponto de vista de trocar ou debater. E então você trabalha basicamente o que está acontecendo nas tendências, desde o tempo de resposta, usuários, instruções SQL, ou seja, o que está impulsionando a atividade no sistema.
Uma das coisas com o IDERA é que, você sabe, nada acontece em um banco de dados até que haja atividade. E essa atividade são instruções SQL que vêm do aplicativo. Portanto, medir as instruções SQL é absolutamente vital para poder detectar a causa raiz. Então, vamos em frente e detalhar. Assim, no nível do host, podemos realmente dar uma olhada na memória, rastrear ao longo do tempo, na utilização da CPU do host. Volte, você pode olhar para as instruções COBSQL. Agora, uma das coisas que você verá no nosso lado da arquitetura é que essas informações são armazenadas fora do HANA; portanto, se algo acontecesse com o HANA, basicamente capturamos informações até, Deus o livre, uma situação de indisponibilidade . Também podemos capturar tudo o que acontece no sistema para que você tenha uma visibilidade clara. E uma das coisas que faremos é apresentar as instruções SQL em ordem ponderada. Então, isso levará em consideração o número de execuções e, portanto, esse é o consumo agregado de recursos.
E assim você pode obter métricas individuais aqui - quando essa instrução SQL foi executada? E então o consumo de recursos é amplamente impulsionado pelo plano de execução e, portanto, podemos capturá-lo continuamente. HANA está na memória. É altamente paralelo. Ele possui índices primários em todas as tabelas, que algumas lojas optam por criar um índice secundário para resolver certos problemas de desempenho. E, portanto, saber o que aconteceu com o plano de execução para determinadas instruções SQL pode ser muito valioso. Também veremos os serviços, consumo de memória mais uma vez, mapeados ao longo do tempo. A arquitetura: portanto, esta é uma solução independente que você pode baixar do nosso site e a arquitetura é habilitada para a web.
Você pode ter vários usuários conectados a uma instância específica. Você pode monitorar instâncias locais do SAP HANA. E mantemos um histórico contínuo de quatro semanas em nosso repositório e é autogerenciado. Para implantar isso, é bastante simples. Você precisa de um servidor Windows. Você precisa fazer o download. A maioria dos servidores Windows possui uma estrutura .NET interna e é fornecida com uma licença. E, então, você acessaria o assistente de instalação, que é conduzido pelo Setup.exe, que abriria uma tela, o contrato de licença, e você simplesmente trabalharia esse esquema clicando em "Avançar". E então, onde você gostaria que o HANA ser instalado? A seguir, estão as propriedades do banco de dados, e essa será sua conexão com o SAP HANA, portanto, esse é o monitoramento sem agente da instância do HANA. E então vamos basicamente dar uma prévia, esta é a porta na qual nos comunicamos por padrão. Clique em "Instalar" e, basicamente, inicia o HANA e você começa a construir o histórico. Portanto, apenas um pouco das informações da tabela de tamanhos. Podemos monitorar até 45 instâncias do HANA, e você deve usá-lo em uma escala móvel para determinar o número de núcleos, memória e espaço em disco necessários. E isso pressupõe que você tenha um histórico completo de quatro semanas.
Assim, como uma rápida recapitulação, estamos analisando a integridade do servidor, a integridade da instância, a utilização da CPU / memória. Quais são os consumidores de memória, quais são os direcionadores de atividades, quais são os serviços? As instruções SQL são vitais - quais são os estados de execução? Mostre-me os planos de execução, quando as coisas foram executadas, fornecem tendências? Isso lhe dará em tempo real e uma história do que aconteceu. E como mencionei, porque nossa história é separada da HANA, vamos capturar coisas que atingiram o tempo limite e foram eliminadas da história da HANA. Para que você possa ver o verdadeiro consumo de recursos em seu sistema por causa do histórico separado.
Então, como eu mencionei, o site da IDERA, em Produtos, você pode encontrar isso facilmente. Se você quiser tentar isso, certamente será bem-vindo. Veja como ele fornece informações para você e há informações adicionais nesse site. Portanto, todas as partes interessadas estão mais do que felizes em entrar nisso. Agora, nos produtos do portfólio oferecidos pela IDERA, há também um monitor de transações SAP ECC, chamado de Precise for SAP. E o que faz é - se você estiver usando o portal ou apenas o ECC direto - ele realmente capturará a transação do usuário final do clique no disco, até a instrução SQL e mostrará o que está acontecendo.
Agora, estou mostrando apenas uma tela de resumo. Há algumas sugestões que eu quero que você tenha nessa tela de resumo. É o tempo de resposta do eixo Y, o tempo do eixo X mais o dia, e nessa exibição de transação, mostraremos o tempo do cliente, o tempo de espera, o tempo do código ABAP e o tempo do banco de dados. Podemos capturar IDs de usuário final, códigos T e você pode realmente filtrar e mostrar servidores através de uma transação específica atravessada. E assim, muitas lojas executam o front-end do cenário no VMware, para que você possa medir o que está acontecendo em cada um dos servidores e entrar em análises muito detalhadas. Portanto, essa visão de transação é para a transação do usuário final em todo o cenário do SAP. E você pode descobrir isso em nosso site, em Produtos APM Tools, e essa seria a solução SAP que temos. A instalação para isso é um pouco mais complicada, por isso não é apenas o download e a tentativa, como fizemos no HANA. É algo em que trabalharíamos juntos para fazer, projetar e implementar a transação geral para você.
Portanto, apenas uma terceira análise rápida da carga de trabalho do SAP HANA, é abrangente, sem agente e em tempo real, oferece um histórico. Oferecemos a capacidade de baixar e experimentar no seu site.
Então, com isso, vou passar o tempo de volta para Eric, Dez e Dr. Bloor.
Eric Kavanagh: Sim, talvez Robin, alguma pergunta sua e depois Dez depois de Robin?
Dr. Robin Bloor: Ok. Quero dizer, a primeira coisa que gostaria de dizer é que realmente gosto da visualização da transação, porque é exatamente o que eu gostaria nessa situação. Eu trabalhei muito - bem, faz muito tempo - monitorando o desempenho, e esse era o tipo de coisa; não tínhamos gráficos naquela época, mas esse era o tipo de coisa que eu particularmente queria poder fazer. Para que você possa, de uma maneira ou de outra, se injetar onde quer que o problema esteja acontecendo.
A primeira pergunta que tenho é, você sabe, a maioria das pessoas está implementando o S / 4 de uma maneira ou de outra, imediatamente. Quando você se envolveu em uma determinada implementação do S / 4, você descobriu que ela foi bem implementada ou acaba descobrindo coisas que podem fazer o cliente querer reconfigurar? Quero dizer, como tudo isso vai?
Bill Ellis: Bem, cada loja é um pouco diferente. E há diferentes padrões de uso, há diferentes relatórios. Para sites que possuem relatórios ad hoc, quero dizer que é, na verdade, um curinga no sistema. E assim, uma das coisas cruciais é começar a medir e descobrir qual é a linha de base, o que é normal para um site específico, onde é esse site específico, com base em seus padrões de uso, estressando o sistema. E depois faça ajustes a partir daí. Normalmente, a otimização do monitoramento não é única, é realmente uma prática contínua em que você está monitorando, ajustando, aprimorando, melhorando o sistema para que a comunidade de usuários finais possa atender os negócios de maneira mais eficaz.
Dr. Robin Bloor: Ok, então, quando você implementa - quero dizer, eu sei que essa é uma pergunta difícil de responder porque vai variar dependendo do tamanho da implementação - mas quanto recurso a capacidade de monitoramento do IDERA, quanto consome? ? Faz alguma diferença em alguma coisa ou simplesmente não interfere? Como isso funciona?
Bill Ellis: Sim, eu diria que a sobrecarga é de aproximadamente 1 a 3 por cento. Muitas lojas estão muito dispostas a sacrificar isso porque, potencialmente, você poderá comprá-lo de volta em termos de otimização. Depende dos padrões de uso. Se você estiver fazendo um cenário completo, isso depende das tecnologias individuais que estão sendo monitoradas. Então, tipo, a milhagem varia, mas, como conversamos, é definitivamente melhor gastar um pouco para saber o que está acontecendo, do que apenas ficar cego. Em particular, aqui estamos em janeiro, você entra no processamento do final do ano e agrega dados de 12 meses. Você sabe, isso é desempenho, obter relatórios para organizações reguladoras, bancos e acionistas é absolutamente vital em um desempenho crítico dos negócios.
Dr. Robin Bloor: Certo. E apenas uma rápida, da sua perspectiva - porque acho que você está envolvido com toda uma série de sites da SAP - qual é o tamanho do movimento da base de clientes da SAP em direção ao S / 4? Quero dizer, é algo que está sendo, você sabe, que existe uma espécie de avalanche de clientes entusiasmados, ou é apenas uma corrente constante? Como você vê isso?
Bill Ellis: Eu acho que há alguns anos atrás, eu diria que era um dedo do pé. Agora, eu diria que as pessoas estão, tipo, até o joelho. Penso que, dada a linha do tempo, as pessoas estarão realmente imersas no HANA nos próximos anos. E assim, o monitoramento, a transformação, eu acho que a maioria dos clientes está, juntos, na curva de aprendizado. E, portanto, acho que não estamos na avalanche como você afirmou, mas acho que estamos à beira da grande transformação para o HANA.
Dr. Robin Bloor: Ok, então, em termos dos sites que você viu que foram para isso, eles também estão adaptando o HANA para outras aplicações ou, de uma maneira ou de outra, meio que completamente consumidos para fazer isso coisas funcionam? Qual é a imagem aí?
Bill Ellis: Sim, muitas vezes as pessoas integram o SAP a outros sistemas, dependendo de quais módulos e assim por diante, então há um pouco. Ainda não vejo pessoas implementando outros aplicativos no HANA. Certamente é possível fazer isso. E, portanto, está mais relacionado ao cenário da infraestrutura SAP.
Dr. Robin Bloor: Suponho que seria melhor entregá-lo a Dez. Eu tenho consumido seu tempo. Dez?
Dez Blanchfield: Obrigado. Não, está tudo bem. Dois muito rápidos, apenas para tentar definir o tema. O SAP HANA está fora do mercado há alguns anos e as pessoas tiveram a chance de considerá-lo. Se você nos fornecesse uma estimativa aproximada da porcentagem de pessoas que o administram - porque há muitas pessoas executando esse material -, em sua opinião, o que você acha que a porcentagem do mercado que você conhece está atualmente desaparecida? desde implementações SAP tradicionais até SAP on HANA? Estamos olhando para 50/50, 30/70? Que tipo de porcentagem do mercado você vê das pessoas que fizeram a transição e fizeram a mudança agora em relação às pessoas que estão apenas se segurando e esperando que as coisas melhorem ou melhorem ou mudem ou seja qual for o caso?
Bill Ellis: Sim, na verdade, eu colocaria a porcentagem em torno de 20%. SAP tende a ser negócios tradicionais. As pessoas tendem a ser muito conservadoras e, portanto, arrastam os pés. Eu acho que também depende, você sabe, que você está executando o SAP há muito tempo, ou você é um tipo de SMB que talvez tenha implantado o SAP mais recentemente? E assim, existem vários fatores, mas no geral não acho que a porcentagem seja 50/50. Eu diria que 50% são pelo menos intrometidos e têm o HANA rodando em algum lugar do data center.
Dez Blanchfield: O argumento interessante que você nos deu anteriormente foi que isso é um fato consumado em certo sentido e que o relógio está física e literalmente correndo na hora da transição. No processo de fazer isso, você acha que as pessoas consideraram isso? Qual é o senso geral do entendimento popular de que essa é uma mudança de transição na plataforma, não é apenas uma opção, está se tornando o padrão?
E, do ponto de vista da SAP, tenho certeza de que eles estão avançando dessa maneira, porque há uma vantagem competitiva significativa no desempenho, mas também acho que eles estão recuperando o controle da plataforma em vez de passar para um terceiro. banco de dados de terceiros, agora eles estão trazendo de volta para sua própria plataforma. Você acha que as empresas realmente receberam essa mensagem? Você acha que as pessoas entendem isso e agora estão se preparando? Ou ainda é uma coisa pouco clara, você acha, fora do mercado?
Bill Ellis: Eu não acho que o SAP tenha vergonha de se comunicar e as pessoas que foram ao SAPPHIRE viram o HANA em todos os lugares. Então, acho que as pessoas estão bem conscientes, mas a natureza humana é o que é, você sabe, algumas pessoas estão meio que se arrastando um pouco.
Dez Blanchfield: Porque acho que o motivo pelo qual fiz essa pergunta, e você terá que me perdoar, mas é que eu concordo. Eu acho que eles não tiveram vergonha de comunicá-lo. Eu acho que o sinal saiu de várias maneiras. E eu concordo com você - não sei se todo mundo pulou ainda. Você sabe, empresas tradicionais, empresas muito grandes que estão executando isso, ainda estão de várias maneiras, não se esforçando muito, mas apenas tentando lidar com a complexidade da mudança. Porque acho que a única coisa que sua ferramenta, e certamente sua demonstração de hoje destacou, e para mim, uma das principais dicas que eu gostaria que todos que estivessem ouvindo e sintonizados hoje se sentassem e prestassem atenção à reflexão são: você tem uma ferramenta agora que simplificou esse processo em minha mente. Eu acho que há um monte de CIOs muito nervosos e suas equipes sob eles que estão pensando: “Como faço a transição do RDBMS tradicional, sistemas de gerenciamento de banco de dados relacional, que conhecemos há décadas, para um novo paradigma de computação e gerenciamento de armazenamento em um espaço que ainda é relativamente corajoso? ”em minha mente. Mas isso é desconhecido de várias maneiras, e há poucas pessoas que fizeram essa mudança em outras áreas, que não é como se tivessem outra seção de negócios que já mudou a computação na memória. Então, é um movimento de tudo ou nada em suas mentes.
Então, uma das coisas que tirei disso mais do que qualquer coisa - vou lhe fazer uma pergunta em um minuto - é que o medo agora, eu acho, é dissipado de várias maneiras e antes de hoje, se eu fosse um CIO, pensaria: “Bem, como vou fazer essa transição? Como vou garantir a mesma capacidade que temos na plataforma de gerenciamento de banco de dados relacional e nos anos de experiência dos DBAs, para uma nova plataforma na qual não temos as habilidades atualmente? ”Então, minha pergunta é:, você acha que as pessoas entenderam que as ferramentas estão lá agora com o que você está oferecendo e que elas podem, meio que, respirar fundo e suspirar de alívio por a transição não ser tão assustadora quanto antes para esta ferramenta estar disponível? Você acha que as pessoas entenderam isso ou ainda é algo que estão apenas lutando com a transição para a computação na memória e armazenamento na memória versus combinações antigas de NVMe, flash e disco?
Bill Ellis: Sim, há, sem dúvida, muita tecnologia e ferramentas que podem exibir isso graficamente, o que está acontecendo e tornar muito fácil identificar os principais consumidores de recursos. Quero dizer, ajuda a simplificar as coisas e ajuda a equipe de tecnologia a realmente lidar bem. Ei, eles poderão saber o que está acontecendo e entender toda a complexidade. Portanto, absolutamente, as ferramentas do mercado são definitivamente úteis e, por isso, oferecemos análise de carga de trabalho para o SAP HANA.
Dez Blanchfield: Sim, acho que o melhor do que você nos mostrou hoje é que, ao monitorar a parte do hardware, a parte do sistema operacional e até mesmo monitorar parte da carga de trabalho, como você disse, quero dizer, as ferramentas já existem há algum tempo. A parte para mim, particularmente no que diz respeito ao HANA, é que não tivemos necessariamente a capacidade de obter uma lupa e espiá-la e ver o que sua ferramenta faz com o que está acontecendo com as consultas e como elas estão. sendo estruturado e onde está essa carga.
Com as implantações que você viu até agora, considerando que você é literalmente o mais autoritário neste espaço em sua plataforma no mundo, algumas das vitórias rápidas que você viu - você tem algum conhecimento anedótico com o qual pode compartilhar? nós, em torno de alguns dos momentos eureka, os momentos aha, em que as pessoas implantaram o conjunto de ferramentas IDERA, descobriram coisas que não sabiam que estavam em suas plataformas e performances que tiveram. Você tem ótimos exemplos anedóticos de onde as pessoas acabaram de implantá-lo, sem saber realmente o que tiveram e de repente se foi: "Uau, na verdade não sabíamos que estava lá?"
Bill Ellis: Sim, uma grande limitação das ferramentas nativas é que, se uma consulta descontrolada é cancelada, ela libera as informações e, portanto, você basicamente não tem o histórico. Ao armazenarmos o histórico offline, como uma consulta descontrolada, você terá um histórico, saberá o que aconteceu, poderá ver o plano de execução e assim por diante. E assim, isso permite que você ajude a comunidade de usuários finais a operar melhor, escrever relatórios melhor, etc. E assim, a história é algo realmente bom de se ter. E uma das coisas que eu pretendia mostrar é que você pode olhar em tempo real por até quatro semanas e, em seguida, pode ampliar facilmente qualquer período de interesse e expor a atividade motriz subjacente. Ter essa visibilidade é algo muito útil para saber qual gargalo surgiu.
Dez Blanchfield: Você mencionou que é multiusuário, uma vez implantado, e fiquei bastante impressionado com o fato de não ter agente e efetivamente zero contato de várias maneiras. É normal que uma única implantação de sua ferramenta esteja disponível para todos, desde o centro de operações de rede no NOC assistindo a infraestrutura principal que está sustentando o cluster até a equipe de aplicativos e desenvolvimento? É a norma e você implanta uma vez e eles compartilham isso, ou você prevê que as pessoas possam ter instâncias de modelo olhando para diferentes partes da pilha? Como é isso?
Bill Ellis: Portanto, a equipe de base normalmente terá um interesse muito forte nos fundamentos da tecnologia do que está acontecendo no SAP. Obviamente, existem várias equipes que apoiarão paisagens inteiras. A peça HANA é focada apenas nisso. Vou apenas adotar a equipe básica da SAP como os principais consumidores das informações.
Dez Blanchfield: Certo. Parece-me, no entanto, que se eu tenho uma equipe de desenvolvimento ou não apenas no nível do código, mas se eu tenho uma equipe de cientistas ou analistas de dados fazendo um trabalho analítico nos conjuntos de dados, principalmente porque há um impulso significativo para que a ciência de dados seja aplicada a tudo dentro das organizações agora, em minha mente - e me corrija se eu estiver errado -, parece-me que isso será de grande interesse para eles também, porque, de muitas maneiras, Uma das coisas sérias que você pode fazer em um ambiente de data warehouse é desencadear um cientista de dados e permitir que ele comece a fazer consultas ad hoc. Você já teve algum exemplo desse tipo de coisa acontecendo em que as lojas telefonaram para você e disse: “Montamos uma equipe de ciência de dados para a coisa, está doendo muito, o que podemos fazer por eles versus o que estamos fazendo apenas monitoramento e gerenciamento operacional tradicional? ”Isso é mesmo uma coisa?
Bill Ellis: Bem, sim, eu meio que mudaria um pouco isso e cortaria minha resposta seria que, olhando para o desempenho, tendo consciência do desempenho no desenvolvimento da produção de controle de qualidade, você sabe, quanto mais cedo você armazenar, menos problemas, menos surpresas que você tem. Então absolutamente.
Dez Blanchfield: Depois disso, muitas ferramentas com as quais eu já experimentei - e tenho certeza que Robin concordará - muitas ferramentas aqui, se você tem um RDBMS grande, precisa realmente de DBAs qualificados, com profundo conhecimento e experientes. Alguns dos requisitos de infraestrutura e plataforma que acompanham o SAP HANA, porque atualmente são suportados em distribuições específicas, alinhadas a partir de hardware específico e assim por diante, com o melhor de meu conhecimento. Você sabe, existem pessoas com décadas de experiência que não são iguais. O que estou vendo, porém, é que esse não é necessariamente o requisito desta ferramenta. Parece-me que você pode implantar sua ferramenta e apresentá-la a alguns rostos relativamente novos e dar-lhes o poder imediatamente para encontrar coisas que não estão funcionando bem. É o caso de haver uma curva de aprendizado bastante curta para acelerar isso e obter algum valor da implantação? Sabe, meu senso geral é que você não precisa ter 20 anos de experiência ao dirigir uma ferramenta para ver o valor imediatamente. Você concorda que é esse o caso?
Bill Ellis: Ah, absolutamente, e a seu ponto, acho que muito do sucesso de uma implantação depende realmente do planejamento e arquitetura do ambiente SAP HANA. E, sem dúvida, há muita complexidade, muita tecnologia em que é construída, mas tudo se resume a monitorar os padrões de uso do que está acontecendo. Portanto, embora seja mais complexo, de certa forma é empacotado e um pouco simplificado. Isso é muito pobre.
Dez Blanchfield: Sim, então antes de devolver a Eric, porque sei que ele tem algumas perguntas, principalmente algumas que surgiram de perguntas e respostas que pareciam interessantes, e estou ansioso para ouvir a resposta. Jornada tradicional para alguém - você mencionou anteriormente que pode obtê-lo, pode baixá-lo e experimentá-lo. Você pode simplesmente recapitular isso rapidamente para as pessoas ouvindo hoje ou para as pessoas que poderão reproduzi-lo mais tarde? Quais são as duas ou três etapas rápidas para colocar as mãos em uma cópia, implantá-la e experimentá-la em seus ambientes antes de comprá-la? Como é isso? Quais são os passos para isso?
Bill Ellis: Sim. Portanto, acesse o IDERA.com e acesse Produtos e você verá a Análise de Carga de Trabalho para SAP HANA. Existe uma página de download. Acho que eles pedirão algumas informações de contato e o produto é fornecido com uma chave de licença, para que você possa instalá-lo com o Setup.exe e começar a rolar muito rapidamente.
Dez Blanchfield: Então, eles podem acessar o seu site, fazer o download. Lembro-me de olhar para isso há algum tempo e verifiquei ontem à noite também, você pode solicitar uma demonstração, de memória, em que alguém da sua equipe o guiará por meio disso? Mas você pode baixá-lo gratuitamente e implantá-lo localmente em seu próprio ambiente, no seu próprio tempo, não é?
Bill Ellis: Sim.
Dez Blanchfield: Excelente. Bem, acho que, mais do que tudo, é provavelmente o que eu pessoalmente aconselho as pessoas a fazer, é pegar uma cópia do site, pegar algumas das documentações lá porque sei que há muito conteúdo bom para fazer isso, e apenas tente. Coloque-o no seu ambiente e veja o que você encontra. Eu suspeito que, depois de dar uma olhada nos ambientes do SAP HANA com a ferramenta IDERA, você encontrará coisas que você realmente não sabia que estavam lá.
Olhe, muito obrigado por isso e obrigado pelo tempo apenas para as perguntas e respostas com Robin e eu. Eric, vou voltar para você, porque sei que algumas perguntas e respostas também são feitas pelos nossos participantes.
Eric Kavanagh: Sim, apenas uma rápida aqui. Então, um dos participantes faz um comentário muito bom aqui, falando sobre como as coisas estão mudando. Dizendo no passado, a memória estava sufocando, diminuindo a velocidade da paginação frequente, atualmente a CPU está sufocando com muitos dados na memória. Você sabe, há problemas de rede. Sempre será um alvo em movimento, certo? Como você vê a trajetória atual em termos de onde os gargalos serão e onde você precisará focar sua atenção?
Bill Ellis: Sim. Até você medir, é difícil saber. Uma das coisas sobre as instruções SQL é que elas serão as motivadoras do consumo de recursos. E, portanto, na circunstância de você ter um grande consumo de memória ou CPU, você poderá descobrir qual atividade causou esse consumo de recursos. Agora, você não necessariamente quer matá-lo, mas também quer estar ciente disso e, mais ou menos, o que está acontecendo, com que frequência isso acontece, etc. Ainda somos novos em termos de abordar todo o conjunto ou livro de receitas de respostas a diferentes circunstâncias. E assim, é uma ótima pergunta e o tempo dirá. Teremos mais informações com o passar do tempo.
Eric Kavanagh: É isso. Bem, vocês estão em um espaço muito interessante. Acho que você verá muita atividade nos próximos meses e nos próximos anos, porque sei que o SAP, como você sugeriu em nossa chamada de conteúdo, proporcionou uma longa e agradável rampa para as pessoas fazerem a transição para HANA. Mas, no entanto, essa rampa tem um fim e, em um determinado momento, as pessoas terão que tomar algumas decisões sérias, então quanto mais cedo melhor, certo?
Bill Ellis: Absolutamente.
Eric Kavanagh: Certo, pessoal, passamos mais uma hora aqui na Hot Technologies. Você pode encontrar informações on-line, insideanalysis.com, também techopedia.com. Concentre-se nesse site para obter muitas informações interessantes, incluindo uma lista de todos os nossos arquivos desses webcasts anteriores. Mas pessoal, um grande obrigado a todos vocês, aos nossos amigos da IDERA, a Robin e, claro, Dez. E nos encontraremos na próxima semana, pessoal. Mais uma vez obrigado pelo seu tempo e atenção. Cuidar. Tchau tchau.
