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

Testando o Vertica

Já há alguns anos eu quero testar um banco de dados colunar. Desde o Pentaho Day 2014 eu fiquei muito curioso para brincar com o HP Vertica, mas não tinha tido o tempo (nem um banco com volume) suficiente para todo o trabalho que isso implica.

No final de 2014 eu consegui instalar uma máquina virtual com o Vertica 7.1.1 (em um Ubuntu Server 14.04.1.) Construí uma dúzia de transformações que copiaram todos os cubos de um DW em Postgres para esse Vertica. Configurei um BI Server 5.1 com as duas fontes de dados, e um esquema Mondrian para cada uma dessas fontes. Ontem em consegui fazer e tabular um experimento simples: usando o jPivot, abri o maior dos cubos (14.095.514 de linhas) e fiz uma exploração simples: abri e fechei cada uma das seis dimensões principais. Todas elas tinham entre um e três membros no nível hierárquico superior, exceto por uma dimensão data, que tinha 11 membros no nível do ano.

O Experimento

Fiz essas navegações logo após o boot do servidor, com cache vazio, e com um esquema (=banco) de cada vez. Capturei o log MDX e SQL do Mondrian para cada caso. Elas foram tão idênticas que foi possível comparar até mesmo o SQL gerado entre os dois experimentos. Como o Vertica é um Postgres colunar, o SQL era idêntico até a última vírgula, e isso facilitou a comparação.

Veja, eu não estava fazendo um estudo milimetricamente planejado. Eu só queria obter um sentimento da relação de performance entre as duas tecnologias. Logo, o resultado vai refletir o preparo do experimento. A informação será mínima, binária: em plataformas de hardware parecidas, qual base é mais rápida?

Tempo total para fazer a mesma coisa.
Tempo total para fazer a mesma coisa.

É o Vertica, sem sombra de dúvida. A máquina virtual do Vertica tinha 2GB de RAM e uma CPU – um quarto do meu i7 2.4GHz. A máquina do Postgres é a minha máquina real, com 16GB de RAM além de toda a CPU disponível. A máquina virtual estava desligada, de modo que minha CPU não estava particionada no momento do teste do Postgres.

O gráfico anterior mostra o tempo total para repetir a mesma operação com o mesmo cubo, usando bases diferentes. Já o gráfico abaixo compara cada uma das operações – que por acaso são 15 – usando uma escala logarítmica no eixo Y.

Tempo por operação nas duas tecnologias.
Tempo por operação nas duas tecnologias.

Curiosamente, e talvez até previsivelmente, o Vertica teve um desempenho uniformemente melhor que o Postgres em todas as operações que levavam mais tempo, mas perdeu feio nas operações M e N, que duraram menos de 50 ms. Destas operações, a M é o pior resultado do Vertica: 42 ms a 0 ms para o Postgres. Ou seja, uma operação que durou mais de 40 ms no Vertica foi tão rápida no Postgres que o log do Mondrian não conseguiu medir.

Lendo a documentação do Vertica eu vi um tópico que discute exatamente isso: consultas menores tendem a ter um overhead proporcionalmente maior que bancos relacionais.

Legal.

Em compensação, o Vertica foi mais rápido em tudo que levou mais de 50 ms. Em alguns casos, como o O, ele chega a ter mais de uma ordem de grandeza de vantagem – 22 vezes mais rápido no caso da operação O.

A Conclusão…

… é óbvia: o Vertica parece ser muito interessante para exploração OLAP de fatos com milhões de linhas. Sendo um cientista, eu estou perfeitamente ciente do risco que seria generalizar essa conclusão para um “logo ele será bom para tudo”. Existe um caso de uso no qual eu estou particularmente interessado, um relatório (PRD) tabular construído sobre esse mesmo cubo. Meus próximos testes vão tentar determinar se é uma vantagem usar Vertica ou não.

E eu aposto que é.

Feliz Ano Novo!!

Ué, Cadê o Perry?

Quem tem filhos pequenos (e usa-os como desculpa para assistir desenhos animados) conhece essa: o Phineas anuncia ao Ferb que “já sabe o que vamos fazer hoje”, olha para os lados e diz “ué, cadê o Perry?” O telespectador já sabe: segundos antes o Perry se esgueirou e sumiu por alguma passagem secreta, em direção à sua próxima missão contra o mais recente -inator do Dr. Doofenshmirtz – só o Phineas e cia. bela é que ainda não tinham notado.

O mundo está cheio destes momentos: “ué, cadê os números romanos?”, “ué, cadê a máquina de escrever?” e assim por diante. (Sério, os números romanos demoraram centenas de anos para sumir de vez.)

O que caracteriza esse momento ué-cadê-o-perry, na minha opinião, é o instante em que ele sai, mas ninguém no desenho notou ainda. É quando uma novidade que vai mudar a cara do mundo apareceu, mas ninguém ainda se deu conta dela, ou de que ela já mudou o mundo.

