Livros

Mais ou menos uma vez por mês eu entro na Amazon, seção de livros, e digito “dw” ou “bi” ou “data mining” ou algum jargão da nossa área. Eu reviso a lista resultante e vou separando (clicando com o control apertado, para abrir em outras abas) todo e qualquer livro que eu ache interessante. Reviso essa seleção mais uma vez e escolho um ou dois para ler.

A última rodada me trouxe quatro livros do balacobaco.

Impossible Data Warehouse Situations

O mais divertido de todos, de longe, foi este:

Impossible Data Warehouse Situations.
Impossible Data Warehouse Situations.

É um livro antigo, do início dos anos 2000, que aborda um rosário de problemas comuns em implementações de DW. Por exemplo:

  • Quando o protótipo vira produção;
  • TI é o assassino;
  • Clientes não sabem o que querem, clássico dos clássicos!
  • A quem o time de DW deve se reportar? (CIO, gerência de departamento etc.)

Ou seja, problemas comuns. Por que, então, o título de situações impossíveis? Bom, justamente por serem comuns é que são impossíveis: impossíveis de se evitar, quase impossíveis de se resolver.

E nenhum destes problemas faz parte de nenhum curso de DW. Pode olhar, pode procurar. O máximo que você vai conseguir achar é um professor mais experiente que passou ou resolveu algumas destas situações, e vai te contar alguma coisa se você perguntar.

Dessa constatação temos o valor que esse livro possui: inestimável. Até porque não é um autor prescrevendo soluções mágicas, mas sim um painel de profissionais gabaritados que dão sua opinião a cada tópico.

Veja esta situação, como exemplo:

  • Should a line of business build its own DM?

Ou, no meu tradicional e macarrônico estilo de tradução, “um departamento deve construir seu próprio DW?” Ela é descrita, contextualizada e daí vários dos colaboradores do livro dão sua opinião. Alguns são bem rasantes, outros são mais acadêmicos, uns são pé-no-chão enquanto que outros, viajantes. Assim você acaba sempre com várias visões e idéias e propostas para o problema – uma riqueza enorme!

A resposta desse exemplo, para mim, vale ouro. Vários foram quadradinhos, “sim, porque o DW é a coleção dos Data Marts” ou “não, porque o DW é uma coisa centralizada”. Bah, isso eu já sei. Mas aí vem a Jill Diché, minha favorita: go togheter with IT. Ou seja, aproxime-se da TI e ofereça para dividir a carga: você colabora com profissionais e ganha, em troca, priorização. Como é você quem vai fazer a sua parte, você recebe antes. Isso deixa o departamento feliz, a TI feliz (porque tem mais mãos para trabalhar) e não aborrece os consumidores que competem com recursos! Gênio!

E o livro está cheio dessas!

Claro que, com essa idade, alguma coisa acaba datada, como essas duas “situações impossíveis” por exemplo:

  • O sistema de origem muda continuamente; ou uma variação
  • O sistema de origem está passando por uma mudança.

As soluções propostas são de gerenciamento, mitigação de riscos e fortalecimento dos padrões e do modelo dimensional. Hoje em dia temos outra opção (já sabe, né? Data Vaul!), mas mesmo assim não é uma mudança tão grande.

O livro fala sobre negócio (mal-entendidos, desinteres, motivação), times (disfuncional, prima-donas, encrenqueiros), clientes (chatos, ruins), chefes (burros, preguiçosos ou bagunçados), técnicas (metodologia, falta de conhecimento, de experiência), padrões (usados errados, sem padrões), ferramentas e qualidade dados, entre outros.

Como eu disse, adorei esse livro. Não consigo deixar de mencionar outros dois favoritos meus, dos padrões:

  • Os empregados usam a terminologia de maneira errada;
  • Tudo é Data Mining.

:-D

Clinical Intelligence

O nome inteiro do livro é enorme:

Clinical Intelligence: The Big Data Analytics Revolution in Healthcare: A Framework for Clinical and Business Intelligence

E ele fala exatamente isso: como usar os conceitos e idéias de BI aplicado ao campo da Saúde. Há algum exagero e um pouco de mal-entendidos, mas nada que prejudique a idéia central.

Por exemplo, ele separa BI e Analytics (item 1.2, paǵina 26), e classifica machine learning, pattern recognition e predictive modeling como motores (engines) e – não bastasse – ainda por cima diferentes. Como se um padrão não fosse um modelo preditivo, e coisas nessa linha. Dá para suspeitar um pouco se ele realmente chegou a entender tudo do que fala, mas – torno a insistir – não compromete o resultado final. Apenas leia com algum resguardo, pois ele não é da área de BI.

Já na parte que realmente interessa, meus caros, ele arrebenta.

E o que realmente interessa é o índice do capítulo 2:

Sumário do capítulo 2.
Sumário do capítulo 2.

(Peço perdão pela baixa qualidade da imagem. Puxei-a do site da Amazon, e ele não estava colaborando muito…)

Vêem? Ele mostra um tipo de análise para cada um dos vários assuntos médicos! Tem desde aspectos administrativos, como casos de uso, scorecards e indicadores diversos, a complexos modelos de atendimento clínico e previsões de custos, passando por modelos de predição de osteopatia e acompanhamento de antibióticos.

Na boa, esse é o livro de cabeceira de QUALQUER gestor de saúde. Quanto mais abrangente a responsabilidade desse gestor, mais importante se torna esse livro. Em outras palavras: leitura obrigatória para secretários e ministros da Saúde, ponto.

É uma leitura que eu passei meio por alto, afinal eu sou um alien para esse campo. Eu me detive apenas nas partes de BI (onde ele faz uma zona com alguns conceitos, acerta outros e se embanana todo com ainda outros) e matemática (em que ele, aparentemente, coleta trabalhos feitos por diversos outros times, uma coisa absolutamente normal, aceitável, afinal, só um ser sobrenatural poderia saber tanto sobre tanta coisa diversa.)

Agile Data Warehouse Design

Este livro tem uma proposta muito bacana: estabelecer uma metodologia para captura de requisitos para DW adequada a projetos ágeis, e ágil em si mesma.

Cara, ficou ruim. Deixe-me tentar de novo:


Este livro tem uma proposta muito bacana: explicar um método ágil de capturar requisitos para DW, requisitos estes adequados a projetos de gestão ágil.


Bem melhor!

Ágil como em ninja, não como em rápido.
Ágil como em ninja, não como em rápido.

E seria um livro excelente não fosse tão… poluído? Pesado? Foi difícil lê-lo do início ao fim, e eu falhei nisso – depois de um tanto saí pulando até onde aguentei. O método é interessante, parece que funciona e não é difícil. Acho que o maior galho dele é justamente ser uma receita de bolo. Ele tenta passar um conhecimento “situacional”, ou seja, de como agir em cada situação, e fica tão cheio de exemplos e detalhes e senões que a coisa toda fica pesada, trabalhosa.

A sensação é que, uma vez assimilado esse conhecimento, a coisa flui. Assimilá-lo é que parece mesmo um trabalho duro. E, já que estou no assunto, ele não resolve os problemas típicos de projetos, nem de projetos de DW, justamente como aqueles colocados no Impossible Situations – esse mesmo, sobre o qual escrevi acima.

Vale a pena ler? É, pode ser que sim. Se tiver tempo, com certeza. Mas não me parece uma daquelas técnicas que abalam o mundo, como – adivinhe? – Data Vault ou Análise Bayesiana. Mesmo assim, ele agrega.

Até porque eu cheguei numa técnica semelhante, muito mais modesta e de alcance muito menor, mas na mesma linha. ;-)

Variados

E esses eram livros que eu havia lido, mas sobre os quais ainda não falara nada. Além deles, em 2016 eu li alguns outros. Dessa leva de coisas da Amazon falei um pouco no post Férias = Livros!. Não custa relembrar (não custa mesmo, é só um copy-paste aqui, hehe):

Cada um deles é um primor de conteúdo e forma. O de expressões regulares eu deixei até separado, de tanto que eu uso. O de análise bayesiana eu leio e leio e leio e uma hora eu vou dominar!

Já o Building A Scalable DW, bom, pelamordedeus, leia! Ele e o DW Toolkit são a base para um DW Corporativo feliz e saudável! ;-)

Alguma Dica?

E isso fecha o meu ano de leitura. Agora estou procurando as coisas para 2017.

Alguma sugestão? ;-)

Uma Ferramenta Para Cada Caso

Há algum tempo eu recebi, na rua, este folheto:

WD-40: muito mais que só um aerosol bonitinho.
WD-40: muito mais que só um aerosol bonitinho.

Quem diria, não? Eu cresci usando WD-40 para quase tudo – de matar formigas a efeito sonoro, passando por desengripante e, claro, anti-ferrugem (o nome é uma referência a deslocamento de água, versão 40.) Mas jamais imaginei que o fabricante do WD-40 oferecia uma linha de vários outros produtos. O folheto que mostra a famosa lata aerosol, mostra também latas de diferentes quantidades do mesmo produto e frascos de coisas como “lixa líquida” e
“graxa branca” (o fim das manchas, com o mesmo poder de lubrificação? Ui! :-D )

Mas, é só lubrificação! Como pode uma única empresa, detentora de um único produto famoso, ter uma quantidade de opções??

Respondo-vos eu: e daí? O que é que tem uma coisa a ver com outra? O que é que proibe a empresa que fabrica um produto multi-uso de ter outros produtos?

Existe uma certa tendência, em TI, a pensar nos nossos produtos como coisas abrangentes, que encompassam tudo. O inglês oferece uma expressão precisa para esse sentimento: one size fits all, ou seja, um tamanho serve para todos.


Será que os softwares e hardwares são desenvolvidos nas fornalhas amaldiçoadas de Mordor?

   Three Rings for the Elven-kings under the sky,
   Seven for the Dwarf-lords in their halls of stone,
   Nine for Mortal Men doomed to die,
   One for the Dark Lord on his dark throne.
   One Ring to rule them all. One Ring to find them,
   One Ring to bring them all and in the darkness bind them.


Mas estou digredindo.

Quem acompanha meu blog sabe que eu tenho uma fixação por propagandas de produtos que prometem fazer tudo com uma só ferramenta. Não tenho problemas com empresas que se prestam a servir tudo, ou one stop shops, mas com empresas que oferecem um único produto e afirmam que ele pode fazer tudo, que ele dispensa qualquer outro complemento.

Esse tipo de mensagem prejudica o cliente, o consumidor, por um motivo muito simples: todo mundo quer ouvir que seu problema tem uma solução fácil.

Mas em TI, e principalmente em BI, não existem soluções fáceis ou óbvias ou tão simples que um mané qualquer pode construir. Se fosse verdade, não teríamos tanta evidência anedótica de projetos que deram errado, de times que ouviram o canto da sereia “one-size” e depois precisaram recolher os cacos e recomeçar.

Pensem em lubrificação: uma coisa simples, só fazer escorregar mais facilmente. Agora pensem em quantas opções de lubrificantes existem. O que gera essa variedade? O uso, os materiais envolvidos e até a dinâmica dos corpos em atrito! Ou você nunca escorregou em um piso molhado que, pisado da forma certa, oferece firmeza?

E essa variedades de opções se estende por uma infinidade de assuntos – basta pensar em alguma coisa e você vai ver que não existe essa coisa de “one ring”, para nada.

E porque continuamos buscando isso em BI? Porque ainda queremos que isso seja verdade?

Não sei, mas o fato é que não é.

Conclusão

Como dito, eu já comentei e dei aqui vários exemplos de como forçar uma ferramenta em todas as funções pode ser um grande erro. Bom, eu tive oportunidade de conhecer melhor dois produtos semana passada, [Alteryx][_bitly] e [Tableau][_bitly]. Adivinhem a mensagem central?


Você só precisa desses dois produtos, mais nada.


Ai, ai, esse ramo não tem jeito, mesmo. Pelo visto, sempre que um fornecedor de BI puder, ele vai tentar reduzir tudo ao mínimo. Mas o cenário talvez esteja melhorando, afinal ouvi dizer pela primeira vez (fora o SAS, que sempre ofereceu um carrilhão de opções) que precisamos de dois produtos! Um para ETL/Analytics, outro para Visual Analytics.

Bom, de qualquer maneira, o fato é que eu ainda preciso estudar mais esses produtos para poder negar a afirmação do fornecedor. Por enquanto, pelo que eu vi, de fato cobrem muita coisa e não é impossível que sejam mesmo o único produto necessário…

… se você ignorar sistema operacional, bancos de dados, diagramação, modelagem matemática etc. etc. etc.

Ai, ai. ;-)


O ano está chegando ao fim. Os próximos posts falarão sobre alguns livros interessantes que li este ano e fecharão a série de soluções clássicas, apresentando o Cálculo Atuarial. Até lá!

Base de Dados para Treinamento

Para escrever o Pentaho na Prática eu construí, do zero, uma base de dados – a Beltrano S/A. Ela está disponível na forma de um backup Postgres, com licença que permite até mesmo o uso comercial. Ou seja, se você quiser montar um curso, ou um produto, embutindo a Beltrano S/A, pode.


