Os ambientes de Big Data estão se tornando cada vez maiores com o crescimento da computação distribuída, IoT, microsserviços e a quantidade de maneiras diferentes de armazenar dados na nuvem. Nesse contexto, acompanhar todo o movimento de dados é quase impossível.
Nos seus sistemas de dados ou no último projeto em que trabalhou, você conseguiria dizer quais dados uma coluna em um database de origem gerou no dashboard ao final de um pipeline? Neste artigo, veremos as ferramentas e abordagens que podem nos dar uma melhor capacidade de observar o data flow através do ambiente, tornando toda a organização mais sustentável.
Introdução
De acordo com o livro Observability Engineering: Achieving Production Excellence, o termo “Observabilidade” foi criado pelo engenheiro Rudolf E. Kalman em 1960. Desde então, passou a significar diferentes coisas, dependendo da comunidade em que é utilizado.
Para aplicações, podemos encontrar com facilidade referências sobre três pilares:
- Logs: logs de aplicativos, logs de infraestrutura, logs de servidores etc.
- Métricas: para qualidade, saúde da infraestrutura, alarmes etc.
- Traces (rastros de execução): solicitações HTTP, microsserviços, banco de dados etc.
Na Engenharia de Dados, porém, podemos desdobrar os traces em dois outros tópicos:
Isso ocorre porque os traces podem não fornecer o mesmo nível de insight sobre o fluxo de dados como o rastreamento de linhagem, e não conseguem entregar os metadados que nos ajudam a saber mais sobre os dados em si, sem a necessidade de abri-los e lê-los. O volume de dados tornaria isso impossível, e é exatamente aí que este método se encaixa melhor.
Data Lineage
Ainda no âmbito da Observabilidade, no artigo Lectures on Controllability and Observability, publicado pelo Departamento de Pesquisa Operacional da Universidade de Stanford, Kalman define que a controlabilidade está relacionada ao input de um sistema, enquanto a observabilidade está relacionada ao output.
Com tal afirmação, ele define que a observabilidade é o quão bem podemos medir ou observar os estados internos do sistema a partir do output. Essa definição tradicional é comumente utilizada na engenharia mecânica e de controle, onde os sistemas são aplicados com um estado final esperado.
A Data Lineage (Linhagem de Dados) surgiu para tornar essa observação possível. É basicamente a capacidade de acompanhar os dados enquanto eles são processados no ambiente da organização. Normalmente, a tabela de origem do nosso dataset é limpa, processada, enriquecida com outras informações ou dados relevantes. Mas o caminho final é geralmente o mesmo para todas as empresas: responder às questões de negócios utilizando diferentes ferramentas como dashboards, indicadores, relatórios etc.
Para representar isso, usamos um diagrama ou um flowchart.
O problema que a linhagem de dados veio resolver é a dificuldade de rastrear as relações dos dados em nível de tabela ou até mesmo de coluna. Torna-se cada vez mais comum que as organizações transformem seus Data Lakes em Data Swamps, retrocedendo anos de trabalho. Além disso, com o crescimento dos negócios, a qualidade dos dados se deteriora. Desse modo, uma empresa que estava avançando para se tornar Data Driven acaba com um armazenamento muito caro, que não consegue atender às suas necessidades.
Exemplo prático
Imaginemos o seguinte cenário:
Neste cenário, temos uma arquitetura simples de Data Lake, com um banco de dados PostgreSQL como fonte, jobs do AWS Glue para ETL, AWS Step Functions para orquestração, Amazon Redshift como Data Warehouse, AWS Glue Crawler para descoberta de catálogo de dados, Glue Data Catalog para catalogação de dados e AWS Athena para consultas ad hoc.
Para o contexto da Data Lineage, quais metadados queremos coletar? Começando pela base. O output do nosso sistema pode ser:
- De onde os dados estão vindo?
- Quais transformações foram feitas nos dados?
- Para onde os dados estão indo?
Para responder a isso, vamos começar identificando as fontes e destinos.
Com o nosso data flow identificado, precisamos entender como os dados estão sendo tratados em cada etapa. Para criar seu Data Lineage, você pode:
- Identificar as fontes, neste caso, uma tabela no banco de dados PostgreSQL.
- Compreender a arquitetura para saber para onde os dados estão indo.
- Neste caso, os dados vão para o Data Lake no bucket AWS S3.
- Em seguida, vão para o Data Warehouse no Amazon Redshift.
Com essas informações, podemos mapear o caminho completo dos dados, desde a origem até o destino, e entender como eles são transformados ao longo do processo.
- Identificar as fontes, neste caso, uma tabela no database PostgreSQL.
- Compreender a arquitetura para saber para onde os dados estão indo.
- Neste caso, os dados vão para o Data Lake no bucket AWS S3.
- Em seguida, vão para o Data Warehouse no Amazon Redshift.
Agora temos duas informações importantes:
- De onde os dados estão vindo? ✅
- Quais transformações foram feitas nos dados?
- Para onde os dados estão indo? ✅
Para ilustrar ou registrar as transformações feitas nos dados, temos várias maneiras, mas duas delas são mais objetivas:
- Registrar a unidade de processamento e a versão que processa os dados:
- Unidade de processamento
- Versão do código
- Data do processamento
- Registrar a linhagem em colunas para entender quais dados geraram quais:
- Coluna de origem
- Coluna de destino
Unidade de Processamento
Esta abordagem inclui a computação de processamento no fluxograma.
- Prós:
- Fácil de descobrir onde corrigir um problema identificado na interface de Data Lineage.
- Agrega informações sobre as etapas do processo no flowchart.
- Contras:
- É necessário entrar no código para saber quais transformações foram feitas.
- Nem todas as ferramentas conseguem acessar essas informações facilmente.
Linhagem em Colunas
- Prós:
- Conhecendo os dados da fonte e o resultado na tabela de destino, é fácil identificar a transformação realizada.
- Informação direta sobre agregações de dados e novos nomes para as colunas.
- Mais ferramentas podem ler essas informações automaticamente.
- Contras:
- Falta de detalhes sobre como a transformação foi feita.
- Com grandes agregações, o fluxograma pode se tornar complexo
Data Lineage com OpenMetadata
Agora que entendemos como a linhagem funciona, suas bases e o que ele tenta resolver, como podemos realizar esse tipo de coleta de metadados na vida real? Ainda existem poucas ferramentas capazes de realizar esse tipo de operação, mas uma delas apresenta características interessantes: o OpenMetadata.
O OpenMetadata é um projeto Open Source que pode coletar informações automaticamente de diversas fontes. Com ele, podemos criar nossa própria plataforma de Observabilidade de Dados e integrá-la com fontes de dados, pipelines, ferramentas de ML, ferramentas de visualização, entre outras.
Na interface web, temos conectores pré-configurados para coletar metadados das fontes e, para algumas fontes, gerar automaticamente a linhagem, como no caso do uso do Amazon Redshift.
Se observarmos mais de perto, veremos que essa ferramenta utiliza a abordagem de linhagem em colunas para o rastreamento de dados.
Linhagem é uma das muitas funcionalidades de observabilidade e governança do OpenMetadata. Há um Sandbox disponível em https://open-metadata.org/ que você pode experimentar.
Conclusão
Essa é uma abordagem fundamental para o Linhagen de Dados e o motivo pelo qual ela é um pilar da Observabilidade de Dados. Embora ainda seja um campo pouco explorado, podemos ver que, com pouco esforço, conseguimos obter informações muito importantes sobre o nosso ambiente de dados.
Esse esforço pode nos economizar muito tempo e dinheiro ao entender as ferramentas de dados da nossa organização. Agora, podemos facilmente acompanhar como o ambiente está crescendo e, mais importante, obter informações mais rápidas para manter o negócio em um caminho saudável para que ele se torne mais orientado por dados.
Conhecer bem a nossa empresa nos leva a tomar melhores decisões sobre o negócio. Vamos começar a agir para analisar melhor os nossos dados? Nossa equipe está pronta para ajudar com seus desafios e construir juntos um futuro melhor para o seu negócio.