Tantas Opções, Tão Poucos Projetos…

Então, já repararam na quantidade de novos bancos de dados que apareceram recentemente? Hadoop é o mais vistoso, mas temos coisas como VoltDB, Vertica, MongoDB, InfiniDB, Infobright etc. etc. etc. E note bem: nenhum deles veio para ser um Hadoop-me-too ou um novo Postgres. Cada um deles oferece recursos específicos para tarefas específicas.

Com esse monte de opções, e com um entendimento mais claro de como um Data Warehouse Corporativo (ou EDW) pode ser arquitetado, vemos que não precisamos mais de um Banco de Dados Relacional para montar um DW. Com isso sabemos que um Sistema Gerenciador de Bancos de Dados Relacional pode se dedicar a tarefa que faz melhor (executar transações) e deixar soluções de BI usar outros softwares.

Arquitetura Típica de EDW

Um EDW deve acumular dados por um tempo a fio, sem final em vista. Até hoje, em quase quinze anos nesta indústria fundamental, eu nunca vi um modelo de dados mais adequado a um EDW que Data Vault.  Acredito que a melhor técnica para um EDW é um modelo de dados DV montado sobre um Hadoop. Graças tanto à flexibilidade e resiliência do DV, quanto a escalabilidade do Hadoop, um arranjo desses pode se sustentar durante anos a fio sem problemas.

Mas como DVs são bons para acumular e péssimos para apresentar (e não é por causa do Hadoop, que por acaso também tem o mesmo problema), a exploração não pode acontecer dentro do EDW. Neste ponto notamos que precisamos de Data Marts.

Esses Data Marts são trechos do EDW colocados ao alcance do usuário final. Disparado, a melhor organização para atender essa necessidade é um Modelo Dimensional.

Então temos dados extraídos dos sistemas de origem carregados em um EDW Hadoop+DV, e deste arranjo dados para exploração pelo cliente são carregados em Data Marts Dimensionais. Como Data Marts prestam-se, principalmente, à análise multidimensional e relatórios, a melhor opção para guardar esse extrato de dados é uma tecnologia que privilegie essa função. Não é uma discussão encerrada, mas há uma seção inteira de bancos de dados analíticos (ou colunares) dedicados a atender exatamente esse tipo de demanda. Exemplos dessa turma são o proprietário gratuito (até 1TB) Vertica, o livre InfiniDB e o fantástico (e caro, proprietário) SybaseIQ.

Ué, Cadê o SGBDR?

Colocando em uma figurinha simples, temos:

Soluções de BI sem Bancos de Dados Relacionais
Soluções de BI sem Bancos de Dados Relacionais

Ué, cade o banco de dados relacional em BI?

Não tem, sumiu. Enquanto ninguém olhava, ele esgueirou-se em direção às novas missões transacionais, e deixou esse nicho ser (adequadamente) preenchido por tecnologias mais apropriadas a BI.

Conclusão

O título original deste post era “Fim de Uma Era”, mas achei pomposo demais e muito ordinário. Isso, porém, não muda o fato de que a era dos SGBDs Relacionais usados para Soluções de BI realmente acabou. Ainda vamos ver empresas investindo nessa tecnologia para montar EDWs porque temos uma inércia em tudo que fazemos, e ainda estamos na curva ascendente de criação de mão-de-obra especializada em Hadoop et. al.

Mas tão logo a oferta mão-de-obra cresça o bastante, o sinal da equação vai mudar e a dobradinha de bancos NoSQL + Analíticos passará a a ser mais barata e eficiente que bancos relacionais, quando então teremos aquele momento:

Ei, cadê o Perry?
Ei, cadê o Perry?

É isso. ;-)

M.I.N.A.

Há anos Inteligência de Negócios deixou de ser uma opção. A empresa que não usa BI, hoje e no futuro, simplesmente não irá crescer além de certo ponto.

Inteligência de Negócios não é fácil, muito menos simples. Um projeto de BI de sucesso depende de muitos fatores, e não é uma tarefa para leigos. Projetos de Inteligência de Negócios são intensivamente dependentes do conhecimento dos gestores, dos desenvolvedores e do cliente. O cliente de um projeto de BI precisa estar educado para poder usufruir dele.

Um best-seller não nasce de qualquer um que disponha de um editor de textos. Um novo software não nasce a partir das mãos de um usuário com um produto point-and-click. Soluções de BI também não. O mundo é um lugar complexo e tem cada vez menos espaço para amadorismo e ignorância. Go educated or go extinct!

Manifesto Ágil

Esse foi um documento que dividiu as águas da indústria de artistas que são os desenvolvedores e criadores das tecnologias de TI, incluindo programadores, projetistas de hardware e software e um sem-número de outros profissionais. Apreender o M.A. quebrou os grilhões dos cronogramas atrasados, dos projetos destinados ao fracasso e me permitiu trilhar caminhos de sucesso sem precedentes.

