A Nuvem Negra

Acabaram-se as férias! De volta ao trabalho!

Eu estava lendo um clássico de SciFi chamado The Black Cloud – sim, é daí que eu tirei o nome do post.

Este é uma daquelas histórias que deram a fama ao gênero: com cientistas e perigos intergalácticos, mas contada do ponto de vista da Humanidade, tal como nós a conhecemos. Eis um resumo: em 1963, um estudante de Astronomia detecta uma anomalia no céu [setentrional][setentrional_bitly]. Descobre-se, mais tarde, que essa “anomalia” é uma gigantesca nuvem de gás interestelar, deslocando-se a mais de 100 km/s (cem kilômetros por segundo! Conte 1… cem kilômetros!) em direção ao Sol. Essa nuvem provoca uma violenta catástrofe por aqui e, por muita, muita sorte, não destrói a Terra de uma vez. (Não vou dar spoiler! Leia, é do balacobado!)

Boa Ciência

Pouco depois do começo da história é formado um time de cientistas (físicos em sua imensa maioria) para estudar a Nuvem, a fim de orientar as decisões dos governos do mundo face à novidade. Eles prevêem um certo cenário, mas ele não acontece. Daí outro, e também a coisa não se passa como esperado, e mais um, e outro… Ou seja, erram um monte, pois a tal da Nuvem comportava-se de maneira “errada”. A certa altura, discutindo como interpretar um certo fenômeno impossível (mais um…), um dos cientistas solta o comentário:

Russo rosna...
Russo rosna…

Tradução “limpa”:

“Porcaria de Ciência ruim!”, rosnou Alexandrov. “Obter correlação após fato, Ciência de porcaria. Ciência só prever.”

Alxenadrov, como o nome sugere, é um russo, e por isso ele tem essa forma de expressão… crua, digamos assim. Ao “exclamar” esse comentário, ele contestava o debate, dizendo que adiantava nada achar uma explicação para os fatos. Se quisessem mesmo entender o que está acontecendo na Nuvem, era preciso testar essa explicação: se ela for capaz de prever o comportamento da Nuvem – que é o que mais interessava à eles – então você fez boa Ciência, gerou conhecimento e progrediu. Caso contrário, é uma explicação furada ou imperfeita e precisa ser revista ou melhorada.

Fazer o contrário, adotar uma explicação pós-fato e confiar nela porque explicou o que aconteceu, é o mesmo que apostar numa corrida de cavalos que já acabou (falam exatamente isso para explicar os termos do Alexandrov para as personagens não-cientistas.) Vem daí o “bloody science” do russo, que a educação manda traduzir por porcaria, mas que é melhor representada por outra palavra, também começada com P. :-)

E o que isso tem a ver com BI? Por que esse assunto tão nada a ver logo no começo do ano?

Já, já chego nisso. Antes, uma pequena revisão.

Inteligência de Negócios

No post Paz, Afinal III, eu defini BI pela última vez na minha vida com essa frase:


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


Revendo, acho dá para simplificar:


BI é o uso do Método Científico por uma organização para melhorar sua administração.


Daí, seguindo nesta trilha, no post Full Metal BI Itch eu desenvolvi o argumento de como a aplicação do Método Científico aos dados de uma empresa produzem valor. Eis o trecho relevante:


(…) E se você pudesse voltar um ano? O que faria? Mandaria alguém embora? Cancelaria uma venda ou faria mais pedidos de matéria-prima? Ou faria tudo igual, de novo?

Você há de concordar comigo que, se pudesse mesmo voltar um ano, muito provavelmente faria alguma coisa diferente. Duvido que você não tenha um único arrependimento sequer. Não? Mesmo? E o dólar?

(…) Se pudesse voltar um ano, saberia quando comprar e vender moeda estrangeira e faria uma grana fácil!

Curiosamente, esse poder de “prever o futuro” existe hoje, mas raros usam-no. Quem dá a uma empresa o poder de prever o futuro é justamente Data Mining, em particular, e Inteligência de Negócios, em geral!

Claro que não é possível prever, com exatidão, o valor que o dólar vai ter amanhã, ou semana que vem, ou… Não se trata disso. Se trata de, sabendo como um negócio funciona, bolar uma equação matemática – um modelo matemático – que ajude a calcular as chances de determinadas situações acontecerem.

Daí, baseados nesse modelo, que é a informação tirada dos dados, podemos tomar decisões com chances melhors de sucesso. Evidentemente não é uma decisão garantida, mas entre optar por um caminho ao invés de outro por pura intuição, ou fazer uma escolha embasado no que já aconteceu, obviamente preferimos apostar no que já vimos acontecer. (…)


Resumindo: BI é a aplicação do Método Científico para, a partir da observação de eventos passados, tentar prever (=tomar a melhor decisão) o que vai acontecer.

BI & Ciência

Acho que a relação entre a exclamação do Alexandrov e BI ficou evidente: são a mesma coisa.

Para que iríamos querer olhar os dados que já são passado? Apenas para explicar porque algo aconteceu como aconteceu? Seria muito estéril aplicar tanto esforço por um consolo intelectual.


Ah, fracassamos porque nossa taxa de falhas nos itens da linha de produção número um eram superiores a 1 em 10.000… Que peninha…


Claro que não é para entender, só entender! É para entender o quê levou as coisas a serem como foram, e então evitar que o mesmo problema se repita! Ou que as mesmas oportunidades sejam perdidas! Ou, ou, ou…

Alexandrov colocou de uma forma muito simples, clara e, bom, elegante (numa forma russa de ser, hehe) de se explicar o propósito do ramo da Inteligência de Negócios: fazer boa Ciência (com os dados da empresa!)

Uma Nuvem Negra

