Arquivo por categoria: HANA

nov 21 2016

Dicas e Truques na Instalação do SAP HANA Express Edition

Olá Pessoal,

Resolvi escrever este post por 3 motivos:

O primeiro deles é que já que me considero um cara altruista, quero evitar que muitos de vocês sofram o que eu sofri (ok, sem drama! Rs) ao instalar o  SAP HANA Express Edition;

O segundo para tentar manter este blog vivo…

E o terceiro, bom, o terceiro foi ser bem pratico e direto ao ponto para quem procura o pulo do gato de maneira resumida, então para atingir estes objetivos o que fiz é disponibilizar tudo o que você precisa para fazer funcionar em apenas 1 link:

https://1drv.ms/f/s!AtsPYvmpca5uk5dJD5_m6bNw8NZaQg

Clique no item “download” e ele ira juntar tudo em um ZIP e iniciar o download

001

O link acima possui:

  1. O VMPlayer 12.5 Workstation free -> Para rodar a maquina virtual do SAP HANA Express Edition;
  2. O Eclipse Neon;
  3. As maquinas virtuais do Hana;
  4. Manual( em Inglês ) passo-a-passo com maiores detalhes da instalação;

O manual seria perfeito se não focasse apenas nas instruções de instalação do SAP HANA Express Edition mas também nas intruções dos Hypervisors… Portanto, se quiser ter sucesso pode seguir o manual, apenas certifique-se antes de marcar a opção abaixo no VMPlayer:

002

003

Normalmente a primeira opção vem marcada e o correto(pelo ao menos a que funcionou comigo) é a Segunda. Vejo o que acontece antes de marcar e depois…

Antes de Marcar:

004

Depois de Marcar:

Repare que até o IP da máquina mudou…

005

É isso ai pessoal, espero ter ajudado vocês…

Até o próximo post…

Will

maio 15 2014

Compressão de dados do HANA

Olá pessoal !!

Neste post falaremos de algo muito importante que normalmente é subjugado, mas do meu ponto de vista é um ótimo recurso para justificar um investimento no HANA e aumentar o ROI e a diminuir o TCO: A compressão de dados.

Ah legal, todos ouvem falar disso e qualquer pessoa com um pouco de conhecimento em informática sabe do que se trata… economizar espaço em disco, mas no caso do HANA economizar espaço em memória RAM, o que pode trazer uma maior custo benefício ainda visto que memória RAM ainda é muito mais cara que memória em disco, embora tenha caído drasticamente nestes últimos anos, permitindo desenvolvimento de plataformas in-memory como o SAP HANA.

A logica é simples: Digamos que a sua empresa já esteja chegando perto do limite de storage para o DW que é de 10 TB e ela já esteja com 9 e isso logicamente é um sinal vermelho para os gestores de TI serão necessários investimentos em algumas baterias de disco para duplicar essa capacidade que acredito custar no mínimo algo em torno de R$ 100 mil se sua empresa for mais ousada então e quiser colocar uma bateria de SSD então.. acho que quase podemos duplicar esse valor! Me corrijam se eu estiver errado mas foi o que conseguir descobrir em uma rápida pesquisa no Google… Como o SAP HANA pode comprimir no mínimo 3x os dados da armazenados no DW por exemplo então se sua empresa optasse por investir no HANA ela teria os seus 9 TB reduzidos a 3 podendo chegar a menos de 1 TB e com isso ajudar já ganhar um ótimo “desconto” com o dinheiro que iria ser gasto em baterias novas… Excelente não? Ou seja, bastaria vc investir em um servidor de 6 TB para ter essa capacidade duplicada e o que o HANA conseguisse comprimir além de 3x ficaria de “contingencia” por exemplo.

Mas logicamente nenhuma empresa bem gerida gosta de desperdiçar dinheiro e o ideal seria investir com “precisão”, e como pra tudo se tem um jeito nessa vida, menos pra morte(ainda..!) existe uma maneira que pode ajudar nisso e falaremos mais tarde.

Na verdade compressão em banco de dados não é exatamente uma novidade, outros bancos também utilizam este recurso,  o que faz o HANA ser tão diferenciado nesse ponto são os seus algoritmos de compressão e fazer tudo isso IN-MEMORY tornando o HANA único!!

Mas como funciona?

Neste post falarei apenas da técnica que dá suporte a todas as outras técnicas, pois falando a grosso modo, em cima dela todos outros algoritmos são baseados otimizando ainda mais a compressão e ela é relativamente simples a técnica se chama: Dictionary Encoding.