Meu credo como desenvolvedor e gestor é o Manifesto Ágil, e Scrum é o método que eu adotei para implementá-lo. Eu os uso como ferramentas para tudo que faço, incluindo e especialmente Ensino e Inteligência de Negócios.

Eu descobri que, influenciado pelo M.A., tenho seguido alguns destes princípios para projetos de Inteligência de Negócios, e vim dividi-los com vocês.

Manifesto de Inteligência de Negócios Ágil

A maior prioridade é ajudar o cliente a responder suas perguntas, através da entrega contínua e cedo de dados e interfaces para sua exploração.

Mudanças nos requisitos são obrigatórias porque só assim a exploração cognitiva toma forma e novas hipóteses podem nascer.

Entregar avanços nas plataformas de dados frequentemente, entre semanas e meses, com preferência para o intervalo menor.

A principal medida de sucesso é o cliente encontrar resposta à suas perguntas, para que possa fazer novas perguntas.

Participar do problema do cliente: ajudá-lo a responder suas perguntas para ajudá-lo a formulá-las através do emprego de conhecimento especializado de técnicas e ferramentas.

Conclusão

Essa lista não se sustenta sozinha, mas sim estende o Manifesto Ágil. Ela também não executa o desenvolvimento, isso é feito por Scrum e uma técnica especial para BI, que eu postarei aqui em breve.

Não concordo que Agile BI seja apenas sobre ferramentas. É muito pouco, e deixa muito de fora – a começar pelo clientes.

Eu não inventei esses princípios. Depois de estudar o Manifesto Ágil, Scrum e várias outras técnicas, e aplicá-las ao meu dia-a-dia profissional, eu descobri que esses princípios surgiram espontâneamente e vêm norteando minha prática profissional. Eles são praticamente o Manifesto Ágil adaptado para BI – algo do qual eu sinto uma falta tremenda. Como ninguém ainda propôs nada, eis a minha proposta.

O que você acha?

Resenha: Pentaho BA Cookbook

A Editora Packt lançou em agosto de 2014 um novo membro da família de “cookbooks”, por Sérgio Ramazina: Pentaho Business Analytics Cookbook, primeira edição.

O hoje defasado Pentaho Solutions foi a primeira fonte oficial de informações sobre a plataforma, mas ele não era um livro prático, ainda que bom. Mesmo que já conhecia e usava a plataforma precisava bater um pouco a cabeça para aproveitar o conhecimento ali depositado. Muitos de nós precisávamos mais do que aquilo. Nós precisávamos de receitas prontas para resolver os nossos problemas e dificuldades com cada componente da Suite Pentaho. Esse é o nicho que a Editora Packt vem preenchendo diligentemente: já são CENTENAS de “cookbooks” – literalmente “livros de receitas” – cobrindo todo tipo de necessidade de TI.

Neste volume estão cobertas várias receitas a versão 5.0 da Suite Pentaho, hoje a mais nova. Excetuando o PDI, que já tem uma boa meia-dúzia de livros na Packt, ele aborda praticamente tudo o restante: BA Server, Metadata Editor, Schema Workbench, PRD, e algumas operações com a Enterprise Edition além de um pouco de C*Tools.

The Good

É um compêndio relativamente completo de tudo que merece atenção na plataforma:

  • BA Server: como configurar fontes de dados JNDI, integrar com LDAP e gerenciar fontes de dados;
  • Metadados: é o primeiro lugar que mostra como usar “concepts”, além de outras dicas importantes (como criar campos calculados e junções complexas);
  • Schema Workbench: como criar um cubo, como membros calculados e tudo;
  • PRD: muito completo, com receitas para construir relatórios com prompts e sub-relatórios, incluindo o uso de “sparklines”, além de usar transformações do PDI como fontes de dados.

Não bastasse a grande quantidade de receitas, todas úteis, o livro ainda vai além disso e oferece receitas de coisas menos buscadas, como customização da interface e introdução ao CDE (C*Tools) – sempre com exemplo prático.

A obra também traz receitas sobre o Pentaho Enterprise Edition, o que leva seu nível a um outro patamar. Apesar de a versão comunitária ser capaz de oferecer todos recursos, a adoção da EE está crescendo, e muitos recursos ainda restam por ser plenamente utilizados por esses clientes. Se o livro já é útil pela simples qualidade e pela variedade de receitas, ele se torna ainda mais interessante com receitas que cobrem:

  • Analyzer: cliente OLAP;
  • Dashboard Designer: editor de dashboards
  • Interactive Report: para criação de relatórios ad hoc via web (parente do Saiku Reporting e do finado WAQR);
  • Mobile: a interface para iPad e celulares.

