O trabalho real de um analista de dados
A maior parte do dia de um data analyst o que faz é resolver problemas de dados sujos antes de conseguir pensar em qualquer coisa inteligente. A imagem que as empresas vendem é de gente fazendo dashboards bonitos e achando padrões mágicos. A realidade é bem diferente na prática. Eu passei duas semanas numa análise de churn de clientes que deveria levar dois dias. O problema era que o CRM da empresa registrava a data de cancelamento de três formas diferentes: a data que o cliente dizia no telefone, a data que o sistema marcava quando o contrato expirava automaticamente, e uma terceira data que aparecia só nos relatórios financeiros. Eu precisei criar uma regra de priorização que pegava a data do financeiro como verdadeira, usava a data do sistema como verificação, e descartava a do atendimento quando havia conflito. Sem essa lógica, qualquer modelo preditivo ia ensinar patterns absurdos.
data analyst o que faz no dia a dia
O trabalho começa com a compreensão de onde os dados vivem e como chegam até você. Sistemas legados que exportam CSVs com codificação errada. APIs que mudam o schema sem avisar. Bancos de dados relacionais onde as chaves estrangeiras são sugestões, não garantias. SQL é a ferramenta principal, mas saber escrever query não é o diferencial. O diferencial é saber quais colunas provavelmente estão erradas antes de rodar o select. Eu trabalho com pandas e SQL diariamente. Para análises exploratórias rápidas, pandas com Jupyter já resolve. Quando o dataset passa de dois gigabytes ou precisa ser reprossado em pipeline, eu migro para Spark. A diferença no tempo de processamento entre os dois é absurda em escala, mas pandas continua sendo a escolha certa para a maioria das tarefas que surgem no dia.
Dashboarding vem depois. Tableau e Power BI são os mais comuns no mercado brasileiro. A armadilha que vejo todo mundo cair é construir o dashboard antes de validar com o stakeholder quais perguntas ele realmente quer responder. Eu costumo pedir para o negócio escrever três perguntas em texto simples antes de abrir qualquer ferramenta visual. Se eles não conseguem formular as perguntas, o dashboard vai ser enfeite de tela. Estatística aplicada é o que separa o analista que descreve dados do analista que responde perguntas com confiança. Teste A/B mal executado pode te fazer acreditar que uma mudança de cor de botão aumentou conversão em 15 por cento quando na verdade o efeito foi ruído. Eu já vi case assim. O time de produto lançou a feature, comemorou, e três meses depois a iniciativa porque a métrica principal não sustentava o upgrade de custo que a mudança gerou.
O que poucos sabem é que a parte mais crítica do trabalho é a documentação de linhagem de dados. Quem consumiu essa coluna anteriormente? Qual transformação foi aplicada? Qual versão do modelo de features está rodando em produção? Eu mantenho um arquivo de versionamento simples em YAML com essas informações. Quando um dado começa a se comportar estranho, meia hora pesquisando no arquivo economiza dois dias de investigação cega.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Ferramentas que realmente importam
SQL precisa ser sólido. Window functions, CTEs, otimização de performance, tudo isso entra no dia a dia. Python ou R para análise exploratória e automação. O mercado brasileiro ainda pede muito Excel avançado, principalmente para comunicação com áreas que não estão imersas em cultura data-driven. Git é obrigatório. Qualquer analista que não versiona o código das queries e scripts está jogando tempo fora. A pessoa que substituir você vai passar horas entendendo o que foi feito, e você provavelmente vai ser essa pessoa substituindo alguém que não versionou nada.
Cloud é o padrão agora. AWS, GCP, Azure. BigQuery e Redshift são os data warehouses mais comuns. Eu recomendo começar com BigQuery pela simplicidade de setup inicial, mas se a empresa já está deep em AWS, Redquery é a escolha mais coerente para evitar fricção operacional.
O que ninguém conta sobre a carreira
Salários variam muito conforme a maturidade da empresa. Startups pequenas pagam menos e pedem que você faça tudo: engenharia de dados, análise, dashboard, suporte ao negócio. Empresas estabelecidas têm equipes especializadas, o que permite profundidade mas também cria burocracia para validar qualquer mudança nos processos. A transição para engenharia de dados é mais comum do que para ciência de dados. Análise de dados puras em empresas brasileiras ainda são vistas como centro de custo, não como motor de decisão. O crescimento real acontece quando você consegue demonstrar impacto financeiro direto das suas análises.
Um erro frequente de quem está começando é tentar aprender tudo ao mesmo tempo. SQL, Python, estatística, machine learning, visualização, cloud, governança. O resultado é mediocridade em todas as frentes. Escolha uma trilha, domine o essencial dela, e expanda depois. Um SQL bem escrito e uma análise estatisticamente sólida valem mais do que dez dashboards coloridos sem fundamento. A demanda por analistas que entendem de negócio ainda supera a oferta. Técnicos bons existem em quantidade. Técnicos que sabem traduzir números em decisões operacionais são raros e bem pagos. Invista tempo entendendo o modelo de negócio da empresa onde você trabalha. Isso não aparece no currículo mas faz toda a diferença nas promoções.
