Ferramentas e Stack de Tecnologia para Data Analyst: A Construção Honesta de 6 Camadas (Com Preços Reais)

Entrei em uma empresa na rodada Série B no ano passado e herdei um stack com três ferramentas de BI, dois fornecedores de reverse-ETL que ninguém lembrava a senha, um "catálogo de dados" com onze entradas e uma fatura anual de R$ 40K que produzia exatamente um print semanal no Slack. Só a licença do Looker era R$ 52K. O Looker estava renderizando doze painéis de controle. Dois deles foram abertos nos 90 dias anteriores. Um deles era eu, verificando se o painel ainda funcionava.

Foi naquele momento que aprendi o que "modern data stack" realmente significa: uma sopa de logos que os fornecedores vendem para analistas que ainda não foram forçados a defender as linhas do orçamento. Se você não consegue desenhar o seu stack em um guardanapo e justificar cada camada para um CFO que nunca ouviu falar de dbt, você vai perder a batalha do orçamento, e essa batalha está chegando.

Então aqui está a versão honesta. Seis camadas. Preços reais. Os fornecedores que eu cortaria da maioria dos stacks. E uma auditoria de 30 dias que você pode executar antes de assinar outra renovação.

Por que isso importa agora

Todos os CFOs com quem converso estão fazendo a mesma pergunta: "Por que o gasto com ferramentas de analytics subiu 40% ano a ano quando o headcount está estável?" A resposta geralmente é que alguém comprou Snowflake quando o Postgres funcionaria, outra pessoa comprou Looker porque apareceu em uma entrevista de emprego e uma terceira pessoa adicionou Fivetran porque o engenheiro antigo saiu e ninguém queria manter os scripts Python.

Nenhuma dessas decisões estava errada isoladamente. O problema é que ninguém é responsável por todo o stack. O gasto com ferramentas é o item de linha mais fácil para um CFO questionar e o mais fácil para um analista defender mal. Se a sua resposta para "por que temos isso?" é "porque a última pessoa configurou", você já perdeu.

Stacks defensáveis têm um traço em comum: cada ferramenta mapeia para exatamente uma camada e cada camada merece o seu lugar. Seis camadas é suficiente.

As 6 camadas essenciais (todo o restante é opcional)

1. Data Warehouse

Esta é a fundação. Escolha errado e as próximas três camadas custam 3 vezes mais do que deveriam.

• Snowflake: baseado em uso, aproximadamente US$ 2 a 4 por crédito dependendo da edição e região. Excelente para cargas de trabalho com picos e acesso SQL em toda a equipe. Fácil de gastar demais se você não configurar auto-suspend do warehouse para 60 segundos e não forçar todos a usar X-Small para trabalho ad hoc. Já vi uma execução errante de dbt consumir US$ 800 em um fim de semana.
• BigQuery: pagamento por consulta a US$ 6,25/TB escaneado (sob demanda), ou slots com compromisso para cargas previsíveis. Ótimo se o tráfego é genuinamente irregular e você não quer gerenciar computação. O modelo de slots é confuso para iniciantes. Leia a documentação antes de comprometer.
• Redshift: barato se você fizer commit em uma instância reservada, doloroso se não fizer. Instâncias reservadas começam em cerca de US$ 0,25/nó/hora. O modelo de cluster parece antiquado comparado ao Snowflake e BigQuery, mas se a sua empresa já está na AWS e o time de DE o conhece bem, é defensável.
• Postgres: ainda é a resposta certa abaixo de 1TB. Pare de se desculpar por ele. Uma instância gerenciada do Postgres no RDS ou no Supabase custa de US$ 50 a 500/mês e lida com tudo que uma equipe de analytics de médio porte realmente consulta. Nunca vi uma carga de trabalho abaixo de 1TB que justificasse o Snowflake. Nenhuma vez.

A árvore de decisão: abaixo de 500GB, Postgres. De 500GB a 5TB com carga irregular, BigQuery ou Snowflake. Acima de 5TB ou muitos usuários simultâneos, Snowflake. Acima de 50TB e com uma equipe de DE, Redshift se você vai fazer o commit.

2. ELT / Ingestão

