Em abril de 2013 eu respondi a um pergunta no LinkedIn: como iniciar uma carreira em BI? A pessoa também pedia dicas de livros para se informar sobre o assunto. Eu respondi e minha resposta se tornou a base desta página, que indica uma lista de livros, separados por assunto, para quem quiser ler seu caminho em BI. Bom divertimento!

Graduação

Leia BI For Dummies (em inglês.) Apesar do nome, é o livro sobre BI mais sofisticado e profundo que eu já vi, e ele usa uma linguagem popular, com muitas referências culturais que ajudam a te ligar ao assunto (meu favorito é o OLAP vs. Star Trek.)

Pós-Graduação

Separei por áreas mais ou menos principais.

Data Warehouse

É uma área enorme, na qual você pode trabalhar a vida toda sem nunca saber o que acontece na mesa do usuário. Existem várias referências boas, mas _definitivamente_ comece pelo livro Data Warehouse Toolkit, do Ralph Kimball. A primeira edição foi publicada em português, e vale a pena – procure em sebos. A Amazon.com vende a segunda edição (eu comprei a versão Kindle, e ela está muito boa), que também vale muito a pena – leia as duas edições, se puder. Você vai entender como a coisa nasceu e era entendida, e como ela evoluiu até chegar no que estamos hoje. Existe muita coisa de outros autores, mas a qualidade é misturada. Em particular, o Bill Inmon não tem nenhuma metodologia específica, e propõe a 3NF (terceira forma normal), que na verdade é explicada em livros de outra área (modelagem E-R). Para se aprofundar em Modelagem Dimensional (que é a melhor para o cliente final), invista nos livros Star Schema (Christopher Adamson), e no Data Warehouse Design Solutions (Michael Venerable) para entender como certos problemas, em diversas indústrias, são resolvidos (eu gosto muito deste livro.)

EDW

O Enterprise DW é um conceito natural, mas suscita muita discussão. Hoje em dia está nascendo um consenso de que Modelagem Dimensional não atende essa necessidade a contento, e a metodologia de modelagem de dados mais adequada é a Data Vault (ou Achor Modeling, 6NF, etc. – mas isso ainda está muuuito em aberto.) Para conhecer DV, leia Super Charge your Data Warehouse, de Dan Linstedt (também existe na Amazon.com e eu comprei o Kindle dele – útil e prático, ainda que num inglês sofrível.)

ETL

Um sub-assunto de DW, muito bem coberto pela literatura. O livro-texto é o ETL Toolkit, também do Kimball. Partindo daí, você tem livros técnicos sobre ferramentas. Como eu sou um cara de Pentaho, o meu livro de ETL com Pentaho é o Kettle Solutions. Tem na Amazon.

Gestão de Projetos de DW

Leia o DW Lifecycle Toolkit, Ralph Kimball. Todos os outros livros de gestão de projeto de DW empalidecem perto deste catatau de centenas de páginas. É muito detalhado, uma bíblia que é difícil dizer que não é completa.

Banco de Dados

Um ponto técnico do mundo de DW, mas muito importante, o tipo de banco a ser usado afeta diretamente a qualidade do DW – performance, manutenção, capacidade etc. Eu não conheço nenhum livro sobre este assunto, então minha dica é busque os panfletos de tudo que prometer melhorias para DW. Existem dois tipos básicos: tabular (o comum) e colunar (mais adequado a DW.) Busque ler sobre isso.

Exploração de dados

Não existe nenhum bom livro que discuta as forma que o usuário dispõe para explorar os dados de um DW (não existe BI sem DW, a propósito.) Basicamente existe OLAP, relatórios a priori, relatórios ad hoc e painéis. Livros interessantes nessa área são: Now You See It, sobre visualização de dados, Show Me the Numbers: Designing Tables and Graphs to Enlighten (o título diz tudo) e Information Dashboard Design: The Effective Visual Communication of Data. Todos eles são do Stephen Few, que é o cara em visualização de dados.