Mais do que ajudar quem possui o EE, o livro mostra grandes detalhes do produto a quem não o possui. Na minha opinião isso é excelente, porque dá a chance de conhecer de perto as vantagens do EE – que é um produto de alta qualidade e (muuuuito) baixo custo.

Finalmente, o livro não apenas tem uma lista extensa de como-fazers, mas o formato de livro de receitas da Packt traz a receita em si e explicações de como e porque as coisas acontecem, e orientação sobre que direção seguir para obter mais informações, ou o sobre o que mais há para aprender. Todas as receitas têm ao menos uma figura, e todas as figuras são claras e bem definidas. O formato Kindle (no qual eu li o livro) sempre piora um pouco as imagens, mas mesmo assim ainda ficou muito bom.

Pelo detalhismo do conteúdo, sua amplitude (incluindo muitas coisas de CE e EE) e a usabilidade de todas as receitas, o Pentaho BA Cookbook mostra-se mais um volume indispensável para quem usa a Plataforma Pentaho no seu dia-a-dia, para o estudante eventual e mesmo para o iniciante.

The Bad

Que não reste dúvida: o livro é muito bom e muito útil. Se você precisa aprender sobre a Plataforma Pentaho, versão 5, esse é o livro.

Isto posto, há um bocado de coisas que ainda não estão 100%:

  • A versão Kindle não tem as divisões de capítulo: se você arrastar o dedo na tela, o livro pula para o início ao invés de para o capítulo seguinte/anterior;
  • Algumas das receitas são muito triviais. Se o leitor precisa daquela receita, então ele precisa de ajuda também para instalar os programas, mas o livro não mostra isso (claro: livros de receita não ensinam a comprar fogão e a ligar o fogo!)
  • Senti falta de receitas importantes, como instalar o BA Server CE com outros bancos de dados. Essa orientação existe no Pentaho Infocenter, e por isso talvez não tenha sido incluída. Mas algumas outras coisas existem no Infocenter e mesmo assim entraram no livro;
  • Senti falta de receitas de performance, como instalação de cache externo e aplicação de tabelas pré-agregadas;
  • Há um pouco de mistura de assuntos, e a separação ainda pode ser melhorada. Por exemplo, há um capítulo só com receitas da nova interface do BA Server, bem no início, e um outro com receitas sobre agendamento quase no final. Como é tudo assunto do BA Server, talvez fizesse mais sentido estarem juntas ou no mínimo subsequentes;
  • Plugins: a quantidade de plugins no Pentaho Marketplace vem crescendo a olhos vistos, mas o livro aborda apenas dois plugins (Saiku e Logs), além da internacionalização;

Nenhuma dessas coisas atrapalham o livro, mas elas estão lá (ou não) de qualquer forma.

The… Italian

A Packt é uma editora internacional, verdadeiramente global e seu elenco de escritores reflete isso: eles têm gente literalmente do mundo todo e o fato é que todos precisam escrever em, no mínimo, inglês. Há essa multitude de culturas e línguas forçosamente enquadradas em uma língua (para o autor) estrangeira. Resultado: uma presença maior ou menor de expressões curiosas, atípicas do inglês falado por nativos.

O Sérgio Ramazina é italiano e como bom latino (assim como nós, brasileiros), tende a pensar em inglês mais literalmente. Por exemplo, quase dá para ouvir seu sotaque em expressões como “This is the idea that stays behind the concept of(…)” (locus 2028.) Um nativo escolheria uma frase mais sintética, com outro verbo:  “This is the idea behind the concept of(…)”

O autor meio que esgotou a cota dele desses regionalismos, mas isso não chega a atrapalhar a leitura. Com certeza causam alguma estranheza em quem esteja mais acostumado ao inglês escorreito, mas para mim, latino com o Sérgio, essas expressões são transparentes porque fazem sentido em português. Talvez leitores de outras nacionalidades sintam alguma dificuldade – como quando eu preciso reler trechos escritos por japoneses, por exemplo.

Conclusão

Instalou a versão 5 da suite Pentaho? Migrou e agora precisa fazer o que já fazia? Quer começar com Pentaho, baixou o produto mas agora está em dúvida sobre como realizar cada tarefa?

Então o Pentaho BA Cookbook é o seu livro: rico em receitas úteis, detalhadas e bem explicadas. Ele aborda assuntos variados, todos relevantes, sobre o servidor e alguns dos clientes Pentaho. Ainda que precise de algumas melhorias (e nestas não se incluem as idiossincrasias de autor), e não traga absolutamente tudo que existe (o que seria um exagero de qualquer forma), esse é o livro sobre a versão 5.0!

Packt Comemora 10 Anos com tudo a US$10!

Em julho a Editora Packt  completou 10 anos e lançou uma campanha: todos vídeos e e-books no site por US$10,00!

Imagine que você precisa aprender algo novo – seja por trabalho, por interesse particular, por qualquer motivo. Como fazemos hoje? Google! Tutorial, Passo-a-Passo, blogs, fóruns etc. etc. etc.

