DW na Nuvem

Até agora eu não consegui “fazer o caso” contra ou a favor da terceirização da infra-estrutura de soluções de BI – a.k.a. DW/BI “na nuvem”. Há pouco tempo, numa destas promoções da Amazon.com, eu consegui uma cópia gratuita do livro Getting Started with Amazon Redshift sobre o serviço homônimo, editado pela Packt em 2013.

Nome adequado!
Nome adequado!

O nome Redshift é uma referência ao deslocamento para o vermelho sofrido pela luz emitida de um corpo que está se afastando do observador. É um efeito observado no nosso Universo, que sugere que ele está se expandindo, ficando maior.


Ainda estou na metade, mas o que eu vi já é o suficiente para me esclarecer algumas coisas.

Para começo de conversa, a maior vantagem de infraestrutura “em nuvem” é, sem dúvida, a capacidade de escala normalmente disponível. O Redshift têm algumas opções de tamanho e preço, todas estupidamente potentes para a maioria das empresas:

Recurso Nó XL Nó 8XL
CPU Cores (Xeon E5) 2 16
RAM (GB) 15 120
Disco 3 HDs, 2TB 24 HDs, 16TB
E/S de Disco (GB/s) 0.5 4

Cada um destes nós é precificado em dois modelos:

  • Por hora: paga pelo uso, enquanto usar;
  • Por reserva: paga por um período, independente de usar ou não.
Tabela de preços em 2015: igual à de 2013, mas com Dense Computing.
Tabela de preços em 2015: igual à de 2013, mas com Dense Computing.

No formato por hora, como podemos ver na tabela acima, cada nó XL sai por US$0,85/hora, e um nó 8XL por US$6,80/hora.

Agora, se você fechar um contrato com eles por um tempo determinado, o custo por hora chega a sair por até 25% do preço cheio! Considerando-se que uma empresa não traça estratégias por períodos muito menores que um ano, especialmente em termos de BI, um nó Redshift XL básico sai por US$0,49/hora para o contrato de um ano, e US$0,213/hora para contratos por três anos.


Colocando ao contrário: seu custo de infraestrutura para manter um DW com 2TB por três anos é US$83,00/mês. No Brasil de hoje isso mal paga a eletricidade das máquinas, quanto mais custos de software, instalação e suporte!


Conclusão: montar um servidor de DW no Redshift, com DOIS TERABYTES de armazenamento e 15 GB de RAM, em dois cores Xeons, parece muito mais barato que montar uma estrutura local. Só isso, para mim, já vale uma investigação mais detida do assunto. Este post vai olhar o lado do DW em nuvem e em um post futuro eu tratarei dos outros aspectos, como servidor de exploração, custos de transferência etc.

A Casa d’Irene

A casa d’Irene si canta si ride

C’e gente che viene, c’e gente che va

A casa d’Irene bottiglie di vino

A casa d’Irene stasera si va

Veja, Armazéns de Dados são como a casa da Irene: é gente que vai e vem, o tempo todo, e é desse fluxo que dependemos para as coisas acontecerem. Se você não consegue manter um fluxo de dados suficiente na carga, seu DW vai levar muito tempo para ser atualizado, estourando os tempos de ETL, entupindo a rede. Da mesma forma, se a vazão de dados entre o disco e a CPU não for o suficiente, as consultas vão demorar demais porque grande parte do tempo vai ser gasto pelo servidor trazendo os dados do disco para memória.

Disco <-> RAM

Quando temos um servidor de DW na nuvem, precisamos passar os dados dos sistemas da empresa primeiro pela Internet, para dentro do cluster Redshift. Depois, quando formos consultar, os dados precisam fluir rapidamente do disco para a RAM.

Este segundo aspecto é garantido pela Amazon em 0,5GB/s no caso mais barato. Uma fato de 1.000.000.000 (isso, um bilhão de linhas), com 400 bytes por linha (dez chaves delegadas de 8 bytes cada e mais 10 métricas de 32 bytes) totaliza pouco mais de 370GB. Ler tudo isso leva uns 12 minutos no cluster mais simples. No cluster mais rápido dá um minuto e meio. Nada mal, mas isso é um caso extremo, já que são raras as fato que atingem esse volume e ainda servem cubos OLAP, que é a aplicação que demanda mais velocidade. Para fatos com dez milhões de linhas, por exemplo, o menor cluster Redshift consegue varrê-lo completamente em pouco menos de 8 segundos.

Ou seja, I/O dentro do Redshift não é uma preocupação.

Origem <-> Redshift

