A Armadilha do "Frankenstein" de Dados: Quando a Complexidade Vira Inimiga da Eficiência

Michel Souza Santana
7 de abr.
11 min de leitura

A Armadilha do "Frankenstein" de Dados: Quando a Complexidade Vira Inimiga da Engenharia

Existe uma confusão recorrente na engenharia de dados moderna: associar complexidade com maturidade técnica.

Na prática, quanto mais experiente o time, mais simples tende a ser a arquitetura.

Mas o que vemos em muitos projetos, principalmente em ambientes cloud modernos, é o oposto: uma sobreposição de ferramentas que cria um ecossistema difícil de operar, difícil de evoluir e, principalmente, difícil de explicar.

Esse fenômeno eu chamo de "Frankenstein de Dados".

Sabe aquele momento em que você entra em um projeto e, ao abrir o diagrama de arquitetura, sente um frio na espinha? Já passei por situações onde, para mover um dado de um ponto A para um ponto B, a solução parecia um quebra-cabeça de mil peças: um orquestrador aqui, uma ferramenta de transformação acolá, um plugin de terceiros conectado por "gambiarra" em uma plataforma que já fazia tudo isso nativamente.

Diferença entre ser um profissional que domina diversas ferramentas e ser alguém que cria "Frankensteins"

No dia a dia da engenharia de dados, existe uma linha muito tênue entre ser um profissional que domina diversas ferramentas e ser alguém que cria "Frankensteins" tecnológicos. Recentemente, tenho observado um padrão curioso e um tanto preocupante em ambientes 100% baseados em Databricks: a insistência em plugar ferramentas externas para funções que a própria plataforma já resolve de forma integrada.

O ponto central aqui não é uma crítica ao dbt ou ao Airflow , ferramentas fantásticas em seus domínios. A provocação é sobre contexto e eficiência.

Tenho observado um padrão preocupante: times que utilizam o Databricks, mas insistem em instalar ferramentas dentro de um cluster ou configurar instâncias de Airflow para gerenciar o que a plataforma já faz de forma integrada.

Ao fazer isso, você cria três problemas imediatos:

Bitributação de Recursos: Você continua pagando pelas DBUs (unidades de processamento) do Databricks para manter um cluster ligado, mas o utiliza apenas como um "hospedeiro" para rodar uma ferramenta externa. Você não elimina custos; você os mascara sob uma camada de gerenciamento extra.
Cegueira Tecnológica: Quando você roda um processo via ferramenta externa dentro do cluster, você frequentemente perde a telemetria nativa. O Unity Catalog e o Query Profile brilham quando entendem o contexto da execução. Ao "esconder" a lógica dentro de um runner externo, você quebra a linhagem e a observabilidade automática.
Acoplamento Distribuído: Você não tem uma arquitetura modular; você tem peças que não se falam nativamente, exigindo "gambiarras" de autenticação e conexões via JDBC/ODBC que adicionam latência e pontos de falha desnecessários.

Este artigo não é uma crítica às ferramentas.

É uma provocação sobre contexto.

A Evolução do Databricks

Nos últimos meses, acompanhando a evolução do Databricks, uma coisa tem ficado cada vez mais clara:

A plataforma está caminhando rapidamente para se tornar um ecossistema cada vez mais completo e, principalmente, cada vez mais independente.

Se antes precisávamos compor uma stack com múltiplas ferramentas para cobrir todo o ciclo de dados, hoje vemos o Databricks avançando exatamente no sentido oposto: convergência de capacidades dentro de uma única plataforma.

E isso não é apenas percepção é movimento claro de produto.

Hoje você já consegue cobrir praticamente todo o ciclo de dados dentro do próprio Databricks:

Ingestão com Lakeflow Connect
Transformação com Lakeflow Declarative Pipelines (Spark)
Orquestração com Workflows
Governança e lineage com Unity Catalog
Qualidade de dados com Delta Live Tables
Deploy com Asset Bundles

Ou seja, aquilo que antes exigia a composição de várias ferramentas externas, agora começa a existir de forma nativa, integrada e, principalmente, com contexto compartilhado.

Plataformas modernas evoluíram para a convergência. Se o seu processamento principal está no Databricks, faz sentido questionar por que distribuir responsabilidades fora dele.

Orquestração: Por que gerenciar um servidor de Airflow, lidar com providers desatualizados e latência de rede se o Databricks Workflows oferece orquestração nativa, reparo de tarefas específicas e integração profunda com o Unity Catalog?
Transformação e Qualidade: O uso do dbt brilha em ambientes multi-plataforma. Mas se você está 100% em Databricks, o Delta Live Tables (DLT) oferece testes inline (expectations), execução integrada e monitoramento de qualidade sem a necessidade de um runner externo.
Deploy: O Databricks Asset Bundles (DABs) permite tratar toda a infraestrutura e jobs como código, integrando-se ao CI/CD de forma muito mais fluida do que tentar plugar orquestradores externos em pipelines de execução interna

