Analytics multi-tenant para negócios de fitness — tenant #1: os meus estúdios
Antes de escolher a arquitetura, fiz grep às job descriptions guardadas: Databricks ×7, Terraform ×7, Airflow ×4, dbt ×2. Ferramentas de BI: ~0.

The €100 Lakehouse — 1/12
Antes de escolher a arquitetura, fiz grep às job descriptions guardadas: Databricks ×7, Terraform ×7, Airflow ×4, dbt ×2. Ferramentas de BI: ~0.
O grep ditou a regra fundadora, escrita verbatim: «The dashboards layer is a product decision, not a CV decision.» O investimento de carreira vai para Databricks, dbt e Airflow; o Superset é install & configure. Recusado: polir a camada de BI para lá do que o produto pede.
O produto: analytics multi-tenant para software de gestão de negócios de fitness. Um pilot tenant hoje — os meus dois estúdios, o cliente que nunca mente sobre requisitos — desenhada para muitos: o tenant_id é o elemento [0] de cada surrogate key; uma key sem tenancy nem sequer se escreve.
O pipeline: dlt → S3 → Databricks (bronze/silver/gold) → dbt → Postgres RLS → Superset · Airflow 3 por cima.
O scoreboard, a agosto de 2026:
→ 43 tabelas bronze · 7.877 pagamentos (@2026-08-02) · 1.850 pessoas · 33 meses de P&L
→ 4.277 testes Python + 892 dbt + 26 Playwright
→ €65–80/mês contra um teto de €100 · Frankfurt, por RGPD
→ do primeiro commit ao dashboard em produção com SSO: ~10 dias
E já encontrou €8.511 de receita genuinamente perdida. Mais sobre isso na semana 9.
Lição: sobre-investir deliberadamente num eixo — desde que o eixo tenha nome e a decisão fique escrita.
Se pudesses sobre-investir deliberadamente num eixo do teu próximo projeto, qual seria — e escrevias a decisão?
Databricks · dbt · Airflow · Terraform · AWS
P.S. Novo post tech todas as quartas-feiras.
#100EuroLakehouse #DataEngineering #Databricks
Comentários