Modelo ETL de alta escalabilidade para Digibee
Aprenda a desenvolver um processo ETL escalável usando pipelines baseados em eventos.
Atualizado
Isto foi útil?
Aprenda a desenvolver um processo ETL escalável usando pipelines baseados em eventos.
Atualizado
Isto foi útil?
Embora uma plataforma iPaaS como a Digibee seja um software em nuvem que ajuda a conectar aplicativos de diferentes sistemas e organizações em tempo real, é inevitável que existam necessidades de implementação de processos de ETL (Extract, Transform and Load). Mesmo com diferentes capacidades, é possível implementar esse tipo de solução com grande eficiência.
Este documento descreve um modelo ETL utilizado na extração, transformação de dados (mapeamento de campos) e envio de arquivos de grande volume de registros em um banco de dados relacional para o sistema de destino utilizando a Digibee Integration Platform.
O objetivo é conseguir realizar a extração dos dados dentro do intervalo de tempo pré-determinado, escalando eventos conforme a demanda.
Considere um cenário onde um alto volume de dados deve ser extraído de uma base de dados relacional que contém diferentes tabelas, onde cada uma contém dados de um fluxo de negócio distinto, ou seja, várias integrações. Todas essas tabelas juntas podem representar cerca de 20 milhões de registros por dia.
Para cada uma das tabelas, é necessário realizar um mapeamento de campos, e os dados devem ser enviados em lotes para o destino que pode ser uma API ou um File Server.
Considere também que no destino não há uma janela restrita de tempo para entregar os dados, mas a extração se dá em um banco de dados de uso crítico e, por isso, deve ser realizada durante a madrugada. Dessa forma, é importante que a arquitetura seja altamente escalável, permitindo parametrização por fluxo.
A implementação deste modelo segue uma arquitetura baseada em eventos, na qual temos:
Dois pipelines iniciais para a etapa de Extract
Dois pipelines que juntos contemplam as etapas de Transform e Load
A arquitetura apresentada neste artigo prevê uma transformação simples como, por exemplo, um mapeamento de campos da origem para o destino, contemplando algumas regras simples.
Entretanto se o cenário requer transformações complexas de dados, que dependem de grandes processamentos internos, talvez seja necessário evoluir a arquitetura com um pipeline de evento somente para transformação, antes do envio dos dados, como mostra o modelo abaixo:
Com a Digibee Integration Platform, é simples evoluir esse modelo de forma desacoplada, ganhando muito em escalabilidade.
Além da estrutura de pipelines citada acima, alguns componentes são importantes para controle e funcionamento do modelo ETL:
Controle de páginas para extração: É necessário um Object Store para armazenar cada “metadata de página” para extração.
Object Store temporário: Um Object Store específico para cada fluxo, onde suas páginas extraídas são armazenadas para posterior transformação e envio.
Controle de integração: Embora não representado no diagrama acima, é altamente recomendado manter um Object Store de controle de integrações para manter o status diário de cada integração configurada na Lista de integrações.
A arquitetura apresentada neste artigo garante alta escalabilidade no processo de ETL. De acordo com a demanda e restrições de cada componente, podemos escalar a extração e carga de formas diferentes, cadenciando cada uma das etapas conforme necessário. Por exemplo, se a janela de extração na origem é menor do que a de carga no destino, podemos acelerar a extração com mais réplicas.
Esse desacoplamento das etapas também evita que uma indisponibilidade no sistema de destino bloqueie a etapa de extração, que pode ser 100% concluída para posterior envio dos dados.
Além disso, o modelo permite compartilhar componentes comuns entre diversos processos, como é o caso dos pipelines de geração de páginas para extração e o pipeline de liberação de envio de páginas.
Um pipeline do tipo de uso comum inicia o processo para extração dos dados. Este pipeline funciona como uma “alavanca” de integrações. Sua responsabilidade é apenas gerar os metadados das páginas de cada fluxo e publicar o evento de extração.
Um pipeline específico para cada integração que recebe em cada publicação os metadados da página para realizar sua extração e armazenar esses metadados no temporário (específico do fluxo).
Por ser um evento, esse pipeline pode ser escalado conforme a necessidade do fluxo em questão. Isso pode ser feito tanto em para suportar a página extraída, quanto em réplicas para suportar a quantidade de páginas previstas simultaneamente. Por exemplo, se for necessário reduzir o tempo de extração, o aumento de réplicas pode ser uma boa estratégia.
Com o , a escala horizontal (réplica) pode ser configurada para , sendo necessário definir apenas o mínimo e máximo de réplicas para que a Plataforma se ajuste conforme necessário.
Esse pipeline do tipo é o responsável por capturar cada página da integração que está no temporário, fazer a transformação, e enviar ao destino. Assim como o pipeline de extração de páginas, esse pipeline deve ser específico para cada integração.
Lista de integrações (fluxos): Pode ser uma configurada com um JSON ou uma tabela no banco de dados do cliente. Para este artigo, consideramos uma Global.
Mecanismos de uso comum: Mecanismos de uso comum já existentes, como reprocessamento ou . Podem dar suporte ao processo de ETL.
