A Hierarquia de Necessidades de Dados: Por que sua IA vai falhar sem uma Engenharia de Dados sólida

Recentemente, revisando alguns materiais fundamentais da nossa área, me deparei com uma página que considero a "bússola moral" de qualquer projeto de dados sério. A imagem, extraída do excelente livro Fundamentos de Engenharia de Dados (de Joe Reis e Matt Housley), apresenta a famosa "Hierarquia de Necessidades da Ciência de Dados", originalmente proposta por Monica Rogati.

Sempre que vejo essa pirâmide, sou transportado para diversas reuniões de kick-off de projetos em que participei. O cenário é quase sempre o mesmo: a diretoria está eufórica com termos como "Inteligência Artificial Generativa", "LLMs" ou "Deep Learning". Existe uma ansiedade palpável para chegar ao topo da pirâmide — a parte sexy da coisa, onde a mágica acontece.

No entanto, a realidade do dia a dia, aquela que nós, engenheiros de dados, enfrentamos "nas trincheiras", é bem diferente. Como a própria página do livro destaca (e minha experiência confirma dolorosamente), cerca de 70% a 80% do tempo de um projeto de dados não é gasto treinando modelos, mas sim na base da pirâmide: coletando, limpando e processando dados.

Neste artigo, quero convidá-los a uma reflexão técnica e prática sobre por que ignorar a base dessa pirâmide é a receita perfeita para o fracasso, e como a Engenharia de Dados atua como o alicerce invisível, mas vital, para qualquer iniciativa de IA.

O deslumbramento vs. A realidade da infraestrutura

Quando comecei a me aprofundar em ecossistemas como o Databricks e a trabalhar com pipelines complexos na Azure e GCP, percebi rapidamente um padrão. Muitas empresas tentam "comprar" a IA antes de "construir" os dados. É como tentar colocar o telhado em uma casa que ainda não tem fundações.

Olhando para a Figura que compartilhei acima, vemos uma estrutura clara de dependências. Vamos quebrar isso com uma visão prática de quem já teve que consertar pipelines quebrados na madrugada.

1. A Base: Coletar (Instrumentation, Logging, External Data)

Tudo começa aqui. Se você não tem o dado, você não tem nada. Mas não é apenas "ter" o dado. É sobre como ele chega.

Em um projeto recente de migração para a nuvem, o cliente tinha terabytes de dados gerados por sensores IoT. O problema? Os logs eram inconsistentes, o formato mudava sem aviso prévio e a ingestão era feita via scripts manuais (o famoso "copy/paste" agendado).

Aqui, o papel do engenheiro de dados é implementar ferramentas de ingestão robustas. Estamos falando de configurar um Kafka ou Event Hubs para streaming, ou orquestrar ingestões em batch com Apache Airflow ou Azure Data Factory. Sem garantir que o dado está sendo coletado de forma confiável, qualquer análise futura é pura especulação.

2. Mover e Armazenar (Reliable Data Flow, Infrastructure, Pipelines)

Subindo um degrau, entramos no meu "playground" favorito: a movimentação e armazenamento.

A imagem menciona "Fluxo de dados confiável". O que isso significa na prática?

Significa que seu pipeline não pode falhar silenciosamente.

Ao desenhar uma arquitetura de Lakehouse, por exemplo, a preocupação aqui é definir as camadas (Bronze, Prata, Ouro).

• Bronze: O dado cru, assim como veio da fonte.

• Prata: O dado limpo, deduplicado e estruturado.

• Ouro: O dado agregado, pronto para o negócio ou para o modelo de ML.

Se os cientistas de dados precisam gastar horas procurando onde o arquivo CSV do mês passado foi salvo, falhamos na camada de "Mover/Armazenar". A engenharia de dados precisa prover uma infraestrutura elástica (como buckets S3 ou Azure Data Lake Storage Gen2) e pipelines de ETL/ELT que sejam auditáveis.

3. Explorar e Transformar (Cleaning, Anomaly Detection)

Aqui reside a maior parte do "trabalho sujo" mencionado no texto da imagem. A limpeza de dados não é glamourosa, mas é crítica.

Imagine treinar um modelo de previsão de vendas onde 10% dos valores de receita estão nulos ou negativos por erro de sistema. O modelo vai aprender errado.

Como engenheiros, automatizamos essa limpeza. Utilizamos frameworks como PySpark para processamento distribuído ou ferramentas de qualidade de dados como Great Expectations. O objetivo é entregar ao cientista de dados um dataset em que ele possa confiar, removendo anomalias antes que elas contaminem o modelo.

O "Gap" entre a Ciência e a Engenharia

O texto da imagem toca em um ponto nevrálgico: "Os cientistas de dados normalmente não são treinados para desenvolver sistemas de dados em nível de produção".

Isso não é uma crítica aos cientistas de dados — longe disso. O foco deles é estatística, algoritmos, matemática avançada e experimentação. O nosso foco, como engenheiros, é escala, resiliência e governança.

Quando um cientista de dados cria um modelo incrível no seu Jupyter Notebook local, ele funciona perfeitamente com aquele arquivo CSV estático de 500MB. O problema surge quando precisamos colocar isso em produção para processar 50GB de dados novos todos os dias, com SLA (Acordo de Nível de Serviço) definido.