A única coisa que eu peço em troca é ser informado no que ela está sendo usada. Só. E mesmo assim, se não quiser não precisa me falar nada. Liberdade total. ;-)


A julgar pelo feedback de quem pediu para usar, eu diria que, como material de ensino, a base é interessante. Por outro lado, como tecnologia ela é bem pouco prática, na minha opinião.

Começa que, para usar, é preciso instalar o Postgres. Depois, precisa criar um banco, baixar o backup, restaurá-lo etc. Daí, se você alterar o conteúdo e quiser resetar o banco para o estado inicial, é preciso dropar a base e recriá-la. E se quiser customizar, precisa extrair umbackup no final e repetir o passo-a-passo de configuração em todas as máquinas de alunos.

É um trabalho chato mesmo para quem sabe mexer no Postgres. Para quem tem pouca familiaridade, é um porre.

Nem todo mundo é fluente em Postgres, e nem sempre dá para instalá-lo nas máquinas. Ou até dá, mas pode rolar conflito de porta, restrições de administração, blá blá blá… Eu ministrei umas vinte turmas de [BI com Pentaho][bicp4lin_bitly], e em todas elas sempre houve ao menos uma pessoa/máquina com problema sério na preparação do banco.

Bom, Bonito e Barato

Existe um servidor de banco de dados chamado HSQLDB que é 100% Java e que não precisa ser instalado. Basta baixar o arquivo do programa, rodá-lo com Java e voilà, tudo em riba!

Como se não bastasse ser Software Livre e 100% Java (ou seja, 100% portável – roda em qualquer plataforma, mesmo!), ainda tem uma interface gráfica a lá pgAdmin III, que pode ser usada para explorar os bancos e executar comandos SQL.

Mas tem uma coisa mais legal ainda: os bancos são construídos, por default, em memória. Quando o servidor é baixado, ele grava tudo que estava em memória em arquivos texto planos, no diretório que especificarmos. Isso, mais o fato de tomar muitas de suas configurações de servidor da linha de comando, nos dá muitas vantagens:

  • Qualquer modificação que é feita nos dados pode ser mantida e transferida para outras máquinas, simplificando o processo de customização para cada uso;
  • Se quiser voltar ao estado original, basta apagar o banco atual e descompactar o banco inicial mais uma vez. Estou falando do Beltrano S/A, mas pode ser feito para qualquer outro banco que você criar: basta guardar uma cópia à parte do seu banco;
  • Ele não mantém arquivos escondidos. Apagou, desinstalou;
  • A porta é configurada na chamada que sobe o servidor. Deu conflito? Baixe o banco, mude a porta e suba novamente;
  • Como podemos rodar um programa Java quantas vezes quisermos, podemos montar um conjunto de vários servidores, cada qual com sua porta e seu banco;
  • Um mesmo servidor, aliás, pode manter vários bancos;
  • É um programa pequeno: o pacote inteiro não chega a 5MB;
  • Mesmo tendo uma “pegada” muito pequena, ele não deixa nada a dever a bancos maiores, em termos de funcionalidades, e aguenta um bom volume de dados (basicamente limitado pela RAM da máquina;)
  • Você pode embuti-lo em outros programas, afinal é um projeto livre, em Java;
  • Você pode carregar data marts nele, e dar a capacidade de processamento de dados in memory a qualquer ferramentas de análises de dados que se conecte a bancos de dados via JDBC, como o Pentaho. Evidentemente não é a mesma coisa que um engine otimizado, como o que acompanha o QlikView, mas é mais rápido que disco.

E o HSQLDB ainda oferece uma boa gama de comandos e recursos, como índices, integridade relacional, muitos tipos de dados, várias funções nativas etc. etc. etc. Não fica a dever para outros bancos, mesmo.

Quem me conhece deve estar esperando a pegadinha, que sempre vem depois que eu desenho uma cena linda, toda rósea e luminosa. ;-) Bom, desta vez não tem: é tudo róseo e lindo, mesmo! No restante do post você verá um pouco sobre o HSQLDB (como baixar e subir um banco) e como instalar o mesmo conteúdo do banco Beltrano S/A oferecido em PostgreSQL.

Introdução ao HSQLDB

Como a promessa deste post é oferecer uma base de treinamento pronta e fácil de usar, eu vou cortar direto para a perseguição1 e ensinar o bê-a-bá do agá-esse-kê-ele-debê: de onde fazer o download, como subir o servidor, criar novos bancos, acessá-lo e depois baixá-lo.

O site do HSQLDB é o http://hsqldb.org, onde você pode estudar toda documentação e ler os guias de uso. Como é um projeto voltado principalmente para programadores (é um banco embutível, afinal de contas), ele abusa da linguagem técnica, tanto SQL quanto Java, e pode ser um pouco árido para o usuário menos proficiente nesses assuntos.

O pacote do servidor HSQLDB pode ser baixado diretamente do SourceForge, neste link, e o pacote do Beltrano S/A pré-configurado pode ser baixado daqui. O restante desta seção usa o conteúdo desse pacote, não do servidor original – muito técnico, lembram-se?

O zip do Beltrano OLTP/HSQLDB traz os arquivos do servidor e mais dois scripts, cada um dos quais em duas versões: Linux (.sh) e Windows (.bat.) Um dos scripts sobe o servidor e outro baixa-o. Os diretórios são ./data, onde fica o conteúdo do banco propriamente dito, e ./lib, onde está o servidor.

Subindo e Baixando o HSQLDB

Basta rodar o script start-hsqldb.sh/bat que o HSQLDB subirá com o banco desejado – Beltrano S/A neste caso. Para rodar esse script, abra um terminal (Windows: prompt do DOS) e mude para o diretório recém-criado. Daí comande ./start-hsqldb.sh (Linux) ou start-hsqldb.bat (Windows.) Em poucos segundos o banco estará no ar.

Eis as mensagens do HSQLDB subindo em um Ubuntu:

ubuntu:beltrano_oltp_hsqldb$ ./beltrano_oltp_hsqldb
classpath is :./lib/hsqldb.jar
[Server@5cd73256]: [Thread[main,5,main]]: checkRunning(false) entered
[Server@5cd73256]: [Thread[main,5,main]]: checkRunning(false) exited
[Server@5cd73256]: Startup sequence initiated from main() method
[Server@5cd73256]: Could not load properties from file
[Server@5cd73256]: Using cli/default properties only
[Server@5cd73256]: Initiating startup sequence...
[Server@5cd73256]: Server socket opened successfully in 4 ms.
[Server@5cd73256]: Database [index=0, id=0, db=file:./data/beltrano10k, alias=beltrano_oltp] opened successfully in 1430 ms.
[Server@5cd73256]: Startup sequence completed in 1435 ms.
[Server@5cd73256]: 2016-11-24 10:37:47.379 HSQLDB server 2.3.4 is online on port 9001
[Server@5cd73256]: To close normally, connect and execute SHUTDOWN SQL
[Server@5cd73256]: From command line, use [Ctrl]+[C] to abort abruptly

Eis o conteúdo da versão Bash do script:

#!/bin/sh
### =================== ###
##  HSQLDB Start Script  ##
### =================== ###

DIR_REL=`dirname $0`
cd $DIR_REL
DIR=`pwd`
cd -

#---------------------------------#
# dynamically build the classpath #
#---------------------------------#
THE_CLASSPATH=
for i in `ls $DIR_REL/lib/hsqldb*.jar`
do
THE_CLASSPATH=${THE_CLASSPATH}:${i}
done
echo "classpath is $THE_CLASSPATH"

java -cp $THE_CLASSPATH org.hsqldb.Server
-database.0 $DIR_REL/data/beltrano
-dbname.0 beltrano_oltp -port 9001

O último comando do script acima deve estar em uma única linha.

Uma vez no ar, você não pode simplesmente apertar CTRL+C para interrompê-lo. Isso pode corromper os arquivos, sem contar que não vai salvar o que estiver em memória. Para encerrar um banco é preciso rodar o script stop-hsqldb.sh/.bat. Note que talvez seja preciso abrir outro terminal. O script de encerramento é o seguinte:

#!/bin/sh
### =================== ###
##  HSQLDB Stop Script  ##
### =================== ###

DIR_REL=`dirname $0`
cd $DIR_REL

java -jar $DIR_REL/lib/sqltool.jar
--inlineRc=url=jdbc:hsqldb:hsql://localhost:9001/nome_do_banco,user=SA,password=""
--sql="SHUTDOWN;"

De novo: linhas maiores foram separadas em várias para facilitar a leitura, mas sempre devem formar uma única linha, sem quebras.

A diferença deste script para o de inicialização é que você não precisa informar o(s) nome(s) do(s) banco(s): ao receber o comando para se desligar, o HSQLDB encerra todos que estiverem abertos. Apenas não se esqueça de conferir as portas: o comando de shutdown precisa ser enviado para a porta certa, caso contrário, óbvio, nada acontecerá.

Acessando o Servidor

O HSQLDB é um servidor de banco de dados como outro qualquer. Ele pode ser acessado por qualquer aplicação que use o padrão JDBC. O driver JDBC dele, aliás, é o próprio servidor. No pacote do Beltrano S/A o servidor/driver é o arquivo hsqldb.jar, que fica dentro da pasta ./lib. Basta passar esse arquivo para o programa que vai se conectar ao servidor HSQLDB e usar a string de conexão abaixo:

jdbc:hsqldb:hsql://:/; ~~~

`<PARAMETROS>` é qualquer configuração que precise ser passada para o servidor. Lembre-se de remover o **;** entre a URL e os parâmetros caso não haja nenhum.

Digamos que você queira usar o PDI (Kettle) para acessar esse servidor. Uma conexão com o HSQLDB é totalmente padrão: basta selecionar Hypersonic (seu antigo nome) na lista e entrar os dados de conexão:

<a href="https://geekbi.files.wordpress.com/2016/11/161123_basededadosparatreinamento_004.png"><img class="size-full wp-image-1550" src="https://geekbi.files.wordpress.com/2016/11/161123_basededadosparatreinamento_004.png" alt="Parâmetros de conexão Pentaho." width="608" height="500" /></a> Parâmetros de conexão Pentaho.

Porém, é importante setar um parâmetro para evitar problemas com &quot;conjuntos vazios&quot; (conexões que se abre e fecham sem gravar nada, acho.) Na janela de conexões do *Spoon*, acesse a seção *Options* e entre o parâmetro `allow_empty_batch = true`:

<a href="https://geekbi.files.wordpress.com/2016/11/161123_basededadosparatreinamento_003.png"><img class="size-large wp-image-1551" src="https://geekbi.files.wordpress.com/2016/11/161123_basededadosparatreinamento_003.png?w=720" alt="Onde adicionar o parâmetro para evitar problemas com INSERTs vazios." width="720" height="278" /></a> Onde adicionar o parâmetro para evitar problemas com INSERTs vazios.

A string de conexão ficaria:

jdbc:hsqldb:hsql://localhost:9001/beltrano_oltp;allow_empty_batch=true

<br />Aproveitando, se você precisa construir uma conexão [JNDI][JNDI_bitly], o formato é esse:

BELTRANO_OLTP/type=javax.sql.DataSource
BELTRANO_OLTP/driver=org.hsqldb.jdbcDriver
BELTRANO_OLTP/url=jdbc:hsqldb:hsql://localhost:9001/beltrano_oltp
BELTRANO_OLTP/user=sa
BELTRANO_OLTP/password=

<br />Lembre-se de ajustar os parâmetros para o seu caso!

### Criar Novos Bancos ###

Pronto, agora você possui um servidor de banco de dados portátil, versátil, apto a um monte de usos educacionais e profissionais. Por exemplo, você pode criar um Data Mart para servir relatórios.

> ---
>
> Francamente, eu não consegui entender a documentação. Não sei dizer se dá para criar um banco subindo um servidor "vazio" e fazendo um `CREATE DB` ou coisa do gênero. Logo, eu vou contar aqui o que eu sei que funciona, mas não é necessariamente a única forma de fazê-lo - eu só não sei de outras. ;-)
>
> ---

Observe a linha de comando Java do script de inicialização:

java -cp $THE_CLASSPATH org.hsqldb.Server
-database.0 $DIR_REL/data/beltrano
-dbname.0 beltrano_oltp -port 9001

<br />É ali que definimos que bancos o servidor vai oferecer, a partir de que diretório, em que porta etc. Logo, para criar um novo banco basta adicionar, a essa linha, um par de parâmetros:

* Diretório do banco e nome dos arquivos: `$DIR_REL/data/NOME`
* Número e nome do banco de dados: `-dbname.X NOME`

Você pode adicionar um novo banco ou remover o antigo antes de criar o novo, apagando os arquivos `$DIR_REL/data/NOME`.

Para subir mais de um banco no mesmo servidor, inclua um novo conjunto de parâmetros. Por exemplo, para termos dois bancos, chamados *nome_do_banco* e *banco_de_dados*, a linha de comando deve ser:

