Arquivo por categoria: SAP

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

dez 17 2013

Treine com SAP gratuitamente

Eis aqui uma oportunidade unica de acelerar suas habilidades e de uma maneira que se encaixa na vida de qualquer profissional/consultor ocupado.

A SAP e o Instituto Hasso Plattner oferecem cursos de graça em diversas áreas, não somente BI, como por exemplo, BPM,  In-Memory Computing entre outros.

O curso está estruturado da seguinte forma:

  • São divididos normalmente de 4, 6 ou 8 semanas e você administra o quando e onde irá fazer os cursos;
  • Você administra seu tempo durante cada semana;
  • Todo material do curso está disponível para download: PDF, Slides, Vídeos e se tratando de um curso técnico que necessite de algum programa em especial também será disponibilizado;
  • Ao final de cada semana há um exame que tem prazo para ser feito. O exame costuma ter um prazo de 30 a 60 minutos;
  • Ao final do curso há uma prova final que também tem um tempo e um prazo para ser realizada e costuma ter um tempo entre 1 hora e meia a 2 horas;
  • Para obter o certificado do curso você deve obter pelo ao menos 50% dos pontos.

50% dos pontos você obtém acertando 100% do exame final

Os 50% restantes você obtêm acertando 100% dos exames semanais

Portanto se você acertar tudo nos exames semanais e na prova final você fica com 100%, mas lembrando o minimo é 50% e se você atingir esse mínimo vc conseguira um certificado igual ao abaixo:

 

01

 

Mas nem tudo são trevas.. mesmo que não atinja 50% você pelo ao menos ganha um certificado de participação.

Para realizar um curso você pode criar uma login ou usar o seu SAP ID, acessando o endereço: http://open.sap.com/

02

 

O mesmo vale para o OpenHPI: http://openhpi.de

03

 

 

O interessante é que mesmo para alguns cursos que já tenham passado você pode faze-lo como Self-Study, mas você não ganhara nenhum certificado nem terá exames para realizar.

Exemplo de um curso oferecido pelo OpenHPI:

04

 

 

Depois de criar o login, clicar em “More Information”, basta clicar em enroll para realizar o curso!

05

 

 

Observação Importante: Se inscreva nos cursos somente se você realmente estiver disposto a realizá-los com comprometimento, pois seus pontos e percentual de aproveitamento ficarão registrados e disponíveis para consulta pública. Portanto, não é interessante que você “mande mal” e isso fique no seu currículo, certo? Se está interessado em fazer em um ritmo mais lento do que o proposto, é melhor esperar o curso acabar e fazer self-study.

 

BONS ESTUDOS!!!