MDX Para Quê?

Por que alguém precisaria aprender MDX? É o que eu pretendo justificar aqui.

Preparado?

Get set, ready, go!

M-D-OQ?

MultiDimensional Expressions é uma linguagem para construção de visões de dados multidimensionais (i.e. com cabeçalhos em linhas e colunas) inventada pela Microsoft, a partir da meta simples de levar BI para as massas.

MDX é muito parecido com SQL, no sentido de que é uma consulta que “constrói” uma “tabela”, exceto por alguns fatos:

  • O resultado tem uma forma mais semelhante a uma planilha que a uma lista;
  • O motor que trata consultas MDX não é um banco de dados relacional tradicional, mas um servidor de dados multidimensional;
  • MDX não possui uma DDL, que é um conjunto de comandos para definir estruturas de dados. Em SQL, por exemplo, CREATE TABLE é um comando DDL;
  • E não tem esses comandos justamente porque o propósito do MDX é fazer consultas, não transações. Mesmo assim, criou-se uma coisa chamada writeback, que permite escrever dados de volta para o servidor multidimensional.

Se você ainda não adivinhou, MDX é uma linguagem de consulta de cubos OLAP. Daí você entende facilmente que MDX é apenas parte de uma arquitetura maior, que engloba um servidor OLAP, ou multidimensional (do qual o Mondrian é um tipo), e algum tipo de processo de atualização de dados.

Há dois bons livros para aprender sobre OLAP e MDX:

O Problema

Vamos deixar MDX de lado um pouco, e examinar o problema desta semana. Para (não) variar, é um problema que eu vim a enfrentar ao tentar resolver uma situação muito ordinária, apresentada por um colega de trabalho.

Esse colega trabalha no marketing da empresa e fez uma pesquisa com nossos empregados. De maneira geral, a pesquisa tinha dois tipos de perguntas:

  • Perguntas com respostas únicas, como sim/não ou uma lista de opções do qual somente uma podia ser escolhida. Por exemplo, setor do empregado (uma opção de uma lista), e se conhecia a estratégia da empresa (sim ou não;)
  • Perguntas que podiam ter nenhuma resposta, uma resposta ou mais de uma resposta. Exemplos: qual é seu meio preferido de comunicação (cite até três).

Para simplificar, assuma que esses dados eram coletados em uma planilha com este layout:

ID P1 P2.A P2.B P2.C
1 Sim E-mail
2 Não Cartaz Reunião
3 Sim

Obviamente a pesquisa era bem maior que isso, e tínhamos várias perguntas de cada tipo. O que é importante guardar aqui é que existe uma pergunta que gera uma resposta em uma única coluna, como a P1, e perguntas que geravam suas respostas em n colunas – duas, três, dez.

Como analisamos esses dados? Bom, por exemplo, podemos perguntar quantas pessoas conhecem a estratégia da empresa, que é a P1. A resposta é obtida somando-se todos os SIMs da lista de respostas. Um simples SELECT COUNT('SIM') AS conheco FROM pesquisa traria a resposta. Ou falando em termos de Excel, basta colocar uma função de contagem para totalizar a coluna da P1.

Outra pergunta pode ser: quantas pessoas têm no e-mail seu meio de comunicação preferido? A resposta, de novo, é obtida com relativa facilidade: contamos quantas vezes a expressão E-mail aparece na coluna P2.A.

Mas é claro que a realidade nunca é assim tão fácil, não é mesmo? Não teria graça, se fosse. ;-)

Suponha que nosso chefe peça o seguinte: “descubra os três meios de comunicação mais preferidos, por ordem do mais votado para o menos votado”.

Fácil? Algoritmicamente, talvez:

  1. Conte P2.A, P2.B, P2.c etc.
  2. Crie uma outra tabela, de duas colunas: opção e contagem;
  3. Insira, na primeira linha desta tabela, o rótulo “E-mail” na coluna 1, e sua contagem na coluna 2;
  4. Repita isso para todas as outras opções;
  5. Ordene esse tabela do maior para o menor, usando a coluna 2 e limitando o resultado em 3 linhas.

O resultado seria algo assim:

Meio Contagem
E-mail 10
Cartazes 7
Reuniões 2

“Ah”, pensas tu, “fácil como torcer para o Grêmio, guri!”


Estou em um treinamento de Lean Business Analysis pelo Luiz Parzianello, um porto-alegrense bah, tchê! Daí eu acabei pegando o sotaque, índio velho!


Então você pensa que é fácil?

Hahahahahaha…

Permita-me frisar:


HahahAHhAHHHaHAhAhAHAHHHahahaHAhahaha!!!….


É qualquer coisa, menos fácil. Por favor, tente essas análises:

  1. Qual é a porcentagem de empregados que conhece a estratégia e prefere e-mail?
  2. Qual é a porcentagem de cada opção, em cima do total de empregados que responderam essa pergunta?

A primeira análise é similar à inicial, mas com um filtro aplicado (conhece a estratégia = sim) antes de calcular a razão entre todos que responderam SIM para opção de e-mail pela quantidade de SIMs totais.

