Para quem está em busca de novos desafios ou mesmo em constante renovação na área de BI, divulgamos abaixo a seguinte oportunidade:
Grande Empresa no segmento de Óleo & Gás busca no mercado: Analista de BI Sênior
Pré-requisitos:
- Graduação em Computação, Engenharia, Administração e áreas afins;
- Inglês Intermediário.
Experiência em:
- Modelagem banco de dados relacional – MS–SQL Server , processos de ETL (MS-SSIS);
- Elaboração de Transact-SQL (Views e Stored Procedures);
- Oracle Hyperion: Essbase, Planning, Excel Addin, Web Analysis;
- Arquitetura de ambiente BI, modelagem de negócios.
Atividades Principais:
- Desenvolvimento de sistemas de informação gerencial – Business Intelligence utilizando ferramentas Oracle Hyperion.
- Análise de requisitos do negócio, especificação do negócio, especificação técnica, modelagem relacional e multidimensional.
- Análise de informações para apoiar áreas do negócio.
- Documentação técnica e do negócio.
Desejável:
- Experiência em BI (entre 1,5 ano a 2 anos)
- Qlikview;
- Excel Macro e VBA.
Local de trabalho: Centro/Rio de Janeiro.
Aqueles que estiverem insteressados nesta oportunidade, por favor, enviem CV para: bi.vagas@gmail.com
quarta-feira, 13 de julho de 2011
terça-feira, 25 de janeiro de 2011
(T) Como indexar uma tabela Fato - (Best Practice)
A base de qualquer projeto de bi é ter um bom dw/data mart. Podemos falar em modelagem star-schema durante dias, sem falar nas variações do snowflake, mas o objetivo principal deste artigo é apontar algumas negligências que tenho percebido no tratamento da tabela fato. Tabela esta que é o principal pilar da casa que reside um modelo star-schema.
Ouço muitas vezes os clientes reclamando do desempenho das consultas enviadas contra o seu dw/data mart, ou do tempo de resposta das análises solicitadas ao bi. Isto é realmente inaceitável, não só numa perspectiva de implantação do projeto, mas também de desempenho da entrega das informações.
Como eu mencionei anteriormente o meu objetivo neste artigo, é alertar sobre a importância da indexação da tabela fato: o que deveria ser, porque é necessário, porque chaves compostas são boas e más, e porque você deveria se preocupar com isso.
Então, vejamos:
|a| Indexação padrão (default):
De forma rápida, todas as colunas de chave estrangeira (FK) devem ter um índice não-agrupado e não-exclusivo.
|b| E o que isso significa?
Isso significa que uma referência de chave estrangeira (FK) em uma coluna de uma tabela contendo a referência de chave primária (PK) apenas fornece ao mecanismo de banco de dados um ponto de referência para a sua tabela dimensão. Ele não faz nada para saber como os dados na tabela fato é organizada. Então, depois de criar uma chave estrangeira (FK) não se esqueça de criar o índice não-agrupado e não-exclusivo também.
|c| Por que a indexação da tabela fato é necessária?
Eu irei abordar este assunto aqui de forma sucinta. Mas, antes é preciso lembrar que você também é capaz de aplicar à FK, constraints. E que esta é uma das principais razões para se utilizar uma FK. Uma constraint basicamente diz ao banco de dados que um valor passado para a coluna FK da tabela fato, deve existir na própria tabela. Isto pode naturalmente ser desligado definindo o atributo apropriado da FK da tabela fato, mas é melhor deixar ativo. É bom ressaltar que até este ponto, isto nada tem a ver com o desempenho, e sim com a integridade dos dados que é realmente muito importante em um dw/data mart. No entanto, quando você começa a combinar indexação de cada coluna FK da tabela fato, na verdade você está iniciando um link entre a camada lógica e o mecanismo de sorting do banco de dados. Ao fazer isso, estamos evitando que uma consulta enviada ao banco de dados, faça uma varredura completa da tabela para recuperar a informação solicitada sem um índice apropriado. Ao passo que, se a tabela está indexada, essa mesma consulta ao invés de fazer uma varredura completa da tabela fato para recuperar n linhas, agora possui um outro caminho para buscar estas mesmas informações de forma mais rápida.
|d| Os índices compostos são bons ou ruins?
Quando eu comecei a aprender sobre indexação de uma tabela eu ainda era um programador em Visual Basic. Naquela época, eu sabia o que cada consulta ia enviar/solicitar ao banco de dados. Por exemplo, se tivesse que construir um relatório de vendas por produto, sabia que a cláusula 'WHERE' do meu 'SELECT' para exibir o resultado da solicitação era bastante simples e sempre estava filtrada em 'category_id' e algumas outras colunas. Para otimizar o tempo de resposta desta consulta, criaria um índice composto sobre as colunas que fazem parte da pesquisa/critérios da consulta. Isso funciona muito bem para um sistema operacional como este descrito acima, mas não é uma boa prática para um sistema business intelligence (BI). Uma das principais demandas de um projeto BI são os relatórios "ad-hoc", o que significa que os usuários finais irão criar uma infinidade de consultas, cortar e fatiar os dados (slice and dice) independentemente da forma como os dados se apresentam, tudo para obter a melhor resposta a sua análise. Além da dificuldade de definir com antecedência como será o índice composto, acrescento a possibilidade da sua tabela fato sofrer um 'overhead'. A maior dificuldade, estaria mesmo, em estabelecer o número de combinações e a quantidade de índices compostos que você teria para dar conta ou tentar usar em sua tabela fato.
Desta forma podemos observar que, naturalmente, o melhor lugar para se aplicar índices compostos é em um sistema OLTP. Eu não vou entrar aqui em maiores detalhes, mas processos de ETL de um sistema BI para a tabela fato pode ter uma baixa performance durante uma extração/carga devido aos índices compostos.
Em última análise, os índices compostos em tabela fato são ruins para os sistemas BI.
|e| Por que você deve se importar?
Em primeiro lugar você deve estar ciente de que existem diferentes aplicações com lógica de sistemas diferentes. E com BI isso não é diferente, ou seja, devemos sempre entender que o que funciona em uma situação pode não funcionar em outra.
Segundo, se você está criando uma nova solução para a sua empresa/cliente, você vai querer dar a melhor solução possível. Um dos itens mais negligenciados pelos arquitetos de solução (a menos que você tenha sido um DBA em sua vida passada) é a indexação, após descobrirem que o desempenho não é o que eles acreditam que deveria ser. A boa notícia é que sempre há espaço para a melhoria destas estruturas existentes. Para isso, dê uma olhada em sua saída de dados - será que é possível converter índices compostos em índices da coluna FK? Eu vejo isso todo o tempo, a tabela possui um índice composto por 'product_id', 'territory_id' e 'date_id'. E, quando é realizado uma análise mais aprofundada percebe-se que não há um índice somente para a coluna 'date_id', por exemplo. Também não podemos esquecer que existem no mercado hoje diversos tipos de motores OLAP. Se você estiver usando um motor OLAP como o do Oracle Essbase, e dependendo do desenho da sua solução (BSO), esta preocupação em indexar a tabela fato para obter o máximo de desempenho no acesso e na entrega das informações solicitadas deixa de existir e então todos os seus esforços passam a estar voltados para o tamanho do bloco de armazenamento, as agregações, e o cache da aplicação. No entanto, em um OLAP como o Oracle BI (OBIEE) ou SAP BW ou ainda MicroStrategy, a estrutura relacional é parte fundamental da solução, uma vez que esses sistemas funcionam como uma re-edição da consulta SQL enviada ao banco de dados para uma recuperação de dados do tipo OLAP.
Conclusão
Eu estava esperando para obter um exemplo através de um plano de execução realizado em cima de uma tabela para mostrar visualmente as estatísticas, mas isso não será possível e eu posso publicar isto em um outro artigo em uma outra data. Eu sei que com o que foi apresentado hoje neste artigo, muitas discussões podem surgir e no entanto, este é apenas um exercício para a frente que você pode fazer sozinho, se necessário. Mais uma vez, a idéia por trás deste artigo era apenas compartilhar uma preocupação minha com algo que continuo a deparar (nas empresas, nos projetos e clientes) e que é facilmente solucionado com algum esforço inicial e compreensão.
Basta lembrar que você precisa tanto de integridade nos dados (FK) quanto de desempenho nas consultas (índices). E para obter sucesso com o dw/data mart você precisa manter este equilíbrio e neste jogo você é a peça fundamental para fazer isto.
Se sua opinião é diferente, eu gostaria de saber o que você tem a dizer, me envie a sua opinião.
Um grande abraço a todos,
Ouço muitas vezes os clientes reclamando do desempenho das consultas enviadas contra o seu dw/data mart, ou do tempo de resposta das análises solicitadas ao bi. Isto é realmente inaceitável, não só numa perspectiva de implantação do projeto, mas também de desempenho da entrega das informações.
Como eu mencionei anteriormente o meu objetivo neste artigo, é alertar sobre a importância da indexação da tabela fato: o que deveria ser, porque é necessário, porque chaves compostas são boas e más, e porque você deveria se preocupar com isso.
Então, vejamos:
|a| Indexação padrão (default):
De forma rápida, todas as colunas de chave estrangeira (FK) devem ter um índice não-agrupado e não-exclusivo.
|b| E o que isso significa?
Isso significa que uma referência de chave estrangeira (FK) em uma coluna de uma tabela contendo a referência de chave primária (PK) apenas fornece ao mecanismo de banco de dados um ponto de referência para a sua tabela dimensão. Ele não faz nada para saber como os dados na tabela fato é organizada. Então, depois de criar uma chave estrangeira (FK) não se esqueça de criar o índice não-agrupado e não-exclusivo também.
|c| Por que a indexação da tabela fato é necessária?
Eu irei abordar este assunto aqui de forma sucinta. Mas, antes é preciso lembrar que você também é capaz de aplicar à FK, constraints. E que esta é uma das principais razões para se utilizar uma FK. Uma constraint basicamente diz ao banco de dados que um valor passado para a coluna FK da tabela fato, deve existir na própria tabela. Isto pode naturalmente ser desligado definindo o atributo apropriado da FK da tabela fato, mas é melhor deixar ativo. É bom ressaltar que até este ponto, isto nada tem a ver com o desempenho, e sim com a integridade dos dados que é realmente muito importante em um dw/data mart. No entanto, quando você começa a combinar indexação de cada coluna FK da tabela fato, na verdade você está iniciando um link entre a camada lógica e o mecanismo de sorting do banco de dados. Ao fazer isso, estamos evitando que uma consulta enviada ao banco de dados, faça uma varredura completa da tabela para recuperar a informação solicitada sem um índice apropriado. Ao passo que, se a tabela está indexada, essa mesma consulta ao invés de fazer uma varredura completa da tabela fato para recuperar n linhas, agora possui um outro caminho para buscar estas mesmas informações de forma mais rápida.
|d| Os índices compostos são bons ou ruins?
Quando eu comecei a aprender sobre indexação de uma tabela eu ainda era um programador em Visual Basic. Naquela época, eu sabia o que cada consulta ia enviar/solicitar ao banco de dados. Por exemplo, se tivesse que construir um relatório de vendas por produto, sabia que a cláusula 'WHERE' do meu 'SELECT' para exibir o resultado da solicitação era bastante simples e sempre estava filtrada em 'category_id' e algumas outras colunas. Para otimizar o tempo de resposta desta consulta, criaria um índice composto sobre as colunas que fazem parte da pesquisa/critérios da consulta. Isso funciona muito bem para um sistema operacional como este descrito acima, mas não é uma boa prática para um sistema business intelligence (BI). Uma das principais demandas de um projeto BI são os relatórios "ad-hoc", o que significa que os usuários finais irão criar uma infinidade de consultas, cortar e fatiar os dados (slice and dice) independentemente da forma como os dados se apresentam, tudo para obter a melhor resposta a sua análise. Além da dificuldade de definir com antecedência como será o índice composto, acrescento a possibilidade da sua tabela fato sofrer um 'overhead'. A maior dificuldade, estaria mesmo, em estabelecer o número de combinações e a quantidade de índices compostos que você teria para dar conta ou tentar usar em sua tabela fato.
Desta forma podemos observar que, naturalmente, o melhor lugar para se aplicar índices compostos é em um sistema OLTP. Eu não vou entrar aqui em maiores detalhes, mas processos de ETL de um sistema BI para a tabela fato pode ter uma baixa performance durante uma extração/carga devido aos índices compostos.
Em última análise, os índices compostos em tabela fato são ruins para os sistemas BI.
|e| Por que você deve se importar?
Em primeiro lugar você deve estar ciente de que existem diferentes aplicações com lógica de sistemas diferentes. E com BI isso não é diferente, ou seja, devemos sempre entender que o que funciona em uma situação pode não funcionar em outra.
Segundo, se você está criando uma nova solução para a sua empresa/cliente, você vai querer dar a melhor solução possível. Um dos itens mais negligenciados pelos arquitetos de solução (a menos que você tenha sido um DBA em sua vida passada) é a indexação, após descobrirem que o desempenho não é o que eles acreditam que deveria ser. A boa notícia é que sempre há espaço para a melhoria destas estruturas existentes. Para isso, dê uma olhada em sua saída de dados - será que é possível converter índices compostos em índices da coluna FK? Eu vejo isso todo o tempo, a tabela possui um índice composto por 'product_id', 'territory_id' e 'date_id'. E, quando é realizado uma análise mais aprofundada percebe-se que não há um índice somente para a coluna 'date_id', por exemplo. Também não podemos esquecer que existem no mercado hoje diversos tipos de motores OLAP. Se você estiver usando um motor OLAP como o do Oracle Essbase, e dependendo do desenho da sua solução (BSO), esta preocupação em indexar a tabela fato para obter o máximo de desempenho no acesso e na entrega das informações solicitadas deixa de existir e então todos os seus esforços passam a estar voltados para o tamanho do bloco de armazenamento, as agregações, e o cache da aplicação. No entanto, em um OLAP como o Oracle BI (OBIEE) ou SAP BW ou ainda MicroStrategy, a estrutura relacional é parte fundamental da solução, uma vez que esses sistemas funcionam como uma re-edição da consulta SQL enviada ao banco de dados para uma recuperação de dados do tipo OLAP.
Conclusão
Eu estava esperando para obter um exemplo através de um plano de execução realizado em cima de uma tabela para mostrar visualmente as estatísticas, mas isso não será possível e eu posso publicar isto em um outro artigo em uma outra data. Eu sei que com o que foi apresentado hoje neste artigo, muitas discussões podem surgir e no entanto, este é apenas um exercício para a frente que você pode fazer sozinho, se necessário. Mais uma vez, a idéia por trás deste artigo era apenas compartilhar uma preocupação minha com algo que continuo a deparar (nas empresas, nos projetos e clientes) e que é facilmente solucionado com algum esforço inicial e compreensão.
Basta lembrar que você precisa tanto de integridade nos dados (FK) quanto de desempenho nas consultas (índices). E para obter sucesso com o dw/data mart você precisa manter este equilíbrio e neste jogo você é a peça fundamental para fazer isto.
Se sua opinião é diferente, eu gostaria de saber o que você tem a dizer, me envie a sua opinião.
Um grande abraço a todos,
domingo, 17 de outubro de 2010
(E) Como transformar a informação e a tecnologia da informação em fatores de crescimento e de alto desempenho nas organizações
De vez em quando sou questionado por profissionais e alunos: como transformar a informação e a tecnologia da informação em fatores de crescimento e de alto desempenho nas organizações?
E sempre me encontro em uma situação delicada para responder a este questionamento, porque é um assunto complexo, não dá para ser resumido em uma única linha. A sua complexidade é devido ao fato que atualmente a tecnologia aplicada com sucesso, pode ser vista por muitos como inovação. Mas nem sempre a tecnologia é garantia de sucesso para muitas organizações. É preciso ir além, é preciso integrar processos, pessoas, e principalmente entregar informação na hora certa.
A informação já é considerada o principal insumo e, em muitos casos, o principal produto das organizações. Quando bem gerenciada, ela se transforma em recurso estratégico: é fator de crescimento de lucros, de redução de custos operacionais, de otimização do processo decisório, de solução de problemas e de eliminação de barreiras de comunicação, entre outros benefícios trazidos para o desempenho organizacional. Com o aumento da complexidade e do dinamismo das organizações, estas passaram a depender de mecanismos mais eficazes de administração da informação, a fim de reduzir o quadro de incerteza em que suas decisões são tomadas e de melhorar o relacionamento com parceiros, clientes, fornecedores e agentes reguladores.
Gerenciar adequademente os recursos informacionais e seus fluxos na organização representa, hoje, uma necessidade cada vez maior em qualquer tipo de negócio. Para serem eficazes, as organizações precisam ter seus processos decisórios e operacionais alimentados com informações de qualidade, obtidas dentro de uma boa relação de custo-benefício e principalmente, conforme as necessidades do negócio. A simples ação de tornar as informações prontamente disponíveis para os vários colaboradores da empresa, pode melhorar de forma significativa os resultados por ela a serem obtidas. Algumas dezenas de vezes por dia, colaboradores dos mais diversos níveis hierárquicos, dentro da organização precisam resolver problemas, tomar decisões, controlar processos, compartilhar informações e relacionar-se com outras pessoas, e em todas essas situações o desempenho pode ser aperfeiçoado caso as informações apropriadas estejam presentes no momento oportuno. Compreender as formas pelas quais se pode otimizar o uso dos recursos informacionais e de TI representa, hoje, um aspecto fundamental para a melhoria do desempenho de qualquer organização.
Por esta razão, resolvi aproveitar este canal de comunicação para compartilhar com todos vocês, conceitos e ideias para melhorar a gestão da informação nas organizações, desta forma, ajudar na transformação da informação e da tecnologia da informação de mero recurso operacional em ativo estratégico para o negócio.
Estarei divulgando, em primeira mão, nas próximas semanas, uma série de publicações, que fazem parte do meu próximo livro (ainda sem título), sobre business intelligence e gestão da informação. Acompanhe aqui, o que eu denominei de: Série Gestão Estratégica da Informação.
Um grande abraço a todos!
E sempre me encontro em uma situação delicada para responder a este questionamento, porque é um assunto complexo, não dá para ser resumido em uma única linha. A sua complexidade é devido ao fato que atualmente a tecnologia aplicada com sucesso, pode ser vista por muitos como inovação. Mas nem sempre a tecnologia é garantia de sucesso para muitas organizações. É preciso ir além, é preciso integrar processos, pessoas, e principalmente entregar informação na hora certa.
A informação já é considerada o principal insumo e, em muitos casos, o principal produto das organizações. Quando bem gerenciada, ela se transforma em recurso estratégico: é fator de crescimento de lucros, de redução de custos operacionais, de otimização do processo decisório, de solução de problemas e de eliminação de barreiras de comunicação, entre outros benefícios trazidos para o desempenho organizacional. Com o aumento da complexidade e do dinamismo das organizações, estas passaram a depender de mecanismos mais eficazes de administração da informação, a fim de reduzir o quadro de incerteza em que suas decisões são tomadas e de melhorar o relacionamento com parceiros, clientes, fornecedores e agentes reguladores.
Gerenciar adequademente os recursos informacionais e seus fluxos na organização representa, hoje, uma necessidade cada vez maior em qualquer tipo de negócio. Para serem eficazes, as organizações precisam ter seus processos decisórios e operacionais alimentados com informações de qualidade, obtidas dentro de uma boa relação de custo-benefício e principalmente, conforme as necessidades do negócio. A simples ação de tornar as informações prontamente disponíveis para os vários colaboradores da empresa, pode melhorar de forma significativa os resultados por ela a serem obtidas. Algumas dezenas de vezes por dia, colaboradores dos mais diversos níveis hierárquicos, dentro da organização precisam resolver problemas, tomar decisões, controlar processos, compartilhar informações e relacionar-se com outras pessoas, e em todas essas situações o desempenho pode ser aperfeiçoado caso as informações apropriadas estejam presentes no momento oportuno. Compreender as formas pelas quais se pode otimizar o uso dos recursos informacionais e de TI representa, hoje, um aspecto fundamental para a melhoria do desempenho de qualquer organização.
Por esta razão, resolvi aproveitar este canal de comunicação para compartilhar com todos vocês, conceitos e ideias para melhorar a gestão da informação nas organizações, desta forma, ajudar na transformação da informação e da tecnologia da informação de mero recurso operacional em ativo estratégico para o negócio.
Estarei divulgando, em primeira mão, nas próximas semanas, uma série de publicações, que fazem parte do meu próximo livro (ainda sem título), sobre business intelligence e gestão da informação. Acompanhe aqui, o que eu denominei de: Série Gestão Estratégica da Informação.
Um grande abraço a todos!
Assinar:
Postagens (Atom)