Na história, a certa altura, a Terra começa superaquecer (levando à morte milhões de pessoas) porque a Nuvem refletia o Sol e, ao chegar mais perto, mandava mais calor para a Terra.

Depois, quando a nuvem chega, ela obscurece o Sol, e a Terra cai em um inverno profundo, intenso, no qual outros milhões morrem.

IMHO, esses trechos da história também ecoam a realidade da indústria de BI.

Visto de longe, chegando, toda tecnologia associada ao jargão Business Intelligence, parece brilhar com luz própria, anunciando um futuro iluminado, onde nenhuma sombra será vista pairando sobre nosso conhecimento! A chegada das ferramentas de BI na sua organização trará uma nova era de conhecimento, rico e valioso conhecimento!

… Até que tudo é instalado e posto a funcionar e, pouco tempo depois, em muitos dos casos, tudo não parece mais tão claro. Não vou querer esticar esse paralelo ao ponto de dizer que todo projeto de BI acaba em mortes de milhões de inocentes, mas sim, quem já passou por um projeto desses sabe que o mundo real acaba sendo mais sombrio e complicado que a expectativa.

Se já é difícil fazer boa Ciência, imagine em um ambiente que não permite experimentos, como uma empresa.

O truque – que, me parece, cada um precisa aprender sozinho – é saber navegar o dia-a-dia da organização, atingindo expectativas, com um olho no futuro e outro no passado. Até mesmo por isso é que BI é um apoio para a estratégia da empresa. (O que me leva mais uma vez ao argumento contra BI em tempo real. Mas estou digredindo, vamos voltar.)

Bloody Conclusion

Ah, ano novo! Tantos clichês, tão pouco espaço… :-)

Eu queria que o primeiro post do ano trouxesse algo mais fundamental, mais na raiz do sucesso de projetos de BI, seja você da área de negócios ou TI. E, sucesso, é ajudar a organização a crescer e se manter.

BI é valioso. BI cria valor para a organização, e por valor eu quero dizer dinheiro, seja aumentando o faturamento, seja reduzindo custos ou melhorando a produtividade.

Se você quer que sua organização viceje e floresça, então você precisa aplicar o que os dados ensinam. A cultura de BI que experimentamos hoje, tal qual uma nuvem, suaviza os contornos da realidade e dá muita relevância às ferramentas, tendendo a deixar de lado o aspecto científico (=do conhecimento.), que é justamente o como as análises criam valor. E o mais complicado dessa situação é que ela não é óbvia. É preciso dar um passo para trás e tentar ver a bloody big picture para apreender como o conhecimento gerado pela análise de dados está sendo reinjetado na empresa, para melhorar seus resultados.

Quando aplicam-se conclusões que explicaram o passado, mas não foram testadas contra o futuro, BI falha em criar valor e, não raro, pode destruir valor na organização. Esse é o cuidado que temos que ter. Esforce-se em aprender a transformar o conhecimento em valor, através do estudo dos dados.

Isso, bloody comrade, é que é bloody BI. Bloody 2017 para todos nós! :-)

As Soluções Clássicas

Se você pudesse olhar para frente no tempo, para o futuro, o que iria querer ver?

Vamos deixar de lado coisas como “números da megasena”, “resultados de jogos de futebol” e outras opções pessoais, e focar apenas no seu lado profissional. Se seu trabalho fosse aumentar a lucratividade da sua organização, e você pudesse olhar o futuro, o que você iria querer ver?


Encare “lucratividade” como uma métrica de sucesso da organização – entregar mais por menos. Para uma fábrica é vender mais com um custo menor, para um hospital é atender mais gente gastando menos tempo e/ou dinheiro, para o governo é entregar o prometido dentro do prazo ao menor custo possível e assim por diante.


O preço do dólar? A demanda por laranjas? O valor das ações na Bolsa de Valores?

Primeira Lei de Newton

Talvez você não se dê conta, mas passamos o dia inteiro olhando para o futuro. Exemplos? Aos borbotões!

  • Saímos de casa pensando em fazer o mesmo caminho que fizemos ontem porque ontem funcionou;
  • Ou então planejamos um caminho diferente, porque ontem o de sempre estava ruim;
  • Assistimos jornal na TV sempre no mesmo horário, porque desde sempre aquele foi o horário do jornal;
  • Agendamos compromissos, fiando-nos em uma expectativa de que nada vai mudar de uma hora para outra;
  • Planejamos festas de aniversário mesmo sem saber se estaremos vivos daqui à pouco (uga, essa foi forte, sorry;)
  • Estudamos a matéria vista ontem para prova amanhã porque temos fortes motivos para acreditar que a prova vai discorrer sobre aquela matéria e não outra – mesmo nunca tendo enfrentado uma prova daquelas.

Eu poderia fazer isso o dia inteiro, mas acredito que já reforcei a idéia: se nada aparecer para mudar a rotina, a rotina continuará como sempre foi. Algo como a Primeira Lei de Newton, aplicada à nossa vida diária.


Primeira Lei de Newton: Todo corpo continua em seu estado de repouso ou de movimento uniforme em uma linha reta, a menos que seja forçado a mudar aquele estado por forças aplicadas sobre ele.


Agimos intuitivamente em relação ao futuro. Procuramos indícios, pistas, sobre como as coisas serão daqui a uma hora, a um mês. Olhamos para o céu para estimar a chance de chover quando estivermos andando na rua, olhamos o Waze para tentar saber se vamos nos atrasar ou não.

A parte curiosa disso é que não estamos, de fato, olhando para o futuro, mas sim avaliando a tendência atual e calculando onde estaremos se essa mesma tendência se mantiver. (Não precisamos parar por aí: podemos fazer uma análise da tendência que a tendência tem de mudar – chamamos de aproximação de segunda ordem. E depois de terceira ordem – tendência de mudar da tendência de tendência da mudança – quarta etc. etc. etc.)

