A Evolução do ETL tradicional: Como iniciar a transição e descentralizar o domínio de dados com Data Mesh

Na maioria das grandes corporações, especialmente em setores dinâmicos como o Varejo e em ambientes regulados como os seguimentos de Saúde Suplementar e Segurado, a arquitetura de dados cresceu em torno de um modelo estritamente centralizado. O fluxo é clássico: as áreas de negócio geram dados em seus ERPs, PDVs e prontuários; a equipe central de Engenharia de Dados extrai, transforma e carrega (ETL) essas informações em um Data Warehouse ou Data Lake monolítico.

O impacto operacional desse modelo na escala atual das empresas é severo. A equipe de dados torna-se um funil corporativo. Quando o time de Varejo Farmacêutico precisa integrar uma nova campanha de descontos, ou a área de Saúde precisa de um novo painel de conformidade regulatória da ANS, essas demandas caem no mesmo backlog. A falta de contexto de negócio por parte da equipe técnica gera retrabalho, pipelines frágeis e o mais crítico: um tempo de resposta (time-to-market) inaceitável para a tomada de decisão estratégica, resultando em perda de competitividade e altos custos de manutenção de silos isolados.

🔍 Diagnóstico e Aprofundamento Técnico

O problema raiz reside no acoplamento entre a infraestrutura de dados e a semântica do negócio. No modelo de ETL tradicional, um pipeline longo e monolítico é responsável por ingerir, limpar e modelar dados de domínios totalmente distintos.

Quando uma regra de negócio muda na ponta (ex: a forma como um imposto é calculado no PDV), o pipeline central quebra. A manutenção é lenta e arriscada.

Para ilustrar o contraste, vejamos como um modelo tradicional agrupa tudo em um único job monolítico, versus uma abordagem descentralizada (orientada a domínio):

# ❌ Abordagem Tradicional Monolítica (Gargalo Central)
# Um único script/job tenta processar regras de Vendas, RH e Logística
def process_corporate_data(spark):
    df_sales = spark.read.table("raw.sales").filter("status = 'CONFIRMED'")
    df_hr = spark.read.table("raw.employees").filter("active = true")
    
    # Mistura de contextos e regras de negócios no mesmo pipeline
    df_unified = df_sales.join(df_hr, "employee_id")
    df_unified.write.mode("overwrite").saveAsTable("dw.corporate_monolith")

# ✅ Abordagem Orientada a Domínio (Primeiro passo para o Data Mesh)
# Cada domínio (ex: Vendas) encapsula sua própria lógica e expõe o dado como Produto
class SalesDataProduct:
    def __init__(self, spark_session):
        self.spark = spark_session
        
    def generate_sales_gold_layer(self):
        # O time de Vendas, que entende do negócio, mantém esta regra
        df_raw = self.spark.read.table("domain_sales_bronze.transactions")
        df_clean = self.apply_domain_business_rules(df_raw)
        
        # Publica o "Data Product" para que outros domínios consumam
        df_clean.write.mode("overwrite").saveAsTable("domain_sales_gold.vw_daily_revenue")

Nesse cenário de arquitetura legada (SSIS antigos, procedures T-SQL monolíticas de milhares de linhas), qualquer tuning de performance ou troubleshooting de contenção (deadlocks) torna-se um pesadelo, pois o banco de dados transacional e o analítico estão frequentemente competindo pelos mesmos recursos em janelas de processamento cada vez menores.

🛠️ A abordagem descentralizada: Solução Arquitetural

A solução para escalar operações de dados corporativas atende pelo nome de Data Mesh. Em vez de focar apenas em tecnologias modernas, o Data Mesh é uma mudança sociotécnica baseada em quatro pilares fundamentais: Propriedade orientada a domínio, Dados como Produto, Plataforma de dados self-service (Autoatendimento) e Governança federada.

O Caminho Híbrido e Seguro para a Migração: Para não paralisar a operação, a transição deve ser iterativa:

1. Definição de Domínios e Data Products: Identificamos as áreas mais maduras (ex: E-commerce ou Financeiro). Em vez de engenheiros centrais, empoderamos desenvolvedores dentro dessas verticais para criar seus próprios pipelines.
2. Plataforma Self-Service (O papel da Engenharia Central): O time de engenharia “deixa de escrever” ETL de negócio e passa a fornecer infraestrutura. Utilizando ecossistemas modernos como o Microsoft Fabric, podemos configurar Workspaces isolados por domínio operando sob o conceito do OneLake unificado, eliminando cópias desnecessárias de dados.
3. Governança Federada: Implementamos políticas automatizadas na camada arquitetural (ex: mascaramento de PII em dados, regras de acesso) que garantem a segurança sem estrangular o acesso.

Essa arquitetura descentralizada elimina dependências manuais, reduz drasticamente o OpEx com refatoração constante de pipelines quebrados e democratiza a inteligência de negócios. A liderança de TI passa a entregar uma plataforma confiável onde as áreas de negócio têm autonomia para gerar seus próprios relatórios com dados auditados e performáticos, alavancando de forma tangível a receita e a eficiência operacional da companhia.