Vamos nos basear como exemplo uma tabela que contem dados da população mundial, na figura abaixo vemos 2 objetos que são a base dessa técnica o dictionary e o attribute vector:

 

img00

 

Na imagem acima temos a coluna de nome da tabela e o Dictionary armazena apenas os valores não repetidos e cria um índice para cada valor o “Value ID”.

O Attribute Vector por sua vez faz exatamente um de-para entre os dados da tabela original e o Dictionary e também cria um índice o “position”.

Agora fica tudo mais fácil pois é só converter os dados da tabela original por bits, pois armazenar em bits é muito mais “econômico” do que armazenar no seu formato original, principalmente se o dado do campo for do tipo char a economia é maior ainda.

 

img01

 

 

Vamos fazer de conta que nossa tabela tenha 8 bilhões de linhas e o comprimento do registro seja de 200 bytes, então teremos:

8.000.000.000 x 200 = 1.6 TB

Peguemos o primeiro campo “first name”, para conseguir substituir os dados por bits tem que saber quantos bits são necessários para 49 bytes de dados e assim por diante, conforme tabela acima, para isso usamos uma função logarítmica de base binária:

Log2(5.000.000) = 23

Fazendo este cálculo temos 23 bits que são necessários para armazenarmos os mesmos 49 bytes, agora vamos fazer uma comparação:

Antes:

8.000.000.000 x 49 Bytes = 392.000.000.000 Bytes / 1024 / 1024 / 1024  = 365.1 GB

Depois:

8.000.000.000 x 23 Bits = 184.000.000.000 Bits  / 8 / 1024 / 1024 / 1024 = 21.4 GB

 

WOWW!!! Tivemos uma redução 94% do tamanho, fantástico não? Agora o que será gravado no campo “first name” serão uma sequencia de 23 bits ao invés de “William” por exemplo… Para quem conhece o BW isso se assemelha a usar as “Surrogate IDs” (SIDs) nas dimensões do cubo.

Mas porque então quando fazemos select vem o nome correto ao invés dos bits? Aahh isso ocorre por causa de uma outra técnica chamada “Materialização” mas isso é assunto para outro post 🙂

Não podemos esquecer de somar os espaço necessário ocupado pelo dicionário

49 bytes x 5.000.000 / 1024 / 1024 / 1024  = 0.23 GB

Então finalmente temos:

img02

 

Temos um fator de redução de aproximadamente 17 vezes e o novo tamanho da coluna “first name” consome apenas 6% do tamanho original… excelente!!!

Basta repetirmos esta mesma logica para as outras colunas e chegaremos ao fator de redução da tabela inteira…

Então podemos concluir que o nível de compressão depende não só do do tipo de dado como também de quantas vezes temos valores repetidos em uma determinada coluna, ou melhor, quantos valores distintos temos, bem como a quantidade de registro

A esta razão damos o nome de ENTROPIA.

 

Entropia =

cardinalidade da coluna
cardinalidade da tabela

 

Então quanto MENOR a entropia maiores taxas de compressão teremos e para nossa alegria os dados corporativos armazenados em tabelas, costumam ter baixa entropia em suas colunas, então na maioria dos casos é possível obter taxas de compressão maiores que o mínimo de 3x sugerido pela SAP.

Outras técnicas de compressão como Prefix Encoding, Run-Length Encoding, Cluster Encoding, Indirect Encoding, Delta Encoding são aplicadas em cima destes 3 objetos(a tabela, o Dictionary e o Attribute Vector) normalmente depois da Dictionary Encoding já aplicada, por isso ela é a mais importante e as outras tem um papel de tornar ainda mais eficiente a compressão do HANA tornando uma banco muito especial e maravilhoso nesse sentido.

O que havia falado no inicio do post sobre a decisão reduzir investimento em sizing implementando o HANA e para isso ter a maior precisão possível, pois o principal fator  que define o preço do HANA é a quantidade de memória RAM, então pode ser fazer uma programa que analise cada tabela da empresa aplicando a logica acima:

Primeiro definir quantos valores distintos a para cada coluna de uma determinada tabela

  • Ver o comprimento de cada coluna
  • Fazer os cálculos apresentados usando a função logarítmica
  • E ao final somar o resultados em GB de cada coluna e comparar com o original

 

