As Sombras São Perigosas?

Pronto, lá vamos nós de novo! A bola da vez é Shadow IT, que é a organização de TI fora da TI.


Gartner: Shadow IT refere-se a equipamentos, softwares e serviços informatizados fora da propriedade e controle do departamento de TI de uma organização.

Wikipedia: Shadow IT é um termo usado com frequência para descrever sistemas de tecnologia da informação construídos e usados dentro de uma organização sem aprovação explícita. Assim como o termo Stealth IT, Shadow IT é usado para descrever soluções especificadas e entregues por outros departamentos que não o de TI.


Soa familiar? Deveria! Olhe esta notícia, de 2 de Fevereiro de 2016:


Gartner estima que as vendas mundiais de software de BI vai atingir US$16.9Bi, conforme as compras mudam do departamento de TI para as mãos de indivíduos adeptos ao auto-serviço. Gartner says $16.9bn BI market in last stage shift from IT to business


Este artigo discorre sobre a tendência de a operação das ferramentas para BI sair da TI e migrar para dentro dos departamentos que usam essas ferramentas. Como estamos em 2016 e a onda de Data Discovery já está passando, o repórter coloca as coisas em uma perspectiva suave comparado ao que foi 2015: “TI ainda tem um papel na captura e preparo dos dados para consumo pelos usuários de negócio”.

Cuma??? Li isso mesmo? “TI ainda tem um papel…”.

Nossa. :-O

Um ano atrás todas as propagandas de Data Discovery e outros quejandos berravam “livre-se da TI, acesse seus dados diretamente, sem precisar de ninguém!” Era praticamente a reedição da Reforma Protestante, agora para Inteligência de Negócios

Nada como um dia após o outro.

Eu até procurei um pouco de todo esse marketing anti-TI, mas não consegui encontrar. Começo a pensar se não vi coisas, ou se não entendi tudo errado.

À Sombra da TI

De volta à vaca fria, o ponto que eu queria enfatizar é que sempre existiu alguma independência entre os departamentos de TI e o restante da empresa. Nas pequenas empresas familiares, um departamento (ou até mesmo dois!) ficam concentrados em uma só pessoa, e o funcionamento da empresa depende das aptidões e talentos multidisciplinares de todos os empregados. Meu primeiro emprego, por exemplo, foi como assistente de vendas na ACATEC (nossa, ela sumiu…) e o trabalho usava uma mistura bagunçada de Word, Access, fax e e-mails. Aos poucos eu aprendi a usar o Access e evoluí o processo de trabalho, até ficar totalmente centrada no Access e eliminar 100% de papel (isso está no meu CV, hehe – e era 1998!!!) Nesse Access registrávamos o contato do cliente, abriámos propostas, mandávamos mala-direta etc. Eu era a TI, o BI, o Marketing E assistente de vendas. :-)

Depois eu fui trabalhar no SAS (graçasadeusaindaestálá!), uma empresa muito, muito, muito maior. Havia um departamento de TI, um cara para cuidar da infra e tudo mais…

… MAS TODO MUNDO ANOTAVA TUDO EM PAPEL!!

O escritório do SAS na maior cidade do maior país da América do Sul tinha uma rotina de trabalho mais manual que da pobre ACATEC. E o que eu fiz? Reconstruí o banco de dados em Access e automatizei o meu trabalho, claro. Mostrei para meus colegas e eles disseram que alguém já tinha tentado fazer a mesma coisa, e até resgataram o que foi feito, mas que não deu em nada.


Foi a primeira vez que eu me dei conta de que não podemos forçar uma boa ferramenta em qualquer uso. O que eu consegui fazer em um dia com Access eles passaram meses tentando, usando o próprio SAS, e não conseguiram. O fato é que o SAS não era voltado para aquela função. Daria para fazer – tanto que eles conseguiram alguma coisa – mas não teria dado tão certo como meu Access nem com todo conhecimento do mundo. E isso faz quinze anos!!


No final veio um mega-sistema da sede, nos EUA, via web, mas ainda não fazia tudo que o meu fazia – estava planejado, mas na primeira etapa era só um apoio para elaboração de propostas. Enfim, saí de lá para uma empresa que vendia software de automação industrial (SCADAs), que era parte de um grupo maior, que incluía uma software house para automação comercial. Era uma empresa nacional, chamada Aquarius, com alcance internacional. Um meio-termo, portanto, entre o SAS e a ACATEC.


Eu, de peixes, trabalhando na Aquarius. Piada pronta… :-P


De novo, operavam na base do papel, e-mail, Word, agendas particulares (de papel! Eu era um dos dois únicos caras com um Palm.) O que eu fiz? Adivinhou: saquei o Access do pacote MS Office, que todo mundo tinha, e reconstruí meu gerenciador de contatos/vendas. Desta vez meu trabalho era todo de campo, e por isso eu precisava visitar muitos clientes. Não tive dúvidas! Criei uma função de planejamento de roteiro. Assim eu poderia passar uma semana no escritório contatando os clientes e fechando agenda para, vai, o sul de Minas Gerais, e registrar tudo. No final eu imprimia um relatório e passava a semana na estrada, ticando empresa após empresa.

De novo, mostrei o que tinha feito em uma reunião da diretoria da empresa. De novo… está ficando cansativo, mas vamos lá…

De novo eles falaram “nossa, igual ao que estamos fazendo!” e me mostraram o que estavam desenvolvendo a coisa de ano ou pouco mais. Claro que eles estavam fazendo um produto para vender e não se comparava com o meu nem em funcionalidades nem em qualidade e aparência. O meu era um Access, manuseado metade por formuláros, metade por tabelas, enquanto que o deles era um aplicativo especial, com instalador, cliente-servidor, todo cheio de ícones bonitos e telas funcionais.

Mas mesmo assim eu os bati – cheguei antes no fim. Na verdade, acho que eu tinha acabado de recriar a idéia do ágil e não sabia. (Eu fazia pedaço por pedaço, para atender uma necessidade imediata.)

Excel-ente!

E esta semana, lendo por aí eu me deparei com o tal do Shadow IT. Ora bolas, eu sempre fui uma sombra de TI! Não quero nem nunca quis sabotar nada, sem contar que algumas vezes eu era a própria TI. Eu sempre tentava obter e adotar a solução oficial. Quando essa não vinha, ou não resolvia um mínimo dos meus problemas, eu partia para resolver eu mesmo.

A maior ferramenta de BI de todos os tempos.
A maior ferramenta de BI de todos os tempos.

Quando os projetos de DW e BI começaram a demorar muito, a frustrar os usuários finais, o que foi que aconteceu?

Eles começaram a contornar à TI! Não é à toa que a funcionalidade mais requisitada em TODOS os projetos de exploração e visualização de dados (aff… “projetos de BI”) é EXPORTAR PARA EXCEL!!! Porque assim cai em uma coisa que o usuário pode fuçar sozinho, sem ser barrado ou frustrado pela TI e pelos “donos” do projeto de BI.

Na minha opinião, foi essa atividade parelala, tocada à sombra da TI formal, que os fornecedores de ferramenta de BI decidiram alimentar. Eu sempre impliquei com todo aquele papo de vendedor, como “se conecta a qualquer fonte de dados”, “self-service!”, porque quase todas as ferramentas de BI, se não todas mesmo, conectam-se a quase todas as fontes de dados, ou ao menos ao conjunto dos bancos mais famosos. Isso nunca foi uma revolução.

A revolução, mesmo, foi o vendedor desviar da porta do departamento de TI e ir bater no departamento de vendas. Na minha opinião, as modernas ferramentas de BI, mais leves e de menor porte, vieram na esteira dessa mudança no paradigma de vendas, e não o contrário.


Eu não levei mais que alguns meses no SAS para chegar a conclusão que BI se vende na diretoria, não na TI. Mais tarde eu percebi que, de maneira geral, essa abordagem é um traço da cultura de vendas do SAS e por isso veio a mim tão rápido (e eu me achando esperto…) Apenas frequentávamos a TI para ter certeza que não seríamos sabotados por um gerente magoado ou por uma prima-dona dodói. Mas nossa mira era sempre o C-Suite, nunca TI.


Conclusão

Meu ramo é BI, e tendo a olhar só BI. Porém, esse movimento “Self-Service” para informatização existe em muitos outros campos. Quantos gerentes não usam planilhas e smartphones para cuidar de suas agendas, deixando o sistema de agenda corporativa para um papel de comunicação/interface? Ou quantos departamentos inteiros não rodam em sistemas locais, completamente separados dos sistemas oficiais da empresa? E quando essa situação surge, adivinha o que acontece? Punem-se os responsáveis pelo sistema paralelo e força-se a adoção do oficial? Não, muito pelo contrário! Não raro a TI oficial assume que o sistema paralelo existe e funciona e deixa de competir por aquele “nicho” local, dedicando suas forças a coisas que ainda precisam da ação oficial.

O termo Shadow IT para faladores de português pode induzir à percepção de algo sombrio, fúnebre ou fora-da-lei. Mas em português, quando ficamos por perto, mas não à frente, ficamos à sombra de algo ou alguém. É esse o sentido, na minha interpretação, do termo Shadow IT. A tradução mais adequada talvez seja TI Paralela ou TI Alternativa.

Ao observar esses fatos – a TI paralela por necessidade, conveniência ou comodidade – e a explosão do mercado de ferramentas, eu passei a acreditar que não estamos vivendo a era do BI Self-Service, mas a do BI Paralelo, do Shadow BI.

O que me leva à uma forçosa conclusão:


Não existe Data Discovery. Não existe Data Lake. Não existe qualquer-coisa-BI-self-service, como eu venho argumentando há algum tempo, aliás.

O que existe é um mercado de softwares para a TI Paralela, e Self-Service Business Intelligence é um desses sub-mercados.


Quando eu me sentei para escrever esse artigo minha visão era colocar Shadow IT e o movimento de BI Self-Service lado-a-lado e, por meio de alguns paralelos, questionar se o que estava acontecendo não era a ascenção da Shadow IT, muito mais que o crescimento do auto-serviço. Só que eu não estava preparado para o que eu descobri: como sempre, eu recolho algumas referências para alimentar meus argumentos1, mas eu encontrei uma extrema dificuldade (leia-se: uma infrutífera hora googlando sem resultados) para encontrar propagandas, anúncios, posts esgoelando sobre “como a ferramenta X vai te dar independência da TI”.

Ao invés disso eu encontrei declarações contemporizadoras, suavizando o embate entre TI e usuário pelo acesso aos dados. Uma situação praticamente impensável a até um ano atrás, ou menos.

Eu não acredito em ferramentas de exploração de dados totalmente dominadas por usuários de negócio – self-service, data discovery – porque isso demanda um conhecimento e habilidade fora do alcance de 99% dessa comunidade. Acho mais fácil acreditar em um departamento de TI paralelo, translúcido, oculto nas dobras do continuum espaço-tempo, digo, corporação-tempo.

No fundo, você sempre precisa tratar os dados, sempre precisa de profissionais que só vão ser encontrados no departamento de TI. Me parece que a que mudou não foi o poder, da TI para o usuário, mas sim o que é a TI, que saiu do departamento e foi para mais perto do usuário final.2

Ufa!

Até a próxima! ;-)


  1. O que me deixa aberto ao viés de confirmação, acusação da qual eu me declaro totalmente culpado. ;-) 
  2. O título é um infame trocadilho. Não deu para aguentar, perdão. 

Nadando em Lagos de Dados

Para escrever meu primeiro post sobre Data Lake eu pesquisei sobre o assunto. Abri o Firefox e saí fuçando o mundo com o Google. Achei alguns artigos interessantes, até que um deles matou o assunto e fiz o post. Eu peguei o restante das pesquisas, dei uma passada d’olhos e, como não achasse nada muito divergente daquilo, descartei.

