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

Anúncios

Como um Data Vault Evolui

Ontem eu estava mexendo no meu projeto de DV de estimação (um aconselhamento que presto a um amigo) e descobri uma coisa: o satélite dos dados dos empregados tinha centenas de registros por empregado. Eu fui olhar de perto e descobri que não eram centenas, mas sim um por dia desde o início da captura dos dados. Para um DV, isso significa que a cada refresh (que é diário neste caso) o ETL está versionando o satélite de empregados. Como isso só aconteceria se todo dia houvesse alguma diferença para a última versão, eu decidi analisar os registros, comparando as versões de satélites para um empregado qualquer.

Eu vou mostrar algumas imagens para ilustrar o que eu fiz, mas saibam que todos os nomes foram mudados para coisas mais óbvias, e campos particulares (que possuíam detalhes da arquitetura do sistema) foram removidos. São ilustrações, não são o caso real, ok? Exceto por esse detalhe, todo o restante é a narração fiel do que eu fiz.

O satélite Empregado, mostrado na figura abaixo junto ao hub Empregado, tem cerca de 13 campos do sistema de origem, mais 4 de controle do DV.

Satélite empregado original, com todos os campos em uma única tabela.
Satélite empregado original, com todos os campos em uma única tabela.

Todos esses campos estão em uma única tabela no sistema de origem, de modo que a carga desse pedaço do modelo é feito por duas transformações: uma de hub e uma de satélite.

Eu descobri, depois de analisar o conteúdo do satélite, que três campos eram atualizados sempre que o empregado chegava para trabalhar e depois ia embora:

  • emp_ultimo_acesso
  • emp_ultimo_ip
  • emp_ultima_sessao

Na verdade, sempre que o empregado fazia login (e depois logoff) em qualquer computador na empresa, esses detalhes são atualizados. Resultado: todo dia eles estavam diferentes do dia anterior, a menos que o empregado tivesse faltado, ou o dia anterior fosse um feriado/fim-de-semana. Portanto, todo dia um novo satélite era carregado, e isso estava correto. O ETL estava fazendo o que havia sido programado para fazer.

Satélites Separados

Temos aqui uma situação clássica para Data Vault: o sistema de origem tem taxas de atualização diferente entre os atributos. Alguns são atualizados uma vez na vida e outra na morte, e outros são alterados todos os dias, quando não várias vezes por dia. Se capturarmos todos os registros na mesma tabela estaremos desperdiçando tempo e espaço em disco, tratando e gravando coisas duplicadas, desnecessariamente.

Neste caso optamos por quebrar um satélite em dois ou mais, em função de sua taxa de atualização: um satélite conterá apenas os três campos que mudam todos os dias, e o outro satélite ficará com os campos mais estáveis. Cada um terá sua própria transformação para carga. No final, nosso DV vai ficar assim:

Satélite Empregado, agora quebrado em duas tabelas em função da taxa de atualização.
Satélite Empregado, agora quebrado em duas tabelas em função da taxa de atualização.

Aplicando a Mudança

Antes havia um satélite (=uma tabela), com todos os campos, carregada por uma transformação. Depois teremos duas tabelas, cada qual com seu conjunto de campos, e cada qual carregada por sua transformação. Eis o passo-a-passo que eu passei para meu amigo aplicar em produção:

  1. Renomear o satélite original para s_empregado_antigo;
  2. Criar as duas novas tabelas, s_empregado e s_empregado_1;
  3. Popular cada uma com o histórico atual;
  4. Apagar o satélite original;
  5. Subir as duas novas transformações.

As novas tabelas foram criadas e populadas de uma só vez com um SELECT INTO (o DV está em Postgres, o que facilita tudo.) As transformações foram criadas semi-automaticamente (basta entrar os nomes das tabelas, campos e da transformação e um script parametrizado gera tudo sozinho.)

Pronto! Quinze minutos depois de diagnosticar o problema eu tinha desenhado a solução. Meu amigo avisou que aplicou e deu tudo certo e agora vai propagar a solução para outros satélites (ele tem vários desses com status instantâneo.)