java -cp $THE_CLASSPATH org.hsqldb.Server
-database.0 $DIR_REL/data/nomequalquer1 -dbname.0 nome_do_banco
-database.1 $DIR_REL/data/nomequalquer2 -dbname.1 banco_de_dados
-port 9001

<br />> *Atenção*: o comando acima deve compor uma única linha.

E, claro que você já deve ter sacado, para alterar a porta na qual o banco vai responder simplesmente mude o número que vem depois do parâmetro `-port`.

### Interface Gráfica ###

Em 17/1/2013 eu postei um artigo mostrando como abrir uma interface gráfica ("mais ou menos") para um servidor HSQLDB: [Interface para o HSQLDB][inthsqldb_bitly]. Vamos relembrar os pontos importantes:

* Abra um terminal (DOS prompt no Windows)
* Mude para o diretório do *HSQLDB*;
* Comande:
java -cp hsqldb.jar org.hsqldb.util.DatabaseManagerSwing --noexit

* Preencha os campos da janela Connect com os seguintes dados:

Setting name: Beltrano OLTP
URL: jdbc:hsqldb:hsql://localhost:9001/beltrano_oltp
User: sa
Senha:
~~~

A figura abaixo mostra um exemplo. Note que ela se conecta a outro banco, e por isso os parâmetros são diferentes – ela foi puxada do outro post.

Exemplo de como criar uma nova conexão.
Exemplo de como criar uma nova conexão.

Quando você conseguir se conectar, poderá explorar o banco à vontade:

Conectado ao servidor.
Conectado ao servidor.

HSQLDB & Pentaho

Se você costuma usar o Pentaho, especialmente o servidor, vale a pena notar que esse é o banco que o Pentaho BA Server usa em sua instalação pré-configurada. Se você tiver curiosidade, tudo que foi descrito aqui pode ser verificado no diretório ./biserver-ce/data, se você souber a quê estou me referindo.

Conclusão

Eu já havia visto MySQL portátil, que é uma boa solução também. O único inconveniente era o fato de precisar de binários diferentes para cada arquitetura (Linux, Windows, Intel, ARM etc.) O HSQLDB supera essa limitação e é, de fato, um servidor de bancos de dados relacionais de arquitetura “universal”. Claro que não possui a mesma robustez de um servidor como Oracle ou PostgreSQL, mas resolve muito bem uma série de necessidades.

Não sei porque eu demorei tanto a perceber isso… ;-)

Não deixe de entrar em contato por meios dos comentários se tiver alguma dúvida, ou encontrar algum bug.

Até a próxima! :-)


  1. Cut to the chase é uma coisa que dizem em Inglês quando não estão a fim de ouvir a história inteira. Aqui usamos mais “vá direto ao assunto”. E porque eu usei a expressão estrangeira? Oras, para poder dizer que GeekBI é cultura, claro! Kkkk…. 

Exame & BigData

A revista exame publicou, em 5 de março deste ano (2016), um artigo comentando sobre o mercado de trabalho para “Cientistas de Dados”.

Eu sempre implico com nomes “da moda” porque, na minha opinião, eles desvalorizam o profissional sedimentado, experiente, abandonando expressões que funcionam por um palavreado mais colorido. Ocasionalmente a coisa muda, claro, e esses nomes precisam mudar junto, mas em TI há uma competição disfarçada para ver quem vem com a próxima buzzword. No final essa disputa acaba por atrapalhar a vida da TI porque tanta mudança forçada impede a construção de senso comum e de uma cultura particular.

Pergunte a um engenheiro mecânico o que é um carburador, ou se eles usam “camâras adiabáticas para oxiredução explosiva”. Ou para um financista se ele fala juros compostos, ou “taxa de interesse recursiva”.

Entendeu a idéia? Para quê mudar uma expressão se ela adequa-se perfeitamente?

Pior: uma pessoa errada, mas com muita certeza, vai levar outros a errar também. É preciso estar de posse de um conhecimento sólido para poder resistir à pressão do hype corrente.

Big Data, Hiper Hype

Nestas últimas semanas eu tenho escrito sobre BigData, mas ontem eu não tinha assunto. Eu não sabia sobre o que postar, e depois de um dia cheio e tela em branco, eu simplesmente desisti.

Sem inspiração? Que tal tocado como gado?
Sem inspiração? Que tal tocado como gado?

Hoje eu acordei e olhei de novo para minhas anotações e achei este rascunho aqui, sobre a Revista Exame, e vi um bom fechamento para a série. Junte-se a isso que eu repeti minha palestra sobre BigData para a Fatec Zona Sul, cujo foco era desfazer confusões antes de começarem.

Leia a reportagem, é interessante. Entretanto, lá no meio, quando tudo estava indo bem, algo dá errado:


“O big data não se resume a um processo de automação. Seu objetivo é entender melhor o que acontece numa empresa, o que os clientes querem e, assim, modificar o negócio”, diz Jorge Sanz, diretor do Centro de Business Analytics da Universidade Nacional de Singapura, um dos grandes centros de big data da Ásia. Esse processo requer softwares capazes de captar os dados relevantes — e, acima de tudo, pessoas treinadas para interpretá-los.


Eu copiei o parágrafo inteiro como está. Releia. Releu? Entendeu? De novo, devagar:

“O big data não se resume a um processo de automação.”

“O” big data? Agora é uma coisa só, um objeto que anda por aí, e não mais uma tecnologia, mas um objeto. Ok, vamos dar uma colher de chá, já que muitos profissionais ainda chamam BI de “O” BI.

“Não se resume a um processo”: então “big data” é um processo? Se ele diz “não se resume”, então ele já classificou o assunto como um processo; apenas vai adiante e diz que não é apenas um processo – mas implica que é um de qualquer forma. Ou seja, passou de tecnologia-objeto (que demanda o tal do artigo definido masculino singular, “O”) para uma coisa que também é um processo. Mais uma confusão, mas vamos relevá-la de novo, em favor da prosa da reportagem.

“De automação”: e de onde veio isso? Do parágrafo anterior no artigo, onde ele começa associando computadores a automação. Até são coisas relacionadas, mas chamar Hadoop de automação é um pouco demais. Mas mesmo assim, vamos em frente.

E aqui o assunto descarrilha de vez:

“Seu objetivo é entender melhor o que acontece numa empresa”

É um repórter competetente, entrevistando um executivo relevante de uma enorme instituição financeira nacional. Quer dizer, não é um par de manés, não! São profissionais experientes, gabaritados e entendidos no assunto…

… que meteram os pés pelas mãos. Há décadas existe um termo que usa como definição justamente essa frase – Seu objetivo é entender melhor o que acontece numa empresa: Inteligência de Negócios, vulgo BI.

O que ele fez foi chamar uma coisa de outra. Foi vender banana anunciando carambola, já ambas são compridas, amarelas, tem casca, são frutas… Só que não são a mesma coisa! É um esforço feito para dar ribalta a uma expressão da moda, dando um gancho (sigam este link, é hilário!) em outra!

Fora, Inteligência de Negócios! Agora queremos "o big data"!
Fora, Inteligência de Negócios! Agora queremos “o big data”!

Existe uma outra explicação, que é dizer que ele não sabia mesmo do que estava falando, mas isso é um pouco demais para aceitarmos. Afinal, é a maior revista de negócios do Brasil, não um panfleto de bairro. Não atribuiriam a um repórter uma tarefa que ele não conseguisse desempenhar adequadamente. Isso feriria a reputação de ambos – revista e repórter. A menos, claro, que seu público não fosse capaz de perceber a confusão, mas aí é demais para aceitarmos porque estamos falando de um público qualificado, líderes, executivos e profissionais de todos os ramos, conhecedores de assuntos mil…

Entenderam como funciona? Ninguém tem bem certeza do que é algo. Aí a moda vem, avassaladoramente, e sacode tudo junto. No final fica parecendo aquela piada:


O bêbado entra no ônibus, passa a roleta e vai para trás. De lá, grita:

  • Do lado direito todo mundo é palmeirense! Do lado esquerdo todo mundo é corintiano!

Ao ouvir isto, levanta um do lado direito e fala:

  • Eu não sou palmeirense!!!

E todo os passageiros começaram a xingar o bêbado e ameaçando cobri-lo de bolacha. O motorista, para evitar confusão, freia bruscamente e todos caem. Um dos passageiros se levanta, pega o bêbado pelo colarinho e pergunta:

  • Fala de novo, safado! Quem é palmeirense e quem é corintiano?!

  • Agora eu não sei mais. Misturou tudo…


Não dá mais para saber quem é quem, porque o jornalismo especializado misturou tudo.

Conclusão

A reportagem segue nesse mesmo ritmo, dando novos nomes a coisas já estabelecidas. Por exemplo, em certo momento ele diz que os cientistas de dados têm remuneração superior à dos técnicos, que até o surgimento do big data eram os responsáveis por cuidar da manutenção dos bancos de dados. Ele misturou DBAs com analistas de DW/ETL, com Analistas de Data Mining, com Hadoop, com Bancos Relacionais… Em metade de um parágrafo, em menos de 30 palavras, causou-se estrago para pelo menos três áreas:

  • DBAs fazem a mesma coisa que cientistas de dados se você não usar “big data”;
  • Cientistas de Dados são DBAs para “big data”;
  • A manutenção de um Hadoop, uma plataforma de clusterização escrita em Java, é feita por um cientista de dados, enquanto que a de um Oracle, um banco de dados relacional, é feita por um técnico, e são a mesma coisa do ponto de vista funcional;
  • E Data Mining?

Esse tipo de artigo confunde um número de conceitos complexos para uma audiência em geral leiga nestes mesmos tópicos. Por ser um veículo de projeção nacional e respeitado, bem-conceituado, muitos tomam o que sai ali por fato, por verdade canônica. Aos poucos essas confusões tomam o lugar das verdades nas empresas, impactando planejamento, contratações, e até debates. Como é que um cara qualquer, um joão-ninguém como eu pode argumentar com o “repórter da Exame”? A quem acreditam vocês que o público atribui maior conhecimento? :-)

E pior ainda: como é que um profissional recém-formado pode querer colaborar com a empresa, se tudo que ele fala é contestado pelo chefe que viu tudo diferente na revista de negócios mais famosa do Brasil?

Tem mais razão e está mais certo que fala com mais convicção? Não, né? Repasso aqui o conselho que dei àqueles alunos das FATECs:

Use sua inteligência para filtrar. Critique e questione tudo. ;-)
Use sua inteligência para filtrar. Critique e questione tudo. ;-)

É isso. ;-)

Todo Dado É Estruturado

Trabalho na indústria de BI há 16 anos. Hoje em dia dá-se muito destaque a um tipo de dados considerados especiais, até meio místicos, como se guardassem a chave para as respostas de todas as perguntas não-formuladas. São os tais dos chamados dados não-estruturados.

Não vou debater semântica, ou nomenclatura, mas o fato é que esse tipo de dado existe desde sempre. Tanto é assim que há um campo inteiro dedicado a produzir conhecimento a partir de fontes hoje ditas “não-estruturadas”. Esse campo chama-se Text Mining, uma extensão do conceito de Data Mining. São as técnicas aplicadas em, por exemplo, soluções de análise de sentimento.

Assim como eu tenho algumas ressalvas com todo o hype em volta de BigData, também tenho minhas reservas quanto ao endeusamento desse tipo de dado. A minha bronca é que essa atitude não raro decorre de modismos, em geral carentes de significado mais concreto, cunhados a fim de encher a cabeça do cliente e ocasionalmente levá-lo a comprar alguma coisa.


Compra quem quer, deixa-se levar por modismos quem quer. Longe de mim atrapalhar a liberdade que cada um tem de se deixar convencer! Entretanto, eu não posso deixar de tocar no assunto. Encare este post como mais um argumento em um longo debate em busca da verdade. ;-)


A maior parte dos dados úteis para análises são justamente os que refletem algum processo, e por isso são capturados em sistemas transacionais ordinários. São dados que vivem em tabelas ou, no máximo, arquivos com algum layout padronizado. Já os tais dos dados não-estruturados não possuem “nenhuma” regularidade. Então tá, se sairmos desse domínio – se deixarmos os sistemas transacionais e suas tabelas padronizadas para trás – o que temos?

Vou ver um exemplo para ficar mais claro.

O Governo Federal tem a missão de gastar o dinheiro da melhor forma possível. Suponha que decidiu-se estabelecer a relação entre o atendimento do Bolsa-Família (BF) e a melhoria da educação. Isso é importante para permitir que a geração seguinte à suportada pelo BF possa almejar empregos de qualidade e melhorar de vida.

Como correlacionar esses dados? Uma opção é avaliar a relação entre demografia e os índices de escolaridade e frequência, e a cobertura geográfica do BF.