Levar os dados para o data warehouse. É aqui que muitos orçamentos de "modern data stack" explodem silenciosamente.

• Fivetran: de US$ 1K a US$ 10K/mês dependendo das Linhas Ativas Mensais. Excelente quando funciona. Caro quando um conector quebra e você passa dois dias esperando o suporte. O modelo de precificação (MAR) é opaco o suficiente para que eu já tenha visto uma fatura de US$ 1.200/mês saltar para US$ 7.800 em um trimestre porque alguém ativou um sync do Salesforce muito frequente.
• Airbyte: open-source, gratuito se você hospedar. A versão Cloud começa em cerca de US$ 360/mês para volumes baixos. A auto-hospedagem em uma instância EC2 ou GKE pequena custa aproximadamente US$ 200/mês em infraestrutura. A troca: você vai corrigir problemas às 23h. Já fiz isso. Está bem se você tem um DE razoável ou um Analytics Engineer forte. Não finja que é "gratuito" se a equipe não consegue operá-lo.
• Stitch: nível intermediário, em declínio. Razoável se você já o tem. Não começaria um novo stack nele.

O meu padrão: Fivetran para os 5 a 10 conectores principais que realmente importam (Salesforce, HubSpot, Stripe, NetSuite, réplicas do Postgres). Airbyte para a longa cauda de APIs estranhas que ninguém mais se preocupa. Não execute dois desses ao mesmo tempo para a mesma fonte. Escolha um.

3. Transformação

Esta camada está definida. É dbt. Pare de procurar.

• dbt Core: gratuito, open-source. Roda em qualquer lugar que você consiga rodar Python. A maioria das equipes de analytics deve começar aqui.
• dbt Cloud: US$ 50/desenvolvedor/mês para o nível Team, US$ 300/desenvolvedor/mês para o Enterprise. Você está pagando pelo IDE, pelo scheduler, pela hospedagem de documentação e pela integração de CI. Vale para equipes de 3 ou mais analistas que não têm um DE. Ignore-o se você tem um DE disposto a configurar Airflow ou Dagster. Rodar dbt Core no Airflow está ótimo, e o próprio Airflow é gratuito.

A única alternativa legítima é o SQLMesh, e apenas se você está em uma escala onde os padrões de atualização completa do dbt são problemáticos. Para a maioria dos stacks com menos de 100 modelos, não é o seu caso.

4. BI / Painéis de Controle

A camada mais sobrecomprada. A maioria das equipes tem duas ferramentas de BI porque alguém veio de uma empresa com Tableau e outra pessoa veio de uma empresa com Looker e ninguém os forçou a escolher.

• Looker: precificação enterprise, estimativas públicas colocam em mais de US$ 50K/ano e subindo rápido. A camada semântica (LookML) é o diferencial. É a única ferramenta de BI onde a governança realmente funciona em escala. Não compre até ter uma camada semântica real para construir e uma pessoa para mantê-la. Comprar Looker sem um proprietário de LookML é como comprar uma Ferrari para dirigir na garagem.
• Tableau: US$ 75/usuário/mês para Creator, US$ 42 para Explorer, US$ 15 para Viewer. Ainda os painéis de controle mais bonitos do mercado. Doloroso para governança e controle de versão. Bom se o público são executivos que se importam com a apresentação visual.
• Hex: US$ 40 a 80/usuário/mês dependendo do nível. Notebooks mais painéis de controle em um único aplicativo. A escolha certa se os seus analistas passam metade do tempo em exploração de SQL e metade em relatórios para partes interessadas. Substitui o "Jupyter para mim, Tableau para eles".
• Metabase: open-source, gratuito para auto-hospedagem. Cloud Pro começa em US$ 85/mês para 5 usuários. A resposta certa para Série A e antes. Honestamente, a resposta certa para muitas empresas na Série B também. Já vi Metabase superar uma licença de Looker de US$ 40K em empresas que ainda não tinham necessidades de camada semântica.

A minha regra: uma ferramenta de BI. Se você está abaixo de US$ 10M ARR, Metabase. Se você tem um proprietário de LookML e executivos que exigem governança, Looker. Se os analistas são notebook-first, Hex. Tableau se a liderança pediu especificamente. Qualquer outra coisa é uma renovação da qual você vai se arrepender.