(Bom, vá lá, eu demorei um pouco mais que quinze minutos porque deu um trabalhinho até eu acertar o SELECT – ele precisava manter o histórico, o que significa dois SELECT DISTINCTs, com ORDER BY etc. Mas agora eu já sei o macete, e da próxima vez vai ser só 15min mesmo!)

Outras Quebras

Outras opções de quebras para satélites são por sistema de origem, que dá a vantagem de integrar os dados já no DV, e por particionamento. Neste último podemos deslocar satélites estáveis para outras mídias (outros tablespaces), e continuar a carregar os novos em uma tabela menor.

O Que Kimball Faria?

Meu grande amigo Gurgel que me perdoe, mas eu não vou nem considerar essa situação na 3NF. Agora, como ficaria essa situação em um Modelo Dimensional?

Na verdade, ficaria muito bem, obrigado! Veja, Modelagem Dimensional é uma técnica resiliente e robusta, com muita flexibilidade. Teríamos praticamente a mesma abordagem: quebrar uma tabela (de dimensão) em duas, criar dois novos processos de cargas (duas novas transformações), e recriar a fato, agora com duas chaves no lugar de uma só.

Factível, viável e simples, sim. Interessante? Não tenho certeza: hoje esses dados não possuem nenhum interesse para o negócio do meu amigo. São dados que ele descartaria sem pensar duas vezes – e foi essa a primeira sugestão dele. Saber qual é a hora do último logoff de cada empregado não tem o menor impacto no rendimento da empresa, nem a menor relação com a produtividade desse empregado. É um dado pura e simplesmente inútil, e só entrou no satélite porque simplificamos o levantamento de requisitos ao mínimo essencial – o também clássico carrega tudo!.

O Que Linstedt Faria?

Tá bom, saber quando o empregado fez o último logoff do dia é inútil. Mas e saber o histórico completo de todos os logins e logoffs, interessa?

Veja, estamos falando de capturar todas as mudanças, até mesmo em tempo real se for necessário. Para conseguir isso, sem gastar muito, basta rodar apenas a transformação que carrega esse satélite (com um ajuste para a variável de tempo – detalhes que não vêm ao caso agora…) a cada hora ou minuto. Com algumas centenas de empregados esse processo seria muito leve.

No caso mais extremo, dá para agendar uma PROC no banco que faça isso, e descartar o PDI completamente, reduzindo ainda mais o impacto da captura de histórico.

Com esses dados, novas perguntas são possíveis:

  • Será que um empregado que entra e sai do sistema várias vezes produz menos?
  • Preciso me preocupar com isso?

Um modelo dimensional permite capturar isso se você quiser. Basta montar uma estrela só para isso, já que esse vai ser o processo de negócio em análise.

Agora, e aqui vem uma das coisas legais do DV, um Data Vault te permite capturar isso já integrado com os outros satélites, o hub e tudo o mais. Um bom desenhista dimensional sabe que a técnica do Kimball também te dá essa possibilidade. Mas quanto mais você extende seu DW Dimensional com esse tipo de recurso, mais chega perto de um modelo Data Vault! A quantidade de dimensões e inter-relações (o Bus Matriz) começa a crescer, e a gestão vai ficando cada vez mais difícil. Apesar de flexível, a Modelagem Dimensional não é pensada para acumular dados, mas para análisá-los e por isso, cedo ou tarde, se seu DW muda com frequẽncia, um DV vai se tornar uma alternativa interessante.

E então você vai testar, só para ver como seria. E, então, já será tarde demais. Você será fisgado, como eu fui.

Até a próxima! Fui! :-)

Packt Video Review – Building a DM with PDI

This video, Building a Data Mart with Pentaho Data Integration, teaches how to apply the Kimball Dimensional Modeling technique with Pentaho Data Integration tool. At the beggining it disclaim it will not teach Dimensional Modeling or how to use PDI. Considering how sophisticated Kimball’s technique is, the content is very usefull for anybody how has to assembly such Dimenional Data Marts.