De onde virão esses dados? Dos sistemas de gestão escolar, por certo. Logo, esses dados são 100% estruturados. Estamos falando de capturar as listas de chamada, as notas, o resultado do ENEM, da Provinha Brasil, da concessão de BFs, de mapas… São todos dados estruturados. Mesmo que não venham de um único sistema, quiçá de uma única entidade, todos esses dados “vivem” em estruturas regulares. Com esses dados obtemos o conhecimento mais valioso que existe nos processos de gestão escolar.


Permitam-me colocar de outra forma: obtemos uma informação valiosa sem precisarmos de nenhum dado não-estruturado. E isso vale para a maioria do que está por aí, aguardando ser descoberto.


O dado não-estruturado serve para situações muito específicas, em condições muito particulares. É um nicho naturalmente pequeno – basta pensar quantas empresas/organizações grandes o bastante existem para puxar alguma inteligência dessas fontes, e o tamanho que essas fontes precisam ter para atribuir alguma confiança, estatisticamente falando, aos resultados.

Analiso Ergo Estruturo

Por outro lado, quais fontes de dados não-estruturadas existem por aí?

  • Textos (web e e-mail;)
  • Textos (posts em mídias sociais;)
  • Textos (documentos;)
  • Vértices de grafos (URLs – textos.)
Um punhado de dados não-estruturados.
Um punhado de dados não-estruturados.

Eu com certeza ignoro algumas outras categorias de dados não-estruturados, mas quais? Repassei a lista mas tudo que eu pensava tinha alguma estrutura mais ou menos óbvia, fixa:

  • Objetos XML: têm estrutura;
  • Transações entre empresas, como SWIFT: além de privados, têm estrutura;
  • Mapas: têm estrutura;
  • Etc…

Ora, o que é uma análise? Pode ser desde uma contagem ou uma média (quantas palavras o post possui, quantas palavras existe, em média, nos posts de cada autor?) a uma coisa mais sofisticada (qual é a chance, para cada assunto, de o autor possuir relação íntima com o dado assunto de seus textos?) Responder a essas perguntas envolve analisar frequências, distribuições, distâncias – números, números, números! Sempre precisamos quantificar em números e qualificar com uma descrição tudo aquilo que desejamos analisar.

Bom, mesmo o exemplo dado na figura 1 (e em geral naqueles elencados no início da sessão) possui alguma estrutura. Por exemplo:

  • Data e hora de publicação;
  • Ocasionalmente data e hora de criação e edição;
  • Versão (1, 2, 3… quando alguém edita o conteúdo e republica o item – doc, post etc.;)
  • Autor, e todos seus dados;
  • Tamanho;
  • Tipo de conteúdos (só texto, só imagem, mistura;)
  • Relacionamentos;
  • E, finalmente, o conteúdo em si.
O mesmo punhado de dados, estruturados.
O mesmo punhado de dados, estruturados.

Veja que, ignorando o conteúdo, podemos puxar muita coisa só olhando o restante! Dá para montar grafos diversos, por exemplo, acompanhando o timestamp e relacionamentos entre publicações em blogs e redes sociais. Dá para analisar o sentimento de um conjunto em relação a um assunto.


Análise impõe estrutura: para conduzir uma análise, os dados precisam ser estruturados de alguma forma. Se os dados não possuem estrutura, então não podem ser organizados e, imperiosamente, não permitem análise.


Logo, se os dados podem ser analisados, então eles possuem alguma estrutura. Isso gera confusão com o jargão de TI, que costuma chamar de “estrutura” um container ou padrão de armazenamento digital (isto é, que guarda os dados de uma forma mais ou menos organizada, como uma tabela, uma planilha ou um arquivo texto, representados por sequências de bytes em alguma mídia.)

Conclusão

O meu ponto é chamar a atenção para o hype em volta de dados não-estruturados. Afinal, para podermos conduzir qualquer análise é preciso poder representá-los matematicamente. Quero dizer, é preciso que eles possuam alguma estrutura, por mais incomum ou exótica que seja essa estrutura, ou por mais “escondida” que ela esteja.

Essa tabela mostra o exemplo da estrutura de dados do post em emu Facebook que aparece nas figuras anteriores:

Campo Conteúdo
Autor Fábio
Data Original 02/11/2016 20:30:00
Flag Editado Sim
Data Editado 02/11/2016 22:43:00
Conteúdo Original Há tanto sobre Big(…)
Conteúdo Editado Há tanto sendo escrito(…)
URLs https://geekbi.word(&#8230;)
Grupo Público
Curtido por Blad, Gisele
Curtido em 03/11/2016 10:15:00

Mesmo dados arquivados sob formatos exóticos (textos, e-mails, páginas web) possuem um mínimo de estrutura matemática apta a análises. Vem daí a afirmação que dá título a este post:


Todo dado (que seja útil para análise) é estruturado, de uma forma ou de outra.


Isso implica em dizer que não existem dados não-estruturados? Pode ser, tanto que esse era o título original deste post. Mas ainda não consigo afirmar isso com certeza.

Quem sabe um dia, não?

Até a próxima! ;-)

 

Alhos, Bugalhos e BigData

Há tanto sendo escrito e falado e mostrado sobre BigData por aí que eu simplesmente não tenho muito o que agregar. Mesmo assim, nestas duas últimas semanas eu acabei fazendo posts sobre BigData:

O primeiro define BigData a partir de sua evolução, seguindo o caminho que a tecnologia percorreu até os dias atuais. Já o segundo é a minha opinião sobre o caminho que o assunto – não a tecnologia – vai tomar.

Eu sinto, porém, que há um último tópico a ser “passado a limpo”: a confusão entre o meio e a meta.

O Meio

A história toda começou com várias empresas e organizações buscando uma forma de aumentar a performance da indexação da World Wide Web, ou simplesmente “A Internet”. Esse esforço culminou no surgimento do Hadoop.

As possibilidades do Hadoop aguçaram os visionários de plantão e logo houve o big-bang do BigData. A coisa atingiu a mídia e o hype foi às alturas – tudo era BigData, BigData pra cá, BigData pra lá, BigData no almoço, café e jantar…


Isso dá samba :-)

BigData pra cá,
BigData pra lá,
BigData no almoço,
    café e jantar.


E essas possiblidades apareceram graças ao surgimento do Hadoop, que em si é uma arquitetura de ingestão e acesso de dados com limites muito superiores às que existiam até então. Cargas de dados, que requeriam caras combinações de hardware e software, puderam ser tratadas com investimentos muito menores, o que permitiu atacar problemas cuja soluções eram exclusividade de grandes empresas.

A Meta

Existem duas categorias de problemas solucionáveis pelo Hadoop:

  • Ingestão de dados;
  • Análises de dados.

Empresas como Facebook, Twitter, Amazon.com etc. são organizações que lidam, naturalmente, com um grande volume de dados, que surge e se modifica muito rapidamente. Capturar esses dados depende de uma infra-estrutura capaz de ler e estocar os dados disponíveis antes de novos dados aparecerem, ou a coisa toda vai por água abaixo.

Por outro lado, não surgiu nada de realmente novo em termos de análises de dados. Tudo que temos hoje foi inventado há décadas. Um ou outro algoritmo sofreu evolução, apareceu uma ou outra técnica mais esotérica, mas o grosso da caixa de ferramentas de análises de dados tem um bom tempo de estrada.

Como exemplo tome uma métrica famosa em Marketing, o Lifetime Value, que estima o valor que um cliente representa para o fornecedor ao longo da sua vida como consumidor. Saber o Customer Lifetime Value (CLV) de cada cliente ajuda, entre outras coisas, a decidir se vale a pena o esforço de mantê-lo, e quanto esse esforço pode ser.

As estimativas mais precisas do CLV são feitas usando-se o conceito de valor atual líquido, ou Net Present Value em inglês. Bom, o uso dessa metodologia remonta ao Século XIX: até mesmo Karl Marx citou esse conceito, cuja popularização aconteceu em 1907 – ou seja, o conceito ficou famoso no início do Século XX!

That Confounded Bridge

Vocês sabem o que acontece quando misturamos gente que fala muito, com coisas que não entendem? Isso mesmo: temos um palavrório que soa como se fizesse muito sentido, mas nem sempre faz. BigData é uma dessas coisas que nem todo mundo entende, mas sobre a qual muitos querem falar. O resultado é que, vira e mexe, alguém solta um “a tecnologia BigData permitirá estimar o valor do cliente para a empresa”.

Pronto: agora você não vai se confundir mais. ;-)
Pronto: agora você não vai se confundir mais. ;-)

Ora bolas, essa estimativa é feita desde o século XIX! Como assim “o BigData permitirá”? Não permitirá porcaria nenhuma – não tem nada a ver! Ele está misturando alhos com bugalhos!

Dando o crédito a uma eventual notícia dessas, pode ser que o uso de Hadoop vá baratear o cálculo do CLV a tal ponto que permita aumentar sua precisão ou incluir dados de outras fontes no algoritmo. Mas, em si, essa medida já existia, já era feita e não é nenhuma novidade, muito menos algo trazido pelo Hadoop e menos ainda coisa de “BigData”!!!

Conclusão

Hadoop é a tecnologia que deu origem ao mercado de BigData, e o centro dele ainda hoje. Hadoop não tem absolutamente nada a ver com Data Mining, que é um processo de extrair modelos matemáticos e outros quejandos dos dados. O casamento do Hadoop com as técnicas de Data Mining rende muito, mas…

Não confunda as coisas. Ou os Coisas. Que coisa confusa...
Não confunda as coisas. Ou os Coisas. Que coisa confusa…

:-)

Até a próxima!

O Fim do BigData

Em 20/10/2016 eu tive a honra e o privilégio de falar como keynote speaker no TechnoTalk de BI, BigData e Data Science da PUC do Rio Grande do Sul. Esse é um evento que ocorre com frequência, organizado pelo insuperável Jorge Audy, Agile Jedi. Já foram mais de 40 eventos, e contando!

TechnoTalk BI, BigData & DataMining.
TechnoTalk BI, BigData & DataMining.

Desta feita o Jorge havia convidado luminares de Data Mining, de BigData e eu, vosso modesto (ha-ha) escriba. Antes de mim falaram Sérgio Blum e João Gutheil, e depois falou o Irio Musskopf. Vou apresentá-los a vocês e contextualizar a discussão que vinha sendo feita e logo depois eu coloco o ponto que eu levantei no debate.

Casa cheia!
Casa cheia!

Sérgio Adriano Blum

Instrutor, gestor de projetos e consultor em Tecnologia da Informação pela White Cube, ele apresentou um painel com opções tecnológicas, ferramentas, cases e cenários do mundo BigData/Data Mining. Sigam este link para o post do Jorge, onde vocês podem baixar o material que ele disponibilizou em PPT. Você também pode entrar em contato com o Sérgio por meio de sua página LinkedIn

Um apanhado geral das tecnologias associadas a BigData.
Um apanhado geral das tecnologias associadas a BigData.

João Gutheil

O João é um conhecido meu de longa data – já batemos papo desde o começo de 2015. A apresentação do Gutheil ligou BigData com Data Mining, detalhando abordagens, valor entregue em diferentes áreas e segmentos de mercado, ferramentas e plataformas, fechando com cenários para futuro próximo.

Vale destacar que ele é um dos vice-coordenadores do Grupo de Usuários de BI (GUBI) da SUCESU-RS. Ou seja, o cara não é fraco, não.

Minha fala foi logo depois da dele, e eu usei o que ele explicou como ponto de partida. Mas segure aí – vamos terminar os convidades e eu já volto.

Irio Musskopf

O Irio é uma daquelas pessoas que tem a rara oportunidade de fazer algo de concreto e impactante para seu país. Ele falou sobre o desafio do uso de Machine Learning na Operação Serenata de Amor, que usa mineração de dados para mapear e destacar anomalias nas prestações de contas de políticos. Para custear esse projeto foi aberto uma conta na Catarse – não deixe de conhecer, é impressionante.

Usando Data Mining e Robôs para pegar malfeitos!
Usando Data Mining e Robôs para pegar malfeitos!

A CodeLand é uma empresa de desenvolvimento web ágil, especializada na liberação de novos negócios digitais.

Explodindo o BigData e Mostrando o Creeper!

Bom, quando eu entrei o Irio seria o próximo, e o João Gutheil tinha acabado de mostrar como BigData e Data Mining poderiam ser usados para resolver problemas reais, concretos, de empresas.

Eu falei sobre minha apresentação do dia anterior, na FATEC, quando eu fiz justamente uma introdução ao assunto. Comentei, então, que na minha opinião BigData é a mesma coisa que Hadoop e que é uma tecnologia útil para resolver problemas com um volume burral de dados – um volume que não cabe dentro de uma só máquina.

Eu coloquei minha primeira pergunta: onde está a maior parte dos dados que giram pelas empresas no Brasil?

Sabemos que a maior parte dos empregos, no Brasil, estão em empresas de médio e pequeno porte, e até menores. Será que o volume de dados tratado por essas empresas também se distribui segundo essa regra? Intuitivamente eu suspeito que não. Eu desconfio que a maior parte das empresas no Brasil recolhem apenas uma pequena parcela dos dados transacionados no país.

