Brito's Data
Plataforma moderna de engenharia de dados — ingestão, catálogo, transformação, qualidade e observabilidade em um único produto. Self-hosted no GCP, construída e operada por Raí Brito.
O problema que resolve
Times de dados em empresas pequenas e médias enfrentam um dilema: precisam de uma stack completa (ingestão, transformação, catálogo, qualidade, lineage) mas não conseguem justificar $5.000–$15.000/mês em assinaturas SaaS — Fivetran, dbt Cloud, Monte Carlo, Airbyte, todas somando custo proibitivo.
Brito's Data consolida essas capacidades em uma plataforma única, self-hosted, rodando em uma VM padrão no GCP por ~R$ 300/mês. Cobre 80% dos casos de uso típicos sem comprometer governança ou performance.
Para quem faz sentido
- ✓ Consultorias que entregam stacks de dados completas para clientes
- ✓ Startups com 5–50 funcionários migrando do "tudo no BigQuery" para arquitetura medallion
- ✓ Times que querem dbt + lineage column-level sem pagar dbt Cloud
- ✓ Empresas que precisam de Delta Lake mas não vão pagar Databricks
Arquitetura
Stack medallion clássica (bronze/silver/gold) com Spark embedded e Delta Lake como formato de armazenamento. Backend FastAPI orquestra ingestão, transformações dbt, Airflow scheduling e eventos de lineage via OpenLineage.
Camadas do medallion
Bronze: dados crus dos conectores, schema-on-write, particionamento por data de ingestão. Silver: dados limpos via dbt staging — tipos padronizados, deduplicação, normalização. Gold: marts de negócio — agregações, KPIs, joins prontos para análise.
Capabilities
Oito módulos integrados que cobrem o ciclo completo de dados:
Ingestão multi-fonte
Postgres, BigQuery, SQL Server, Oracle, Delta. Engine V3 com control table, full + incremental, watermark com timezone-aware.
Catálogo column-level
Stats automáticas vindas de _delta_log (null_count, min, max, version) — equivalente a Unity Catalog.
Lineage column-level
OpenLineage spec v2 nativo. Rastreio coluna-a-coluna desde fonte até gold mart.
dbt Projects integrado
Git/Upload/Local, parser nativo, materialização Delta com method=session e extensões.
Data Quality
Regras nativas + integração Great Expectations. Tests do dbt importados como DQ rules.
Pipeline Builder
Drag-and-drop visual (React Flow) com agendamento via Airflow. Joins, filtros, transformações Spark.
Notebooks
Editor Databricks-style com sidebar de catálogo, sessão Spark persistente, autocomplete.
Observabilidade
Schedule, dashboards, métricas de execução, alertas de falha, retenção configurável.
Stack técnica
Tecnologias maduras, padrões de mercado, sem dependência de SaaS proprietário.
| Camada | Tecnologia |
|---|---|
| Frontend | Next.js 14 · React 18 · TypeScript · Tailwind · React Flow · sonner |
| Backend | FastAPI · Python 3.11 · SQLAlchemy · Pydantic · Alembic |
| Compute | Spark 3.5 · Delta Lake 3.2 · dbt-core 1.8 |
| Orquestração | Airflow 2.9 (scheduler + webserver) |
| Metadados | Postgres 16 (Alembic migrations) |
| Storage | GCS bucket via FUSE mount (/data/lakehouse) |
| Auth | Firebase Auth (Google SSO) |
| Lineage | OpenLineage spec v2 |
| Infra | GCP Compute Engine e2-standard-2 · Docker Compose · Nginx · Let's Encrypt |
| DNS / CDN | Cloudflare |
| Container Registry | GCP Artifact Registry (southamerica-east1) |
Decisões técnicas
Toda escolha de arquitetura tem trade-offs. Estas são as decisões mais relevantes e por quê:
Por quê: custo. e2-standard-2 + GCS = ~R$300/mês. Equivalente Databricks/Snowflake = ~$2.500/mês.
Trade-off: sem auto-scaling automático, sem suporte enterprise. Adequado para times <50 pessoas e volumes <100GB.
Por quê: ecosistema mais maduro com Spark, Time Travel nativo, MERGE INTO performático, Z-Order e VACUUM padronizados.
Trade-off: menos cloud-native que Iceberg (que tem Athena/BigQuery nativo). Para nosso caso (Spark embedded), Delta vence.
Por quê: uma equipe (eu). Microsserviços para 1 dev é over-engineering que adiciona complexidade sem ganho real.
Trade-off: deploy é monolítico. Mitigado por sidecar dbt-runner isolado em container próprio (FastAPI separada).
Por quê: Spark/Delta tratam GCS como filesystem POSIX nativo. Zero mudança de código vs lakehouse local.
Trade-off: latência maior em listing de muitos arquivos. Mitigado por particionamento adequado nas tabelas Delta.
Por quê: SQL relacional simples para metadados de catálogo, conexões, jobs. Hive Metastore exigiria infraestrutura adicional sem ganho prático.
Trade-off: não compatível com ferramentas externas que esperam Hive Metastore (Trino, etc). Limitação aceitável dado o escopo da plataforma.
Roadmap
Recently shipped (Abr–Mai 2026)
-
✓
S13 — Carga Incremental com control table: Engine V3, watermark timezone-aware, full/incremental UI
-
✓
Catalog auto-sync: stats column-level direto do
_delta_log -
✓
OpenLineage events: emissão automática em cada ingestão
-
✓
dbt Projects + Delta:
method=sessioncom Delta extensions -
✓
Wizard opt-in autosync: catalog + DQ rules importados automaticamente
-
✓
Pipeline Builder polish: rename inline, edge types, preview
-
✓
Security hardening: redaction de credenciais, SA key rotation, migrations automáticas
Next (S12, S14, S15)
-
○
S12 — Dev↔Prod sync: Airflow rodando em PRD, control table replication
-
○
S14 — Escalabilidade: Cloud SQL, Spark memory dinâmico, Cloud Monitoring alerts, backup automático
-
○
S15 — Multi-tenancy + GE Wizard: workspaces isolados por cliente, GUI para Great Expectations
Modelo de custo
A plataforma roda em uma única VM (e2-standard-2) com disco SSD e GCS bucket. Custo total previsível, sem cobrança por linha processada ou por usuário.
Custos baseados em preços públicos GCP (São Paulo, 2026) e tabelas comerciais dos vendors SaaS para teams <25 usuários.
Precisa implantar uma stack como esta?
Disponível para projetos de consultoria, implantação corporativa ou conversa técnica. Resposta em 24h.