A maioria dos artigos sobre stack moderna de arquitetura de dados começa pelas ferramentas. Todo projeto que tocamos começa em outro lugar: nas suas fontes e nos seus outputs. A arquitetura segue os dados, não o contrário.
O que vem a seguir são as decisões de engenharia que realmente fazem diferença. Não os conceitos, mas os tradeoffs: onde as coisas quebram, o que aguenta pressão e como evitar os erros que afundam projetos de dados em silêncio, muito antes de eles chegarem a um dashboard.
Comece pelos outputs e pelas fontes, não pelas ferramentas
A primeira coisa que definimos em qualquer projeto de dados é um exercício de duas colunas:
- Quais decisões de arquitetura de dados você precisa tomar mais rápido ou com mais qualidade? (outputs)
- Onde os dados que alimentam essas decisões realmente estão? (fontes)
Toda a stack decorre da resposta a essas duas perguntas.
Parece óbvio, mas é fácil pular essa etapa. Os times se empolgam com BigQuery, Databricks ou dbt e começam a desenhar a infraestrutura antes de mapear o que, afinal, querem enxergar. O resultado é uma plataforma que pode até ser best in class, mas não resolve o que o negócio precisa.
Antes de recomendar qualquer ferramenta, nós documentamos os outputs de analytics desejados: dashboards, relatórios ou decisões específicas. Depois percorremos o caminho de volta até os sistemas de origem. Tudo o que existe entre um ponto e outro é encanamento.
O tipo de fonte de dados mais difícil é também o mais comum: planilhas
Quando fazemos esse caminho de volta até as fontes, quase sempre encontramos planilhas.
Os dados de finanças moram em uma planilha. O custo por pessoa mora em uma planilha. E aquele relatório semanal de alocação que alguém roda toda segunda-feira? Uma planilha, que puxa de outra planilha, ligada a uma terceira por um PROCV que quebra toda vez que alguém muda o nome de uma coluna.
Planilha não é um ponto de partida ruim. É um estado permanente ruim.
Trate planilhas como uma ponte, não como fonte da verdade. Dá para conectar o Google Sheets direto ao BigQuery com conectores nativos. Funciona, e permite subir seus primeiros modelos e levar dados para o data warehouse sem mexer no fluxo de trabalho que já existe. Só que essas conexões são frágeis: credenciais expiram, nomes de colunas mudam, alguém apaga uma linha que não devia. Reserve tempo de manutenção e planeje a substituição delas.
Antes de conectar qualquer coisa, pergunte: a planilha é mesmo a fonte, ou existe um sistema a montante que alguém transcreve na mão para dentro dela? Essa é uma das perguntas mais valiosas para levantar logo no início. Se alguém do financeiro digita dados de salário em uma planilha uma vez por mês, você vai ganhar muito mais estabilidade indo direto ao sistema de folha de pagamento ou ao HRIS que alimenta essa pessoa, mesmo que isso exija um conector customizado. Uma API estável sempre ganha de uma planilha manual.
O objetivo é migrar a lógica, não só os dados. Planilhas carregam regras de negócio: cálculo de margem, conversão de câmbio, fórmulas de rateio. Quando você move tudo para o data warehouse, essas regras precisam ir junto e passar a viver nos modelos da sua arquitetura de dados. A pessoa que é dona do processo da planilha é o recurso mais valioso que você tem durante essa migração: é ela quem sabe onde estão os casos de exceção.
Escolhendo seu data warehouse: a decisão depende do seu contexto
A discussão BigQuery vs. Snowflake vs. Databricks já rendeu muita tinta. Nossa visão vem do que observamos nas empresas com quem trabalhamos.
O BigQuery é o default certo para a maioria das empresas de mid-market e em fase de crescimento, principalmente se você já está no ecossistema Google. A cobrança por consumo mantém o custo perto de zero até você começar a mover volume de verdade. A integração nativa com o Google Sheets reduz o atrito do lado das fontes. E o free tier, somado aos créditos para startups, facilita validar antes de se comprometer com qualquer coisa.
O tradeoff: o BigQuery é poderoso, mas relativamente bare metal quando comparado às plataformas all-in-one. Você vai combiná-lo com outras ferramentas: Airbyte para ingestion, dbt para transformação e uma camada de BI separada. Essa composabilidade é uma vantagem para times com capacidade de engenharia, e um custo extra para quem não tem.
Snowflake e Databricks fazem mais sentido quando você lida com volumes muito altos de dados, cargas de machine learning ou casos de uso de lakehouse: telemetria de produto, dados em streaming e conteúdo não estruturado. As duas são plataformas excelentes, mas ambas têm custo de entrada mais alto e tendem a compensar apenas a partir de volumes contratados maiores, quando o preço fica competitivo.
Vale avaliar o Databricks quando seus dados incluem conteúdo não estruturado em alto volume junto com dados operacionais estruturados. O lakehouse unificado simplifica bastante a arquitetura para empresas que, de outra forma, precisariam gerenciar um data lake e um data warehouse separados, em paralelo.
Sobre o Microsoft Fabric: recomendamos se você já roda dentro do ecossistema Microsoft. Se a sua organização está padronizada em Azure, o time trabalha na toolchain da Microsoft e os dados ficam nesse ambiente, o Fabric é uma escolha legítima e a tecnologia é sólida. A ressalva não é com a plataforma em si, e sim com adotá-la fora desse contexto.
Leia também: Como migrar dados de usuários de apps nativos para cross-platform
Ingestion: Airbyte primeiro, Fivetran quando se justifica, conectores customizados mais vezes do que você imagina
O Airbyte é por onde você começa. Open source, centenas de conectores nativos, custo de entrada baixo, comunidade ativa. A versão cloud acrescenta infraestrutura gerenciada com preço por uso, acessível o suficiente para trabalho de dados em estágio inicial e escalável para planos por capacidade conforme os pipelines crescem. Se um conector não existe de forma nativa, dá para escrever um customizado em Python sem muito esforço.
O Fivetran tem a melhor confiabilidade de conectores do mercado, mas o modelo de preço ficou bem mais caro em março de 2025. A empresa passou a cobrar MAR (Monthly Active Rows) por conector, e não mais por conta, o que eliminou os descontos por volume que antes tornavam viáveis os setups com muitas fontes. Times com várias integrações estão relatando aumentos de custo de 40% a 70% por causa disso.
As cargas iniciais continuam gratuitas; tudo o que é incremental é medido por conector. Use quando confiabilidade for inegociável e o orçamento estiver claramente disponível, mas faça as contas com o seu número real de conectores antes de fechar.
Conectores customizados em Python são subestimados. Se você tem um punhado de sistemas de origem específicos e capacidade de engenharia para manter scripts Python enxutos, esse costuma ser o caminho mais econômico no longo prazo. Também cria ownership interno do fluxo de dados, o que faz diferença quando algo quebra às 2h da manhã. Combine os conectores customizados com o Airflow para orchestration: open source, bem documentado e flexível o bastante para a maioria das necessidades de agendamento e dependências.
O framework prático: Airbyte para fontes SaaS padrão. Conectores nativos do data warehouse na nuvem quando existirem e a fonte for de alta frequência. Conectores customizados para sistemas internos de nicho ou proprietários. Fivetran só quando os requisitos de confiabilidade e o orçamento apontarem na mesma direção.
A arquitetura medallion na prática: bronze é de graça, o trabalho está na silver
A estrutura de três camadas, bronze (bruta), silver (limpa e com joins) e gold (pronta para o negócio), é o framework certo. Do ponto de vista de engenharia, na prática, ela funciona assim:
A bronze é só um despejo. Tabelas cruas das suas fontes, sem transformação. Você nunca faz query direto na bronze para analytics. O trabalho dela é existir e ser imutável. Se algo der errado lá na frente, você reconstrói a partir da bronze sem precisar extrair tudo da fonte de novo. Guarde tudo.
A silver é onde a engenharia de verdade acontece. É aqui que você define o que significa “cliente” no modelo da sua arquitetura de dados. Onde a lógica de conversão de câmbio, que antes vivia em uma planilha, agora vive em um modelo dbt. Onde dados de alocação e de custo se juntam em uma visão limpa e confiável da margem por projeto. A camada silver precisa ser estruturada o bastante para responder à maioria das perguntas, mas não tão agregada a ponto de prender você a um único caso de uso.
Tem uma coisa importante sobre a camada silver que quase nunca é dita: ela também é a sua camada de IA. Quando você coloca em produção pipelines de RAG, workflows agênticos ou qualquer automação baseada em LLM, o ideal é que os modelos busquem contexto em dados limpos e governados da silver, e não batam direto nos sistemas de origem. APIs de origem têm rate limit.
O dado da fonte tem ruído. O dado da silver já foi limpo, cruzado e ganhou contexto de negócio. É disso que um modelo precisa para gerar respostas confiáveis. Construir a camada silver pensando em acesso por IA desde o primeiro dia significa não ter que reconstruí-la quando os casos de uso de Inteligência Artificial chegarem.
A gold é para stakeholders específicos. Data mart de vendas. Data mart de finanças. Data mart de operações. São visões altamente estruturadas e agregadas, que respondem a perguntas conhecidas e recorrentes. Construa depois que a camada silver estiver estável. Não crie gold para todo caso de uso possível logo de cara: é assim que você acaba com marts desatualizados que ninguém usa.
Leia também: Product Framework: fallback de modelo e estratégia de precificação de IA para decisões melhores
O dbt é a camada de transformação, e também a camada de governança
Assim que os dados começam a chegar no data warehouse, você precisa de uma camada de modelagem. O dbt foi onde a comunidade de engenharia de dados convergiu, e com razão.
O dbt Core (gratuito e open source) dá conta da maioria dos projetos. Você escreve modelos em SQL, roda pela CLI e ganha uma lógica de transformação limpa, versionada e testável. Se o seu time de engenharia se vira bem no terminal, o Core resolve 90% do caminho.
O dbt Cloud acrescenta a camada visual de DAG: linhagem gráfica, uma interface para rodar jobs e agendamento gerenciado. Se stakeholders de fora do time de dados precisam enxergar o que está rodando e por quê, o Cloud compensa o custo. Para um público puramente técnico, o Core basta.
A história da governança acontece dentro da arquitetura de modelos do dbt. Quando cada métrica é definida uma única vez, em um modelo que diz “é isto que significa um projeto ativo”, você elimina aquela situação em que dois times calculam o mesmo número de formas diferentes e gastam uma reunião de board discutindo qual está certo. Não é um documento de política, e sim uma fonte única de lógica que todo mundo consulta. Os testes nativos do dbt (not_null, unique, accepted_values) pegam problemas de qualidade dos dados antes que eles cheguem a um dashboard. Comece com testes básicos em todos os modelos desde o primeiro dia.
Ferramentas de BI: escolha pela necessidade do seu time, não pela popularidade
O Looker Studio é gratuito e útil para validação inicial. As limitações de verdade não estão no número de gráficos: estão na ausência de um semantic layer ou de uma camada de modelagem, na governança básica só por papéis (sem row-level security nem workspaces na versão gratuita), na queda de performance com datasets grandes ou de múltiplas fontes e em conectores de terceiros que quebram mais do que você esperaria. Para confirmar que os dados estão chegando corretamente antes de assinar uma ferramenta paga, funciona. Para qualquer coisa da qual stakeholders dependam todo dia, a fragilidade aparece rápido.
O Sigma é um bom default para analytics nativo no data warehouse. Tem uma exploração assistida por IA competente, é intuitivo o bastante para usuários de negócio depois de um curto período de adaptação e não exige tirar os dados do warehouse para gerar relatórios.
Um ponto de atenção: o Sigma faz query ao vivo no data warehouse a cada interação, em vez de usar extrações ou cache. Isso pode elevar o custo de computação em modelos de cobrança por query, como BigQuery ou Snowflake, se o padrão de exploração for intenso. Para times com capacidade reservada, não é problema. Para warehouses cobrados por consumo, monitore os padrões de query desde cedo.
O Hex se encaixa em workflows de data science melhor do que em BI puramente operacional. Se o seu time mistura notebooks com dashboards para experimentação de ML, análise ad hoc e compartilhamento de resultados, o Hex cai bem. Para operação padrão ou business analytics, é mais superfície do que você precisa.
O Looker (o produto completo) é caro e hoje tem alternativas à altura. Avaliaríamos principalmente para organizações que já estão comprometidas com o Google Cloud, querem consolidar relações com fornecedores e têm orçamento para ferramentas enterprise.
Para ferramentas internas em que flexibilidade importa mais do que licenciamento, um frontend React enxuto consultando a sua camada gold diretamente costuma ser mais rápido de construir e mais fácil de manter do que forçar uma ferramenta de BI a caber em um caso de uso incomum. Isso funciona especialmente bem em ferramentas operacionais: dashboards de alocação, acompanhamento de margem, visões de capacidade do time, qualquer lugar em que a interface precisa espelhar um fluxo interno que nenhum produto de prateleira atende direito.
Um framework prático de decisão
Ao começar um projeto de arquitetura de dados, as decisões seguem esta ordem. Já existe um provedor de nuvem contratado? Comece por ele e construa dentro desse ecossistema.
Se não há preferência, as fontes principais estão no Google Workspace? BigQuery com conectores nativos é o caminho de menor resistência.
Quais são os tipos de fonte? Na maior parte, ferramentas SaaS padrão com conectores prontos, como Salesforce, HubSpot ou Amplitude? Airbyte. Na maior parte, sistemas internos customizados ou proprietários? Conectores em Python com Airflow. Uma mistura dos dois? Airbyte para as fontes padrão e conectores customizados para o resto.
Existem planilhas entre as fontes? Conecte como ponte. Mapeie os sistemas a montante. Comece a planejar a migração para conexões estáveis via API. Quais são os outputs desejados? Desenhe os modelos da camada silver em torno desses outputs, não em torno do que é fácil de construir. Só construa a gold quando a silver estiver estável e o público estiver definido.
Inteligência Artificial é um caso de uso de curto prazo? Desenhe a camada silver para ser acessível por IA desde o primeiro dia. Uma arquitetura só com gold vai exigir retrabalho quando os workflows com LLM ou agênticos chegarem.
No fim das contas
A parte difícil é entender seus dados bem o suficiente para saber quais ferramentas se justificam. Depois disso, escolher as ferramentas é fácil.
Mapeie seus outputs primeiro. Rastreie suas fontes. Desenhe a camada silver em torno das decisões que importam. Construa governança desde o começo com dbt. Trate planilhas como uma ponte enquanto identifica os sistemas estáveis por trás delas. Mantenha a stack enxuta: cada ferramenta a mais é uma superfície de falha e mais uma relação com fornecedor para gerenciar.
As empresas que conseguem colocar IA em produção não são as que têm as arquiteturas mais sofisticadas. São as que primeiro tornaram seus dados confiáveis e só depois colocaram a IA por cima.
Na Cheesecake Labs, ajudamos empresas a construir a base de arquitetura de dados que torna a IA possível, da arquitetura e engenharia de pipelines até analytics e workflows agênticos. Se o seu time é rico em dados, mas pobre em insights, vamos conversar.
