O "modern data stack" ainda é uma ideia útil?
Vendors e profissionais de dados estão questionando cada vez mais se o “modern data stack” — um conjunto vagamente definido de ETL em nuvem, warehouses, ferramentas de transformação como dbt e plataformas de BI — alguma vez entregou valor suficiente para justificar seu custo e complexidade. Os comentaristas descrevem um ecossistema movido por hype que empurrou stacks fragmentados e pesados em SaaS para empresas que muitas vezes não tinham objetivos claros de analytics, boas práticas de engenharia ou uma contabilidade realista de custos, levando muitos a reconsiderar plataformas integradas ou soluções sob medida construídas por engenheiros experientes. O consenso emergente é que as escolhas de ferramentas devem ser guiadas por necessidades concretas de negócio, escala e práticas de observabilidade, e não por termos de marketing como “modern”, com alguns prevendo uma mudança para “analytics stacks” mais simples e mais integrados.
Utilidade do “Modern Data Stack” (MDS) como Conceito
- Muitos veem “MDS” como um termo da moda que perdeu o significado depois de ser apropriado por vendors e VCs.
- Críticas: mal definido, “modern” envelhece rapidamente, ressoou principalmente com investidores e analistas, não com praticantes.
- Alguns argumentam que o rótulo ajudou no marketing e nos ecossistemas de parceiros, mas acrescentou pouco valor descritivo.
Abordagens Pesadas em Vendors vs Integradas/Sob Medida
- Crítica forte de que o MDS multivendor criou complexidade desnecessária e gastos altos (por exemplo, várias ferramentas só para executar pipelines simples).
- Visão de que as empresas agora preferem plataformas integradas ou construir internamente, especialmente quando percebem que contratar alguns engenheiros pode ser mais barato do que empilhar muitos produtos SaaS.
- Contraponto: ferramentas modulares de “escolha seu stack” dão flexibilidade, evitam lock-in e permitem que as equipes adaptem os componentes; sistemas integrados “tudo em um” muitas vezes são desajeitados.
- Consenso de que a resposta certa depende do contexto (tamanho da empresa, habilidades, requisitos).
dbt e a Stack de Analytics
- Amplamente reconhecido como um grande avanço para organizar SQL: controle de versão, DAGs, testes, documentação, ganchos de CI/CD.
- Também criticado por ser lento e desajeitado em comparação com ferramentas de dataframe, por não ter um ótimo IDE local e por se tornar difícil de gerenciar em escala (centenas+ de modelos).
- Alguns veem o dbt como mais adequado para transformações de “last-mile”, não para lidar com dados brutos e bagunçados.
Práticas de Engenharia de Software vs Engenharia de Dados
- Muitos argumentam que a área de dados está uma década atrás da engenharia de software padrão em CI/CD, testes, observabilidade e disciplina de deploy.
- Outros dizem que os problemas centrais são na verdade os mesmos da SWE em geral: gerenciamento de dependências, mudanças de contrato, monitoramento e tratamento de erros.
- Uma corrente enfatiza desafios específicos de dados: schemas e distribuições mudam sem mudanças no código; o controle de versão não é o único gate do comportamento do sistema.
Coleta de Dados, Custos e Over-Instrumentation
- Debate entre “meça tudo” vs coleta guiada por hipóteses.
- Alguns justificam ingestão ampla quando o armazenamento e as exportações nativas são baratos e exigem pouco esforço.
- Outros destacam custos ocultos: tempo de engenharia, manutenção de conectores, contas das ferramentas MDS e custo de oportunidade, argumentando que muitos pipelines existem sem perguntas de negócio claras ou ROI.
Como é um Stack “Modern” na Prática
- Os stacks sugeridos variam de pesados (Kafka, Flink, Iceberg, Spark/Ray, ferramentas de metadata) a muito simples (BigQuery + dbt + BI básico; ou até MySQL + file server + relatórios simples).
- Conselho comum: mantenha o mais simples possível, combine as ferramentas com necessidades concretas e evite correr atrás de tendências por currículo ou hype.