Pronto! Ao final o programa apresenta um relatório e vc pode ajudar o seu diretor ou gerente de TI a comprar exatamente o tamanho necessário para sua empresa de um servidor HANA, claro que levando em consideração uma contingencia segundo as perspectivas de crescimento por ano dos dados da empresa.ou o Sizing Plan

Se o sistema da sua empresa for o SAP é mais fácil ainda… basta consultar a tabela DD02 e a DD03 para ter o nome de todas as tabelas e seus campos que existem no sistema e ainda otimizar uma busca apenas por tabelas que contenham dados e voilá

Bom, está lançada a idéia… quem sabe no próximo posto eu não dou uma de Papai Noel e presenteie vcs com esse programa em ABAP pronto 😉

Um abraço e até a próxima!

 

Will

out 03 2013

SAP HANA One (Visão Geral)

Olá pessoal, hoje vamos falar sobre SAP HANA One.

O que venha ser o SAP HANA One?

O SAP HANA One é a plataforma do SAP HANA na web. Com ela você pode trabalhar no HANA como um servidor de banco de dados comum com diferença que ele está remotamente na web.

E com isso você pode desenvolver aplicativos usando o HANA com um banco de dados, mas isso é assunto para um outro post…

Eis aqui o passo-a-passo de como fazer. Embora exista alguns posts na internet que já mostrem como fazer, esse é o primeiro em português, com prints e com umas dicas a mais de maneira a tornar o mais fácil possível o processo.

Há outras empresas oferencedo o SAP HANA One, mas neste post iremos mostrar com o AWS da Amazon.

 

Let´s Begin:

1 – Clique aqui para criar uma conta no AWS

2 – Clique aqui para fazer o download do client e do HANA studio

3 – Clique aqui para criar uma chave S na SCN

image10 image01

 

 

Depois de criar o login e ESTIVER LOGADO, siga para o passo 4.

4 – Clique aqui para criar uma licença de desenvolvedor.

As telas a seguir são bastante intuitivas, você deve aceitar a licença.

 

image02

 

image02 imagem03

 

 

Nesta tela é só inserir o numero da conta que você criou no AWS.

image04

 

 

Nesta tela tudo que você precisa fazer é dar um nome para o stack a ser criado. O stack é uma espécie de “lâmina” de servidor onde os recursos serão alocados (CPU, Memória, discos etc…).

image05

 

 

Nesta tela note que escolhi a menor instância, por questões de custo, o ideal é começar com a menor e caso precise, você poderá mudar a qualquer momento no seu console.

 

image06

 

 

Eu não criei nenhum tag e até hoje nunca me facilitou em nada.

image07

 

 

Aqui tem um dica importante com relação aos custos veja o link abaixo destacado em vermelho escrito “Cost” recomendo criar um link em seus favoritos para sempre que alterar a sua instancia ou adicionando discos você tenha uma previsão de quanto vai pagar, mas a frente eu dou um detalhamento deste link..

Após clicar em continue seu stack ficará pronto em menos de 5 minutos.

 

image08

 

 

image09

 

 

Uma vez com o stack pronto, clique em Services e você poderá arrastar os ícones e criar atalhos na sua barra de atalhos.

Clicando no link “EC2” vc irá acessar a próxima tela.

image10

 

 

Clicando nos links destacados podermos descobrir o IP que será usado para conectar ao HANA no através do HANA Studio.

 

image11

 

 

Use o IP abaixo para configurar o arquivo Hosts.

 

image12

 

 

O arquivo Hosts, normalmente fica no caminho C:\Windows\System32\Drivers\etc

image13

 

image14

 

 

Uma vez configurado o arquivo Hosts e instalado o cliente e o HANA Studio no computador, é só conectar ao HANA.

 

image15

 

 

image16

 

 

Nesta tela coloque:

Usuário: SYSTEM
Senha: manager (em minúsculo)

image17

 

 

E Voilà o HANA está conectado!!!

 

image18

 

 

Custos:

Com relação aos custos tenho apenas 3 observações:

1 – Sempre que não estiver usando o HANA, mantenha sua instancia parada. Ainda assim a Amazon cobra um pequeno custo (menos de 6 dólares). Para não haver cobrança nenhuma você deve clicar em “terminate”.

 

image19

 

 

2 – Nunca deixe seu “Elatic IP” unassigned, pois se ele não estiver associado a uma instancia você é cobrado por isso também.

