Latinoware 2015 – Apresentação

Conforme prometido, eis aqui link para palestra apresentada na Latinoware 2015.

Slide de abertura da apresentação.
Slide de abertura da apresentação.

Opinem! ;-)

Anúncios

Latinoware 2015 – Eu Vou!

Ora, quem diria, eu fui convidado à participar da Latinoware 2015! :-)

Meu perfil no site da Latinoware. Preciso melhorar essa foto...
Meu perfil no site da Latinoware. Preciso melhorar essa foto…

Minha palestra será “Inteligência Institucional para o Governo Digital”:

Minha palestra na grade: 10H00min @ 15/10/15.
Minha palestra na grade: 10H00min @ 15/10/15.

Eu vou mostrar como as tecnologias atuais – com 100% de Software Livre – habilitam a construção de um Armazém de Dados de proporções continentais. Por falta de nome melhor ele chama-se Armazém de Dados Governamental (ADG ou GDW) e pode ser construído para qualquer esfera de poder: municipal, estadual ou federal.

Consegue imaginar 27 ADGs estaduais integrados? É como construir a Matriz: vai estar tudo lá dentro!!

Semana que vem, dia 15/10/2015 às 11H00min (logo após a palestra), a apresentação estará disponível em PDF aqui no blog.

Vejo vocês por lá!

Minérios & Dados – Parte 1

O ápice da disciplina de Business Intelligence é criar valor com Data Mining. Mas como isso acontece? Qual é o entregável de um projeto de Data Mining? Como explicar isso a pessoas de outras áreas, leigas em Business Intelligence?

Acho que eu descobri como. Preparado para mais um longo post? Café na mão? Tempo de sobra? (há-há…)

Mineral, Mineração, Mina

Você já viu uma mina surgir?

Primeiro, não há nada: floresta, mata, rios, colinas, montanhas. Nada na acepção humana da coisa, claro.

Vários especialistas chegam e analisam o solo – composição química, camadas, história geológica, ultrassonogragia, sismogramas.

Em certo ponto concluí-se que ali há um potencial de exploração mineral, e uma mineradora assume o negócio: contrata equipe (gestores de todo tipo, operadores de máquinas e sistemas), quota e compra o material necessário para o início das operações.

Aí o vespeiro começa a zumbir: operações de deslocamento e assentamento são montadas, materiais são movidos até lá, pessoas são transportadas e alojadas. Já não é mais o nada da Natureza, a paisagem começou a se modificar e as primeiras marcas da mudança ficam visíveis. Até então, figurativamente, ocorria tudo no subterrâneo, e apenas os patrocinadores e diretores da operação saberiam que estava em curso um negócio. Até agora, ainda, só investimento e pouca coisa concreta.

Conforme o tempo passa, as equipes progridem, abrindo valas, cavando e escorando túneis. Rotas de escoamento futuro são definidas e seguradas, seja por meio de compra de terreno ou manutenções em estradas, ramais rodoviários e hidrovias. As primeiras máquinas de processamento de minério começam a funcionar, e os primeiros carregamentos são extraídos da mina. Talvez anos tenham se passado, e só agora começam a sair os primeiros resultados e sabe-se lá quantos e quais contratempos ou “novidades” foram enfrentados pelo empreendimento. Pode ter havido “revolta” da Natureza, instabilidade de Governo, reviravoltas na economia, problemas trabalhistas, acidentes, limitações financeiras e tecnológicas… Murphy teria orgulho da lista de coisas que podem dar errado em uma aventura destas!

Do 'nada' à mineração.
Do ‘nada’ à mineração.

Muito tempo depois de os peritos dizerem que ali, naquele ponto, era possível extrair minério deste ou daquele tipo, a esta ou aquela taxa, provendo um certo faturamento, a promessa se realiza. O negócio está a pleno vapor, produzindo com eficiência e gerando os dividendos almejados.

Hora de descansar.

Será?

Há! Nem de longe!

É preciso manter tudo funcionando – trocar peças, repor consumíveis, atualizar equipamentos e pessoas, expandir ou contrair em função do mercado. Renegociar dívidas, replanejar investimentos, desembaraçar-se de problemas legais – não tem fim! É uma empresa humana a pleno funcionamento! Só haverá descanso quando o último empregado apagar as luzes, fechar a porta e virar as costas, deixando para a Mãe Natureza cuidar da baderna feita pelos “filhos”. Hehe. Deve ser por isso que chamamos Mãe Natureza e não Cunhado Natureza. Kkkkk….


Outra forma de coletar recursos minerais é por meio de um garimpo. Não vou digredir sobre a diferença entre os dois, mas eu vejo garimpo como uma operação muito mais manual, e de menor escala, do que uma mina, em que se conta com mais automação e se produz volumes maiores. Mas eu não sou versado no assunto e essa aqui é só a minha opinião. ;-)


Garimpagem de Dados

Eu estava pensando (de novo ou ainda, a obsessão não me deixa largar o osso) no problema que me foi colocado no trabalho:

Qual é o produto?Puxa, como assim? O produto é a porcaria do modelo, do algoritmo, oras! >:-/

Estou indo rápido demais, sorry. Vamos do início.

A empresa na qual trabalho precisa criar novos produtos, abrir novos mercados e incrementar o faturamento. Não precisa ter passado 15 anos no mercado de BI para saber que, se você cuida das operações mais importantes de um grande ecossistema, você está sentado em uma montanha de negócios em potencial. Todos aqueles dados, interpretados, contam histórias fantásticas, que valem dinheiro não apenas pelo que informam, mas pelo que ajudam a poupar e melhorar a qualidade das operações.

Vários projetos de Data Mining foram iniciados com vistas a extrair esse valor todo, melhorar a segurança econômica da empresa e ajudar os clientes (ou “O” cliente, como queira) a operar melhor, gastando menos, melhor e entregando mais, com mais qualidade.

Mas eis que batemos num iceberg e a idéia de usar Data Mining começou a fazer água: o que é o produto? O que eu instalo? Que tela o cliente vai ver no final? A imensa maioria dos profissionais de TI e executivos estão acostumados com bancos de dados, telas, relatórios. Quando se fala em BI com esses profissionais, se entrou no ramo nos últimos dez anos, vai pensar em dashboards e Data Discovery; se for da antigas, pode pensar em OLAP e dados consolidados. Raramente se ligam no que, de fato, é BI: Ciência a serviço dos negócios.