Daí eu comecei a levantar outros pontos, que há coisa de um ano começaram a despertar minha curiosidade:

  • Certos usos dos dados não se dão bem com o modelo de operação em lote (batch) do Hadoop. Cubos OLAP são um caso, relatórios são outro. Até porque uma coisa é coletar um volume monstruoso de dados, e outra é usar parte desse volume como fonte para um cubo;
  • Um volume muito grande de dados pode ser tratado usando-se algumas outras tecnologias, como por exemplo clusters de bancos de dados relacionais, e até mesmo clusters de bancos de dados colunares. Esse tipo de tecnologia cabe na descrição de “BigData” mas ainda não é Hadoop, e se presta a coisas como, de novo, cubos OLAP, que são um ponto fraco do Hadoop ainda;
  • Por fim, o volume de dados que justifica a adoção de Hadoop é realmente uma coisa fora-do-comum. Quantas empresas existem que lidam, que captam um volume de dados deste porte?
  • Mais ainda: das empresas que coletam um volume gargantuesco de dados crús, quantas possuem problemas que requerem uma parcela tão grande desses dados que esse subconjunto seja, por si sói, um problema de BigData?

Vocês hão de concordar comigo – como de fato concordaram na hora – que não é a maioria das empresas que possuem um volume de dados que sirvam para alguma coisa e que estejam na casa do Hadoop.

Minha intenção, eu expliquei, era conseguir deles a concordância para o seguinte ponto: “não é toda empresa que precisa usar Hadoop”. Eles concordaram, já que eu havia colocado uma dúvida razoável quanto à tecnologia necessária para o tratamento de dados na maior parte das empresas – se a maior parte de empresas de um país são pequenas e médias, e elas lidam com volumes de dados que dispensam Hadoop, então não é a maior parte de empresas que precisa de Hadoop. Simples e razoável, não?

Neste momento pedi ao Jorge que colocasse esse e-mail para a platéia:

Como resolver o problema de Hadoop dos seus usuários...
Como resolver o problema de Hadoop dos seus usuários…

Notaram como ele 1) presume que você tinha um problema de BigData que foi resolvido e 2) assume que ele não deu totalmente certo, porque ainda existe gente reclamando que não está vendo o que queria? Esse “now what?” é bem chatinho! Como assim, e agora o quê? Oras, de onde ele tirou a associação entre usuários finais e Hadoop? Quem disse que Hadoop resolveria 100% dos problemas de BI de uma empresa?

É muito chute em tão pouco espaço.

Outro ponto: contei-lhes que na apresentação da FATEC eu tive muitos espectadores de cursos hardcore de TI, como Análise de Sistemas, e Hardware. Mas eu tive a presença de vários alunos de Secretariado!

Me digam, pedi a eles, não é estranho que um curso tão “humanas” coloque no espírito do aluno inquietude o bastante para ele se arriscar em uma palestra técnica sobre Hadoop/BigData?

Mais: a lotação foi muito maior que a sala comportava, e era uma sala quase do tamanho da do TechnoTaks. Já não tinha mais espaço nem para sentar-se no chão… do corredor!! Era muita gente querendo ouvir sobre um treco que, ao cabo e ao fim, tem um uso muito restrito.

Tem uso mais restrito que Data Mining, aliás. Quase toda empresa pode se beneficiar de Data Mining. Mas poucas têm uso real para Hadoop, BigData e outros quejandos deste porte!

Vestido para detonar! Kkkkk...
Vestido para detonar! Kkkkk…

Eu participei do TT remotamente. No plano original eu estaria em um Hangout com a turma em Porto Alegre, e poderia ser visto. Por isso, considerando-se o que eu estava tramando soltar, vesti-me a caráter: com uma camiseta de Minecraft. Claro, pois se eu pretendia detonar boa parte do nosso senso-comum, nada tinha mais significado que me vestir de Creeper.

“Ora”, falei, me encaminhando para o fechamento:


“Se existe tanta propaganda sobre BigData/Hadoop, a ponto de mobilizar muita gente, e de áreas pouco relacionadas; se o assunto sempre vai estar restrito a um conjunto pequeno de empresas, com um subconjunto ainda menor de problemas aplacáveis com BigData/Hadoop, então essa exposição toda não passa de hype, de propaganda, de vapor. E se for isso mesmo, não há como sustentar o atual ritmo de destaque na mídia.”


Logo, na minha opinião,


O BigData vai sumir. Não vai demorar muito e tudo isso sobre o qual falamos não será mais um assunto tão quente, e essas tecnologias estarão de volta ao nicho de Data Mining ao qual pertencem.


Conclusão

Acabou, era só isso. Frustante? Pouco?

Eu queria ter estado lá, porque pelo pouco que eu percebi, remotamente, tinha gente louca de vontade para falar. Soube que algumas cabeças balançavam afirmativamente, outras meneavam e algumas sacudiam-se.

Só para dar um grau, eis um comentário que eu recebi no dia seguinte:


Quando começaste a falar, pensei: “o que esse maluco está dizendo?”, mas conforme foste expondo teus argumentos, vi que concordo contigo. Atualmente eu trabalho na Procergs, onde está se tentando utilizar sistemas de Big Data para análise e esse, sim, é um caso atipico, de governo, onde se processa notas fiscais de vários estados. Para se ter ideia, todas as notas fiscais são armazenadas e processadas em banco relacional SQL Server e possuem um volume de Terabytes de dados, mas que ainda assim a tecnologia que está no mercado há anos, dá conta. Parabéns pela iniciativa, conseguiste passar a mensagem! E obrigado, vou aproveitar o material. Abraço, Rodrigo Batista


E você, o que acha? Pirei de vez na batatinha? Concorda comigo? ;-)

Até a próxima! :-)

BigData

(Este post deveria ter sido publicado em 19/10/16, no dia seguinte ao evento. Não deu para completá-lo no dia, e para não ficar sem nada saiu apenas os links para download. Em todo caso, as referências a datas serão mantidas. Amanhã o blog volta ao ritmo normal.)

O conjunto das FATECs de São Paulo, capital, faz um congresso de tecnologia anual. Nesta semana está ocorrendo a décima oitava edição do evento, ao qual eu fui convidado para palestrar. A coordenação do evento me deixou livre para propor o tema e acabamos ficando com BigData. A apresentação foi ontem, 18/10/16, às 10H00min, com boa presença dos alunos e até mesmo de professores (!!). Conforme prometido a todos eles, eis aqui os links para download dos slides e notas, ambos em PDF:

Você pode clicar nestes links para download direto ou, se estiver lendo em papel ou outro meio não-digital, basta copiar os bit.lys no seu navegador. Ambos arquivos estão hospedados em uma conta [DropBox][dropbox_bitly] e, por causa disso, pode ser que apareça uma tela requisitando seu login para fazer o download. Não caia nessa! Não é preciso fazer login para baixar os arquivos: examine a tela com atenção que você vai acabar descobrindo algum texto do tipo “não obrigado, leve-me ao download”. O DropBox usa qualquer opoturnidade para ampliar sua base e por isso ele fica com essas “pegadinhas”.

O post de hoje é um resumo da apresentação. Bom proveito!

De Onde Veio?

Quando a Profa. Célia me convidou para participar do fórum ela me deixou à vontade para escolher o tema. Uau, que responsa…

Como a FATEC é uma escola técnica, de tecnologia, e voltada para o mercado profissional, eu propus apresentar um pouco sobre BigData, que tem sido um assunto “quente”. Acredito que uma palestra sobre esse tema possa abrir horizontes para vocês, alunos.

Vocês podem encontrar, pela web, toneladas de vídeos, livros e textos explicando o que é BigData, como montar uma fazenda Hadoop, porque Storm é o máximo e que Social Analytics é o bicho.

De que valeria um profissional do ramo vir até aqui e alugá-los por sessenta minutos para ler powerpoint e repetir o que existe por aí? Vocês não precisam de ninguém para se virar sozinhos, não é mesmo?

Minha meta, hoje, é dar a vocês uma visão calibrada do quê, de fato, essa tecnologia significa para o mercado de TI, o que ela pode fazer e para onde eu, Fábio, acredito que esse barco vai.

Com isso eu espero dar a vocês uma vantagem em sua vida profissional, em sua busca por emprego, que – todo mundo está careca de saber – não está fácil para ninguém, certo? ;-)


Notem que, exceto pela minha certificação Pentaho, eu não tenho nenhum diploma de BI ou pós-graduação em DW nem nada do gênero. O que eu vou contar aqui eu aprendi na lida diária, no contato com problemas e soluções que afligem toda empresa moderna.


Eu vou mostrar os conceitos do Hadoop em alto nível, sem entrar nos detalhes técnicos, e daí explorar as possibilidades que surgiram, que promessas estão sendo feitas e o quê é besteira nisso tudo.

O Céu é o Limite

Todo computador funciona da mesma forma: lê dados de algum lugar, realiza alguma operação e manda o resultado para algum outro lugar.

Computador conceitual.
Computador conceitual.

Um computador nada mais é que um circuito eletrônico. Aliás, era mecânico, daí a a válvula foi inventada e deu origem ao computador eletrônico. Mais tarde ela foi substituída por transístores, que foram combinados em circuitos integrados (CI), que começaram grandes, com poucos componentes. Conforme a eletrônica se sofisticou, a quantidade de transístores por CI aumentou, elevando a velocidade de processamento.

Exemplo de circuito integrado: o famoso 555.
Exemplo de circuito integrado: o famoso 555.

Essa tendência poderia ir adiante para sempre, se não fosse um porém: a Física, a própria Natureza, interpõe certos limites.

A resistividade de um condutor aumenta conforme sua secção diminui. Logo, com circuitos integrados na casa dos milhões de transístores em menos de um centímetro quadrado, os circuitos ficam muito pequenos, o que faz com a corrente através desses circuitos gere cada vez mais calor. Para piorar, o aquecimento em si também afeta a condutividade, “somando agressão à injúria”1. No final das contas, a redução de escala é barrada por um limite prático.

E mesmo que o problema de condutividade seja resolvido usando, digamos, supercondutores, efeitos quânticos limitam o tamanho dos transístores.

Se mesmo assim conseguíssemos superar essa barreira, lá no fim acabaremos trabalhando com átomos individuais, e não dá para ficar menor que um átomo. Dá para usar átomos menores, claro, mas trocar o material do chip nunca vai remover essa barreira, vai apenas empurrá-la para mais longe. E mesmo que pudéssemos avançar ininterruputamente crescendo o poder da CPU, estaríamos limitados velocidade de acesso de RAM, discos, redes.

Todo computador sempre terá um limite de capacidade e velocidade de processamento.


Os maiores computadores monolíticos, ou seja, cujo software é executado integralmente na mesma CPU, são os mainframes. O SERPRO usa mainframes para quase todos os processamentos de altos volumes, como tratamento do IR e o SISCOMEX (o sistema aduaneiro da RFB.)

Mainframes são o limite da máquina monolítica.
Mainframes são o limite da máquina monolítica.

Entretanto, enquanto a capacidade de cada máquina ficava cada vez maior, com valores proporcionais, tecnologias que se tornavam mais ordinárias se tornavam cada vez mais baratas. Ou seja, as grandes máquinas continuam caras como sempre, mas as máquinas baratas estão ficando cada vez mais poderosas, e isso abre uma possíbilidade interessante: paralelizar.

Custo do poder de processamento não cresce linearmente.
Custo do poder de processamento não cresce linearmente.

Superman & Batatas

Pense no seguinte: o Super-Homem é o cara mais forte e rápido do mundo. (Please, deixem o Flash fora disso…)

Suponha que um homem normal leva um minuto para descarcar uma batata, e que o Super-Homem leva, vai, um segundo. Isso quer dizer que ele pode descascar sessenta batatas no tempo que um homem normal descasca uma – e só! Nada além disso! Ele não consegue ficar mais rápido.

Bom, basta juntarmos 120 homens normais e teremos o dobro da velocidade do Super-Homem! Super-homens não existem por aí dando sopa, mas temos sete bilhões de humanos normais. Isso significa que, botando todos para descascar batatas, temos uma velocidade média de 116 milhões de batatas descascadas por segundo (million-peeled-potatoes-per-second, ou mppps kkkk…) Considerando-se que a produção mundial de batatas é de mais ou menos 1,88 trilhões de batatas (dados de 2013, supondo 200g de peso médio por batata), levaríamos aproximadamente 16.200 segundos para descascar tudo, ou quase cinco horas – menos de um dia de trabalho. A mesma tarefa feita pelo Super-Homem levaria mais de 520 milhões de horas, sem parar, ou quase um milhão e meio de anos!!

O mesmo pode ser feito com o processamento de dados: se uma máquina, sozinha, levaria um tempo X para realizar um processamento qualquer, duas máquinas iguais realizariam o dobro do processamento no mesmo tempo, ou poderiam completar a tarefa na metade do tempo.

Se podemos fazer isso, então nosso problema muda de figura: já não é mais como construir um computador super-rápido, mas sim como dividir nosso trabalho em pedaços iguais e processar esses pedaços em muitos computadores medianamente rápidos.