Quando você tem:

Airflow orquestrando jobs
dbt fazendo transformações
Databricks executando processamento
mais uma camada de CI/CD externa
e integrações customizadas entre tudo isso

Você não tem uma arquitetura moderna.

Você tem acoplamento distribuído.

Essa fragmentação traz impactos técnicos reais e mensuráveis.

1. Perda de Linhagem e Governança

Governança parcial é governança inexistente. Quando você fragmenta o fluxo entre Airflow, dbt e Databricks, a linhagem de dados (lineage) fica com "buracos". O Unity Catalog perde o rastro do dado no momento em que a lógica sai do controle nativo da engine.

2. Custo Cognitivo e Operacional

Um engenheiro novo precisa aprender a gerenciar o cluster, as DAGs do Airflow, as macros do dbt e a integração entre eles. Times fortes não são os que usam mais ferramentas, mas os que reduzem a superfície de ataque da complexidade.

3. O Dilema do Vendor Lock-in vs. Eficiência

É justo argumentar que o uso de ferramentas externas evita o vendor lock-in. No entanto, essa "liberdade" tem um preço alto: o custo da ineficiência diária. Vale a pena pagar mais caro e ter uma operação mais frágil hoje para uma hipotética migração amanhã? Arquiteturas maduras equilibram esse risco sem sacrificar a performance.

Times fortes não são aqueles que usam muitas ferramentas. São aqueles que reduzem a superfície de complexidade.

Arquitetura não é sobre ferramentas. É sobre distribuição clara de responsabilidades.

O Orquestrador do Orquestrador: Airflow vs. Databricks Workflows

Lembro que, há alguns anos, o Apache Airflow era a resposta para quase tudo. E não me entenda mal, ele é uma ferramenta fantástica. Mas o cenário mudou.

Quando atuamos em um ambiente totalmente voltado para Cloud com Databricks, vejo muitos times gastando horas configurando instâncias de Airflow, gerenciando conexões via DatabricksSubmitRunOperator e lidando com latências de rede e autenticação externa. A pergunta que eu sempre faço é: Para quê?

O Databricks Workflows evoluiu drasticamente. Hoje, ele oferece:

Orquestração nativa com baixa latência.
Reparo de tarefas específicas sem precisar rodar a DAG inteira.
Integração profunda com o Unity Catalog para linhagem de dados.
Processamento: Spark + Delta
Governança: Unity Catalog
Deploy: Asset Bundles
Qualidade de dados: Delta Live Tables

Plataformas como o Databricks evoluíram justamente para resolver esse problema.

Hoje, você tem tudo isso dentro de um único ecossistema.

Isso não é coincidência.

É uma tendência clara: convergência de capacidades dentro da mesma plataforma.

Quando você opta pelo nativo, você elimina uma camada de gerenciamento de infraestrutura. Não precisa se preocupar se o Worker do Airflow caiu ou se a versão do provider está desatualizada. Você ganha tempo para focar no que realmente importa: a qualidade do dado.

O erro mais comum que vejo é:

“Sempre usamos Airflow e dbt, então vamos continuar usando.”

Isso é um viés de decisão baseado em histórico, não em arquitetura.

Arquitetura moderna deve responder:

Onde está o processamento principal?
Quem é o “source of truth” operacional?
Onde a governança precisa estar centralizada?

Se a resposta for Databricks, então faz sentido questionar:

Por que distribuir responsabilidades fora dele?

O Dilema do DBT: Precisamos mesmo de mais uma camada?

Este é um ponto polêmico, mas necessário. O dbt (data build tool) é uma ferramenta incrível para SQL-first engineers. No entanto, quando instalamos o dbt dentro de um ambiente Databricks ou forçamos seu uso em um ecossistema que já possui o Databricks Asset Bundles (DABs) e o Delta Live Tables (DLT), estamos criando uma redundância técnica.

O dbt brilha em:

Modelagem SQL declarativa
Padronização de transformações
Testes versionados

Mas em ambientes Databricks, você já possui:

Delta Live Tables (DLT)
Notebooks versionados
Asset Bundles
Expectations nativas

Em muitos cenários dentro do Databricks, parte significativa do que o dbt resolve já pode ser atendida por funcionalidades nativas, o que levanta a necessidade de avaliar se a camada adicional realmente agrega valor naquele contexto.