Limpando meus papéis eu achei um dos artigo que eu separara para ler com mais calma, chamado – que criativo! – DataLake, publicado pelo Martin Fowler em pessoa, em fevereiro de 2015.


Ele se autodefine como “author, speaker, and loud-mouth on the design of enterprise software”, ou em bom português, “autor, palestrante e tagarela sobre o design de software corporativo”.

Eu sou um fã de seu trabalho e já li muitos livros dele e da série Signature, a maioria através Addison-Wesley. Ele é muito bom, e é preciso que se destaque isso: em desenvolvimento de software. Ele nunca publicou ou palestrou sobre BI. O mais perto que ele chegou foi um livro sobre NoSQL escrito em parceria e, pelo visto, este artigo. Por mais que eu o respeite em seu campo, não posso ter o mesmo sentimento quando ele atua fora de sua área. Neste caso o que ele escreve está mais para uma visão multidisciplinar e informada que um comentário de especialista no assunto.


E não é que tem ali uma coisa que eu não tinha notado? Algo que parcialmente redime o conceito de Data Lake e confirma a importância de Data Vault. Vou pegar o assunto do começo, desenvolver o tema e, na conclusão, mostro o que me escapou antes. Acredito que isso vai ajudar a entender melhor tanto o conceito e a utilidade de um Data Lake, quanto a verdadeira natureza de ambos – Data Lake e Data Vault.

Despensa, Cozinha e Salão

Não deixe de ler o artigo, que é muito bem escrito e é do próprio Martin Fowler. Ele começa:

Data Lake é um termo que apareceu nesta década para descrever um importante componente do encanamento analítico no mundo do Big Data. A idéia é ter um único depósito para todos os dados crus que qualquer um na organização possa precisar para análise. Normalmente o povo usa Hadoop para trabalhar os dados no lago, mas o conceito é mais amplo que meramente Hadoop.

Eu saí pulando pelo artigo, da primeira vez, e do meio dele achei o que eu queria ouvir (ler!):

O Data Lake não deve ser acessado diretamente com frequência. Pelo fato de os dados serem crús, você precisa de um bocado de habilidade para tirar qualquer sentido deles. Você tem relativamente pouca gente que trabalha no Data Lake, e conforme eles descobrem visões úteis genericamente, eles podem criar Data Marts cada um do qual com um modelo específico para um único bounded context. Daí, um número grande de usuários podem tratar esta “loja a beira-rio” como uma fonte de dados fidedigna para aquele contexto.

No original: The data lake shouldn’t be accessed directly very much. Because the data is raw, you need a lot of skill to make any sense of it. You have relatively few people who work in the data lake, as they uncover generally useful views of data in the lake, they can create a number of data marts each of which has a specific model for a single bounded context. A larger number of downstream users can then treat these lakeshore marts as an authoritative source for that context.

Neste ponto eu parei de ler e fui escrever aquele post. Quando eu retornei e reli este artigo inteiro, eu notei a primeira relação desta visão de Data Lake com um Data Vault: assim como o proposto aqui por Fowler, um Data Vault não é uma estrutura para acesso direto. Os dados de um DV precisam ser refinados para uma área de apresentação, para aí então serem consumidos. Usando a metáfora de restaurante do Kimball, um Data Vault é a despensa, e tanto o DV quanto o Data Lake precisam passar por uma cozinha que deve preparar os dados para consumo pela clientela.

Aff… Medo de perder o contato com a realidade com tantas metáforas… Enfim, em frente.

Uma Rosa por Qualquer Outro Nome

Não bastasse essa semelhança, existe um outro conceito amarrado ao Data Vault que aparece no post do Fowler: o bounded context, que corresponderia a um conceito meio obscuro em DV, o Unit of Work.

Primeiro, o que é bounded context? A imagem abaixo dá um exemplo:

Ilustração do conceito de contexto limitado - bounded context.
Ilustração do conceito de contexto limitado – bounded context.

Agora a definição de bounded context:

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD‘s strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

Ou, em tradução livre, “contexto limitado é um padrão central em Domain-Driven Design. É o foco da estratégia de design, que mostra como lidar com grandes modelos e equipes. DDD lida com modelos grandes dividindo-os em diferentes contextos limitados, sendo explícito em seus inter-relacionamentos”.

Em outras palavras, o tal do “contexto limitado” que o Fowler usa para dar sentido aos dados consumidos do Data Lake é similar ao conceito de orientação a assunto, subject oriented, do Inmon e [Kimball][dmmanifesto_bitly]:

“(…)what a data warehouse is – a subject oriented, nonvolatile, integrated, time variant collection of data in support of management’s decisions(…)”

Como o próprio Linstedt (o criador do Data Vault) insiste na necessidade de um área de apresentação de dados, tanto o conceito de “orientação por assunto” ou “limitação de contexto” se aplicam ao Data Vault! Mas há algo mais: existe um conceito pouco mencionado chamado Unit of Work (UoW), ou “Unidade de Trabalho”.

Conceito de UoW ilustrado: cada circunferência representa uma "unidade", que se integra a conceitos vizinhos.
Conceito de UoW ilustrado: cada circunferência representa uma “unidade”, que se integra a conceitos vizinhos.

Eu revi os livros e fiz uma busca pela Internet, mas não achei nada definitivo sobre o assunto. Este post foi feito por um dos alunos do Hans Hultgren, que parece ter sido o único a avaliar o conceito do ponto de vista de modelagem. Isso seria a definição de UoW:

  • A Unit of Work defines a correlated set of data;
  • A Unit of Work keep things together;
  • A Unit of Work establishes consistency between arriving data and data stored in the Datavault links;
  • UOW should be consistent with the (Enterprise wide) business keys.

Resumindo e traduzindo, traduzindo e resumindo, uma Unidade de Trabalho segundo Hans Hultgren é:


Um conjunto de dados correlacionados entre si, que faz sentido apenas quando estão juntos e representam aspectos do negócio.


Nest link e neste outro link esse conceito aparece de novo, mas sempre jogados, sem aprofundamento.

Então temos três conceitos:

  • O clássico subject oriented, da área de DW;
  • O bounded context herdado da área de desenvolvimento de sistemas;
  • O misterioso Unit of Work, visto em textos de Data Vault.

E todos eles querem dizer praticamente a mesma coisa: um conjunto de dados relacionados entre si, que representam a realidade da organização tal como foi capturada pelos sistemas informatizados.

Romeu & Julieta. Quê?! Shakespeare de novo, uai! Peguei gosto. :-)
Romeu & Julieta. Quê?! Shakespeare de novo, uai! Peguei gosto. :-)

Esta bela imagem foi retirada da Wikipedia.

Juliet:

‘Tis but thy name that is my enemy;
Thou art thyself, though not a Montague.
What’s Montague? It is nor hand, nor foot,
Nor arm, nor face, nor any other part
Belonging to a man. O, be some other name!
What’s in a name? that which we call a rose
By any other name would smell as sweet;
So Romeo would, were he not Romeo call’d,
Retain that dear perfection which he owes
Without that title. Romeo, doff thy name,
And for that name which is no part of thee
Take all myself.

W. Shakespeare, Romeu and Juliet

Portanto temos mais um tema em comum entre a visão de Data Lake de Martin Fowler e os conceitos de um Data Warehouse: o conjunto de dados correlacionados entre si.

Mesmo Assim…

… Fowler comete alguns equívocos:

  • Ele afirma que modelar o dado na entrada é um beco sem saída. De fato, usando modelo dimensional ou a terceira forma normal, não há solução possível. Cedo ou tarde esses modelos abrem o bico e quebram. Eu já discuti isso aqui e a conclusão foi justamente que um Data Vault supera essa limitação;
  • Ele diz que qualidade de dados é um problema, primeiro porque pode ser difícil equalizar a qualidade entre fontes diversas, e depois porque Data Mining (ele não usa esse termo, mas é disso que ele fala) precisa dos dados sujos. Ele tem razão e está errado nos dois casos, pois um modelo dimensional, que é feito para apresentação, guarda dados limpinhos e cheirosos, mas não um Data Vault. Um DV guarda 100% dos dados tal como vêm dos sistemas de origem, tanto que uma das premissas é que possamos reconstruir o estado do sistema de origem usando o DV e ter 100% de auditabilidade;
  • Aceita que o sistema de origem pode e deve mudar, afirma que o Data Lake deve guardar tudo e nunca apagar nada, mas deixa em aberto como gerenciar a associação entre as diversas capturas ao longo do tempo e a variação de esquema no sistema de origem. Quer dizer, até entende essa necessidade – uma coisa básica em todo DW – mas não tem idéia de como deve ser feito. Apesar de um modelo dimensional e um na 3NF poderem assimilar essas mudanças, um Data Vault é a única modelagem que aguenta.

E, vamos reconhecer, ele diz uma coisa muito muito bacana: You should use a data lake for analytic purposes, not for collaboration between operational systems. Ele afirma que trocas de dados transacionais entre sistemas devem ser feitas usando tecnologias como chamadas HTTP RESTFul e não via DW/DL/WH(atever). Finalmente! Acredite se quiser, tem gente que vê essas tecnologias de BI/DW como respostas para toda e qualquer necessidade. Absurdo! Mais um ponto para o Sr. Fowler.

Conclusão

É isso que conseguimos quando pegamos profissionais inteligentes, altamente gabaritados e humildes1 como Martin Fowler. Ele conseguiu enxergar na definição do James Dixon, da Pentaho, um componente do cenário de análises de dados de uma organização. Até então, eu via no conceito Data Lake apenas um departamento de marketing forçando a barra para vender software.

Mas o resultado final do post do Fowler é muito maior que seu conteúdo:

Data Lake Data Vault
Dados crús Dados crús
Precisa destilar para consumir Precisa destilar para consumir
Context bounded Subject oriented

PQP DE RODINHA!!!

O que o artigo dele coloca é de uma obviedade cristalina, e por isso mesmo nós, gente comum, deixamos passar:


DATA LAKE = DATA VAULT


Só o gênio dele para trazer essa relação à tona.

Então, da próxima vez que aventarem um Data Lake do seu lado, responda: “show! me dê o curso do Linstedt, o Wherescape e vamos começar!”

;-)


  1. Para mim é inconcebível um cara da área dele falar sobre outro assunto com tanta propriedade sem ter estudado e se consultado com um monte de livros e pessoas e ter ouvido essas pessoas. A lista de agradecimentos dele, ao final de seu artigo, reforça minha certeza. 

Eleições Inteligentes

Agora que estamos na época, diga-me: como você escolhe seu candidato às eleições?

Essa é uma escolha pessoal (mas de arrependimento coletivo :-) ) e não tem uma fórmula. Cada um vota de acordo com sua consciência e opinião.

Não deixa de ser curioso, portanto, os argumentos que cada político apõe à sua campanha. Um dos candidatos a vereador em São Paulo, por exemplo, promete acompanhar de perto os gastos públicos. Para dar um exemplo do que está falando, ele soltou uma lista das emendas aprovados na câmara dos vereadores, que geraram despesas.


Hmmm… Dados tabulados… Planilha…


É claro que eu não pude resistir e, morando em São Paulo, eu tinha que fazer um exame mais visual desses dados.

Assim Não Vai Rolar…

Eu poderia usar o Calc (=Excel do LibreOffice) ou qualquer outra ferramenta. Optei pelo [BA Server 5.4][ba54] que me permite importar um arquivo CSV e montar um cubo. Assim eu poderia examinar os dados e montar um post para o blog. Eu estava farejando um caso neste assunto.

Eu me propus a uma tarefa muito simples:


Examinar os gastos das emendas de vereadores, no período 2013-2015, contra as principais dimensões: Vereador, Destino da Verba e Tempo.


Não queria achar nenhum padrão oculto nem nada, apenas exercitar um pouco de ETL/OLAP com o Pentaho e aproveitar para ver como o dinheiro está sendo gasto.