Mas o caminho dos dados até os nós Redshift é.

Uma técnica tradicional de ETL consulta os sistemas transacionais e o DW simultaneamente, batendo um contra o outro e carregando no DW apenas as novidades. Essa arquitetura tem um impacto insignificante quando os sistemas ficam todos na mesma rede, que em geral está geograficamente muito próximo. Porém, quando o DW tem uma Internet no meio do caminho, cheia de firewalls, roteadores etc., a coisa muda de figura e se torna inviável. O round-trip time, que é o tempo entre uma leitura de um lado receber a resposta do outra, fica muito alto e, mesmo que o processamento seja rápido, o overhead de transmissão mata a performance do processo de ETL.

A solução é diminuir o uso da rede entre o sistema de origem e o DW no Redshift o máximo possível. Por exemplo, podemos selecionar apenas as linhas que tiveram atualização na origem e despachá-las compactadas para um armazenamento na mesma rede do Redshift.


Isso não é um cenário exótico, afinal, pois empresas que possuem centros de dados dispersos por vários territórios já lidam com essa preocupação rotineiramente.


Redshift <-> Soluções de BI

Quando resolvermos a questão da carga do DW, restará a exploração desses dados. Podemos consumir esses dados em dois modos:

  • On-line: aplicações cujas consultas precisam retornar em segundos;
  • Off-line: aplicações que podem esperar minutos ou horas por uma resposta.

O primeiro caso engloba painéis, análises OLAP e alguns tipos de relatórios. O segundo caso é mais comum em projetos de Data Mining e relatórios renderizados em plano de fundo, que sabidamente tomam muito tempo.

Qualquer que seja o caso, porém, sempre estaremos preocupados com o volume de dados que flui entre os dois servidores. Consultas para o Redshift são feitas com SQL normal, já que ele é um derivado Postgres, e isso raramente passa de alguns kilobytes.

A volta, do Redshift para o cliente que fez a consulta, é quando a porca torce o rabo. Em alguns casos o SQL retorna umas poucas linhas, com dados já totalmente agregados. Em outras situações, o retorno pode ser grandes datasets, que serão processados no servidor de exploração (o Mondrian, servidor OLAP usado pelo Pentaho BA Server, se encaixa neste caso.)

A solução é desconfortavelmente simples: a melhor forma de evitar gargalo de rede entre o servidor de exploração e seu DW Redshift é colocar o servidor de exploração dentro da Amazon, como outro serviço!


Uma das configurações mais “confortáveis”, com menos gargalos potenciais, é montar tudo dentro da Amazon.com.


Chutando Tudo

Quanto custa o hardware e software da categoria XL mais simples, e quanto sai um Redshift dessa categoria por um ano?

Se fosse medir isso para minha empresa, eu tomaria um cuidado enorme, começando por pedir cotações de vários fornecedores, custos de instalação, fretes, softwares, suporte etc. etc. etc. Mas eu quero apenas saber se os valores são comparáveis ou não. Para mim, comparáveis são valores que têm uma diferença de no máximo 10% entre si.

Hardware

Eu fiz uma busca por um Intel Xeon E5 e, logo nos primeiros resultados, achei isso:

Servidor da categoria XL.
Servidor da categoria XL.

Continha rápida (dólar de 1/7/15):

    R$ 9.553,93 / 12 meses = 
    = (R$ 796/mês) / R$ 3,14
    = US$ 253,00/mês

Ele tem um quadro grande de especificações, mas nos interessa apenas essa:

    Fonte: Cougar
    Potência: 500 Watts
    Tensão de entrada: 110/220V

Software

Depois eu verifiquei o preço de um HP Vertica para três nós, até 1TB: gratuito, assim como um sistema operacional (o Vertica funciona em algumas versões de Linux, que podem ser instaladas sem custo de licença.)

PostgreSQL colunar para três nós e 1TB: na faixa!
PostgreSQL colunar para três nós e 1TB: na faixa!

Infraestrutura

Vamos lá: no mínimo precisamos de um departamento de TI para tomar conta da máquina:

  • Profissional de TI: R$ 5,000.00/mês de salário;
  • Mais R$ 5.000,00 de encargos trabalhistas;
  • Trabalhando 8×5;
  • Menos um mês de serviço por ano (por férias);
  • Mais riscos diversos (acidentes doenças, paternidade, “ser roubado” por outra empresa etc. etc. etc.) que reduzem a disponibilidade dele.

