Ladyvaulk – O Feitiço de Dataváulquila

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


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


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

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

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

Enter Linstedtman!

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

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

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

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

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

Usar um Data Vault. :-)

The Curse

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

:-O

Conclusão

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

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

Eu tive que brincar com isso.

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

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

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

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

AI MEUS SAIS!
AI MEUS SAIS!

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

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

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


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

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

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

10/08/2016 Link para o post.

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

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

Data Lake

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

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

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


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


O Problema de um Data Lake

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

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

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

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

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

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

Posso ouvi-los cantando meu nome:

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

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

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

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

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

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


Já pensou que terror??

  • Manhê! Dá um Negresco?

  • Peraí, filhote…

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

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

:-D


Até parece Minecraft

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

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

Conclusão

Eis a conversa com meu amigo, regalem-se:

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

Vamos destacar, imprimir e pendurar na parede:


Sobre Data Lakes:

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

Vitor Rosan

Savan Extraordinaire


Falou pouco mas disse tudo! ;-)

Férias = Livros!

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

Análise Bayesiana

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

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

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

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

O Que É Análise Baeysiana?

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

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

Expressões Regulares

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

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

Building a Scalable DV

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

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

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

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

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

Mastering Docker

E finalmente o livro que me fez desistir do Vagrant:

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

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

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

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

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

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

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

Conclusão

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

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

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

E você, o que tem lido de bom?

Até a próxima! ;-)

 

Desculpe o Transtorno

… Estamos em obras para melhor servi-los.

Eu sempre quis dizer isso!! :-D

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

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

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

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

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

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

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

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

Vamos ver se eu consigo. Até lá…

Teste

:-)

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

Férias!

Ah, férias! Aquela época do ano em que, sem um chefe no seu cangote, você trabalha sem parar, até cair de sono na sua cama. É consertar isso, levar aquilo para lavar, cuidar das crianças, passear com o cachorro…

Enfim, o blog está dando um tempo enquanto eu desfruto desses momentos de inenarrável deleite doméstico. O próximo post será dia 3 de agosto, daqui a duas semanas.

Até lá, para você não achar que perdeu a viagem, fica a dica: todos os livros da Packt estão por US$10,00 hoje – e somente hoje. Eis algumas sugestões:

É perturbador ver tanta coisa, tão barato…

Até a próxima! ;-)

Promoção de Lançamento do Pentaho na Prática, Segunda Edição

Quase três anos atrás, em 2 de agosto de 2013, o livro Pentaho na Prática apareceu para venda na Amazon.com. Com isso ele ganhou algumas marcas, como ser o primeiro livro sobre Pentaho em Português, e o primeiro livro sobre Pentaho no Brasil.

Essa era minha única meta. Queria que minha esposa tivesse orgulho de mim, e poder apontar aos meus filhos um livro empoeirado na (magra) estante em casa e dizer: “papai escreveu aquele livro”. Tudo que viesse na esteira disso seria um bônus. Algo como nascer, quando estamos pelados, carecas e sem dentes – dali em diante tudo é lucro! :-D

Quando o livro foi tirado do ar por problemas, eu achei que seria o fim da minha carreira literária (ai, que drama! kkk), pois eu tinha cumprido a minha meta. (Se bem que eu preciso pegar o Kindle da minha esposa para mostrar meu livro a eles, mas enfim.)

Graças a meus leitores, e a todo mundo que perguntou pelo livro nestes últimos anos, eu acabei me aplicando na auto-editoração, e agora tenho cinco livros publicados! E o primeiro virou sexto: chegou a segunda edição do PnP.

Sempre que lanço um novo livro ele sai em meio a uma promoção, que eu anuncio primeiro aqui para os leitores do blog, e depois para as listas das quais faço parte.

Antes, porém, uma pausa para um aviso importantíssimo:


O Pentaho na Prática, segunda edição, cobre a versão 4.8 da Suite Pentaho, sem CTools.


Sem maiores delongas, com vocês…

O Pentaho na Prática, segunda edição, está oficialmente lançado!Hoje, 13 de julho de 2016, ele está com 75% de desconto: de R$80,00 por R$20,00. Além disso, meus outros livros também estão com descontos significativos:

  • Autopublicação na Prática: de R$14,99 por R$5,99;
  • Geek BI 2012, 2013 e 2015: de R$5,99 por R$1,99 cada.

Quer ir direto para a Amazon? Eis os links para a loja brasileira:

E aqui para a loja dos Estados Unidos:

Você pode conhecer um pouco mais sobre cada livro seguindo os links no topo da página do blog, nos respectivos nomes.

É um prazer servi-los. ;-)

Servidor Pentaho com Vagrant

Em um post anterior eu resenhei um livro da Packt que ensina como usar o Vagrant para criar ambientes de desenvolvimento. Lá eu comentei sobre como Vagrant é interessante, e até como eu tentei montar um servidor, mas não consegui. Ainda tenho muito que aprender sobre Puppet para fazer a coisa tão bem, mas vou dividir com vocês o que eu fiz. Na pior das hipóteses é um ambiente Pentaho pronto, e pode quebrar um bom galho.


Antes de mais nada eu preciso deixar claro que vou falar sobre o Pentaho por mera conveniência. Dá para aplicar tudo que eu vou falar aqui em qualquer plataforma, com quaisquer softwares de BI. Pentaho é do balacobado, mas cada um é livre para montar seu projeto como achar melhor. Eu gosto de software livre, lembram-se? Isso significa liberdade para usar o software que quiser. ;-)


O primeiro post caiu direto no assunto, e ficou meio “seco”. Por isso vou começar revisando a idéia toda com mais cuidado. Depois eu vou mostrar como fazer e, na conclusão, detono tudo. (Tee-he)

Processos & Ambientes

Desde sempre, e não apenas hoje em dia, qualquer projeto de BI sempre possuiu duas etapas: colher dados e usar dados.

A parte de colher os dados equivale à montagem de um DW, um Armazém de Dados. Já a parte de usar os dados corresponde a um projeto de Data Mining ou a um projeto que expõe os dados aos usuários por meio de ferramentas de análises.

Quando o projeto é pequeno podemos desenvolver na produção e simplesmente lidar com as consequências dessa bagunça, mas quando os projetos são maiores que um certo porte, esse “simplesmente” não se aplica mais. Precisamos de pelo menos dois ambientes: um de desenvolvimento e um de produção.

O problema é que manter dois ambientes separados acaba por originar discrepâncias entre eles, e aos poucos começam a ficar diferentes um do outro. Depois de um tempo as diferenças são tamanhas, e tão irreconciliáveis, que cada nova versão levada para produção gasta um tempo só ajustando o código para as diferenças.