Bom, a Packt oferece centenas de livros para novatos e profissionais que precisem aprender algo sobre uma determinada tecnologia. Não é brincadeira: valem por um curso! Quer exemplos?

  • Vídeo Building a Data Mart with PDI: em um conjunto de vídeos com excelente qualidade de som e imagem você aprende como montar um Data Mart dimensional. Autor? Ninguém menos que o Diethard Steiner, um dos grandes profissionais Pentaho no mundo;
  • Livro Pentaho Data Integration Cookbook (2nd. Ed): a arca do tesouro do PDI!! Imperdível!
  • Livro Hadoop Beginner’s Guide: eu consegui montar um servidor Hadoop seguindo as orientações desse livro, que não apenas é muito bom, mas é gostoso de ler!
  • Livro HP Vertica Essentials: de novo, eu saí do zero e completei um servidor Vertica sozinho, sem precisar de Internet nem nada! Outra pérola!
  • Livro QlikView 11 for Developers: tudo que você sempre quis saber sobre o QV, mas não tinha na Internet! Finalmente consegui entender como o QV funciona (e desmistificar aquele “qualquer data, de qualquer lugar”! QV dá tanto trabalho quanto qualquer ferramenta!)
  • Livro Bonita Open Solution 5.x Essentials: outro caso de muita informação de qualidade e valor.
  • Data Mining (RapidMiner, R), Zabbix, Postgres, MySQL, Minecraft (!!!), Apache, Oracle, SQL Server, Closure, HTML5, PenTesting, jQuery, Spark, Lumion 3D, Raspberry Pi, OpenStack …

Putz… Acho que faz tempo que não leio nada que não venha da Packt (e olha que eu sou fã da Wiley!)

Enfim, você está trabalhando com TI? Precisa aprender a mexer com alguma tecnologia (hardware, software – livre _E_ proprietário), ou precisa melhorar? Está curioso e quer brincar com robôs ou automação do lar? A Packt tem – e é bom!

A promoção acaba amanhã, 5 de julho, mas ainda dá tempo: dê um passeio no site deles, você não vai se arrepender.

O Que Leva à Alta Performance?

Michael Porter, da Harvards Business School, diz que o rendimento de uma empresa é empurrado por dois fatores: estratégia e execução.

Phil Rosenzweig escreveu em seu livro The Halo Effect (com a tradução Derrubando Mitos) que, se isso é verdade, então tocar uma empresa com sucesso é uma coisa arriscada pelo simples fato de que nada dá a menor garantia que escolheremos sempre a estratégia vencedora, ao invés de alguma outra estratégia furada.

Não bastasse a dificuldade na escolha da estratégia, a execução dela também é um desafio de porte semelhante. Coisas que funcioaram para uma empresa não necessariamente vão funcionar para outra. Coisas que deram certo no passado ou em outro mercado, podem não dar certo agora, para sua empresa. Ou seja, a execução é algo que também depende de sorte e de alguma experimentação. Claro que existem coisas que são atemporais e independente de mercados ou indústrias – gestão de pessoas, finanças, estoque, algumas automações etc. Uma empresa depende de tantos processos e de tanta gente para funcionar que uma parte dela, com certeza, será particular ou diferente do restante.

Não sei se consegui me fazer entender, e por isso aqui vai o resumo:

  • Duas das maiores e mais afinadas mentes científicas de nosso tempo argumentam que o sucesso de uma empresa depende de sua estratégia e da execução dessa;
  • Adotar uma estratégia é igual a descartar TODAS as outras estratégias possíveis;
  • Não é possível saber de antemão qual estratégia vai dar certo, e qual vai dar errado;
  • Implantar (executar) essa estratégia é algo que depende de conhecimento, experimentação e sorte.

Melhorou? Leiam o livro do Rosenzweig para uma iluminação maior, mas se você acha que entendeu a lista acima, beleza, consegui o que eu queria. Próxima pergunta:

Como Escolher uma Estratégia?

O Rosenzweig discute isso brevemente. Resumindo, não dá para competir com todo mundo, em todos os mercados, oferecendo todos os produtos para todos os clientes. É preciso fazer escolhas, é preciso tomar decisões, como por exemplo:

  1. Em que mercado vamos atuar?
  2. Que produto vamos oferecer?
  3. Contra quem vamos concorrer?
  4. Vamos vender por menos que a concorrência, ou cobrar um prêmio por mais qualidade/conteúdo/rendimento/etc?
  5. Quanto os clientes estão dispostos a pagar?

Como Executar a Estratégia?

Larry Bossid disse que “Nenhuma estratégia entrega resultados a menos que convertida em ações específicas.” Uma vez que a estratégia foi escolhida, a execução precisa ser suficiente e isso implica em fazer mais escolhas. É irreal pretender executar 100% das atividades possíveis e ter 100% de qualidade em 100% das vezes. É preciso escolher no que investir tempo e recursos, e decidir que atividades serão deixadas de lado ou terão menos atenção.