Construa seu próprio supercluster!
Construa seu próprio supercluster!

Bom, Bonito & Barato

E foi nesse problema que vários pesquisadores passaram a trabalhar na década de 2000. Em 2003, para vocês terem um idéia, ainda não existia nenhum “kit” pronto para processamento distribuído. Já existiam clusters, claro, mas eram coisas como o Beowulf, que nada mais eram que um monte de máquinas na mesma rede e alguns pacotes de software para ajudar a paralelizar a execução de determinado programa.

Nesse cenário o Internet Archive e a University of Washington se lançaram à busca de uma tecnologia que melhorasse a indexação de páginas web. Depois de algum tempo a equipe conseguiu produzir uma arquitetura clusterizada que dava uma performance superior em indexação, ainda que bem mequetrefe e instável, que acabou sendo chamada de Nutch. Segundo eles, era preciso uma pessoa ficar literalmente ao lado da aplicação o tempo todo, consertando os erros e defeitos.

… mas ao mesmo tempo outra empresa, uma com ainda poucos anos de vida, investia pesado em coisa semelhante.

Essa empresa, que não era ninguém menos que a Google, lançou dois papers, em 2003 e 2004, que se tornaram a fundação do que viria a ser o ecossistema de BigData. O primeiro falava sobre um cluster de sistemas de arquivo massivo, automatizado, o Google File System. O segundo propunha um modelo de programação para processamento paralelo, e expandia conceitos de uma tecnologia chamada programação funcional, desenvolvida no final da década de 1950 a partir dos conceitos de Cálculo Lambda, que por sua vez é da década de 1930. Esses conceitos resultaram em um framework, que é o segundo paper publicado, chamado de MapReduce. Esse paper mostrava como usar as operações funcionais de map() para distribuir a operação e reduce() para consolidar os resultados.

O gênio saíra da garrafa. :-)


A história toda é bem interessante, e vale a pena conhecer: clique aqui para ler a história inteira.


Eram os primeiros anos do Google, e uma outra empresa dominava então: o Yahoo. Buscadores de web (Google, Yahoo etc.) ganham dinheiro vendendo links e anúncios. Quanto mais páginas indexadas, maior sucesso nas buscas, e com maior sucesso, mais gente aparece querendo buscar. Quanto maior o público, a venda de anúncios cresce em número e valor.


Mais gente usando = maiores oportunidades de negócio.

Para aumentar o público, melhore seu produto = indexe mais.


Em 2006 o Yahoo investiu na reconstrução de seu motor de busca e começaram um projeto que incluíu os criadores da tecnologia que o Internet Archive estava desenvolvendo, o Nutch. O Nutch, que ainda existe aliás, era montado usando os conceitos do GFS e MapReduce. Quando o Yahoo encampou o projeto eles decidiram dividi-lo em dois pedaços: um webcrawler, que permaneceu com o nome Nutch, e uma infra-estrutura de clusterização, que englobava os pedaços trazidos do GFS e MapReduce. Já que eram tecnologias essencialmente diferentes, essa separação fazia todo sentido.

E que nome dar a este projeto?

Doug Cutting, que assumiu o projeto no Yahoo, nomeou-o a partir do elefante de pelúcia que seu filho chamava de, adivinhou, hadoop. Segundo Cutting, esse foi um bom nome porque era simples, sonoro, fácil de lembrar e sem nenhum significado em particular.

Ti fofu!!!! Had'oop!
Ti fofu!!!! Had’oop!

E o Que é BigData?

BigData é Hadoop, Hadoop é BigData. Ao menos no contexto geral, comercial, essa é a relação entre a tecnologia e o conceito: a tecnologia Hadoop ajudou a firmar o conceito de BigData, que por sua vez ganhou relevância conforme o Hadoop era aplicado em mais e mais casos de uso.

Em outras palavras, a maturação do Hadoop trouxe solução a uma classe de problemas normalmente fora do alcance. Esse sucesso turbinou o comércio dessas soluções, que acabaram sendo chamadas de BigData.

Hadoopen! Haduken! Shoriuken! Spining Round Kick-u-ken! Barbie e Ken!
Hadoopen! Haduken! Shoriuken! Spining Round Kick-u-ken! Barbie e Ken!

A certa altura o Hadoop ganhou status de cool, de pop, e caiu no gosto tanto dos capitalistas de risco. Daí surgiu uma leva de startups focadas em Hadoop, seus serviços, usos e todo o ecossistema tecnológico. E também caiu na graça da imprensa de tecnologia, que achou um nicho cheio de jargões fresquinhos e enigmas suficiente para uma década de reportagens.

Estamos agora em 2016 e, finalmentem, a força das buzzwords BigData/Hadoop está começando a esmaecer. Será preparação do palco para as próximas, como IoT?

O primeiro uso da expressão BigData foi em 1997, no artigo Application-controlled demand paging for out-of-core visualization para designar dados que não cabiam na memória do computador ou mesmo no disco. O resto é história: Hadoop acabou irreparavelmente associado ao termo. Apesar disso houve (e há) outras tecnologias para resolver problemas de “dados que não cabem na memória” do computador (e quase todas giram ao redor de clusterização.)

Por exemplo, existem bancos de dados especiais para aplicações computacionais intensas (muita conta e muito dado), como o Vertica e o Teradata. Ambos armazenam os dados de maneira diferente da de um banco relacional ordinário, e montam-se em clusters. Isso permite que distribuam as contas pelos nós, usando conjuntos locais de dados que depois se integram nos resultados em um nó mestre – que é exatamente a mesma idéia do Hadoop.

Pelo que vimos do histórico na primeira seção, existe um limite para o aumento da capacidade de processamento monomáquina, e portanto existe uma categoria de problemas que não pode ser tratada, dentro de tempos razoáveis, por esta arquitetura.

Resumindo:


Sempre que sua necessidade de processar dados extrapole a capacidade de uma só máquina e um tempo razoável, você está com um problema de BigData.


Podemos colocar de uma forma mais prática:

BigData é uma tecnologia de cluster de máquinas COTS2 para coleta e processamento de um grande volume de dados, dentro de um tempo razoável.

  • “Grande” é impreciso: qualquer coisa maior do que uma máquina simples consegue dar conta;
  • “Tempo Razoável”: mais imprecisão. Um tempo tal que os resultados são obtidos antes de tornarem-se inúteis.

Por exemplo, pode ser que os dados caibam todos no maior HD que você pode comprar, mas levariam anos sendo processados só para obter a primeira resposta – imagine as seguintes. Se você precisa da resposta em meses, anos é muito tempo. Se precisa de horas, semanas é muito tempo, e assim por diante.

Só que essa definição não é comercial, ela não “vende”. Foi quando começaram a surgir os acrônimos, sempre em tuplas de Vs, com cada vez mais vês: 3, 4, 5…

A primeira foi 3Vs: Volume, Velocity, Variety.

Alguns adicionaram um novo V, de veracidade, que queria dizer “qualidade”. Ou seja, não bastava acumular lixo, tinham que ser dados verdadeiros.

Outro colocou um V para valor, chegando a 5Vs, argumentando que se você não extrair valor dos dados, então não era BigData. E assim por diante.


Eu não consigo para de associar VVV com vai e volta, viu?, he he, ou com as variações. Por exemplo, meu primo usava 5 Vs: vai e volta voando, viu v******* ? :-D


Essa é a parte chata do mundo de TI, que tenta transformar conceitos e softwares em produtos com o mero balançar de beiços. Não caiam nessa! Só porque alguém escreveu uns slides (como eu fiz), montou um produto e está vendendo (que é quase o mesmo que estou fazendo…) não significa que ele está transmitindo um fato novo, uma verdade inegável ou algo supimpa. Use sua inteligência para filtrar o mundo.

No fundo tudo isso queria dizer a mesma coisa: problemas tão grandes que precisam de mais capacidade que uma só máquina pode fornecer.

Mas, ora vejam vocês, existem muitas opções para atender essa categoria de problemas!! Para começo de conversa existem máquinas SMP e multi-core. Existem clusters de bancos de dados, existem tecnologias de bancos de dados alternativos (como o Teradata ou o Vertica, que são colunares.)

Hadoop é uma destas tecnologias, que acabou ganhando fama por que seus limites situam-se muito acima dessas outras opções. (Mais imprecisão…)

Se precisássemos classificar os problemas pela capacidade de processamento requerido para resolvê-los, teríamos algo como isso:

  • Problemas normais: monomáquina;
  • Problemas grandes: Clusters de bancos (tradicionais e depois colunares;)
  • Problemas extremos: Hadoop.

Confuso? Complicado? Então guardem apenas isso:


BigData = Hadoop

Hadoop = BigData

BigData é a tecnologia de cluster de máquinas COTS2 para armazenamento e processamento de um volume de dados maior que cabe em uma só máquina, antes de o resultado ficar inútil.


Como sempre, essa definição é a minha, a partir do que eu aprendi. Você pode contestá-la (adoraria ouvir) ou achar outras. Como quase tudo em BI, vale a que você preferir. ;-)

Botando Para Rodar

Daí vem você e me diz: “Fábio, entendi patavinas do que você falou. Por analogia, algum destes temas tem a ver com o Hadoop/BigData?”

  • Inteligência de Negócios? Não mais que um banco de dados normal;
  • Armazém de Dados? De novo, mesma resposta (sem contar que projetos de DW incluem qualidade de dados e valor;)
  • PostgreSQL, Oracle etc? Esses são os famosos bancos relacionais, o que são bem diferentes – a começar pela forma de operação;
  • Sistemas transacionais (OLTP)? Os sistemas, em si, usam bancos transacionais. Como Hadoop é, grosso modo, um sistema que opera em lote, a resposta é não;
  • Linguagens de Programação? Não, nada a ver. Você pode implementar rotinas de MapReduce em algumas linguagens, mas Hadoop não é uma linguagem. Só para constar, programas MapReduce nativos são escritos em Java;
  • A Nuvem? De uma forma oblíquoa e não-relacionada, talvez. De maneira direta, nada a ver;
  • A Nuvem é BigData? Mesma resposta.

Se você precisa montar uma analogia para entender, meu caro, você está no sal, porque não existia nada como Hadoop antes. Pelo menos nada que fosse comum o bastante para ser um senso-comum. Sabe o que é Lustre? Já ouviu falar em MPI ou Beowulf? Pois é, Hadoop é uma mistura dessas coisas. ;-)

E todo mundo precisa de Hadoop? Ou de BigData? Não, claro que não. São raras as tecnologias que são aproveitadas indistintamente por qualquer organização. Hadoop não é uma dessas. Hadoop/BigData é uma tecnologia de nicho.


Veja que Hadoop(=BigData) é totalmente implementando com Software Livre. Logo qualquer um pode usar como e para o quê quiser, sem custos de licenças.


Como saber se você precisa? Fácil: sua organização enfrenta algum problema causado pelo mero volume dos dados? Se tem, pode ser que precise. Se não, então nem se dê ao trabalho. Simples assim.

Claro que podem existir problemas que você ainda não sabe que tem, e que podem vir a ser tratados com Hadoop, mas esses fazem parte de um conjunto mais ou menos pequeno. Vejamos um pouco sobre isso.

É Online?

Hadoop foi projetado para ser operado por meio de programas MapReduce. Isso é qualquer coisa, menos online. Problemas online, em geral, dizem respeito a registrar transações e hoje a melhor opção para isso ainda são bancos de dados relacionais. Em alguns casos, um mainframe é a única solução.

Por exemplo, caixas do Pão de Açúcar eram operadas por mainframe. Não sei como é hoje, mas até meados da década passada cada checkout do Pão de Açúcar era ligado a um mainframe, com operações de enorme volume de dados acontecendo em tempo real.

Isso não quer dizer que essa possibilidade está barrada ao Hadoop. Muito pelo contrário: existe muita pesquisa e desenvolvimento sendo conduzido para reduzir e até eliminar os overheads do Hadoop e colocá-lo em “modo online”. Em última análise, esse caminho vai nos levar até o ponto de processamento transacional, operacional.

Mas, hoje e pelos futuro próximo, Hadoop é algo que opera em batches, não online.

Se você precisa de operações online em grande volume (OLTP), como ERP, invista em grandes computadores e até mesmo em mainframes. Por enquanto, Hadoop não é uma tecnologia para esse tipo de aplicação. Um dia, quem sabe?

DataLake?

Esse é um conceito idealizado pela própria Pentaho. A meta deles era popularizar o uso do Hadoop, e com isso alavancar o consumo de Pentaho, já que esse tem enormes facilidades para lidar com Hadoop.

Em tese, DL é um substituto para um Data Warehouse, um armazém de dados. O problema é que, hoje, Data Lake é uma coisa bagunçada e crua. Para a empresa consumir os dados de um Data Lake é preciso que um profissional trabalhe os dados que estão lá e construa outras estruturas, normalmente fora do Hadoop, que serão consultadas pela comunidade de usuários da organização.