Expertei a planilha para CSV e importei no BA Server usando o wizard de nova fonte de dados. Isso me deixou com um cubo OLAP, “pronto” para explorar.

Primeira Visão: Por Vereador

Coloquei entre aspas porque estava pronto coisíssima nenhuma. Vejam:

Valor de emenda aprovada, quebrado por vereador.
Valor de emenda aprovada, quebrado por vereador.

O nome do verador pode aparecer de mais de uma forma, resultando em linhas que não são agregadas. Assim parece que temos dois vereadores “tipo Netinho”, cada qual com um total de gastos, quando na verdade é um só político:

Vereador Gasto
Netinho de Paula 180.000,00
Netinho De Paula 660.000,00
Netinho de Paula”_” 560.000,00

O “_” é para indicar que o nome possui um espaço extra ao final, dando três “nomes” diferentes para a mesma pessoa.

E apesar de o objetivo ser examinar os valores por vereador, se eu quisesse ver por partido, quantidade de votos etc. não daria, pois essa informação não consta na planilha.

Segunda Visão: Por Objeto

Vamos lá:

Valor de emenda aprovada, quebrado por objeto, i.e. destino da verba.
Valor de emenda aprovada, quebrado por objeto, i.e. destino da verba.

Nossa, pior ainda! Até há um padrão de nomes, mas não é consistente (nomes duplicados de formas diferentes, como no caso dos vereadores) nem prático (não dá para analisar um gráfico com um item “Reforma do CDC Moinho Velho, no bairro do Ipiranga, incluindo troca do piso do salão de festas, do salão sede, do vestiário e sanitários, troca do telhado, instalação de forro de gesso no salão de festas, reforma da parte elétrica/luminárias, além de pintura geral – Rua Elba 980 – Ipiranga”!!)

E também não dá para separar por categorias, como Saúde, Esporte, Reforma, Compra etc. Até temos que orgão recebeu o dinheiro, mas não vai além disso. Não dá para, por exemplo, comparar os gastos de subprefeituras com secretarias municipais.

Terceira Visão: Por Ano

Até temos um padrão melhor, graças ao fato de termos uma coluna só para ano:

Valor de emenda aprovada, quebrado por ano.
Valor de emenda aprovada, quebrado por ano.

… mas não dá para quebrar por mês, por exemplo, ou para saber qual dia da semana tem mais aprovações.

Também não dá para quebrar por região da cidade ou qualquer outro parâmetro, como quantidade de eleitores, por exemplo. Imagine saber quais são os projetos que atendem mais pessoas? Será que tem algum padrão bairrista, onde somas vultosas são gastas com projetos populistas, mas de baixa serventia pública? Isto é, que é bonito pra chuchu, mas atende pouca gente?

Data Quality To The Rescue!

Eu sempre quis fazer um post com exemplos de Data Quality, e estava apostando que esta planilha seria um bom caso.

Há uma renca infinita de operações e técnicas de limpeza de dados, mas na maior parte dos projetos sempre usamos as mesmas técnicas. Duas destas técnicas mais frequentes são muito úteis, e se aplicam diretamente ao ETL: normatização e classificação dos dados.

Por exemplo, o “multi-vereador” que vimos acima passaria a ter um único nome, e as agregações passariam a funcionar. Isso é normatização: damos uma norma aos membros de um conjunto, que obtemos montando – manual ou automaticamente – um dicionário para traduzir todas as formas de cada elemento em uma forma só.

Já a classificação é uma técnica que automatica extrai atributos de um certo elemento. Por exemplo, podemos usar a data, que existe na planilha, para conseguir as informações de mês e dia da aprovação do gasto.

Em outro exemplo, podemos fazer buscas por textos específicos em cada linha tratada, e assim gerar uma classificação automática para os dados. Vou usar essa técnica para tratar os objetos de cada emenda, e descobrir se pertencem à área da Saúde, Esporte ou Cultura, se são Melhorias ou Compras e assim por diante.

Vamos lá.

Normatização com Dicionários

Com relação ao nome dos vereadores, precisamos montar um dicionário que “traduz” cada variação de nome para um padrão. E já que estamos nesta, podemos fazer um pouco mais: podemos enriquecer essa planilha com outros dados do vereador, como partido, quantidade de votos conquistados etc.

Na verdade podemos fazer a mesma coisa com tudo nesta planilha:

  • Orgão: tipo (Secretaria, Subprefeitura, Autarquia etc.);
  • Região da cidade atendida: Centro, Sul, Leste, Oeste, Norte;
  • Objeto: usufrutuário, prazos etc.

Imagino que a Câmara dos Vereadores registre esses e muitos outros atributos em seus sistemas, mas o que temos é só essa planilha e por isso não dá para extrapolar demais.


O nome do vereador na planilha original vem com maiúsculas e minúsculas. A primeira coisa mais fácil a fazer é mudar todos para caixa baixa ou alta – prefiro alta.

Daí podemos pegar o partido, votação etc. do vereador em algum site. Eu achei uma página do UOL sobre as eleições de 2012 que trazia tudo: nome do vereador, partido e quantidade de votos. Com isso tudo em mãos eu construí uma planilha Excel com o seguinte layout:

Coluna Função
VEREADOR_ORIGINAL Nome do vereador na planilha original
VEREADOR_CORRIGIDO Nome corrigido
PARTIDO Partido pelo qual ganhou a eleição
VOTOS Quantidade de votos recebidos pelo vereador
VOTOS PARTIDO Quantidade de votos recebidos pela legenda

A tabela abaixo mostra como essa tabela foi preenchida:

VEREADOR_ORIGINAL VEREADOR_CORRIGIDO PARTIDO VOTOS
Abou Anni ABOU ANNI PV 
Adilson Amadeu ADILSON AMADEU  PTB  40100
Adolfo Quintas ADOLFO QUINTAS PSDB 
Alessandro Guedes ALESSANDRO GUEDES PT 
Alfredinho Alfredo Alves Cavalcante (ALFREDINHO) PT  36634
Andrea Matarazzo ANDREA MATARAZZO  PSDB  117617

Porque há casos de nenhum voto? Não sei. Provavelmente é um vereador suplente, que não constava na lista que eu usei. Dá para corrigir, mas o propósito deste post é exemplificar algumas técnicas de Data Quality e por isso não me preocupa se sobrar algumas lacunas.


Depois eu fiz mais duas colunas: faixa_votos_1 e faixa_votos_2. A primeira qualifica o vereador em faixas de 10.000 em 10.000 votos. A segunda faz uma divisão em três categorias: menos de 50.000 votos, entre 50.000 e 100.000 votos, e uma última de mais de 100.000 votos.

Depois eu apliquei a mesma idéia para o orgão e criei este dicionário:

Coluna Função

| ORGAO_EXECUTOR_ORIGINAL | Orgão na planilha original |
| ORGAO_EXECUTOR_CORRIGIDO | Nome do orgão corrigido |
| TIPO_ORGAO | Tipo: secretaria, autarquia etc. |
| REGIAO_CIDADE | Região que atende, ou Geral quando não tem |

Que, preenchido à mão, ficou assim:

ORGAO_EXECUTOR_ORIGINAL ORGAO_EXECUTOR_CORRIGIDO TIPO_ORGAO REGIAO_CIDADE
Autarquia Hospitalar Municipal AUTARQUIA HOSPITALAR MUNICIPAL AUTARQUIA GERAL
Fundo de Preservação do Patrimônio Histórico e Cultural FUNDO DE PRESERVAÇÃO DO PATRIMÔNIO HISTÓRICO E CULTURAL FUNDO GERAL
Fundo Municipal de Assistência Social FUNDO MUNICIPAL DE ASSISTÊNCIA SOCIAL FUNDO GERAL
Secretaria Municipal de Coordenação das Subprefeituras SECRETARIA MUNICIPAL DE COORDENAÇÃO DAS SUBPREFEITURAS SECRETARIA MUNICIPAL GERAL
Secretaria Municipal do Verde e do Meio Ambiente SECRETARIA MUNICIPAL DO VERDE E DO MEIO AMBIENTE SECRETARIA MUNICIPAL GERAL
Serviço Funerário do Município de São Paulo SERVIÇO FUNERÁRIO DO MUNICÍPIO DE SÃO PAULO AUTARQUIA GERAL
Subprefeitura Pinheiros SUBPREFEITURA PINHEIROS SUBPREFEITURA OESTE
Subprefeitura Sé SUBPREFEITURA SÉ SUBPREFEITURA CENTRO
Subprefeitura Vila Mariana SUBPREFEITURA VILA MARIANA SUBPREFEITURA SUL
Subprefeitura Vila Maria/Vila Guilherme SUBPREFEITURA VILA MARIA/VILA GUILHERME SUBPREFEITURA NORTE
Subprefeitura Vila Prudente/Sapopemba SUBPREFEITURA VILA PRUDENTE SUBPREFEITURA LESTE

Classificação Automática

Resolvidas essas dimensões, restou apenas o objeto de cada emenda. O que contém a lista de objetos de emendas? Coisas assim:

  • Contenção Margem com Gabiões – Rua Magdeburgo – Processo nº 2013-0.102.577-8;
  • Readequação área de lazer Rua Constantino Cavafi – Processo nº 2013-0.102.541-7;
  • 26º Campeonato de Moto Aquática – Jet Ski – Associação Brasileira de Jet Ski Profissional e Não Profissional;
  • E172 – Realização de Duas Etapas da Copa São Paulo de Jet Ski na Represa do Guarapiranga;
  • Execução de Obras de microdrenagem nas Ruas Rodrigues dos Santos, joão Teodoro e Ruas limitrofes no Bairro do Brás;
  • Associação Beneficente Nossa Senhora do Pari – Melhorias e Ampliação de Atendimento para adequação, ampliação e reforma do mobiliário e equipamentos hospitalares referente ao setor de Nutrição e Dietética;

E assim por diante. A única forma de fazer uma classificação precisa, bem-feita, é manualmente. São quase 1.800 projetos aprovados. Se eu levar um minuto para qualificar cada um, são 1.800 minutos ou 30 horas trabalhando sem parar.

No $%#%!@% way.

Logo, ou achamos o sistema de origem e vemos o que mais dá para puxar, ou montamos uma aproximação. Por exemplo, podemos montar uma tabela com uma coluna para cada atributo, como “É uma compra de material/produto?”, “É um pagamento de serviço?”, “É um gasto com saúde?” e por aí vamos. Daí, para cada objeto que entrar nesta tabela na primeira coluna, respondemos as perguntas em outras colunas. No final teríamos algo assim:

Objeto Compra? Cultura? Saúde? Esportes?
E2538 – Fundação Antonio Prudente(…) Não Não Sim Não
Implantação de equipamento de Ginástica (…) Sim Não Não Sim
Realização de obras e pavimentação de vias, visando a melhoria (…) Não Não Não Não
Incentivo à pratica de esportes Não Não Não Sim

Isso permitiria uma classificação rudimentar, inicial, que desse ao menos uma visão geral. Com ela podemos responder perguntas como “quanto do gasto é compra de material novo, e quanto é manutenção?” Ou “quanto estamos alocando de dinheiro para Saúde, Educação e Lazer?”

Uma forma de se fazer seria colocar essas linhas em uma planilha Calc e uma coluna para cada pergunta. Daí, usando fórmulas como IF() e FIND(), buscamos as ocorrências de termos-chaves. Sempre que encontrarmos um, marcamos com “SIM”. Se não encontramos nada, com “NÃO”.

E, de fato, foi a primeira coisa que eu fiz:

Primeira tentativa de qualificar os objetos.
Primeira tentativa de qualificar os objetos.

Era uma solução muito tosca, mas me ajudou a entender a mecânica da coisa. Com isso eu pude subir para o nível seguinte: usar RegEx, isto é, Expressões Regulares para fazer essa detecção. Usando expressões regulares eu poderia montar um processo de detecção automático e mais robusto que uma planilha Excel.