É aqui que a história da mineração do começo se liga – e é onde eu tenho falhado na comunicação.

O produto é claro: o resultado de um projeto de Data Mining é um modelo matemático, que vira um algoritmo e é, literalmente, programado nos sistemas. A partir daí o sistema, sozinho, começa a tomar as decisões. Lembram daquela história toda de DSS e BI? Pois é: uma solução de Data Mining faz exatamente isso, toma decisões sozinha. Decide se o cliente merece crédito, se esse ou aquele produto deve ser oferecido, se essa ou aquela declaração deve ser auditada etc. etc. etc.

Na Passarela, O Modelo!

Veja:

'Modelo' matemático da atração gravitacional.
‘Modelo’ matemático da atração gravitacional.

Se você jogar uma pedra para cima, ou um foguete, ou uma vaca, todos eles vão voltar à terra sofrendo uma força F calculada por essa fórmula.

Se você for um piloto de moto, pode calcular que aceleração a é preciso imprimir a seu bólido para fazer o percurso S da pista no tempo t que ele desejado:

'Modelo' matemático da posição de uma moto em uma pista de corrida reta.
‘Modelo’ matemático da posição de uma moto em uma pista de corrida reta.

Se a pista tiver 1 Km e o piloto quiser fazer isso em 10 segundos:

Resolva para encontrar a aceleração que a moto deve ter para fazer 1 Km em 10 segundos.
Resolva para encontrar a aceleração que a moto deve ter para fazer 1 Km em 10 segundos.

Para os preguiçosos: a = 20 m/s2.


Para você ter uma idéia de quanto isso é, a gravidade (a aceleração que te força a ficar no chão) é de ~ 9,8 m/s^2 (ou Pi ao quadrado, como dizia meu eterno orientador, Prof. Carlos Lenz Cesar.)


E, é claro, você pode fazer o contrário: pode usar o modelo para descobrir a aceleração, conhecendo o tamanho da pista e medindo o tempo do início ao fim. Ou medir o tamanho da pista se souber o tempo e a aceleração. Essa é a graça de um modelo matemático: ele correlaciona variáveis e permite que analisemos o que acontece com uma em função da variação de uma outra qualquer. Ah, aproveitando o gancho, vale lembrar que é por isso que precisamos de Data Mining: um ser humano não consegue “enxergar” essas correlações “à olho nu”, só plotando uma coisa em função da outra. Primeiro porque qualquer coisa mais complicada que uma reta já é muito complexa. Veja a curva da moto acelerando:

Gráfico da posição da moto. Consegue usar isso para prever a posição se a aceleração mudar?
Gráfico da posição da moto. Consegue usar isso para prever a posição se a aceleração mudar?

Segundo porque se com duas variáveis (t e S) já não é fácil, imagine com 20 ou 200?

Qual é o Produto?

O produto é claro um ovo! É claro para mim, que vivo, como e respiro BI, e sou um cientista desde criancinha (literalmente, hehe.) Nem de longe é claro para outrem!

O produto de um projeto de Data Mining é como o produto de uma operação de mineração: ele não existe antes, é subterrâneo por um tempão e, definitivamente, acima de tudo, não é uma geladeira, que ligamos na tomada e começa a produzir. E para piorar, o resultado de uma operação de mineração é – adivinhe!! – minério! E daí? Puxa, você já comprou pirita para birita, ou viu alguém pilotando um balde de bauxita?? Não? Sabe por quê? Porque minério, assim como o “produto” de um projeto de Data Mining, é um insumo para outra coisa! Ferro para carros, tinta de ouro para terminais elétricos, lítio para baterias, nitrogênio para refrigeração, carbono para uma infinidade de coisas! É como petróleo: extrair é o começo, pois muito precisa ser feito para tornar disponível o poder daqueles hidrocarbonetos complexos até que um carro possa sair andando, sozinho por aí, usando gasolina. Foi preciso inventar algo (em 1886) que se aproveitasse a [gasolina][gas_bitly] (1870) para ela ter o valor que tem, aliás.

Sei lá, entende?! Padaqui, padali. Padicá, palilá.

Grande Orival! Até hoje eu uso seu famoso “sei lá, entende?”, rio só de lembrar…

Bom, o tal do Patropi, personagem do Orival, era um estudante de comunicação que, no fundo, comunicava porcaria nenhuma. Era todo enrolado e vivia confundindo tudo.

Sempre que eu preciso falar de Data Mining eu me sinto meio Patropi: sei lá, entende? Afirmar “o produto é o modelo”, por mais sintético e completo que possa ser, é pouco para explicar o mundo que existe por trás. Mas quando eu começo a desfiar – tem o sistema de origem, daí a necessidade de negócio, e o problema, e então a análise, a modelagem blá blá blá – eu perco a platéia!

E acho que eu finalmente entendi como comunicar isso.

Contando a história da mineradora.

Veja:

  1. A mina não existe até ser criada, como o projeto de Data Mining: não é como um aparelho, um produto, que se compra e usa. Data Mining não é uma melhoria em algo que existia antes, é um novo projeto!
  2. Um projeto de Data Mining está para um sistema transacional da mesma forma que uma mineradora está para uma fábrica de qualquer coisa: são empreendimentos bem separadas um do outro, com vidas independentes;
  3. Assim como um projeto de Data Mining, uma mineradora não gera um artefato pronto para consumo, mas sim um insumo para outra parte da supply chain, a cadeia de fornecimento: o modelo. Mas não um modelo de tabela ou de banco de dados, e sim um modelo matemático, como o que idealiza a realidade e ajuda a entendê-la;
  4. A mina é o produto do projeto da mineradora; o produto do projeto de Data Mining é o modelo. A exploração da mina produz minério, a exploração do modelo produz decisões;
  5. Clientes da mina pagam pelo minério, e vendem produtos acabados; clientes de Data Mining pagam pelo modelo e geram valor (“vendem”) a partir de decisões automáticas.

Agora Vai! O Produto é…

Como eu já coloquei, o produto de um projeto de Data Mining é um modelo matemático. Esse modelo vai ser usado para gerar valor tomando decisões de negócio automaticamente. Como isso vai ser feito depende muito de qual problema está sendo resolvido.