I liked it very much:

  • The video has very high quality: 1920×1080 @ 25 fps and 44KHz audio stream.
  • The video capture is very fluid, very stable, no skipping. The machine on which it was recorded is blazing fast, and paired along Ubuntu it just screams – no loading times, no lags, only smooth movements. You can see it is not an edited video because most of the time the mouse cursor does not do leap around the screen;
  • The product is not only a video feed, it has a whole site with the video splitted in sections, make it easy and an ease to navigate, to play, stop and resume;
  • The narration is very concise and sparingly (no hums and ehhs or silences.) You can see it has been edited to reach this quality;
  • The product is very complete, with downloadable material;
  • It is totally based on FOSS community editions softwares, so no extra cost at all to follow it (although it does use Pentaho Analyzer, but a free limited feature license one – very high added value because this is a very usefull tool;)
  • It shows en passant how to use the EObjects Data Cleaner to achieve better data quality, which is a huge plus just by mere mentioning it;
  • It is a very good course because it address not only the promised subject with detail, but it also teaches a lot on important aspects of data warehousing, like using columnar databases, caring about data quality, file and database versioning etc.;
  • Most of the technical decisions are justified, which means you bask on the author experience.

I didn’t like it:

  • The narrator has an accent with gets in the middle sometimes (I could never fully understand the second part titles), but you get accostumed to it. Also, I believe they’ve changed narrators a couple of times or maybe changed the pitch – the guy sounds a bit different at some chapters. No big deal;
  • The sound has some volume and pitch wobling: sometimes (and quite frequently) it sounds like having skipped a frame or two and the voice goes into a higher pitch while decreasing the volume a bit. However, other than a little irritanting, it does not impair the hearing and you eventually also get accostumated to it;
  • The use of JNDI connections: PDI has variables which are better fit to make connections portable than JNDI. However, it is a technical option you don’t need to follow and it does not negativelly affect the video or the content and its usability;
  • On the Packt off-line video interface I missed very much some buttons to replay the video or go back a little, pause it and so on. When you download and play with your favorite media player everything is ok, tough.

Conclusion

I could go on and on listing things I liked about this video, but I’d became repetitive. On the other hand, the bad things are not really important. Besides the listed above, I could hardly find anything else.

Packt's video has very high quality.
Packt’s video has very high quality.

The content is rich, detailed, carefully organized and laid out, very usefull and very practical. The video itself is very good, worth an in person course, technically very well done, and with a nice off-line interface. The negative points amounts to some quirks of the audio and the offline interface navigation buttons that I miss, but none of them are really important and do not stand in the way for an enjoyable experience.

All in all, Building a Data Mart with Pentaho Data Integration is a buy if you need to learn how to use PDI to design an ETL process for loading a Dimensional Model.

Gravar Fato com Dimension Lookup/Update

Inteligência e criatividade já foram definidas como misturar coisas com um propósito e atingir outro. Eu tive o melhor exemplo disso há pouco, durante uma aula.

Explicando a gravação de uma fato, e peculiariedades de cada tipo de fato (snapshot, acumulating etc.), ela me perguntou:

Ah, então eu posso gravar a fato com a Table Output, e se quiser atualizar uso um Dimension Lookup/Update?”

De cara eu não entendi a pergunta – “Comparar table output com dimension lookup/update? Mas não tem nada a ver…” – foi quando eu parei para pensar e vi que era não só uma pergunta lógica, como óbvia.

Sim, claro, o D L/U (Dimensio Lookup/Update) é um passo dedicado a gravar dimensões, mas a lógica dele se presta a qualquer gravação/atualização que envolva uma chave composta e “coisas” (métricas!) que variem (ou não.)

Eu resolvi fazer um teste. Essa é a transformação que grava a fato pedido da Beltrano S/A, tirada do meu livro Pentaho na Prática:

Transformação que carrega a fato, usando passo "normal" Insert/Update.
Transformação que carrega a fato, usando passo “normal” Insert/Update.

Eu então troquei o Update no final por um D L/U – e não mexi em mais nada:

Transformação que carrega a fato, usando passo D L/U.
Transformação que carrega a fato, usando passo D L/U.