Você está sentado na sua mesa de trabalho? Pode ver a empresa de onde está? Então olhe a seu redor. Consegue enxergar os pedidos chegando, as entregas saindo? Consegue ver o movimento que está fazendo essa organização na qual você trabalha? Claro que não: sua empresa se move em um plano invisível a olhos nús, o plano dos dados. Você pode até aprender a associar a entrada e saída de pessoas e veículos, o toque dos telefones e outros sinais à atividade da empresa, mas isso não seria nada além de um reflexo do que acontece de verdade.

Talvez não seja possível ver a empresa funcionando, mas se pudermos coletar os dados que fluem por ela, conseguiremos enxergar seus movimentos.

Dados são a nova realidade.
Dados são a nova realidade.

Seguindo na mesma linha da intuição com o dia-a-dia, entendendo o movimento dos dados podemos estimar a chance de algum evento ocorrer: ganhar ou perder uma venda, receber um chamado de manutenção, um equipamento apresentar falha.

Se o nosso dia-a-dia é resolvido, algo automaticamente, pelo nosso cérebro, como resolver o “dia-a-dia dos dados”?

Ciência & Futuro

Bom, o fato é que a resposta para essa questão já existe, e a vimos na escola: são as tais das “teorias”. Uma teoria é um conjunto de conhecimentos que explicam algo, e por explicar queremos dizer “prever um determinado resultado a partir de uma certa entrada”.

Um exemplo pode ajudar a entender o que eu quero dizer: o que acontece se você jogar alguma coisa para cima? Resposta: cai de volta (na sua cara, se você não tomar cuidado.) A repetição desse experimento várias e várias vezes nos dá uma certa segurança para afirmar que “coisas jogadas para cima, caem”. Essa é uma Teoria, que explica o que acontece com as coisas quando são jogadas para cima. Ela foi criada a partir da nossa observação. Usando essa teoria podemos prever o que vai acontecer se você jogar um sofá, uma bola ou uma vaca para cima: vão cair de volta.

Podemos sofisticar nossa Teoria de Coisas que Caem mais e mais, ao ponto de dizermos com que velocidade as coisas vão cair de volta, que distância vão percorrer e assim por diante. Podemos continuar fazendo experimentos e testando nossa teoria, chegando a formas cada vez mais genéricas.

O exemplo que começamos acima termina assim: Sir Isaac Newton estabeleceu uma lei chamada Lei da Gravitação Universal, que diz como qualquer coisa cai em relação a qualquer outra coisa, em qualquer lugar do Universo conhecido. Ei-la:

Lei da Gravitação Universal.
Lei da Gravitação Universal.

Lei da Gravitação Universal: Duas partículas quaisquer do Universo se atraem por meio de uma força na direção que atravessa seus centros de massa, diretamente proporcional ao produto de suas massas e inversamente proporcional ao quadrado da distância que as separa.

Através dessa equação podemos conhecer a força que age sobre quaisquer duas partículas. Usando a Segunda Lei de Newton, a famosa F = m.a, podemos calcular a aceleração que essas partículas sofrem. Com isso e a equação da posição de um corpo em função da velocidade e aceleração (S = S0 + V0.t + a.t^2/2 – conhece essa?) podemos determinar exatamente onde um corpo vai estar a partir de um momento inicial, desde que S0 e V0 sejam conhecidos.

Dadas as condições iniciais de dois corpos no Universo, em um dado momento, as Leis de Newton e a Lei da Gravitação Universal nos permitirão saber onde elas estarão, em um tempo futuro.

Estamos prevendo o futuro? Não, estamos apenas acompanhando a evolução da realidade com o que conhecemos a respeito de seu funcionamento. É como se a Ciência nos desse uma janela para o futuro, ainda que seja apenas a extrapolação do passado.

Data Mining & Negócios

Uma forma de descrever tudo isso é dizer que as leis criadas por Newton oferecem um modelo de interpretação do Universo. Todas as equações citadas formam um modelo matemático, que pode ser usado para extrapolar o presente para algum tempo no futuro.


Só para não deixar pontas penduradas: todas essas leis e teorias são conhecidas pelo nome coletivo de Mecânica Clássica. Dizemos, então, que a Mecânica Clássica é um modelo que explica a nossa realidade cotidiana.


Bom, e se pudéssemos fazer o mesmo com os dados da nossa empresa, da nossa organização? E se pudéssemos olhar para nossos dados passados e tirar deles uma relação matemática? Então poderíamos usar essa relação para estimar o que vai acontecer no futuro!

É exatamente isso que faz Data Mining: busca um padrão – um modelo matemático – nos dados.

Sabe aquela coisa de BI é para trás, BA é para frente? Bullshit. Data Mining é Inteligência de Negócios no seu máximo!

Voltando à nossa pergunta inicial, se você fosse responsável por uma empresa, e pudesse ver o futuro, o que você iria querer ver?

As Soluções Clássicas

Estamos em 2016. Faz quase cinquenta anos que o conceito de Armazém de Dados está por aí, outro tanto de anos para BI, e séculos que a Ciência, tal como a conhecemos, existe. Temos centenas e centenas de anos de técnicas, métodos, teorias e ferramentas para explorar a realidade ao nosso redor e tentar extrair dela o mecanismo que está por trás da Natureza.

Mais ainda: não é de hoje que tentamos analisar os dados de nossas organizações em busca de estimativas mais seguras do que vai acontecer. Desde que a primeira empresa coletou dados pela primeira vez, alguém tentou analisá-los para extrair vantagem de negócio (siga aquele link: aquela história é de 1865.) Temos décadas, minto, temos mais de um século (1911) de investidas formais nesse campo.

