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. ;-)

ERP BI Solutions

E esse é o mundo de hoje: quando você pensa em fazer algo, alguém já fez. Conheçam ERP BI Solutions, primo do OpenBI Solutions:

ERP BI Solutions provides business intelligence solutions for popular open source ERP systems including PostBooks and XTuple ERP. Solutions are designed using data warehousing best practices and are built on best-of-breed open source BI technology giving you cost effective, innovative business intelligence.

Assim como o OpenBI Solutions oferece soluções de BI para softwares comuns (como o atual Apache) e de treinamento (Beltrano S/A), o ERP BI Solutions oferece soluções de BI com Pentaho para ERPs Open Source. A última publicação é de janeiro de 2014 e atende aos ERPs PostBooks e XTuple. Imagino que a coisa ande devagar, pois mais difícil que criar esses projetos é mantê-los em par com os respectivos ERPs.