Garimpagem de Dados

Normalmente conhecida como Data Mining, erroneamente traduzida no Brasil para Mineração de Dados (o brasileiro pensa em mineração como um buraco aberto no chão, de onde saem toneladas de minério bruto), outro mundo dentro do mundo que é BI. Como DW, é interminável e fundamental para inteligência de negócios em grandes empresas. Leia Freakonomics para entender como estatística e modelagem matemática abrem uma janela de compreensão sobre a realidade (o exemplo de painel na análise da relação livros-estudantes de sucesso é, na minha opinião, a definição mais clara e concisa de Data Mining que eu já vi – e olha que eu vendia SAS…) Depois dele, leia Data Mining Techniques, de Gordon Linoff e Michael Berry. Daí você pode passar para alguma ferramenta: SAS, SPSS, R, Statistica, JMP, Weka…

Painéis

Já tratado em exploração de dados.

Automação/Integração de BI

É inexistente. O Pentaho Solutions fala um pouco sobre isso quando explica sobre as XActions do Pentaho.

Livros Pentaho

Eis a minha lista de Pentaho até o momento (4/4/13):

  1. Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL
  2. Pentaho Kettle Solutions: Building Open Source ETL Solutions with Pentaho Data Integration
  3. Pentaho 3.2 Data Integration: Beginner’s Guide
  4. Pentaho Reporting 3.5 for Java Developers
  5. Pentaho Data Integration 4 CookBook
  6. Data Mining Practical Machine Learning Tools and Techniques

Todos existem em versão impressa e Kindle. Eu só não li o último, do Weka. Todos são ótimos e excelentes fontes de informação.

Mas, Afinal, Como Iniciar uma Carreira em BI?

Se você quiser mesmo entrar nesse ramo, o ideal é escolher uma área e uma ferramenta e investir nela – faça cursos, monte pilotos com dados públicos, dê um projeto de graça para uma empresa e use de caso etc.

Eu gosto do e uso o Pentaho na empresa em que trabalho – o Serpro. Mas existe uma infinidade de opções, desde da MS até QlikView, passando por Oracle, SAP, SAS, IBM etc. Apenas lembre-se que ferramenta, no fundo, não faz diferença. O que faz a diferença é gerar valor com BI.