Assim, aproveitei o que eu aprendi com o livro RegEx Com Python e, com o auxílio do passo Regex Evaluation consegui extrair essa informações do nome do objeto de cada emenda parlamentar.


Eu parei de criar atributos e de refinar minhas RegExes quando comecei a ter um resultado aproveitável, mas poderia ter ido mais longe e conseguido bem mais coisa – até mesmo reconstruir a descrição da emenda aprovada. Mas, de novo, não era essa a meta e por isso não avancei.


Transformação Eleições 2016

A figura abaixo dá a visão geral da transformação que lê a planilha e gera um CSV pronto para importação no BA Server:

Transformação que incrementa a qualidade dos dados da planilha.
Transformação que incrementa a qualidade dos dados da planilha.

Essa transformação, e todos os dicionários, resultados e um pouco mais, estão disponíveis para download aqui, como um zip. Descompacte em um diretório qualquer e abra os arquivos .KTR com o Spoon do PDI 5.4. Falarei mais sobre a outra transformação na Conclusão.

Agora Sim!

Muito bem, com um novo e melhorado conjunto de dados, recarreguei o CSV no BA Server e gastei um tempinho refinando o mapeamento. Vejamos o que podemos fazer agora.

Por Vereador: bem melhor! Agora dá para ver todo mundo, numa só posição.

Valores aprovados por vereadores em São Paulo, no termo 2012-2016.
Valores aprovados por vereadores em São Paulo, no termo 2012-2016.

Veja que existe apenas um vereador que aprovou menos de um milhão de Reais em emendas. Até dá para dizer que existe duas faixas:

  • Uma turma que libera muito, com totais sempre maiores que R$ 5.000.000,00;
  • E outra que é mais modesta, que fica entre os R$2M e R$4M.

Mesmo assim não temos nenhum “calombo”, que seriam vereadores que liberam (ui!) muito mais que a média (ai!). Eu diri até que eles se espalham em uma graduação mais ou menos suave.

Por Objeto: Agora sim! Mesmo sendo uma classificação incipiente, consegui ver que os dez maiores valores em gastos concentram-se em coisas que não é nem para Saúde, nem para Esportes ou para Cultura.

Valores aprovados por qualificação de objetos.
Valores aprovados por qualificação de objetos.

Os dois picos são muito curiosos… Daí eu fui olhar por orgão:

Valores aprovados por orgão.
Valores aprovados por orgão.

Uia. Quem mais recebe dinheiro de emenda parlamentar… é a Secretaria de Esportes e Lazer, mas os picos do gráfico anterior mostram que o grosso do dinheiro não vai para isso… Confuso! Com certeza culpa da classificação porca e apressada que minhas expressões regulares toscas.


Eu explorei essas visões um pouco mais do que eu vou mostrar aqui. A menos que eu tenha cometido um erro grosseiro, parece que há mesmo uma concentração de emendas para Secretaria de Esportes. Eu fiquei pensando sobre o quê explicaria isso, e bolei uma hipótese: eventos e ações voltadas para Esportes causam um impacto mais marcante, e não constumam ser caras. Assim, se um político precisa prometer algo que tenha condições de cumprir, prometer fazer um evento esportivo parece uma opção de boa relação custo-benefício.

Mas é só uma hipótese, sem nenhum embasamento sério nos fatos. Tipo assim, um chutão. ;-)


E eu continuei a cutucar os dados, até que me deparei com uma visão interessante:

Eleitores representados por gastos.
Eleitores representados por gastos.

Lemos esse gráfico assim: “O maior valor foi liberado para emendas criadas por parlamentares com representação menor que 50.000 votos”. Legal, não é? Como a maior quantidade de vereadores tem menos que 50.000 votos, ter a grana concentrada nessa parcela de políticos significa que o dinheiro está sendo empregado em projetos da maioria dos vereadores, e que são projetos de baixa representatividade, ou seja, tocados por políticos que representam poucos eleitores.


Eu sou partidário do voto distrital, e não da forma atual. Esse gráfico reforça meu viés pelo voto distrital, mas evitaria tomá-lo como uma prova inconteste da vantagem dessa opção.


Essa é uma visão difícil de ler, mas é bem curiosa:

Valores em ementas espalhados na área proporcional a cada orgão.
Valores em ementas espalhados na área proporcional a cada orgão.

Imagino que era para ser um gráfico de árvore, mas ficou meio estranho…

Ele representa o valor gasto por orgão, dentro de cada tipo (Fundo, Subprefeitura etc.) De novo, observe como parece haver alguma desproporção entre os valores alocados à Secretaria Municipal de Esporte e Lazer e, por exemplo, a de Saúde. Até a de Cultura é maior que a de saúde!

E o gasto ao longo do tempo? Não parece nada de mais, um comportamento quase aleatório:

Distribuição de valores nos meses de aprovação.
Distribuição de valores nos meses de aprovação.

Eu poderia prosseguir aqui até a próxima eleição… de 2018. Mas não é preciso tanto. ;-)

Conclusão

Diz o ditado: Lixo Entra, Lixo Sai. Análises de dados dependem de dados Limpos, bem tratados etc. Existem muitas formas de se cuidar dos dados para que eles possam nos contar a verdade por trás de si. O ramo que responde por essas técnicas chama-se Data Quality e costuma ser uma disciplina complexa.

Vimos que, mesmo sendo trabalhoso, qualquer melhoria pode render ganhos significativos. Por isso considere sempre fazer ao menos uma avaliação da qualidade dos seus dados que o cliente vai examinar.

Coceira…

Com os dados ali, prontinhos, e os assuntos separados em tópicos, eu fiquei com a mão coçando para andar mais um pouco e transformar aquilo em uma estrela dimensional. Como a melhor maneira de se livrar da tentação é ceder, eu cedi.

Peguei a transformação anterior e coloquei alguns passos que alimentam junk dimensions. Isso deu origem a dimensões instantâneas de Vereador e Orgão.

Modelo dimensional miojo: basta adicionar Junk Dimensions!
Modelo dimensional miojo: basta adicionar Junk Dimensions!

Depois eu juntei todos os atributos em uma dimensão junk de verdade, e mais adiante adicionei outra para os objetos das emendas. Eu poderia degenerá-lo mas, francamente, a idéia daquele texto todo na fato, uuhhh calafrios, não me agradou.

Por fim criei uma dimensão data completa, usando um passo Database Lookup. Pronto! Um Table Output no final, sair clicando em todos os botões SQL para criar tabelas, rodar e…. PIMBA! Tudo no ar!

Eu peguei o Power*Architect e fiz uma engenharia reversa no banco. Ajustei alguns detalhes (como os relacionamentos) e voilà! Modelo dimensional de valores de ementas!

Diagrama de tabelas da estrela Emendas Vereadores 2013-2015.
Diagrama de tabelas da estrela Emendas Vereadores 2013-2015.

Esse diagrama e a transformação que o alimenta estão no mesmo pacote deste post. Fique à vontade para brincar, explorar e descobrir. Apenas mantenha em mente o seguinte:


Eu, Fábio, não sou responsável pelo conteúdo de dados deste pacote, nem por qualquer interpretação que alguém tirar dele.

Me incluam fora dessa! ;-)


Até a próxima!

Full Metal BI Itch

Outro dia assisti um filme de SciFi que eu adorei, No Limite do Amanhã, ou Edge of Tomorrow no original em inglês. (Clique aqui para ver o trailer.)1

Nele o herói “ganha” o poder de resetar o dia, ativado pela morte. Assim, cada vez que ele morre ele volta para o início de um certo dia – sempre o mesmo, sempre na mesma hora. Como o dia recomeçou, as coisas se repetem, sempre as mesmas, desde que ele tome as mesmas decisões. Logo ele percebe isso: os eventos futuros mudam em função das ações dele.

Por exemplo, na primeira “vida” ele é emboscado pelo inimigo logo que chega na praia. Na segunda, ainda sob o choque de ter morrido pela primeira vez, ele morre no mesmo lugar. Na terceira vida, quando ele chega na praia ele já sabe onde o inimigo vai estar, e acerta um tiro em cheio… e sobrevive! Apenas para morrer segundos depois, de novo, e reiniciar o dia pela quarta vez.

E assim ele vai: a cada vida que ele “revive” ele já sabe onde falhou da última, e avança mais um pouco.


Agora que eu parei para pensar um pouco, exatamente como em um video-game!


Amei aquele filme. Adoraria pode esquecê-lo só para poder vê-lo de novo e sentir a mesma emoção que eu senti da primeira vez.

E o que ele tem a ver com BI?

Guenta as pontas aí, já vou amarrá-las. Antes, um pouco sobre…

Técnicas de Garimpagem de Dados

Se você ainda não leu, leia. Esse deve ser o livro de BI mais de BI que existe:

O livro de BI mais de BI que existe. Leia!
O livro de BI mais de BI que existe. Leia!

Em sua introdução ele explica uma coisa chamada “ciclo virtuoso do Data Mining”, na minha tradução livre:


A promessa do data mining é encontrar padrões interessantes dormentes em todos esses bilhões e trilhões de bits jazendo em memórias computacionais. Meramente encontrar esses padrões não é o suficiente. Você deve responder aos padrões e agir sobre eles, em última instância transformando dados em informações, informações em ações e ações em valor. Esse é o ciclo virtuoso do data mining, resumidamente.


Capítulo 1, páginas 9 e 10 da terceira edição física, ou locação 676 para quem tem o livro no Kindle.

Acho que não preciso interpretar o que ele disse, não? É muito óbvio, certo?

Se é tão óbvio, seu projeto de BI deve estar fazendo, não?

Ah, não estão fazendo porque seu projeto é de Inteligência de Negócios, não de Data Mining? Entendi. ;-) Vamos ver o início do capítulo 3, então?

O que é que pode dar errado, não é mesmo?
O que é que pode dar errado, não é mesmo?

Este capítulo do livro vai esmiuçar um problema de Data Mining em suas partes e aspectos gerais e comuns entre várias técnicas. Não vou traduzir tudo que está escrito aqui, exceto por este trecho:


Data Mining is a way of learning from the past in order to make better decisions in the future.


Traduzindo mais ou menos ao pé-da-letra:


Garimpagem de Dados é uma forma de aprender com o passado a fim de tomar melhores decisões no futuro.


The Ultimate Past is The Future!

Vamos voltar ao filme: a cada vez que o herói morre, ele volta para o início do fatídico dia. Naquele momento, o futuro ainda não aconteceu mas, na cabeça dele, já. Ou seja, para ele, o passado é uma história que já aconteceu, e está para se repetir. Ele pode, portanto, usar o que aprendeu na sua “vida anterior” para tomar melhores decisões… no futuro!


Loucura, não? Filmes de Ficção Científica com viagem no tempo são mesmo de dar nós nas nossas cabeças. Enfim, adiante.


A esta altura acho que é impossível você não notar a ligação entre Data Mining/BI e o filme. Falam da mesma coisa!!

Isso não acontece na vida real, claro, mas… E se pudesse acontecer? 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?

A-há! Agora percebeu, né? 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.

O arriscamos no cara-ou-coroa, ou apostamos em algo mais sensato.

Odd Squad

Um bom exemplo de como Data Mining age sobre nossas decisões pode ser vista no seriado infantil Esquadrão Bizarro, episódio “Undercover Olive”.

Sem entrar nos detalhes desse seriado, que é divertido pra chuchu, a história é simples: os vilões roubaram o mapa para o quartel-general dos mocinhos – o tal Esquadrão Bizarro – e vão presenteá-lo a quem vencer o torneio de jan-ken-po do mal. Para impedir que esse mapa caia nas mãos de qualquer vilão, o Esquadrão Bizarro decide mandar uma agente, disfarcada (undercover) para participar do torneio e ganhar o mapa. Eles contam com uma vantagem: Oscar, cientista do grupo, analisou torneios anteriores e fez a contagem de cada movimento (pedra, papel ou tesoura) de cada vilão. Assim, quando a agente Olívia disputa um jogo, o Oscar “sopra” por rádio qual opção ela deve fazer para ter a maior chance de vitória.