Eu já vi cenários onde o desenvolvedor instalava o dbt-core em um cluster para rodar transformações que o DABs faria de forma muito mais fluida. O Databricks Asset Bundles permite que você trate toda a sua infraestrutura, jobs, notebooks e testes como código, integrando-se perfeitamente ao seu pipeline de CI/CD via Git/Github.

No modelo tradicional (dbt):

Teste separado do processamento
Execução desacoplada
Dependência de runner externo

No modelo com DLT:

Teste inline
Execução integrada
Observabilidade automática

Isso reduz:

Latência de feedback
Complexidade de execução
Pontos de falha

Exemplo Prático: A simplicidade do nativo

Imagine que você precisa validar se uma coluna de "ID_CLIENTE" é nula antes de carregar a camada Gold. No dbt, você criaria um arquivo .yml de teste. No Databricks, usando Delta Live Tables, você resolve isso com uma expectativa (Constraint) diretamente no código:

Python

import dlt
from pyspark.sql.functions import col

@dlt.table(
  comment="Limpeza de dados de clientes",
  table_properties={"quality": "gold"}
)
@dlt.expect_or_drop("valid_id", "customer_id IS NOT NULL")
def processed_customers():
    return dlt.read("raw_customers").filter(col("active") == True)

O resultado? Você tem o teste, a transformação, a linhagem de dados e a monitoração de qualidade em um único lugar, sem precisar de uma ferramenta externa para "orquestrar" o SQL. É elegante, é performático e, acima de tudo, é simples de manter.

Quando Faz Sentido Usar Ferramentas Externas

Seria hipocrisia minha dizer que ferramentas externas nunca devem ser usadas. O equilíbrio é a chave.

Ferramentas externas são aliadas quando:

Arquitetura Híbrida/Multi-cloud: Você processa dados no Databricks, mas também no BigQuery ou Snowflake.
Padronização Organizacional: O Airflow já é o cérebro de todas as áreas da empresa (Marketing, RH, Financeiro), não apenas da Engenharia de Dados.
Legado de Alto Risco: O custo de migração para o nativo traria um risco operacional proibitivo no curto prazo.

Nesse caso, coexistência faz mais sentido que ruptura.

Existe um princípio simples que deveria guiar qualquer arquitetura:

Minimize o número de sistemas responsáveis pelo mesmo problema.

Se duas ferramentas fazem a mesma coisa:

Você não ganha redundância
Você ganha ambiguidade

E ambiguidade em engenharia de dados vira:

bugs difíceis
troubleshooting lento
perda de confiança no dado

Se o seu "playground" é 100% Databricks, o meu conselho de quem já quebrou muita cabeça com isso é: explore o potencial máximo do que a plataforma oferece antes de buscar fora.

Existe uma fase na carreira onde o engenheiro quer provar que domina ferramentas.

Depois de um tempo, ele percebe:

O verdadeiro domínio está em remover complexidade desnecessária.

Arquiteturas maduras têm:

menos componentes
mais coesão
maior previsibilidade

O "Frankenstein de Dados" não nasce de más decisões isoladas.

Ele nasce de boas ferramentas usadas fora de contexto.

O ponto não é abandonar ferramentas maduras como dbt ou Airflow. É evitar usá-las fora de contexto, especialmente quando são encaixadas dentro de uma plataforma que já resolve, de forma nativa, a maioria ou o mesmo problema.

Arquitetura madura não é sobre quantas ferramentas você usa. É sobre quão claro está o papel de cada uma.

Por que fugir da "Reinvenção da Roda"?

Manter uma stack inchada traz custos ocultos que muitas vezes não aparecem no primeiro mês de projeto, mas que cobram o preço no longo prazo:

Custo de Manutenção: Cada ferramenta extra exige atualização de versão, patches de segurança e monitoramento próprio.
Curva de Aprendizado: Novos membros do time precisam aprender cinco ferramentas diferentes em vez de dominarem profundamente uma plataforma robusta.
Linhagem Quebrada: Quando você fragmenta o processo (Airflow -> dbt -> Databricks), a linhagem de dados (data lineage) muitas vezes se perde ou fica "buraco", dificultando a governança e o data quality.
Latência de Desenvolvimento: O ciclo de "codar, testar e deployar" fica mais lento devido às integrações entre as peças do Frankenstein.

O Elefante na Sala: A Realidade dos Custos (FinOps)

Não podemos ser hipócritas: adotar Delta Live Tables (DLT) e Databricks Asset Bundles (DABs) tem um custo, e muitas vezes o valor da DBU (Databricks Unit) para DLT é superior ao de um job comum. No entanto, a análise de custo real não deve ser feita apenas no valor unitário da DBU, mas no TCO (Custo Total de Propriedade).