Podemos argumentar que um profissional não vai ficar 100% do tempo dele só com um produto – servidor de DW – e que ele vai fazer muitas outras coisas. Concordo. Para efeitos de proporção, então, vamos dizer que apenas um décido do serviço dele é gasto com esse recurso. Se por mês gastamos R$ 10.000,00, então R$ 1.000,00 é a parcela de custo do servidor de DW.

Servidor que, aliás, precisa ficar ligado 24×7. Os preços de eletricidade em São Paulo, SP, hoje (julho/2015 antes do aumento de 1/7/15) são:

Tarifas de energia elétrica em SP, julho de 2015.
Tarifas de energia elétrica em SP, julho de 2015.

Uma empresa é classificada como grupo B3:

Classes de fornecedimento de energia elétrica.
Classes de fornecedimento de energia elétrica.

Juntando tudo ficamos com:

  • A fonte consome 500 Watts, que eu suspeito que seja Watt-hora. Por mês, ligado o tempo todo gastaria: (500 Watts x 24 horas x 30 dias)/1000 = 360 kWh/mês;
  • Em São Paulo a tarifa comercial está em R$ 0,25625/kWh;
  • Total mensal de R$ 92,25 e anual de R$ 1.107,00.

Somando os dois temos R$ 1.092,25/mês de custo de infraestrutura.

Comparando Alhos com Bugalhos

Resumindo, com a infraestrutura interna gastamos anualmente um mínimo de:

Item Valor
Máquina R$ 9.553,93
Software R$ 0,00
Serviços R$ 13.107,00
Total R$ 22.660,93

Contra o valor integral da modalide de reserva, que você pode conferir na tabela adiante:

  • Para um ano: US$ 4.295,00 * R$ 3,14 = R$ 13.486,30 ;
  • Para três anos: US$ 5.605,00 * R$ 3,14 = R$ 17.599,7, ou R$ 5.866,56.
Tabela de preços da modalidade reserva.
Tabela de preços da modalidade reserva.

Conclusão

Se você conseguir comprar um servidor, fazê-lo ser entregue sem frete, instalar-se e conectar-se a tudo sozinho, nunca der pau e nem precisar ficar em algum lugar no mundo físico – como uma sala, que paga aluguel, luz, IPTU etc. etc. etc., então um servidor Redshift sai por no mínimo R$ 9.174,63 a menos, por um ano. Aliás, com o que você gastaria em um servidor físico (em um cenário irreal) você poderia pagar TRÊS ANOS de Redshift equivalente, e ainda sobraria dinheiro!

Tudo muito lindo, tudo muito bacana, mas toda análise que joga luz sobre algo, projeta sombras sobre outras coisas. Olhe de novo para minha análise e se pergunte: o que é que não está dito ali?

Algumas coisas não são ditas:

  • Uma instância Redshift XL é algo muuuuito grande para os padrões de uma empresa média. Bom, isso eu disse, mas isto não: uma empresa desse porte pode ser virar com um servidor muuuito menos potente (por exemplo, com 1TB de disco e 8GB de RAM, CPU i7), na faixa de R$ 5.000,00 ou menos;
  • Existem outros custos associados a manter um Redshift que eu não contei. Um destes é o balde S3. Um balde S3 ajuda no transporte dos dados dos sistemas de origem para o nó Redshift, e ele consome outro tanto de dinheiro – incluindo custo de transferência de dados, medidos em gigabytes/mês. Veja aqui esses valores e faça uma conta;
  • Eu disse que o Redshift funciona melhor com toda estrutura na Amazon, incluindo o servidor de exploração e ETL. Isso representa no mínimo uma nova máquina online, com custos de disco, memória e transferência que precisam ser levados em conta;
  • Trocar um ambiente local por um “na nuvem” requer um conjunto habilidades ainda raro no mercado brasileiro. Esse caminho pode ser um beco sem saída em termos de mão-de-obra;
  • Acesso à Internet e a própria Internet viram um fator a ser levado em conta no planejamento. A empresa vai precisar de links de respeito para usufruir da potência desse servidor.

O que o livro me trouxe foi um pouco mais de conhecimento técnico sobre o assunto, que por sua vez me permitiu entender que uma arquitetura de BI/DW em nuvem é viável desde que, pelo que tudo indica, a solução fique completamente na nuvem. Se hoje eu fosse contratado para montar um DW em uma empresa, eu consideraria muito seriamente a montagem de tudo na Amazon.com, o que fatalmente me levariam a considerar as mesmas opções em outros serviços “de nuvem”.


Este post é dedicado à memória de minha querida tia Irene Michelette. Na casa de Irene se canta e se ride! :-)

Anúncios