Por que utilizar uma ferramenta de ETL ?

Bom Dia Pessoal,

Essa semana ministrarei um curso oficial de Integration Services em um CPLS. Já ministrei esse curso algumas vezes e sempre no início do curso eu deixo o assunto SSIS de lado e começo a falar de ETL de uma forma geral. ETL é o acrônimo de Extract, Transform & Load e trata-se de um processo indispensável na construção de um Data Warehouse. O Data Warehouse dificilmente existirá sem um processo de ETL (por mais simples que seja), mas processos de ETL existem para atender a muitas necessidades (não somente abaster um Data Warehouse).

Há milhares de ferramentas de ETL disponíveis no mercado como o Oracle Warehouse Builder (OWB), IBM Information Server (Data Stage), o Integration Services (SSIS), o Power Center (antigo Power Mart), etc para citar algumas. Normalmente ferramentas de ETL custam caro e não raras às vezes as pessoas se perguntam se é mesmo necessário adquirir uma ferramenta de ETL. Já escutei algumas coisas do tipo:

  • "Se eu vou só transportar dados de um lugar pro outro eu preciso comprar uma ferramenta pra isso ?"
  • "É só pegar meia dúzia de tabelinhas do banco A e mais algumas do banco B e colocar no banco C. Pra que ferramenta ?"
  • "Putz, além de ter de entender de PL/SQL, TSQL e Java eu agora vou ter que aprender mais uma tecnologia só pra transportar dados ?"
  • "Não dá pra fazer um programinha pra poder fazer essas cargas ? Uma ferramenta de ETL é muito cara"
  • "Se usamos somente banco de dados ORACLE não precisamos de ferramenta de ETL, afinal é de ORACLE pra ORACLE e aí é tudo compatível"

De fato são questionamentos que à primeira vista parecem imbatíveis. Os custos com ferramentas de ETL podem ser expressivos variando desde alguns dólares por CPU até algumas centenas de milhares de dólares para licenciar um servidor. Nenhum gestor irá dispender recursos financeiros se julgar que eles não absolutamente necessários e isso se aplica a ferramentas de ETL. Avaliar o valor agregado de um novo servidor ou de um novo software é algo relativamente direto. Bastaria avaliar a quantidade de transações processadas, a satisfação dos usuários, o aumento de visitas no site, a produtividade adquirida, etc. Entretanto avaliar os ganhos de uma ferramenta de ETL antes mesmo de adquirí-la já é algo bem mais complicado. Se o retorno é difícil de ser mensurado e de ser visto, naturalmente adquirir uma ferramenta de ETL pode não ser algo fácil. Mesmo as alternativas Open Source como Pentaho podem ser difíceis de implementar se os benefícios do uso da ferramenta não forem claros.

Dado esse contexto é comum surgir o questionamento "Preciso mesmo de uma ferramenta de ETL ? Não dá para desenvolver isso na mão ?". A resposta categórica de muitos fabricantes é simplesmente dizer que a ferramenta de ETL é indispensável, que tem várias vantagens, é mais performática, etc. Não discordo de muitos desses argumentos, mas pessoalmente acredito que possuir uma ferramenta de ETL não é indispensável para todas as situações e há cenários que a construção "hard code" pode ser mais vantajosa. Se me perguntassem se um processo de ETL deve ou não utilizar uma ferramenta eu diria "depende". Há vantagens e desvantagens associadas em utilizar uma ferramenta ou fazer todo o processo "hard code".

Algumas vantagens do uso de processo "Hard Code"

  • Controle: Se você desenvolve tudo do zero, você tem controle completo sobre o processo. Esse controle evita qualquer tipo de "caixa preta" ou desconhecimento de como uma determinada parte da carga funciona. Todo o processo é conhecido e controlada de ponta a ponta e pode ser modificado da forma desejada quando necessário.
  • Customização: As possibilidades de customização são infinitas, pois, todo o código do processo de carga estará disponível para eventuais mudanças. Isso inclui novas funcionalidades na carga, adaptabilidade em relação a algum framework interno da empresa, etc.
  • Convergência com a plataforma tecnológica: Não será necessário adquirir hardware, software ou um sistema operacional a parte para adaptar a ferramenta de ETL ao direcionamento tecnológico da organização. A criação de um processo de ETL "hard code" permite a escolha da linguagem de programação que a organização jugar mais adequado.
  • Convivência com o legado: O desenvolvimento interno sempre se adaptará aos sistemas legados e nunca será impositiva a mudança do legado para adaptar-se às cargas e (ou) construção de pequenos módulos para realizar essa integração.
  • Suporte: A construção própria dispensa contratos de suporte e manutenção com o fabricante. Você também não será surpreendido pelo fato de um fabricante simplesmente descontinuar o produto e não comercializar mais suporte.
  • Debugação: As atividades de DEBUG não vão se deparar com uma parte não "debugável" do código, pois, não haverá no processo partes cujo codigo fonte não esteja disponível