A diferença entre a execução e a estratégia é que a estratégia depende muito do que está fora da empresa, e a execução depende quase que totalmente do que está dentro da empresa.

Ou seja, se a sua empresa ainda não existe, se ela é só um Plano de Negócios, você precisa de dados gerados por outrem. Você não tem nada, e precisa pesquisar tudo. Você ainda não sabe nada sobre seu (futuro) negócio, tudo são estimativas, chutes e palpites.

Você faz o melhor que pode para tirar a empresa do papel, e durante um tempo voa por instrumentos, meio às cegas, contando com a melhor informação que você conseguiu acumular e seu taco para o negócio.

Uma vez que sua empresa passou a existir, dados começaram a ser gerados – pedidos, itens produzidos, serviços prestados, clientes adquiridos e perdidos, lucratividade, competição, market share etc. etc. etc. A partir daí você pode avaliar se está indo bem ou não. Você consegue dizer se está executando bem, ou não, se sua estratégia está dando certo, ou não.

Inteligência de Negócios, Estragégia & Execução

Rosenzweig conclui, no capítulo nove do Halo Effect, que executar brilhantemente uma estratégia de sucesso pode levar uma empresa à falência. Se o mercado mudar, se a tecnologia mudar, se a concorrência mudar – se alguma coisa mudar o mundo no qual sua empresa existe –  sua empresa vai ficar vulnerável, e a única forma de lidar com isso é estar sempre atento e, eventualmente, decidir mudar de estratégia, antes que seja tarde demais. No final deste capítulo, Rosenzweig cita Tom Peter de novo:

Para ser excelente, você precisa ser consistente. Quando você é consistente, você é vulnerável a ataques. Sim, é um paradoxo. Vire-se com isso.

E como você decide que é hora de mudar de estratégia? Como você descobre se o problema não é estratégia, mas sim execução? Ou o inverso?

Uma empresa é uma coisa viva, que existe em um mundo em constante mutação. Organizações podem ser entendidas em si, e em seu meio-ambiente, por um único indivíduo até certo tamanho: uma padaria, uma farmácia, uma escola – um supermercado, talvez. Acima de um certo tamanho, as interações dentro da empresa, e da empresa com o meio externo são tão numerosas e complexas que uma só pessoa não consegue abarcar em sua mente toda aquela informação e tirar sentido dela. A partir de um certo tamanho, repensar a estratégia e avaliar a execução passa a ser uma tarefa sobre-humana.

E é nesse ponto que se encontra o valor da Inteligência de Negócios. A captura e análise sistemática de todos os dados que sua empresa gera, e se possível, dados do mercado e dos clientes, só pode ser feita com ferramentas específicas. Essas ferramentas se separam em duas categorias: acúmulo de dados e análise de dados. Armazéns de Dados (Data Warehouses) cuidam do acúmulo. Ferramentas como OLAP e Data Mining cuidam da segunda. Recursos de apresentação, como painéis e relatórios, comunicam os resultados para a empresa, e servem como guias para avaliar o risco da estratégia atual, para avaliar a qualidade da execução em curso.

Inteligência de Negócios é a disciplina que habilita uma empresa a buscar alto rendimento.

Juntando à conclusão do post anterior:

Inteligência de Negócios é a disciplina que habilita uma empresa a buscar alto rendimento através da compreensão de seu negócios mediante a aplicação do Método Científico.

Fechou, é isso. Até a próxima.

Lavando Louça (ou Paz, Afinal III)

Todo mundo que lava louça em casa sabe que essa é uma atividade mecânica, meio que automática depois de um tempo, e também sabe que nesta situação a mente fica ociosa e acabamos pensando em qualquer coisa.

Bom, então, eu estava lavando louça esses dias e me lembrei de uma conversa que eu tive no LinkedIn, e só então me dei conta da importância do que foi discutido. O restante da discussão não vem ao caso, mas eu posso contar o santo: o autor, Diego Elias, propunha uma contextualização de BigData em BI. No meio da conversa eu soltei:

No meio da bagunça (entendeu o lance das faixas pretas?) eu soltei essa.
No meio da bagunça (entendeu o lance das faixas pretas?) eu soltei essa.

Try to See the Truth:

There Is No Spoon.

Eu simplesmente não aguento mais fazer posts sobre definições de coisas fundamentais, e o mundo está até as tampas de literatura especializada, feita por gente muito melhor do que eu, de modo que tudo que eu possa falar é completamente redundante. Mesmo assim…

Mesmo assim, nas minhas turmas de BI eu sempre faço questão de insistir em um ponto:

Try to see the truth: There is no BI.
Try to see the truth: There is no BI.

