Excel vs. MDX

Não me entenda mal: não quero começar uma guerra santa entre usuários de Excel e de MDX, até porque eu provavelmente pertenceria ao exército santo do Excel.

Mas a verdade é que, quando alguém precisa tabular dados, a primeira escolha é sempre o Excel. Ele é simples e fácil de usar, e dá resultados mais ou menos intuitivos.

Neste post eu vou mostrar um caso típico de uso do Excel – comparar valores de dois períodos – e como fazer o mesmo usando MDX. Daí eu vou tirar algumas conclusões e, espero, te convencer da importância de investir no estudo de MDX.

Vamos lá.

O Problema

Eu recebi um e-mail de um ex-aluno com o seguinte problema:


(No meu cubo) tenho uma coluna de valor faturado e, estou fazendo um comparativo entre os anos de 2014 e 2015, por empresa, pois somos um grupo de empresas. A minha métrica é o valor faturado. Então, como proceder se eu tiver que dividir um valor pelo o outro?


Quantas vezes não precisamos fazer isso? Comparar um ano com outro, uma linha de produtos com outra, faturamento em estado com outro… Qual é a primeira idéia que nos ocorre para tratar esse problema?

Montar uma planilha eletrônica – um Excel. É ou não é?

Vamos fazer isso aqui: vamos pegar o problema que meu ex-aluno trouxe e resolvê-lo, primeiro no Excel e depois como uma consulta MDX.

Para facilitar a compreensão do raciocínio, eu vou alterar ligeiramente o problema trazido pelo aluno. Ao invés de considerarmos os dados da empresa dele, que são sigilosos e relativamente complexos, vamos usar o cubo de vendas da SteelWheels, que é a empresa usada na demonstração do Pentaho BA Server.

Reformulando o problema com a SteelWheels, fica:


Estou fazendo um comparativo entre os anos de 2004 e 2005, por linha de produto. A minha métrica é o valor vendido (Sales). Como proceder se eu tiver que dividir um valor (Sales em 2005) pelo o outro (Sales em 2004) para cada linha de produto?


Resolvendo com Excel

Para resolver esse problema usando uma planilha eletrônica (nome genérico do Excel, que serve para designar não apenas o Excel, mas o Calc, do LibreOffice, o Lotus 1-2-3 etc.), precisamos primeiro extrair os dados para um arquivo, que vai ser importado pelo Excel e só então aparecer como uma planilha. Normalmente, para bancos de dados relacionais, fazemos isso exportando para CSV o resultado de uma consulta SQL, e depois importando esse CSV para dentro da planilha eletrônica.

E para fazer isso nós precisamos:

  1. De uma ferramenta que permita rodar SQL contra a base e exportar o resultado para arquivos CSV;
  2. Conhecer a base de dados, entendendo que tabelas possuem os dados que queremos, e como elas se relacionam entre si; e finalmente,
  3. Saber SQL o bastante para escrever uma consulta válida.

Vamos começar por entender os dados. Eis abaixo o esquema do banco, construído no Power*Architect:

Esquema que alimenta o cubo SteelWheels Sales.

Esquema que alimenta o cubo SteelWheels Sales.

Montei esse diagrama fazendo engenharia reversa no esquema Mondrian (que por sua vez foi retirado do servidor Pentaho) e na base de dados.

Como queremos os dados das vendas feitas por ano, por linha de produto nos interessam as tabelas PRODUCTS, ORDERFACT e DIM_TIME. O SQL que retorna a lista de valores vendidos por linha de produto, por ano é:

SELECT
  PRODUCTS.PRODUCTLINE AS PRODUCTS_PRODUCTLINE,
  DIM_TIME.YEAR_ID AS DIM_TIME_YEAR_ID,
  SUM(ORDERFACT.TOTALPRICE) AS SALES
FROM PUBLIC.PRODUCTS PRODUCTS
INNER JOIN PUBLIC.ORDERFACT ORDERFACT
  ON PRODUCTS.PRODUCTCODE = ORDERFACT.PRODUCTCODE
INNER JOIN PUBLIC.DIM_TIME DIM_TIME
  ON ORDERFACT.TIME_ID = DIM_TIME.TIME_ID
GROUP BY PRODUCTS_PRODUCTLINE,
         DIM_TIME_YEAR_ID