Algumas vantagens do uso de ferramentas de ETL

  • Desenvolvimento das cargas: Desenvolver uma rotina de carga em uma ferramenta de ETL é muito mais fácil e rápido que codificá-la. Dependendo da facilidade da ferramenta é possível inclusive que usuários não técnicos a utilizem para cargas mais simples.
  • Manutenção das cargas: As tarefas de manutenção de uma rotina de carga são mais fáceis de realizar em relação à manutenção de código.
  • Desempenho: As ferramentas de ETL utilizam métodos mais performáticos para trabalhar com grandes volumes e normalmente conseguem extrair, transformar e carregar dados com mais velocidade e menos utilização de recursos. Isso inclui operações não logadas, gravações em bloco, etc.
  • Execução em paralelo: Ferramentas de ETL possuem recursos de paralelização nativos e facilmente implementáveis.
  • Escalabilidade: Ferramentas de ETL podem ser transferidas de servidor mais facilmente e até eventualemente distribuir sua carga entre vários servidores.
  • Diversidade de conectores: A conexão de uma ferramenta de ETL com múltiplas fontes de dados é transparente. Caso apareça alguma fonte não trivial como o SAP, Mainframe, VSAM, etc é possível adquirir o conector sem a necessidade de codificar um.
  • Separação entre funcionalidade e manipulação de dados: Uma ferramenta de ETL já possui suas funcionalidades disponíveis (Lookup, Merge, Split, Expressões calculadas, etc). Só é necessário concentrar-se em como fluir os dados dentro da carga e não codificar cada tarefa da carga.
  • Reusabilidade: Uma carga normalmente pode ser reaproveitada dentro de outras cargas ou sobre a forma de um template
  • Reinicialização: Ferramentas de ETL possuem a capacidade de reiniciar a carga de onde pararam sem a necessidade de codificar essa inteligência
  • Manutenção de Metadados: Os metadados são gerados e mantidos automaticamente com a ferramenta evitando que problemas de conversão gerem dados não íntegros ao final do processo. A manutenção de metadados também evita ou alerta para alterações de esquema que invalidem a carga.
  • Documentação: As ferramentas de ETL possuem mecanismos de documentação (quando não são autoexplicativas). Isso pode ser um diferencial significativo principalmente para equipes de alta rotatividade.
  • Maior garantia da qualidade dos dados: Ferramentas de ETL podem disponibilizar meios para trabalhar a qualidade dos dados através de algoritmos complexos (lógica fuzzy, IA, etc).
  • Auditoria & Tracking: É possível implementar recursos de auditoria e tracking para conhecer de onde veio o registro, que transformações sofreu e como foi carregado.
  • Segurança: É possível tornar a segurança mais modular dividindo-se os papéis (criação de cargas, execução de cargas, agendamento, etc)

Como é possível observar há vantagens e desvantagens associadas entre utilizar ou não uma ferramenta de ETL e muitos fatores podem influenciar nessa escolha (custo, tamanho do projeto, complexidade das cargas, etc). Com o declínio dos custos das ferramentas ETL e aumento constante de uso de ETL (principalmente para atender às crescentes demandas de BI), creio que optar por desenvolver todo o processo de ETL de forma "hard code" será algo cada vez mais sem sentido. Mesmo uma tarefa simples como retirar dados do SQL Server e colocar no Excel envolve um certo trabalho se for completamente codificada.

