topic DW - Boas Práticas ETL in Brasil

DW - Boas Práticas ETL

Thu, 16 Jun 2016 23:03:55 GMT

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

lucianosv — Fri, 17 Jun 2016 10:55:32 GMT

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

Marcio_Campestrini — Fri, 17 Jun 2016 11:39:35 GMT

Bom dia Isabela

O procedimento que adotamos aqui na empresa segue abaixo:

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.
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.
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

nicolett_yuri — Fri, 17 Jun 2016 12:39:05 GMT

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

nicolett_yuri — Fri, 17 Jun 2016 12:43:31 GMT

Para complementar:

imagine uma aplicação que precisa ser atualizada a cada 10 minutos, neste exemplo temos um curto intervalo de tempo do processo de atualização, e neste tipo de caso não ha necessidade de ter as três etapas.

Re: DW - Boas Práticas ETL

fabionakashigue — Fri, 17 Jun 2016 13:09:27 GMT

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

lucianosv — Fri, 17 Jun 2016 14:08:35 GMT

Se você relacionar não conseguirá analisar os dados puros caso exista erro na resultante.

Eu prefiro deixar desamarrado.

Re: DW - Boas Práticas ETL

Fri, 17 Jun 2016 17:52:35 GMT

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

Fri, 17 Jun 2016 17:59:29 GMT

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

Fri, 17 Jun 2016 18:02:16 GMT

Márcio, muito obrigada pela explicação, acredito que estou indo no caminho correto 😃

Re: DW - Boas Práticas ETL

Fri, 17 Jun 2016 18:04:24 GMT

Muito obrigada Yuri, fico feliz que estamos indo pelo caminho certo, fizemos um curso básico, mas na prática tudo é diferente, então surge várias dúvidas.

Re: DW - Boas Práticas ETL

nicolett_yuri — Fri, 17 Jun 2016 18:11:00 GMT

O mundo real é sempre mais divertido

Aqui tem um material bom: Best Practices for Data Modelling

Re: DW - Boas Práticas ETL

Fri, 17 Jun 2016 18:17:03 GMT

Fabio, Luciano

Ainda fiquei na dúvida entre relacionar ou não os dados nas etapas iniciais, na extração eu gero os qvds e apago as tabelas, não vejo necessidade de relacionar nessa etapa, na transformação faço a validação e tratamento dos dados, aqui vejo a real necessidade de relacionar para verificar se tudo está ok, não sei se estou correta, o Qlik ainda é um mundo meio desconhecido para mim

Deixando desamarrado o processo fica mais rápido?

Re: DW - Boas Práticas ETL

fosuzuki — Fri, 17 Jun 2016 19:17:47 GMT

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.