Modelo ETL de alta escalabilidade para Digibee

Aprenda a desenvolver um processo ETL escalável usando pipelines baseados em eventos.

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.

Cenário

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.

Arquitetura

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.

Principais componentes

Extract

Pipeline para a paginação de registros para extração

Um pipeline do tipo Scheduler 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.

Os metadados das páginas são uma estrutura JSON que informa:

• O nome da integração

• ID da página

• Registro inicial

• Registro final

A partir de uma lista de integrações configurada com os parâmetros necessários para cada uma delas, o pipeline identifica por exemplo:

• Nome do fluxo

• Tabela de origem

• Número de registros a ser extraídos por página em cada evento

• Evento de extração a ser publicado

• Horário inicial da extração

• Lista de dependências de outras integrações (caso exista)

Pipeline para a extração de páginas

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 Object Store 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 tamanho (Small, Medium ou Large) 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 modelo baseado em consumo, a escala horizontal (réplica) pode ser configurada para Autoscaling, sendo necessário definir apenas o mínimo e máximo de réplicas para que a Plataforma se ajuste conforme necessário.

Transform e Load

Pipeline despachante de páginas

A responsabilidade desse pipeline tipo Scheduler de uso comum é verificar se um fluxo está liberado para envio e publicar o ID de cada página do fluxo para o pipeline de envio.

Enquanto as extrações acontecem, ele verifica as páginas já extraídas de cada integração, suas dependências em relação a outras integrações e publica o ID da página para o pipeline final (de envio) que coletará os dados da página para enviar ao destino.

Pipeline para envio de páginas

Esse pipeline do tipo Event é o responsável por capturar cada página da integração que está no Object Store 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.

Outros componentes importantes

Além da estrutura de pipelines citada acima, alguns componentes são importantes para controle e funcionamento do modelo ETL:

• Lista de integrações (fluxos): Pode ser uma Global configurada com um JSON ou uma tabela no banco de dados do cliente. Para este artigo, consideramos uma Global.

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

• Mecanismos de uso comum: Mecanismos de uso comum já existentes, como reprocessamento ou notificação. Podem dar suporte ao processo de ETL.

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

Conclusão

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.