E é neste ponto que a idéia de infraestrutura como código pode nos ajudar: ao invés de mantermos dois ambientes com configurações manuais, descrevemos cada ambiente com um código-fonte, tal qual um software. Desta forma mantemos um controle muito maior sobre cada configuração e, melhor ainda, podemos comparar ambas e evitar as discrepâncias que acabam por atolar o projeto a cada nova versão.

Softwares como Puppet e Chef cuidam para que as definições desse “código” sejam aplicadas e respeitadas. Sempre que um servidor sofre alguma mudança que o desvia de sua configuração “correta”, esses programas, chamados genericamente de provisionadores, forçam a configuração de volta, apagando as coisas erradas e restaurando as configurações definidas pelo projeto.

O Vagrant é um passo na direção de infraestrutura como código: ao invés de construirmos um servidor, simplesmente definimos um servidor virtual. Associado a provisionadores, conseguimos um projeto cuja configuração é uniforme de ponta-a-ponta. Mais: podemos trabalhar em projetos distintos, tendo um ambiente de desenvolvimento finamente ajustado para cada projeto, se um interferir com outro.

Se durante o desenvolvimento descobrimos que precisamos alterar alguma configuração, essa alteração entra no código que descreve o servidor, ao invés de ficar perdida em um manual qualquer. Por meio de um versionador, como Git, esse código de infra-estrutura entra no projeto e é distribuído para todos os envolvidos. Mais ainda, sendo versionado e propagado para a produção! É um mundo perfeito – ou não? ;-)

Vagrant BA Server

Agora eu vou mostrar para vocês a sequência de ações que eu tomei até construir um Pentaho BA Server apto a atender um projeto simples. Não é o resultado final perfeito, que eu gostaria de obter, pois ele não envolve nenhum provisionador – ainda estou batendo cabeça com isso, e não queria demorar para levar isso a vocês. Esse campo ainda está muito cru, e quanto antes essas idéias começarem a se espalhar por aí, melhor.

O processo é relativamente simples:

  1. Instalar o VirtualBox;
  2. Instalar o Vagrant;
  3. Criar um ambiente Vagrant;
  4. Adequar os parâmetros desse ambiente para o BA Server;
  5. Instalar o Pentaho BA Server.

Eu fiz tudo isso em Ubuntu 16.04-64bits, um Linux, mas deve ser possível repetir esses passos com Windows e Mac, já que eles são suportados.

Todas essas ações são tediosamente sem graça em Ubuntu:

  1. Abri um terminal e comandei sudo apt-get update, para atualizar os repositórios de pacotes;
  2. Instalei o VirtualBox comandando sudo apt-get install virtualbox;
  3. Instalei o Vagrant: sudo apt-get install vagrant;

    O site do Vagrant adverte as versões de repositório normlamente estão bem defasadas em relação ao projeto, e que não raro podem acabar apresentando problemas. Por isso, recomendam eles, baixe o instalador do site (aqui) ou compile o projeto do zero.


  4. Criei um ambiente Vagrant:
    1. Em outro terminal criei um diretório para o novo servidor: mkdir AmbienteVagrant;
    2. Entre neste diretório com cd AmbienteVagrant e criei o arquivo inicial: vagrant init precise32 http://files.vagrantup.com/precise32.box;
  5. Configurei esse ambiente para ter 1.5 GB e expor a porta 8080:
    1. No diretório AmbienteVagrant surgiu o arquivo Vagrantfile, que eu abri com o editor de textos;
    2. Entre as linhas que definem a configuração, Vagrant.configure(2) do e end, inseri esses dois trechos: config.vm.provider "virtualbox" do |vb|
      vb.memory = "1536"
      end
      e
      config.vm.network "forwarded_port", guest: 8080, host: 8080

    Isso vai mudar a memória da máquina virtual para 1.5GB ( = 1024 MB * 1.5), suficiente para um BA Server 5.x, e vai fazer um forward da porta 8080 da máquina virtual para a máquina real.

  6. Ainda dentro daquele diretório, subi o servidor Vagrant com o comando vagrant up. Na primeira execução ele baixou um disco virtual configurado com Ubuntu Precise Pangolin (12.04 LTS) para 32 bits, e só então subiu o servidor.

Voi-là! Agora temos uma máquina virtual pronta para ser configurada com o BA Server. O que precisamos fazer é bem simples: adicionar Java 1.7, baixar e descompactar o BA Server 5.4 e configurar o servidor para subi-lo automaticamente. Vamos nessa:

  1. Acessamos o servidor Vagrant rodando com o comando vagrant ssh. Um terminal se abre diretamente no servidor virtual;
  2. Vamos instalar o Java Oracle: é só adicionar o repositório e rodar um apt-get:
    1. Dentro do servidor Vagrant comandamos sudo apt-get update para atualizar a lista de pacotes disponíveis;
    2. Para adicionarmos a chave do repositório Java WebUpd8 precisamos de alguns pacotes. Instale-os com este comando:sudo apt-get install python-software-properties;
    3. Depois disso estamos preparados para adicionar a chave do PPA:sudo add-apt-repository ppa:webupd8team/java. Apenas bata enter para concluir;
    4. Atualize os repositórios novamente, com outro sudo apt-get update;
    5. Finalmente, comande a instalação do Java 7:sudo apt-get install oracle-java7-installer;

      A instalação do Java por meio de repositório no Ubuntu é um truque: a licença da Oracle não permite empacotá-lo no repositório, então o que realmente baixamos é um programa de instalação que coleta, por meio de um prompt, uma anuência com os termos legais da Oracle, para então baixar os arquivos do Java e configurá-lo. Por isso a série de pontinhos, indicando o download – uma coisa que não acontece com o apt-get ordinário.


  3. Ao final teste o java: comande java -version e veja se volta uma mensagem informando a versão;
  4. Vamos precisar de outro programa: unzip. Comande sudo apt-get install unzip para instalá-lo;
  5. Instale o BA Server:
    1. Ainda no SSH do Vagrant, entre sudo mkdir /opt/pentaho para criar o diretório no qual vamos deixar o servidor;
    2. Para facilitar nossa vida, mude esse diretório para “casa da mãe joana”, comandando sudo chmod 777 /opt/pentaho. Isso vai dar permissão de escrita geral no diretório pentaho;
    3. Mude para ele, cd /opt/pentaho, e baixe o Pentaho BA Server 5.4 a partir do SourceForge:wget http://bit.ly/29gb4ak --output-document=biserver-ce-5.4.0.1-130.zip
    4. Depois que ele terminar de baixar, descompacte-o: comande unzip biserver-ce-5.4.0.1-130.zip;
    5. Terminou de descompactar? O zip não é mais necessário, e você pode removê-lo com rm biserver-ce-5.4.0.1-130.zip. Não precisa, já que isso não vai forçar o tamanho do disco virtual para baixo automaticamente.

