O Nubank é uma empresa orientada por dados que tem a Ciência de Dados como um de seus quatro pilares, junto com Tecnologia, Design e Experiência do Cliente. Na prática, modelos de ciência de dados tomam decisões automatizadas desde a fundação da empresa; uma infraestrutura de dados e uma plataforma de última geração permitem que qualquer Nubanker manipule os dados. 

Uma oferta crescente de produtos levou a um aumento nos dados coletados, o que tornou a descoberta dos dados corretos cada vez mais árdua. Então além de acesso fácil e seguro a dados, Nubankers precisam de dados prontos com qualidade verificada para se concentrarem na análise e na aplicação de seus dados em vez de procurar os dados corretos.

Vejamos um exemplo simples. Digamos que você precise da quantidade de clientes para a sua análise. Você poderia usar a quantidade de pessoas cadastradas, quem fez uma primeira transação ou transferência, quem esteve ativo no último mês, quem não foi cancelado ou bloqueado por fraude ou quem não deixou de pagar.

Como poderia saber todas as opções e quais podem ser comparadas com as análises de outros?

Para abordar a qualidade dos dados e melhorar a eficiência dos Nubankers ao coletar dados e tomar as melhores decisões com base em dados, recentemente criamos uma nova camada de dados com qualidade verificada no nosso armazém de dados, com uma nova equipe centralizada para coordenar sua adoção e sustentabilidade.

Neste texto, nós vamos: 

  1. contextualizar a antiga abordagem descentralizada do Nubank quanto à qualidade dos dados;
  2. explicar como isso levou ao desafio de obter eficiência e qualidade de dados;
  3. apresentar a camada de “dados centrais” e a estrutura que introduzimos em janeiro de 2020 junto com uma equipe centralizada para melhorar a eficiência e a qualidade.

Conheça nossas oportunidades

Parte 1: O Nubank é uma organização descentralizada, acelerada e baseada em dados com uma plataforma de dados de autosserviço.

Trabalhamos em uma empresa que passou por um crescimento tremendo: 7 anos após o lançamento, o Nubank tem mais de 25 milhões de clientes, mais do que qualquer outra fintech do mundo sem considerar a Ásia.

Ele teve um crescimento impressionante com uma organização muito ágil, tanto em relação à organização de pessoas (cerca de 100 equipes autônomas) quanto à arquitetura de engenharia (cerca de 500 microsserviços). Isso significa equipes (esquadrões) multifuncionais com foco em um projeto ou objetivo específico da empresa, em conjunto com algumas equipes horizontais centralizadas.

A Equipe de Dados Horizontal se concentrou na democratização do acesso aos dados pela implementação de uma infraestrutura de fluxo de dados (ETL), integrando com ferramentas de consulta / BI e reforçando a proteção da privacidade dos dados. No entanto, como cada equipe tinha a liberdade de criar suas próprias tabelas, análises e modelos de ciência de dados, a qualidade dos dados estava variando muito.

Então a execução do ETL (processo de Extrair, Transformar e Carregar para transferir dados dos nossos microsserviços de produção até o nosso Data Lake e o Armazém de Dados) é responsável pela Equipe Horizontal; qualquer equipe, no entanto, é capaz de adicionar uma nova fonte de dados, ou uma nova tabela, ao ETL simplesmente usando as ferramentas de autosserviço desenvolvidas internamente.

Com uma boa mentalidade quantitativa e de engenharia entre os Analistas de Negócios, a adoção das ferramentas de dados foi muito rápida e ampla. Algo impressionante no Nubank é que há centenas de Analistas que sabem usar SQL, Scala, git e testes para suas transformações.

Em muitas empresas, adicionar uma transformação ao ETL automatizado é um processo de gargalo, então a quantidade de tabelas em execução fica limitada. No Nubank, entretanto, esse processo foi democratizado para todos contribuírem com pouco atrito.

Nossas avançadas ferramentas de dados de autosserviço foram “vítimas do seu próprio sucesso”: em poucos anos, nós não só tínhamos milhares de tabelas brutas, mas também milhares de tabelas de dados transformadas – e a quantidade só aumentava!

Parte 2: desafios de produtividade analítica e de consistência de dados decorrente de análise descentralizada

verificações de qualidade vs. velocidade de execução

todos os Nubankers podem usar nossa plataforma de dados de autosserviço para manipular dados, ganhando a responsabilidade de verificar os dados que estão usando e publicando.

no entanto, verificar a qualidade dos dados virou uma tarefa cada vez mais árdua devido ao aumento na quantidade de tabelas brutas e transformadas:

  • dados brutos (20 mil tabelas) com a diversificação dos nossos produtos financeiros oferecidos de um produto de cartão de crédito para pontos de recompensa, poupanças e empréstimos;
  • tabelas transformadas (10 mil) no nosso ambiente de análise com o crescente número de contribuidores engenheiros de análise, analistas, engenheiros de dados e cientistas de dados).