E o que é que já existe?

Este post inaugura uma nova série do GeekBI, na qual serão apresentadas as soluções de Business Intelligence hoje tidas como “clássicas”. De início eu planejei os seguintes posts:

  • CRM
  • Churn Detection
  • Credit Scoring
  • Atuarial
  • Supply Chain
  • Fraude
  • Risco

Tem alguma solução que você gostaria de conhecer? Deixe sua sugestão na área de comentários!


Todos esses casos são baseados em práticas do mercado de Data Mining e conhecimento comum de consultorias da área. Para não ficar só na teoria, no abstrato, eu vou buscar detalhes mais concretos com os maiores especialistas em BI e Data Mining do mundo, o SAS e tentar tornar tudo mais palpável.

Visão geral das soluções de BI do SAS.
Visão geral das soluções de BI do SAS.

Até a próxima!

Ué, Cadê o Perry?

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

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

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

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

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

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

Arquitetura Típica de EDW

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

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

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

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

Ué, Cadê o SGBDR?

Colocando em uma figurinha simples, temos:

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

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

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

Conclusão

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

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

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

É isso. ;-)

Introdução à Data Vault

Toda empresa que deseja usufruir das vantagens que projetos de Inteligência de Negócios trazem (como incremento de lucros), precisa investir concomitantemente em Armazéns de Dados.

O primeiro passo é decidir o que se deseja: oferecer relatórios, análises, uma solução do tipo CRM ou Churn etc. Essa escolha vai determinar quais dados são necessários. Esses dados devem ser levados para um Armazéns de Dados (ou DW, do inglês Data Warehouse)  antes de ser consumidos pelo projeto de BI.

Armazéns de Dados são bancos de dados, em qualquer tecnologia, que acumulam os dados da empresa. Um DW, em princípio, acumula todos os dados que a empresa julgar importantes hoje, como aqueles necessários para o projeto de BI, ou acreditar que possam vir a ser importantes no futuro. Os dados são armazenados no DW em sua menor granularidade, para que qualquer pergunta possa ser respondida.

Cada solução de BI implantada na empresa consome dados em formatos específicos. Por exemplo, relatórios e análises OLAP funcionam melhor se os dados estiverem organizados em um Modelo Dimensional. Já uma solução de CRM consome dados em formato “tabelão”, que são adequados a Data Mining. Painéis podem usar os dados de uma estrela dimensional, mas eventualmente pode ser mais producente usar tabelas especiais – simplificam a lógica nos painéis e tendem a reduzir o consumo de hardware. E assim por diante.

Observe sua vida: você usa uma só máquina para tudo? O seu carro passa fax? O seu fax corta grama? O seu barbeador bate bolo? Não, claro. (Caso sua resposta para uma destas perguntas seja sim, entre em contato comigo – vamos ficar ricos!!)

Da mesma forma que no mundo real, o mundo informatizado também usa programas e tecnologias específicas: banco de dados não serve HTTP, Java armazena dados, PHP não oferece cubos OLAP.

Armazéns de Dados não servem para consultas – servem para armazenar dados. Logo, o primeiro erro que precisamos evitar é “one size fits all”: uma tecnologia desenvolvida para resolver um problema não serve para resolver qualquer problema, muito menos todos.

Data Vault

Uma tradução livre do termo é Cofre de Dados: uma tecnologia adequada a acumular dados ao longo do tempo. A partir deste repositório de dados, outros projetos podem se servir do que precisar.

A idéia central de se ter um Data Vault é dispor de um repositório que receba e organize os dados de múltiplas fontes, de tal forma que seja muito fácil incluir ou remover fontes, sem quebrar o repositório e sem virar um pesadelo de manutenção. A partir daí, cada projeto de BI busca do DV os dados que precisa e grava-os em outros repositórios de dados, no formato que precisar.

Apesar de soar como uma camada desnecessária, aparentemente dobrando o esforço (com DV precisamos de dois ETLs no mínimo – um para dentro e outro para fora do DV), adotar um Data Vault reduz o trabalho porque torna o crescimento do DV algo semi-automático, e a criação de fontes secundárias algo padronizado.

Veremos a seguir um DV: seus componentes e como um é modelado. Tudo que será visto pode ser encontrado nos livros abaixo:

Beltrano S/A

Para os exemplos vamos usar o diagrama de dados do banco transacional da Beltrano S/A:

Modelo E-R da aplicação transacional.
Modelo E-R da aplicação transacional.

Leia este link para todos os detalhes sobre a base.

O Modelo de Dados

Um DV tem três componentes básicos:

  1. Hub
  2. Link
  3. Satélite

E mais algumas tabelas acessórias:

  1. Point-In-Time (PIT)
  2. Same-As
  3. Tabelas “dicionário”

Não vou entrar no detalhe das tabelas acessórias, pois elas resolvem problemas específicos que não são necessários para entender o mecanismo geral.

Hub

Hubs são tabelas que guardam conceitos, ou chaves, de negócios. Uma chave de negócio é um conceito importante para a empresa: cliente, produto, pedido, posição no call center, empregado, etc.

Tabelas hub possuem as seguintes colunas, nem uma a mais nem a menos:

  1. Business Key: chave primária, um inteiro sequencial;
  2. Load Date/Timestamp: data e hora da inserção do registro;
  3. Record Source: fonte da chave de negócios;
  4. Source business key: chave de negócio no sistema de origem.
DV Beltrano S/A: hub Empregados.
DV Beltrano S/A: hub Empregados.