Talvez esse seja um ponto de debate: o produto é o modelo, ou a aplicação dele? No meu entendimento, aplicar o modelo para gerar valor é o resultado (o produto, portanto) de outro projeto, ou do trecho final do projeto de Data Mining. As técnicas de Garimpagem de Dados foram aplicadas até chegarmos no modelo. O uso dele em produção pode, sim, gerar dados que realimentados no projeto de Data Mining refinam o modelo, mas a integração com o sistema transacional é feita por meio de outras artes. A competência dos profissionais de Mineração de Dados acabou bem antes!


Acho que, a esta altura, você já notou que o falado Data Scientist é ninguém menos que o Analista de Data Mining.


E como um modelo pode ser integrado a um sistema on-line, transacional? De diversas forma, como por exemplo:

  • Vendas: a clássica solução de CRM. Neste caso o modelo é programado em uma solução de campanha de Marketing, e passa a gerar as sugestões de produtos ou ações para cada prospecto ou cliente. Você vê esse sistema em ação sempre que visita uma loja eletrônica e recebe sugestões baseadas no seu perfil;
  • Crédito: um banco opera em cima de diversos sistemas, como cadastro de correntistas, gestão de conta-corrente, gestão de carteiras de produtos e assim por diante. A equipe de Data Mining trabalha com a equipe de sistemas para criar um módulo que aplica o modelo (chamado de credit scoring, pontuação de crédito) aos clientes. Esse módulo pode então ser usado em vários sistemas, como ATM (onde você pode receber um valor de crédito instantâneo), gestão de empréstimos (para avalizar o negar a operação solicitada pelo cliente), vendas, no qual o modelo do CRM usa o resultado do modelo de credit scoring para selecionar clientes a que oferecer empréstimo e assim por diante;
  • Seguro: a equipe atuarial (que constrói o modelo) trabalha com a equipe de marketing para calcular os riscos de cada público para cada produto, e com isso derivar a lista de preços. Neste caso o modelo não vira um programa on-line.

Nos casos acima os modelos gerados pelos projetos de Data Mining foram usados para realimentar os sistemas transacionais da empresa com o conhecimento apreendido dos dados. Exatamente da mesma forma que o minério extraído pela mineração vai ser refinado em um produto final.

Será que ficou mais claro agora? ;-)

Como Um Data Vault Evolui II

Em vários posts (Data Vault Para Quê?, Introdução à DV e Como um DV Evolui) eu falei sobre as vantagens em se ter um Data Vault no miolo do seu projeto de Data Warehouse Corporativo. (E eu também expliquei porque um DW é importante neste outro post.)

Hoje eu vou mostrar uma destas vantagens em ação: como um DV evolui quando a fonte de dados muda.

Cenário

Em julho de 2013 a equipe de desenvolvimento do DW Corporativo do SERPRO estava com um problemão: não conseguiam formular o modelo dimensional adequado à uma necessidade específica do cliente. Me convocaram a trabalhar no projeto e, depois de umas duas semanas apanhando “que nem” cachorro magro, eu consegui resolvê-lo. Ajustei o modelo, repassei os conceitos com a equipe, para evitar novos problemas do tipo, e saí do projeto no início de 2014.

Nessa época a arquitetura do projeto era a mais padrão possível, igual à de qualquer outra empresa:

Arquitetura original.
Arquitetura original.

Ou seja, os vários sistemas de origem eram lidos e partes de seus dados copiados para dentro de um outro banco de dados. Esse banco fazia algumas agregações, algumas integrações e produzia dados combinados. Esse banco não tinha o perfil de um palco (stage), apesar de concentrar dados, e por isso eu prefiro chamá-lo de ODS, ainda que também não se encaixe na perfeita acepção do termo. Finalmente, várias estrelas dimensionais eram populadas a partir da colagem que era esse ODS.

Eu construí a solução para a demanda do cliente em cima desta arquitetura, e percebi mais tarde que o que eu encontrara era, no fundo, a raiz de um modelo do tipo do Data Vault. Animado, eu redobrei meus estudos sobre DV, e no início de 2014 eu pude aplicar o que estava aprendendo para montar um DW na empresa de um amigo. Eu poderia ter feito tudo com Modelo Dimensional, mas seria uma boa chance de testar Data Vault. Deu muito certo: não apenas eu consegui desenvolver tudo em tempo recorde, como ainda criei um conjunto de templates, um processo de modelagem e um processo de desenvolvimento de ETL, que mais tarde foi usado no primeiro curso de Data Vault no Brasil.

Em novembro de 2014 eu voltei a ser alocado ao DW do SERPRO, para atender uma demanda, outra estrela, parada há alguns meses por falta de gente. Só que, desta vez,me deram a liberdade de aplicar meus conhecimentos de Data Vault e não perdi tempo:

Arquitetura com o Data Vault.
Arquitetura com o Data Vault.

Ou seja, meu novo ETL buscava no ODS os dados levados para o Data Vault, e deste um outro ETL partia com os dados para uma estrela de apresentação. Como meu DV foi preparado para se ajustar ao Data Mart Dimensional, eu não precisei refazer nenhuma das dimensões que já existiam. Criei apenas uma nova fato e uma junk, que agregava várias flags e voilà, tudo pronto.

Resumidamente, eu 1) construí o modelo DV, 2) construí o modelo da nova estrela, 3) gerei o ETL do DV automaticamente e 4) criei o ETL para estrela na mão. Levou um mês, mais ou menos, e eu produzi tudo com documentação e processo. Nada de improvisos – não gerei um único débito técnico. Tanto que eu fui embora e deixei-o rodando. Deixei-o não: eu esqueci completamente que ele existia.

Tudo Muda

Eu esqueci, mas o cliente não. Esse “remendo” está funcionando desde então, há mais de seis meses, diariamente, sem ter sofrido uma única parada causada pelo ETL do DV ou dali para o dimensional.


(…)sem ter sofrido UMA ÚNICA PARADA causada pelo ETL(…) Sabe, acabei de me tocar disso e estou profundamente impressionado. Caraca, NUNCA deu pau!! O ETL para o DV parou algumas vezes, mas sempre por causa de problemas gerais, como instabilidade de rede ou pau do banco, nunca por causa de erros imprevistos, e nunca teve nenhuma inconsistência de dados. :-O C-A-R-A-C-A!!…


