Como a Loft lida com governança e qualidade na plataforma de dados

Texto escrito em co-autoria com Tiago Vinícius

Lidar com dados com diversas fontes da verdade e sem responsáveis bem definidos costuma ser um grande desafio para uma correta análise e apuração dos dados. Neste texto, compartilho como organizamos nosso Data Lake, como estruturamos os papéis e responsabilidades na construção dessa solução e usamos o ferramental da plataforma de dados na Loft, de modo a trazer mais governança e qualidade em um cenário de alta variedade de dados.

A Loft é uma plataforma digital que usa a tecnologia para simplificar a venda e a compra de imóveis. Fundada em 2018, a empresa conta com o apoio de importantes investidores globais, incluindo Andreessen Horowitz, a Fifth Wall, a Thrive Capital, QED Investors e a Monashees, e já captou US$ 788 milhões em cinco rodadas de investimento, que levaram a Loft ao ranking das 10 maiores empresas do mercado imobiliário do mundo.

Desde a fundação da Loft, houve um crescimento considerável em relação ao número de pessoas em nossa equipe (contamos com um time de mais de 1.000 pessoas Lofters espalhadas pelo Brasil), e também ocorreram aquisições de outras empresas. Como resultado da rápida expansão, temos um cenário de crescente complexidade nos processos que envolvem venda e compra de imóveis. Esta complexidade é suportada por um número elevado de ferramentas, sendo que parte destas são soluções contratadas de empresas externas e, em muitos desses casos, as contratações são realizadas sem envolvimento direto de nenhum squad de Engenharia. Diante deste cenário, temos um problema maior em relação à variedade do que no volume de dados.

Esta variedade de dados provoca o que chamamos de paradoxo da governança. Enquanto há dados com múltiplos responsáveis, existem muitas fontes de dados que não possuem um dono. O cenário de dados com múltiplos responsáveis passa hoje pelo uso de diversas ferramentas, sejam backoffices construídos internamente ou ferramentas de terceiros, resultando em múltiplas fontes da verdade para uma determinada informação. Também existem cenários de ferramentas contratadas em que há a necessidade de se extrair informações, mas não há um responsável direto por garantir qualidade e estruturação dos dados.

O cenário descrito provoca um impacto direto no trabalho de Business Analytics (nosso time interno que cuida de relatórios e auxilia a tomada de decisão baseada em dados) e Data Scientists. Em uma pesquisa interna, realizada recentemente com Data Scientists a respeito das dificuldades em lidar com dados na Loft, foram apontados problemas tais como muitas bases com dados duplicados, baixa confiabilidade dos dados e desconhecimento sobre qual seria a melhor fonte de dados para um assunto específico.

Além de Business Analytics e Data Scientists, temos outros perfis que trabalham com dados na Loft:

• Analytics Engineers — tem o papel de interpretar as necessidades de dados, abstraindo as complexidades técnicas, a fim de disponibilizar o melhor dado para os times consumidores trazendo robustez, eficiência e qualidade para todo o ciclo de vida das informações;
• Data Platform Engineers — organizados sob o Squad de Data Platform, são responsáveis pela construção da plataforma de dados da Loft, tendo como objetivo fazer com que as pessoas que lidam com dados na empresa possam ser mais produtivas no seu dia-a-dia;
• Machine Learning Engineers — organizados sob o Squad de MLOps, são responsáveis por construir um ferramental utilizado no dia-a-dia por Data Scientists, abstraindo complexidades de software e infraestrutura.

Dado o cenário do paradoxo de governança, e com o objetivo de dar mais produtividade ao trabalho de Business Analytics e Data Scientists, o squad de Data Platform vem trabalhando em um projeto que visa governança e qualidade de dados, que chamamos internamente de Data Lake 2.0.

Na versão anterior do Data Lake, que referenciamos a partir daqui como Data Lake 1.0, a ingestão de dados não é padronizada e, em função disso, a escrita em algumas tabelas não é otimizada. O Data Lake 1.0 também não apresenta uma estruturação bem definida, ocorrendo uma mistura entre dados exploratórios e analíticos. Por fim, o paradoxo da governança se reflete no Data Lake de tal forma que databases e tabelas não apresentam owners bem definidos.

Estruturação em Camadas

Para mudar esse cenário, estruturamos o Data Lake com uma separação dos dados em camadas. O diagrama a seguir representa as camadas que utilizamos e o ferramental usado para promoção dos dados entre as camadas.

.

Usamos no Data Lake 2.0 quatro camadas:

• Landing Area — corresponde ao dado mais próximo do data source, em formato json ou csv, sem qualquer otimização de escrita neste momento. Nesta área os dados ainda não estão disponíveis para consulta analítica, e não sofreram nenhum tipo de transformação. Para esta etapa, usamos a ferramenta Stitch para ingestão de informações de banco de dados de aplicações ou ferramentas desenvolvidas por terceiros em um bucket S3.
• Bronze Area — nesta camada, os dados da landing area passam pela primeira transformação, que nos referimos aqui como limpeza de dados. Os dados desta camada já estão disponíveis para análise em um formato Delta Lake.

Visando dar um ownership para cada tabela e obter o maior número possível de informações sobre o dado que está na camada bronze, adotamos o uso de schemas (Avro e Json Schema), com o AWS Glue Schema Registry. Por meio de schemas é possível que o dado da bronze area:

• Seja documentado, pois é possível inserir descrições a respeito de cada coluna e tabela existente;
• Definir alias para determinadas tabelas / colunas, feature especialmente útil em cenários de ferramentas externas que usam prefixos ou sufixos que indicam um contexto de uso;
• Anonimizar dados PII (personally identifiable information), como nome, email, telefone, etc.
• Definir quais colunas devem ser importadas de cada tabela, podendo até realizar cast para alguns tipos específicos.

A promoção da landing area para a bronze area é feita por meio do data-loader, que é um job pyspark executado no Databricks. Ele captura o dado da landing area e cria as tabelas em formato Delta Lake de acordo com o schema definido. Se o dado da landing area não estiver de acordo o job falha e os responsáveis pelos dados são notificados.

A definição de schemas deve ser principalmente dos squads responsáveis por estes dados. Em alguns casos de ferramentas externas, nas quais não existe um responsável internamente pelos dados, Analytics Engineers estão assumindo a responsabilidade pelo contrato. A ideia do ferramental é que squads ou analytics engineers devem conhecer bem o dado que está sendo promovido para a camada bronze, por meio da definição dos schemas. Questões como “qual formato utilizar” e “como realizar uma escrita otimizada pensando nos cenários de uso” são de responsabilidade do time de Data Platform, especializado no assunto, e que resolve estas questões de forma centralizada através do data-loader.

• Silver area — o principal ator nesta etapa é o time de analytics engineers e a ferramenta utilizada é o DBT. Com o DBT, o analytics engineer realiza uma modelagem lógica dos dados que estão no Data Lake com um viés analítico. Com o DBT atrelado a um conector Spark, as principais transformações são realizadas por meio de abstrações SQL.

Se por um lado, o dado da área bronze apresenta uma estrutura similar ao do data source, somente com alguns controles adicionais de alias e anonimização, o dado que está na camada silver apresenta uma qualidade atestada, com tabelas confiáveis que são consideradas fontes de verdades para Business Analytics e Data Scientists.

• Gold area — nesta camada os dados já sofreram transformações para fins mais específicos (por exemplo, um dashboard no Looker). Neste cenário, entram possíveis agregações, filtros, etc., que representam cenários de uso bem específicos. Assim como ocorre hoje da Bronze Area para Silver Area, as transformações da Silver Area para a Gold Area são realizadas por meio do DBT.

Controle de Acesso

Além da estruturação em camadas, habilitamos a feature de Table Access Control disponibilizada pelo Databricks. Com o Table Access Control, os databases e tabelas presentes no Data Lake obrigatoriamente possuem Owners, ajudando a diminuir o impacto do paradoxo da governança. Cada owner controla operações de GRANT e REVOKE, e os Owners de cada tabela avaliam se os dados contidos nas tabelas podem ser compartilhados com outras áreas da empresa.

Resultados obtidos

No momento, estamos atuando com o objetivo de migração dos dados presentes no Data Lake 1.0 para o 2.0. Para isso, estamos trabalhando em melhorias na usabilidade do ferramental construído, de tal forma que a construção de schemas seja uma atividade com a menor fricção possível.

Um ponto observado é que atribuir o ownership de tabelas com Table Access Control aos squads tem gerado uma mudança cultural. Os squads têm apresentado maior responsabilidade em relação a tabelas, jobs e schemas.

Do ponto de vista de arquitetura, o principal objetivo é que toda a ingestão de dados na Loft passe pelo ferramental do Data Lake 2.0. Com todos os dados neste fluxo único, além de controlar o processo de escrita das tabelas, podemos evoluir a solução visando controle de qualidade (detecção de anomalias, por exemplo) e observabilidade do dado (recência, métricas de confiabilidade, etc.). Além disso, toda a documentação das tabelas estará disponível em um catálogo de dados em breve.

Gostou do conteúdo? Espero que seja útil e, para finalizar, se você deseja entrar para o time e trabalhar focado em melhoria contínua junto com a gente, estamos com vagas abertas! Confira: loft.vc/vagas e #VemPraLoft