3 – A titulo de exemplo, usando o template padrão no qual o HANA One foi criado, usando 30 GB de disco e 2 horas por dia no mês (ou 60 horas) temos um custo aproximado de 38 dólares.

 

image20

 

 

Acesso ao LINUX a nível de OS:

1 – Você precisará dos 3 arquivos abaixo. Clique aqui para fazer o download do arquivos.

2 – Você deverá ter salvo o arquivo *.pem durante a criação do stack, caso não tenho feito, a exemplo deste post de realizar o download deverá deletar a chave e recriar novamente que após a re-criação será feito o download automaticamente pelo browser.  Lembre-se de guardar em um LOCAL SEGURO para não perder.

 

image21

 

 

image22

 

 

3 – O usuário default do sistema operacional são:

Usuário: hdbadm
Senha: HANAabcd1234

Com eles você pode entrar no sistema e alterar esta senha, parar ou iniciar o banco (somente o banco e não a instancia) direto do HANA Studio com esse usuário e senha ou via linha de comando do Linux, usando o Putty e o arquivo .PEM.
Sinceramente nunca usei, troquei e nunca tive problemas e para ser sincero, quando tentei fazer ocorria um erro e não conseguia acessar.

Acho que um hacker não vai se interessar em descobrir o IP de um servidor de teste de um simples desenvolvedor… mas caso você queira tentar só clicar aqui, seguir as instruções e boa sorte 😉

 

Bom pessoal, agora que o brinquedo está pronto é só brincar!

No próximos posts iremos falar sobre outras maneiras de usar o HANA One e funcionamento interno do HANA.

Abraços e até lá.

 

nov 12 2011

SAP HANA – Conceitos e Arquitetura

No artigo de hoje falaremos mais um pouco sobre um conceito novo de se fazer BI, onde a SAP mais uma vez inovou e está trazendo para o mercado o SAP HANA. Nesse artigo falaremos de conceitos e um pouco de arquitetura para que possamos começar a entender melhor essa
tecnologia que está mudando os conceitos de projetos de BI realizados até hoje.

1 – O que é o SAP HANA?

O nome SAP HANA vem do SAP In-Memory Appliance. O SAP HANA pode ser entendido como uma fonte de dados independente, que permite aos clientes analisar grandes volumes de dados SAP ERP em tempo real.  O SAP HANA é uma combinação de Hardware e Software que integra uma séria de componentes SAP incluindo o SAP In-Memory Database.

2 – Como funciona o SAP In-Memory Database?

O SAP In-Memory Database é um banco de dados híbrido que combina linha com colunas. Ele é otimizado para explorar o processamento paralelo.  O Banco de Dados SAP In Memory é o cerne de ofertas que a SAP disponibiliza nessa tecnologia como o SAP HANA que ajudam os clientes a melhorar a sua eficiência operacional, agilidade e flexibilidade.

3 – Tecnologias de Replicação do SAP HANA

Para que possamos ter relatórios e análise de dados de negócio o SAP HANA exige uma replicação dos dados a partir de um sistema de origem para o SAP In Memory Database. Nessa parte do artigo mostraremos uma visão geral dos possíveis métodos de replicação de dados que estão disponíveis para o SAP HANA 1.0.

A figura acima ilustra a tarefa de carregamento de dados de negócio de um sistema ERP SAP o IMDB (SAP In Memory Database) do SAP HANA.

Existem três métodos para se replicar dados no SAP HANA. Os principais componentes para a replicação de dados em todos os cenários são:

1 – SAP HANA que consiste no IMDB e no SAP In Memory. Interfaces com usuários tais como SAP BO, Dashboards, etc. não fazem parte da arquitetura;

2 – Sistema de origem tais como o SAP ERP;

3 – Componentes de software que suportam diferentes métodos de replicação de dados.

A figura acima apresenta uma visão geral dos três métodos alternativos para a replicação de dados de um sistema fonte para o IMDB. Cada método lida com a replicação de dados necessários de uma forma diferente e, consequentemente, cada método tem vários pontos fortes.
Dependendo do seu campo de aplicação específica e os existentes de um sistema para o IMDB.

Trigger-Based Replication

A Trigger-Based Data Replication Using SAP Landscape Transformation (SLT) Replicator é uma base de captura de alteração de dados em alto nível de abstração no sistema de origem ERP. Esse método de replicação possui os benefícios de ser independente de banco de dados, e também ser paralelizado com os dados alterados no banco de dados em várias tabelas ou segmentado por mudanças em uma grande tabela.