Ufa! Quase lá! Primeiro deixe o BA Server pronto para atuação automática:

cd biserver-ce
./start-pentaho.sh

Responda com enter à mensagem e aguarde alguns minutos. Daí teste abrindo seu navegador web e apontando para http://localhost:8080. Se tudo deu certo você verá a tela de login do servidor. Não se esqueça de baixar o servidor antes de prosseguir, com um ./stop-pentaho.sh dentro da caixa Vagrant.


É importante você rodar o BA Server ao menos uma vez manualmente, e assim se livrar do prompt de execução inicial. Caso contrário o servidor pode não subir na inicialização automática.


E o que falta? Bom, queremos que o servidor Vagrant fique pronto com um único comando – vagrant up – sem precisar de mais nada. Então é necessário configurar o servidor para subir e baixar sozinho, na inicialização da máquina.

Configurando o BA Server para Início Automático

O procedimento descrito aqui foi retirado do capítulo 3 do livro Pentaho na Prática. Você pode baixá-lo [deste link][pnpcap3_bitly], e ter um gosto do livro.

  1. Primeiro, garanta que o servidor Vagrant esteja no ar emitindo o comando vagrant up dentro do diretório em que criamos o arquivo de configuração Vagrant (/home/USUÁRIO/AmbienteVagrant);
  2. Faça login no servidor Vagrant com vagranta ssh;
  3. Assuma credenciais de root na caixa Vagrant: sudo su;
  4. Mude para o diretório de scripts de serviço: cd /etc/init.d;
  5. Abra um editor para um arquivo novo, neste mesmo diretório, chamado biserver-ce: nano biserver-ce (pode usar o vim, se quiser;)
  6. Agora precisamos do script de inicialização de servidor, para Linux. Abra este link em uma outra aba do seu navegador e procure o item “Script de Inicialização do BI Server para Linux”. Baixe este script, abra-o e copie tudo para dentro do arquivo do item anterior. Salve, pressionando CTRL+O e batendo enter, e depois saia do editor, pressionando CTRL+X;
  7. Por fim ative a execução automática: ainda no terminal Vagrant, como sudo, comande: (atenção! são dois blocos diferentes!)
ln -s /etc/init.d/biserver-ce /etc/rc2.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc3.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc4.d/S99BAServer
ln -s /etc/init.d/biserver-ce /etc/rc5.d/S99BAServer
 
ln -s /etc/init.d/biserver-ce /etc/rc0.d/K19BAServer
ln -s /etc/init.d/biserver-ce /etc/rc1.d/K19BAServer
ln -s /etc/init.d/biserver-ce /etc/rc6.d/K19BAServer

É isso. Saia de tudo, pare o servidor Vagrant com vagrant halt e depois reinicie-o com vagrant up. Assim que o prompt voltar, abra um navegador web e aponte para http://localhost:8080/pentaho.


O comando vagrant up pode terminar antes de o servidor Pentaho estar no ar. Dê alguns minutos para tudo acabar de acontecer antes de tentar acessar o BA Server com o navegador web.


Conclusão

Acabei de reler tudo, para fazer a conclusão, e acho que devo um pedido de desculpas: parecia mais fácil na minha cabeça… Se você tiver algum problema, ou dúvida, deixe aqui um comentário, que eu te ajudarei.

Vamos lá, para a conclusão.

Virtualização é uma idéia muito legal. Virtualizar máquinas permite desde jogar antigos arcades a testar sistemas operacionais sem precisar arriscar ferrar a nossa máquina e nossos dados.

No mundo dos desenvolvedores, as coisas ficam cada vez mais complicadas. Uma das complicações mais perniciosas é o duo ambiente de desenvolvimento/produção: a tendência humana em mexer agora e documentar depois acaba bagunçando a situação a tal ponto que cada novo deploy, isto é, a cada entrega de uma nova versão no ambiente de produção, exige muito trabalho para compensar as diferenças entre os ambientes.

Para resolver esse problema surgiram tecnologias englobadas na disciplina DevOps, como os provisionadores, softwares que configuram, e forçam essa configuração em um ambiente, automaticamente. Dois membros desta classe são o Puppet e o Chef, que permitem definir uma infraestrutura como se fosse código, tornando possível até mesmo uma coisa estranha: versionar uma infraestrutura, isto é, guardar todas as configurações que ela já teve ao longo do projeto.

Alguém teve a (óbvia e genial) idéia de combinar essas duas coisas e conseguir uma terceira ainda mais bacana: ambientes de desenvolvimento isolados!

O software Vagrant, sobre o qual a Ed. Packt oferece um livro muito bom, faz exatamente isso: permite a criação de ambientes estanques, configurados ao gosto do projeto. Graças a ele, qualquer equipe pode ter um ambiente de desenvolvimento “limpo” (i.e. exclusivo por projeto), uniforme (igual para todo mundo) e estável (não muda sem querer ou por acidente.)

Em um post anterior eu resenhei o livro da Packt sobre o Vagrant, e hoje eu dei aqui o passo-a-passo para montar um servidor Vagrant para projetos que usem o Pentaho BA Server 5.4.

… ou quase: o ideal teria sido definir a configuração como um script Puppet ou Chef (scref?? kkk) e deixar o provisionador tomar conta. Mas eu ainda tenho muito a aprender e por isso resolvi mostrar o que eu já consegui fazer.

Burning Down the House

Eu seguia feliz da vida estudando o Vagrant, quando, de repente! (kkk), fiz o curso da 4Linux sobre DevOps! Foi quando eu fui obrigado a aprender sobre o [Docker][docker_bitly], algo do que eu vinha escapando deliberadamente (infra não é minha praia.) O Docker leva adiante a idéia de isolamento proposta pela virtualização, mas a um custo de infra menor: enquanto que a virtualização quebra uma máquina real em várias virtuais, o Docker monta várias máquinas “virtuais” compartilhando a mesma infra. Isso tem uma grande vantagens logo de saída: por não virtualizar tudo, mas apenas a parte que interessa, ele é muito mais leve e por isso usa melhor os recursos da máquina. De cara a performance de um container Docker é melhor que a de uma máquina virtual.

