Logo E-Commerce Brasil

Como o time de dados do Elo7 transformou seu negócio para ter métricas realtime

Por: Redação E-Commerce Brasil

Equipe de jornalismo E-Commerce Brasil

O Fórum E-Commerce Brasil 2023 trouxe Mario Amaral, Chief Architect da Elo7, para mostrar como o time de dados da empresa está usando ksqlBD para ter métricas de negócio realtime no DW (Data Warehouse). A palestra aconteceu na plenária Tecnologia no segundo dia de evento.

Imagem de palestrante sobre o palco do Fórum E-Commerce Brasil 2023
O palestrante Mario Amaral disse que a Elo7 passou de uma arquitetura baseada em jobs batch com Spark para a implantação do ksqlDB, um banco de dados para processamento em stream baseado no Kafka

“Em um cenário onde decisões de negócio precisam ser feitas cada vez mais rápidas, esperar dias ou horas para ter acesso a métricas de negócio é uma grande desvantagem competitiva. Por isso mudamos de uma arquitetura baseada em jobs batch com Spark para a implantação do ksqlDB, um banco de dados para processamento em stream baseado no Kafka”, revela Amaral.

Durante a apresentação, o palestrante compartilhou boas práticas e desafios encontrados no processo. “Começamos com arquitetura de ETL/batch, mas tem o problema da demora de 30 minutos. Por isso o nosso objetivo era ter mais velocidade no processamento dos dados e acompanhar algumas métricas de negócio em tempo real”.

Confira a seguir alguns apontamentos apresentados por Amaral em sua palestra:

Os desafios enfrentados

– Quanto mais próximo do realtime, menos tempo para validações;

– Nem tudo pode ser realtime. Janela de dados determina o “pace”;

– Dados nem sempre disponíveis. Não queremos ficar buscando dados nas bases dos sistemas externos;

– Consumidores precisam ser idempotentes. Isso significa que para ter algo realtime, para ter a visão final leva um tempo. Eventualmente quer ser atualizado conforme as coisas vão acontecendo. </em>

Sessões de usuários: unificar sessões de app e web, para isso agruparam navegação na sessão

– Emitir dados de sessão assim que o 1º presquest chegar;

– Janela de 30 minutos de inatividades;

– Contadores de request;

– Duração da sessão;

– Modelo de atribuição.

Por que KsqlDB?

– Abstração do KStream, que já usávamos;

– Menos trabalho de infraestrutura;

– Facilidade de deploy;

– Sintaxe em SQL;

– Integração com o schema-registry;

– Possibilidade de plugar Kafka conectores de forma simples.

Solução com ksqlDB

Boas práticas e pontos de atenção

– Dependência entre strams só dentro de contexto;

– Cuidado com a materialização de tabelas. Permite ter dados do passado para ser usado no stream (enrichment). Traz os dados para o ksqlDB e mantem ele em disco, mas cuidado com o espaço.

Solução com ksqlDB facilita a vida dos engenheiros de dados