E a segunda? Simples:

  1. Calcular a razão entre a quantidade que respondeu “prefiro e-mail”, pela quantidade de participantes que tem pelo menos uma resposta;
  2. Calcular a razão entre a quantidade que respondeu “prefiro cartaz”, pela quantidade de participantes que tem pelo menos uma resposta;
  3. Etc.

E é claro que fica cada vez mais complicado: depois de dois dias trabalhando com Excel sem parar, o chefe olha seu relatório e diz: “excelente! agora quebra por setor!”

Vamos é querer quebrar a cabeça do pobre desafortunado que decidiu te ter na equipe, não é?


Vou tentar colocar de outra maneira: contagens simples são, como o nome implica, ações triviais. Só que, em geral, o maior valor de negócio está nas análises mais complexas, mais sofisticadas. Coisas que nem sempre podem ser respondidas com filtros e contagens.

Se meu exemplo não passou esse cenário, perdão. Esse é o cerne do problema: análises “complexas”


Trabalho de Ser Vivo de Crânio Ornado com Projeções Ósseas

Pode não ser um trampo excessivo quando temos uma pesquisa só, que por sua vez contém apenas uma pergunta deste tipo, que não tem mais que meia-dúzia de opções.

Mas, adivinha: meu colega vai fazer uma pesquisa assim uma vez a cada pelo menos dois meses! E cada uma das pesquisas do baita tem, por alto, uma meia-dúzia dessas perguntas, cada uma com quase dez opções, se não mais. E cada pesquisa atinge 10.000 empregados, com uma taxa de quantidade de respostas média em torno de 3.000. Ou seja, dos 10.000 pesquisados, em média, 3.000 respondem.

E conforme o número de variáveis sobe (gênero, setor, cidade, faixa etária, conhecimento etc. etc. etc.) sobe exponencialmente o trabalho para correlacionar uma coisa com outra.

Mas fica pior.

Uma Pergunta Múltipla Incomoda Muita Gente…

.. duas incomodam, icomodam muito maais.

Uma técnica prática para simplificar o trabalho de corno que é tabular esse tipo de dado é transpor parte da pergunta, ou desnormalizá-la. Por exemplo, a tabela do início vai de:

ID P1 P2.A P2.B P2.C
1 Sim E-mail
2 Não Cartaz Reunião
3 Sim

para:

ID P1 P2
1 Sim E-mail
2 Não Cartaz
2 Não Reunião
3 Sim

Notou o que eu fiz? Eu repliquei cada linha que tinha mais de uma resposta, e coloquei todo mundo lá.

Agora ficou mais fácil fazer uma contatem simples. Mas o que aconteceu se eu tiver DUAS perguntas de múltiplas escolhas?

ID P1 P2 P3
1 Sim E-mail Escolha X
1 Sim E-mail Escolha Y
2 Não Cartaz Escolha Y
2 Não Cartaz Escolha K
2 Não Cartaz Escolha Z
2 Não Reunião
3 Sim Escolha Y

Agora não basta mais contar cada coluna: é preciso deduplicá-las antes, e fazer as contas depois.

Uma vez a cada dois meses.

Em datasets pequenos, de coisa de 3.000 linhas… E algumas dezenas de colunas. Duas perguntas de cinco escolhas cada, as 3.000 linhas iniciais pulam para pelo menos cerca 6.000, podendo chegar – em casos extremos – a centenas de milhares de linhas… PARA SEREM TRATADAS NO EXCEL.

Não vira, né? ;-)

Operações de Conjuntos

Foi tentando resolver esse problema que a minha ficha caiu: eu vou precisar de um ETL específico para cada pergunta de resposta múltipla para colocar tudo como colunas simples, para permitir contagens simples, mas cada contagem vai ficar mais complicada ainda! É um círculo vicioso! A solução que achamos foi aplicar essa transposição coluna a coluna, uma de cada vez, e fazer análises estanques. Só depois, então, as análises de cada coluna são feitas.

MDX To The Rescue

Bom, MDX é difícil, na prática, mas na teoria, no conceito, é simples: uma expressão literal que manuseia conjuntos multidimensionais.

Falando de outra maneira, é uma linguagem que trata um problema complexo como o que eu expliquei aqui, com muito menos trabalho que toda operação manual.

Por exemplo, o caso inicial – top 3 canais – pode ser descrito como um conjunto formado pela união de três subconjuntos, que por sua vez recebeu uma ordenação com limite.


Eu voltarei ao assunto com um exemplo concreto. Por ora, por favor, tentem visualizar o que estou descrevendo.


Mas e se tivermos, por exemplo, várias perguntas de múltiplas respostas? Não tem importância: comandos MDX, que podem ficar verdadeiramente cabeludos, lidam com conjuntos de membros de uma dimensão (as opções de cada pergunta) e calculam as métricas para aqueles cruzamentos. Comandos que constroem sub-conjuntos podem ser aninhados para montar dois, três, n conjuntos e, em seguida, totalizá-los o apresentá-los como uma matriz – uma planilha.