Voltando: desde de o ano passado que esse ODS vem sendo desativado, pois ele é complexo demais e seu ETL sofre paradas demais (sem contar inconsistências de dados, quando o ETL vai até o final.) Uma nova iniciativa de DW corporativo foi montada (pfff…) e começaram de novo (eu já vi essa história antes…). Decidiram não fazer nenhum modelo: se antes o ODS fazia alguma integração, agora teríamos um palco persistente (PSA, de Persistent Staging Area.) A partir desse PSA as estrelas de consulta eram populadas. Ou seja, se antes a integração acontecia na entrada do ODS, agora ela acontece na saída do PSA. Enfim…

Como disse Otis, as coisas mudam, sempre mudam. Há uns dois meses chegou a hora de desativar o pedaço do ODS que servia de fonte para meu DV. Era preciso migrar o meu Data Vault do ODS para os sistemas de origem, e precisava ser uma migração à quente, sem parar de rodar e sem refazer nada. Não seria possível, por exemplo, analisar as tabelas dos sistemas de origem que compunham o ODS e refazer quaisquer hubs, links ou satélites.

Vem Quente…

A arquitetura após a migração da fonte ficaria assim:

Alteração de fonte do Data Vault.
Alteração de fonte do Data Vault.

Aqui há outro problema embutido: as tabelas que existem nesse ODS são quase as mesmas que existem nos sistemas de origem. Ou seja, se no sistema de origem existe uma tabela produto, no ODS vai existir uma tabela tb_pro_produto. Se essa tabela, na origem, possui 10 campos, no ODS vai possuir 9 ou 11 ou 30 campos. Grosso modo, porém, o conteúdo do sistema de origem existe no ODS quase intacto. Logo, para usarmos os sistemas de origem no lugar do ODS é preciso analisar a correspondência entre as tabelas.

Para cada tabela do ODS que o Data Vault consultava haviam três possibilidades:

  1. Equivalência direta: no máximo o nome da tabela (ou de uma de suas colunas) muda;
  2. Praticamente a mesma coisa: sem contar o nome da tabela, o conteúdo era praticamente o mesmo. As diferenças seriam um nome de coluna diferente, uma coluna a mais ou a menos, mas o mesmo grão: se na origem existissem 1000 registros, o ODS teriam 1000 registros, equivalentes um a um;
  3. Tabelas equivalentes: meu Data Vault usava uma tabela no ODS que era resultado da combinação de duas ou mais tabelas do sistema de origem.

O melhor caso é o primeiro, pois a mudança no Data Vault resumir-se-ia a trocar os parâmetros de conexão para apontar para o novo banco e, talvez, mudar um nome de tabela ou coluna.

O segundo caso também não seria difícil: para cada link, hub ou satélite que usasse esse tipo de tabela bastaria reescrever um único SQL, e mudar a conexão do ODS para o novo banco, e as transformações estariam migradas.

Já o terceiro caso seria o pior. Haveriam duas situações possíveis:

  1. A tabela equivalente dentro do ODS derivava de várias tabelas de uma única fonte de dados. Ou seja, é possível construir um SQL, ou talvez uma procedure mais complexa, que remonta a antiga tabela a partir das tabelas do sistema de origem. Esse novo e complexo SQL seria o novo SQL de cada transformação de hub, link ou satélite, que junto com a mudança de fonte de dados completaria a migração;
  2. A tabela equivalente dentro do ODS derivava de várias tabelas, de duas ou mais fontes de dados. Ou seja, como um SELECT (ordinariamente) não cruza as fronteiras de bancos, e muito menos de tecnologias de bancos, não seria possível construir um SQL para replicar a tabela do ODS. Seria necessário uma transformação intermediária, que unisse esses dados e entregasse-os para as transformações de carga de hubs, links e satélites.

Na pior das piores hipóteses, poderíamos criar uma tabela intermediária, em um palco, e usá-la para carregar o DV.


A migração de fonte de dados de um DV vai de algo tão simples como mudar um IP e uma senha, na conexão com um banco de dados de origem, a algo complexo e trabalhoso como reconstruir parte do DV ou criar etapas de carga intermediárias. Em qualquer situação, porém, sempre haverá uma saída e ela nunca vai quebrar o downstream, o lado do cliente.


…Que o DV Está Fervendo!

Fizemos – a equipe de desenvolvimento do DW e eu – uma áudio-conferência há umas três semanas atrás. Em menos de duas horas eu expliquei o que era DV, o básico de como se construir um e como o trecho do DV funcionava. Depois expliquei exatamente os mesmos pontos acima, mostrando que, quanto mais complexa for a origem do DV, maior vai ser o trabalho de migração.

Bom, o trabalho de migração (já!) acabou! O pior caso foi o de umas tabelas que combinavam coisas de um mesmo sistema, mas sem alterar o grão, de modo que mesmo o pior caso foi muito fácil de fazer.

Não estamos esquecendo de nada?…

Sim! E o data mart populado pelo DV? Você consegue chutar o que deve ter acontecido com ele, e com o ETL do DV para a estrela?

Simples, não aconteceu absolutamente nada. Veja, apenas alteramos as entradas do Data Vault, e nada mais. Assim, o ETL que rodava sobre o DV para popular a estrela que o cliente usava continuou como estava!!

Conclusão

Um Data Vault carrega grandes promessas:

  • Carregar 100% dos dados, 100% das vezes (regra de ouro do DV;)
  • Acomodar qualquer mudança dos sistemas de origem, sem quebrar;
  • Permitir exploração dos dados como o cliente quiser, sem quebrar;
  • Reduzir o trabalho de desenvolvimento e manutenção, automatizando sempre que possível;
  • Reduzir e até eliminar retrabalho;
  • Grande velocidade de carga.

O primeiro artigo, Como um Data Vault Evolui, mostrava o que acontece com um DV quando uma premissa inicial se mostrava incorreta, e como ele se acomoda elegantemente os ajustes necessários. Este post mostrou de que forma uma mudança profunda como a troca de fonte de dados é tratada por um DV. Ainda que tenhamos tido sorte com um ODS que não era complexo demais, todas as mudanças ocorreram em questão de semanas, sem quebrar o dia-a-dia do cliente.

E ele continua rodando sem parar há seis meses! :-D

Big Fragging Gun!

O problema que define a nossa época corrente, em BI, é o grande volume de dados. Parece que todo o restante é um problema secundário quando alguém joga as palavras BigData na sala.

