// stack.lumi

Dados

BigQuery

Data warehouse serverless para analytics rapido.

// o que é

BigQuery e o data warehouse serverless do Google Cloud, criado para consultar grandes volumes com pouca administracao de infraestrutura. Para a Lumi Data, e uma base excelente para analytics, BI e experimentos de dados com velocidade.

O BigQuery é a implementação pública da arquitetura Dremel, descrita por Melnik et al. (2010) no VLDB como um sistema de análise interativa de datasets na escala de petabytes em questão de segundos. A inovação central do Dremel é o armazenamento colunar em formato aninhado (Capacitor), que permite leitura seletiva de colunas sem desserialização de linhas completas, reduzindo dramaticamente a I/O para queries analíticas que tocam poucos campos de tabelas largas. Kleppmann (2017) categoriza esse padrão como column-oriented storage, explicando por que ele é fundamental para workloads OLAP em contraste com row-oriented storage otimizado para OLTP. A separação de computação e armazenamento do BigQuery, com slots de processamento independentes do espaço em disco, antecipou o modelo que Snowflake popularizou e que Dageville et al. (2016) formalizaram como virtual warehouses — uma arquitetura que elimina o trade-off clássico entre escala de armazenamento e escala computacional.

Como a Lumi enxerga:A Lumi modela datasets, particionamento, clustering, controle de custo e governanca para transformar BigQuery em fonte confiavel de decisao.

// na prática

Como empresas usam BigQuery

Empresa de mídia e publicidade digital com análise de audiência e performance de campanhas

BigQuery centraliza eventos de sites, apps e plataformas de ads (Google Ads, Meta, TikTok) via BigQuery Data Transfer Service e APIs customizadas, permitindo que o time de mídia cruze dados de impressões, cliques e conversões com comportamento on-site em queries que antes demandavam horas em PostgreSQL. A integração nativa com Looker Studio e Looker permite que analistas construam dashboards diretamente sobre BigQuery sem extrair dados para outro sistema.

Healthtech com dados sensíveis de pacientes exigindo conformidade com LGPD e HIPAA

BigQuery com controles de acesso granular por coluna (Column-Level Security) e Data Masking permite que analistas de negócio consultem métricas agregadas sem enxergar CPF ou dados clínicos individuais, enquanto o time médico acessa a view completa com suas credenciais. O audit log automático do BigQuery registra cada query executada, quem executou e quais dados acessou — requisito direto de conformidade com a LGPD para dados de saúde.

Scale-up de SaaS com dados de produto e finanças consolidados para investidores

BigQuery serve como data warehouse principal de uma empresa com 500 clientes corporativos, armazenando eventos de produto (Segment), dados financeiros (Stripe) e métricas operacionais em um único lugar. Com dbt organizando a camada de transformação, o CFO e o board recebem dashboards de MRR, churn e NPS com os mesmos números que o time de produto vê — eliminando o problema recorrente de "qual planilha está certa" nas reuniões de diretoria.

// decisão técnica

Quando usar — e quando não usar

Use quando

A empresa já opera no Google Cloud ou tem produtos Google como G Suite, Google Ads ou Firebase e a integração nativa do BigQuery com esse ecossistema reduz significativamente o esforço de ingestão.
O workload é predominantemente analítico (OLAP) com queries que varrem milhões a bilhões de linhas; o modelo serverless elimina a necessidade de provisionar e tunar clusters.
O time de dados precisa democratizar acesso analítico para analistas de negócio sem habilidades de infraestrutura; a interface SQL familiar e o modelo pay-per-query viabilizam exploração sem risco de custo de cluster idle.
A arquitetura requer integração com ferramentas de BI do Google (Looker, Looker Studio) ou com Vertex AI para modelos de ML diretamente sobre os dados do warehouse.
O volume de dados cresce de forma imprevisível e a escalabilidade automática do BigQuery elimina o ciclo de resize de cluster que outros warehouses exigem.

Evite quando

