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. 
Anúncios

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.][post_bitly]

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


10/10/2016 08:10:41Complemento

Cheguei no trabalho, abri meu IM e pulou:


(05-10-2016 17:14:06) Vitor: boa tarde
(05-10-2016 17:14:20) Vitor: está ocorrendo aquilo que você profetizou no seu blog, sobre o datalake
(05-10-2016 17:14:55) Vitor: tem muitas pessoas tentando obter dados da base do dw recorrendo a mim para explicar como achar o caminho no meio do pântano


Reparem que ele comenta sobre a minha “professia” do Data Lake, mas depois fala do DW. Eu não entendi na hora, mas a explicação é simples: ainda nem entrou o Data Lake no ar, nem começou, e o problema de entender os dados já está acontecendo em um DW normal, com gerenciamento insuficiente.

Imagine no Data Lake? :-D

 

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

:-)

Vaga para Consultor Pentaho

A quem interessar possa:

A Source2IT busca um profissional para atuar como Consultor de BI/Pentaho
Requer experiência com Pentaho (ETL e Suite BA) para atuar em cliente na região de Campinas
Interessados enviar currículo para taniellen.machado arroba source2it.com.br

Notem, por favor, que eu não tenho nenhuma associação com a Source2IT ou com o dito cliente (que eu nem sei quem é – portanto não adianta me perguntar.)

Coloco esta vaga aqui para dar uma mão a quem estiver precisando. MAS LEMBRE-SE: não tenho nada a ver com essa vaga ou as empresas. ;-)

Quarta-feira tem post novo, com o tema “O que fiz nas férias”. :-D