Como reinar sobre eles? Como manter uma vida pessoal, ser um profissional de BI de sucesso e mesmo assim conseguir atender às necessidades gasgantuescas de acúmulo de dados e – pior ainda – análise desses?

Conseguindo uma Big Fragging Gun for BI. ;-)

BFG

Quem é velho (ou novo) o bastante para ter jogado muito video-game vai se lembrar de um jogo chamado Doom. Nele havia uma arma, a Bio Force Gun, ou BFG, que disparava o tiro mais poderoso do jogo. Ninguém nunca a chamava de Bio-Force Gun, mas sim de Big F****** Gun, por que ela arrasava (hehe) tudo no caminho. Nada resistia à ela.

Big Fragging Gun!
Big Fragging Gun!

Quando você tem um problema muito grande, você o resolve com ferramentas ainda maiores.

Em 28/04/2015 eu proferi uma palestra no SERPRO exatamente sobre isso: como resolver um problema do tamanho do governo federal brasileiro?

Usando uma ferramenta maior. >:-)

O Tamanho da Bagaça

A IBM é uma das maiores empresas do mundo, e tem cerca de 400.000 empregados em 2015. A esfera federal do governo brasileiro emprega mais de 1.900.000 pessoas.


Permitam-me frisar: UM MILHÃO E NOVECENTAS MIL pessoas. Dá quase cinco IBMs (e olhe que uma IBM existe no mundo inteiro. Estamos falando de quase cinco dessas, circunscritas ao Brasil.)


Se cada uma dessas 1.9M pessoas gerar duas linhas de dados por dia, dá quase quatro milhões de dados só sobre o próprio governo, por dia.

Quatro milhões? Pff, dirão meus leitores, que sabem que eu chamo fato com 10 milhões de linhas de pequena (pequena, para mim, era um milhão, mas é um número tão carne de vaca – qualquer coisinha já gera um milhão de linhas – que eu precisei atualizar esse meu patamar.)

Bom, uma parte considerável desse contingente todo – quase 2 milhões de pessoas – opera os sistemas que movem o governo federal, e que fazem o governo federal mover as coisas no Brasil. É um mundaréu de gente e dados: começa por orgãos como a Receita Federal, o Tesouro Nacional e o Ministério do Planejamento, que detêm o grosso do trabalho informatizado, vai até fundações como a Biblioteca Nacional e diversos museus, e passa por universidades, hospitais, todas as forças-armadas, ONGs etc. etc. etc.

Não há Teradata que aguente, na boa.

O Tamanho do Problema

Preciso dizer mais?? Cada empresa já sofre um parto para montar um punhado de estrelas para análises, imagine cruzar dados entre empresas! E fazer isso oferece capacidade real e imediata de ganhos para nós, pagadores de impostos.

Se um ministério tem um custo de infra-estrutura, e todos os ministérios tem custos semelhantes, temos muito a ganhar em gestão entendendo esses gastos e buscando oportunidades de economia. Aproveitando um tema que anda pela moda, o potencial de terceirização – com ganhos de produtividade, qualidade e custos – são gigantescos!

Mas não compre ainda!

Como uma mega-instituição, complexa, pesada, coisas mais sutis passam completamente despercebidas! Você consegue imaginar a quantidade de perdas, desperdícios, erros e fraudes que pode acontecer em um sistema composto por tantos sistemas, e cada um com sabe-se lá quantas partes móveis? Todos esses dados, consolidados, integrados e deduplicados, se analisados com critério, podem mostrar muitas oportunidades de melhorias.

E se pudéssemos integrar os dados financeiros aos dados do DNIT? E se pudéssemos colocar lado-a-lado os dados das polícias de todo país e dos hospitais? Pense nos dados dos ministérios da Saúde, do Trabalho, da Fazenda, unidos! O que isso não poderiam nos dizer?

Como se não bastasse, de onde saem os parâmetros para definição de políticas? De onde tiramos que um projeto social está dando o resultado desejado, ou uma política de estado está tendo o efeito planejado?

Para arrematar, no meio de todos esses dados operacionais do Governo Federal existem os nossos dados, aos quais a Lei de Acesso nos granjeia acesso livre e imediato.

Conseguem ter uma noção da monstruosidade que é coletar e integrar todos esses dados, quiçá analisá-los??

Inteligência Institucional

Eu diria que ser um Governo Eletrônico é ser capaz de fazer mais que informatizar e automatizar os processos. Ser um Governo Eletrônico é ser capaz consumir esse planeta de dados para melhorar a si mesmo e para entregar serviços melhores. (Oceano de dados agora me parece uma coisa muito pequena. Já, já eu vou estar falando de Sistema Solar de Dados, ou Pequena Nuvem de Magalhães de Dados, hehe.)

Malgrado as dificuldades do mundo real, conseguir a capacidade de acumular e analisar esses dados é um imperativo para qualquer instituição, e um imperativo ainda mais forte para uma instituição tão central a um nação quanto seu Governo Federal.

Soluções

Tradicionalmente, uma solução de BI que analise os dados da empresa inteira tem esta aquitetura:

Arquitetura tradicional de EDW.
Arquitetura tradicional de EDW.

Ou seja, existe um banco de dados (relacional, quase sempre) que serve como Enterprise Data Warehouse (EDW ou Armazém de Dados Corporativo.) Quase sempre, também, esse EDW armazena os dados em um modelo dimensional, composto por uma coleção de estrelas (conjuntos de tabelas dimensão ligadas a uma fato.) Cada estrela representa um assunto dentro da empresa, e as estrelas são integradas via um barramento de dimensões conformadas.

Finalmente, um processo de ETL cuida de ler os dados na origem, limpá-los, arrumá-los, integrá-los e finalmente depositá-los no banco de dados, no EDW.

Uma empresa de porte médio, talvez até grande, pode conseguir viver com um EDW assim. Mas o modelo dimensional funciona bem para analisar, para explorar os dados, não para armazená-los eternamente, muito menos para integrá-los. Tanto é assim que a integração é feita pelo processo de ETL.

A partir de um certo ponto, essa estrutura colapsa sobre o próprio peso e se torna impossível de receber manutenção. Em bom informatiquês, torna-se imanutenível.