Complexo? Sim. Pouco intuitivo? É, um pouco. Torna tudo viável? Sim!

Conclusão

Muito de análise multidimensional pode ser feito com um conjunto de dados simples e uma boa ferramenta OLAP. Porém, certos conjuntos de dados representam um desafio muito maior – que nem mesmo um bom trabalho de ETL pode simplificar. Podemos acabar mudando um problema complexo em outro, tão complexo quanto ou mais!

A linguagem MDX, e as tecnologias OLAP associado por trás, como servidor de dados multidimensional, pré-agregadores etc., são uma opção poderosa, geralmente certeira e muito pouco conhecida!

É esse cenário que eu pretendo mudar, daqui para o final do ano.

Até lá, guarde em mente que um analista de dados deve aprender MDX por dois motivos simples:

  • Permite analisar mais dados, mais rapidamente;
  • Simplifica o trabalho de responder uma pergunta a partir dos dados, tornando algo complexo em simples, e tornando em possível o im possível.

Até a próxima! ;-)

 

Anúncios

A Vantagem do Visual

Recebi o pedido de um post:

Fábio, você poderia fazer um post sobre sua experiência no pentaho referente a performance? Desenvolvo um projeto onde eu prefiro realizar todas as transformações via query e percebi que você utiliza os componentes do pentaho para fazer o mesmo. Como tenho poucos dados de testes quando vou testar a performance de ambos acaba dando quase o mesmo resultado em questão de tempo.

E é claro que eu vou atender. ;-)

Comparar ou Não Comparar, Eis a Questão

Suponha que eu escolha, como um exemplo para medir essa performance, copiar uma tabela para outra, no mesmo banco:

  • A query ganharia, já que nada bate uma cópia interna, de uma tabela para outra, dentro do mesmo banco.
  • Se a cópia fosse entre dois bancos diferentes, na mesma máquina, ainda seria muito rápido, mas acho que precisaria apelar para uma linguagem do banco, ou algum recurso não-padrão para que o SELECT em um banco sirva de entrada para o INTO em outro. Imagino que a consulta ainda bateria o PDI.
  • Agora, se a cópia fosse entre duas máquinas diferentes, talvez houvesse um empate porque a rede entre as máquinas passaria a ser um gargalo. Como os dois recursos (query e PDI) normalmente são muito mais rápido que a maioria das redes, a velocidade final seria limitada pela velocidade da rede, e daria empate.

Se eu escolhesse ler um arquivo e carregar no banco, os fatores envolvidos seriam outros e os resultados desse caso não teriam nenhuma relação com os resultados do caso anterior, da cópia entre duas tabelas. Se fosse um join, outro resultado. Se fosse um lookup em banco a partir de um arquivo, outro resultado. Etc. etc. etc. e assim por diante.

Ou seja, os resultados de uma comparação desse tipo seriam inconclusivos, pois oscilariam entre vantagem ora de um método, ora de outro.

Vendo Vantagem

Então tanto faz? A performance, na média, vai ser sempre a mesma para qualquer tecnologia?

Nem de longe. A comparação direta de performance entre as duas técnicas (PDI e SQL) pode ser uma medida muito difícil, mas não deve ser importante para optar por uma ou por outra. O que deve nortear sua escolha é, como sempre, o custo-benefício.

Se as suas transformações só envolvem bancos de dados, todos do mesmo tipo, pode ser que seja mais fácil desenvolvê-las usando SQL – já está tudo ali mesmo, e rodar SQLs diretamente no banco pode dar muito menos trabalho que baixar o PDI, configurar uma máquina, desenvolver as transformações e agendâ-las em produção.

Se o seu processo envolve arquivos (talvez em um servidor remoto), bancos (de diversos tipos), uma área de transferência temporária (palco ou stage) etc. etc. etc., desenvolvê-lo usando SQL pode ser tão complexo quanto construir uma nova aplicação do zero. Num caso desses, usar o PDI pode até redundar na mesma performance, mas o desenvolvimento desse processo será – eu te garanto – muito menos trabalhoso. Sua produtividade tende a ser mais alta com o PDI que com uma linguagem de programação.

Conclusão

A performance de cada processo depende de um sem-números de fatores, e o critério para você fazer uma escolha entre as tecnologias possíveis, em princípio, é o custo de cada uma dessas opções, comparado com o retorno que elas vão te dar.

Como o PDI permite desenhar todo processo graficamente, “ligando os passos”, um analista produz muito mais usando o PDI que desenvolvendo um programa em alguma linguagem.

Mas e a performance, Fábio? Afinal, qual eu devo escolher se a performance for importante? PDI ou Query?

PDI, sem sombra de dúvida. Porquê? Porque o PDI oferece muitos mecanismos para melhoria da performance do processo e você fatalmente vai conseguir a performance que precisa, a uma fração da complexidade do desenvolvimento de queries.

É isso.