O desafio de organizar os dados no Nordestão — Parte 1
Quando uma empresa passa por transformação digital, seus dados passam a valer muito mais.
Background
O Nordestão vem passando por sua própria transformação digital nos últimos anos. Desde reestruturação das equipes, mudança de ERP, reafirmação da sua cultura para seus colaboradores, todas as atitudes apontam para uma empresa mais digital, com novos canais de atendimento ao cliente, maior uso de redes sociais e expansão de suas fronteiras (João Pessoa, estamos chegando!).
E como é de se esperar de qualquer empresa que passe por uma transformação, seus dados passaram a valer muito mais. Dessa forma, 2020 tem sido um ano ímpar para o ADAP (se não sabe quem somos, leia aqui) lidar com a demanda que surgiu da empresa por relatórios, análises, dashboards…
Por isso, nessa sequência de posts (essa é a parte 1) vamos contar para vocês todos os desafios, perrengues, ideias e vitórias que passamos e vamos passar nessa empreitada de fornecer a empresa uma base de dados estruturada, organizada e eficiente.
A situação inicial
No início de 2020, que foi o ponto de inflexão na nossa gestão de dados, o panorama que tínhamos era basicamente o de vários bancos de dados separados para cada aplicação, os famosos silos de dados. No ecossistema do Nordestão, as duas principais aplicações geradoras de dados são o nosso software de Ponto-de-Venda (PDV) e o nosso ERP. Obviamente as duas aplicações estavam ligadas através de integrações que foram definidas lá no início do projeto de implantação do ERP e que vêm sendo aperfeiçoadas pela nossa (brilhante) equipe de TI.
(Futuramente teremos um post explicando a estrutura da nossa diretoria de tecnologia e a função de cada célula dentro dela)
Entretanto só isso já não era suficiente. Era sempre custoso fazer qualquer análise que envolvesse informações de cupom (que vinha do nosso pdv) e classificação de produtos (ERP). As tabelas estavam todas em formato transacional, o que tornava as consultas demoradas e precisávamos de velocidade e eficiência. Foi nesse momento que decidimos que o Nordestão precisava do seu primeiro Data Warehouse.
O que é um data warehouse?
Um warehouse é uma estruturada criada para armazenar produtos de maneira organizada e que têm como principal função controlar os produtos que entram e saem e, além disso, tornar fácil o processo de extração e inserção de produtos, utilizando um esquema de organização que permite aos funcionários identificar rapidamente onde cada produto está. Um data warehouse segue a mesma linha de raciocínio, apenas substituindo os produtos por dados.
Construir um data warehouse não é uma tarefa simples. Foi necessário tomar várias decisões. Qual banco de dados usar? Quais especificações? Como extrair dados do ERP sem degradar seu desempenho? Qual ferramenta usar para ETL?
Tivemos que responder esse questionamento em várias reuniões junto como nosso diretor, nosso time de TI e até uma consultoria externa. Ao final desse processo, chegamos à estrutura que temos hoje. Decidimos que o protótipo inicial deveria ser feito com custo zero. Escolhemos o PostgreSQL como banco de dados e o Airflow como ferramenta de ETL. Nossa analista Fernanda escreveu no seu medium um excelente tutorial para quem quiser utilizar o airflow.
Nossa primeira demanda foi para atender o setor comercial. De maneira simplificada, eles precisavam enxergar de diversos pontos de vista (fornecedor, loja, categorias de material…) como as verbas recebidas estavam distribuídas. Esse é um acompanhamento que precisa ser feito diariamente para garantir que ao final do período (no nosso caso, mensal) as metas de margem da empresa sejam atingidas.
Entretanto, haviam muitos problemas. Verbas que eram lançadas a nível de fornecedor (impossibilitando que fossem analisadas do ponto de vista de categorias de material), verbas que não eram lançadas atreladas a uma loja, e etc. Como qualquer base de dados, era necessário limpeza e pré-processamento para torná-la utilizável como o setor comercial demandou.
O esquema estrela e sua aplicação
Depois de alguns dias de leitura e videoaulas, conseguimos entender que esse era um claro problema onde poderíamos aplicar, sem medo, o conceito de Modelagem Dimensional. A modelagem dimensional é um modelo de organização de dados que prioriza a velocidade de consulta em detrimento da velocidade de inserção de dados. Basicamente o oposto do Modelo Relacional, que estávamos acostumados.
A principal estratégia utilizada para implementar um modelo dimensional de dados é criar um esquema estrela. Esse modelo foi idealizado por Ralph Kimball (você pode encontrais mais informações aqui) e utiliza basicamente dois tipos de tabelas: Uma tabela-fato e suas várias tabelas-dimensão. Cada tabela segue regras sobre o que elas armazenam, visando tornar o modelo eficiente na consulta de dados e, claro, confiável.
A tabela fato deve armazenar apenas dois tipos de dados: Chaves estrangeiras que a ligam com as tabelas-dimensão e os valores que se quer medir, na sua máxima granularidade. Já as tabelas-dimensão devem ter suas respectivas chaves primárias ligadas à tabela-fato e todas as outras colunas devem ser classificações diferentes daquela dimensão. Calma, vamos dar um exemplo real de modelagem dimensional que utilizamos no dia-a-dia.
Suponha que determinado setor queira analisar os cupons vendidos no mês X, e quer agregar esses dados por dia da semana. Além disso, para cada dia da semana, ele quer agregar esses dados por cada categoria de produto que foi vendida, mas não todas, apenas as categorias que estão dentro do departamento de bebidas alcoólicas.
Fazer essa análise em um modelo relacional puro, requer que a tabela relacional contenha todas essas colunas. Além disso, para evitar uma varredura completa na tabela, você teria que ter índices criados em todas as colunas que você fosse utilizar, o que é um tarefa custosa e se estamos falando de uma tabela que armazena uma linha para cada combinação de produto e cupom, temos algo em torno de 20 milhões de linhas por mês aqui no Nordestão…
Mas, vamos imaginar que você é um guerreiro e você criou essa tabela, colocou todos os índices, e agora você tem essa informação rápida e eficiente. Na outra semana, o mesmo setor te pede exatamente a mesma análise, mas ao invés de querer ver por categoria, ele agora está interessado em ver por fornecedor. Todo o seu trabalho foi por água abaixo.
Utilizando modelagem dimensional, você pode criar uma tabela com uma chave primária incremental que aponta univocamente para um produto e, nessa tabela você cria outras colunas com características daquele produto (departamento, seção, categoria, data de criação, fornecedor…). Essa tabela tende a ter uma quantidade muito grande de colunas, porém ela tem uma quantidade reduzida de linhas (uma linha para cada produto, no nosso caso vamos arredondar para 20 mil). Está criada a sua tabela-dimensão de produto.
Então você faz o mesmo para a data e cria um calendário: Uma chave primária incremental, uma coluna com a data, e outras colunas com todas as dimensões daquela data: dia, mês, ano, bimestre, dia da semana e por aí vai.
Por fim, você utiliza a sua tabela transacional para criar uma tabela-fato que contém 20 milhões de linhas por mês, mas que tem apenas quatro colunas: id_produto, id_data, numero_cupom, valor. As colunas id_produto e id_data são chaves estrangeiras para as tabelas-dimensão que você acabou de criar.
E pronto, está criado o seu primeiro esquema estrela. Imaginando a situação que analisamos anteriormente, nesse caso você poderia usar a mesma modelagem para fazer os dois relatórios. E mais, quando você for filtrar dados (como queríamos filtrar apenas o departamento de bebidas alcóolicas) você vai fazer esse filtro na tabela-dimensão. Ou seja, anteriormente você precisaria filtrar todos os produtos em uma tabela com 20 milhões de linhas e agora você vai fazer esse filtro em uma tabela com 20 mil linhas. A mesma coisa com o filtro de data. No fim você só precisa fazer os filtros que você quer nas tabelas-dimensão e fazer um join com a fato (agora você precisa de apenas dois índices: id_data e id_produto). Essa operação é geralmente menos custosa computacionalmente.
De volta ao problema inicial
Se olharmos para o problema que nós tínhamos que resolver para o nosso setor comercial e o problema que usamos como exemplo anteriormente, chegamos à conclusão que usar um esquema estrela era a bala de prata que precisávamos para deixar esses dados disponíveis.
Foi então que começamos a construir a estrutura que temos hoje. Hoje o nosso data warehouse possui vários esquemas estrela. Temos 7 tabelas-fato que se ligam a 5 tabelas dimensão. Todas as tabelas são atualizadas diariamente utilizando o airflow como ferramenta de ETL rodando códigos python.
Manter essa estrutura não vêm sendo fácil. Para cada tabela-fato, temos dois scripts: Um que vai no banco de dados do ERP e faz a Extração e outro que Processa e Carrega os dados processados em cada uma das tabelas-fato. Temos também um script que atualiza cada tabela-dimensão (todos os dias novos materiais são cadastrados, mudam de categoria, alteram fornecedores, e etc.). No fim das contas são 16 scripts que precisam rodar em uma sequência específica onde cada conjunto de scripts depende de outro conjunto ter rodado antes para funcionar perfeitamente. Temos que lidar com problemas de limpeza de dados, variações no desempenho dos sistemas que gera atrasos nos scripts, novas dimensões que precisam existir para atender os setores e etc.
No fim das contas, o importante é que se por um lado ainda falta um oceano para atravessarmos e chegarmos a excelência que a empresa precisa de nós, por outro o Nordestão hoje já não está mais na praia, estamos todos os dias nadando cada vez mais rápido e cada dia mais próximos do nosso objetivo.
O que vem por aí
Na parte 2 desse projeto (que pode já estar sendo escrita ou não) vamos falar sobre:
- As dificuldades de se trabalhar com dados que vêm de fontes duvidosas
- Por que vamos migrar do PostgreSQL e vamos para Oracle e quais os desafios de migrar essa quantidade de dados entre bancos
- O próximo passo da nossa gestão de dados: Gerenciamento de metadados
E você? Já teve dores de cabeça organizando seus dados?