Não há grandes segredos aqui: tabelas hubs acumulam as chaves de negócio, que são a espinha dorsal dos dados. A chave primária é a BK. A cada carga insere-se apenas as novas chaves de negócio dos sistemas de origem. Se a chave já existe, nada é feito. Se a mesma chave existe em vários sistemas, apenas a primeira que chegar é inserida.

Se a mesma chave existe em vários sistemas, com os mesmos valores, essa tabela automaticamente integra esses sistemas. Por outro lado, se a mesma chave existe em sistemas diferentes, mas com valores diferentes diferentes, então elas devem ser carregadas em hubs separados por sistema. A integração é feita por uma tabela do tipo Same-As entre cada hub.

Eventualmente a chave de negócio no sistema de origem podem ser uma chave composta (ter mais de uma coluna), mas nunca podemos montar como chave de negócio as colunas 3 e 4.

Link

Links tão tabelas que guardam o relacionamento entre dois hubs.

Uma tabelas link que relaciona os hubs 1, 2, … , n possuem as seguintes colunas, nem mais, nem menos:

  1. Link Key: chave primária, um inteiro sequencial;
  2. Load Date/Timestamp: data e hora da inserção do registro;
  3. Record Source: fonte do relacionamento;
  4. BK1: business key do hub 1;
  5. BK2: business key do hub 2;
  6. BKn: business key do hub n.
DV Beltrano S/A: link Empregados-Pedidos.
DV Beltrano S/A: link Empregados-Pedidos.

Uma tabela link mantém relacionamentos M para M entre os hubs. Elas não dizem nada sobre a validade desse relacionamento, mas apenas que ele foi detectado no sistema de origem. Uma tabela link pode manter auto-relacionamentos também: um hub empregado, quando um empregado é chefe do outro, usa uma tabela link para registrar o relacionamento pai-filho entre os empregados.

Ela também não sofre atualização: novos relacionamentos são inseridos, antigos são descartados. Se um relacionamento já registrado não é mais detectado, ele não é apagado.

Satélite

Satélites são como tabelas de dimensão: guardam os contextos de hubs e links.

Uma tabelas satélite de um hub/link que guarda os atributos A1, A2, …, An de um hub/link X possui as seguintes colunas, nem mais, nem menos:

  1. Business Key/Link key: chave primária do hub/link
  2. Load Date/Timestamp: data e hora da inserção do registro;
  3. Load End Date/Timestamp: data e hora do fim da validade daquele registro (default é NULO);
  4. Record Source: fonte dos atributos;
  5. A1: atributo 1;
  6. A2: atributo 2;
  7. An: atributo n.
DV Beltrano S/A: satélite Empregados.
DV Beltrano S/A: satélite Empregados.

Ao contrário do hub e link, o satélite não tem uma chave primária própria. Ao invés disso a chave primária é composta pelas colunas 1 e 2 (BK/LK + LDTS.)

De novo ao contrário dos hubs/links, os registros de um satélite possuem validade: a cada carga o processo verifica se os registros do satélite ainda existem na origem. Se não existirem mais, eles recebem um date/timestamp atual na coluna 3 (LEDTS.) A cada carga os satélites mudam e desta forma acumulam histórico do sistema.

DV Beltrano S/A: satélite do link Empregados-Pedidos, que guarda a validade do link.
DV Beltrano S/A: satélite do link Empregados-Pedidos, que guarda a validade do link.

Os atributos de uma chave de negócio ou relacionamento não precisam estar totalmente contidos em uma única tabela: se os atributos variam em taxas diferentes (como quando alguns mudam todos os dias, enquanto outros apenas de vez em quando), eles podem ser gravados em tabelas diferentes.

Quando um mesmo conceito de negócio existe em dois sistemas, criamos um satélite para cada sistema, com cargas independentes.

Corpo

Hubs são conceitos de negócios, links relacionam estes conceitos entre si e os satélites dão o contexto dessas chaves e relacionamentos.

DV Beltrano S/A: modelo captura que empregado fez que pedido.
DV Beltrano S/A: modelo captura que empregado fez que pedido.

Se compararmos um DV a um corpo humano, os hubs são como ossos, formando um esqueleto, links são ligamentos que unem os ossos e satélites são todos os músculos, orgãos e pele que recobre o esqueleto, dando-lhe forma.

Ah! Existe um código de cores: hubs são azuis, links vermelhos e satélites são amarelos.

As Vantagens de um Data Vault

Um DV oferece três vantagens:

  1. Estabilidade e Isolação
  2. Repetibilidade
  3. Performance

Estabilidade

Basta deter-se um pouco sobre essas explicações e perceber que, se a empresa não muda constantemente de ramo, seus conceitos de negócios são relativamente estáveis. Ou seja, mesmo que a empresa mude a forma como ela processa sua vida diária, poucos conceitos de negócio vão nascer ou sumir ao longo do tempo. Mesmo assim, um novo conceito de negócio é imediatamente associado a um novo hub. A implementação desse novo hub não afeta os que já existem – o impacto por uma novidade em termos de conceito de negócio é zero.

Os relaciomentos entre dois conceitos também são, via de regra, estáveis. Pense em produto e fornecedor: podem surgir novos fornecedores (inseridos num hub “fornecedor”), com novos produtos (inseridos num hub “produto”), ou mesmo novos produtos de um fornecedor já existente. Quando isso acontece, o próprio processo de carga se encarrega de anotar esse relaciomento, automaticamente. Se um novo relacionamento é descoberto, porém, o impacto no DV é zero: basta criar a nova tabela link e produzir o código de carga dela. Nenhuma outra tabela do DV é afetada. Ah, e se um relacionamento “morrer”, basta desativar a carga para ele, e para seus satélites – sem NENHUM impacto no restante do Cofre de Dados.