Só que ao fazer isso caímos de novo no modelo de Armazém de Dados, que faz exatamente a mesma coisa.

E se a dita empresa quiser se livrar desse profissional intermediário, ela terá que deixar cada cliente, cada usuário, construir seus próprios usos. O que vai requerer que esses usuário conheça não apenas o negócio, mas também conheça intimamente os dados – ou nada vai sair!

No fundo, DL, tal como se apresenta hoje, é uma tentativa de criar um produto comercial, de linha de frente, com um insumo que só funciona bem em certas situações, mas não em todas. Atualmente eu não vejo nenhuma vantagem nele – especialmente se considerarmos Data Vault.

Machine Learning

O termo Machine Learning é um tipo de expressão guarda-chuva para acomodar um monte de tecnologias. Grosso modo, Machine Learning, ou Knowledge Discovery etc., são termos relacionados à área de Data Mining.

Data Mining é o processo – não o software! o processo! – de examinar dados em busca de um modelo matemático que permita usar o passado para prever o futuro.

Um exemplo simples é a previsão do tempo: depois de analisar os dados meteorológicos acumulados por décadas, fomos capazes de construir uma equação – um modelo matemático – que dá a probabilidade de ocorrer ou não chuva em um determinado lugar, em um determinada dia e hora.

Podemos aplicar o mesmo tipo de técnica a coisas mais prosaicas como sugerir um produto para nosso cliente, oferecer um desconto para ajudá-lo a fazer uma compra ou negar qualquer desconto. Podemos analisar os dados de tráfego em uma cidade e descobrir uma sequência de acionamento de semáforos para reduzir congestionamentos. Podemos analisar os caminhos produtivos de uma fábrica e mudar seu layout para reduzir custos, aumentar a produtividade ou prevenir defeitos.

Machine Learning é justamente uma técnica de descoberta de um modelo que explique os dados. Como volume é uma variável crítica para o sucesso de técnicas de ML, Hadoop e BigData têm sido associados a ML, mas não são, de forma alguma, sinônimos.

NoSQL?

NoSQL já foi descrito como not SQL e mais recentemente como not only SQL, e refere-se de maneira geral ao mecanismo de consulta de uma base de dados. Hoje entende-se por NoSQL como uma expansão nas técnicas de manuseio de dados em bancos para além de mero SQL.

Hadoop, que é alimentado por operações de transferência de arquivos e consultado por MapReduce, é considerado uma tecnologia NoSQL. Entretanto, NoSQL não é sinônimo de Hadoop, da mesma forma que não é sinônimo de MonetDB, CouchDB e outros famosos bancos NoSQL.

Curiosamente, há um grande esforço para conseguir “equipar” Hadoop com SQL! Vai entender…

IoT?

Internet das Coisas, pelo que tudo indica, é a próxima BuzzWord a estourar nas paradas. E aí, qual é a relação entre IoT e Hadoop/BigData?

A visão trazida pelo conceito IoT diz que todos os eletrodomésticos e traquitanas terão, cada um, seu próprio IP e trocarão dados entre si e com computadores. Para que propósito, exatamente, é um tópico à parte. O que nos interessa, hoje, é notar que o volume de dados estima-se que será gerado é muito (muito (muito!)) maior que as maiores plataformas atuais trabalham. Logo, analisar esses dados será tarefa para Hadoop – até mesmo transacioná-los talvez venha a ser feito por uma plataforma similar.

Logo, IoT não é sinônimo de BigData, ainda que com certeza possuam uma forte ligação.

Que Problemas Resolve?

Vocês hão de concordar comigo que essa pergunta é um pouco boba. Afinal, se BigData trata de processar dados que não cabem na RAM ou no disco local, então BigData (que é o mesmo que falar “Hadoop”) resolve problemas… com dados demais!

O critério para saber se você – sua empresa, sua organização – precisa de uma solução de BigData não é o tipo de negócio, o porte da organização ou o alcance dela. O critério é ter coisa demais para processar e, mesmo com uma máquina maior, ainda continuar a ser coisa demais, ou nunca ser rápido o bastante.

Por isso, se algum fornecedor te pestear para oferecer BigData, ponha um pé atrás. Assista a apresentação dele e pergunte-se sempre, o tempo todo, “não dava para fazer com ( ) um banco tradicional? ( ) um banco colunar? ( ) um cluster? ( ) alguma outra coisa mais fácil ou barata? ( ) etc?”.

Voltando ao ponto, graças a paralelização massiva, Hadoop/BigData arquiva e processa dados com uma grande velocidade. Que categoria de problemas conhecemos, ao menos em BI, que causa grande processamento?

Relatório? Não, nem de de longe.

OLAP? Mais ou menos, talvez, mas via de regra, não.

Painéis? Menos ainda…

Data Mining?

Isso mesmo: Hadoop barateia Data Mining. Sempre que você precisar de Data Mining, e a performance do seu parque estiver abaixo do que você precisa, adotar Hadoop pode melhorar sua vida com uma relação custo-benefício sensivelmente melhor que outras tecnologias. Mas cuidado: melhor relação custo benefício olhando apenas hardware e software! Sem mão-de-obra qualificada, pode ser que seja tão difícil montar e operar um cluster Hadoop que outras soluções mais caras podem ter, no final, uma relação custo-benefício mais interessante!


SEMPRE considere a necessidade, o custo e a disponibilidade de mão-de-obra especializada!! SEMPRE!!!


E, claro, Hadoop é uma boa opção toda vez que for preciso arquivar um grande volume de qualquer coisa que não seja usado online, como arquivos, históricos, logs etc.

Profissional de BigData?

Gostou do que viu? Tem interesse em saber no quê trabalha, quanto ganha e que sofrimento passa um profissional dessa área? Enfim, é a sua vida… ;-)

Há duas grandes áreas: Infra-estrutura e Aplicação em si.

Como o próprio nome diz, montar e sustentar a infraestrutura de um cluster Hadoop requer conhecimento multidisciplinar: redes, sistemas operacionais, Linux (fundamental!) e assim por diante. Até ajuda saber programar Java, ou no mínimo entender o assunto, mas não é um pré-requisito. Invista em cursos de qualidade, começando por um sobre Hadoop e depois avançando nos sub-tópicos. Isso vai te dar capacidade para entender os problemas que assolam ambientes Hadoop e a fazer otimizações mais sofisticadas, te distinguindo no mercado de trabalho.

Agora, você gosta mesmo é de sujar as mãos escovando bit até deixar um algoritmo tinindo de brilhante, seu caminho no Hadoop é praticamente o mesmo de um Analista de Data Mining: é obrigatório conhecer bem e ter experiência com Estatística e Matemática. A partir daí é necessário saber transformar esse conhecimento em modelos matemáticos a partir dos dados disponíveis, o que é feito usando-se o ferramental de Data Mining, como R, RapidMiner, SAS Enterprise Miner, SPSS, Python e/ou similares.

Mas todo esse conhecimento é apenas para sua fundação. O profissional que vai fazer a diferença, que vai elevar seu salário à estratosfera é aquele que tiver visão de negócio e habilidades de desenvolvedor. É aquele que souber entender o negócio da empresa e traduzir aquilo em perguntas aos dados, e a moldar as respostas em conceitos que possam ser transformados em algoritmos.

Esse sempre foi, é e sempre vai ser O cara. ;-)

Hoje em dia essa função leva um nome vistoso, para o qual eu sempre torço o nariz: Cientista de Dados. No fundo, porém, o mesmo de sempre: Analista de Data Mining.

Conclusão

Meu propósito era ajudar os alunos da FATEC a entrar com o pé direito no tema. Não tenho como avaliar o resultado e saber se eu atingi ou não esse objetivo. O feedback dos alunos foi bastante positivo, e a recepção foi boa. No mínimo, portanto, eu atendi a um anseio deles.

Uma coisa que me chamou a atenção foi o fato de ter ali não apenas cursos de TI em geral, mas também alunos do curso de Secretariado Executivo. Porquê? Oras, se tem uma coisa que é distante de BigData, em uma empresa, é a disciplina de administração/secretariado/gestão em geral. Mesmo que se argumente que BigData é o futuro e que logo a estratégia da empresa vai estar calcada em resultados obtidos graças à essas tecnologias, me parece um exagero colocar o assunto em uma faculdade tão distante de TI quanto Secretariado. Na minha opinião, é o mesmo que ensinar bancos de dados transacionais para o pessoal de Biblioteconomia porque usam sistemas OLTP.

Essa observação alimentou minha palestra seguinte, na PUC do Rio Grande do Sul. Mas isso é o assunto do próximo post.

Até lá! ;-)


  1. Uma expressão inglesa, “to add insult to injury” 
  2. Common-Of-The-Shelf, ou “de prateleira”. Significa coisas padronizadas, baratas – algo como uma commodity

Data Vault: Como Usar – Errata

Meu grande amigo e co-autor do PnP, Cesar Domingos, me mandou um e-mail com duas dúvidas:

Fala Fábio,

Tudo bem?

Tô vendo uns posts seus sobre Data Vault e fiquei com dúvida em um.

https://geekbi.wordpress.com/2016/05/25/data-vault-como-usar/

Na parte do Modelo Completo, onde tem o desenho, a tabela s_l_empregados_pedidos não deveria estar linkada à tabela h_pedidos? Ou se não for na h_pedidos, não deveria existir uma tabela hub entre ela e a l_empregados_pedidos?

Fiquei meio perdido ali. Você tem algum exemplo com dados?

E uma outra pergunta. O que vai exatamente no campo Record Source? O nome da tabela de origem?

Abraços,

Cesar Domingos
Vida corrida de Cesar Domingos
Consultor Linux e BI
LPIC-3 e RHCE

Fui ver, e ele tem razão. Naquele post, a função da tabela s_l_empregados_pedidos não está clara, até porque existe um erro também. Neste post completo a explicação, explicitando o que eu queria fazer e mostro uma correção possível.

O Problema

A metodologia de modelagem de dados para Data Vault define três tipos principais de tabelas: hub, links e satélites. Hubs registram conceitos de negócio, como vendedor, cliente e produto. Links registram relacionamentos entre conceitos de negócios, ou seja, entre hubs. Por exemplo, se um vendedor cuida de um certo cliente, então podemos definir um link entre os hubs de vendedor e cliente.

Satélites guardam os atributos de hubs e links. Se o cliente é um hub, um satélite de cliente contém, por exemplo, seu endereço, sua data de nascimento, sua ocupação e outros dados.

A figura da qual o Cesar falou mostrava dois hubs, empregados e pedidos, e um link entre os dois:

As tabelas combinadas no modelo.
As tabelas combinadas no modelo.

Além disso, ela também mostra um satélite para hub empregados, e um para o link empregado-pedido. E isso está errado!

Sim, veja: satélites contêm atributos de um hub ou de um link. A tabela s_l_empregados_pedidos é um (s_)atélite pertencente ao (l_)ink empregados_pedidos. Mas olhe que atributos esse satélite tem:

  • data_pedido
  • pagamento_tipo

De quem são esses atributos? Data do pedido é um atributo do… pedido. E tipo de pagamento? Também! Ora, se são atributos do pedido – e não da relação entre pedido e vendedor – então esse satélite é do hub pedido, e não do link empregado-pedido! Por isso esse satélite está errado.

Para estar correto ele precisaria conter algum atributo da relação, do link. Esse modelo não é um bom caso para um exemplo de satélite de link, que era a minha intenção original.

A Solução

A mensagem que eu queria passar precisa de um modelo ligeiramente diferente:

O modelo corrigido.
O modelo corrigido.

Agora temos um novo hub, cliente. Poderíamos ter seu respectivo satélite, mas seria redundante, pois já temos um exemplo de satélite de hub.

Nesta empresa, cada cliente é atendido por um único vendedor ou gerente, que é o dono da conta, como acontece em um banco, por exemplo. Em um banco, todo cliente possui um gerente. Esse relacionamento aparece como um novo link, entre clientes e empregados.

Como dizia uma propaganda de banco, o tempo passa, o tempo voa. Um gerente muda de agência, outro muda de emprego, entram novos gerentes, chegam clientes de outras agências, clientes vão embora… Conforme o tempo passa, a relação cliente-gerente muda. Pior ainda: pode ir e voltar, ou seja, um cliente pode estar com um gerente hoje, outro daqui um mês e daí no ano seguinte volta a estar sob seu primeiro gerente.

O link não possui data de validade. Ele não possui nada além de data de criação e sistema de origem, aliás. Como, então, saber qual é o gerente atual de cada cliente? Ou que gerente teve que clientes durante um certo período?

Um satélite de link, justamente como mostrado na figura anterior, resolve essa situação: cada vez que o link sofre uma atualização, o satélite versiona sua data de validade. Resumindo:


Porque um link pode ter um satélite? Por que a relação entre dois hubs pode mudar ao longo do tempo, e a única forma de saber quais estão ativas, hoje, no sistema de origem é usando um satélite.


