13 Replies Latest reply: Jun 17, 2016 3:17 PM by Fernando Suzuki RSS

    DW - Boas Práticas ETL

    Regiane Paulo

      Boa noite,

       

       

      Sou iniciante no Qlik e gostaria de saber se estou no caminho certo.

      Tenho um banco de dados relacional e o objetivo é criar um DW no QlikView, li os prós e contras sobre essa questão e acredito ser uma boa prática, me corrijam se eu estiver errada =)

      Separei meu projeto em 3 QVW:

      Extração - Carrego todas as tabelas que preciso, gerando um QVD para cada uma, em seguida apago todas as tabelas do QVW.

      Transformação - Carrego os QVDs que gerei na Extração e faço os tratamentos.

      Carga - Carrego os QVDs da transformação e desenvolvo minha aplicação.

       

       

      Gostaria de dicas, essa é a melhor prática?

       

       

      Desde já, agradeço a todos.

      Muito Obrigada.

        • Re: DW - Boas Práticas ETL
          Luciano Vasconcelos

          Bom dia.

          Sou um pouco radical nesta questão e diria que DW no Qlikview não existe.

          Se puder modele e faça em um banco de dados para que possa ser acessado de diversas formas.

          Quanto ao tratamento de dados está correto.

          Dependendo dos seus dados você pode em cada etapa criar um qvw para as dimensões e um para cada fato sem precisar apagar.

          As tabelas não deverão gerar relacionamentos nas etapas de Extração e Transformação para você poder ajudar você na validação dos dados.

            • Re: DW - Boas Práticas ETL
              Fábio Nakashigue

              Luciano,

               

              Sobre a parte de relacionamentos nas etapas de Extração e Transformação, acredito que não seja ruim você relacionar as tabelas. Afinal você está montando sua estrutura para evitar mudanças na aplicação final. E caso precise validar uma informação é mais simples utilizar um qualify no qvd ou criar rapidamente um qvw de teste.

               

              Abs.

              Fabio Nakashigue

              • Re: DW - Boas Práticas ETL
                Regiane Paulo

                Muito obrigada Luciano.

                Deixa eu ver se entendi, em cada fase eu faria um qvw para dimensões e um para cada fato, isso dependendo dos meus dados, quais fatores devo levar em conta para definir esse processo, pode citar um exemplo?

                Gero as tabelas sem relacionamentos, somente na carga (última fase) eu crio as ligações? Isso torna o processo mais rápido?Não entendi muito bem a utilidade.

                • Re: DW - Boas Práticas ETL
                  Regiane Paulo

                  Em relação ao DW, sempre fui a favor de criar em um Banco de Dados, mas aqui querem deixar tudo no Qlik =-(, não sei até que ponto é viável, então segui nesse modelo de separação (ELT) para gerar as tabelas desnormalizadas e trabalhar com os dados.

                   

                  Muito obrigada pela Ajuda.

                • Re: DW - Boas Práticas ETL
                  Mário Rodrigo Campestrini

                  Bom dia Isabela

                   

                  O procedimento que adotamos aqui na empresa segue abaixo:

                   

                  1. Extração e transformação dos dados: os processos de extração e transformação (inicial) são agrupados em um único aplicativo, criando um QVW para cada tabela do banco de dados. Nesse passo, lemos a tabela do banco de dados e gravamos em QVD, aplicando tratamentos (campos nulo, remoção de espaços, maiúsculas/minúsculas, mapping de valores, criação de campos para exibição - código + nome -, etc.). Com isso, temos os arquivos QVD prontos para utilização nas aplicações.
                  2. Transformação (avançada): em alguns casos temos um novo QVW (para cada caso) que lê as informações transformadas dos QVDs e as agrupa em um novo QVD. Isso é feito para dados que são utilizados em vários aplicativos e são oriundos de diversas tabelas.
                  3. Aplicativo: os aplicativos leem diretamente dos arquivos QVD e fazem a menor transformação possível para a carga dos aplicativos. Essa definição sobre o que é transformado na aplicação e o que não é depende de avaliação sobre o melhor local a fazer essa transformação.

                   

                  Conforme o lucianosv mencionou, cada campo das tabelas geradas tem nome específico para não gerar relacionamentos automáticos na carga.

                   

                  Espero ter ajudado.

                  • Re: DW - Boas Práticas ETL
                    Yuri Nicolett

                    Isabela, seu procedimento esta correto. É sempre ideal tratar um projeto com no mínimo 3 etapas (extração, transformação e leitura). Claro que cada caso precisa ser analisado, pois pode ter a necessidade de mais ou menos etapas.

                    • Re: DW - Boas Práticas ETL
                      Fernando Suzuki

                      Também costumo utilizar o processo em 3 camadas. Além de organizar o fluxo das informações, facilita a escalabilidade do ambiente com o reaproveitamento dos QVDs.

                       

                      Minha contribuição pro tópico:


                      Na extração:

                      - vale a pena pensar em um processo de carga incremental para algumas tabelas, dependendo do tamanho e tempo de extração.

                      - para facilitar o gerenciamento das tarefas de recarga no server, organize os QVWs extratores por base de dados e por frequência de carga.

                      - deixar as strings de conexão em arquivos texto e fazer include deles no script. Assim quando vc precisar trocar os parametros de conexão (servidor, usuário, senha...), vc mexe em um único lugar e isso se refletirá em todos os QVWs extratores que usarem aquela conexão.

                       

                      Na transformação:

                      - centralizar todas as regras de negócio nesta camada, assim facilita na hora de debugar os dados. Sabe-se que dá pra fazer muitas regras de cálculo no layout, mas sempre que possível, migre as regras de cálculo para a transformação, criando flags auxiliares, contadores, dimensões auxiliares, consolidando valores, e até mesmo duplicando valores (com cuidado e quando fizer sentido, é claro...). Com isso você evita complexidade nas dimensões e expressões do gráficos, e eles ficarão mais performáticos, o que é muito importante para o usuário final.

                       

                      Na extração e transformação:

                      - organizar o código em abas para "compartimentalizar" a geração de cada qvd, o que também facilitará na hora de debugar os dados. Nos meus projetos eu crio flags de controle em variáveis e no início de cada aba eu checo se a respectiva flag está marcada, e com isso o usuário pode escolher qual qvd ele quer gerar.

                       

                      DW no QV:

                      - O QlikView é bastante flexível quanto à organização das informações, então neste sentido entendo o ponto do  lucianosv quando ele fala que não existe DW no QV. Porém, pela minha própria experiência, os aplicativos mais complexos vão demandar mais carinho na modelagem dos dados para que as informações se amarrem da forma correta, o que no final das contas significa criar um modelo no estilo de DW, com fatos, dimensões e linktables.

                      - É possível criar um DW fora do QV e já vi projetos funcionarem assim. Acho que o ponto crítico aqui é saber se o DW externo conseguiria se adaptar rapidamente às mudanças de requisitos nos apps do QlikView. Se sua empresa possui DBAs bons e que conseguirão criar e dar manutenção num DW externo com agilidade, eu recomendaria a você para aproveitar isso, pois você consegue dividir a responsabilidade com eles. Caso contrário, creio que ficará mais fácil centralizar o DW no QV.