E essa ficou sendo a configuração do passo (eu tratei o tipo de pagamento como uma degeneração, mas sem querer coloquei como métrica):

Configuração do passo D L/U para gravar uma fato.
Configuração do passo D L/U para gravar uma fato.

Resultado? Bom, depois que eu criei a fato com o botão de SQL do D L/U e carreguei, ela ficou assim:

Fato gravada pelo passo D L/U. Repare que todos campos de controle da dimensão foram chamados de fut_ext_x (futuras extensões), e que agora ela possui uma chave primária.
Fato gravada pelo passo D L/U. Repare que todos campos de controle da dimensão foram chamados de fut_exp_x (futuras extensões), e que agora ela possui uma chave primária.

Ou seja, é a fato, mas com os campos de controle da dimensão. Eu nomeie todos eles como futuras expansões (fut_exp). A chave delegada também está lá, mas agora na função de uma chave primária! Compare com a fato “normal”:

A tabela fato gravada com um passo normal. (As chaves zeradas são um bug da minha transformação, que está bagunçada (sabe como é, próxima versão do livro...)
A tabela fato gravada com um passo normal. (As chaves zeradas são um bug da minha transformação, que está bagunçada (sabe como é, próxima versão do livro…)

Os zeros nas chaves decorrem do fato de a minha transformação estar em mudança – por algum motivo eu não recuperei as chaves (pau do banco?) – mas normalmente dá certo. Por favor, releve como ruído no material do livro, que está sendo revisado.

Conclusão? Dá certo! (Claro que dá, mas… como é que eu nunca pensei nisso antes???) Será que é alguma vantagem usar o D L/U para isso? Será que simplifica alguma lógica? A ver!

Genial! :-)

Novo Livro: Pentaho Data Integration Cookbook – Segunda Edição

Um cookbook é um livro de receitas (recipes), e normalmente se vale de o leitor possuir algum conhecimento sobre o assunto (culinária via de regta) para ensinar algumas receitas. Por exemplo, para aprender a fazer um bolo você precisa saber quebrar ovos, que é algo que ninguém te ensina – um dia você viu alguém quebrar ovos para cozinhar e pronto, hora da receita (Recipe Time!)

Eu ganhei da Packet mais um livro sobre Pentaho para resenhar, o Pentaho Data Integration Cookbook (Segunda Edição), lançado há algumas semanas. Ele não ensina como instalar o PDI, ou rodá-lo, nem explica o que é uma transformação, um job e como criar um novo de cada. Isso é tarefa para outros livros, como o também excelente Pentaho 3.2 Data Integration: Beginner’s Guide.

O PDI Cookbook te ensina receitas, pequenos how-to, para mais de 100 objetivos. Ele tem receitas para ensinar a conectar uma transformação a um banco de dados, e como parametrizá-la (e porquê), uma para ler dados de tabelas em bancos relacionais, outra para construir e usar sub-transformações e ainda outras sobre como gravar os dados em clusters Hadoop, manusear o fluxo e os metadados de transformações, executar análises de dados, gerar relatórios, executar dentro do BI Server e assim por diante. Ele não esgota as possibilidades, mas chega bem perto de. Você pode consultar a página do livro na Packt, aba Table of Contents, para ver a lista completa.

Estou com o livro há duas semanas e ainda não li o livro todo, mas olhei uma boa parte delas e fiz questão de ler com cuidado algumas receitas sobre coisas que eu conheço (como conexões parametrizadas, leitura de dados, lookups e fluxos) e algumas sobre coisas que eu nem imagino como sejam (como ler e gravar dados do Salesforce.com e do Hadoop.)

Cada receita demanda algum conhecimento prévio do leitor, mas tem informação o bastante para não deixar dúvidas para os iniciantes, sem aborrecer o leitor mais experiente. As figuras são usadas com parcimônia, notadamente quando os autores sentem necessidade delas para explicar melhor algum detalhe ou comunicar uma configuração com mais precisão. Se por um lado isso torna o livro menor (e ele já um bom catatau, com mais de 400 páginas), por outro força o leitor a prestar mais atenção e requer mais familiariedade com os termos envolvidos. Ele não dá tudo mastigadinho, mas tem boa didática e os textos são bem escritos (mais sobre isso daqui a um parágrafo.)

Muitas (se não todas) receitas trazem dicas sobre eventuais opções ou formas alternativas de se obter o mesmo resultado, ou ainda alguma variação sobre o tema. Em várias das receitas que eu li há comparações entre métodos (como o lookoup de dados, que explicita a diferença entre Database Lookup e Database Join, por exemplo) e em geral há comentários sobre impactos de performance quando são significativos. A location 400 traz um dos meus favoritos, pela engenhosidade: usar bancos de dados em memória (como HSQDB ou H2) para montar lookups transitórios de alta performance.

Claro que, como a maioria dos livros da Packt é escrita em inglês por não-nativos, a linguagem do livro é por vezes menos fluída que o inglês de um norte-americano ou britânico (ou mesmo um aussie.) Acho que essa é única coisa do livro que é mais… desconfortável, mas decididamente não afeta o resultado final.

Enfim, o livro é um verdadeiro baú do tesouro, com grande valor para desenvolvedores novatos ou experientes. Se você já sabe mexer com o PDI, e quer se aprofundar nele, esse livro é uma boa escolha. Se você quer aprender a mexer no PDI, procure antes algo como o PDI Begginer’s Guide, e depois não deixe de investir no PDI Cookbook (mas a segunda edição; a primeira ainda tinha espaço para melhorar, tanto que foi o que fizeram.)

É isso, grande leitura! ;-)

