De Silos a OneLake: Modernizando Data Warehouses para Microsoft Fabric com Entrega Contínua

Na maioria das corporações que dependem fortemente de dados (como Varejo, E-commerce e Saúde), a arquitetura analítica foi construída ao longo de uma década com ferramentas tradicionais. O resultado é um ecossistema frágil: rotinas pesadas de SSIS, bancos de dados transacionais sobrecarregados e silos onde cada departamento (Financeiro, Vendas, RH) possui sua própria “versão da verdade”.

Quando a diretoria de TI decide modernizar para a nuvem visando IA, escalabilidade e redução de custos (FinOps), o medo natural é a paralisação. A abordagem de migração “Big Bang” onde tenta-se reescrever tudo de uma vez para desligar o servidor antigo em uma data mágica quase sempre falha. Os relatórios de faturamento atrasam, o E-commerce perde visibilidade de estoque e o time técnico gasta madrugadas apagando incêndios. O negócio exige inovação (OneLake, Data Mesh), mas a operação transacional e a tomada de decisão diária não podem parar por um segundo.

🔍 Diagnóstico e Aprofundamento Técnico

O problema das arquiteturas legadas é a movimentação excessiva de dados. Extraímos do ERP para uma Staging Area, movemos para o DW, processamos em um Cubo (SSAS) e finalmente consumimos no Power BI. Cada salto é um ponto de falha e um custo duplicado de armazenamento.

O Microsoft Fabric, centrado no OneLake (o “OneDrive para dados”), elimina essa redundância utilizando o formato aberto Delta Parquet. Porém, a chave técnica para migrar de Procedures complexas em T-SQL para a arquitetura Medalhão no Fabric sem quebrar a empresa é a Validação Side-by-Side através de esteiras de CI/CD (Integração e Entrega Contínuas).

Abaixo, ilustro a estratégia arquitetural de paralelismo lógico que adotamos durante Sprints ágeis:

[ ARQUITETURA DE VALIDAÇÃO SIDE-BY-SIDE (ÁGIL) ]

                 (1) INGESTÃO PARALELA (Sem impacto no transacional)
[ERP / PDV] ──┬──> [ETL Legado (SSIS)] ──────> [SQL Server DW] ─────> [Power BI Legado]
              │
              └──> [Fabric Data Factory] ────> [OneLake (Bronze)] ──> [Spark/SQL (Silver/Gold)]

                 (2) CAMADA DE TESTES AUTOMATIZADOS (CI/CD)
[PySpark Data Quality Script] 
    Lê totalizadores de vendas do DW Legado
    Lê totalizadores da camada Gold do Fabric
    Compara: (Abs(Legado - Fabric) < Tolerância) -> APROVADO ✔️

Nesta abordagem, convertemos a lógica de negócio de maneira iterativa. Exemplo de validação de paridade em PySpark dentro do Fabric:

# Script de Validação de Paridade Ágil executado no final de cada Sprint
def validate_domain_parity(spark, domain_date):
    # Lendo o DW On-Premises via conector / gateway
    df_legacy = spark.read.jdbc(url=legacy_dw_url, table="Fact_Sales")                      .filter(f"DateKey = {domain_date}")                      .groupBy("StoreId").sum("TotalAmount").withColumnRenamed("sum(TotalAmount)", "LegacyTotal")
                     
    # Lendo a nova camada Gold (Delta) no OneLake
    df_fabric = spark.read.format("delta").load("abfss://workspace@onelake/Gold.lakehouse/Tables/FactSales")                      .filter(f"DateKey = {domain_date}")                      .groupBy("StoreId").sum("TotalAmount").withColumnRenamed("sum(TotalAmount)", "FabricTotal")
                     
    # Join e validação de desvios
    df_comparison = df_legacy.join(df_fabric, "StoreId")                              .withColumn("Variance", abs(col("LegacyTotal") - col("FabricTotal")))
                             
    if df_comparison.filter(col("Variance") > 0.01).count() > 0:
        raise Exception("❌ Falha de Paridade: Regra de negócio divergente entre Legado e Fabric.")
    else:
        print("✅ Paridade Validada com Sucesso para o Domínio de Vendas.")

🛠️ A Visão de Solução Arquitetural

Como líderes técnicos, nosso papel é mitigar o risco e fatiar o elefante. A transição para o Microsoft Fabric utilizando métodos ágeis deve seguir um fluxo de Modernização por Domínio:

1. Seleção Estratégica (MVP): Não começamos migrando o complexo fechamento contábil. Escolhemos um domínio analítico de alto impacto, mas de menor dependência cruzada, por exemplo, a análise de metas diárias de vendas do varejo.
2. Ciclos Curtos e Entregas Contínuas: Em sprints de 2 a 3 semanas, a equipe de engenharia mapeia o legado, constrói a ingestão via Fabric Pipelines, cria as transformações Medalhão (Bronze, Silver, Gold) via Notebooks/Spark ou Stored Procedures (Synapse DW), e constrói o novo painel Direct Lake.
3. Shadow Mode e Switch-Over: O novo painel roda em “shadow mode” (modo oculto) em paralelo com o antigo. Ferramentas de validação atestam a veracidade dos dados. Assim que o Business Owner aprova a precisão e a nova performance, fazemos o switch-over de leitura daquele domínio, desativando o pipeline legado correspondente.

Essa engenharia reversa executada de forma ágil converte um projeto de risco catastrófico em uma série de pequenas vitórias. O OneLake unifica o dado, o processo ágil garante a continuidade dos negócios, e a organização absorve a cultura de dados modernos gradativamente, justificando o ROI do projeto mês a mês para os executivos.