Já os satélites, que são naturalmente mais voláteis, podem mudar de forma com certa frequência. Digamos que, hoje, o DV coleta todos os hipotéticos atributos do cliente. Algo acontece – inventam um novo tipo de e-mail – e passamos a registrar, no sistema de origem, mais esse atributo. Qual é o impacto disso no DV? A resposta é “depende”:

  1. O caminho mais fácil é simplesmente criar um novo satélite com apenas esse atributo e instalar o novo processo de carga para ele. Impacto zero, mas o custo de recuperar essa informação depois pode ficar muito alto, especialmente se formos preguiçosos o tempo todo. A título de curiosidade, essa abordagem leva a uma coisa chamada Anchor Modeling;
  2. O segundo caminho mais fácil é estancar o satélite atual, mudando seu nome para alguma coisa _ate_data-X,  e criar um novo satélite com o novo atributo, e passar a carregá-lo daí em diante. É uma técnica mais interessante em situações que mais do que um par e tal de novis atributos precisam ser capturados. A derivação dos dados para as fontes secundárias precisa levar em conta as diversas versões da tabela, mas o impacto no DV é próximo a zero;
  3. Finalmente podemos simplesmente aumentar o satélite atual em uma coluna e atualizar a carga dele para levar esse novo atributo. A vantagem é que você mantém o mesmo número de tabelas que existia antes, mas agora seu processo de extração pós-DV precisa saber que esse atributo não vão existir em todas as versões de cada registro do satélite. Impacto para o DV: próximo a zero também.

Repare que o DV tem um impacto na sua atualização, mas esse impacto não se propaga para fora dele: em qualquer um dos casos listados acima, a extração de dados do DV para fontes de dados secundárias não sofre NENHUMA alteração. Mesmo nas opções que mudam as tabelas dos satélites (é indiferente o que acontece aos hubs e links), as alterações vão de nada (ignorar a nova tabela/coluna) a pouca (mudar o nome de uma tabela.)

Veja que se queremos que o novo atributo “saia” para as fontes secundárias, então o impacto vai ser maior.

Lido ao contrário fica:

A incorporação de novas fontes de dados ao Data Vault não perturba os processos de carga das fontes de dados derivadas: o DV pode ser evoluído com um impacto próximo ao desprezível para a carga dos data marts dimensionais, tabelas de painéis etc.

Isolação

Isso é perfeito para DWs que servem mais de um departamento (praticamente todos): mudanças requeridas por um departamento tem impacto desprezível a nulo nos produtos de BI de outros departamentos.

Repetibilidade

Um Cofre de Dados é montado com “pedaços” (tabelas) padronizados. Cada tipo de pedaço – hub, link ou satélite – segue um modelo (um template ou gabarito) e tem um processo de carga idêntico. Para cada nova tabela mudam-se coisas como chaves de negócio ou atributos, mas o processo em si, de desenhar o DV e seu ETL, é 100% repetitivo. Isso significa que criar um novo hub/link/satélite e seu processo de carga é o mesmo que copiar um outro elemento do mesmo tipo já pronto, e mudar os nomes das colunas e tabelas.

Em outras palavras:

O layout das tabelas e o processo de ETL para um Data Vault é 100% baseado em templates. A geração do processo de ETL pode ser automatizada ao ponto de um novo hub/link/satélite poder ser incluído no modelo e colocado em produção em menos de uma hora.

O tempo acima não é um chute: eu brinquei com um sistema real e descobri que consigo criar um hub em menos de 15 minutos, um link em menos de 20 e um satélite em menos de uma hora. O satélite leva muito mais tempo porque tem um número variável de colunas, e isso dá um trabalho extra para testar (a criação mesmo, de todos, é de cinco minutos – o resto é tempo desenho para saber que colunas usar e testar o resultado.)

Performance

O conceito de Data Vault foi feito tendo em mente a idéia de se aproveitar de capacidades de processamento paralelo massivo – MPP. Graças à sua arquiteturua, cada tipo de elemento de um DV podem ser carregados 100% em paralelo: podemos carregar todos os hubs ao mesmo tempo, todos os links ao mesmo tempo e todos os satélites ao mesmo tempo.

Graças a bancos de dados capazes de se espalhar em diversos servidores, e programas de ETL como o Pentaho Data Integration que pode escalonar elasticamente por inúmeras máquinas, o gargalo de carga de um Data Vault passa a ser a própria velocidade de rede e computadores – melhorando esses, reduzimos o tempo de carga

Data Vault 2.0 & BigData

Tudo que este post aborda vem da especificação 1.0 do Data Vault. A especificação do DV 2.0 troca as chaves sequenciais por hashes, o que permite carregar 100% dos elementos em paralelo. Graças à eliminação da dependência de um campo sequencial, um DV 2.0 é adequado para criar DWs diretamente em clusters Hadoop.

A Regra de Ouro do Data Vault

Daniel Linstedt define como a regra de ouro do DV

Carregar 100% dos dados, 100% das vezes

Ele diz, nas apresentações, que chega de chamadas do Centro de Dados de madrugada, avisando que a carga do DW parou. Chega de perder o sono por falhas causadas por dados mal-formatados. Um DV carrega tudo, da forma que vier. Como diz o cowboy, “eu carrego antes e limpo depois”. Bam! Bam! :-)

Conclusão

Sólidos projetos de BI de qualidade constroem-se sobre Armazém de Dados. A melhor tecnologia para construção de um DW é aquela que reduz seu custo e tempo de desenvolvimento, reduz retrabalho e aumenta sua performance.