5. Notebook / Exploração

Onde os analistas realmente fazem o pensamento bagunçado antes de virar um painel de controle.

• Jupyter: gratuito, local, funciona para sempre. O padrão. Combine com VS Code e você está pronto.
• Hex: já está no seu orçamento se você o comprou para BI. Elimina duas camadas com uma única ferramenta. É parte do motivo pelo qual a precificação do Hex faz sentido para algumas equipes.
• Deepnote: o nível gratuito é generoso. Os planos pagos começam em US$ 39/usuário/mês. Edição colaborativa forte. Vale se a equipe genuinamente co-edita notebooks; menos convincente se todos trabalham sozinhos.

Se você comprou Hex para BI, não adicione Deepnote. Se não comprou, Jupyter está ótimo.

6. Gestão de Tickets / Entrada de Solicitações

A camada que a maioria dos analistas não enxerga como uma camada. É.

• Jira, Notion ou Linear: escolha um. Seja qual for o que a equipe de engenharia usa costuma estar ótimo. O ponto não é a ferramenta. O ponto é eliminar o DM no Slack como canal de entrada de solicitações.

DMs no Slack como entrada de analytics não produzem fila, prioridade, trilha de auditoria e geram infinitas "perguntas rápidas" que levam seis horas. Uma ferramenta de entrada real oferece fila, SLA e um registro. Trate-a como uma ferramenta.

Dados de CRM / Vendas: a camada que a maioria dos analistas suborça

Aqui está a realidade pouco discutida: metade dos problemas de "qualidade dos dados" com os quais os analistas lutam são problemas de higiene do CRM empurrados downstream. Quando o time de operações pede "dados B2B limpos", a resposta padrão é canalizar exportações do Salesforce por quatro transformações dbt para desduplicar contatos, normalizar nomes de empresas, corrigir formatos de telefone e preencher os códigos de setor ausentes.

Isso não é engenharia de dados. É compensar um CRM que não impôs higiene no momento da gravação.

O Rework começa em US$ 12/usuário/mês para CRM e Sales Ops e exporta dados limpos de contatos B2B e pipeline diretamente para o seu data warehouse. A etapa de limpeza que você faria no dbt em grande parte desaparece porque os dados são estruturados na entrada (campos obrigatórios, formatos validados, desduplicação na gravação). Já migrei equipes do Salesforce mais quatro modelos de limpeza e vi o tempo de build do dbt cair de 22 minutos para 6 minutos.

Isso não é um argumento de "o Rework vence em todos os casos". Se você está rodando Salesforce em uma organização de 500 pessoas com 12 administradores, não vai trocar amanhã. Mas se você está no estágio em que "devemos comprar o Salesforce algum dia" é o plano, faça as contas com o Rework primeiro. A economia aparece na contagem de modelos dbt, não apenas no custo da licença.

A auditoria de stack de 30 dias (faça isso antes de comprar qualquer coisa)

Todo analista deveria executar isso uma vez por ano. Se paga na primeira semana.

Dias 1 a 3: inventário. Liste cada ferramenta, cada assento, cada fatura mensal. Puxe o razão do contas a pagar. Encontre o extrato do cartão de crédito. A maioria das equipes encontra de R$ 10K a 30K/ano em software sem uso na primeira semana. A conta de leitura do Snowflake que ninguém usa. O assento do Tableau para o analista que saiu em novembro. A assinatura do Census da época em que você tentou reverse-ETL por um trimestre.

Dias 4 a 10: mapeie. Mapeie cada ferramenta para uma camada acima. Qualquer coisa que não mapeia recebe uma entrevista de "por que isso existe?" com quem quer que seja responsável pelo contrato. Se eles não conseguem responder em duas frases, é um candidato a eliminação.

Dias 11 a 20: encontre as duplicatas. Duas ferramentas de BI. Duas ferramentas de ELT. Três coisas se chamando "catálogos de dados". Escolha uma por camada. A duplicata é a eliminação.

Dias 21 a 30: escreva a lista de eliminação. Valores em reais concretos. Motivos concretos. Apresente ao head de dados com recibos. Traga o plano de migração alternativo, mesmo que seja apenas "mover para o Metabase, aqui está o cronograma". Heads de dados odeiam listas de eliminação vagas. Adoram as específicas com planos de substituição.