Há muita coisa ainda para se evoluir e resolver na tecnologia de containers mas, como colocou o The Register, se virtualização é uma tecnologia importante e valiosa em certos cenários, em outros ela é pesada e ineficiente, e coisas como containers são o futuro.

Uma destas coisas, na minha opinião, é justamente a gestão de ambientes, e não apenas de desenvolvimento! Como um container tem performance nativa, podemos montar servidores reais usando Docker e ainda atingir o grau de isolamento e controle proposto pelo Vagrant. No fundo, é a mesma coisa, mas executada de uma forma diferente.

Por isso eu disse, no começo, que “vou mostrar como fazer e, na conclusão, detono tudo. (Tee-he)”: não sei se vou continuar investindo no Vagrant. Ao menos por um tempo, eu definitivamente vou cair de cabeça no mundo do Docker! Eu até comprei um livro da Packt sobre isso, o Learning Docker. Assim que eu acabar de lê-lo vou fazer sua resenha aqui e depois montar o mesmo ambiente de hoje usando Docker.

Docker

Docker

Docker Docker Docker Docker Docker Docker Docker Docker

Já reparou como é viciante falar Docker? Docker Docker Docker Docker

Até a próxima! ;-)

Migrando o Pentaho BA Server +5.x

Até a versão 4.x o Pentaho BI Server usava um repositório que misturava sistema de arquivos com bancos de dados, e era muito prático de mexer. Só tinha um problema: era tosco pra dedéu. A Pentaho aproveitou a reforma geral que deu à luz o BA Server 5.0 e adotou um repositório “profissa”. A partir da versão 5.0 o servidor passou a usar o JackRabbit como repositório oficial.

Eis a definição do projeto pela Apache Foundation, que cuida desse projeto:


O repositório de conteúdo Apache Jackrabbit é uma implementação 100% aderente à API de Repositórios de Conteúdo para Tecnologia Java (JCR especificada nas JSR 170 e JSR 283.)


Logo a seguir dizem que um repositório de conteúdo é “um provedor de armazenamento hierárquivo de conteúdo com suporte para conteúdo estruturado e não-estruturado, busca por texto, versionamento, transações, observação e mais”. Interessante! Será que o repositório do BA Server suporta versionamento? O que é observação? Perguntas para outro post!

Para os usuários do BA Server esse novo formato se traduz em segurança aumentada, mais integração com a plataforma e seus serviços, maior flexibilidade e melhor performance em geral. Uma das mudanças trazidas por esta nova tecnologia é o processo de migração de soluções (do conteúdo gerado no servidor) entre duas versões do BA Server. Antes era só copiar as pastas particulares do diretório ./pentaho-solutions de uma instalação para outra, atualizar o servidor do destino e estava feito.

Ou quase. Na verdade, havia um trabalho meio chato nesse caminho, já que você tinha que levar também as permissões por pasta e objetos e cuidar de alguns outros detalhes. No final das contas, só quem tinha a versão Enterprise (paga) é que tinha um processo de migração mais facilitado.

A adoção do Jackrabbit tornou esse processo de migração mais profissional também para a comunidade. E isso tudo eu escrevi só para dizer que neste post eu vou dividir com vocês o que eu aprendi quando precisei migrar um servidor da série 5.x.


AVISO IMPORTANTE!!!

Mesmo que tenha resolvido meu caso, esse procedimento é experimental!! Estou compartilhando aqui o pouco que eu aprendi para resolver a minha necessidade. Se você decidir aplicá-lo a seu ambiente, o fará por sua conta e risco. Eu não posso ser responsabilizado por nenhuma de suas ações!


Isto posto, terei prazer em ajudar se você tiver algum problema ou dúvida – basta postar um comentário. ;-)

Preparando o Cenário

Para que você aprenda o processo, sem ser atrapalhado por um monte de pequenos detalhes que podem aparecer no caminho, eu sugiro que monte um ambiente simples, no qual você possa testar o processo e praticá-lo à vontade, até aprendê-lo e só então aplicá-lo ao seu ambiente.

Para montar esse ambiente eu sugiro o BA Server 5.4, mas em princípio esse processo deve ser compatível com qualquer versão das séries 5.x e 6.x – mais uma vantagem da adoção de um padrão. Apenas esteja atento para o fato de que o programa que faz a exportação/importação pode ser diferente (pouco ou muito) de uma versão para outra, como, por exemplo, ter um switch a mais ou a menos.

Nosso ambiente terá dois BA Servers, um de origem e outro de destino. Para conseguir isso apenas descompacte o ZIP do BA Server 5.4 para pastas ora com um nome, ora com outro. Neste exemplo o diretório do BA Server de origem chama-se ./biserver-ce e o de destino, ./biserver-ce_DESTINO

Diretório /opt/pentaho/5.4 com dois BA Servers.
Diretório /opt/pentaho/5.4 com dois BA Servers.

Não é possível rodar dois BA Servers simultaneamente sem alterar diversas configurações em pelo menos um deles. Por isso, para manter tudo o mais simples possível e focar só no processo de migração, não vamos rodar os dois ao mesmo tempo, mas apenas um de cada vez: rodamos o de origem, exportamos o repositório, paramos esse servidor, subimos o de destino e importamos o pacote extraído do outro.

Vamos lá!

Exportando o Repositório

Depois de expandir o ZIP do BA Server, suba-o: abra um terminal, mude de diretório e comande ./start-pentaho.sh.


Se você não tem idéia de como fazer isso, bolas, porque está se metendo a migrar a coisa? :-) Mas se você é como eu, que não desiste só porque não está entendendo nada, e quiser experimentar mesmo assim, baixe o capítulo de degustação do meu livro Pentaho na Prática.