A consistência da definição de conceitos e métricas pela empresa também virou um desafio, pois a quantidade de equipes chegou a mais de 100, e elas precisavam se coordenar e colaborar da melhor maneira possível.

Para cada uso de dados, eram necessárias repetidas tarefas de controle de qualidade: garantir que os dados consumidos estejam compreensíveis (legibilidade), corretos (precisão) e coerentes (consistência). Então a velocidade da entrega (produtividade) da análise de dados era afetada.

Havia uma troca a ser feita entre a velocidade da entrega e a qualidade dos dados dependendo do caso de uso. Priorizar qualidade para relatórios regulatórios, modelos de ciência de dados de alta exposição ou decisões estratégicas e priorizar velocidade para análises ad hoc ou relatórios exclusivamente internos.

Embora tivéssemos verificado as tabelas com muita atenção, não era óbvio distingui-las entre outras. Além disso, dados com qualidade verificada podem ficar obsoletos com o tempo se não forem mantidos, e algumas tabelas de qualidade podem não estar coerentes com as outras em relação a convenções de denominação.

Identificando ganhos de qualidade e eficiência

Ficou claro que havia grandes oportunidades de ganho de eficiência, pois muitas das tarefas repetitivas de verificação de qualidade em centenas de equipes poderiam ser feitas de modo centralizado uma única vez, deixando mais tempo para analistas e cientistas de dados se concentrarem na análise e nos modelos em vez de procurar pelos dados certos.

Conforme percebemos que poderíamos melhorar muito a eficiência, a consistência, a precisão e a compreensibilidade da análise de dados coordenando a qualidade dos dados em uma equipe centralizada, a equipe de Produtividade de Análise do Nubank foi criada em janeiro de 2020.

Nosso objetivo era trazer essa eficiência sem perder a liberdade analítica dos analistas em toda a empresa. Por mais que centenas dos objetivos autônomos das equipes devam ser coerentes com os objetivos gerais da empresa, a nossa visão era de que as métricas, os modelos e os relatórios deveriam ser consistentes na empresa apesar de serem gerados por centenas de microsserviços independentes.

Parte 3: Introduzindo uma camada de “dados centrais” na empresa inteira com uma equipe centralizada para coordenar seu lançamento e sustentabilidade

Conforme a nova equipe de Produtividade de Análise tomou conta da qualidade dos dados para a empresa, ela abordou a organização do armazém de dados junto com um conjunto de regras (convenções de denominação, requisitos de documentação), processos (contribuição e manutenção) e iniciativas de comunicação.

Nossos componentes de implementação de governança de qualidade de dados no Nubank

Uma nova camada “central” no armazém de dados com alguns princípios

A equipe criou uma pasta “central” (ou seja, camada, esquema, recipiente ou domínio) para diferenciar claramente tabelas com qualidade verificada de outras pastas (de leitura e gravação) de acesso livre.

Implementamos regras mais rigorosas apenas à “pasta central” mantendo o restante do armazém de dados em um ambiente de leitura e gravação de baixas restrições de autosserviço. Isso foi essencial para as equipes manterem a liberdade de uso de dados que foi um catalisador para o crescimento do Nubank.

Além disso, reconhecemos que diferentes camadas de dados precisam coexistir, pois nem todas as tabelas devem ser usadas para mais de um caso de uso ou equipe. Nosso objetivo é que as tabelas de dados centrais sejam a fonte de dados de qualidade verificada e reutilizável para camadas mais focadas em aplicativos de negócios.

Os maiores princípios da camada “central” são:

  1. Os dados devem ser precisos (ou o mais precisos possível) e mantidos para continuarem precisos.
  2. As métricas devem ter convenções de denominação coerentes e consistentes e definições em todas as tabelas da camada.
  3. Qualquer Nubanker deve achar e usar os dados “principais” de fonte confiável para os principais objetos e processos de negócios.
  4. As tabelas seriam calculadas com base em dados brutos ou em outros conjuntos de dados centrais para garantir que a precisão fosse mantida.
  5. Há sempre uma documentação atualizada com cada tabela para garantir que os consumidores possam entender o conteúdo rapidamente.

Uma representação simples da nossa implementação: uma camada central de dados de qualidade verificada no nosso armazém de dados.

Regras e processos para tornar uma realidade sustentável

Para garantir que os princípios sejam seguidos, definimos regras e as reforçamos tecnicamente: para adicionar, modificar ou excluir um conjunto de dados na camada central, isso deve ser feito a partir de uma pasta específica no nosso repositório de código com regras de contribuição mais rigorosas.

Também temos processos de manutenção para monitorar possíveis problemas nas tabelas da pasta central com uma pessoa encarregada de corrigi-los.

Comunicação para envolver a empresa inteira

