Tecnologia
Consultoria e implementação de Metabase
O time queria parar de pedir relatório para a área de dados, e conseguiu. Agora cada pessoa escreve a sua própria question direto sobre a tabela bruta. Cada uma reimplementa a mesma regra do seu jeito, e duas respostas para a mesma pergunta passam a conviver sem que ninguém note. A autonomia chegou; a definição de cada número foi embora junto.
Como a gente encara.
Autonomia só se sustenta quando existe algo pronto para consultar. Antes de abrir a ferramenta para todo mundo, definimos as entidades que as pessoas de fato perguntam. Elas são expostas como model, com a regra dentro. As questions nascem do model, e não da tabela bruta, e o cálculo deixa de ser copiado. A permissão é desenhada no banco, com usuário próprio e escopo limitado. E a consulta pesada aponta para uma réplica, nunca para a produção.
Onde costuma quebrar
Os erros que aparecem sempre, e que ninguém conta na demonstração.
- 01
Question escrita direto sobre a tabela bruta. Cada pessoa reimplementa o mesmo filtro do seu jeito, e as versões divergem sem que ninguém veja, porque cada uma mora dentro de uma pergunta diferente.
- 02
Ausência de camada de model. O mesmo cálculo é copiado entre perguntas por duplicação, então corrigir a regra vira caçar todas as cópias — e a collection arrumada por área esconde justamente as que ficaram fora dela.
- 03
Permissão concedida no nível da ferramenta e não do banco. A tela esconde a tabela, o usuário do banco continua enxergando tudo, e quem tem acesso ao editor de SQL nativo alcança exatamente o que a interface escondia.
- 04
Consulta pesada disparada contra o banco de produção. Uma pergunta mal filtrada varre a tabela inteira no mesmo banco que atende a aplicação, e o seu cliente sente a lentidão que nasceu num painel interno.
O que custa mais do que parece
- A facilidade de criar pergunta gera volume de consulta que o banco não foi dimensionado para absorver. Cada dashboard aberto dispara todas as suas questions de uma vez, e os envios programados concentram esse disparo no mesmo horário da manhã, junto com a carga do dia.
- A edição gratuita cobre a consulta e não necessariamente a governança. Login por LDAP e por conta Google a edição gratuita atende. Do lado pago ficam a federação por SAML, o acesso embutido assinado por JWT, a permissão por linha — que na ferramenta se chama isolamento de dado por usuário (data sandboxing) — e a trilha de quem consultou o quê, que são justamente os requisitos que aparecem na auditoria. É ali que você descobre de que lado da divisão a sua edição está, com a ferramenta já adotada.
- O Metabase guarda os próprios metadados num banco de aplicação: questions, dashboards, collections, permissões e histórico. Por padrão esse banco é o embutido em arquivo (H2), ao lado do processo. É postura de quem está experimentando, não de quem opera: não dá backup consistente com o serviço no ar e some junto com o container recriado. Trocá-lo por Postgres depois da adoção é migração com parada e conferência, e é trabalho que ninguém orçou.
O que você recebe
- Camada de model sobre as entidades que as pessoas realmente perguntam, com a regra dentro e as questions partindo dela.
- Definição acordada para cada número que a empresa usa, com dono do negócio e o model onde ela mora.
- Permissão desenhada no banco, com usuário próprio da ferramenta, escopo limitado e a decisão registrada sobre quem recebe editor de SQL nativo.
- Réplica de leitura como destino das consultas, com a lista do que ainda aponta para produção e a justificativa de cada caso.
- Collections com dono e o procedimento para aposentar pergunta que ninguém abre.
O que fazemos com Metabase
Open source ou enterprise, a frente é a mesma.
Implantar
Do zero, com a arquitetura decidida no diagnóstico e não pelo catálogo do fornecedor.
Migrar
De outra ferramenta, ou de uma versão antiga, com o que já roda continuando a rodar.
Desenvolver em cima
Aplicação, integração e automação construídas sobre Metabase, incluindo o que a ferramenta não faz sozinha.
Sustentar
Operação, custo sob controle e correção de rota depois que entra em produção.
Perguntas diretas.
- Quando o Metabase basta e quando não?
- Basta quando as perguntas são sobre entidades que já existem modeladas, o público filtra e lê mais do que calcula, e o volume cabe no banco que você já tem. Deixa de bastar em três situações concretas. Quando a definição das métricas precisa ser versionada e revisada como código, porque aí a regra tem de viver na camada de dado e não na ferramenta. Quando o relatório precisa sair com formatação exata para fora da empresa. E quando o isolamento de dado por usuário (data sandboxing) teria de aplicar regra que mora em outro sistema. Nesses casos a ferramenta certa é outra, e adotar esta é adiar a conversa.
- Quem decide o que uma métrica significa quando qualquer pessoa pode criar pergunta?
- Alguém do negócio, e isso precisa estar escrito antes de a autonomia ser distribuída. A ferramenta não tem opinião: ela executa o SQL que recebe e mostra o resultado com a mesma autoridade nos dois casos. O que dá para fazer tecnicamente é reduzir a superfície de discordância, colocando as regras contestadas dentro do model e deixando para as pessoas o recorte e o filtro. O que não dá é fazer com que a ferramenta resolva um desacordo entre duas áreas sobre o que conta como venda. Essa parte é conversa, e ela não fica mais barata por ser adiada.
- Já temos outra ferramenta de BI. Faz sentido manter as duas?
- Faz, quando a divisão é por público e não por preferência. Uma ferramenta leve para quem explora e escreve consulta, outra para o relatório institucional que circula fora da área, é um arranjo que se sustenta. O que não se sustenta é definir métrica nos dois lugares: aí você mantém duas camadas semânticas que divergem no primeiro mês e passa a explicar a diferença toda vez. A pergunta a fazer não é qual ferramenta é melhor, e sim onde a regra vai morar — se ela mora na camada de dado, ter duas telas é detalhe; se mora dentro de cada ferramenta, uma delas sobra.
Antes de escolher a ferramenta
A ferramenta é consequência da arquitetura. Nunca a premissa.
Esta página existe porque alguém procura por esse nome. Mas a escolha certa sai do diagnóstico do seu cenário, não do catálogo de quem vende. Se a resposta for outra ferramenta, ou nenhuma, é isso que você vai ouvir.
Não está na lista? Não é impedimento, é conversa. O que decide não é o nome do produto, é o problema que ele precisa resolver.