Engenharia de dados como produto: como eu trabalho dados em um grande banco

Eu sou Gabriel Henrique, Data Engineer e Data Architecture em um grande banco, no segmento Wealth Management. Antes disso, cuidei por três anos dos pipelines que alimentam um CRM comercial ligado a uma operação de mais de R$ 500 milhões em receita, e fui Data Owner do catálogo de dados interno.

Nesse caminho, a ideia que mais mudou meu trabalho foi tratar cada conjunto de dados como um produto, com dono, usuários, contrato e padrão de qualidade. Neste artigo eu explico como isso funciona na prática.

O que muda quando o dado tem dono

Um pipeline sem dono quebra em silêncio. Alguém percebe três dias depois, quando o número da reunião não bate. Um produto de dados tem uma pessoa que responde por ele e sabe quem depende dele.

No catálogo de dados, eu era o desenvolvedor principal e o Data Owner. Isso significava responder a perguntas de produto, marketing e vendas sobre o que cada dataset significa, de onde vem e quando atualiza. Com 3.000+ usuários por mês, a documentação precisa estar certa, porque cada erro vira dezenas de decisões erradas.

Os cinco pilares que eu uso

1. Contrato explícito

Todo consumidor precisa saber o que vai receber: esquema, regra de negócio, horário de entrega. Hoje, no Wealth Management, eu mantenho as regras e os contratos que definem como as audiências curadas chegam ao Salesforce. Se o Lakehouse e o CRM discordam, o contrato mostra quem está certo.

2. Lógica reproduzível e auditável

As regras de segmentação de clientes Wealth traduzem estratégia comercial em filtros. Eu escrevo essas regras em código versionado, e não em consultas soltas, para que qualquer pessoa consiga rodar de novo e chegar ao mesmo resultado. Em banco, auditoria é parte do requisito.

3. Qualidade e monitoramento

Coloquei controles de qualidade e monitoramento nos pipelines para pegar falha antes do usuário. As perguntas que eu automatizo são simples: o dado chegou no horário, o volume está dentro do esperado e as colunas-chave vieram preenchidas.

4. Performance como requisito

Refatorei consultas SQL legadas e processos ELT com Apache Spark no Databricks e cortei mais de 80% do tempo de processamento. Dado que chega tarde perde valor, então trato tempo de execução como parte da entrega.

5. Ponte com o negócio

Boa parte do meu trabalho é conversa: levantar requisitos com áreas de negócio, alinhar prazos e explicar em reunião o que a engenharia vai entregar. Um pipeline tecnicamente perfeito que responde à pergunta errada não serve para ninguém.

Migração de SAS para Databricks: o produto em construção

Meu foco atual é modernizar rotinas legadas em SAS para o Databricks. A entrega vai além de traduzir código: eu desenho camadas canônicas e derivadas que o CRM legado e o Salesforce consomem ao mesmo tempo.

• Camada canônica: uma versão única e confiável de cada entidade de negócio.
• Camadas derivadas: visões prontas para cada consumidor, construídas a partir da canônica.
• Promoção por CI/CD: nada vai para produção sem passar pelo fluxo de deploy e pelos padrões internos.

Escrevi mais sobre essa stack no artigo da certificação DP-750 de Azure Databricks.

Automação também é produto

Desenvolvi um web crawler estratégico e mais de dez automações de governança com Python, Databricks, Azure e Apache Airflow. Cada uma tem a mesma regra dos pipelines: alguém responde por ela, ela é monitorada e o resultado é medido. A orquestração dessas rotinas é tema do artigo sobre autoria de DAGs no Airflow 3.

Por onde começar no seu time

1. Liste os cinco datasets mais usados e dê um dono para cada um.
2. Escreva o contrato de cada um em uma página: esquema, regra e horário.
3. Adicione três checagens automáticas: atraso, volume e nulos.
4. Meça o tempo de execução e ataque o pipeline mais lento.

Se quiser ver os projetos em que apliquei isso, o portfólio de Gabriel Henrique, Data Engineer reúne tudo, e a seção de experiência conta minha trajetória como engenheiro de dados. Sou Gabriel Henrique e escrevo aqui sobre engenharia de dados, governança e as certificações que uso no dia a dia.