Acesso ao Log do BI Server, Quick & Dirt Parte 2 – Usando XActions

No post anterior eu mostrei como implementar a genial idéia do Gerson Tessler para acessar os logs do BI Server via o próprio BI Server usando um relatório PRD e uma transformação. Agora vamos ver outra técnica (que eu prefiro porque tem um overhead menor): como expor o log do BI Server (ou qualquer outro) usando a mesma transformação e uma XAction.

Primeiro você precisa instalar e configurar o Pentaho Design Studio. Acesse a página de links do site companheiro do livro Pentaho na Prática e baixe o capítulo de degustação. Olhe nas páginas 3, 5 e 17 como instalar o PDS. Depois baixe este guia rápido e configure um projeto para seu BI Server 4.8. Teste e brinque um pouco com o BI Server e o PDS, até sacar a mecânica da coisa (atualizações feitas com o PDS sobre XACTIONs aparecem no BI Server depois de um refresh do repositório, a menos que você use um repositório em arquivo.)

Pronto? Vamos lá:

  1. No PDS clique com o botão da direita sobre a Beltrano e escolha a opção BI Platform e depois New Action Sequence;
  2. Na janela que aparecer deixe o campo Container como está e modifique o nome no campo File name de untiltled.xaction para log.xaction;
  3. Aba General: não mexa em nada e pule para a aba seguinte, Define Process;
  4. Na aba Define Process clique no ícone de mais azul que fica na seção Process Actions. Vai se abrir um menu: escolha Get Data From e depois Pentaho Data Integration;
  5. Usando a Figura 1 como guia, preencha:
    1. Name: não precisa mudar nada;
    2. Input Section: Transformation File deve apontar para a transformação (preencha com solution:le_log_biserver.ktr ou use o botão Browse – mas ele nunca funciona comigo…). Depois digite em Transformation Step o nome do passo que o BI Server deve drenar para receber as linhas lidas pela transformação, que é Saida;
    3. Output Section: preencha apenas o campo Output Rows Name com resultado, que é um nome da variável para receber as linhas drenadas da transformação;
  6. Para “imprimir” o que foi lido, adicione a variável resultado à seção Process Outputs (basta clicar no ícone de mais azul e selecioná-la).
Figura 1: configurando a execução de uma transformação no PDS. (Clique para tamanho natural.)
Figura 1: configurando a execução de uma transformação no PDS. (Clique para tamanho natural.)