4 comentários sobre “Sugestões de Livros sobre BI e DW

  1. Olá, Fábio,

    Me chamo Ricardo e sou Analista de Sistemas.
    Conheci o seu blog porque pesquisei por literatura sobre o Pentaho / Data Integration, etc. Gostaria de sua opinião e ajuda. Tenho visto alguns livros sobre o Pentaho na Amazon e vi comentários que falam que os livros já estão muito para trás porque a ferramenta pentaho evolui rapidamente. Gostaria que você me orientasse um pouco sobre quais livros seria importante adquirir para iniciar no desenvolvimento de soluções com esta tecnologia. Já conheço a ferramenta Pentaho do ponto de vista de usuário, pois na empresa que trabalho usamos Pentaho Enterprise.

    Parabéns pelo blog!
    Desde já agradeço pela atenção,
    Ricardo Dias

    1. Obrigado pela visita, Ricardo! Fico feliz em saber que ajudo. ;-)

      Falando em termos de plataforma, que é patenteada, nunca mudou. O entorno dela, a “casca”, por outro lado, mudou bastante, em especial no BA Server.

      Resumidamente, podemos pensar assim: tanto o Pentaho na Prática (PnP) quanto o Pentaho Solutions (PS) podem ser reaproveitados para Report Designer, PDI/Kettle e Schema Workbench. Nestes houve mudanças cosméticas na maior parte (PDI e PRD, não PSW) e algumas mudanças na forma de operar (como as conexões do PRD e os logs do PDI – mas praticamente nada no PSW.) O Pentaho Aggregation Designer, por estar mais alinhado ao PSW que ao servidor, continua praticamente a mesma coisa – e a parte do meu livro trata dele continua 100% válida.

      A parte de servidor de ambos perdeu bastante com a mudança da série 4 para a série 5. Até a versão 4.8, o servidor era uma demonstração de como usar a plataforma para construir soluções com Pentaho. Tudo começou na 1.0, que era literalmente uma demo. Como fez sucesso, muito sucesso, ganhou uma cara nova na 2.0 e cresceu incremetalmente na 3 (plugins) e na 4, que foi mais um trabalho de polimento que outra coisa. A versão 5 foi reescrita do zero e por isso mudou quase tudo e o máximo que se aproveita é o uso básico (acesso, pastas, agendamento) e o conceito de usuários. Ainda que a administração de usuários continue igual, agora ela tem uma interface integrada ao servidor – antes era separado.

      Além disso, o Pentaho Kettle Solutions é o melhor livro para PDI. O único senão é que ele saiu durante um período de retrabalho intenso do PDI, o que o leva a ter vários trechos como “nas próximas versões será diferente” ou “funciona assim hoje, mas não temos certeza se vai continuar ou não” etc. Mas é um livro que vale muito a pena, não tenha dúvidas! Especialmente pela parte de Data Vault, que ainda hoje é mais prática que os outros livros de DV.

      Beleza? Era isso? Ficou alguma outra questão em aberto?

      Ah, é, tem ainda o Pentaho Design Studio, que não mudou nada, e o Weka, que é independente. No máximo os exemplos não vão funcionar, mas a lógica continua a mesma.

      Agora sim, fechou. Acho. Me diz aí. :-)

  2. Olá Fabio! Sou veterinária, atuei por mais de 10 anos na área financeira em uma empresa do agronegócio com grande perspectiva de crescimento e recentemente recebi um desafio de montar um sistema de BI aqui, além de ajudar a mudar a cultura da empresa para se tornar mais analítica e tomar mais decisões baseadas em dados. Estou bem empolgada com o desafio, pois acho esse mundo de BI encantador, mas a minha dúvida tem sido por onde uma pessoa apaixonada por dados mas com formação completamente oposta (como meu caso) poderia começar??? A propósito, adorei seu blog!

    1. Começando pelo fim, muito obrigado pela visita. Fico feliz em saber que apreciou. :-)

      Agora, ao que interessa.

      A resposta curta: pelo início, obviamente. Pelo que é mais importante. ;-)

      A resposta longa: tudo que uma empresa faz é (ou deveria ser) voltado à aumentar sua lucratividade. No longo prazo, isso significa se manter viva. No curto prazo, mudar alguma coisa, aumentar sua lucratividade e mover-se para o próxima coisa a ser mudada.

      Se você leu o bastante do meu blog, talvez tenha encontrado o post Analítico ou Operacional. O ponto daquele artigo é expor o fato de que nem todas as necessidades de dados que uma empresa possui podem (ou devem) ser resolvidos com Inteligência de Negócios. É importante saber qual problema vai ser resolvido, para então, e só então, decidir como tentar resolvê-lo.

      Mas a coisa fica pior: mesmo que você consiga dizer qual tipo de solução você quer dar ao seu problema (OI ou BI), resta o fato empírico de que frequentemente existe mais de uma solução. E raramente temos informação o suficiente para decidir qual solução escolher.

      No final das contas, não existe resposta certa para nenhum problema (ainda que hajam muitas erradas), nem alguém que vá avaliar seu resultado e dizer se você acertou ou errou. Só os resultados, apenas os resultados, é que vão dizer se a sua escolha funcionou ou não. Nem mesmo os resultados, porém, vão dizer se era a melhor escolha, apenas que funcionou.

      Eu não estou fazendo nenhuma revelação do antigo segredo dos analistas de BI, nem inventando algo novo. Tudo isso é largamente conhecido é, até certo ponto, óbvio, se você parar para pensar um pouco.

      Então, se o que interessa é o resultado ser valioso para a empresa, você precisa começar com o que vai ser mais valioso. É irrelevante se você vai construir um modelo de dados, adotar uma tecnologia ou implementar um processo ou fazer qualquer outra coisa. O que é relevante, a única coisa relevante, é criar valor, resolver um problema, aumentar a lucratividade da empresa.

      Logo, comece pelo início: o que é o mais importante para sua empresa? Qual problema, se resolvido, vai gerar o maior retorno (financeiro ou estratégico), no menor tempo?

      Lamento se isso te decepcionou, se você esperava algum conselho do tipo leia este livro ou faça aquele curso. Anos testemunhando projeto após projeto se desenvolver, eu estaria te enganando se dissesse que o importante é a tecnologia, ou a metodologia ou o processo ou qualquer coisa. Esses elementos são importantes, cruciais até! Se errar com eles, o projeto pode fracassar, da mesma forma que uma excelente receita de bolo dá errado se você errar passos críticos. Mas acertar os passos de uma receita ruim vai produzir um resultado perfeitamente ruim.

      Vamos para a parte legal. :-)

      A forma mais prática e resiliente de descobrir o que é mais importante, e como executar, e até mesmo lidar com os fracassos e falhas, é adotar um método Ágil. Eu sou fã do Scrum: criar um backlog de necessidades, priorizar e meter o pé na estrada. Iterar, lavar e repetir. Para sempre, até o ponto em que uma sprint, mesmo de uma semana, é muito tempo, seu backlog some e você pode/deve/precisa chavear para Kanban.

      Cada decisão técnica possui custos e consequências. A relação de custo-benefício varia em função do risco que você quer tomar, do esforço que você quer realizar e de quanto no futuro você quer olhar.

      Se você quer reduzir o risco e olhar para o futuro mais longínquo, adote uma Corporate Information Factory baseada em Data Vault. Ela dá mais trabalho para começar e tem um ciclo de vida inicial mais esticado, mas esse investimento retorna como uma queda do trabalho ao longo do tempo (i.e. um contínuo aumento de produtividade) e na reducação de riscos de todo tipo (implementação, falhas, interpretação da necessidade do cliente etc. etc. etc.)

      Por outro lado, se você precisa dar resultados tipo, até amanhã, vá de XGH (olhe aqui: http://sou.gohorseprocess.com.br/extreme-go-horse-xgh/) com um Data Mart e uma ferramenta de apresentação de dados.

      O XGH é brincadeira!! :-D

      Apesar de oferecer resultados rápidos, esta estratégia aumenta os riscos (porque multiplica os pontos de falha) e diminui o horizonte do seu projeto (porque cria débito técnico.) Não é uma estratégia ruim, se você precisa obter um sucesso “quick and dirt” para demonstrar a viabilidade do projeto de BI, ou se quiser conduzir uma prova de conceito, uma análise exploratória do ambiente e do contexto e assim por diante. Mas, uma vez adquirido conhecimento suficiente, você precisa chavear para um formato mais sustentável, como o modelo CIF + DV, e reiniciar o projeto. Pode até refatorar o piloto, mas não pode preservá-lo, reaproveitá-lo sem atualizá-lo.

      Daí é vida normal.

      Bom, é isso. Para fazer uma lista:

      * Aprenda Scrum;
      * Construa um backlog;
      * Decida a estratégia;
      * Construa um projeto de sucesso.

      Tecnicamente falando, todas as ferramentas e produtos servem de alguma forma, todas as tecnologias podem ser usadas (exceto Data Lake!) Cada uma tem algum livro seminal, algum filósofo central, basta procurar no Google. Ou se quiser passar por aqui de novo, fique à vontade. Será um prazer ajudar. ;-)

      Era isso? Respondi sua pergunta?

Deixe uma resposta para Fábio de Salles Cancelar resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s