E esse não é o único galho dessa abordagem, não senhor! Que tamanho você acha que um banco de dados relacional, por mais parrudo que seja, consegue atingir? Você consegue imaginar uma tabela em um Postgres ou Oracle ou Teradata recebendo gigabytes e gigabytes diariamente, por meses, anos, décadas?? Nem eu!

Mas há soluções para cada um destes problemas.

A mais fácil é o volume de dados. Um cluster Hadoop consegue armazenar uma quantidade razoavelmente (petabytes) grande de dados, com performance de consulta aceitável, a um custo viável por gygabyte. Não vou entrar em detalhes aqui pois há muito sobre isso na web.

Sobrou a outra ponta: acumular e integrar esses dados.

A solução não fácil, ou mágica, mas existe: Data Vault. Veja essa arquitetura:

Arquitetura de EDW adequada a mega-empresas.
Arquitetura de EDW adequada a mega-empresas.

Ela propõe um EDW baseado em Data Vault, armazenado em um cluster Hadoop.

Isso resolve dois grandes problemas de uma vez:

  1. Integração: o modelo de dados de um Data Vault integra os dados. Quando uma nova fonte é incorporada ao EDW do Governo, o GDW (Government-sized Data Warehouse), os dados redundantes já entram nas tabelas pré-existentes e apenas os dados novos entram em tabelas novas. O processo de ETL, por outro lado, passa a ser completamente “burro”, pois vai apenas mover os dados novos dos sistemas de origem para dentro do EDW;
  2. Manutenção: a inclusão, alteração e remoção de fontes de dados, bem como a integração entre as fontes, passa a ser uma atividade padronizada, organizada e repetível. Acaba o pesado de inconsistência entre dimensões “parecidas mas diferentes”, comuns em DWs dimensionais.

Fábrica de Dados

A minha proposta nada mais é que a reedição do conceito de Fábrica de Informações Corporativas do Bill Inmon, com um Data Vault no meio, e com dados gravados em um cluster Hadoop. Isso mesmo: nada de novo. Já poderia ter sido feito há anos. Talvez até há mais de uma década, já que outra vantagem do Data Vault é a relativa facilidade de migração de fontes de dados. Ainda teria havido um bom retrabalho passar de um Data Vault 1.0, típico em bases relacionais, para o Data Vault 2.0, adequado ao Hadoop, mas nada teria sido intransponível.

Lei de Acesso à Informação

E como fica o atendimento à Lei de Acesso à Informação neste cenário?

Consideravelmente mais simples:

  • Ao invés de cada orgão ter que atender à demandas em separado, um único centro de dados do Governo faria isso;
  • Novas demandas de inclusão passam a ser tratadas uma única vez, em um único ponto: se um orgão pode atender seus pedidos de acesso à dados com dados já capturados por conta de outra demanda dos mesmos dados;
  • O pedido de novos dados, ainda não coletados, entra em uma linha de produção muito mais previsível e estável que a loucura tradicional de montar um serviço para cada demanda, em cada orgão.

E é claro, essa integração daria um poder fantástico ao gestor público.

Conclusão

Você pode baixar o PDF da apresentação clicando aqui e ver um pouco mais de argumentação. Esse material nunca foi aproveitado para nada dentro do SERPRO, e foi criado por mim mesmo por puro diletantismo, em meus períodos de lazer. Eu cheguei a propor como um produto, mas haviam outras coisas mais interessantes ou urgentes.

Pensando um pouco, acho que essa solução não precisa se limitar à esfera federal. Seria relativamente simples construir o mesmo em esferas estaduais e municipais, e integrá-las.

Lavando Louça (ou Paz, Afinal III)

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

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

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

Try to See the Truth:

There Is No Spoon.

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

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

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

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

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

Simplesmente

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

Porque simplesmente faz sentido.

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

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

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

Simplesmente:

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

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

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

Até a próxima.


 

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

Book Review – Practical Change Management

I work supporting and developing Business Intelligence solutions, a job that is all about changing things: updating a table layout in a database, changing an IP address in the ETL, adding users to the OLAP tool – pretty standard GitHub/SourceForge chores and the like. So when I was given a chance to review the new Impackt book, Practical Change Management for IT Projects, I dove in, little knowing how mistaken I was and how happy this misunderstanding was about to become.

Reading the book was like seeing the sea for the first time: wow! There is a whole field of corporate change management, with people planning and rolling out a change in detail!

I work with a large (+10.000 employees, US$1Billion/Year) brazillian federal government IT company and we do plan our rollouts (for new systems, new process, new softwares, corporate culture change and so on), but the book addresses it in a deeper level than we have ever done. The author writes with focus, with the tight and well constructed sentences only those who had done something a lot are able to use. You can see it is so and not a professional polished text because among the concise wording, here and there, you can spot some odd constructions, and sometimes the train of thought is strained a bit too long, even for the native English speaker.

Managing the Change without Chance

If Change Management, the discipline of planning and conducting some change in an organisation, were a shrink-wrapped product, this book would be its instruction manual. It neatly explains what change management is and how the change eventually go around happening (or not.) She explains what are and and then identifies the components of a change (the “Pillars of Change”), the participants, the components of a change program and finally she lays out a project pattern for making the change happen in an orderly fashion. So there is quite a detailed work break-down, with roles, activities, milestones, deliverables, documentation (with templates and credible examples), control meetings. The whole shebang.

Concurrently, and I believe this is what add most value to this book, while the author presents all the information and the method she walks the reader trough every piece of it by using a Case Study set at the beggining of the book. In it, Acme Corp is adopting a new buying system in replacement for an old one. This change must happen in every division of the company and, to makes things look worse, this very system holds a sizeable amount of responsability for the results of Acme. If something goes awry this fictional company profitability might be badly hurten.

The Only Constant is Change

Practical Change Management for IT Projects is worth every penny. If you might be affected by change anytime, buy and read it at once. It seems Change Management is not that widespread discipline as is Project Management so it might be possible your company has never heard about it in that formal way. I am no novice on corporate life and it strucks me with some shame I have never seem it around. I am at ease to confess my loss at it just because the last words in the book are saved for telling you (the reader) the importance of the awareness of Change Management, that this awareness is key to success and how to rise it. Hence, to share those ideas and the book are an important exercise alongside everything else.

The Hands Down

I must admit I became an Emily Carr’s fan. I enjoyed reading the book by its sheer style, the upbeat never-surrender-never-retreat attitude. There is some inspiring grandeur in how she poses the problem and the hardship everyone faces daily, and the feeling she imparts on the need for change just makes you feel good.