O Esquadrão Bizarro: Oscar, Srta. O, Otto e Olívia.
O Esquadrão Bizarro: Oscar, Srta. O, Otto e Olívia.

No começo é fácil: a maioria dos vilões tem algum padrão, e eles usam esses padrões para ganhar. Mas quase no fim aparece um vilão que é aleatório! Ele sempre usa quantidades praticamente iguais de cada movimento, aleatoriamente. Não existe escolha mais provável, e a equipe fica em uma sinuca de bico: chutar qualquer coisa, e arriscar, ou se agarrar ao método que usaram até ali e fazer um chute calibrado?

É como Data Mining: pode ajudar muitas vezes, mas existe sempre o risco de errar pois não é uma previsão exata.


O Esquadrão Bizarro é um programa para crianças, que usa aquele fino humor britânico. É praticamente um Dr. Who para crianças, e usa uma pancada de clichès. Oscar, o cientista do Esquadrão, é obviamente inspirado no Q, o cientista do MI:6, das histórias do James Bond. O sistema de tubos é uma interpretação infantil dos teleportes de Star Trek, e assim por diante. E tem as galinhas-laser, uma birutice que não remete a nada, só piração mesmo. ;-) Meu filho de sete anos (e eu) adora(mos), mas o de dez acha uma chatice.


Ciclo Virtuoso do Conhecimento

Apesar de o livro tratar de Data Mining e por isso usar a expressão Ciclo Virtuoso do Data Mining, na minha opinião o correto seria falar Ciclo Virtuoso do Conhecimento ou Ciclo Virtuoso da Inteligência de Negócios, já que não é a garimpagem de dados que eleva a rentabilidade da empresa, mas sim o conhecimento gerado por meio de um processo de Data Mining que provê as melhorias.

Do início do terceiro capítulo, eis o ciclo:

  1. Identificar o problema;
  2. Transformar dado em informação;
  3. Tomar uma ação;
  4. Avaliar o resultado.

Auto-explicativo, não?

Conclusão

Comprar ferramentas, montar DWs, entregar dúzias de dashboards, etc. etc. etc. são ações tidas como “de BI”. São todas vazias, inúteis e até um desperdício de dinheiro se elas não forem construídas dentro do Ciclo Virtuoso do Conhecimento, no qual todos esses projetos e ferramentas são aplicados na construção de conhecimento, que depois é usado para tomar uma ação. Sem aplicar o conhecimento obtido em uma ação concreta, todo esse esforço terá sido desperdiçado, terá sido em vão.

Volto a frisar:


Se sua empresa não tem um problema para resolver, então não precisa de BI.


E se tem um problema, não começe comprando uma ferramenta bacana, ou subindo um projeto de “Data Lake”, ou coisa que o valha. Não.

Comece pelo começo: identifique o problema.

E sempre tome uma ação. Ou você vai viver todas as suas vidas repetindo os mesmos erros e morrendo no mesmo lugar.

Está sentindo essa coceira por BI?

Aquilo não é uma espada, é uma hélice de helicóptero!
Aquilo não é uma espada, é uma hélice de helicóptero!

Até a próxima! ;-)


  1. Há uma ligação entre o título do post e o filme. Assista-o e descubra. ;-) 

Santa Inquisição, Batman!

Um ex-aluno mandou um e-mail com uma pergunta simples, fácil até:


Olá professor como vai?
Fui seu aluno da última turma da 4linux de Pentaho e estou interessado em
usar o PDI como webservice e também em usá-lo para fazer stream de arquivos.
Você tem alguma referência sobre isso?


Uau, eu ministro esse curso há 7 anos e sempre aprendo coisas novas com meus alunos! PDI para stream? Quem pensaria nisso?

E porque ele pensou? Bom, eu respondi:


Vou bem, obrigado, e você? Tudo em riba? :-)

O PDI, especialmente combinado com um ESB ou mesmo com o BA Server, pode se tornar um provedor de webservices. Existe literatura sobre isso aqui e aqui.

Agora, sobre streaming é mais complicado. Já vi um exemplo de ler uma stream contínua do Twitter, mas nunca ouvi falar de servir streaming com o PDI. Procurei um pouco, mas não vi nada…


Só que não é assim que funciona. Veja, ninguém chega a um médico e pergunta “doutor, o ácido acetilsalicílico pode ser usado contra angina?”

Meu complemento:

Qual é, exatamente, seu caso de uso, sua necessidade?

E veio a resposta dele:


A questão do stream seria para transmitir arquivos entre servidores. Pensei em um webservice em C# que seria consumido pelo PDI, que enviaria arquivos através dessa sessão! O que acha? Ou usar um daqueles componentes de post para tentar enviá-los! Não sei bem ainda como pensar.


WTF?! Se você está coçando a cabeça, imagine eu.

O que eu consegui entender dali foi que existe um problema e ele imaginou que passar um arquivo por streaming resolveria esse problema. Note que já fomos do “dá para fazer X com Y?” para “preciso fazer Z, mas não sei bem como”.

Minha resposta:


Veja, transferir arquivos é o que você quer fazer. A questão é: que problema você resolve ao fazer isso? Qual é a “dor” que te motivou a buscar esse “remédio”? ;-)

É que, devido às normas de segurança, eu não posso usar métodos normais como compartilhamento entre máquinas ou sftp. Esses arquivos serão transmitidos pra outro servidor e redirecionados por email! Voce tem alguma outra sugestão? Eu pensei em stream porque lembrei daqueles servidores do Kazzar de transferência de música! A ideia era transmitir via stream e da memória mesmo, do outro servidor, passar por email.

É muita viagem? Heheheh


Sim, meu caro aluno, bastante! :-D Mas eu admito que foi muito criativo.

Notaram como agora estamos mais perto do problema, mas ainda não chegamos lá?

Pois foi o que eu disse:


Estamos chegando lá!

Pelo que você contou, o problema que você tem em mãos é resolvido com a transferência de arquivos, que não dá para ser feito por métodos mais ordinários, simples. Que problema é esse? Que necessidade é essa, que vai ser resolvida pela transferência de arquivos?

Transferir os arquivos, em si, é só a operacionalização da solução, não a solução do problema. O problema não é “como transferir arquivos”, mas sim o que requer que arquivos sejam transferidos.

Confuso? Vai melhorar, apenas pense um pouco mais. ;-)


Eu estou editando nossa correspondência para ficar mais clara e sucinta, mas confesso que eu mesmo não tenho bem certeza do que eu queria dizer naquele final… Enfim… ;-/

O fato é que surtiu efeito:


A necessidade é a seguinte professor!

Estou montando o BI aqui na empresa e temos muitos requisitos de segurança devido à norma PCI1.

Preciso prover relatórios por e-mail, o que é muito tranquilo de se fazer com Jobs e Transformations do PDI. O problema é que os arquivos serão gerados em uma máquina “interna”, que tem acesso ao banco de dados, mas essa máquina não pode falar com o servidor de e-mail, que está em um servidor “externo”, com acesso à Intranet.

A solução é enviar os arquivos de relatórios renderizados para um servidor intermediário, que daí os enviará por e-mail. Seria fácil se pudesse usar SFTP (que inclusive é um componente PDI), mas ainda não consegui a liberação para isso.

Por isso a ideia do stream: eu controlaria a transmissão do webservice a partir do “lado de fora”, onde montaria o e-mail com anexo para então enviar aos usuários.


U-la-lá! Envio de relatórios por e-mail, prejudicado por causa do bloqueio da rede por conta de normas de segurança! ESSE é o problema.

Meu comentário:


Ah! Agora sim! :-) Esse é o problema.


Foi o que eu disse…

No fundo o caso dele é uma situação complicada mais por conta da norma PCI1 que dos dados ou da tarefa em si. Na verdade, e se você ler a norma PCI vai entender isso, provavelmente o PDI vai poder fazer pouco por ele. É uma questão mais de administração e aderência a regras que ferramentas em si.

Por Quê Até Sangrar a Língua

O que eu queria trazer para divir com vocês era um caso real da dinâmica que rola em todo processo de levantamento de requisitos em BI. O mesmo ocorre em outros cenários, mas em BI isso é crítico: o cliente chega pedindo a receita do remédio para ele ir até a farmácia, comprá-lo e tomar sozinho. O cliente não está se reunindo com o analista de requisitos com quem vai ao médico e coloca uma situação, descrevendo os detalhes e perguntando o que fazer.

Não!

O clientes vão para sala de reunião dizer o que eles querem, e em 90% dos casos assumem que já bolaram a melhor solução, e que cabe ao projeto apenas implementá-la. Poucos carregam humildade o bastante para questionar a própria opinião ou, melhor ainda, oferecer o problema e pedir orientação.

Esse pequeno exercício de vai-e-vem, de abrir caminho no cipoal de achismos e “viagens” até pisar no cerne da questão, é o feijão-com-arroz do levantamento de requisitos em BI. Se você quer ajudar mais seu cliente, sofrer menos no desenvolvimento e passar menos frustrações, aprenda a perguntar porquê até não sobrar nada, até a língua sangrar!

Fábio, drama queen

:-D

Claro que a coisa precisa ser feita com um mínimo de tato e inteligência, ou vai virar uma patetada digna do Chaves.

Chamam isso de técnica dos “cinco porquês”, pois ao perguntar “por quê?” pelo menos cinco vezes chegamos à raiz de qualquer coisa. Este blog tem um texto mais detalhado.

Por Que Sim!

Fui vendedor de soluções de BI e depois de algum tempo percebi que 100% dos clientes pediam coisas que achavam que solucionariam o problema deles, mas que se eu vendesse o que eles pediam nunca daria certo.

Para entender o problema do cliente e descobrir o que resolve – ou seja, qual é a Solução de BI que ele precisa – é preciso um tempo de relacionamento, uma alma insatisfeita e muita paciência. Raramente você vai conseguir perguntar porquê? cinco vezes, de cara, na mesma reunião ou telefonema e sair com algo útil.

Por quê?…

Por que nem sempre o cliente tem paciência para isso.

?…

Por que ele sempre acha que já te respondeu e que você está sendo um chato.

?…

Por ele demora um tempo até perceber quão vazias são as respostas que ele está te dando – porque leva um tempo até a ficha cair.

?…

Por que raramente ele espera que o profissional de BI ajude com o problema dele.

?…

Por que quase todos clientes acham que vendedor de BI vende software, e não solução! ;-)

Até a próxima! ;-)

Por quê? Por que sim, pô! :-P


  1. PCI vem de Payment Card Industry Data Security Standard, ou padrão de segurança de dados da indústria de cartões de pagamento. 

ROI de Projetos de BI

Eu já falei um pouco sobre ROI de BI em dois posts:

O ponto nos dois casos era o mesmo: dinheiro voando pela empresa que foi recuperado com o uso de Inteligência de Negócios, comparado com o custo de cada solução. Como sempre, o ROI de projetos de BI é astronômico, é fora de escala. O primeiro se pagou em algumas semanas, e o outro deu um retorno de dezenas de vezes. Um exagero nos dois casos, não se importa como se examine a questão.

Em 8/8/16 (8+8=16! :-O ) meu grande amigo Rômulo me mandou um SMS:


Perguntas recorrentes: como avaliar o sucesso de uma implantação de ferramentas analíticas (BI); como medir, nesse caso, o ROI?


Eu prometi a ele responder com um post no blog, já que o assunto é extenso, interessante (e relevante) demais para um SMS.

Return On Investment

Em bom português, ROI significa “retorno do investimento”. Via de regra, ROI pode ser definido como, por exemplo, o tempo para um projeto pagar a si próprio ou o impacto do projeto sobre o faturamento ou o lucro anual.