Um cenário comum bem relacionado a essa avaliação é a utilização de stored procedures para carregar dados. Já vi diversas implementações que utilizam stored procedures para carregar dados. Em minha opinião, utilizar stored procedures para carregar dados é algo que funciona bem para pequenos projetos e iniciativas, mas é algo inadequado para processos de cargas complexas e (ou) grandes volumes. Apresento abaixo algumas razões pela qual stored procedures não devem ser utilizadas em atividades de carga. Foquei mais no SQL Server, mas provavelmente boa parte das razões (senão todas) são válidas para outros SGBDs.

  • Incapacidade de rodar em paralelo: Por melhor codificada que uma stored procedure possa ser ela não é capaz de paralelizar comandos, ou seja, não há como uma stored procedure rodar duas instruções de INSERT em paralelo. Será necessário finalizar a primeira instrução para prosseguir para a segunda. Com grandes cargas e muitas bases, tal abordagem pode simplesmente ser proibitiva em virtude da janela de tempo
  • Incapacidade de se recuperar no caso de uma parada: Se o processo que roda uma stored procedure for eliminado por qualquer razão (kill, deadlock victim, reinicialização do servidor, etc) não há como a carga se recuperar do ponto em que parou. É possível codificar essa inteligência na stored procedure, mas reinicializar a partir de uma parada não é uma característica nata.
  • Contexto transacional: Stored Procedures rodam sobre um contexto transacional e vão impor bloqueios até que finalizem sua execução. Se uma stored procedure demorar para executar é possível que boa parte dos seus recursos sofra contenção até que ela finalize provocando bloqueios e lentidão para os outros processos. Se ela for eliminada, o custo de ROLLBACK pode ser considerável gerando mais indisponibilidade no acesso a dados além de aumentar o log de transações. Tais características podem ser descartadas em um processo de ETL retirando seu contexto transacional bem como implementar cargas não logadas.
  • Não isolamento: Stored Procedures não podem ser isoladas do resto das atividades do SGBD. Elas sempre irão rodar no mesmo lugar que o SQL Server está impossibilitando movê-las para outro servidor para aliviar a carga das demais tarefas do SQL Server. Embora o Resource Governor possa ajudar com essa limitação não haverá como retirar as stored procedures do servidor onde o SQL Server está.
  • Dificuldades para escalar: Se as stored procedures estão provocando lentidão em um servidor SQL Server não há muita escolha senão aumentar as capacidades do servidor de banco de dados. Se uma ferramenta de ETL fosse utilizada outros mecanismos de escalabilidade podem estar disponíveis como o balanceamento de carga por exemplo.
  • Manutenção e Complexidade: Cargas complexas podem significar stored procedures bem longas com milhares de linhas (já vi SP com 20.000 linhas). Dar manutenção em um código desses é algo bem complicado já que não há nenhuma iteração visual. As atividades de testes e análise de impactos também são muito mais complicadas.

Nas palavras de Ralph Kimball no clássico "Data Warehouse ETL Toolkit", ele é enfático quando diz: "Um sistema de ETL pode fazer ou invialibizar o Data Warehouse". Embora o processo de ETL seja uma atividade em background que o usuário não visualize, ele certamente consome a maior quantidade de tempo de um projeto de Data Warehouse e Business Intelligence (há percentuais variando de 70% a 90%). A escolha em optar ou não para uma ferramenta de ETL juntamente com a complexidade do projeto é crucial na determinação desse percentual.

[ ]s,

Gustavo

10 Respostas para “Por que utilizar uma ferramenta de ETL ?

  1. Excelente artigo.
    Bastante esclarecedor e de leitura fácil.
    Parabéns e obrigada por compartilhar.

  2. excelente o post, bem esclarecedor, estou passando por uma situacao parecida, onde nao sei se fazer o code ou usar uam ferramenta. Pois, ainda nao conseguir medir o custo x beneficio por agora.
    parabnes gustavo.

    • Oi Camilo,

      O grande complicador de adquirir ferramentas de ETL é que o custo é conhecido, mas o benefício é difícil de mensurar. Caso você opte pelo SQL Server, a ferramenta de ETL já está paga e basta usufruir.

      [ ]s,

      Gustavo

  3. Excelente Gustavo. De forma simples e clara o artigo aborda tópicos importantes sobre o uso de ferramentas ETL. Parabéns.

    Abraço,

    Demétrio Silva

  4. Oi Gustavo,

    Parabéns pelo artigo, ficou excelente. Estou desenhando e implementado um projeto de DW e optei por usar o SSIS como facilitador, porém como o negócio envolvido é muito dinâmico, isto é , há mudanças constantes nas regras de negócio, estou mesclando o processo de etl com Hard Cod para mudanças das dimensões que são em sua maioria do tipo 2.
    Adorei suas abordgens sobre o assunto.

    • Oi Carol,

      E aí ? Tudo bem ?
      A idéia de fato é ponderar quando o ETL pode ser melhor que o hardcode e vice-versa.

      Dimensões do tipo 2 podem ser tratadas sem muita alteração no ETL. O problema mesmo são as dimensões do tipo 3 (essas sim, dão trabalho com ETLs, pois, envolvem mudanças de estrutura).
      Ainda assim, muitas mudanças de negócio alguns vezes podem ser melhor endereçadas por Hardcode e acredito que deva ser o seu caso.

      [ ]s,

      Gustavo

  5. Mauro Cesar Medeiros

    Bom dia amigo, qual ferramenta de BI indicaria?

    • Olá Mauro,

      Sem querer parecer clichê, mas a resposta é “depende”. Até pq BI envolve alguns módulos como ETL, OLAP, Profiling, Data Quality, etc. Só o que poderia dizer é que tente manter a padronização sempre que possível. Evite adquirir componentes de múltiplos fabricantes para não ter dor de cabeça na hora de ter de falar com o suporte.

      [ ]s,

      Gustavo

  6. Ótimo post!
    Rápido, prático eficiente e eficáz.
    Parabéns!

Deixe uma 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 )

Imagem do Twitter

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

Foto do Facebook

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

Foto do Google+

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

Conectando a %s