Data Vault é um modelo de dados criado por Daniel Linstedt em 2000 que atende a todas essas necessidades. A versão 2.0 da especificação traz melhorias que permitem construir um DW diretamente em um cluster Hadoop e com isso baratear ainda mais o processo e a infraestrutura, enquanto aumenta sua performance.

Um Data Vault é o ponto final de um DW, mas um DW é só o ponto de partida para projetos de BI, que devem extrair seus dados do DW, no formato que desejarem, como bem entenderem.

É isso.

M.I.N.A.

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

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

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

Manifesto Ágil

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

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

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

Manifesto de Inteligência de Negócios Ágil

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

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

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

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

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

Conclusão

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

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

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

O que você acha?

O Que Leva à Alta Performance?

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

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

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

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

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

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

Como Escolher uma Estratégia?

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

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

Como Executar a Estratégia?

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

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

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

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

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

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

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

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

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

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

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

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

Juntando à conclusão do post anterior:

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

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

Lavando Louça (ou Paz, Afinal III)

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

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

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

Try to See the Truth:

There Is No Spoon.

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

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

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

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

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

Simplesmente

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

Porque simplesmente faz sentido.

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

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

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

Simplesmente:

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

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

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

Até a próxima.


 

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

A Pirâmide (Invertida) do Conhecimento dos Negócios

Hoje eu vi num post do BI na Prática, do Diego Elias, algo que há um bom tempo eu não encontrava: uma discussão sobre o relacionamento dados-conhecimento. Ele usa uma pirâmide para mostrar esse relacionamento, com os dados crús na base e conhecimento no topo, sugerindo que para muitos dados crús, temos um volume de conhecimento proporcionalmente menor. Concordo com essa escala de valores: se você sabe mil fatos a respeito de um cliente, você sabe uma coisa sobre ele – fez mil pedidos, hehe. Brincadeirinha: eu queria dizer que com milhares ou milhões de fatos sobre um cliente ou produto, você extrai um volume pequeno de conhecimento, como algumas coisas sobre o hábitos do cliente ou a sazonalidade das vendas de um produto. Muitos e muitos fatos -> algumas informações.

O galho com essa escala é que ela induz a comparação de laranjas com maçãs.

Eu trabalhei um tempo no SAS, há mais de dez anos, e eles usavam uma pirêmide invertida para tratar do assunto. Ela tinha (praticamente) os mesmos labels que a pirâmide do Diego, com uma diferença legal: a escala é de conhecimento, de cima a baixo.

A pirâmide de relacionamento de dados crús ao conhecimento. O conhecimento aumenta conforme trabalhamos os dados crús.
A pirâmide de relacionamento de dados crús ao conhecimento. O conhecimento aumenta conforme trabalhamos os dados crús.

Nesse caso, o conhecimento começa pequeno e termina grande, independentemente da quantidade de registros em bancos de dados. Percebem? Ao invés de quantificarmos o número de registros (milhares ou milhões de pedidos contra uma informação sobre os clientes), quantificamos a informação obtida. Na ponta inferior da pirâmide, na qual temos os dados crús, a informação é pequena. A quantidade de pedidos de um cliente, por exemplo, nos diz apenas que esse cliente fez X pedidos – nada sobre seu perfil ou sobre seu lifetime value.

No nível seguinte já temos alguma informação – podemos ver a sazonalidade da interação do cliente com a empresa, podemos analisar a vazão das linhas de produção ou a lucratividade de nossos produtos ao longo do tempo.

Finalmente, no último nível, aplicamos nosso conhecimento sobre o negócio e geramos a informação tal como ela pode ser aproveitada para as estratégias da empresa. Coisas como “dado o que sabemos, o que vai acontecer?” ou “quem mirar para obter o maior retorno?” e assim por diante. Esse conhecimento sobre o negócio é gerado pelas soluções de Inteligência de Negócio, coisas que vão muito além do relatório ou do dashboard.

Podemos traduzir essa figura por outra, indicando claramente alguns dos exemplos famosos de BI:

Pirâmide completa, com exemplos de soluções de BI que geram conhecimento sobre o negócio.
Pirâmide completa, com exemplos de soluções de BI que geram conhecimento sobre o negócio.

Assim a solução de CRM dá informações sobre o cliente, SCM ajuda a incrementar o valor agregado na cadeia de fornecimento e Riscos mostra quais existem e como eles impactam os cenários de negócios.

E é isso. Kudos ao Diego por retomar uma discussão valiosa, e que por algum tempo esteve escanteada.

A Vantagem do Visual

Recebi o pedido de um post:

Fábio, você poderia fazer um post sobre sua experiência no pentaho referente a performance? Desenvolvo um projeto onde eu prefiro realizar todas as transformações via query e percebi que você utiliza os componentes do pentaho para fazer o mesmo. Como tenho poucos dados de testes quando vou testar a performance de ambos acaba dando quase o mesmo resultado em questão de tempo.

E é claro que eu vou atender. ;-)

Comparar ou Não Comparar, Eis a Questão

Suponha que eu escolha, como um exemplo para medir essa performance, copiar uma tabela para outra, no mesmo banco:

  • A query ganharia, já que nada bate uma cópia interna, de uma tabela para outra, dentro do mesmo banco.
  • Se a cópia fosse entre dois bancos diferentes, na mesma máquina, ainda seria muito rápido, mas acho que precisaria apelar para uma linguagem do banco, ou algum recurso não-padrão para que o SELECT em um banco sirva de entrada para o INTO em outro. Imagino que a consulta ainda bateria o PDI.
  • Agora, se a cópia fosse entre duas máquinas diferentes, talvez houvesse um empate porque a rede entre as máquinas passaria a ser um gargalo. Como os dois recursos (query e PDI) normalmente são muito mais rápido que a maioria das redes, a velocidade final seria limitada pela velocidade da rede, e daria empate.

