A ascenção (e queda?) da dívida técnica em dados

Esse post foi escrito originalmente em inglês por Martin Sahlen e traduzido por mim, Gabs Ferreira.

Como engenheiros de software, falamos muito sobre dívida técnica. À medida que qualquer projeto ou produto progride, é quase inevitável que as compensações e os compromissos feitos ao longo do caminho se tornem problemáticos eventualmente.

Muitos de nós sabem lidar com dívida técnica, então será sabemos fazer a mesma coisa quando se trata de dados? Talvez sim, talvez não. Acho que precisamos dar um passo para trás e ver onde estamos e para onde estamos indo.

Neste artigo, meu argumento é que a engenharia de dados ainda é muito imatura em comparação com a engenharia de software e também porque a simples adoção de ferramentas e estruturas é, na melhor das hipóteses, uma maneira superficial de estabelecer as melhores práticas em engenharia de dados.

Usarei ideias e conceitos da engenharia de software para ilustrar o que penso ser necessário para a evolução da engenharia de dados. Existe um caminho para sair dessa bagunça? Como começamos a pagar a dívida de dados?

A mudança mais proeminente na área de dados nos últimos 5 anos foi a adoção de práticas de engenharia de software, como:

• Dados como código (e código como dados, se preferir);
• Controle de versão;
• Testes automatizados;
• Integração Contínua e Implantação;
• Frameworks opinionados para gerenciar uma ou mais partes do ciclo de vida dos dados.

De muitas maneiras, o surgimento da chamada modern data stack exacerbou os problemas existentes ao colocar ferramentas muito poderosas (e caras) nas mãos de pessoas sem o conhecimento total de como aproveitá-las. Como afirma Lauren Balik, o problema é a explosão de tabelas e dashboards para alimentar uma aparente necessidade cada vez maior de dados em todos os níveis da organização:

O que realmente está acontecendo aqui é que o número de analityc engineers (principalmente usando dbt como aproximadamente 75% das pessoas que tem esse cargo) está aumentando. Há uma explosão de tabelas e objetos no warehouse, e de dashboards, eventualmente mais pessoas são contratadas para fazer e gerenciar mais tabelas, tabelas e mais tabelas e dashboards, e essas pessoas adicionam custos ao Snowflake, fazendo cada vez mais tabelas e objetos para alimentar dashboards e análises crescentes que decaem em valor incremental para os negócios.

O custo financeiro tangível é significativo à medida que o número de tabelas e dashboards aumentam. É claro que nem tudo isso é dívida técnica, mas pelo que observei, a maioria das equipes de dados que usam dbt sente que está perdendo o controle sobre seus ambientes. Eles não têm ideia do que esses 10 modelos de aparência semelhante devem fazer ou qual dos 5 dashboards de “retenção de clientes” representa a fonte da verdade.

Claramente, trabalhar com dados como código não é a salvação que esperávamos. Chad faz um ponto importante semelhante aqui — nenhuma ferramenta sozinha pode ajudá-lo a gerenciar sua dívida técnica e não há soluções rápidas:

Quais são os problemas que estão causando essa bagunça?

Problemas:

🛠 Temos ferramentas poderosas: temos data warehouses que engolem consultas ineficientes sem soluços — e ferramentas para gerar novas tabelas em segundos. Estamos usando ferramentas elétricas para produzir pilhas de lixo com eficiência. Você pode fazer uma pilha de lixo ainda mais cara e confusa ainda mais rápido — automatizada e com CI/CD e testes. Mas no final do dia, ainda é uma pilha de lixo.

🌋🤑 Uma montanha de dados: lembra daquelas pilhas de lixo do ponto anterior? São dados que ninguém precisa ou usa, e isso não gera valor. Está aumentando o custo de computação, aumentando o custo de armazenamento e causando uma dor de cabeça com possíveis problemas de conformidade e segurança. Claro, seguimos todas as “práticas recomendadas” com testes em todas as colunas para distribuição, atualização e qualidade — acumulando ainda mais consultas desnecessárias 🤯

