O Futuro da Linhagem de Dados: Além do Diagrama

My post The Future of Data Lineage — Beyond a Diagram, translated into Portuguese by Gabs Ferreira

Pra a grande maioria, o termo linhagem de dados evoca pensamentos de um diagrama de linhagem, com nós e conexões entre esses nós. Um pouco como uma árvore genealógica, se você tivesse parentes chamados SALES_QUANTITY e PRODUCT_KEY.

É basicamente assim que vimos a linhagem, até que inúmeras conversas com engenheiros de dados nos fizeram perceber que este é apenas o ponto de partida.

Inicialmente, ficamos surpresos com o quão instigante era o termo “linhagem de dados”. A maioria dos engenheiros de dados já tinha pensado sobre o assunto e muitos estavam explorando ativamente como poderiam implementar a tal linhagem. Isso foi uma grande validação para Alvin: identificamos uma dor quase universal sentida na comunidade de dados.

Quem dera fosse assim tão simples.

Quanto mais conversávamos, mais dores íamos descobrindo. E em vários graus diferentes, dependendo de uma infinidade de fatores, incluindo função, empresa, ambiente regulatório e stack de tecnologias.

E aí percebemos que na verdade a linhagem de dados em si não é a dor: é a tecnologia. Perguntar “linhagem de dados é um problema para você?” não é diferente de perguntar “bancos de dados baseados em grafo são um problema pra você?”.

Pra nós, a linhagem de dados é uma estrutura de dados em tempo real que mapeia as dependências entre colunas, tabelas, dashboards, jobs e pessoas. É um conjunto de dados como qualquer outro, e um diagrama é apenas uma maneira de representá-lo.

Parte do motivo pelo qual as ferramentas atuais apenas arranharam a superfície quando se trata de linhagem de dados, é que ela faz parte de uma abordagem de cima para baixo na governança de dados. A tecnologia foi empurrada para os engenheiros de dados, às vezes criando mais dores de cabeça do que resolvendo. Encontramos pouco amor por catálogos de dados corporativos na comunidade de dados.

Na realidade, são os engenheiros de dados que enfrentam os desafios de garantir uma boa governança todos os dias. Ao compreender verdadeiramente os casos de uso técnico, as melhores práticas de governança de dados podem ser integradas em seus fluxos de trabalho, causando alegria em vez de pavor.

Vamos agora discutir alguns dos principais casos de uso para linhagem de dados que surgem em nossas conversas com engenheiros de dados, antes de revisitar a questão central de saber se um diagrama é a melhor maneira de resolvê-los.

Análise de impacto

Sem ter a oportunidade de usar dados de linhagem, fazer alterações na infraestrutura de dados (mesmo em um ambiente relativamente simples) nos foi citado como uma grande dor.

Algo tão inocente quanto adicionar uma coluna a uma tabela pode ter implicações downstream significativas. Em uma empresa que conversamos, isso fez com que uma métrica usada em relatórios financeiros ficasse fora por meses.

Para tentar evitar isso, é comum inspecionar manualmente logs SQL, DAGs do Airflow, arquivos LookML e arquivos Github. Isso não é só extremamente entediante: é uma enorme perda de tempo de um engenheiro altamente qualificado, assim como algo muito suscetível a falhas. É normal fazer uma alteração e morrer de ansiedade esperando alguém começar a falar no Slack que algo quebrou. Ou pior ainda, o CFO vir te cobrar pessoalmente!

A partir de nossas conversas, começamos até a categorizar diferentes personas entre os engenheiros de dados. O Cansado inspeciona meticulosamente os logs e mapeia as dependências downstream antes de fazer qualquer alteração. O Sagaz evita fazer alterações, a menos que seja absolutamente necessário. O Esperançoso está tão carregado de outras tarefas que ele faz o que pode e torce pelo melhor.

Cá entre nós: nenhum deles é o ideal.

Detecção de problemas

A maioria das perguntas (e reclamações) relacionadas a dados são direcionadas a engenheiros de dados. Por que este dashboard está quebrado? Onde estão os dados mais recentes? Você pode verificar se esta métrica está correta?

Mesmo depois de realizar a análise de impacto, podem ocorrer erros de pipeline de dados. O consumidor de dados geralmente os identifica, e cabe ao engenheiro de dados investigar.

Outra problema nesse sentido é que, muitas vezes, depois de investigar, os engenheiros de dados não encontraram nenhum erro. Por exemplo: alguém do time marketing que pensou que uma métrica estava fora do ar quando uma campanha simplesmente teve um desempenho inferior. Ou um analista solicitando os dados mais recentes antes da execução do trabalho agendado.

Com grandes consumidores de dados vêm grandes responsabilidades.

Priorizar essas tarefas em tempo real, juntamente com seu trabalho principal, sem comprometer a segurança e a privacidade, não é fácil para engenheiros de dados.

Sem dados de linhagem, o rastreamento do problema é extremamente manual e é alcançado principalmente por meio de uma combinação de conhecimento prévio e trabalho de adivinhação. Um pesadelo em particular pra quem está começando.

Limpeza de dados inativos

Quando se trata de um ambiente de análise, os engenheiros de dados expressaram várias vezes a falta de visibilidade sobre quais dados estavam em uso. Sem atenção regular, tabelas e painéis não utilizados podem se acumular rapidamente.