ORDER BY DIM_TIME.YEAR_ID ASC,
PRODUCTS.PRODUCTLINE ASC`

(Eu não sou esse mago do SQL. Eu consegui essa expressão usando o SQLeonardo. E não, não existe o SheldonQL.)

O SQLeonardo já seria o bastante para exportar os dados, mas eu resolvi usar a grande dica do Rômulo, e montei uma conexão com o banco usando uma interface gráfica padrão do HSQLDB:

Conexão do cliente HSQLDB com o SampleData.

Conexão do cliente HSQLDB com o SampleData.


O HSQLDB é o banco de dados portátil, usado pelo Pentaho BA Server.


Depois da conexão feita, rodamos a consulta acima:

Resultado da consulta que traz o dados que desejamos.

Resultado da consulta que traz o dados que desejamos.

E salvamos esse resultado em formato texto:

Arquivo texto resultado do comando 'File -> Save Result'.

Arquivo texto resultado do comando ‘File -> Save Result’.

Depois de um pouco de escovação, finalmente aparece como uma planilha eletrônica:

Colocando os anos lado-a-lado na planilha.

Colocando os anos lado-a-lado na planilha.

Pronto, podemos nos dedicar a montar a resposta ao problema. Primeiro, rearranjamos a planilha para colocar os anos lado-a-lado:

Colocando os anos lado-a-lado na planilha.

Colocando os anos lado-a-lado na planilha.

Agora ficou fácil: basta calcular a razão (=divisão) entre quaisquer colunas e inserir o resultado em uma nova coluna. Do enunciado do problema sabemos que queremos a divisão de 2005 por 2004. Assim, apaguei a coluna de 2003 e coloquei uma nova coluna, 2005/2004, contendo a fórmula que divide uma pela outra. Formatei como porcentagem e finalmente temos (com destaque para a fórmula):

Calculando 2005 dividido por 2004, como uma porcentagem.

Calculando 2005 dividido por 2004, como uma porcentagem.

Voilá! Problema resolvido!

MultiDimensional eXpressions

MDX é a linguagem que a Microsoft criou para seu produto OLAP, o MS SQL Server Analysis Services, ou SSAS, como é conhecido. O SSAS é uma base multidimensional real, o que significa que ele guarda cada célula de um cubo OLAP como um registro físico, assim como um banco relacional guarda registros em disco. Em comparação, o Mondrian é um servidor OLAP, que monta o cubo em memória a partir de um banco de dados relacional tradicional, conforme processa comandos MDX. Em comum, SSAS e Mondrian têm exatamente isso: a linguagem MDX.

A meta da Microsoft com o SSAS era popularizar BI, e nisso o MDX era instrumental. A idéia por trás do MDX era viabilizar justamente o tipo de manipulação que fazemos com o outro produto da MS – o Excel – mas para grandes e complexas massas de dados. O livro Fast Track to MDX traz um histórico, simples mas muito valioso, de como o SSAS (e o MDX) nasceu e cresceu.

Resolvendo com MDX

Para resolver esse mesmo problema com MDX usamos um Pentaho BA Server (eu usei a versão 5.4, mas funciona com qualquer uma – mesmo!) Depois de subir o servidor, acessamos o endereço http://localhost:8080, fazemos login com usuário admin e senha password e criamos uma nova visão OLAP:

Abrindo uma nova visão OLAP do cubo de vendas SteelWheels.

Abrindo uma nova visão OLAP do cubo de vendas SteelWheels.

Assim que você seleciona o esquema SteelWheels e o cubo SteelWheelsSales e clica em Ok, a visão inicial do cubo se abre:

Visão inicial do cubo de vendas da SteelWheels.

Visão inicial do cubo de vendas da SteelWheels.

Usando o primeiro ícone do jPivot, Cube Navigator, e mudando o tipo de drill para Drill Replace (ícone de setas vermelhas), chegamos a uma visão análoga à da planilha:

Cubo rearranjado para mostrar a mesma visão de planilha.

Cubo rearranjado para mostrar a mesma visão de planilha.

Neste ponto, quando usamos o Excel, criamos uma nova coluna e colocamos a fórmula nela. Vamos fazer exatamente a mesma coisa aqui, mas com MDX.

Até agora manuseamos os dados em uma interface gráfica. Vamos ver o que existe de MDX por trás disso. Clicando-se no botão MDX do jPivot, vemos a consulta que construímos enquanto lapidávamos o cubo:

SELECT NON EMPTY Crossjoin( {[Measures].[Sales]},
              [Time].[All Years].Children ) ON COLUMNS,
NON EMPTY [Product].[All Products].Children ON ROWS
FROM [SteelWheelsSales]

Em MDX-zês, uma “nova coluna” equivale a uma métrica calculada (bom, tecnicamente falando, é um membro calculado, mas como é um membro do conjunto de métricas, fica sendo uma métrica calculada mesmo.) Essa métrica calculada pode ser definida, em português, assim:

    COM O NOME "Razao_2005_2004" USE A FORMULA ([2005,Categoria]/[2004,Categoria]), <OPÇÕES>

O truque todo está na fórmula: pense no cubo OLAP como uma mega-planilha, na qual toda métrica pode ser referenciada com um conjunto de coordenadas, exatamente como em uma planilha Excel. A diferença é que as coordenadas não são colunas e linhas, como na fórmula da figura anterior, mas sim membros dos conjuntos das dimensões!


Outro detalhe importante: se você não explicitar uma dimensão, assume-se que a fórmula vale em todas as “coordenadas” daquela dimensão. Ainda apelando para a analogia do Excel, é como fazer referência à planilha: a menos que você indique uma célula em outra planilha, a fórmula Excel vai assumir que a coluna/linha indicada é na mesma planilha (o “membro atual”, do inglês current member – essa noção é importantíssima!!), e se você copiar essa fórmula para outra planilha, o mesmo vai continuar valendo.

Trocando o Português por MDX castiço, a fórmula fica:

WITH MEMBER [Measures].[Razao_2005_2004] AS (
  ([Measures].[Sales],[Time].[2005],[Product].CurrentMember) / 
  ([Measures].[Sales],[Time].[2004],[Product].CurrentMember)
                                   ), format_string = "#.00%"

O format_string serve para que os valores calculados apareçam como porcentagens. Sem ele ali, os valores seguiriam a formatação da métrica original.

Agora vamos colocar essa fórmula no nosso MDX anterior:

WITH MEMBER [Measures].[Razao_2005_2004] AS (
  ([Measures].[Sales],[Time].[2005],[Product].CurrentMember) / 
  ([Measures].[Sales],[Time].[2004],[Product].CurrentMember)
                                   ), format_string = "#.00%"
SELECT NON EMPTY Crossjoin({[Measures].[Sales]},
               [Time].[All Years].Children) ON COLUMNS,
NON EMPTY [Product].[All Products].Children ON ROWS
FROM [SteelWheelsSales]

Se você testar essa consulta no jPivot, copiando-a e colando-a, vai ver que nada de novo aparece, mas também não dá erro. Isso acontece porque, apesar de termos definido a nova métrica, ela não está sendo usada na consulta. É preciso incluir a nova métrica na consulta para que ela apareça no cubo. Fazemos isso alterando o termo logo depois de SELECT NON EMPTY Crossjoin:

WITH MEMBER [Measures].[Razao_2005_2004] AS (
  ([Measures].[Sales],[Time].[2005],[Product].CurrentMember) / 
  ([Measures].[Sales],[Time].[2004],[Product].CurrentMember)
                                   ), format_string = "#.00%"
SELECT NON EMPTY Crossjoin(
          {[Measures].[Sales],[Measures].[Razao_2005_2004]},
           [Time].[All Years].Children ) ON COLUMNS,
NON EMPTY [Product].[All Products].Children ON ROWS
FROM [SteelWheelsSales]

Notou que o nome da nova métrica, definida no WITH MEMBER, agora aparece na consulta? Se tudo deu certo para você, seu cubo agora deve se parecer com este aqui:

Cubo com a nova métrica calculada.

Cubo com a nova métrica calculada.

Algumas coisas ficaram esquisitas: a coluna se repetiu, com o mesmo valor, para os três anos. Essa visualização é estranha, e não ajuda muito. Se você pensar um pouco, verá que a fórmula que calculamos opera sempre apenas sobre 2005 e 2004. Logo, não há sentido em mostrar o ano


Ao remover a dimensão Ano da grade OLAP, a métrica Sales passará a ser agregada para todos os anos, e não veremos mais as duas colunas para 2004 e 2005. Precisamos aprender um pouco mais de MDX para saber como mostrar a métrica Sales em 2004, em 2005 e, em uma terceira coluna, a métrica calculada – mas aí já é outra história. Entretanto, se você quiser procurar, a solução para este caso passa por NAMED SETS (NS).


Grade agora mostra só a métrica calculada.

Grade agora mostra só a métrica calculada.

Tudo isso parece um pouco confuso no início, mas eu posso dizer algumas coisas para ajudar:

  • É uma fórmula que resolve esse o problema atual, e nenhum outro. Em outras palavras, não é uma solução genérica e geral, mas sim uma bem específica;
  • Pense sempre como uma planilha Excel: para calcular a metade do valor da célula F4, você coloca “=F4/2″ na célula G4. Certo? Em MDX é a mesma coisa, mas uma “célula” é o cruzamento das dimensões e uma ou mais métricas. Para calcular uma nova relação, construímos uma nova coluna, e assim por diante;
  • Logo, a solução de outros problemas demandam outras consultas MDX. Preparamos uma nova solução sempre que tivermos uma nova necessidade.

Conclusão

Meu modesto objetivo era mostrar como uma conta feita em planilha pode ser replicada com MDX. Ou seja, eu queria mostrar que MDX pode ser encarado como uma outra forma de se manusear planilhas de dados. Por favor deixe sua opinião nos comentários: eu consegui?

Se você pensar um pouco, vai ver a mesma situação acontece com bancos relacionais e SQL: em busca de uma resposta específica, podemos escrever um programa (Java, Kettle, PHP etc.) que itera sobre as linhas de uma tabela – para calcular uma média por exemplo, ou podemos tentar escrever uma consulta SQL. Em geral, a consulta SQL vai ser mais enxuta, poderosa, rápida e flexível, porque ela foi pensada para fazer bem certos tipos de trabalho.

Com MDX temos a mesma situação: podemos montar uma planilha, ou podemos escrever uma consulta MDX sobre um cubo OLAP. Em geral, MDX vai ser mais enxuto, poderoso, rápido e flexível, porque ele foi pensado para resolver problemas analíticos.

Há algumas outras coisas dignas de nota em nossa breve aventura com planilhas e OLAP:

  • Ambos os métodos partem da existência de um banco de dados pronto para consulta. Criar esse banco já é um trabalho considerável, dependendo da empresa e das complexidades (negócios, dados etc.) envolvidas;
  • Uma vez que você consiga montar esse banco, ainda precisa escrever o SQL para poder chegar à planilha;
  • Se você optar por montar um cubo OLAP, precisa mapear o banco com um esquema Mondrian, e depois construir o MDX que resolve seu problema.

Ou seja, por qualquer caminho que peguemos (MDX ou Excel), sempre vamos precisar “escrever” algo (um SQL ou um MDX), mesmo que para isso usemos uma ferramenta visual.

Bom, se pelos dois caminhos temos o mesmo trabalho, se não maior no caminho MDX, porque então vale a pena usar MDX? Porque não ficamos só com Excel?

Resposta: volume de dados e complexidade.

Veja como tínhamos poucas linhas e poucas colunas para manusear em uma planilha eletrônica. Conforme o volume de dados e a complexidade desse volume aumenta, cresce a complexidade das operações necessárias para montar a planilha. Nosso exemplo usa apenas anos e linha de produto. Como ficaria para Mês/Ano e Produto com Cliente? Com duas dimensões conseguimos “ver” a planilha numa boa, mas e com três, quatro, cinco?…

Mais ainda: para cada visão em planilha, o comando SQL precisa mudar para tratar das agregações nos níveis corretos!

O livro OLAP Solutions desenvolve esse argumento melhor, mas o ponto que eu quero destacar é que planilhas podem ser práticas e muito úteis apenas até certo ponto! A partir daí, as operações para montar e explorar as planilhas ficam sobejamente complexas.

É quando MDX passa a ser mais interessante que Excel.

Até a próxima!

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! :-)

Como Um Data Vault Evolui II

Em vários posts (Data Vault Para Quê?, Introdução à DV e Como um DV Evolui) eu falei sobre as vantagens em se ter um Data Vault no miolo do seu projeto de Data Warehouse Corporativo. (E eu também expliquei porque um DW é importante neste outro post.)

Hoje eu vou mostrar uma destas vantagens em ação: como um DV evolui quando a fonte de dados muda.

Cenário

Em julho de 2013 a equipe de desenvolvimento do DW Corporativo do SERPRO estava com um problemão: não conseguiam formular o modelo dimensional adequado à uma necessidade específica do cliente. Me convocaram a trabalhar no projeto e, depois de umas duas semanas apanhando “que nem” cachorro magro, eu consegui resolvê-lo. Ajustei o modelo, repassei os conceitos com a equipe, para evitar novos problemas do tipo, e saí do projeto no início de 2014.

Nessa época a arquitetura do projeto era a mais padrão possível, igual à de qualquer outra empresa:

Arquitetura original.

Arquitetura original.

Ou seja, os vários sistemas de origem eram lidos e partes de seus dados copiados para dentro de um outro banco de dados. Esse banco fazia algumas agregações, algumas integrações e produzia dados combinados. Esse banco não tinha o perfil de um palco (stage), apesar de concentrar dados, e por isso eu prefiro chamá-lo de ODS, ainda que também não se encaixe na perfeita acepção do termo. Finalmente, várias estrelas dimensionais eram populadas a partir da colagem que era esse ODS.

Eu construí a solução para a demanda do cliente em cima desta arquitetura, e percebi mais tarde que o que eu encontrara era, no fundo, a raiz de um modelo do tipo do Data Vault. Animado, eu redobrei meus estudos sobre DV, e no início de 2014 eu pude aplicar o que estava aprendendo para montar um DW na empresa de um amigo. Eu poderia ter feito tudo com Modelo Dimensional, mas seria uma boa chance de testar Data Vault. Deu muito certo: não apenas eu consegui desenvolver tudo em tempo recorde, como ainda criei um conjunto de templates, um processo de modelagem e um processo de desenvolvimento de ETL, que mais tarde foi usado no primeiro curso de Data Vault no Brasil.

Em novembro de 2014 eu voltei a ser alocado ao DW do SERPRO, para atender uma demanda, outra estrela, parada há alguns meses por falta de gente. Só que, desta vez,me deram a liberdade de aplicar meus conhecimentos de Data Vault e não perdi tempo:

Arquitetura com o Data Vault.

Arquitetura com o Data Vault.

Ou seja, meu novo ETL buscava no ODS os dados levados para o Data Vault, e deste um outro ETL partia com os dados para uma estrela de apresentação. Como meu DV foi preparado para se ajustar ao Data Mart Dimensional, eu não precisei refazer nenhuma das dimensões que já existiam. Criei apenas uma nova fato e uma junk, que agregava várias flags e voilà, tudo pronto.

Resumidamente, eu 1) construí o modelo DV, 2) construí o modelo da nova estrela, 3) gerei o ETL do DV automaticamente e 4) criei o ETL para estrela na mão. Levou um mês, mais ou menos, e eu produzi tudo com documentação e processo. Nada de improvisos – não gerei um único débito técnico. Tanto que eu fui embora e deixei-o rodando. Deixei-o não: eu esqueci completamente que ele existia.

Tudo Muda

Eu esqueci, mas o cliente não. Esse “remendo” está funcionando desde então, há mais de seis meses, diariamente, sem ter sofrido uma única parada causada pelo ETL do DV ou dali para o dimensional.


(…)sem ter sofrido UMA ÚNICA PARADA causada pelo ETL(…) Sabe, acabei de me tocar disso e estou profundamente impressionado. Caraca, NUNCA deu pau!! O ETL para o DV parou algumas vezes, mas sempre por causa de problemas gerais, como instabilidade de rede ou pau do banco, nunca por causa de erros imprevistos, e nunca teve nenhuma inconsistência de dados. :-O C-A-R-A-C-A!!…


Voltando: desde de o ano passado que esse ODS vem sendo desativado, pois ele é complexo demais e seu ETL sofre paradas demais (sem contar inconsistências de dados, quando o ETL vai até o final.) Uma nova iniciativa de DW corporativo foi montada (pfff…) e começaram de novo (eu já vi essa história antes…). Decidiram não fazer nenhum modelo: se antes o ODS fazia alguma integração, agora teríamos um palco persistente (PSA, de Persistent Staging Area.) A partir desse PSA as estrelas de consulta eram populadas. Ou seja, se antes a integração acontecia na entrada do ODS, agora ela acontece na saída do PSA. Enfim…

Como disse Otis, as coisas mudam, sempre mudam. Há uns dois meses chegou a hora de desativar o pedaço do ODS que servia de fonte para meu DV. Era preciso migrar o meu Data Vault do ODS para os sistemas de origem, e precisava ser uma migração à quente, sem parar de rodar e sem refazer nada. Não seria possível, por exemplo, analisar as tabelas dos sistemas de origem que compunham o ODS e refazer quaisquer hubs, links ou satélites.

Vem Quente…

A arquitetura após a migração da fonte ficaria assim:

Alteração de fonte do Data Vault.

Alteração de fonte do Data Vault.

Aqui há outro problema embutido: as tabelas que existem nesse ODS são quase as mesmas que existem nos sistemas de origem. Ou seja, se no sistema de origem existe uma tabela produto, no ODS vai existir uma tabela tb_pro_produto. Se essa tabela, na origem, possui 10 campos, no ODS vai possuir 9 ou 11 ou 30 campos. Grosso modo, porém, o conteúdo do sistema de origem existe no ODS quase intacto. Logo, para usarmos os sistemas de origem no lugar do ODS é preciso analisar a correspondência entre as tabelas.

Para cada tabela do ODS que o Data Vault consultava haviam três possibilidades:

  1. Equivalência direta: no máximo o nome da tabela (ou de uma de suas colunas) muda;
  2. Praticamente a mesma coisa: sem contar o nome da tabela, o conteúdo era praticamente o mesmo. As diferenças seriam um nome de coluna diferente, uma coluna a mais ou a menos, mas o mesmo grão: se na origem existissem 1000 registros, o ODS teriam 1000 registros, equivalentes um a um;
  3. Tabelas equivalentes: meu Data Vault usava uma tabela no ODS que era resultado da combinação de duas ou mais tabelas do sistema de origem.

O melhor caso é o primeiro, pois a mudança no Data Vault resumir-se-ia a trocar os parâmetros de conexão para apontar para o novo banco e, talvez, mudar um nome de tabela ou coluna.

O segundo caso também não seria difícil: para cada link, hub ou satélite que usasse esse tipo de tabela bastaria reescrever um único SQL, e mudar a conexão do ODS para o novo banco, e as transformações estariam migradas.

Já o terceiro caso seria o pior. Haveriam duas situações possíveis:

  1. A tabela equivalente dentro do ODS derivava de várias tabelas de uma única fonte de dados. Ou seja, é possível construir um SQL, ou talvez uma procedure mais complexa, que remonta a antiga tabela a partir das tabelas do sistema de origem. Esse novo e complexo SQL seria o novo SQL de cada transformação de hub, link ou satélite, que junto com a mudança de fonte de dados completaria a migração;
  2. A tabela equivalente dentro do ODS derivava de várias tabelas, de duas ou mais fontes de dados. Ou seja, como um SELECT (ordinariamente) não cruza as fronteiras de bancos, e muito menos de tecnologias de bancos, não seria possível construir um SQL para replicar a tabela do ODS. Seria necessário uma transformação intermediária, que unisse esses dados e entregasse-os para as transformações de carga de hubs, links e satélites.

Na pior das piores hipóteses, poderíamos criar uma tabela intermediária, em um palco, e usá-la para carregar o DV.


A migração de fonte de dados de um DV vai de algo tão simples como mudar um IP e uma senha, na conexão com um banco de dados de origem, a algo complexo e trabalhoso como reconstruir parte do DV ou criar etapas de carga intermediárias. Em qualquer situação, porém, sempre haverá uma saída e ela nunca vai quebrar o downstream, o lado do cliente.


…Que o DV Está Fervendo!

Fizemos – a equipe de desenvolvimento do DW e eu – uma áudio-conferência há umas três semanas atrás. Em menos de duas horas eu expliquei o que era DV, o básico de como se construir um e como o trecho do DV funcionava. Depois expliquei exatamente os mesmos pontos acima, mostrando que, quanto mais complexa for a origem do DV, maior vai ser o trabalho de migração.

Bom, o trabalho de migração (já!) acabou! O pior caso foi o de umas tabelas que combinavam coisas de um mesmo sistema, mas sem alterar o grão, de modo que mesmo o pior caso foi muito fácil de fazer.

Não estamos esquecendo de nada?…

Sim! E o data mart populado pelo DV? Você consegue chutar o que deve ter acontecido com ele, e com o ETL do DV para a estrela?

Simples, não aconteceu absolutamente nada. Veja, apenas alteramos as entradas do Data Vault, e nada mais. Assim, o ETL que rodava sobre o DV para popular a estrela que o cliente usava continuou como estava!!

Conclusão

Um Data Vault carrega grandes promessas:

  • Carregar 100% dos dados, 100% das vezes (regra de ouro do DV;)
  • Acomodar qualquer mudança dos sistemas de origem, sem quebrar;
  • Permitir exploração dos dados como o cliente quiser, sem quebrar;
  • Reduzir o trabalho de desenvolvimento e manutenção, automatizando sempre que possível;
  • Reduzir e até eliminar retrabalho;
  • Grande velocidade de carga.

O primeiro artigo, Como um Data Vault Evolui, mostrava o que acontece com um DV quando uma premissa inicial se mostrava incorreta, e como ele se acomoda elegantemente os ajustes necessários. Este post mostrou de que forma uma mudança profunda como a troca de fonte de dados é tratada por um DV. Ainda que tenhamos tido sorte com um ODS que não era complexo demais, todas as mudanças ocorreram em questão de semanas, sem quebrar o dia-a-dia do cliente.

E ele continua rodando sem parar há seis meses! :-D

E o Mobile BI?

Sabem aquelas modas que borbulham de vez em quando? Então, Mobile BI é uma destas. Alguém viu alguma empresa usando Mobile BI por aí? Eu perguntei entre meus amigos e conhecidos da área, mas nenhum sabia de qualquer projeto na própria empresa ou em outra. Como meus contatos na indústria de BI não são poucos, mas estão longe de representar tudo, eu resolvi abrir a pergunta a mais gente. Fui ao LinkedIn e postei, apenas em fóruns nacionais, a mesma pergunta:

Sua empresa usa Mobile BI?

Sua empresa usa Mobile BI?

Postei-a nestes grupos:

  1. BI Brasil;
  2. Business Intelligence (BI) – Brasil;
  3. BI Open Source;
  4. Brasil BI Networking;
  5. Pentaho Brasil;

Se você estiver em algum deles, os links te levarão à questão.

Sabem quantos projetos de Mobile BI eu descobri?

Zero. Ditch. Rien.

Em três meses de pergunta no ar, eu ganhei UM LIKE – da minha querida esposa – e MAIS NADA. Nenhum comentário, like, nada vezes nada vezes nada. Menos do que quando eu perguntei “o que é Data Discovery?“.

Há duas conclusões possíveis:

  1. Existe um número de projetos de Mobile BI no Brasil, mas eu não fui capaz de encontrá-los com uma pesquisa tão rasante. (Pode ser que eu não tenha atingido o público-alvo, talvez esse público não esteja no LinkedIn ou no meu círculo, ou simplesmente ninguém quis se dar ao trabalho de me responder.)
  2. Existem tão poucos projetos de Mobile BI – se existir ao menos um – que o extrato capturado pelo LinkedIn é insuficiente para encontrá-los.

Mas há uma terceira conclusão inevitável: a onda de Mobile BI passou e não deixou marca tangível. Alguém sempre comenta algo, ou pelo menos gosta da perguntas que eu faço. Eu não tenho nenhuma importância no mercado brasileiro de BI, sou só um blogueiro bocudo, mas mesmo assim eu não sou invisível. Todos os meus posts têm, pelo menos, algumas (mais de uma) curtidas e/ou um comentário. O fato de eu conseguir passar completamente em branco (amo minha esposa, mas ela não conta!) é um tipo de achievment, não? Sei lá, Ghostly Writing ou Haunted Post

;-)

Categorias:Solução de BI Tags: , ,

Aprendizagem Gratuita Packt

Para quem ainda não conhece, a Packt é uma das maiores – se não A maior – editora de livros práticos do mundo. Eles têm livros de tudo quanto é assunto, para tudo quanto é público. E em 2015 eles fizeram uma coisa impressionante – vai lendo…


ATENÇÃO: o texto à seguir possui graus extremos de nerdice! Você foi avisado.


Durante a minha infância eu tinha uns sonhos de consumo muito nerds. Coisas como ganhar na loteria para comprar todos os kits da DCE (e assinar a DCE, claro), comprar todos os kits da Abril-Funbec… Coisa hardcore, hehehe.

DCE: Divirta-se Com a Eletrônica. Bons tempos!

DCE: Divirta-se Com a Eletrônica. Bons tempos!

Um destes sonhos era ser dono de uma banca de jornais, para poder ler todos os gibis que eu quisesse, para sempre.

Pois é. Alguns sonhos tornam-se realidade. :-)

Não, eu não estou mudando para o ramo de bancas de jornais. Até porque, hoje, esse sonho está atualizado para “ser dono da Amazon” para ler tudo que eu quiser, de graça. Mesmo assim, não foi o que aconteceu – ainda. Aconteceu algo ainda mais legal, que bate de longe meus sonhos de consumo mais selvagens (eu sou tão mansinho…): desde abril/2015, a Packt está disponibilizado UM LIVRO GRATUITO POR DIA!!! E vai ser assim para SEMPRE!!! :-O

Anúncio da promoção eterna.

Anúncio da promoção eterna.


Press Release

Every day Packt Publishing is giving away books for free to help teach new tech skills

From 30th April, 2015 Packt Publishing has thrown open the virtual doors of its new ”’Free Learning Library”’ and offering its customers a daily chance to grab a fresh free eBook from its website. The publisher is encouraging people to learn new skills and try out new technologies and so every day it will be offering a different eBook from its huge list of titles free for anyone to download.

The Free Learning Library will be open all year-round but each title will only be up for 24 hours, so make sure you keep checking back to get your hands on the latest book! Packt has well over 2000 titles published and the range of topics that could potentially feature is huge. From AngularJS to Zabbix, there’s going to be something to appeal to everyone – this is a great opportunity to try out a different technology or a new technique.

All you’ll have to do is simply click on the day’s free eBook and it will instantly be added to your account. New customers are also encouraged to take advantage, with the offer being a brilliant chance to try out Packt’s great range of books and products – all that’s required is a Packt account.

Find out more.

#FreeLearning

Categorias:Uncategorized Tags: , ,

Novo Livro de Data Vault

Boas notícias! Daniel Linstedt, criador do Data Vault, anunciou a data de lançamento de um novo livro, seguindo a linha do Super Charge Your Data Warehouse:

Anúncio feito em lista do LinkedIn. (Em 20/05/2015)

Anúncio feito em lista do LinkedIn. (Em 20/05/2015)

É claro que eu não perdi tempo:

Posso contar para todo mundo? Posso? Posso? Diga que sim, por favor, ah, vai diga que sim, siiiiiiim???... (Em 21/05/2015)

Posso contar para todo mundo? Posso? Posso? Diga que sim, por favor, ah, vai diga que sim, siiiiiiim???… (Em 21/05/2015)

Então é isso: dia primeiro de Setembro de 2015 (segundo o autor – a editora informa que será um mês depois, em primeiro de Outubro) será lançado o livro Building a Scalable Data Warehouse with Data Vault 2.0! Sairá pela Morgan-Kaufmann, um selo da Elsevier, já que a Wiley caiu na bobagem de dispensá-lo. Eis a capa, que já foi confirmada:

Capa do novo livro.

Capa do novo livro.

Show!! :-)

Instalando A Base Beltrano S/A

Em breve publicarei um post sobre o uso de metamodelos como fontes de dados no PRD. O post de hoje é para ajudá-lo a se preparar, e não traz nada de novo: como instalar Postgres e as bases da Beltrano S/A.

Esse post é uma atualização das instruções de instalação da base de treinamento Beltrano S/A. Você pode seguir este link para conhecer a Beltrano e como ela foi pensada. O texto a seguir apareceu pela primeira no Capítulo 3 do livro Pentaho na Prática.

Instalando e Configurando um Postgres

Para usar as bases OLTP e DW da Beltrano você precisa ter um Postgres instalado e funcionando, bem como conhecer o usuário root e sua senha. Se você já tem um, clique aqui e pule para etapa seguinte. Caso contrário, siga os passos descritos nesta seção para instalar um Postgres em sua máquina.

Se você usa Windows, continue lendo. Se usa Linux, pule para a próxima seção.

Instalar PostgreSQL no Windows XP

As instruções de instalação no Windows estão disponíveis em um e-Book gratuito.

Capa do e-Book Instalando Postrgres 9.0 no Windows.

Capa do e-Book Instalando Postrgres 9.0 no Windows.

Você pode usar o Calibre ou qualquer outro programa leitor de e-Pubs para lê-lo.


Eu tinha uma licença do WindowsXP e resolvi aproveitá-la para fazer esse tutorial. Pelo mesmo motivo (falta de licença) não existe tutorial para Windows mais novos. Entretanto, a uniformidade entre as versões do Windows deve ser o bastante para que você possa seguir praticamente 100% do tutorial em qualquer versão mais recente do Windows.


Instalar PostgreSQL no Linux

Linux é um sistema operacional com n sabores – distribuições – e é virtualmente impossível cobrir todas. Por isso eu não fiz um livro mostrando como instalar Postgres em Linux, mas fiz para Windows. Vamos ver um passo-a-passo para Debian/Ubuntu. Se não for o suficiente, acesse a página de instalação do PostgreSQL para outros Linuxes.

Esse procedimento funciona em qualquer derivado Debian (como o Ubuntu). Existem opções gráficas, mas a linha de comando é universal e relativamente simples.

  1. Abra um terminal de comandos;
  2. Digite,seguido de \[ENTER\]:
    sudo apt-get install postgresql
    
  3. Se perguntado, responda Y ou S. Assim que a instalação acabar você terá um banco instalado, configurado e em operação, mas vazio;Em seguida, altere a senha do usuário-padrão, postgres, para algo fácil de lembrar (e potencialmente inseguro), como postgres. Faça assim:
  4. Entre na conta de usuário Postgres do sistema operacional (aquele que executa o programa do servidor:)
    sudo su – postgres
    

    Esse usuário do sistema operacional (postgres) tem permissão para acessar o servidor PostgreSQL diretamente. Ele é criado pelo processo de instalação do banco e recebe uma senha aleatória, que nunca é mostrada ao usuário final. Como não sabemos nem a senha do usuário nem a senha do root do banco, precisamos fazer login na conta de sistema operacional postgres com sudo. Você até pode modificar a senha desse usuário, mas não há razão para isso.

  5. Agora entre no programa de interface de linha de comando do PostgreSQL, o PSQL, digitando o comando:
    psql
    
  6. Deve aparecer um prompt, esperando comandos, parecido com isso:
    postgres=#
    

    Pronto, você está no prompt do PSQL. Agora altere a senha do usuário do banco (que é diferente do usuário do sistema operacional no qual o banco é executado):

    ALTER ROLE postgres with password 'postgres';
    

    ROLE é o usuário, e entre as aspas simples está a nova senha – postgres. Se deu tudo certo, deve aparece uma mensagem como:

    ALTER ROLE
    postgres=#
    
  7. Saia do PSQL, digitando \q seguido por \[ENTER\];
  8. Faça logout da conta postgres, digitando exit seguido por \[ENTER\].

Agora você tem um servidor PostgreSQL instalado e pronto para ser usado. Sempre que precisar acessá-lo para algo, comande:

    psql postgres -U postgres

Se ele pedir senha, ela será postgres.

Fazer o Postgres Aceitar Qualquer Conexão


Atenção! O procedimento abaixo vai abrir seu PostgreSQL para acesso por qualquer um na mesma rede em que você está! Lembre-se disso ao criar bancos e gravar dados nele. Essa configuração é útil para desenvolvimento, testes, treinamento, mas é perigosa para ambientes de produção ou no caso de dados sensíveis.


  1. Volte à conta do postgres. Em um terminal, entre novamente:
    sudo su – postgres
    
  2. Abra o arquivo de configuração pg_hba.conf para edição com seu editor de textos favorito. Nosso exemplo usa o nano:
    nano etc/postgresql/X.Y/main/pg_hba.conf
    
  3. Vá até o final do arquivo e insira a seguinte linha:
    host all all 0.0.0.0/0 md5
    

    Isso vai fazer com que o servidor aceite conexões de qualquer IP, desde que forneça usuário (postgres) e senha (postgres) para qualquer banco;

  4. Salve o arquivo (nano: CTRL+O) e depois saia do editor (nano: CTRL+X);
  5. Agora edite o arquivo de configuração do servidor postgres.conf:
    nano etc/postgresql/X.Y/main/postgresql.conf
    
  6. Role o arquivo até encontrar a linha com listen_addresses;
  7. Altere localhost para *. Isso vai fazer com que o servidor passe a ouvir conexões de qualquer IP;
  8. Salve o arquivo (nano: CTRL+O) e depois saia do editor (nano: CTRL+X);
  9. Re-inicie o servidor:
    /etc/init.d/postgresql restart
    
  10. Finalmente saia da conta de usuário postgres:
    exit
    

A partir de agora qualquer cliente PostgreSQL pode se conectar ao seu servidor.


Dica: se você for adotar o PostgreSQL como banco para sua empresa, contrate suporte especializado e treine pelo menos um DBA. Você faria isso com Oracle e MS SQL Server, porque vai deixar de fazer com PostgreSQL (ou MySQL)?


Instalando as Bases

Primeiro, instale as bases:

  1. Baixe-as destes links (clique nos nomes dos bancos:)
    1. Beltrano (OLTP) (arquivo beltrano_oltp_10k_pedidos.backup.zip;)
    2. Beltrano DW (arquivo beltrano_dw.backup.zip;)
    3. Beltrano Log (arquivo beltrano_log.backup.zip;)
  2. Descompacte-as em um diretório conhecido e sem espaços no path. Por exemplo, C:\ no Windows e /opt/beltrano no Linux.
  3. Se você usa Linux, não se esqueça de mudar as permissões dos arquivos (já descompactados) com um chmod 777 *.backup.Usando o PSQL (interface de linha de comando do Postgres), conecte-se ao servidor, crie um banco vazio para cada base e restaure-as neles:
  4. Rode o PSQL:
    1. Windows: rode o programa SQL Shell, que fica em Menu Iniciar -> Programas -> Posgtres <Versão> -> SQL Shell (psql);
    2. Linux: abra um terminal e comande psql -U postgres. Isso vai conectar você ao servidor localhost, porta 5432, banco postgres, com usuário postgres;
  5. Crie o novo banco de dados, comandando:
    1. Beltrano OLTP: CREATE DATABASE beltrano; (inclua o ponto-e-vírgula!);
    2. Beltrano DW: CREATE DATABASE beltrano_dw; (não se esqueça do ponto-e-vírgula!);
    3. Beltrano Log: CREATE DATABASE beltrano_log; (já sabe, não? Ponto-e-vírgula incluso!);
  6. Conecte-se a cada uma das bases recém-criadas e restaure-as. Ou seja, ainda no psql, comande (pressionando \[ENTER\] ao final de cada linha:)
    \c beltrano
    \i /opt/beltrano_oltp_10k_pedidos.backup
    \c beltrano_dw
    \i /opt/beltrano_dw.backup
    \c beltrano_log
    \i /opt/beltrano_log.backup
    

    Cada um destes comandos terá uma resposta. Os comandos \i efetivamente populam o banco, processando cada linha do script, e por isso resulta em uma lista maior de respostas – uma para cada comando do arquivo de backup.


Esse script é para Linux!


Windows: entre os mesmos comandos acima, mas use o caminho c:\, com barra contrária, ao referenciar o arquivo. Por exemplo:

  • \i c:\beltrano_oltp_10K_pedidos.backup
  • \i c:\beltrano_dw.backup
  • \i c:\beltrano_log.backup

Voilà! Bases instaladas e prontas para os exercícios. Você pode comprovar usando o pgAdmin para examinar os bancos e verificar o conteúdo das tabelas.

Bases restauradas (pgAdmin III do Windows.)

Bases restauradas (pgAdmin III do Windows.)

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 116 outros seguidores