Com ele no ar, acesse-o (URL http://localhost:8080/pentaho) com usuário admin e senha password e mude alguma coisa. Apague um arquivo, remova um diretório, criei e salve alguma análise com o jPivot etc. Se você não modificar nada, não vai notar o resultado do processo.

Eu removi todos os usuários, menos o admin, e criei alguns novos. Montei uma visão OLAP com jPivot e salvei em admin. Daí criei uma pasta pública chamada Rodas de Aço e movi para lá todo conteúdo das subpastas do Steel Wheels, apagando esta. No final ficou assim:

Origem: note as pastas de usuários e pública.
Origem: note as pastas de usuários e pública.

Pronto para exportar!

  • O servidor deve estar no ar;
  • Abra um terminal e mude o diretório para dentro do ./biserver-ce de origem;
  • Comande:
./import-export.sh --export --url=http://localhost:8080/pentaho
--username=admin --password=password --file-path=/tmp/Repositorio_54_Origem.zip
--charset=UTF-8 --path=/ --withManifest=true --logfile=/tmp/logfile_export.log

Se tudo der certo a saída no terminal vai ser mais ou menos esta:

fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce_ORIGEM$ ./import-export.sh --export --url=http://localhost:8080/pentaho --username=admin --password=password --file-path=/tmp/Repositorio_54_Origem.zip --charset=UTF-8 --path=/ --withManifest=true --logfile=/tmp/logfile_export.log
WARNING: Using java from path
DEBUG: _PENTAHO_JAVA_HOME=
DEBUG: _PENTAHO_JAVA=java
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document root element "configuration", must match DOCTYPE root "null".
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document is invalid: no grammar found.
log4j:WARN The <configuration> element has been deprecated.
log4j:WARN Use the <log4j:configuration> element instead.
Export Completed
Response Status: 200
Export written to: /tmp/Repositorio_54_Origem.zip
fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce_ORIGEM$

E você terá um zip, na pasta /tmp, contendo o repositório de arquivos do servidor:

Conteúdo do arquivo de backup do repositório.
Conteúdo do arquivo de backup do repositório.

Note que interessante: ainda existem diretórios ocultos, como o famoso /bi-developers, uma coleção de exemplos de uso do BI Server.

E uma “pegadinha”: parece que nenhum dos diretórios de usuários, que estavam vazios, foram exportados. Isso não é verdade, pois eles aparecem se listarmos o conteúdo do arquivo em um terminal (ou talvez com algum outro programa que não o File Roller):

fabio@pentaho:/tmp$ unzip -l Repositorio_54_Origem.zip 
Archive:  Repositorio_54_Origem.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2016-06-29 13:02   home/
        0  2016-06-29 13:02   home/Everton/
        0  2016-06-29 13:02   home/Fabio/
        0  2016-06-29 13:02   home/Joe/
        0  2016-06-29 13:02   home/admin/
     7052  2016-06-29 13:02   home/admin/Analise+jPivot.xjpivot
      186  2016-06-29 13:02   home/admin/Analise+jPivot.xjpivot.locale
       62  2016-06-29 13:02   home/index_pt_BR.locale
        0  2016-06-29 13:02   public/
        0  2016-06-29 13:02   public/bi-developers/
(...)
       84  2016-06-29 13:02   public/index.locale
       64  2016-06-29 13:02   public/index_pt_BR.locale
   961634  2016-06-29 13:02   exportManifest.xml
---------                     -------
 10708536                     2014 files
fabio@pentaho:/tmp$

O comando de exportação para Windows tem apenas as diferenças do sistema operaciona: muda de .sh para .bat e tudo que é / vira c:\ :

import-export.bat --export --url=http://localhost:8080/pentaho
--username=admin --password=password
--file-path=%USERPROFILE%\AppData\Local\Temp\Repositorio_54_Origem.zip
--charset=UTF-8 --path=/ --withManifest=true
--logfile=%USERPROFILE%\AppData\Local\Temp\logfile_export.log

Ao contrário do Linux, que por padrão tem um diretório /tmp universal, no Windows cada usuário tem seu próprio diretório temp. Ele pode ser referenciado pela variável %USERPROFILE%\AppData\Local\Temp, que usamos acima.


Importando o Repositório

Baixe o servidor de origem e suba o de destino. Pronto?

  • O servidor de destino deve estar no ar;
  • Abra um terminal e mude o diretório para dentro do ./biserver-ce de destino;
  • Comande:
./import-export.sh --import --url=http://localhost:8080/pentaho --username=admin
--password=password --charset=UTF-8 --path=/ --file-path=/tmp/Repositorio_54_Origem.zip
--logfile=/tmp/logfile_import.log --permission=true --overwrite=true --retainOwnership=true

Ele vai passar um tempo “pensando” e depois começar a cuspir a saída do processamento:

fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce_DESTINO$ ./import-export.sh --import --url=http://localhost:8080/pentaho --username=admin --password=password --charset=UTF-8 --path=/ --file-path=/tmp/Repositorio_54_Origem.zip --logfile=/tmp/logfile_import.log --permission=true --overwrite=true --retainOwnership=true
WARNING: Using java from path
DEBUG: _PENTAHO_JAVA_HOME=
DEBUG: _PENTAHO_JAVA=java
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document root element "configuration", must match DOCTYPE root "null".
log4j:WARN Continuable parsing error 3 and column 57
log4j:WARN Document is invalid: no grammar found.
log4j:WARN The <configuration> element has been deprecated.
log4j:WARN Use the <log4j:configuration> element instead.
done response = <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Repository Import Log</title>
<style type="text/css">
<!--
body, table {font-family: arial,sans-serif; font-size: x-small;}
th {background: #336699; color: #FFFFFF; text-align: left;}
-->
</style>
</head>
<body bgcolor="#FFFFFF" topmargin="6" leftmargin="6" style="font-family: arial,sans-serif; font-size: x-small">
<hr size="1" noshade>
Log session start time Wed Jun 29 15:00:44 BRT 2016<br>
<br>
<table cellspacing="0" cellpadding="4" border="1" bordercolor="#224466" width="100%">
<tr style="background: #336699; color: #FFFFFF; text-align: left">
<th>Time</th>
<th>Import File</th>
<th>Level</th>
<th>File:Line</th>
<th>Message</th>
</tr>
(...)

Isso vai continuar por mais um monte de linhas, varrendo o arquivo inteiro até o final. As mensagens no final devem ser assim:

(...)
<tr>
<td>06/29/2016 15:01:36</td>
<td title="importFile">/public/Public</td>
<td title="Level">INFO</td>
<td>Log4JRepositoryImportLogger.java:53</td>
<td title="Message">Start File Import</td>
</tr>
 
<tr>
<td>06/29/2016 15:01:36</td>
<td title="importFile">/public/Public</td>
<td title="Level"><font color="#993300"><strong>WARN</strong></font></td>
<td>Log4JRepositoryImportLogger.java:181</td>
<td title="Message">Public</td>
</tr>
 
<tr>
<td>06/29/2016 15:01:36</td>
<td title="importFile">/</td>
<td title="Level">INFO</td>
<td>Log4JRepositoryImportLogger.java:47</td>
<td title="Message">End Import Job</td>
</tr>
</table>
<br>
</body></html>

Na minha contagem, o processo soltou exatas 63636 linhas, incluindo o cabeçalho com mensagens sobre o Java no início – e era um repositório mínimo. :-O

Vamos verificar o resultado? Eis o estado do repositório do servidor de destino antes da importação do backup:

Servidor de destino antes da restauração.
Servidor de destino antes da restauração.

Após fazer a importação usando o import-export.sh temos:

Servidor de destino após a restauração.
Servidor de destino após a restauração.

Observe que não aparece nenhuma das pastas de usuário do servidor de origem, que nós sabemos que existiam no arquivo ZIP, e continuam existindo as pastas que já existiam no destino, ou seja, não foram apagadas.


Volto a frisar: teste o processo algumas vezes para evitar surpresas. Neste exemplo migramos pastas vazias, mas de usuários que não existiam no destino. E se elas não estivessem vazias na origem? Eu fiz o teste: arquivos de diretórios de usuários que não existem no destino, não são importados. Isso é muito importante: arquivos que vêm de diretórios de usuários, na origem, que não existem no destino, são perdidos!! Para funcionar, o usuário precisa existir no destino!


Como Funciona?

É bem simples, na verdade: a Pentaho construiu um programa, import-export.sh (Linux e MacOS) ou import-export.bat (Windows), que chama um “processo” (classe? método?) diretamente no código do servidor. Eis o conteúdo da versão Linux/MacOS (observe a última linha do bloco a seguir:)

#!/bin/sh
DIR_REL=`dirname $0`
cd $DIR_REL
DIR=`pwd`
#cd -
 
. "$DIR/set-pentaho-env.sh"
setPentahoEnv
 
# uses Java 6 classpath wildcards
# quotes required around classpath to prevent shell expansion
"$_PENTAHO_JAVA" -Xmx2048m -XX:MaxPermSize=256m -classpath "$DIR/tomcat/webapps/pentaho/WEB-INF/lib/*" org.pentaho.platform.plugin.services.importexport.CommandLineProcessor ${1+"$@"}

Esse programa possui várias opções e parâmetros. Para ver a lista completa de opções, basta rodar o comando sem nenhum switch:

fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce$ ./import-export.sh
 
(... mensagens de erro por falta de parâmetros ...)
 
usage: importexport
Unified repository command line import/export tool
 -a,--url <arg>                      url of repository (e.g.
                                     http://localhost:8080/pentaho)
 -a_ds,--analysis-datasource <arg>   Analysis datasource description
 -a_xmla,--xmla-enabled <arg>        Analysis XMLA enabled flag
 -c,--charset <arg>                  charset to use for the repository
                                     (characters from external systems
                                     converted to this charset)
 -cat,--catalog <arg>                catalog description
 -ds,--datasource-type <arg>         datasource type
 -e,--export                         export
 -f,--path <arg>                     repository path to which to add
                                     imported files, or to export from
                                     (e.g. /public)
 -fp,--file-path <arg>               Path to directory of files for
                                     import, or path to .zip file for
                                     export
 -h,--help                           print this message
 -i,--import                         import
 -l,--logfile <arg>                  full path and filename of logfile
                                     messages
 -m,--permission <arg>               apply ACL manifest permissions to
                                     files and folders  (import only)
 -m_id,--metadata-domain-id <arg>    Metadata domain ID
 -o,--overwrite <arg>                overwrite files (import only)
 -p,--password <arg>                 repository password
 -params,--params <arg>              parameters to pass to REST service
                                     call
 -r,--retainOwnership <arg>          Retain ownership information  (import
                                     only)
 -res,--resource-type <arg>          Import/Export resource type
 -rest,--rest                        Use the REST (Default) version (not
                                     local to BI Server)
 -u,--username <arg>                 repository username
 -v,--service <arg>                  this is the REST service call e.g.
                                     acl, children, properties
 -w,--withManifest <arg>             Export Manifest ACL file included
                                     (export only)
Common options for import & export using REST ServicesExample arguments
for import:
--import --url=http://localhost:8080/pentaho --username=admin
--password=password --charset=UTF-8 --path=/public
--file-path=c:/temp/steel-wheels
--logfile=c:/temp/logfile.log
--permission=true
" + "--overwrite=true
--retainOwnership=true
Example arguments for export:
--export --url=http://localhost:8080/pentaho --username=admin
--password=password
--file-path=c:/temp/export.zip --charset=UTF-8 --path=/public
--withManifest=true--logfile=c:/temp/logfile.log
Example arguments for running REST services:
--rest --url=http://localhost:8080/pentaho --username=admin
--password=password
-path=/public/pentaho-solutions/steel-wheels/reports
--logfile=c:/temp/logfile.log --service=acl
 
(... Erros por falta de parâmetro ...)
 
fabio@pentaho:~/opt/Pentaho/5.4/biserver-ce$

Então, por exemplo, para exportar apenas o diretório do usuário Joe, usando para isso o usuário admin, que possui todas as permissões de acesso, o comando fica:

./import-export.sh --export --url=http://localhost:8080/pentaho
--username=admin --password=password --file-path=/tmp/PastaDoJoe.zip
--charset=UTF-8 --path=/home/Joe --withManifest=true --logfile=/tmp/logfile_export.log

Note que não exportamos simplesmente “Joe”, mas sim “/home/Joe”. Isso porque a pasta do Joe existe dentro de uma outra subpasta, como você pode observar ao notar o atributo Source nesta figura:

Pasta do Joe no diretório /home.
Pasta do Joe no diretório /home.

E é por isso que usamos --path=/ para exportar/importar o repositório inteiro: / é a raiz de tudo.

O processo de importação segue as mesmas regras, só que no sentido inverso: levando o conteúdo exportado para dentro de um repositório.

Não deixe de consultar o Pentaho Infocenter (ou Pentaho Help) para aprender mais sobre isso:

Curiosamente, a página do BA Server 6 fala que o procedimento exporta tudo, incluindo usuários e permissões, mas não consegui encontrar essa informação no arquivo ZIP. O exportManifest.xml, que registra a lista de pastas e arquivos, e seus respectivos donos e permissões, não mostra nada. E só para tirar a cisma, tentei importar no 6 o repositório do 5, mas o seis não registrou nenhum dos usuários que eu criei no cinco. Pode ser que essas páginas estejam se referindo a alguma ferramenta que vai junto da versão Enterprise (paga), indisponível na Community.

Conclusão

Vimos como usar o programa import-export.sh/bat para exportar o repositório de arquivos de um servidor Pentaho e importar em outro. Depois da substituição do mecanismo de repositório que existia até a versão 4.8, esse método é a única forma de fazer a migração entre dois servidores – uma tarefa necessária quando se instala uma nova versão do Pentaho BA Server e queremos levar tudo que nossos usuários já fizeram.

Mostrei um exercício simples, “migrando” o repositório entre duas instâncias da versão 5.4, para que você possa estudar o processo livre de problemas paralelos. Você pode usar o que aprendeu para experimentar uma migração real, levando os arquivos de uma versão 5.x para a 6.x, por exemplo.

Além disso, ainda é preciso levar os usuários e seus papéis, e todas as conexões de dados, metamodelos e esquemas OLAP. Mesmo assim a nova tecnologia Jackrabbit é mais prática (em especial para a versão CE) que o antigo formato, tosco pra dedéu, de filesystem + banco de dados.

Feliz migrações! ;-)

Lago ou Pântano?

Há duas regras que eu procuro respeitar nos meus posts: não publico nada que eu mesmo não gostaria de ler e nunca repito algo que já foi publicado por aí. Entretanto, em alguns casos o assunto que já foi publicado é tão relevante, e está tão bem escrito, que eu me sinto na obrigação de dividir meu achado, e este é o caso do post de hoje.

Eu havia planejado dois posts sobre o conceito de Data Lake, tal qual eu fiz com Data Discovery. Ao começar a pesquisa eu topei com um artigo do Gartner falando justamente sobre esse assunto: Gartner Says Beware of the Data Lake Fallacy. Eles colocaram o problema de uma forma tão simples, clara e lúcida que se meter a querer fazer algo melhor seria uma pretensão muito maior que o meu normal – e olhe que eu sou um cara pretensioso pra chuchu! Devo ser o cara mais pretensioso mundo, mas felizmente minha modéstia também é enorme, o que me salva.

:-DEntão, ao invés de refazer o trabalho eu vou apresentar o artigo do Gartner.

A Questão

Em 2010, James Dixon publicou um post num blog Pentaho apresentando a motivação e o conceito de um Data Lake:


Motivação

James Dixon conversou com várias empresas que usam Hadoop e descobriu que cerca de 80-90% deles usam dados estruturados ou semi-estruturados, mas não “desestruturados”, sendo que a fonte desses dados é quase sempre um só sistema transacional. Mesmo assim nem tudo é dado transacional, e apesar de várias perguntas sobre esses dados serem conhecidas, muitas mais – desconhecidas – podem vir a ser formuladas no futuro. Em geral existe mais que uma ou algumas comunidades de usuários interessados nestes dados, que são gerados ou processados em um passo muito superior ao que um SGBDR aguenta.

Definição

Se você pensar que um data mart como um armazém de água engarrafada, que foi limpa e empacotada para consumo, um Lago de Dados (aka Data Lake) é o corpo de água em um estado mais natural. O conteúdo dos sistemas de origem fluem para dentro do Data Lake, e vários usuários do lago podem vir examiná-lo, mergulhar nele ou levar amostras.


Francamente, para mim é o mesmo que dizer que você pode comprar farinha pronta no supermercado, mas ir até a fazenda comprar grãos direto do armazém. Enfim, adiante.

A partir daí o hype tomou conta do debate, e tudo passou pelo processo de “binguificação corporativa”, que é aquele mecanismo em que os chavões da hora vão parar em tudo que é reunião de estratégia, documento de intenções, briefings, pings para manter as coisas in the loop blá bláh blah yadda yadda yadda.

Resultado? Em 2016 não se acham Data Lakes “na natureza”, nos grandes espaços selvagens do mundo corporativo. Traduzindo: ninguém ainda veio a público dizer que implementou um e que resultados está tirando deles.


Mais ou menos a mesma coisa pela qual passou Mobile BI, Business Discoveryt/Data Discovery, e em boa parcela o mesmo pelo qual BigData ainda passa. Mas BigData é outro assunto, para outro dia, outro post.


Fiat Lux!

E aí vem o artigo do Gartner. Não quero repetir palavra por palavra, do contrário eu prestaria a vocês um serviço melhor só informando o link ao invés de escrever meu próprio post. Vou colocar as minhas críticas e depois o que o artigo do Gartner fala, e então bater os dois.

Seis por Cinco e Meio

Meu primeiro cisma com DL (Data Lake) é o fato de que ele não trazer algo de realmente novo: muitos outros projetos fazem cópias simples dos dados de um sistema para outro repositório. Na verdade, é a abordagem de praticamente todos que assumem um projeto de DW sem estudar o assunto antes. Como não sabem o que vão fazer, começam fazendo o óbvio: copiam tudo, e geram os produtos de dados a partir deste dump.

Vejam o que o Gartner coloca:


Nick Heudecker, research director at Gartner(…) “The idea is simple: instead of placing data in a purpose-built data store, you move it into a data lake in its original format. This eliminates the upfront costs of data ingestion, like transformation. Once data is placed into the lake, it’s available for analysis by everyone in the organization.”

However, while the marketing hype suggests audiences throughout an enterprise will leverage data lakes, this positioning assumes that all those audiences are highly skilled at data manipulation and analysis, as data lakes lack semantic consistency and governed metadata.


Em Português é mais ou menos isso:


Nick Heudecker, diretor de pesquisa no Gartner: “A idéia é simples: ao invés de colocar os dados em uma estrutura construída com especificamente para arquivar os dados, você move-os para dentro do Data Lake em seu formato original. Isso elimina os custos iniciais de ingestão e processamento dos dados de origem. Uma vez que esteja no lago, o dado fica disponível para todos na organização.”

Entretanto, se o hype dá a entender que as comunidades de usuários por toda empresa vão aproveitar um DL, então ele está sugerindo que todas essas comunidades são altamente habilidosas com manipulação de dados e análise, já que um DL não traz consistência, uniformidade e gestão dos metadados.


E nós sabemos que isso não é verdade. Eles vão adiante na questão e terminam (resumindo:)


Um DL tenta resolver dois problemas, um velho e outro novo. O velho é acabar com silos de dados: ao invés de ter várias fontes controladas de dados, jogamos tudo num só repositório, sem modificações. A consolidação, teoricamente, traria um maior uso dos dados enquanto reduz custos com licenças e servidores.

O novo tem mais a ver com BigData: pela própria disparidade das fontes, nem sempre dá para catalogar o dado na chegada e acomodá-lo em um SGBDR pode limitar futuras análises.

Atacar esses dois problemas com certeza beneficia a TI no curto prazo, no sentido de que reduz o trabalho para acomodar os dados, segundo o Sr. White. Porém, achar valor nestes dados permace tarefa do usuário final. Mas por mais que a aplicação de ferramentas ajude nisso, sem um mínimo de gestão tudo que conseguiremos é um monte de dados desconexos arquivados no mesmo lugar.


Bingo! E logo em seguida ele fala dos riscos de transforma um DL em um pântano se não houver um mínimo de gestão sobre ele. Ou seja, ao trocar um DW normal por um Data Lake arriscamos perder mais que ganhar. Arriscamos? Não, nós vamos perder, se não houver um mínimo de governança em cima desta infra-estrutura.

O Barato Sai Caro

Qualquer um que já passou pela frustrante experiência de manter um projeto de DW baseado em dumps sabe que a promessa de economia de tempo e recursos desse formato nunca se realiza. Fazer um dump pode até ser mais rápido que, por exemplo, desenhar um Data Mart e seu ETL. Porém, mais tarde, esses projetos batem com problemas que desperdiçam muito mais tempo que o rápido início economizou.

Um destes problemas é justamente racionalizar o uso dos recursos para poupar carregar o banco inteiro a cada atualização. A solução que sempre encontram é capturar um “delta”: comparar o sistema de origem com o dump no “DW” e trazer apenas as diferenças.

Mesmo assim há um custo em hardware e tempo inevitável. À esse custo os adeptos do DL respondem com a velocidade de carga do Hadoop, invariavelmente o miolo de DLs.

Outro problema é que a cada demanda do usuário por uma análise ou relatório, um novo ETL pós-dump precisa ser produzido. Até aí tudo bem, porque qualquer projeto de DW enfrenta isso. O problema é que qualquer alteração na origem “quebra” tudo que depende do dump e do nada surge uma montanha de retrabalho.

Ao que os seguidores do DL contrapõe outro argumento: self-service! Só que explorar um Data Lake não é para qualquer por dois motivos:

  • A pilha (stack) de tecnologia necessário é imensa. Um profissional especializado teria dificuldades, imagine um cara do Marketing?!
  • É preciso entender os dados e como eles “funcionam” para poder extrair valor deles. Nem mesmo todos os DBAs de uma empresa costumam saber tudo sobre os dados, quanto mais um leigo… do departamento de Marketing!!!

Entender muito de uma coisa faz com que tendamos a entender menos de outras. Marketing é uma ciência que se aproxima da arte, assim como muitas outras funções em uma empresa, e o custo de saber tanto do negócio da empresa é a tendência a saber menos de coisas como TI e BI. Não tenho nada contra “o Marketing”, só acho um bom exemplo do conflito entre a necessidade da informação e a capacidade de manuseio das ferramentas.


Viram o tanto que eu gastei de letras para explicar a idéia? Olhem e aprendam com quem sabe o que faz:


“The fundamental issue with the data lake is that it makes certain assumptions about the users of information,” said Mr. Heudecker. “It assumes that users recognize or understand the contextual bias of how data is captured, that they know how to merge and reconcile different data sources without ‘a priori knowledge’ and that they understand the incomplete nature of datasets, regardless of structure.”

While these assumptions may be true for users working with data, such as data scientists, the majority of business users lack this level of sophistication or support from operational information governance routines. Developing or acquiring these skills or obtaining such support on an individual basis, is both time-consuming and expensive, or impossible.


Sintético, completo, preciso! Elegante! Em tradução livre:


“A questão fundamental que um DL traz é que partimos de certos pressupostos sobre os usuários da informação”, disse o Sr. Heudecker. “Assume-se que os usuários reconhecem ou entendem o viés contextual de como os dados são capturados, que eles sabem como juntar esses dados e reconciliar diferentes fontes de dados sem um conhecimento prévio e que eles compreendem a natureza de incompletude dos conjuntos de dados, independentemente da estrutura.”

Ainda que esses pressupostos possam ser verdade para usuários que trabalham com dados, como cientistas de dados, a maioria dos usuários de negócios não possui esse nível de sofisticação ou apoio dos procedimentos de governança de informações operacionais. Desenvolver ou adquirir essas habilidades ou obter tal suporte em uma base individual e caro e demorado, ou impossível.


Eles vão no miolo da questão: propor um Data Lake presume que os usuários são de um tipo que quase não existe, e que transformar um usuário comum nesta figura de super-usuário é caro, se não impossível.

Outros Casos

O artigo segue adiante para discutir outros aspectos e riscos presentes em uma iniciativa de DL, mas o fulcro é sempre o mesmo: a falta de gestão do repositório, e a excessiva dependência do usuário final para geração de valor.

A certa altura vem este comentário (tradução livre:)


DL normalmente começa com repositórios de dados sem “governo”. Atender as necessidades de uma audiência mais ampla requer repositórios organizados, controlados, consistentes e com controle de acesso – elementos já disponíveis em um DW.


Conclusão

E o que tiramos disso tudo? O Gartner é bem simpático (tradução livre:)


White: Sempre há valor a ser encontrado nos dados, mas a questão que sua organização deve atacar é esta: “nós permitimos e até encorajamos análises que ocorrem uma única vez, autônomas, de dados que estão em silos ou em um Data Lake, unindo esses dados para aquela análise apenas, ou nós formalizamos esse esforço até certo ponto, e tentamos sustentar as habilidades que geram valor?” Se vamos endossar o herói, o agente solitário, um Data Lake com certeza possui um grande apelo. Se estamos mais tendentes à alternativa, um uso mais formalizado, então é melhor deixar o DL para trás e seguir para adotar uma estratégia baseada em DW.


Eu, bom, eu sou mais marrento mesmo, então as conclusões a que eu chego são:

  • Data Lake parece mais um conceito experimental que um produto ou serviço concreto e acabado;
  • Ainda não existe um caso de uso claro, ou mesmo nublado, que sirva para uma organização decidir-se pela adoção de um DL;
  • O conjunto de riscos e dificuldades associados a um DL supera de longe quaisquer prováveis benefícios.

Eu sempre digo que BI é uma disciplina, mais que ferramentas ou técnicas. Sempre que aparece uma tendência de mercado como o Data Lake (e Data Discovery, Cientista de Dados etc. etc. etc.), eu fico com o pé atrás, pois parece muito mais um tipo de Marketing do que uma tecnologia nova.

Talvez um dia evolua e torne-se uma peça valiosa do arsenal de BI. Mas por enquanto, por mais que adore a Pentaho e o Pentaho (e eu gosto muito dos dois, por enquanto), eu não vejo motivo para investir em um DL. Na verdade, eu vejo um alto risco de um projeto de DL acabar em problemas caros, ou até mesmo fracasso total.