Well, now that I said how much the book is worth and much I enjoyed it, I can tell what I didn’t like.

The Caveats

To make it sure: the book is good, you won’t regret buying it. However…

She operates the change management on some level of optimism. Unfortunatelly, real companies seem to be much more difficult to deal than Acme. On ocasion she sets some ideal situation that is simply not every time attainable. Some sort of compromise usually kicks in everything we do but she does not acknowledge that much (she doesn’t deny it, thoug.) For instance, on location 2187 she states the extreme importance of having every event you invite user to to be well planed and features a bug-free version of the product involved in the change. Good luck getting it…

She avoids dealing with all the possible variations and cenarios, or even with a small set of possibilities, so everything seems to be under an “ideal world” lighting. Although the consideration on some variability would enrich the book, taking in consideration its lenght, the templates, walkthroughs, insights and tips, by not addressing this much of variability doesn’t hurt the final results and, after all, makes for a more readable and practical book.

Another thing I can spot as some hidden hindrance to the newly broken Change Manager is that she makes it seem so much easy and success prone. There is nothing wrong here, for with some training and a bit of practicing it will probably became easier to drive a change program. The risk is not being aware how easy it is not. She knows how to do and have come confidence on doing it and she stress constantly a Change Program takes a lot of effort to turn in a success, but she writes very well and easily gets the reader carried away (again, nothing wrong – passion is good. Just kiss with lights on, and with open eyes.)

Finally, I couldn’t find any reference to Scrum or some Agile method. The program has a very conservative look of a waterfall planing. Of course if it works out good, I can’t ask for anything else. But Scrum is such a powerfull way of managing project that Change Management, being all about commiting changes, should be connected to it in some way.

Conclusion

As I said, Practical Change Management for IT Projects is very good and in fact a must have: practical, usefull guide on how to make change happen and how to have some control on it. All in all, a good read in all the senses. Its only downsides are some optmism and a couple of beatifull scenarios. I also miss some relationship with Scrum or any Agile technique, but none of those aspects are really an issue.

There is some changing come my way and I am very happy I have mistakenly turned to this book for some dull code-versioning stintch. After all it was not anything I would imagine, but thanks to this misunderstanding now I can really help make change happening, something I didn’t even know about a couple of weeks ago.

Meet PUMA!

O legal do Software Livre é isso: quando você menos espera, seu colega de trabalho é um gênio e cria uma coisa nova, que você sempre precisou mas nunca soube!

https://github.com/dguiarj/puma/

O PUMA – Pentaho Unified Management Archiver – é um aplicativo simples e muito prático. Ele te permite se conectar a um BI Server e subir qualquer arquivo para dentro dele. Ele é totalmente baseado nas APIs da Pentaho e por isso é 100% compatível.

O projeto, como dizem, está em early alfa, mas já funciona – eu vi o David (o tal dguiarj) usando para subir KTRs no BI Server e babei. Se você quiser ajudar, vá ao GitHub e contate-o – ele com certeza precisa de toda ajuda que puder ter.

É isso! Roarh!! :-D Kkkkkk

Exportando Dados com BI Server

O Pentaho é uma plataforma de construção de soluções de BI. Ele atende muitas necessidades, cada qual de uma maneira. Para quem está acostumado com o MicroStrategy, por exemplo, pode ficar um pouco chocado – como, não é só fazer um relatório? Pois é, o Pentaho faz bem mais coisas que “relatórios” e hoje eu vou mostrar aqui um truque eu aprendi com o (blog do) Nicholas Goodman, neste post. O site do blog dele, aparentemente, sumiu e esse é um dos motivos que me levou a postar aqui a mesma coisa. Repare que esse mesmo post também existe no fórum da Pentaho, neste link, ainda que sem as imagens ou arquivos.

O Problema

… é simples: seu usuário precisa “extrair os dados” da sua base (um DW, possivelmente) para usá-los em alguma outra atividade. Bom, seu cliente deveria gastar mais tempo com você e desenharem juntos uma solução com o Pentaho. Mas já que ele prefere ter mesmo tudo nas próprias mãos, vamos dar a ele a solução Pentaho que faz exatamente isso: baixa um pacotão com os dados extraídos do(s) banco(s).

A Solução

… é simples, também: vamos criar uma XAction no BI Server que, ao ser executada, baixa um arquivo de dados formatos em CSV. O “projeto” da solução é o seguinte:

  1. Usando o Spoon construa uma transformação que recupera os dados desejados. Por isso eu escrevi fontes de dados, no plural: com o PDI você pode combinar quantas quiser e ainda montar alguma coisa em cima;
  2. Crie a área de depósito, ou landing zone, na qual vamos deixar o arquivo que o usuário vai recuperar.
  3. Vá até o BI Server e crie uma nova solução (pasta de nível zero);
  4. Coloque a transformação dentro desta pasta;
  5. Construa a XAction que executa a transformação e devolve o arquivo.

A Implementação

Vamos passo-a-passo, mas eu preciso partir de um mínimo. Eu vou assumir que você:

  • Já sabe usar o PDI (a.k.a. Kettle) para construir transformações;
  • Consegue configurar e usar um BI Server, incluindo adicionar drivers;
  • Sabe usar o Pentaho Design Studio para construir e implantar XActions.

Se você ainda não sabe alguma dessas coisas deixe um comentário que darei algumas dicas, ou me procure no Linkedin (Fábio de Salles).

Primeira Passo: Construindo a Consulta

Digamos que meu cliente, que é o Analista de Data Mining da Beltrano S/A (a empresa que usamos no livro) e quer uma listagem com todos os atributos dos pedidos, extraídos diretamente da base transacional (beltrano_oltp). Ele me deu o SQL, que é:

SELECT
pedidos.data_pedido,
pedidos.cliente_tipo,
pedidos.pagamento_tipo,
pedidos_detalhes.quantidade,
pedidos_detalhes.desconto,
pedidos_detalhes.total_item,
pedidos_detalhes.preco_unitario,
turmas.data_turma,
cursos.curso_nome,
cursos.duracao_total,
cursos.duracao_aula,
cursos.vagas,
cursos.preco_vaga,
pedidos.cliente_id,
pedidos.pedido_id
FROM
public.cursos,
public.pedidos,
public.turmas,
public.pedidos_detalhes
WHERE
pedidos.pedido_id = pedidos_detalhes.pedido_id AND
turmas.curso_id = cursos.curso_id AND
pedidos_detalhes.turma_id = turmas.turma_id;