Neste slide eu sempre mango do Matrix: tente ver a verdade, não existe BI. O slide diz tudo, mas não custa reforçar: BI é uma disciplina, da qual software-houses e fabricantes de hardware se apoderaram, ao ponto de existir uma carreira de Administração de Empresas, mas não uma de Inteligência de Negócios! BI está virando uma piada, como aquela sobre hardware e software(*1), “BI é quem toma a decisão errada, Administração é quem enfia o pé na jaca”.

E, se eu não me engano, até comentei essa idéia com um grande amigo da USP, durante o Pentaho Day de 2014.

Simplesmente

Taylor, em seu seminal livro, preconiza que a gestão empresarial deveria ser uma ciência, com movimentos friamente calculados e ponderados de antemão. É uma idéia tão forte e com tanto apelo que ninguém conseguiu, até hoje, deslocá-la. Todos reconhecem que Administração não uma ciência “no duro”, principalmente porque não é possível criar empresas em placas de Petri, mas mesmo assim tentamos nos cercar de fatos testados para conduzir uma empresa. Por isso fazemos pesquisas de opinião no mercado, por isso entrevistamos e testamos nossos candidatos antes de contratá-los, por isso medimos e tentamos controlar a qualidade dos produtos e processos.

Porque simplesmente faz sentido.

Simplesmente faz sentido relacionar causa (ferramentas sujas, falta de habilidade, material de baixa qualidade) com o efeito (produtos feios, mal-feitos, ordinários.)

Simplesmente faz sentido examinar os números da empresa para descobrir que história eles contam.

Paz, Afinal III: O que é Inteligência de Negócios

Simplesmente:

Inteligência de Negócios é a disciplina de busca da compreensão dos negócios de uma organização mediante a aplicação do Método Científico.

Eu entrei no SAS em abril de 2000. Fiz essa pergunta a um sem-número de pessoas, começando pela Country Manager do SAS em 2000 (é tomar decisões com ferramentas – grosso modo, já não me lembro bem o que ela falou), passando por todos os meus colegas de SAS, depois por um VP de vendas do SAS, daí para pessoas em indústrias, bancos, varejo, o pessoal da MicroStrategy, várias pessoas no meu emprego, fóruns etc. Sem contar os livros que eu li (li tanto que um dia botei tudo para fora e escrevi meu próprio) e mesmo assim eu não tinha nenhuma resposta. Nenhuma boa o bastante, simples o bastante, nenhuma que eu pudesse ler quando não soubesse o que fazer, que caminho seguir. Eu costumava usar a do livro do Swain Scheps, BI for Dummies, e ela fazia isso por mim.

Eu procuro essa definição há quase 15 anos. Obviamente eu não perguntei à pessoa certa, e deixei de ler exatamente o livro que tinha essa definição. Infelizmente eu continuo não sabendo qual é – quem sabe um dia eu encontro um dos dois. ;-)

Até a próxima.


 

(*1) Odeio notas-de-rodapé, mas não queria quebrar o raciocínio lá em cima: perguntado sobre a diferença entre hardware e software, o cara responde que “hardware é o que você chuta, software é o que você xinga”. :-) É engraçado porque é verdade…

Book Review – Practical Change Management

I work supporting and developing Business Intelligence solutions, a job that is all about changing things: updating a table layout in a database, changing an IP address in the ETL, adding users to the OLAP tool – pretty standard GitHub/SourceForge chores and the like. So when I was given a chance to review the new Impackt book, Practical Change Management for IT Projects, I dove in, little knowing how mistaken I was and how happy this misunderstanding was about to become.

Reading the book was like seeing the sea for the first time: wow! There is a whole field of corporate change management, with people planning and rolling out a change in detail!

I work with a large (+10.000 employees, US$1Billion/Year) brazillian federal government IT company and we do plan our rollouts (for new systems, new process, new softwares, corporate culture change and so on), but the book addresses it in a deeper level than we have ever done. The author writes with focus, with the tight and well constructed sentences only those who had done something a lot are able to use. You can see it is so and not a professional polished text because among the concise wording, here and there, you can spot some odd constructions, and sometimes the train of thought is strained a bit too long, even for the native English speaker.

Managing the Change without Chance

If Change Management, the discipline of planning and conducting some change in an organisation, were a shrink-wrapped product, this book would be its instruction manual. It neatly explains what change management is and how the change eventually go around happening (or not.) She explains what are and and then identifies the components of a change (the “Pillars of Change”), the participants, the components of a change program and finally she lays out a project pattern for making the change happen in an orderly fashion. So there is quite a detailed work break-down, with roles, activities, milestones, deliverables, documentation (with templates and credible examples), control meetings. The whole shebang.

Concurrently, and I believe this is what add most value to this book, while the author presents all the information and the method she walks the reader trough every piece of it by using a Case Study set at the beggining of the book. In it, Acme Corp is adopting a new buying system in replacement for an old one. This change must happen in every division of the company and, to makes things look worse, this very system holds a sizeable amount of responsability for the results of Acme. If something goes awry this fictional company profitability might be badly hurten.