E isso é óbvio, não é?

Toda Estrada Tem um Retorno Invisível

Pare um pouco. Respire, tire os olhos desta tela e olhe ao seu redor. De onde veio tudo que está por aí?

Do retorno esperado.

Por que você come quando está com fome? Porque espera que, em retorno ao seu ato de mastigar e ingerir, desapareça o incômodo da fome.

Por que compramos uma mesa, uma TV, pagamos um curso ou convidamos alguém para sair?

Por que trabalhamos? Por que uma empresa surge? Por que montamos projetos?

Fazemos tudo isso para obtermos um retorno, algo que vai aplacar uma vontade ou atender uma necessidade.

Tudo que fazemos, e por extensão tudo que uma empresa realiza, gera um retorno. É por isso que, às vezes, perceber o retorno de uma determinada ação é muito difícil, especialmente se é algo que pouco afeta sua realidade. Às vezes, o retorno de uma determinada ação só pode ser percebido quando aquela ação deixa de ser feita, como quando perdemos o emprego, ou quebra-se uma linha de produção. Neste momento vemos como é importante ter um salário, ou como uma peça que representam 10% dos custos de uma empresa pode ser responsável por mais da metade do dinheiro que entra.

Uma situação comum em que o ROI não é tão facilmente calculável é justamente a modernização de um recurso ou a manutenção de uma situação. Vamos bolar um cenário para um caso clássico, o ROI de um treinamento, e examinar algumas coisas.

Imagine um banco. Estamos em 2016 e nosso banco é uma empresa já estabelecida, operante. Fazemos uma pesquisa de opinião e descobrimos que nossos atendentes não gozam de boa reputação com a clientela. Ser mal-visto é ruim, e queremos diminuir essa percepção negativa. Decidimos, então, aplicar um treinamento de “atendimento qualidade total”.

Como medimos o ROI desse treinamento? Fácil: rodamos uma nova pesquisa e verificamos se a reputação melhou, certo?

NÃO! Errado!

É de ROI que estamos falando, de DINHEIRO, não de percepção subjetiva do atendimento pessoal.

Uma coisa é observar se o projeto – o treinamento – deu resultado. Outra, bem diferente, é descobrir quanto dinheiro ficou a mais com o banco por causa dessa capacitação!

Pense em outro cenário no mesmo negócio, o banco: um novo sistema interno vai entrar em operação, e a certa altura do roll-out é feito um treinamento no uso desse sistema. Seis meses mais tarde, com 100% dos usuários do novo sistema treinados e aprovados nas avaliações, a capacitação deu resultado? E o ROI, de quanto foi?

Talvez vocês conheçam essa anedota:

Ouvido na conversa entre dois empresários:

- Eu decidi que não vou treinar meu novo empregado. Imagine se eu invisto nele, preparo-o, e ele resolve ir embora?!

Ao que responde o outro empresário:

- É? E o que acontece se você não treiná-lo, e ele decidir ficar?

Vêem onde eu quero chegar?

Certos projetos oferecem uma dificuldade extra para calcular o ROI porque o retorno do projeto serve apenas para manter as coisas como estão, para evitar que piorem. Só conseguimos avaliar o quanto nos custaria não investir, como na anedota. Por extensão, podemos supor que o ROI desse tipo de projeto depende desse custo de não investir, do chamado custo de oportunidade.

Quadridimensional

Lá no começo dissemos que ROI pode ser, por exemplo, o dinheiro que o projeto gerou a mais, e aqui em cima mostramos que esse retorno pode não ser a mais e sim evitar uma perda, evitar um dinheiro “a menos”. Para fechar o assunto vamos apresentar umas equações simples, para ancorar o conceito na Matemática.

Uma das formas de calcular ROI é esta:

 

Definição simples de ROI.
Definição simples de ROI.

 

Aqui considera-se o ganho total de um investimento, contra seu custo. É uma fórmula válida para quando compramos ou vendemos alguma coisa, mas não quando mudamos algo na vida da empresa.

Quando um projeto é conduzido para mudar algo, precisamos considerar o impacto deste projeto ao longo do tempo. Basta pensar um pouco para entender o porquê: ao prevenir a interrupção da produção, por exemplo, você garante que o dinheiro vai continuar entrando. Se o projeto custa mais caro do que, digamos, um mês de produção, o ROI definido acima vai ser negativo se considerarmos o ganho do investimento apenas durante um mês, ou menos. Agora, este mesmo ROI se torna positivo – e cada vez maior – se considerarmos esses números a cada mês, ou dentro de um ano, por exemplo.

O chato de ver a questão sob este ponto de vista é que tudo passa a ter ROI, e não raro um grande ROI:

  • Se eu deixar de pagar meus empregados, eles param de trabalhar e eu paro de faturar. Então há um ROI aqui, que equivale a tudo que eu faturo!
  • Se eu deixar de pagar a eletricidade, ou a água, ou telefone, ou…, ou…, ou…, de novo, o dinheiro não vai entrar. Então, pagar tudo isso tem um ROI que é, de novo, igual a tudo que a empresa ganha!
  • Se eu deixar de investir na melhoria da empresa, meus clientes podem me abandonar, piorando meu faturamento. Logo, investir em melhorias tem ROI!

E asssim por diante. Esse raciocínio vai dar muita confusão se o levarmos adiante e por isso vamos manter o foco apenas nos projetos limitados no tempo. Esses projetos têm início e fim (um custo determinado), e normalmente mudam ou acrescentam algo na empresa (um impacto limitado.)

Ao considerarmos projetos e tempo, definimos o ROI como um retorno dentro de um período. Ou então como o tempo que o projeto leva para se pagar, em função de quanto esse projeto agregou de valor. Sob estas condições, a fórmula fica assim:

 

Definição de ROI com tempo.
Definição de ROI com tempo.

 

Leia: o ROI do projeto é medido em períodos, calculado como a razão entre o custo do projeto e quanto de dinheiro o projeto traz a mais. Se dissermos que período é mês, estamos calculando quantos meses o projeto leva para se pagar.

Essa é a fórmula de ROI que eu usei no post R$20M, e é o que nos interessa para responder a pergunta do Rômulo:


Em “uma implantação de ferramentas analíticas (…) como medir (…) o ROI?”


Ganha um bombom quem percebeu que essa é a fórmula para o famoso “vai levar X anos para se pagar”. ;-)

Só para completar, podemos calcular um percentual de retorno por período, deixando a equação semelhante à definição inicial:

Definição de ROI percentual, com tempo.
Definição de ROI percentual, com tempo.

Projetos de BI

Agora temos uma definição para ROI, e sabemos que o retorno pode ser tanto uma melhoria nos resultados quanto a prevenção de uma piora destes.

Antes de continuarmos, deixe-me esclarecer uma coisa sobre o meu amigo.


O Rômulo mora em uma cidade no estado do Rio de Janeiro e foi aluno meu numa das turmas de BI da 4Linux, à distância. Ele é muito gente fina e um dia, ao vir para um congresso em São Paulo, entrou em contato comigo e marcamos uma pizza. Conversa vai, conversa vem eu percebi que não era um aluno típico de BI. Ele estava terminando o doutorado e precisou de uma ferramenta de integração de dados, de relatórios etc. e por isso foi atrás do Pentaho. Daí optou pelo EAD da 4Linux etc. etc. etc.

Foi um certo choque para mim, quase tão grande quanto ter dado aula para o Prof. Fidelis – que ensina Data Mining há mais de 20 anos – e para o Grimaldi, do BI Com Vatapá, outro gigante nacional. Dar aulas para caras muito mais gabaritados do que eu me dá um tanto de medo, mas enfim.


Então quando o Rômulo faz perguntas, ele coloca a coisa em outro nível. Ele não diz simplesmente “ROI de BI”. Ele é preciso: “ROI da implantação de ferramentas analíticas”. E não faz isso por pedantismo ou para se exibidir – ele é gente fina, lembrem-se! – mas sim porque é precisamente essa a expressão.

O que é um projeto de “implantação de ferramentas analíticas”? É o que popularmente chamamos de “BI”, e mais recentemente de “Data Discovery”: é a disponibilização de dados, para análises ad hoc, por meio de alguma ferramenta de análise multidimensional.

Não BI, Mas Sim Ferramentas Analíticas

Quase lá!!

E o quê um projeto de “implantação de ferramentas analíticas” entrega? O que ele cria na instituição, na empresa? Que retorno ele traz?

Depende.

É isso mesmo que você leu: d-e-p-e-n-d-e. ;-)

Imagine que estivéssemos falando de Data Mining. O que um projeto de Data Mining entrega é um modelo matemático que vai ser usado para tomar decisões automaticamente. Esse tipo de projeto tem uma meta clara desde o começo. São sempre coisas como “aumentar X% as vendas”, “reduzir em 100 clientes/mês de perda por atrito”, “economizar K dinheiro na distribuição” e tals.

Mas e um projeto que coloca, nas mãos dos empregados, uma ferramenta para montar “relatórios”?

Depende: para que eram necessários esses “relatórios”?

Pode ser que sejam usados apenas para substituir um trabalho braçal feito todo mês, como consolidar o balanço da empresa.

Ou talvez o usuário esteja tentando bolar uma estratégia de cobrança para recuperar dinheiro de caloteiros.

Ou talvez para desafogar a TI, que gasta muito tempo só fazendo consultas triviais nas bases, servindo a empresa inteira.

Róidebiai

Esse subtítulo parece “pedro bial”, se lido bem rápido… :-)

O cálculo do retorno do investimento de um projeto de BI, em geral, ou de implantação de ferramentas analíticas, em particular, vai depender muito da clareza de objetivos do gestor que patrocinou o projeto.

Há um sério problema na indústria de BI hoje em dia porque nem todos entendem como usar os dados para gerar valor. Quando entendem do assunto, gestores patrocinam projetos de Data Mining, com metas claras e portanto ROI fácil de se calcular, ou então apoiam projetos que visam equipar a força de trabalho da empresa com um ferramental necessária para o trabalho diário. Neste caso, especificamente, a meta não é aumentar um faturamento, mas sim reduzir o esforço do trabalho como um todo, aliviar uma dificuldade sistêmica, azeitar melhor as engrenagens que mantém a organização eficiente, produtiva.

Calcular um ROI desse tipo de meta não é fácil, isso quando não é impraticável. É exatamente o caso de um projeto que não impacta criando algo novo, mas impedindo que se perca algo que já se tem, ou se tem pouco.

Assim, medir o ROI da implantação de ferramentas analíticas equivale a medir a produtividade dos beneficiados com essas ferramentas. Pode ser a redução do trabalho para gerar informações, pode ser uma maior velocidade na solução de problemas ou qualquer outra melhoria marginal, difusa pela empresa!

E, claro, temos casos pontuais no qual o cálculo do ROI é mais prático. Por exemplo, digamos que a tal ferramenta analítica foi trazida para um conjunto pequeno de profissionais, para resolver um problema pontual. Um projeto desses vai entregar alguma coisa muito definida, que facilita a medida de ROI.

Conclusão

Rômulo, você queria saber, em “uma implantação de ferramentas analíticas (…) como medir (…) o ROI?”

Depende! Que problema essa implantação mirava resolver? Resolveu? Agregou dinheiro ou apenas impediu o desperdício?

Essa é uma regra geral de BI que eu sempre reforço:


Projetos de Inteligência de Negócios resolvem problemas. Se sua instituição não tem um problema para resolver, então você não tem nenhuma necessidade de BI, não importa o que os vendedores de ferramenta digam em contrário.


Implantar recursos de Inteligência de Negócios sem ter claro que problema você vai resolver é uma coisa bem pouco inteligente. Se está muito difícil calcular o ROI do seu projeto de BI, pense duas vezes: precisa mesmo? Para fazer o quê? Para resolver que problema? Pode ser que você esteja no camiho errado!