De posse desse SQL eu crio uma transformação que executa-o e grava o resultado em um arquivo CSV, zipado para ocupar menos espaço e testo: (ops! minha base estava vazia quando eu fiz esse screenshot!)

Transformação pronta e funcionando!
Transformação pronta e funcionando!

Beleza, funcionou, etapa um pronta.

Segundo Passo: Preparando o BI Server

Em uma instalação padrão do BI Server (estou usando a 4.8), equipado com driver para meu banco (um Postgres), eu crio o diretório que vai receber o arquivo. Meu BI Server fica em /opt/pentaho/4.8/biserver-ce. Entro em tomcat, webapps e crio uma pasta chamada lz:

Pasta lz criada.
Pasta lz criada.

Agora eu subo o BI Server, faço login como joe e crio uma solução (=nome de pasta no nível zero):

Criada a solução na qual o cliente vai recuperar os dados.
Criada a solução na qual o cliente vai recuperar os dados.

Finalmente, eu volto à transformação e coloco como diretório do arquivo de saída a nova pasta lz, /opt/pentaho/4.8/biserver-ce/tomcat/webapps/lz:

Incluído diretório de saída da extração.
Incluído diretório de saída da extração.

Pronto, segunda etapa feita.

Terceira Etapa – XAction exporta_dados

Abra o Design Studio (estou usando o 4.0.0), aponte para o pentaho-solutions do BI Server 4.8 e crie uma nova XAction:

  1. Configure o PDS para apontar para ./biserver-ce/pentaho-solutions;
  2. Na pasta (solução) Exportacao de Dados crie uma nova XAction: clique com o botão da direita na pasta e selecione BI PlatformNew Action Sequence. Dê um nome (eu chamei de exporta_dados);
  3. Preencha a ficha de identificação com o que bem entender, apenas evite acentos e cedilhas;
  4. Mude para aba 2 (Define Process);
  5. Clique com o botão da direita sobre Inputs e selecione AddString;
    1. Nomeie a nova variável como redirect_uri;
    2. Ligue o check-box Has default value;
    3. Preencha o valor dela com o caminho do arquivo dentro da solução lz: /lz/dados.zip;
  6. Clique com o botão da direita sobre a área das Process Actions e selecione AddGet Data FromPentaho Data Integration;
    1. Clique sobre a nova Process Action e altere seu nome; eu mudei para Extrai para arquivo.
    2. Coloque o caminho da transformação em relação à solução (solution:/exporta_dados.ktr), no campo Transformation file;
    3. Ajuste apenas o Kettle logging level. Eu deixei em Minimal;
  7. Finalmente, adicione o comando que vai redirecionar o navegador para o arquivo que a transformação vai criar:
    1. Clique o sinal de + azul que existe na seção Process Outputs, e selecione a variável que criamos antes: redirect_uri;
    2. Clique sobre a variável, para selecioná-la, e clique no sinal de + azul, na folha de propriedades da variável de saída, e selecione response: redirect_uri;
    3. Dê um duplo-clique sobre redirect_uri e altere para redirect, apenas;
  8. Salve.
Adicionando saída que redireciona o navegador.
Adicionando saída que redireciona o navegador.

Para não ficar dúvidas:

Variável de saída redirect_uri.
Variável de saída redirect_uri.

E

Configuração da Action Sequence de transformação.
Configuração da Action Sequence de transformação.

Atualize o BI Server, para ele recarregar a XAction. Dê um duplo clique nela e veja a mágica acontecer: seu navegador vai dizer que tem um arquivo ZIP para baixar.

Dados, Trasnformação, Ação!
Dados, Trasnformação, Ação!

Voi là! Abra o arquivo e veja seu conteúdo: um CSV com os dados pedidos.

Conclusão

Por ser uma plataforma de BI e não uma ferramenta de visualização de dados OU de ETL OU de Data Mining OU … OU … etc., o Pentaho pode entregar muito mais que só relatórios. Certifique-se realizar uma entrevista detalhada e de explorar a necessidade e o uso que seu cliente vai dar ao projeto de BI, pois há muito mais ações entre o DW e os Dashboards que supõem nossos vãos relatórios.

Serpro Homologa Compra do Pentaho Enterprise Edition

O Serpro acaba de homologar a licitação de compra de licenças do Pentaho Enterprise Edition! Isso significa que falta “apenas” pagar! :-)

De acordo com o site ComprasNet, o Serpro homologou hoje, 28 de novembro de 2012, às 12:16, a aquisição de R$1.302.192,96 em licenças Pentaho Enterprise Edition e com isso está prestes a se tornar a primeira empresa do governo federal a investir na versão corporativa do Pentaho.

Para ver o resultado acesse o link acima e percorra esse caminho:

  • Na barra de menus clique em Acesso Livre.
  • Selecione Consultas …
  • …e depois Atas de Pregões/Anexos.
  • Entre 31282012 no campo Número Pregão.
  • Clique em Ok.

Vai aparecer uma tabela com uma linha, referente à licitação. Clique no número dela e você terá algumas outras opções, incluindo “Termo de Homologação.” Clique nele para ver os dados confirmando a homologação. Eu não entendo do processo de licitação, mas pelo que eu já participei como fornecedor, o próximo passo é assinar ou pagar – alguma coisa assim. De qualquer forma, está feito!

A versão EE da suite oferece não apenas suporte e manutenção, mas melhorias em muitos pontos importantes para o Serviço Federal de Processamento de Dados,como maior facilidade de admnistração e melhores interfaces de usuário – como o Analyser e o Interactive Reporting.


23/12/2012 Atualização: estou de férias, mas um amigo me disse que o contrato foi assinado. Logo, 2012 agora é o ano oficial da primeira licença Pentaho adquirida pelo Serpro, e de maneira geral pelo Governo Federal Brasileiro.

P.S.: Gustavo Ostermann comentou que é uma vergonha o Serpro contratar a licença do Pentaho. O assunto é extenso e pretendo elaborar uma resposta adequada em meu outro blog, Solução em Aberto. Avisarei aqui quando isso acontecer.