The Only Constant is Change

Practical Change Management for IT Projects is worth every penny. If you might be affected by change anytime, buy and read it at once. It seems Change Management is not that widespread discipline as is Project Management so it might be possible your company has never heard about it in that formal way. I am no novice on corporate life and it strucks me with some shame I have never seem it around. I am at ease to confess my loss at it just because the last words in the book are saved for telling you (the reader) the importance of the awareness of Change Management, that this awareness is key to success and how to rise it. Hence, to share those ideas and the book are an important exercise alongside everything else.

The Hands Down

I must admit I became an Emily Carr’s fan. I enjoyed reading the book by its sheer style, the upbeat never-surrender-never-retreat attitude. There is some inspiring grandeur in how she poses the problem and the hardship everyone faces daily, and the feeling she imparts on the need for change just makes you feel good.

Well, now that I said how much the book is worth and much I enjoyed it, I can tell what I didn’t like.

The Caveats

To make it sure: the book is good, you won’t regret buying it. However…

She operates the change management on some level of optimism. Unfortunatelly, real companies seem to be much more difficult to deal than Acme. On ocasion she sets some ideal situation that is simply not every time attainable. Some sort of compromise usually kicks in everything we do but she does not acknowledge that much (she doesn’t deny it, thoug.) For instance, on location 2187 she states the extreme importance of having every event you invite user to to be well planed and features a bug-free version of the product involved in the change. Good luck getting it…

She avoids dealing with all the possible variations and cenarios, or even with a small set of possibilities, so everything seems to be under an “ideal world” lighting. Although the consideration on some variability would enrich the book, taking in consideration its lenght, the templates, walkthroughs, insights and tips, by not addressing this much of variability doesn’t hurt the final results and, after all, makes for a more readable and practical book.

Another thing I can spot as some hidden hindrance to the newly broken Change Manager is that she makes it seem so much easy and success prone. There is nothing wrong here, for with some training and a bit of practicing it will probably became easier to drive a change program. The risk is not being aware how easy it is not. She knows how to do and have come confidence on doing it and she stress constantly a Change Program takes a lot of effort to turn in a success, but she writes very well and easily gets the reader carried away (again, nothing wrong – passion is good. Just kiss with lights on, and with open eyes.)

Finally, I couldn’t find any reference to Scrum or some Agile method. The program has a very conservative look of a waterfall planing. Of course if it works out good, I can’t ask for anything else. But Scrum is such a powerfull way of managing project that Change Management, being all about commiting changes, should be connected to it in some way.

Conclusion

As I said, Practical Change Management for IT Projects is very good and in fact a must have: practical, usefull guide on how to make change happen and how to have some control on it. All in all, a good read in all the senses. Its only downsides are some optmism and a couple of beatifull scenarios. I also miss some relationship with Scrum or any Agile technique, but none of those aspects are really an issue.

There is some changing come my way and I am very happy I have mistakenly turned to this book for some dull code-versioning stintch. After all it was not anything I would imagine, but thanks to this misunderstanding now I can really help make change happening, something I didn’t even know about a couple of weeks ago.

Planos para 2013

Com o excelente ano de 2012 acabando – e eu em merecidas férias – é hora de pensar no que fazer em 2013. Essa é uma pequena lista de coias que eu pretendo abordar no ano que vem:

  1. Data Vault: acabei de ler o livro e estou fazendo uns testes. Podem contar como um dos meus próximos tópicos.
  2. Banco colunar: o LuciDB é um banco de dados especial para Data Warehouses, e passou da hora de eu fazer alguns testes nele. Já tenho o post bolado, só preciso implementar e medir os resultados.
  3. PostgreSQL 9.2: ele veio com algumas mudanças interessantes para Data Warehouse. Vou testá-lo e compará-lo com o LuciDB.
  4. Infobright: outro banco colunar dedicado a Data Warehouses, mas derivado do MySQL. Mesma vontade: comparar com Postgres 9.2 e LuciDB.
  5. Bonita: eu mantenho um blog sobre o Bonita Open Solution, uma solução de BPM livre e fantástica – o Pentaho do BPMS. Eu estou trabalhando numa séries de posts para testá-lo e pretendo construir uma solução de BI sobre o meu processo.
  6. Pré-Agregadas: já faz uns anos que eu quero escrever um artigo completo sobre isso. Quem sabe dessa vez vai?

Isso é o que está na minha lista, mas outras coisas devem vir. Por exemplo, quero completar a solução de BI do Apache , li um livro sobre dashboards que me deixou com algumas idéias e estou lendo um livro sobre Data Mining do qual vou testar algumas coisas também. E, é claro, conto com sugestões de vocês sobre quaisquer assuntos relacionados à BI.

Feliz Natal e Próspero Ano Novo!

Até 2013!