ETL-Based Replication

O ETL-Based Replication são serviços para especificar e carregar os dados de negócio relevantes em um período de tempo definidos a partir de um ERP. Nesse processo pode-se reutilizar a lógica do aplicativo ERP através da leitura ou utilização de extratores dos módulos funcionais da SAP. Além disso, o método baseado em ETL oferece algumas opções para a integração de provedores de dados.

Log-Based Replication

O Log-Based Replication é baseado em uma tabela de log do banco de dados de baixo nível onde a mesma captura todas as modificações nos dados. Este método é dependente do banco de dados. As alterações de dados são propagadas em uma base de dados por transações, que são enviadas ao IMDB.
Cabe ressaltar que esse processo não é capaz de usar paralelismo para a propagação das mudanças nos dados.

4 – Integrações do SAP HANA com os Painéis Gerenciais

Após a instalação de todos os componentes do SAP HANA 1.0, teremos que conectar todos os componentes dos Painéis SAP HANA para que eles possam trabalhar juntos. Para que isso aconteça precisamos estabelecer a conectividade entre os seguintes componentes:

1. SAP HANA box to SAP ERP system

2. SAP HANA box to SAP In-Memory Computing studio

3. SAP HANA box to end user clients

Se estivermos usando os servidores do SAP BO, que não estão no escopo do SAP HANA 1.0, poderemos também fazer as devidas conexões utilizando os seguintes componentes:

1. SAP HANA box to SAP BusinessObjects Enterprise (to use the SAP BusinessObjects BI clients)

2. SAP ERP system to SAP BusinessObjects Data Services (to use Data Services for data replication)

Observem na figura acima que através dos componentes que descrevemos é possível integrar serviços do SAP BO como o Explorer e o Xcelsius ao SAP HANA 1.0.

Bom, espero que tenham gostado do artigo, mais novidades sobre o SAP HANA será postado no blog muito em breve.

Até a próxima.

ago 19 2011

SAP HANA (High Performance Analytic Appliance) – Introdução

Se você esta com dificuldade em acessar os dados com rapidez e em tempo real, a solução pode ser o SAP Hana.

Esta nova modalidade de gerenciamento de dados poderá modificar a forma com que você acesse os dados, pois ele te dará uma velocidade muito maior (aproximadamente 3600 vezes) que um gerenciador de banco de dados convencional e com a vantagem de poder trabalhar facilmente com uma quantidade de dados enorme. Este ganho só é viável pelas características do hardware e software que foram implementados nesta nova ferramenta analítica de negócio. Seguem as características.

– A partir da forma com que os dados são acessados (In-Memory Computing), a velocidade em extrair estes dados se tornou muito grande;
– A nova arquitetura permitiu com que a forma de calcular os dados fosse flexível e poderosa;
– Suporte ao acesso de MDX e SQL para praticamente qualquer fonte de dados, incluindo o universo e o SAP BW;
– Existe um repositório persistente para armazenar as views contendo informações de negocio.

Os componentes expostos acima provêem um ambiente ideal para a análise do negócio, possibilitando a organização em extrair as informações de toda a empresa, informações analíticas e transacionais, explorar estas informações instantaneamente e analisar os dados em tempo real. Cabe ressaltar que estas funcionalidades poderão ser executadas ao mesmo tempo.

Com o In-Memory Computing os dados são armazenados em memória e estes são consultados em tempo real e com uma velocidade muito satisfatória para o usuário.

In-Memory Conputing é um sistema de gerenciamento de base de dados que depende principalmente da memória principal para o armazenamento dos dados. Comparando com os sistemas de gerenciamento de banco de dados comuns, In-Memory Computing é muito mais rápido, pois a arquitetura utilizada permite ter um algoritmo muito mais simples e que utilize menos instruções da CPU.

Alem disso, este método inovador permite acessar menos recursos de I/O quando os dados são solicitados, o que faz com que a consulta fique mais ágil. Esta forma de acesso pode ser utilizada com segurança pelas empresas que necessitem obter os dados em tempo real.

OBS: Esta foi a primeira parte do artigo, porém, em breve, publicarei a segunda parte contendo mais detalhes.

Referencias:
– http://en.wikipedia.org/wiki/In-memory_database
– http://www.sap.com/platform/in-memory-computing/index.epx
– http://www.sap.com