E está pronto. Salve a XAction, mude para o BI Server, faça login, depois um refresh do repositório. A Xaction deve aparecer – execute-a com um duplo clique. Se tudo deu certo você vai ver o mesmo resultado do post anterior, feito com PRD, mas agora sem a “cara” de um relatório (Figura 2.)

Figura 2: exibindo o log do BI Server com XAction e transformação. (Clique para tamanho natural.)
Figura 2: exibindo o log do BI Server com XAction e transformação. (Clique para tamanho natural.)

Como da outra vez você pode baixar o pacote no site do Open BI Solutions: https://sourceforge.net/projects/openbisolutions/files/Logs/.

Até a próxima!

Acesso ao Log do BI Server, Quick & Dirt

Qualquer desenvolvedor de soluções com o BI Server precisa ter acesso ao(s) log(s). Na maioria das empresas os desenvolvedores simplesmente têm acesso direto ao BI Server e podem examinar os arquivos de log diretamente. Em outras empresas, porém, isso não é possível – não me pergunte porquê, mas existem empresas nas quais o desenvolvedor é proibido de acessar o ambiente de desenvolvimento. De produção, então, nem pensar!

Gerson Tessler, meu colega de trabalho e amigo, que mexe com Pentaho desde 2008, deu uma solução genial para esses desenvolvedores desafortunados: usar o próprio BI Server para examinar qualquer log. Fácil, simples, óbvio – a marca da genialidade!

Vamos fazer como um laboratório:

  1. Monte um BI Server e remova as pastas de demonstração;
  2. Crie uma pasta vazia. Como eu sempre uso a Beltrano S/A para tudo, minha pasta se chamará Beltrano;
  3. Abra o PDI e crie a transformação da Figura 1 (adicione um passo Text File Input e um Dummy, ligando o primeiro ao segundo):

    Figura 1: Layout de passos da transformação.
    Figura 1: Layout de passos da transformação. (Clique para tamanho normal.)
  4. Configure o Text File Input:
    1. Insira ${Internal.Transformation.Filename.Directory}/../../tomcat/logs/pentaho.log no campo File/Directory da seção Selected Files, aba File (Figura 2);

      Figura 2: configurando o arquivo. (Clique para tamanho normal.)
      Figura 2: Configurando o arquivo. (Clique para tamanho normal.)
    2. Aba Content (Figura 3), campo Filetype: CSV; campo Separator: §§§ (ou qualquer coisa que dificilmente aparecerá no log); desligar o checkbox Header; Format Unix (Linux e Mac) ou DOS (Windows); Encoding UTF-8;

      Figura 3: configurando a interpretação do arquivo. (Clique para tamanho normal.)
      Figura 3: Configurando a interpretação do arquivo. (Clique para tamanho normal.)
    3. Aba Fields (ignore todas as outras): registre um campo chamado log_line como Type String, deixando todos os outros parâmetros vazios.
  5. Dummy: apenas mude o nome para Saida (sem acento);
  6. Salve dentro da pasta Beltrano, em ./biserver-ce/pentaho-solutions/Beltrano.

Essa transformação vai ler o arquivo de log independentemente de onde estiver o BI Server, porque se refere ao arquivo de maneira relativa, apontando para o ./tomcat/logs a partir de dois diretórios acima do pentaho-solutions /beltrano. (Nota: talvez no Windows seja preciso reverter a barra, mas teste antes.)

Segunda parte: executando a transformação a partir do BI Server, para o qual temos duas opções. A primeira e mais trivial é usando um relatório criado com o PRD:

  1. Rode o PRD e crie um novo relatório e salve-o (já, senão pode dar erro) na mesma pasta da transformação, ou seja, na Beltrano dentro do BI Server;
  2. Clique com o botão da direita no cilindro amarelo (aba Data) e selecione Pentaho Data Integration;
  3. Na janela que se abrirá (Figura 4) clique em Browse e selecione a transformação – que deve estar no mesmo diretório;

    Selecionando uma transformação como fonte do relatório.
    Figura 4: Selecionando uma transformação como fonte do relatório.
  4. No que a janela de seleção se fechar, os passos da transformação serão listados. Clique em Saida e depois em Ok;
  5. Voltamos à lona, para construir o relatório (Figura 5). Sem estresse: arraste o campo log_field para a banda Details;

    Posicionando e configurando o campo. (Clique para tamanho natural.)
    Figura 5: Posicionando e configurando o campo. (Clique para tamanho natural.)
  6. Posicione o campo no extremo esquedo e alargue-o até ocupar a folha inteira;
  7. Com o campo selecionado, mude para a aba Structure, sub-aba Style. Localize a propriedade Dynamic Height e sete-a para TRUE;
  8. Para ficar bonito, acesse o menu File, opção Report Properties (e aba Descriptio na janela que se abrir) e preencha o título (algo como “Log”, mas sem as aspas… ;-) );
  9. Salve, faça login no BI Server, comande um refresh e execute o relatório.