1. O Custo Oculto da "Ferramenta Externa no Cluster"

Quando você decide rodar o dbt-core ou um orquestrador externo dentro de um cluster Databricks, você está pagando por um "hospedeiro" caro.

Idle Time (Tempo de Inatividade): Você mantém instâncias EC2/Azure VM ligadas para sustentar o ambiente da ferramenta externa, muitas vezes pagando por memória e CPU que a ferramenta não consome totalmente.
Double Billing: Você paga a licença da nuvem + a DBU do Databricks para, no final das contas, rodar um processo que ignora as otimizações de Photon ou Serverless da plataforma.
Manutenção Humana: O tempo que seu engenheiro sênior gasta corrigindo versões de bibliotecas Python no cluster para o dbt não quebrar é um custo invisível, mas altíssimo.

2. DLT e Serverless: Pagando pela Entrega, não pela Infra

O DLT, especialmente em modalidades Serverless, elimina o desperdício. Você paga exatamente pelo processamento do dado.

Auto-scaling Inteligente: O DLT gerencia o escalonamento de forma muito mais agressiva e precisa do que um cluster comum rodando dbt.
Otimização de Performance: Por ser nativo, o DLT utiliza o motor Photon de forma otimizada, o que pode reduzir o tempo de execução. Se um job roda em 10 minutos no DLT e 20 minutos no dbt "espetado" via JDBC, o custo final do DLT pode ser menor, mesmo com uma DBU mais cara.

3. A Balança do Custo-Benefício

Para decidir o que vale a pena, a pergunta não é "qual DBU é mais barata?", mas sim:

Critério	Ferramenta Externa no Cluster	DLT / Nativo
Infraestrutura	Você gerencia e paga pelo "aluguel" do cluster.	O Databricks gerencia; você paga pelo uso.
Observabilidade	Exige ferramentas extras (custo extra).	Nativa e gratuita (incluída na plataforma).
Complexidade	Alta (integrações, drivers, conexões).	Baixa (configuração única e fluida).
Escalabilidade	Manual ou reativa (lenta).	Automática e granular.

Veredito Financeiro

No final, não sai a mesma coisa. Rodar uma ferramenta externa dentro do Databricks é como alugar uma suíte de luxo apenas para usar o Wi-Fi e trabalhar no notebook: você está pagando por uma estrutura nobre para realizar uma tarefa que não usufrui dela.

Se você busca portabilidade absoluta (multi-cloud), o custo extra de uma ferramenta externa pode ser um "seguro". Mas se o seu objetivo é eficiência operacional e performance no Databricks, o investimento no nativo se paga pela redução do tempo de desenvolvimento e pela eliminação do desperdício de infraestrutura ociosa.

Este tópico traz o equilíbrio necessário, admitindo que o DLT tem seu preço, mas expondo a ineficiência financeira de manter "Frankensteins" ligados.

Conclusão: O Valor Real está na Simplicidade

Ao longo da minha jornada, percebi que a sofisticação técnica não reside na quantidade de ícones que você consegue colocar em um diagrama de arquitetura, mas em quão eficiente e resiliente sua solução consegue ser com o menor número de peças móveis possível.

O "Frankenstein de Dados" não nasce de uma má intenção. Ele nasce do desejo de usar o que há de melhor no mercado, mas sem considerar o custo da fragmentação. Quando você tem o Unity Catalog para governança, o Workflows para orquestração e o Lakeflow para ingestão e transformação, você tem uma Ferrari nas mãos. Tentar acoplar motores externos por mero costume não é apenas redundante; é uma ineficiência financeira e operacional.

O Desafio da Engenharia Moderna

A evolução do Databricks para um ecossistema independente e declarativo nos força a repensar o papel do Engenheiro de Dados. Nosso valor não está mais em "codar" integrações entre ferramentas que não se falam, mas em:

Garantir a qualidade e a linhagem do dado de ponta a ponta.
Otimizar o TCO (Custo Total), trocando a manutenção de infraestrutura ociosa por performance nativa.
Reduzir o "Time-to-Value", entregando produtos de dados em semanas, não meses.

Minha provocação para você hoje é: Olhe para o seu pipeline atual com olhar crítico de FinOps e Arquitetura. Existe algum componente que está ali apenas por "costume" ou porque "todo mundo usa", enquanto sua plataforma principal já resolve o problema de forma nativa e integrada?

Às vezes, o maior salto de maturidade de um time não é adicionar a ferramenta do momento, mas ter a coragem de remover a complexidade desnecessária.

E você? Está construindo ecossistemas coesos ou alimentando um Frankenstein? Vamos conversar nos comentários.