Até a próxima! :-)

 

 

Ladyvaulk – O Feitiço de Dataváulquila

Faz uns dois anos, e começou assim: minha mão estava coçando para testar Data Vault. Eu tinha feito alguns experimentos, tinha implementado um caso pequeno, mas ainda queria explorar mais. Queria um volume maior, mais complexidade, algo mais difícil.


Cuidado com o que você deseja, porque pode conseguir.


E eu consegui. Quem mandou desejar? Um dos softwares que o SERPRO usa é o Zabbix. Resumidamente, ele server para monitorar ativos, como roteadores, servidores e hubs, coletar métricas do parque informatizado e assim por diante. Consulte a página do projeto Zabbix para saber mais.

Como o SERPRO é uma coisa imensa, tudo está sempre no limite, no máximo, no maior volume, no mais complicado. São milhares de máquinas, dezenas, se não centenas de redes e sub-redes, kilômetros de cabos e tudo mais. Não vou entrar em detalhes técnicos para não correr o risco de falar besteira mas, resumidamente, o povo super-criativo conseguiu botar o esquema todo para a funcionar dentro do que era possível e desejável. Há um vídeo com uma apresentação sobre esse assunto neste link, feita por um dos empregados do SERPRO.

Uma das soluções adotadas passava por uma concentração de dados, que era atualizada periodicamente e servia para apresentar certos dados coletados pelo Zabbix.

Enter Linstedtman!

A pessoa responsável por essa necessidade foi aluna em um dos meus treinamentos de Pentaho, e veio me procurar imaginando se o PDI não poderia ajudar nesse caso. Afinal, consolidar dados é justamente a função dele.

As atualizações precisavam ocorrer a cada 30 minutos, no máximo, ou idealmente a cada 5 minutos ou menos. Apesar do grande espalhamento do sistema, como o volume dos dados capturados era, em si, até modesto, a baixa latência do refresh não era um problema.

O que realmente dava trabalho era a integração dos dados. Poderíamos, por exemplo, modelar os dados em uma estrela dimensional, definindo os atributos de interesse como dimensões e adotar uma fato artificial para correlacionar os dados entre si. Daria certo mas, depois de algumas mudanças nas fontes dos dados, as tabelas dimensionais acabariam ficando complicadas demais. Ou seja, logo no início do projeto daríamos de cara justamente com o ponto fraco da metodologia – a dificuldade de manutenção. Não era uma opção.

Poderíamos simplesmente replicar o layout de origem, mas isso implicaria em capturar os dados em uma granularidade confusa e, de novo, na primeira alteração na origem, quebraria todo histórico.

Não havia alternativa. Eu não queria admitir que estava usando os problemas como justificativa, mas no final, os problemas justificaram mesmo a escolha óbvia.

Usar um Data Vault. :-)

The Curse

Como havia uma certa urgência, trabalhamos em equipe: eu analisava os sistemas de origem para desenhar o Data Vault, e ia tirando dúvidas sobre os conceitos de negócio com os especialistas. Em pouco tempo (duas semanas, se não me falha a memória), foi montado o diagrama de tabelas, os modelos de transformação PDI e, com isso, um processo de ETL completo, de cabo a rabo, saiu do nada.

Como não era um grande volume de dados, a primeira carga levou coisa de uns trinta minutos, um pouco menos que isso. A partir da segunda carga, o processo de ETL terminava em menos de um minuto, graças ao fato de o DV usar CDC para tudo. Quando a rede está muito lenta, leva quase três minutos. Finalmente, por garantia, decidiu-se manter uma latência de 30 minutos (i.e. meia-hora), que dá uma boa margem para falha e recuperação, e ainda atende a necessidade.

E isso tem funcionado nesses últimos dois anos, sem parar, sem falhas, sem soluços, liso como gelo. De vez em quando aparece uma situação nova, e toca lá eu ir atrás de entender como usar Data Vault para resolver.

Um dia destes, batendo-papo e conversando sobre o projeto, a minha ficha caiu.

Sabe, eu não implementei esse lance – eu apenas desenhei um template, um gabarito de transformações para hubs, links, satélites e satélites de links. Nem tampouco desenhei o diagrama de dados: passei as regras de modelagem para a pessoa e deixei-a desenhar sozinha. Eu revisava tudo e corrigia os erros cometidos, mas eu mesmo não pus um dedo no processo de ETL!

É verdade que eu montei a configuração do PDI, configurei a captura de logs de cada transformação, e ainda montei um job que chama tudo. Mas de novo: montei na minha máquina, mandei para o projeto, expliquei como instalar no servidor e não fiz mais nada.

E tudo ia crescendo, ganhando tabelas, coletando dados… E a coisa rodando, e o monstro ficando maior, e maior e novos problemas aparecendo e eu só dizendo o que fazer. No máximo eu examinava os dados remotamente, para descobrir porque isso ou aquilo não estava dando certo, diagnosticava e, quando muito, corrigia os templates. A pessoa do projeto regerava as transformações problemáticas e tudo ia em frente.

Vocês não perceberam ainda né? Eu também demorei:


O projeto foi completamente, totalmente, 100%-mente construído, implementado e está sendo gerenciado por um profissional que não criou nada daquilo.

O projeto foi completamente, totalmente, 100%-mente construído, desenhado e planejado por um profissional que não implementou uma única transformação!


Sacaram? Eu não repeti a mesma frase duas vezes, leiam de novo.

Vou escrever ao contrário e vamos ver se fica mais claro:


O grau de automação do desenvolvimento foi tão grande, e em nível tão detalhado e profundo que a construção do modelo de dados e processo de ETL foi feito por um profissional que ignorava quase que completamente a técnica (DV) por trás.

E mais: a flexibilidade e resiliência da Metodologia de Data Vault é tão grande que foi possível desenvolver tudo – modelo e ETL – entendendo quase nada do negócio!


Nossa ignorância mútua dos problemas um do outro só não era total porque aos poucos fomos pegando partes da coisa – eu entendendo um pouco de Zabbix e o outro lado um pouco de DV e PDI. Mas nunca precisamos explicar nada sobre os detalhes de nada um ao outro!!!!!!!

:-O

Conclusão

Na esbórnia cultural que foi a década de 80, um dos filmes mais aclamados foi Ladyhawk, que contava a história de um casal amaldiçoado por um sacerdote malévolo. A maldição jogada nos dois fazia com que nunca se vissem, a não ser por uns breves segundos ao anoitecer e ao raiar do dia. Esse era o tal “Feitiço de Áquila”, que o nome do lugar: durante o dia a mulher era um gavião, e durante a noite, quando ela voltava à forma humana, o cara virava um lobo.

Preciso pedir perdão a vocẽs, porque foi mais forte que eu. Não deu para resistir.

Eu tive que brincar com isso.

A narrativa épica de um projeto de sucesso na era ágil! Quem projetou o ETL não implementou, e não sabia nada do negócio, enquanto que quem entendia tudo do negócio não sabia nada nem do modelo de dados, nem do ETL que estava  implementando com as próprias mãos (e um monte de processos automatizados!)

Uma equipe que nunca se vê, um projeto conhecido metade por cada um, que ninguém sabe por inteiro! Essa é a história de…

Ladyvaulk – O Feitiço de Dataváulquila!!!

Preciso concluir?? Não é à toa que existem, hoje, ferramentas como Wherescape e Attunity! Data Vault é uma coisa tão bombástica que um só “arquiteto”, como eu, pode cuidar de muitos projetos ao mesmo tempo, cada qual com UM – permita-me frisar: UM! – profissional de dados do outro lado.

AI MEUS SAIS!
AI MEUS SAIS!

Traduzindo: uma equipe de arquiteto mais alguns implementadores pode cuidar de muitos Data Vaults. É uma eficiência simplesmente impensável em qualquer outra metodologia!!

Claro que a realidade não é tão rósea. Para começo de conversa, os dados precisam ser extraídos do Data Vault, preparados e só então consumidos. Isso dá trabalho, mas mesmo assim nem de longe é o mesmo trabalho que dá construir um ETL para um modelo dimensional carregado diretamente a partir da fonte.

É isso. Até a próxima! :-)


Eu rio toda vez que falo Dataváulquila em voz alta. Vamos, tentem! Não me deixem pagando este mico sozinho!… :-D

A Orquídea, o Pântano e o Jacaré

A Orquídea, o Pântano e o Jacaré

10/08/2016 Link para o post.

Mostrei meu post Lago ou Pântano? a um colega de trabalho e ele matou a pau. O comentário dele foi tão interessante que eu resolvi publicá-lo aqui, como uma lição para todos nós.

Mas eu não vou entregar assim de graça, vocês vão ter que ler até lá. ;-)

Data Lake

Você pode ler sobre o conceito direto do pai dele, James Dixon, neste post. Em resumo, DL é uma tecnologia que captura “tudo”, direto para um repositório Hadoop, e que fica disponível para quem quiser usar. Esse paradigma coloca uma série de questões. Por exemplo:

  • Se dados no Hadoop não aceita updates, como lidar com incrementos?
  • Devemos capturar as fontes de dados e seus metadados?
  • Como arquivar as evoluções de layout da origem?
  • Como tratar tempo-real?

E assim por diante. Essas questões, dirão vocês, provavelmente foram resolvidas na cabeça do Dixon, ou então são partes das dores evolutivas de uma nova tecnologia. Não discordo de nenhum destes argumentos. Em TI nada nasce completo, e faz parte do ciclo de vida de cada nova tecnologia se aprimorar e se apurar a cada nova versão.


Estudando para escrever este post eu acabei assistindo este vídeo, que mostra como injetar dados em um Hadoop automaticamente. Preciso admitir que é impressionante. Na verdade, estou morrendo de vontade de testar, mas para um caso de uso muito específico: stage!


O Problema de um Data Lake

Se aqueles detalhes são apenas isso, detalhes técnicos, e não são problemas, quais são os problemas que um Data Lake coloca?

Ora, muito simples. Se ele é mesmo uma réplica de todos os dados de todos os sistemas de uma organização, então ele carrega os mesmos problemas de usar os dados na origem:

  • Sujos;
  • Não-integrados;
  • Não-documentados;
  • Inconstantes.

São exatamente os problemas resolvidos por um projeto de DW, que mira em entregar dados prontos para uso a partir de várias origem. Ou seja, um projeto de DW promete entregar:

  • Dados limpos, prontos para consulta;
  • Integrados;
  • Com uma explicação clara sobre sua função e origem;
  • Imutáveis.

Portanto, ou o projeto de Data Lake incorpora, por definição, um subprojeto de DW, ou o usuário final deve fazer isso tudo sozinho!

Posso ouvi-los cantando meu nome:

“Fábio, Fábio, Fábio, homem de pouca fé! É óbvio que o cliente não está sozinho!”

Não? Então os usuários de Data Lake vão trazer apoio para entender e integrar os dados… De onde? Do sistema de origem, dos próprios DBAs e tals? Bom, se essa é a solução, ok, quem sou eu para desdizer!

Estou zoando, mas a questão é séria. O usuário vai até o DL e, sozinho, escolhe as fontes de dados? Como ele vai saber qual daqueles arquivos contém o dado que ele precisa, ou que é que significa cada uma daquelas colunas e tabelas? E como saber de que forma cada tabela se liga com outras tabelas?

Não tem como se virar sozinho, 100% sozinho, em um curto espaço de tempo. Raramente a informação sobre os dados existe empacotada em algum lugar, à disposição de quem precisar. Geralmente esse conhecimento todo está espalhado em documentos de sistema, na cabeça de DBAs e na cabeça de usuários de cada sistema. Se virar sozinho com o Data Lake implica em gastar muito tempo e, mesmo assim, provavelmente gastaria esse tempo perguntando coisas a quem sabe.