Se tudo deu certo vai aparecer a Figura 6:

Examinando o log do BI Server via relatório dentro do BI Server.
Examinando o log do BI Server via relatório dentro do BI Server.

Veja que estamos acessando um dos arquivos do diretório de logs do BI Server e que podemos usar o mesmo método para qualquer arquivo. Não apenas isso, mas como estamos usando uma transformação em um relatótio, podemos combinar as capacidades dos dois e adicionar (por exemplo), filtros por data e hora, horizonte (quanto do log mostrar) etc.

A outra maneira é rodando uma XAction, que eu vou publicar em em 15/8/13. Até lá você pode obter o pacote relatório + transformação no site de projetos de BI livres: https://sourceforge.net/projects/openbisolutions/files/Logs/. Basta descompactar o arquivo dentro do seu pentaho-solutions/Beltrano (ou qualquer outra pasta) e atualizar seu BI Server. Deixe um comentário aqui se tiver algum problema.

Hackeando Transformações

Ocasionalmente precisamos alterar o volume de linhas lido de um banco por um Table Input, numa tranformação, para testar o processo inteiro. Se você tem apenas uma transformação, isso é fácil – basta abrir a transformação com o Spoon, alterar e testar.

E quando você acabou de montar o ETL inteiro, criou o job e ele vai levar algumas horas para rodar completamente? Cada teste de ponta-a-ponta pode levar algumas horas, e nós nunca queremos esperar horas para descobrir um erro numa RegEx no meio da última transformação. Não, especialmente quando não dá para rodar uma só de cada vez, mas precisamos rodar todas na sequência. E foi isso que me aconteceu: eu precisava testar a carga de certas variáveis e ver se todas as transformações de um ETL estavam tratando as variáveis corretas.

Eu poderia deixar o processo rodar e, a cada erro (que poderia ou não existir) eu corrigiria e reiniciaria tudo. Bummer! Horas para descobrir se havia erro, e mais horas para ter certeza que o consertara! Não, precisava haver uma forma melhor.

Como os arquivos eram todos texto (eu sempre salvo meus ETL em arquivo, raramente uso o repositório do PDI), eu tinha outra saída: um comando de linha que alterasse cada arquivo, mudando o limite de leitura de cada Table Input de 0 (infinitas linhas) para, por exemplo, 1000. Pedi ajuda a um grande e famoso (Wikipedia!!) amigo, Júlio Neves, que me deu o seguinte comando:

sed -i ‘s-<limit>0</limit>-<limit>1000</limit>-‘ *.ktr

Ele usa o Sed para alterar o parâmetro diretamente nos arquivos das transformações. Assim, com um comando de uma única e miseravelmente curta linha eu alterei o projeto todo!

Depois de finalizado o teste, o comando “reverso” leva o projeto de volta a seu estado original:

sed -i ‘s-<limit>1000</limit>-<limit>0</limit>-‘ *.ktr

Ou eu poderia simplesmente jogar as novas transformações fora e puxar do repositório de novo.

Observação: o Sed é um programa que faz parte da maioria (se não de todas) as distribuições Linux/Unix. Mas você pode tê-lo no Windows também. Basta instalar o Cygwin. É um pouco chato, para quem nunca mexeu com Linux, mas o poder que ela traz é proporcional. Vale a pena!