O workload é transacional com muitas escritas individuais e updates frequentes em registros específicos; BigQuery não é otimizado para INSERT/UPDATE de linhas individuais em alta frequência — o DML tem latência e custo elevados.
O budget é muito restrito e o padrão de uso inclui muitas queries sem controle de custos; BigQuery cobra por dados varridos e queries exploratórias sem filtros em tabelas grandes podem gerar faturas surpresa — exige governança de custos ativa com reservas ou cotas.
A empresa opera predominantemente em AWS e já tem Redshift ou S3/Athena estruturados; migrar para BigQuery só para usar o produto em si não se justifica sem um benefício técnico claro.
O caso de uso exige latência de milissegundos em queries de lookup de registro único; para esse padrão, BigQuery é inadequado — Bigtable, Cloud Spanner ou um banco relacional servem melhor.

// visão lumi

O BigQuery é a escolha padrão da Lumi para projetos data warehouse quando o cliente está no GCP ou não tem preferência de cloud — e a razão principal não é tecnológica, é operacional: zero clusters para gerenciar, escalabilidade automática e modelo de cobrança que alinha custo com uso real. O que diferencia nossa implementação de um setup genérico é o investimento em governança de custos desde o dia um: reservas de capacidade para workloads previsíveis, cotas por projeto para conter queries exploratórias, e particionamento e clustering em todas as tabelas grandes. BigQuery sem governança de custos transforma empresas em clientes infelizes com faturas de cloud imprevisíveis — algo que vemos com frequência em projetos que chegam até nós para correção.

Lumi escolhe quando

Quando o cliente está no GCP ou usa produtos Google (Ads, Firebase, Workspace) e a integração nativa elimina esforço de ingestão.
Quando o time de dados tem analistas SQL que precisam de acesso direto ao warehouse sem gerenciar infraestrutura.
Quando o projeto inclui ML ou GenAI com Vertex AI e manter dados no mesmo ecossistema Google reduz latência e custo de transferência.
Quando a empresa prefere modelo de cobrança por query a custo fixo de cluster, especialmente em fases de crescimento com volume imprevisível.

Lumi não recomenda quando

Quando o cliente está fortemente investido em AWS e já tem Redshift estruturado — a migração para BigQuery não se justifica sem benefício técnico concreto.
Quando não há governança de custos planejada e o time faz queries exploratórias frequentes em tabelas não particionadas — o risco de fat finger bill é real.
Quando o workload é transacional com updates frequentes de registros individuais; nesse caso BigQuery é a ferramenta errada independente do ecossistema cloud.

// aplicações

Onde essa tecnologia gera valor

Data warehouse corporativo

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Analytics exploratorio

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Camadas para Power BI, Looker e Tableau

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

Modelos analiticos com dados semi-estruturados

A Lumi conecta essa aplicação ao objetivo de negócio, definindo arquitetura, dados, segurança e indicadores de sucesso antes da implementação.

// fundamentos

Referências acadêmicas e técnicas

Melnik, S., Gubarev, A., Long, J. J., Romer, G., Shivakumar, S., Tolton, M., & Vassilakis, T. (2010). Dremel: Interactive Analysis of Web-Scale Datasets. VLDB 2010.

Paper original da arquitetura Dremel que fundamenta o BigQuery, descrevendo armazenamento colunar aninhado e execução de queries em árvore.

Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media.

Capítulo sobre column-oriented storage explica por que o modelo colunar é otimizado para OLAP e como ele difere de row-oriented.

Google Cloud. (2023). BigQuery Documentation. https://cloud.google.com/bigquery/docs

Documentação oficial cobrindo arquitetura, modelos de precificação, controles de acesso e integração com o ecossistema Google Cloud.

Dageville, B., Cruanes, T., Zukowski, M., Ease, V., Shrotri, A., Vondrak, L., Hilber, J., Backus, D., Swanson, T., Steinoff, T., Schmuckler, J., Wottawa, J., Srinivasan, V., Subramanian, A., Bhatt, V., Keller, C., Shetty, A., Sundararaman, S., & Schilling, O. (2016). The Snowflake Elastic Data Warehouse. ACM SIGMOD 2016.

Formaliza a separação de armazenamento e computação que BigQuery também implementa, permitindo escalabilidade independente de cada camada.

Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit (3rd ed.). Wiley.

Referência de modelagem dimensional aplicada ao BigQuery para estruturar camadas gold com fatos e dimensões para BI.

// tecnologias relacionadas

Dados

// próximo passo

Quer saber se esse stack faz sentido para você?

A Lumi avalia contexto, dados, equipe, custo e maturidade para recomendar a tecnologia certa e entregar com responsabilidade.

Avaliar meu stack →Voltar ao stack