É aqui que a Engenharia de Dados preenche a lacuna (como mostra a Figura 1.6). Nós transformamos aquele código experimental em um pipeline de produção.

Um exemplo prático: Do Notebook para o Pipeline

Imagine que um Cientista de Dados criou um código em Python para categorizar clientes. Ele usou Pandas e rodou na máquina dele.

Ao levar isso para produção no Databricks, eu, como Engenheiro de Dados, preciso refatorar isso.

Cenário do Cientista (Conceitual):

Python

import pandas as pd

# Lê o arquivo local
df = pd.read_csv("dados_clientes_final_v2.csv")

# Remove nulos
df = df.dropna()

# Lógica complexa de negócio
df['categoria'] = df['gasto'].apply(funcao_complexa)

Minha Abordagem como Engenheiro de Dados:

Eu preciso garantir que isso rode para milhões de linhas, que tenha tratamento de erro e que seja monitorado. Usaríamos PySpark para garantir o processamento distribuído:

Python

from pyspark.sql.functions import col, udf
from pyspark.sql.types import StringType

# Leitura otimizada do Data Lake (Camada Prata)
df_spark = spark.read.format("delta").load("/mnt/datalake/silver/clientes")

# Validação de Data Quality (Logar o erro, não apenas dropar)
# Em um cenário real, usaríamos Great Expectations, mas aqui vai um exemplo simples
total_count = df_spark.count()
null_count = df_spark.filter(col("gasto").isNull()).count()

if (null_count / total_count) > 0.05:
    raise Exception(f"Alerta: Mais de 5% dos dados estão nulos. Pipeline interrompido para verificação.")

# Aplicação da lógica de forma otimizada (UDF ou Pandas on Spark se necessário)
@udf(returnType=StringType())
def categorizar_udf(valor):
    # Lógica de negócio...
    return "Premium" if valor > 1000 else "Standard"

df_final = df_spark.withColumn("categoria", categorizar_udf(col("gasto")))

# Escrita na Camada Ouro com particionamento e controle de transação (Delta Lake)
df_final.write.format("delta").mode("overwrite").partitionBy("regiao").save("/mnt/datalake/gold/clientes_categorizados")

Percebem a diferença? O resultado analítico é o mesmo, mas a robustez é completamente diferente. É isso que significa "suporte e recursos de um engenheiro de dados", conforme citado no texto.

Por que focar na base é o melhor investimento

Rogati defende que as empresas precisam construir essa base sólida antes de abordar IA e ML. E eu assino embaixo.

Ao longo da minha carreira, vi projetos de ML falharem não porque o algoritmo era ruim, mas porque:

1. Os dados de treinamento não representavam a realidade (falha na Coleta/Exploração).

2. O pipeline de dados que alimentava o modelo quebrava toda semana (falha no Mover/Armazenar).

3. Não havia histórico de dados suficiente ou organizado (falha na Agregação).

O texto da imagem diz: "Ao se concentrarem nessas partes inferiores da hierarquia, os engenheiros de dados criam uma base sólida para o êxito dos cientistas de dados."

Isso me traz um senso de propósito enorme. Nós somos os facilitadores. Quando vejo um modelo de recomendação funcionando em tempo real, ou um dashboard executivo que carrega em segundos com dados confiáveis, sei que o trabalho "invisível" da engenharia foi bem feito.

A Era da IA Generativa muda isso?

Muitos me perguntam se com a chegada do ChatGPT e das IAs generativas, essa pirâmide mudou. A resposta é: ela se tornou ainda mais crítica.

Para usar LLMs em contextos corporativos (como RAG - Retrieval-Augmented Generation), a qualidade do seu dado não estruturado (documentos, PDFs, textos) e a governança sobre ele são vitais. Se você alimentar uma IA avançada com dados "sujos" ou desorganizados, você apenas terá uma "alucinação" muito convincente e rápida. O princípio Garbage In, Garbage Out (Lixo entra, Lixo sai) nunca foi tão verdadeiro.

Portanto, as camadas inferiores da pirâmide (Coleta, Armazenamento, Limpeza) continuam sendo onde a batalha é vencida ou perdida.

Conclusão: O valor do invisível

A engenharia de dados, muitas vezes, é um trabalho de bastidores. Não somos nós que apresentamos o gráfico bonito na reunião anual, mas somos nós que garantimos que os números naquele gráfico são reais.

A lição que tiro ao reler esse capítulo e analisar a Figura é que não devemos ter pressa em pular etapas. A maturidade de dados de uma empresa é uma jornada, não uma corrida de 100 metros.

Se você é um gestor, valorize seus engenheiros de dados e entenda que o tempo gasto em "limpeza e pipeline" é investimento, não custo.

Se você é um aspirante a engenheiro de dados, orgulhe-se dessa responsabilidade. Construir pipelines resilientes, garantir a qualidade do dado e arquitetar soluções escaláveis é uma arte que exige estudo contínuo e muita "mão na massa".

Afinal, como vimos, sem uma base sólida, a ponta da pirâmide (a tão sonhada IA) não passa de um castelo de cartas esperando para desabar.

E na sua empresa? Vocês estão construindo fundações sólidas ou apenas tentando decorar o telhado antes da hora? Gostaria de saber como vocês lidam com esse equilíbrio entre a pressão por IA e a necessidade de infraestrutura. Vamos conversar nos comentários!