Tabelas temporárias para análise imediata aparecem mais rápido do que podem ser identificadas e removidas. Dashboards específicos para campanhas geralmente têm uma vida útil limitada, mas quem vai pensar em excluí-los quando eles deixarem de ser úteis?

É por isso que as pessoas precisam ser incluídas em qualquer gráfico de linhagem de dados. Antes de excluir uma coluna ou tabela, não apenas os engenheiros de dados precisam saber quais dados dependem dela, mas também de quais pessoas. Esse contexto ajuda engenheiros de dados a organizarem o ambiente de análise e a se sentirem tranquilos com relação a isso.

Dentro desta categoria, identificamos alguns casos de uso distintos:

• Limpeza periódica: como uma faxina de verão, os engenheiros de dados querem se livrar de ativos “obsoletos” de uma só vez.
• Pesquisa de ativos: um engenheiro de dados deseja saber se um ativo de dados específico está em uso e como esse uso mudou ao longo do tempo.

Confiabilidade dos dados

Ajudar os consumidores de dados a entender se podem confiar nos dados geralmente é tratado de forma imediatista por engenheiros de dados. Perguntas comuns aqui podem incluir: Como este campo é calculado? Devo usar o campo VALOR ou PREÇO? De onde vêm esses dados? Esses tipos de perguntas são mais comuns ao trabalhar com novos conjuntos de dados.

Catálogos de dados open source como Amundsen (Lyft) e DataHub (Linkedin), fizeram (e fazem) sucesso pelo fato de que havia uma tonelada de dados úteis que não estavam sendo usados ​​porque as pessoas não tinham como encontrá-los. Mas novos conjuntos de dados não são tão úteis, a menos que sejam confiáveis.

Os catálogos de dados resolvem isso por meio de metadados (proprietários, descrições, classificações etc.). Mas a fonte dos dados, como os campos são calculados e como são usados ​​são vistos regularmente como os fatores mais importantes para a confiança. Os dados de linhagem podem fazer com que a confiança nos dados seja algo natural e reduzir a carga dos engenheiros de dados para desempenhar essa função.

Rastreamento de dados PII

Engenheiros de dados descrevem privacidade como uma grande preocupação e algo que acaba sendo uma fonte de estresse com a qual eles precisam aprender a conviver. Grande parte do trabalho necessário para cumprir os regulamentos de privacidade recentes e mais rigorosos, como a LGPD, recai sobre seus ombros.

Em um ambiente de dados moderno, os dados confidenciais (por definição) passarão da fonte de dados para muitas tabelas diferentes, dashboards, notebooks, planilhas, modelos de aprendizado de máquina e muito mais. Manter o controle manual de onde os dados PII terminam com 100% de precisão é quase impossível.

Para dar um exemplo concreto, se um cliente exercer seu direito de exclusão sob a LGPD, como você rastrearia e excluiria todos os seus dados? Com as multas e o risco de reputação em jogo, não há espaço para erros. A tecnologia de linhagem pode ser extremamente valiosa aqui, rastreando dados confidenciais onde quer que fluam, até mesmo nos cantos mais escuros do data warehouse.

O futuro da linhagem de dados

Para nós, está bem claro que, ao aplicar a tecnologia de linhagem de dados a cada um desses casos de uso separadamente, a solução será diferente. As tentativas de resolvê-los todos de uma vez em um diagrama tendem a parecer um punhado de espaguete jogado na parede; o que obviamente não resolve nada.

Vamos ampliar o primeiro caso de uso que analisamos: análise de impacto. Geralmente, o que os engenheiros de dados querem saber é quais são as consequências downstream da execução dessa instrução SQL? E pra isso eles vão ter que sair do editor de consultas, pesquisar em um catálogo de dados e tentar descobrir o impacto de um diagrama de linhagem complexo parece a solução ideal? A resposta é um sonoro não!

Como a automação está se tornando algo presente em todos os aspectos da engenharia de software, é natural que a engenharia de dados adote as mesmas práticas; de DevOps para DataOps. Dados de linhagem de alta qualidade permitirão casos de uso semelhantes na engenharia de dados. As empresas já executam testes para pipelines de dados, bem como testes de controle de qualidade, e vemos algumas possibilidades interessantes aqui quando se trata de análise de impacto.

Ao isolar as dependências de downstream para uma determinada coluna, conseguimos simplificar a análise de impacto em nosso software. Estamos satisfeitos que isso esteja se mostrando útil, embora ainda tenhamos algum caminho a percorrer para cumprir as ambições apresentadas neste artigo. Mas com uma comunidade de engenheiros de dados constantemente impulsionando nosso pensamento, estamos otimistas de que podemos chegar lá.

Na grande maioria dos casos, o componente humano da governança de dados é o engenheiro de dados. A tecnologia de linhagem de dados tem o potencial de fornecer toda uma série de recursos que aumentam e até substituem partes de seu fluxo de trabalho, permitindo que eles concentrem seu tempo em atividades de criação de valor. A governança de dados está se tornando cada vez mais complexa, mas acreditamos que as ferramentas orientadas a casos de uso com tecnologia de linhagem ajudarão os engenheiros de dados a enfrentar o desafio.

Quer testar a Alvin?

Estamos em fase de pré-lançamento do produto! Solicite uma demo aqui.