Evidentemente, um link pode ter outros atributos além de período de validade. Exemplo? Pense nos itens de um pedido, ou seja, os produtos que o cliente comprou naquele pedido. Esses itens são registrados no DV como um link entre o hub pedido e o hub produto. Agora, os detalhes de cada item, ou seja, a quantidade, o valor pago etc. são registrados como satélites desse link.

Record Source??

Quanto à segunda pergunta, o que vai no campo Record Source? Bom, o campo RSRC recebe o nome do sistema de origem, não da tabela. Como as tabelas, em princípio, fazem a integração dos dados, o campo indica em que sistema foi identificado aquele elemento – hub, link ou satélite – pela primeira vez. Como as tabelas hub e link são carregadas um sistema de cada vez, o campo RSRC indica, no fundo, que sistema foi carregado primeiro, já que ele não é atualizado mesmo que o campo seja encontrado em outro sistema, com o valor idêntico.

Esse campo tem um pouco mais de utilidade para satélites.

Já passei por situações em que era fundamental separar os dados dentro do satélite por sistema de origem. Foi com o Zabbix: um DV foi construído para integrar 11 Zabbixes. Como era tudo igual, tínhamos apenas uma tabela de satélite para cada item. Como o mesmo item podia aparecer em dois ou mais Zabbixes diferentes, o satélite do Zabbix 1 podia ser encerrado se o mesmo item existisse em qualquer outro Zabbix. O mesmo aconteceria com o segundo Zabbix a ser carregado e assim por diante e depois se repetindo desde o início. A única forma de resolver foi filtrando o satélite pelo RSRC, um para cada Zabbix. ;-)

Casos de Uso de Inteligência de Negócios

Inteligência de Negócios é a disciplina que busca a compreensão do funcionamento de uma organização (o conhecimento do negócio) mediante a aplicação do Método Científico. Além de insumo para aplicação do Método Científico, os dados de uma empresa prestam-se a um sem-número de funções, que podem ser realizadas por uma gama de ferramentas.

Algumas das formas de uso são notadas com maior frequência em uma organização ordinária. Vamos descrever algumas destas formas de uso de dados e ferramentas, os chamados Casos de Uso.

Caso de Uso

Um caso de uso (ou CDU para simplificar) é um modo de aplicação ou o propósito – o uso – de algo, como uma ferramentas ou uma técnica.

Como exemplo tome o caso de uso de uma panela de pressão: cozinhar alimentos a temperaturas superiores ao ponto de ebulição da água. Sempre que um alimento precisar de maior temperatura para ser adequadamente cozido, podemos usar uma panela de pressão.

Conversamente, sempre que um alimento pode ser cozido no ponto de ebulição da água, o uso de uma panela de pressão é desnecessário e pode até mesmo comprometer a qualidade do resultado.

A toda ferramenta corresponde um ou mais casos de usos com graus variados de adequação. Aplicar uma ferramenta a situações para as quais ela não possui uma adequabilidade mínima pode comprometer o resultado almejado, ou pior, pode entregar um resultado plausível enquanto oculta alguma falha intrínseca. Basta pensar no velho ditado “para martelo, tudo é prego” e imaginar que uma boa martelada pode engastar um parafuso na madeira: a qualidade da fixação será insuficiente e, mesmo aparentando estar “pregado” bem o bastante, o parafuso pode soltar-se e causar uma falha catastrófica.

Casos de Uso de Dados

Os dados produzidos nos sistemas informatizados de uma organização podem ser consumidos de várias formas e usados para várias finalidades.

Monitoração

Parte do trabalho de qualquer profissional, nos dias de hoje, é acompanhar eventos diários e responder a eles.

Entrou um novo ticket pedindo serviço? Surgiu um defeito? Um sistema sofreu pane?

Manter-se informado dos acontecimentos é parte da tarefa de monitorar o ambiente. Outra parte é examinar a situação, ou seja, os dados correntes, em busca de sinais que prenunciem o surgimento de uma situação específica. O exemplo mais banal é observar o dia no calendário: a aproximação de certas datas, que avizinham vencimentos de prazos, é uma forma de monitoração.

Algumas situações só podem ser monitoradas a partir de um conhecimento prévio, que precisa ser adquirido de antemão. Sabemos que a chance de chover aumenta quando o céu cobre-se de nuvens escuras porque tivemos a oportunidade de testemunhar a correlação entre chuva e céu nublado – com frequência o primeiro segue-se ao último – várias vezes.

Evidência

Situações surgem em que ocorrências passadas são questionadas. A forma mais prática de confirmar fatos é apresentar os dados que evidenciam o que aconteceu.

Por vezes essa evidência é direta, como um relatório de gastos ou uma lista de peças de um lote. Em outras situações a evidência é indireta. Se nenhum sistema registra a entrada do empregado em certo dia, por exemplo, e nenhum arquivo de sua estação de trabalho possui timestamp de acesso naquele dia, então é razoável supor que naquele dia ele não esteve em seu posto.

Análise

Pense no indivíduo que nunca testemunhou uma chuva na vida. Na primeira ocasião em que observar o céu escurecido – resultado da monitoração – ele não presumirá o risco maior de precipitação. Apenas depois de algumas ocorrências céu escuro/chuva é que ele poderá ser levado à concluir que a associação existe.

Essa é uma situação recorrente no funcionamento diário em qualquer organização: se não entendemos a relação entre causa e efeito, monitorar o quê? Se não temos um argumento a ser testado, provar o quê? Esse é o miolo da disciplina de Inteligência de Negócios, a que realmente agrega valor à organização ao produzir conhecimento explicitando a relação (e os parâmetros) entre causa e efeito. Essa é a mesma justificativa para erigirmos um DW, aliás.

Dados, além de servir para monitorar e para demonstrar fatos, ainda podem ser explorados e estudados em busca do conhecimento de negócio. Na minha opinião, essa classificação do uso dos dados em uma empresa explicita a separação entre os usos analíticos e operacionais.

Casos de Uso de Ferramentas de Dados

O termo genérico “ferramentas de dados” significa toda ferramenta que manuseia e/ou apresenta os dados dos sistemas informatizados de alguma maneira. Por exemplo, o próprio sistema informatizado, que produz os dados, é uma ferramenta de dados. Levado ao paroxismo, todo software é uma ferramenta de dados, já que todo software comanda uma CPU para tratar algum dado de alguma maneira. Para o propósito deste documento vamos restringir essa definição aos softwares que lidam com dados de negócio em sua forma operacional. Por exemplo, softwares que tabulam dados ou traçam gráficos.

Relatório

Uma das ferramentas mais simples para o manuseio dos dados é a exibição de listas. Esse CDU é conhecido pelo termo de relatório, pois relata, descreve, apresenta os dados. Um relatório é, por definição, uma lista de dados com rótulos nas colunas, que pode vir acompanhado de outros recursos.

Uma ferramenta de relatório pode incorporar uma quantidade de opções de apresentação, como títulos, cabeçalhos, números de páginas, gráficos ou sub-relatórios (relatórios dentro de relatórios.) Ferramentas de relatórios podem possuir alguma resposta dinâmica, como escolher o formato de saída (HTML, PDF e CSV entre outros), ou a aplicação de algum filtro em tempo de execução e até mesmo embutir URLs (links web) nos campos, tal que clicar sobre eles abrem páginas em navegadores web. Consta como tradicional a possibilidade de imprimir tais listas.

O acesso aos relatórios pode ser por meio do software instalado localmente ou via portal web e algumas soluções combinam a possibilidade de remeter um relatório renderizado diretamente para o e-mail de um usuário.

Painel de Dados

Um passo adiante do simples relatório, painéis são meios eminentemente gráficos, usados para apresentar diversas visões sobre dados em uma única área, em geral com alguma correlação entre si. Tradicionalmente associa-se à esta tecnologia a capacidade de algum tipo de interação. Por exemplo, um painel de vendas pode mudar para exibir os números por UF ao se clicar em um mapa do país.

A promessa dessa tecnologia é comunicar um volume maior de informações por meio de uma diagramação mais inteligente dos dados. Em outras palavras, um painel é a proverbial imagem que vale por mil palavras para a gestão da organização.

Análise Multidimensional

Uma ferramenta de análise multidimensional tem a capacidade de cruzar atributos em linhas e colunas, com os valores nas células resultantes desse cruzamento. Em comparação com uma ferramenta de relatório, uma ferramenta de análise multidimensional possui duas diferenças principais:

  • Exibir cabeçalhos tanto em linhas quanto em colunas, já mencionado;
  • Reorganizar a visão interativamente, com um tempo de espera mínimo.

Enquanto que ferramentas de relatórios estão limitadas a listas, que são renderizadas a partir de consultas, uma ferramenta de análise multidimensional pode criar planilhas, e respondem em segundos. Esse tipo de exploração de dados apóia processos de investigação de causa-raiz (ir de uma visão macro a uma visão micro, até achar a causa de um evento) e de entendimento de correlações entre os dados.

Se relatórios e painéis de dados sobressaem-se na apresentação dos dados, ferramentas de análises multidimensionais ajudam a descobrir o quê é interessante apresentar.

A sigla tradicional para análise multidimensional é OLAP, abreviação em inglês de Processamento Analítico On-Line.

Além da organização dos dados e da interatividade, ferramentas OLAP ainda oferecem controle sobre os níveis e o tipo de agregação. Por exemplo, podemos criar uma visão multidimensional mostrando, nas colunas, as UFs, e nas linhas os produtos. Cada célula dessa planilha indica, portanto, o total de venda de um certo produto numa certa UF. Podemos trocar UF por região, e a quantidade de colunas passará de 27 a 5. Mas também podemos manter a UF e fazer uma quebra por região, exibindo simultaneamente o UF e região para cada valor. Uma linha de células no topo (ou no fundo da planilha) pode, então, mostrar as agregações por região.

Data Mining

Esse pode ser considerado uma família de casos de uso mais do que um único CDU, cujo propósito genérico é apoiar o desenvolvimento de algum modelo matemático que “explique” os dados.

Ferramentas desta categoria costumam oferecer, entre outros recursos:

  • Estatísticas básicas: média, mediana, variância etc.;
  • Estatísticas avançadas: distribuições, ajustes de curvas, testes de regressão e hipóteses, por exemplo;
  • Análises sofisticadas, como Análise Baeysiana, clusterização, grafos, previsores como ARIMA e HoldWinters.

Ao contrário das outras ferramentas, as que implementam estes CDUs são voltadas para um público específico, dotado de habilidades específicas no tratamento de dados e construção de modelos empíricos. O nome corrente do profissional apto a aplicar este tipo de ferramenta é “cientista de dados”, mas já foi tratado por analista de data mining ou simplesmente “o estatístico”.

Os resultados de projetos para este caso de uso costumam se apresentar como algoritmos ou equações que, devidamente implementadas nos sistemas transacionais, podem operar decisões autônomas, sem supervisão humana. Um exemplo clássico dessa situação são as ofertas de crédito pré-aprovado exibidas por ATMs.

E o Pentaho?

A suite Pentaho implementa casos de uso de dados através de alguns casos de usos de ferramentas de dados.

O Pentaho oferece a possibilidade Monitorar, Reportar e Analisar dados.

Entre as ferramentas disponíveis na suite temos as capacidades de relatório (Report Designer), Painéis (BA Server) Análises Multidimensionais (Mondrian) e Data Mining (Weka.)

Cada CDU de ferramenta é implementada por um software específico. Cada CDU de dados é resultado da combinação de uma ou mais ferramentas, em geral com o BA Server no centro.

Conclusão

Os casos de uso de dados explicitam uma separação que eu fiz no primeiro post de 2016: o uso dos dados pode ser estratégico ou operacional. O CDU de Dados Análise é o único que realmente se encaixa em BI. Os outros dois podem consumir dados tanto de um DW quanto de bases transacionais, vivas. O CDU de Análise, não. A única forma de determinar a relação de causa e efeito é usando um DW e o Método Científico.

Olhando as demandas por dados que toda empresa experimenta através do ponto de vista de CDUs, podemos notar que a Suite Pentaho é uma solução completa, pois permite implementar todos os CDUs de dados através de todos os CDUs de ferramentas.

Mesmo que pareça o contrário, a intenção do post de hoje não era tecer loas ao Pentaho. Nunca escondi que sou fã da plataforma e se um dia eu decidir rasgar ceda para o Pentaho, eu o farei escancaradamente, sem pudores. Este post nasceu de um relatório que eu terminei hoje, que examinou a adequação de outra ferramenta, o [Spotfire][spotfire_bitly], à comunidade de usos e necessidades de certa empresa real. É justamente o fato de ser baseado em um relatório autêntico, de uma empresa real, que deu esse tom mais austero, mais academicista ao post. Espero que isso não espante vocês. Semana que vem volto ao modo galhofa de sempre. ;-)

Lamentavelmente para essa companhia, o Spotfire não possui uma adequabilidade tão grande às necessidades dela quanto outras ferramentas – como SAS e Pentaho – ainda mais em um patamar de custo benefício significativamente desvantajoso para o Spotfire.

Até a próxima. ;-)