Se eu escolhesse ler um arquivo e carregar no banco, os fatores envolvidos seriam outros e os resultados desse caso não teriam nenhuma relação com os resultados do caso anterior, da cópia entre duas tabelas. Se fosse um join, outro resultado. Se fosse um lookup em banco a partir de um arquivo, outro resultado. Etc. etc. etc. e assim por diante.

Ou seja, os resultados de uma comparação desse tipo seriam inconclusivos, pois oscilariam entre vantagem ora de um método, ora de outro.

Vendo Vantagem

Então tanto faz? A performance, na média, vai ser sempre a mesma para qualquer tecnologia?

Nem de longe. A comparação direta de performance entre as duas técnicas (PDI e SQL) pode ser uma medida muito difícil, mas não deve ser importante para optar por uma ou por outra. O que deve nortear sua escolha é, como sempre, o custo-benefício.

Se as suas transformações só envolvem bancos de dados, todos do mesmo tipo, pode ser que seja mais fácil desenvolvê-las usando SQL – já está tudo ali mesmo, e rodar SQLs diretamente no banco pode dar muito menos trabalho que baixar o PDI, configurar uma máquina, desenvolver as transformações e agendâ-las em produção.

Se o seu processo envolve arquivos (talvez em um servidor remoto), bancos (de diversos tipos), uma área de transferência temporária (palco ou stage) etc. etc. etc., desenvolvê-lo usando SQL pode ser tão complexo quanto construir uma nova aplicação do zero. Num caso desses, usar o PDI pode até redundar na mesma performance, mas o desenvolvimento desse processo será – eu te garanto – muito menos trabalhoso. Sua produtividade tende a ser mais alta com o PDI que com uma linguagem de programação.

Conclusão

A performance de cada processo depende de um sem-números de fatores, e o critério para você fazer uma escolha entre as tecnologias possíveis, em princípio, é o custo de cada uma dessas opções, comparado com o retorno que elas vão te dar.

Como o PDI permite desenhar todo processo graficamente, “ligando os passos”, um analista produz muito mais usando o PDI que desenvolvendo um programa em alguma linguagem.

Mas e a performance, Fábio? Afinal, qual eu devo escolher se a performance for importante? PDI ou Query?

PDI, sem sombra de dúvida. Porquê? Porque o PDI oferece muitos mecanismos para melhoria da performance do processo e você fatalmente vai conseguir a performance que precisa, a uma fração da complexidade do desenvolvimento de queries.

É isso.

Ouro Escondido em Dados

Eu continuo lendo o tijolo Data Mining Techniques e mais empolgado a cada página. Ontem eu passei pelo texto abaixo:

Interviewing business experts is another good way to get started. Because people on the business side may not be fmiliar with data mining; they may not understand how to act on the results. By explaining the value of data mining to an organization, such interviews provide a forum for two-way coommunication. One of the authors once participated in a series of meetings at a telecommunications company to discuss the value of analyzing call detail records (records of completed calls made by each cstomer). During one meeting, the participants were slow in understanding how this could be useful. Then, a colleague pointed out that lurking inside their data was information on which customers used fax machines at home (the deteails of the resulting project are discussed in Chapter 16 on link analysis). This observation got the participants thinking. Click! Fax machine usage would be a good indicator of who was working from home. For the work-at-home crowd, the company already had a product bundle tailored for their needs. However, without prodding from the people who understood the data and the techniques, this marketing group would never have considered searching through data to find a worh-at-home crowd. Joining the technical andthe business highlighted a very valuable opportunity.

TIP: When talking to business users about data mining opportunities, make sure they focus on the business problems and not on technology and algorithms. Let the technical experts focus on the technology and let the business experts focus on the business.

Levaria muito tempo para traduzir tudo, mas resumidamente o que ele diz é que Data Mining não é um jogo só de técnicos nem só de analistas de negócio, mas dos dois. Mais ainda: não é um projeto de balcão! É preciso que todos envolvidos com o negócio da empresa sejam ensinados sobre o que é Data Mining, como ele funciona, o que ele pode fazer, e sobre os dados que a empresa dispõe.

Projetos de Data Mining não são caixa-preta. Muito pelo contrário, precisam ser divulgados, compartilhados e abraçados por todos na empresa.

Ele dá um exemplo: como especialista em Data Mining, ele colocou o pessoal de marketing para conversar com pessoal técnico sobre o valor do CDR, o Call Detail Record, ou registro detalhado de chamada, que é o registro gerado a cada ligação completada em uma central, e serve para fazer o billing do cliente. A certa altura, alguém lembrou que o CDR guarda a informação sobre que cliente usa máquina de fax em casa. Click! (sic) Quem usa muito fax em casa provavelmente tem home office, e a tal companhia tinha um pacote pronto para esse público!

Mais que tirar relatórios, responder perguntas e montar dashboards, Business Intelligence é sobre melhorar a gestão e os resultados da empresa a partir da montanha de dados que ela gera. Esse livro fala sobre isso: como BI/Data Mining pode mudar sua empresa para ser realmente centrada no cliente e com isso crescer.

Se quiserem aprender sobre BI, leiam esse livro. Ele é imprescindível para sua formação como analista de BI. Meu post Não é Bem Assim era exatamente sobre o que ele fala: usar o conhecimento extraído dos dados para ajudar a empresa a crescer. Eu voltei ao mesmo tema no post O Andar  Bêbado do Negócio tentando mostrar um exemplo, mas o que eu coloquei aqui, tirado do livro, é matador.

A mensagem é essa: construa sua infra/solução de BI mantendo o olho em Data Mining. É daí que virá o verdadeiro ouro que seus dados escondem.