À medida que lidamos com uma necessidade crescente dos nossos consumidores de dados, esperamos que eles usem nossos conjuntos de dados centrais. Também esperamos que as equipes ajudem a contribuir na sua própria área de especialização, ou quando tiverem tabelas que já atendem aos nossos critérios e podem ser transferidas para a pasta principal, enquanto a equipe central coordena o cumprimento dos princípios de contribuição.

Por meio da comunicação e treinamentos, queremos impulsionar a contribuição e o consumo em toda a empresa, além de garantir que estejamos atentos às necessidades dos nossos consumidores de dados.

A equipe

Iniciamos a equipe com Engenheiros de Análise (EAs) e Analistas de Negócios (ANs).

Os EAs estavam mais focados na implementação, aproveitando conceitos de modelagem dimensional para projetar arquiteturas e ferramentas robustas, desempenho de execução, monitoramento e os reforços de regras técnicas no nosso repositório. Eles também foram fundamentais para esclarecer cálculos complexos e garantir que estavam corretos.

Os ANs estavam mais focados nas necessidades comerciais e em entender quais dados deveriam ser adicionados primeiro, ajudando a alinhar definições de métricas quando não havia um consenso claro, e documentando nossos processos que geram esses dados.

Além disso, eles também integraram esse conceito de dados centrais com a nossa ferramenta de visualização de dados, não apenas no modo como os dados eram organizados, mas também fornecendo alguns painéis e insights com base nessas métricas da empresa inteira, nos quais a considerável adesão deu visibilidade ao nosso projeto.

De cima a baixo, esquerda para a direita: Logotipo da equipe, Renan Critelli (AN), Amanda Onaga (EA), Pepijn Looije (EA), Vitor Julio (EA), Joao Pedro Micena (EA), Flavio Akira (EA), Marcel Rubner (AN), Talisson Souza (AN) e Ariane Hoffenberg (EA, líder da equipe).

Medindo o sucesso

O maior impacto é em relação à produtividade da coleta e do uso dos dados. No entanto, medir o aumento da produtividade é um desafio próprio, pois medir o tempo exato necessário para buscar alterações de dados é impossível. Até o momento, nossa abordagem é realizar pesquisas com os consumidores de dados.

Um segundo impacto é ter métricas e definições consideradas “fontes confiáveis” pela empresa inteira. Nós medimos isso verificando quantas equipes estão usando nossas tabelas centrais e quantas consultas são realizadas nas nossas tabelas centrais vs. nas “concorrentes”, ou seja, tabelas semelhantes que não foram verificadas.

Por fim, também medimos o desempenho das nossas tabelas, tanto em desempenho de execução (tempo para carregar) e em problemas que precisaram ser corrigidos de modo reativo.

Conclusão

Lembra-se do exemplo no início da publicação? Nós queríamos a quantidade de clientes. Um dos conjuntos de dados centrais que criamos é uma tabela no nível do cliente, com um resumo das informações mais recentes sobre ele/ela. Há uma coluna para cada opção mais comum para obter esse valor, e uma documentação que explica exatamente o que cada opção considera.

É possível comparar facilmente com outros relatórios que usam a mesma coluna, e se você vai usar esses dados para um relatório regular que precisa enviar, pode contar com esses dados, pois eles serão monitorados e mantidos. 

É muito mais direto e rápido do que seria antes, pois primeiro seria necessário perguntar às pessoas ou tentar comparar diversos cálculos diferentes de outros relatórios.

Como em toda plataforma que permite aos usuários consumir e contribuir com o mínimo de restrições possível, o sucesso leva a quantidades e variedades de conteúdo tão grandes, que a curadoria desse conteúdo se torna um grande desafio a ser enfrentado para manter a plataforma o mais relevante e intuitiva possível para os usuários.

A estrutura de dados centrais é uma maneira de separar uma categoria de tabelas que seguem um conjunto rigoroso de regras e implementar processos para garantir que elas sejam mantidas e que a contribuição siga o ritmo das nossas novas demandas de dados. A comunicação também é essencial para toda a empresa para garantir que a iniciativa seja compreendida e divulgada.

Alguns dos desafios que tivemos durante a implementação foram: 

  • Quais são as etapas para criar uma pasta abrangente de “dados centrais”? Como escolher e priorizar as tabelas para adicionar à pasta? Qual é a quantidade crítica de tabelas que deve servir de marco?
  • Como devemos lançar e definir proprietários de manutenção para cada tabela adicionada à pasta? Como podemos detectar novos problemas em um conjunto de dados centrais?
  • Como podemos definir quais são as colunas compartilhadas por toda a empresa?
  • Quais KPIs devemos monitorar? O que isso implica nas ferramentas de visualização de dados?

Esperamos compartilhar nossas respostas a algumas dessas perguntas em artigos futuros!

Conheça nossas oportunidades