👎 Pior dos dois mundos: um “pedido rápido de dados” não pode mais ser atendido. Os engenheiros de dados gostam de tirar sarro do usuário comercial que solicita dados “bem rápido”. Essas solicitações eram algo que era tratado ad hoc e chegavam a uma planilha, só agora é muito rápido criar e executar um novo modelo dbt (talvez até criar um um dashboard?). Frequentemente, esse novo modelo é essencialmente algo duplicado de outro modelo, talvez com algum filtro ou agregação. Portanto, agora temos o poder de agilizar essas solicitações “únicas” no controle de versão, e elas permanecerão lá para sempre, pois ninguém sabe se são usadas ou não. As “melhores práticas” de controle de versão e dados como código agora estão trabalhando contra nós, pois o código está se acumulando e não há uma boa maneira de gerenciar seu ciclo de vida. Tudo isso em prol do "self-serv data" — não nos livramos das solicitações ad hoc, mas podemos agilizá-las pela a eternidade 😩

🧐 Falta de boas práticas: Pegamos seletivamente as coisas mais modernas e brilhantes da engenharia de software, como CI/CD, automação e tudo o mais que a galerinha descolada está fazendo. Temos ferramentas que nos permitem produzir e consumir dados em um ritmo sem precedentes, mas muito raramente falamos sobre o ciclo de vida dos dados em si. Quando a propriedade não é estabelecida, é difícil manter o que está sendo criado. As “coisas difíceis” como manutenção, refatoração e revisões de arquitetura não são feitas. Não existe a cultura do “menos é mais”. Isso contrasta fortemente com as equipes de software de alto desempenho. Na verdade, a maioria dos engenheiros seniores vê seus melhores dias como deletando e simplificando o código, deixando o mundo um pouco melhor do que o encontraram naquela manhã. Isso parece muito diferente de como a maioria das equipes de dados opera hoje em dia. Além disso, também acabamos de reinventar várias práticas recomendadas existentes e de longa data na engenharia de dados que estavam lá por um motivo, ou pior, simplesmente optamos por ignorá-las. Provavelmente, o maior elefante na sala é a modelagem de dados. Tabelas de fatos, tabelas de dimensões e dimensões que mudam lentamente estão se tornando relíquias do passado na corrida por mais e mais dados:

Como saímos dessa bagunça?

Como muitos profissionais de dados estão percebendo, os dados (como tudo) são sobre cultura e pessoas — não apenas sobre as ferramentas. Ainda acho que as ferramentas desempenham um papel vital, mas o caminho é uma mistura de considerações técnicas e organizacionais que devem ser levadas a sério. A lista abaixo resume minhas opiniões sobre onde precisamos ir e o que devemos fazer:

🌅 Entender ainda estamos no começo e que os frameworks que temos atualmente são sobre produção de dados. Ainda não estamos falando de forma coesa sobre propriedade e gerenciamento do ciclo de vida dos dados — o que também inclui depreciação e remoção de dados. As ferramentas precisam levar isso em consideração. Algumas pessoas pensam que essa omissão é intencional e até mesmo mal-intencionada como uma estratégia para aumentar o custo de todas as ferramentas — por exemplo Fivetran-dbt-Snowflake-Looker. Acho que provavelmente nem tudo são más intenções, é só que mais dados não são “melhores dados/melhores decisões”, e as pessoas simplesmente não perceberam que podem não precisar de todos esses dados em todos os lugares, o tempo todo.

💼 Alinhe o time de dados com as metas e resultados de negócios — ou seja, aproxime-se do negócio e trabalhe para fornecer valor tangível. Essencialmente, a equipe de dados precisa trabalhar ativamente para ser vista como um parceiro valioso que ajuda outros departamentos de negócios a atingir seus objetivos: fechar mais negócios, reduzir churn, aumentar contas correntes, fornecer melhor suporte. A lista continua. Mas, no final das contas, cada item do balanço precisa justificar sua existência e ROI. Como as equipes de dados têm sido responsáveis por um grande gasto, é natural que sejam colocadas sob escrutínio. Por mais estressante que seja ser bombardeado com solicitações urgentes de toda a empresa, geralmente há motivos claros para a solicitação. As melhores equipes de dados são especialistas em rastrear essas questões, assim como as melhores equipes de produtos adaptam continuamente seus produtos às necessidades explícitas e implícitas de seus usuários. Como o Chad Sanderson: comece simples, mas metas e resultados claros são essenciais para os dados (devo acrescentar, como em qualquer iniciativa).