Lembrando que cada novo consumidor deste Data Lake vai repetir os mesmos caminhos. Depois de recuperar os dados, ainda precisa tratá-los de alguma forma – limpando-os e integrando-os – para depois carregar em alguma estrutura que permita a consulta dos dados, o uso destes dados para um propósito qualquer.

É como se trocássemos uma padaria, na qual compramos o que precisamos, por um grande silo que visitamos para comprar o trigo, e depois em casa convertê-lo em pão, macarrão, biscoito etc.


Já pensou que terror??

  • Manhê! Dá um Negresco?

  • Peraí, filhote…

  • Mas mãe, faz duas semanas que você diz “peraí”… Esse biscoito num assa nunca?

  • Assar, até assa, meu filho. E fazer o chocolate para misturar com a farinha para fazer o biscoito, nem foi tão difícil. O diacho é secar o tacho de caldo-de-cana para conseguir o açúcar mascavo para conseguir o açúcar refinado para fazer o recheio com o leite que seu pai trouxe lá da fazenda da Parmalat… E nem pense em pedir bife à parmeggiana de novo!!!

:-D


Até parece Minecraft

Só para constar, o mundo já foi assim. Naquele tempo alguém percebeu que poderia fazer algum dinheiro transformando o trigo em farinha, e outro percebeu que poderia vender macarrão com a farinha do fulano, e assim por diante, até chegarmos neste nosso mundo de Pães de Açúcar, padarias e postos de gasolinha em todas as esquinas.

JÁ PENSOU TER QUE REFINAR PETRÓLEO EM CASA???? :-O

Conclusão

Eis a conversa com meu amigo, regalem-se:

(09:15:36) Fábio: Você entendeu, não?
(09:16:09) Colega/DEPTO: o super-herói precisará entender todas as regras de todas as bases de origem
(09:16:44) Fábio: ISSO!!!!! :-D
(09:17:25) Fábio: É tão bem colocado que eu vou fazer um take dois!
(09:17:26) Colega/DEPTO: vai lá procurar uma orquídea dentro de um pantano!
(09:17:44) Colega/DEPTO: o jacaré vai te comer
(09:17:58) Fábio: quá quá quá!
(09:18:23) Fábio: O nome desse próximo post vai ser A Orquídea, O Pântano e o Jacaré.

Vamos destacar, imprimir e pendurar na parede:


Sobre Data Lakes:

O [usuário] super-herói precisará entender todas as regras de todas as bases de origem. Vai lá procurar uma orquídea dentro de um pântano! O jacaré vai te comer.

Vitor Rosan

Savan Extraordinaire


Falou pouco mas disse tudo! ;-)

Férias = Livros!

Eu sou daqueles nerds (geek, please!) que adora enfiar o nariz em um livro e sair só quando não der mais para segurar a fome ou qualquer outro chamado da natureza. Não deu para fazer isso nessas férias, claro, não consigo fazer isso desde que passei no vestibular. Mas eu consegui começar a ler vários! Achei todos muito interessantes, e recomendo!

Análise Bayesiana

Em Data Mining existem muitas técnicas para analisar dados. Uma das mais úteis é justamente a Análise Bayesiana. Sabendo disso, e tendo criado vergonha na cara, decidi ir atrás de um livro sobre o assunto. Como essa matemática toda me mete medo, eu procurei um com capa fofinha.

Não se deixe enganar pela capa fofa, esse livro morde!
Não se deixe enganar pela capa fofa, esse livro morde!

Grande erro!! É um tijolo com quase 800 páginas, que além de explicar a técnica e a teoria, inclui tutoriais em R, Jags e muitas outras coisas legais. Você pode encontrar o Doing Bayesian Data Analysis na Amazon, tanto em versão física quanto eletrônica, pela bagatela de quase US$100,00.

Brincadeiras à parte, é um livro leve, divertido e inteligente.

O Que É Análise Baeysiana?

Você já leu Sherlock Holmes? Ele tinha um método peculiar para analisar cada mistério: primeiro, examinava as evidências e montava uma lista de hipóteses. Depois testava cada uma delas, tentando validá-la ou refutá-la. Ele sempre dizia que “eliminadas as hipóteses inviáveis, a que restar deve ser a resposta correta, por mais impossível que pareça” e com isso ele sempre chegava a uma resposta. Nem sempre ele acertava, claro, e nestes casos ele voltava ao começo: reexaminava as pistas, montava outras hipóteses e recomeçava.

Esse processo, de listar as possibilidades, e depois calcular as probabilidades de cada possibilidade é justamente a essência do método. Há toda uma matemática envolvida para descrever esse de ciclo, mas tudo que você precisa para entender a matemática é – segundo o autor – saber derivada e integral. Ele parece ser muito bom em te levar por esse caminho, da intuição até a formalização, sem traumas e com exemplos práticos.

Expressões Regulares

Ah, as exaltadamente malditas RegEx! Uma ferramenta tão poderosa quanto xingada! Bom, a Packt abriu gratuitamente, no Free Learning Forever o livro Mastering Python Regular Expressions e eu peguei. Ainda estou nos 50%, mas posso garantir: mudou minha vida. O autor explica a idéia de expressões regulares muito bem no primeiro capítulo. Já li bastante coisa sobre RegEx pela web, mas nunca alguém foi tão claro e conciso. O autor entende muito bem as confusões de quem não conhece nada do assunto e sabe mesmo como evitar as armadilhas de explicação. A clareza cai um pouco no segundo capítulo, mas só primeiro já valeu.

Finalmente um livro que explica bem RegEx!
Finalmente um livro que explica bem RegEx!

Building a Scalable DV

E finalmente consegui separar um tempo para lê-lo com calma. Esse livro é o bicho, o cara, o alfa e o ômega, é tudo – e muito mais! Se você não sabe do que eu estou falando, é bom aprender. O livro é este:

Building Scalable Data Warehouse Vault - O Livro!
Building Scalable Data Warehouse Vault – O Livro!

E pode ser comprado aqui. Ele ensina como montar um EDW usando Data Vault, inteirinho, com tudo dentro – até a pia da cozinha. Não vou colocar os detalhes: baixe uma amostra e leia o sumário para ver tudo que ele inclui.

Se todos os livros do Linstedt até agora eram uma porcaria, esse aqui o redimiu.

Para montar um EDW de gente grande você precisa apenas de dois livros: este aqui e o DW Toolkit, do Kimball. E só.

Mastering Docker

E finalmente o livro que me fez desistir do Vagrant:

Aprendendo Docker. Lentamente. Mais devagar... isso...
Aprendendo Docker. Lentamente. Mais devagar… isso…

Eu ouço falar de Docker já há um bom tempo, mas nunca dei muita trela. Preconceituosamente, achava que era só mais um concorrente no espaço de virtualização. Num destes finais de semana, fuçando no site da Packt, recebi uma pesquisa para responder. No final ganhei um cupom de 75% de desconto, que eu usei para comprar esse livro por 1/4 do preço.

Bom, eu não podia estar mais enganado sobre o Docker.

Sim, ele monta ambientes por meio da virtualização de alguns recursos, mas a similaridade com máquinas virtuais acaba aí. A tecnologia do Docker, chamada de Linux Containers, permite montar ambientes de todo tipo, por uma fração do overhead de virtualização. Ainda que esta possua certas capacidades que a tornam mais apta a necessidades específicas, quase tudo pode ser muito bem resolvido com um conteiner, e o Docker é justamente o engine que movimenta isso.

E o livro? Ele é bom, falando de maneira geral. Ele foi escrito por gente que entende do assunto, não há dúvidas, mas são acadêmicos. Isso tem reflexos no estilo do livro, que é um pouco enrolão. Normalmente esperamos por alguma explicação centrada em exemplos e mais explícita, mais digerida, o que não acontece nesta obra. Pode ser só birra minha, ou pura e simples limitação intelectual (mais provável), mas as coisas importantes me pareceram estar disfarçadas sob uma grossa camada de fraseados elaborados e contorcidos como um arabesco.

No final das contas até dá para pegar as coisas importantes, como por exemplo a distinção entre contêiner e imagem (um é a execução do outro, que é o filesystem do um.) Mas se você espera uma coisa como o livro de RegEx do tópico anterior, recalibre sua expectativa.

Por uma daquelas imensas coincidências, ontem eu descobri um blog mantido por um cara que eu acho que já foi meu aluno, o Alexssandro Oliveira, que dá um excelente exemplo de como subir um servidor Pentaho com Docker. Vale a pena ler: Configurando um ambiente Dev Pentaho com Docker. Eu pretendia montar um exemplo, mas o dele está tão bem-acabado que é até besteira querer fazer melhor. E não é a única coisa boa lá, não! O blog inteiro dele é muito interessante, tanto que eu me inscrevi nele ontem mesmo.

Conclusão

Quem, em 2016, ainda compra ou empresta livros? Em uma era com tanta documentação on-line e gratuita, quem em sã consciência gastaria dinheiro e tempo com livros?

Eu. :-) E não pretendo parar tão cedo! Felizmente eu ganhei o dom de gostar de ler, o que ajuda muito a me mantar atualizado e a aprender sempre mais. Mas se você não faz o gênero CDF-óculos-fundo-de-garrafa (que eu fiz por uns 25 anos), devorador de livros, tente ler ao menos uns dois ou três por ano. Livros vão sempre mais fundo que posts, e em geral são mais fáceis de acompanhar que uma Knowledge Base.

Hoje eu mostrei alguns que vão me ocupar pelo próximo mês.

E você, o que tem lido de bom?

Até a próxima! ;-)

 

Desculpe o Transtorno

… Estamos em obras para melhor servi-los.

Eu sempre quis dizer isso!! :-D

E daí que é um lugar-comum? Nada expressa tão bem o que eu quero dizer. O GeekBI vai passar por algumas mudanças, e isso pode causar algum desconforto. Por favor, aguentem firme!

Eu comecei o blog em 2012, quando decidi criar vergonha na cara e parar de poluir meu outro blog, o Solução em Aberto, com posts de BI. Eu precisava escrever, por mim, para botar as idéias para fora e me livrar das vozes nas minhas cabeças. Ops, cabeça. Vozes é plural mesmo, tá certo. Naquele ano já tínhamos muitas coisas que temos hoje, como smartphones e tablets, mas o layout escolhido, chamado INove, já era antigo. Ele era o tema do blog de um membros-fundadores da Pentaho e eu gostei muito – simples e relativamente “limpo”, cores discretas. Decidi ficar com ele.

Escolhido o tema, configurei o que faltava e vamos que vamos! Desde então eu não mudei nada por aqui, nem mesmo a disposição do widgets, essas seções que dividem na página espaço com cada post. Para vocês terem uma idéia, só hoje eu traduzi a mensagem para assinar a lista de comunicados do blog, que eu chamei de Stalk me.

Nossa, eu fui tão sem-noção! Eu configurei tudo meio na gozação, sendo diferentão… Era só para mim, mesmo, eu pensava. Ninguém vai olhar, eu dizia a mim mesmo…

Aos poucos apareceram meus fiéis leitores, que semana após semana voltam aqui, prestigiando minhas mal-traçadas linhas com suas visitas.

E daí vieram os livros! Agora além de leitores, eu tenho clientes, pessoas que pagaram para ler algo que eu escrevi.

Não dá mais para continuar com um tema tão simplório, que nem sequer suporta dispositvos móveis. Não dá mais para deixar a cargo do WordPress.com a notificação sobre novos posts. O layout precisa melhorar, o tratamento dos visitantes, o reconhecimento dos meus clientes…

Então é isso: nessas próximas semanas várias mudanças vão acontecer. Provavelmente o blog vai mudar de cara algumas vezes, as seções vão mudar de lugar, e até a forma de falar com vocês vai sofrer um upgrade: eu abri uma conta no MailChimp, uma ferramenta on-line (é nuvem que se diz hoje em dia, velho!) de mala-direta, pensando em formas de melhor servi-los.

Vamos ver se eu consigo. Até lá…

Teste

:-)