Diagrama do stack em um guardanapo (a entrega para o seu CFO):

Sistemas de origem → ELT (Fivetran) → Data Warehouse (Postgres ou Snowflake) → dbt → BI (uma ferramenta) → Partes interessadas
                                              ↑
                                      CRM (Rework)
                                      insere dados
                                      limpos aqui
Entrada (Jira) governa a fila.

Se o seu guardanapo precisar de mais quadros do que esse, você está superdimensionado.

A lista de eliminação: fornecedores que removeria da maioria dos stacks

• Reverse-ETL quando você tem 3 destinos. Hightouch e Census são produtos reais, mas se você está canalizando dados para Salesforce e HubSpot e só isso, você não precisa de uma ferramenta de US$ 24K/ano. Escreva um script Python. Agende-o no dbt Cloud ou no Airflow. Siga em frente.
• Catálogos de dados com menos de 50 tabelas. Atlan, Alation e Collibra são ótimos em escala. Com menos de 50 tabelas, uma página no Notion os supera e não custa nada. Os catálogos só merecem seu lugar quando ninguém consegue encontrar a tabela certa sem um.
• Qualquer coisa "com IA" que envolve GPT em torno de um editor SQL. Avaliei cinco dessas. Todas geram SQL plausível que está errado de formas sutis. Os seus analistas vão gastar mais tempo corrigindo do que escrevendo o SQL eles mesmos. Espere 18 meses.
• Ferramentas de observabilidade quando você tem 12 modelos dbt. Monte Carlo, Bigeye e Elementary fazem sentido em escala. Com 12 modelos, a sua "camada de observabilidade" é um conjunto de testes dbt e um alerta no Slack. Isso é gratuito.

Erros comuns

Comprar Looker antes de ter uma camada semântica. Vejo isso todo trimestre. Uma equipe compra Looker pela promessa de governança, depois percebe que ninguém no quadro conhece LookML, depois paga um consultor a US$ 200/hora para construir a camada semântica. Dois anos depois ainda não estão usando o Looker da forma que pretendia.

Escolher Snowflake para uma carga de trabalho de 200GB. O Postgres lida com 200GB em uma instância RDS de US$ 200/mês. O Snowflake lida com isso por no mínimo US$ 2K/mês quando você considera computação, armazenamento e os warehouses que as pessoas esqueceram de suspender. Se os seus dados cabem na RAM de um servidor de US$ 500, você ainda não precisa de um cloud warehouse.

Tratar o dbt Cloud como obrigatório. Não é. dbt Core mais Airflow mais um runner de CI gratuito do GitLab oferece 90% do dbt Cloud a 0% do custo. Os 10% que você perde são o IDE e o site de documentação. Ambos são agradáveis. Nenhum dos dois é obrigatório.

Deixar cada equipe comprar a própria ferramenta de BI. O Marketing compra Tableau. O time de Vendas compra Looker. O Produto compra Hex. Agora você tem três camadas semânticas, três conjuntos de painéis que discordam e três renovações para defender. Uma ferramenta de BI. Negocie com firmeza. Faça as equipes se adaptarem.

Medindo o sucesso

Você terminou a auditoria quando:

• Consegue nomear cada linha no orçamento de analytics, cada preço mensal e cada camada que ela atende.
• O gasto com ferramentas por analista está comparado a benchmarks. (A minha meta: US$ 8K a 15K por analista por ano para tudo abaixo do data warehouse, mais a computação do warehouse. Se você está acima de US$ 25K por analista, algo está errado.)
• Nada no seu stack existe "porque a última pessoa configurou".

Essa é a barra. Seis camadas, preços reais, defensável para um CFO que nunca ouviu falar de dbt. Se você consegue escrever esse parágrafo de cabeça, vai manter o orçamento. Se não consegue, não vai.

Saiba Mais

• Modelo de Descrição de Cargo para Data Analyst
• Trajetória do Data Analyst
• KPIs e Métricas do Data Analyst
• Construindo uma Equipe de Dados do Zero
• Precificação do Rework