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

13 comentários sobre “DW na Nuvem

  1. Parabéns ! Great Article ! Posso te dizer que todos os grandes fornecedores estão colocando seus times de engenharia para trabalhar tornando seus produtos alinhados à nuvem. De tendência, já é realizada e está virando questão de sobrevivência no mercado. Quando olhamos por exemplo, o que a Sales Force tem feito no ERP, Em ambientes menos propensos a armazenamento externo cresce o uso de BI em clouds privadas. Parece só um simples mudança, mas quando se avalia a escalabilidade horizontal que na prática traz custo marginal a cada adição de nó, reduz significativamente o custo com infra-estrutura nesses tempos de massificação dos volumes de dados.

    1. Graaaande Dr. Washington! Muito obrigado! Seu feedback é muito valioso, grato por compartilhar comigo e os leitores. Pelo que eu entendi, não apenas o uso de nuvens contratadas, como a da Amazon, mas a própria idéia de um Data Center como uma nuvem privada é que está ganhando força, não é? Muito interessante, e faz todo sentido quando se vê coisas como DevOps e infra como código.

      Nossa, esse blog está ficando muito bem-frequentado! :-)

  2. Fábio,

    Excelente post!! Precisamos conversar mais :)

    Já venho trabalhando com Pentaho na Amazon há mais de 2 anos. Comecei utilizando RDS MySQL e agora Postgresql. Só não migrei para o Redshift porque ainda não está disponível no Brasil e o tempo de resposta das minhas consultas do DW não justificam migrar para outra região.

    Já testei o Redshift e o tempo de resposta, comparado ao banco relacional, é impressionante. Mas os benefícios de utilizar um DW na nuvem vão além … a Amazon disponibiliza outros recursos, que podem ser facilmente integrados ao Pentaho (mas também a outras soluções de BI :p), tal como o EMR (Elastic MapReduce), onde podemos levantar uma infraestrutura totalmente gerenciada em minutos, e utilizar hadoop e spark para processamento de grande volume de dados.

    DW na nuvem tem seus desafios, mas recomendo!!!

    Grande abraço

    1. Muito obrigado, Wellington! Com certeza precisamos botar o papo em dia. Eu não sabia que não temos Redshift para o Brazil – faz diferença? Não é só pagar e usar, mesmo nos EUA? Intuitivamente eu tinha a idéia que você confirmou: Redshift vale pelo tempo de resposta, mais do que pela infra de armazenamento e carga.

      Aproveitando, qualquer parâmetro dos seus DWs que você puder compartilhar aqui vai enriquecer todos nós – eu incluído. Tamanho, custo, janela de ETL, falhas, estabilidade etc. etc. etc. Eu sou totalmente cru em relação a um DW “em nuvem”. Qual é a maior diferença: a carga (incluido o processo de ETL) ou a gestão? Você manter a exploração na nuvem, também, ou só o DW?

      Aos meus leitores: eu não posso contar o milagre, mas o Wellington é o santo que opera muitos! Se ele recomenda, podem ter certeza, vale a pena no mínima uma POC com seriedade.

      1. Oi Fábio, boa noite!

        A princípio não é um problema usar o Redshift nos EUA, é até mais barato do que seria se já tivesse o serviço no Brasil. Nesse caso, é recomendável manter todo o ambiente também lá (BI Server, rotinas de ETL). Daí surge outros desafios, como por exemplo o tempo de resposta de um servidor nos EUA se comparado com um servidor da Amazon em SP. Pode variar de 10ms (em SP) até 200ms (Virginia), dependendo do roteamento. Em um processo de carga faz uma grande diferença. O que pode ser minimizado utilizando o S3 como stage dos dados, o que recomendo.

        Em relação à segurança da informação, é um mito achar que a segurança na nuvem é frágil (minha opinião). Trabalhei durante 3 anos como analista sênior nessa área. Minha experiência diz que as maiores vulnerabilidades são de dentro pra fora. Ou seja, é mais comum que um vazamento de informação venha de um funcionário da própria empresa. Acredito que poucas empresas no Brasil passem por tantas auditorias de segurança se comparados com os Datacenters da Amazon. Mas se quer garantia de confidencialidade dos dados, basta aplicar criptografia forte na origem, antes de enviar seus dados para a nuvem.

        Mas o melhor de tudo isso é poder focar no negócio, e se preocupar MUITO menos com infraestrutura (upgrade de servidor, ampliação de storage, atualização de firmwares de equipamentos, manutenção de banco de dados, lentidão de rede, etc, etc, etc). Quem já trabalhou com operação de Datacenter sabe bem do que estou falando. Hoje tive a curiosidade de ver o uptime de meus servidores. O primeiro a entrar em produção já passou de 400 dias. Tenho um painel que exige uma atualização quase que em tempo real. A carga incremental roda a cada 3 minutos e, até o momento sem falhas, após 370.000 execuções (Tirei um print hoje do jenkins :) http://prntscr.com/7v3cxk).

        Enfim, poderia dar mais uma dúzia de razões, mas sugiro que façam a experiência. Quem quiser ir além e mais rápido, considere utilizar o Pentaho com Docker (sensação do momento). Mantenho repositório no Docker Hub para quem quiser testar (https://registry.hub.docker.com/u/wmarinho/pentaho-biserver/)

        Grande abraço,

  3. Muito interessante esse post, mas como acontece com ERP, acredito que ainda há uma certa resistência em relação a certo tipos de informação armazenada em nuvem. Por causa da segurança da informação, afinal a responsabilidade pelo ativo intangível nesse caso é do cliente e não da Amazon. Sendo assim é mais fácil deixar onde o olho do dono pode ver.

    1. Obrigado pelo comentário, Jason. Mais uma vez, coberto de razão: é uma mudança dupla, sem dúvida. Não bastasse o complexo aspecto técnico, a parte cultural também é crítica. Eu sempre me pego no lugar do usuário, pensando “e se ‘acabar’ a Internet (como acaba luz), o que eu faço?”

      Quanto à facilidade, bom, não é um mundo fácil: você precisa ralar para ficar à frente da concorrência, para usar melhor seus recursos e se manter no jogo enquanto der. No pain, no gain! ;-)

  4. Gostei bastante dessas informações, por estar iniciando estudos em BI não tinha ouvido falar na questão de ser ter o ambiente em nuvem, mas o que achei interessante foi a questão dos custos, a redução pois se existe empresas que talvez ainda resistam a pensar em BI pelos custos, esta ai uma alternativa para implantação de BI e sem contar na expansão da demanda profissional.

    1. Obrigado, Júlio, e seja bem-vindo à essa loucura organizada que é BI! :-)

      Concordo contigo: a questão dos custos de implantação de um projeto de BI ainda não é tratada com muito detalhamento. Claro que os preços de máquina, hardware, projeto etc. são sempre alvo de escrutínio, mas pouco se pondera sobre as opções. Normalmente assume-se como um mal necessário (não é!), “restando decidir o desconto”.

      Eu sempre reforço o aspecto que BI, se empregado adequadamente, paga-se em meses, se não em semanas. Logo, tanto faria ser mil reais ou um milhão de reais – se ele se pagar em um mês, que diferença faz? Com esta visão, a questão da arquitetura e dos custos contínuos (como infra) são muito mais interessantes e pertinentes.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s