🧑‍💻 Análise estática aprimorada: certamente podemos fazer melhor do que modelos jinja e {{ ref(“order_items”) }}. O próprio SQL pode ser analisado para inferir automaticamente o relacionamento DAG e a linhagem entre as tabelas (como fazemos na Alvin). Nesse sentido, também fico feliz em ver algumas iniciativas como o SQLMesh. É realmente empolgante — e evita aquelas referências irritantes e permite escrever nosso pipeline de dados e dependências simplesmente no velho SQL.

Linting e regras de sintaxe: aplique linting e padrões em SQL (não mais SELECT *) para ter formatação e estilos uniformes. SQLFluff é uma ótima ferramenta para remover aborrecimentos como colunas não qualificadas e muitas outras coisas que tornam nosso SQL menos legível e de fácil manutenção.

Gerencie dados como um produto utilizando metadados: as melhores equipes de produtos conversam com seus usuários para entender suas necessidades, mas também usam análises de produtos fortemente para priorizar e reduzir a prioridade dos recursos. Esta é uma parte muito natural do ciclo de vida de um recurso e do código que o alimenta. Ao fazer análises em suas análises, times de dados também podem obter uma melhor compreensão de seu impacto nos negócios. Entender quais dashboards estão sendo usados e as tabelas que os alimentam pode fornecer informações sobre onde priorizar as melhorias de desempenho. Da mesma forma, tabelas e painéis não utilizados devem ser excluídos rapidamente. Claro, aqui é importante ter um processo adequado em relação à depreciação e exclusão, que está relacionado ao alinhamento com as necessidades de negócios. Mas a arma secreta aqui é a proatividade. Em vez de descartar tabelas e dashboards de controle e aguardar o ataque, as equipes de dados podem notificar os consumidores sobre as próximas descontinuações e alterações. Melhor ainda, com base em padrões, eles podem encaminhar os usuários para versões mais atualizadas ou aprimoradas das tabelas ou dashboards dos quais eles dependem atualmente! Isso sim é ser um parceiro de negócios valioso 🤝

Gerenciar custos no nível certo: Este ponto, como o anterior, também gira em torno de metadados. Existem diferentes níveis de granularidade e, dependendo de seus objetivos para as práticas de dados, você precisa escolher o mais adequado para abordar o custo. Por exemplo, o dbt pode dizer quanto tempo seus modelos estão rodando e isso pode ajudá-lo a torná-los mais rápidos. Mas esse é o nível certo para fazer perguntas? Claro, é bom economizar tempo (e custo) de nossos modelos dbt, mas quanto impacto isso realmente terá? Já existem inúmeras abordagens e também empresas inteiras focadas exclusivamente em otimizar consultas adicionando filtros, partições, índices e outras coisas. Mas acho que esta é uma toca de coelho em potencial e não tenho certeza se resolve o problema fundamental. Tenho uma forte convicção de que, para tarefas de engenharia de dados, muitos dos problemas são resolvidos com muito mais facilidade. Compreendendo de forma holística o custo, o uso e a linhagem dos ativos de dados, é muito mais fácil fazer (e responder) as perguntas certas. Perguntas como: “Precisamos que essa consulta cara seja executada a cada hora?”. Se a resposta for não e decidirmos mudar para diário, a economia potencial é muito maior (e mais fácil) do que qualquer otimização de consulta. Assim que terminarmos com todas essas perguntas, podemos nos permitir mergulhar na otimização de consultas e tabelas. É muito mais fácil e rápido remover algo do que entendê-lo e otimizá-lo.

Existe um caminho à frente pra gente sair dessa bagunça? Tenho esperança que sim!

O que você acha? Deixa aí nos comentários ou me adiciona no Linkedin e vamos discutir!