Como o datalake StarRocks funciona.
Esta página descreve a arquitetura ponta-a-ponta: como cada alteração no banco de origem chega ao StarRocks numa janela típica de 15 segundos a 2 minutos, quais componentes participam do caminho e por que o StarRocks especificamente é o motor escolhido como destino.
Postgres é ótimo escrevendo. Não foi feito para ler analítico.
Aplicações modernas armazenam dados em bancos transacionais (Postgres, MySQL) que são excelentes para escritas concorrentes e consistência, mas limitados em queries analíticas. Conforme o produto cresce, dois sintomas aparecem:
- Dashboards e relatórios começam a travar a aplicação principal. uma query mal otimizada de BI consome CPU do banco que serve transações.
- O ETL noturno deixa de ser aceitável. o time de produto, de finance ou de operação precisa de números que reflitam o estado atual, não o estado de ontem às 4h.
Read replica não resolve: continua sendo Postgres, com as mesmas limitações em joins multi-tabela e queries colunares. Snowflake resolve mas é caro (Fanatics cortou 90% do custo migrando para StarRocks) e cobra por concorrência. Fivetran/Airbyte movem dados mas tratam StarRocks como destino genérico via JDBC, perdendo até 20× de performance vs. a API nativa.
A solução
Em vez de mover tabelas inteiras de tempos em tempos, capturamos cada alteração linha-a-linha diretamente do log de transações do banco de origem. Essas alterações fluem por um stream service e são aplicadas no StarRocks em até 2 minutos. Resultado:
- O datalake reflete o estado da aplicação com latência típica entre 15 segundos e 2 minutos. uma arquitetura near real-time, não tempo real estrito, mas com frescor adequado para dashboards operacionais e BI.
- O OLTP nunca é lido por queries analíticas. toda a pressão de BI sai dele.
- Múltiplos bancos consolidam-se em um motor único, permitindo cruzamentos que seriam inviáveis com replicação tradicional.
- O motor de destino é purpose-built para esta carga: Primary Key Tables aceitam upserts contínuos sem degradar queries, e Materialized Views inteligentes mantêm agregações sempre atualizadas com refresh incremental.
Cinco etapas, sem caixa-preta.
Cada bola que você vê no diagrama representa um evento atravessando o pipeline. tipicamente entre 15s e 2min do COMMIT até virar uma linha consultável no datalake.
Service
Processor
Os componentes acima descrevem funções no pipeline, não produtos específicos. Cada um corresponde a uma peça open source consolidada na indústria, escolhida pela combinação de maturidade, performance e ausência de lock-in. Os detalhes exatos de implementação são compartilhados em uma reunião técnica quando faz sentido. o objetivo aqui é o quê e o porquê.
O que cada peça faz
CDC Connector
Lê o log de transações do banco de origem (WAL no Postgres, binlog no MySQL) e emite um evento por alteração: insert, update ou delete. Não roda SELECT em tabelas, não usa triggers, não precisa de janelas de polling. Suporta heartbeat para evitar acúmulo do log em períodos de baixa atividade. um problema clássico que normalmente travaria o disco da origem.
Stream Service
Barramento de eventos durável e particionado. Funciona como buffer de retenção: se o destino sair do ar, o stream segura as mudanças e o reprocessamento acontece sem perda. Permite múltiplos consumidores. outros sistemas (alerts, lakehouse, ML) leem o mesmo fluxo sem replicar a captura.
Stream Processor
Lê o stream, agrupa eventos em batches inteligentes (por tamanho, contagem ou tempo), aplica transformações (conversão de JSON, normalização de timestamps, soft delete) e empurra para o StarRocks via Stream Load API. Retry exponencial e roteamento de tabelas particionadas resolvem dois bugs operacionais comuns sem código de cliente.
StarRocks (datalake)
Motor analítico colunar de código aberto, escrito em C++, hospedado pela Linux Foundation sob Apache 2.0. Suporta primary key tables (upserts contínuos com Delete+Insert), materialized views inteligentes, índices secundários (bitmap, bloom filter, prefix), partições, compressão ZSTD/LZ4 e Cost-Based Optimizer maduro. Aceita SQL padrão via protocolo MySQL.
O único motor open-source que aceita CDC sem degradar queries.
A escolha do destino determina se a arquitetura inteira funciona. ClickHouse, Druid, Pinot, Trino. todos têm trade-offs sérios para esta carga. StarRocks foi construído exatamente para combinar ingestão contínua e queries sub-segundo na mesma tabela.
Primary Key Tables com estratégia Delete+Insert
3 a 10× mais rápido em queries que tabelas Unique Key (Merge-On-Read). Mantém performance analítica mesmo com upserts e deletes contínuos vindos do CDC. Coinbase processa 30k mensagens Kafka/seg em PK tables mantendo queries sub-segundo. ClickHouse não tem equivalente eficiente.
Materialized Views com auto-rewrite
O Cost-Based Optimizer reescreve queries automaticamente para usar MVs sem o usuário precisar referenciá-las. Refresh incremental e particionado: quando novos dados CDC chegam, só as partições afetadas são reprocessadas. Agregações ficam sempre atualizadas sem cron jobs ou pipelines manuais.
MPP vetorizado em C++ com SIMD
Motor totalmente vetorizado, sem JVM, sem GC pauses. Em benchmarks oficiais TPC-DS 1TB sobre Iceberg, StarRocks é 5.54× mais rápido que Trino. Em SSB wide-table, é 2.2× mais rápido que ClickHouse e 8.9× mais rápido que Druid.
Cost-Based Optimizer cascades-like
Reordena joins, reescreve subqueries, reusa CTEs e aplica filtros dinâmicos antes de ler do storage. Faz colocated joins (sem shuffle) quando tabelas dividem chave de distribuição. decisivo para TPC-H multi-tabela em escala TB.
Lakehouse aberto via External Catalogs
Query nativa em Apache Iceberg, Hudi, Delta Lake, Hive e Paimon. sem migração. Unified Catalog (3.2+) trata todos como uma fonte só. Coinbase mantém 2-3 meses quentes em StarRocks PK tables e o histórico em S3 Iceberg, juntando tudo num único SQL.
Stream Load + Routine Load
APIs HTTP nativas para ingestão de microbatches (Stream Load) e jobs persistentes lendo Kafka com semântica exactly-once (Routine Load). 20× mais throughput que JDBC genérico. é por isso que Fivetran/Airbyte para StarRocks rendem o que rendem.
Decisões que aparecem só em produção
Não são vendáveis em slides, mas aparecem na primeira semana de operação real:
- Heartbeat anti-WAL-bloat. Em períodos de baixa atividade no Postgres, o slot de replicação pode acumular logs e encher disco. O serviço já vem com heartbeat configurado, evitando o problema clássico que normalmente derruba CDCs em produção.
- Routing de tabelas particionadas. Se sua aplicação usa partições por hash ou por data (
tabela_2025_01,tabela_2025_02...), o pipeline reconhece o padrão e converge para uma única tabela analítica no destino. Você consulta um lugar só. - Soft delete preservado. Por padrão, deletes do OLTP viram updates com campo
_deleted_atno datalake. Auditoria e LGPD ficam servidas; a query analítica filtraWHERE _deleted_at IS NULLquando quer só o estado atual. - JSON nativo no destino. Colunas JSONB do Postgres são convertidas para o tipo JSON do StarRocks (não string), permitindo path expressions sem custo de parse a cada query. StarRocks 4.0 tornou JSON 3-15× mais rápido.
- Schema migrations versionadas. Mudanças nos schemas de origem, no destino e na configuração do CDC são versionadas e aplicadas de forma controlada. Não há "configuração que ninguém sabe quem fez".
- Replicação de identidade completa. O Postgres é configurado para emitir o antes e o depois de cada update. Permite reconstruir o estado anterior, fazer reconciliações e investigar bugs de aplicação.
- Materialized Views auto-refresh. Para dashboards top-N, agregações horárias, métricas diárias. definimos uma vez no início, o StarRocks mantém atualizado conforme novos dados chegam. Sem dbt cron jobs, sem pipelines de refresh manuais.
Não é experimento. É infraestrutura testada em escala.
Volumes documentados publicamente pelas próprias empresas e pela Linux Foundation/CelerData (mantenedora comercial do StarRocks).
| Empresa | Volume / carga | Resultado |
|---|---|---|
| Fanatics | 1B eventos/dia, múltiplos PB em Iceberg | Snowflake reduzido em 95%, custo cortado em ~90% |
| Coinbase | 573B linhas, 300+ tabelas, 30k msg/seg em PK tables | Queries sub-segundo, freshness near real-time |
| 500M+ MAU, migração Druid → StarRocks | Latência p90 -50% usando 32% da infra (3× cost-perf) | |
| Airbnb | 20 EC2 i3.8xlarge, tabelas 500M-6B linhas | Queries de 3-10min para 3.6 segundos |
| Intuit | 100k eventos/seg, substituiu Druid | TP99 <500ms, agregação 98.33% mais rápida |
| Demandbase | Lakehouse PB-scale (StarRocks + Iceberg) | Federated query frio + quente em 1 SQL |
Quando este serviço é indicado
O serviço entrega valor quando:
- Há volume de dados ou de queries analíticas que começa a impactar a aplicação principal.
- Existe necessidade de cruzar dados de mais de um banco em um único motor (ex.: Postgres operacional + Postgres de eventos + dump de planilha).
- A latência do ETL atual (horas, dia anterior) deixa de ser aceitável para alguma operação do negócio.
- Há requisito de auditoria ou LGPD que exige preservar histórico de mudanças.
- Custo de Snowflake / Databricks está crescendo desproporcional ao valor entregue.
- O time interno não quer (ou não tem capacidade) de operar Flink, Kafka, Debezium e StarRocks separadamente.
Não é indicado quando:
- Volume total é pequeno (poucas dezenas de milhares de linhas) e queries analíticas são raras. Postgres puro resolve, e adicionar complexidade nesse cenário é overkill.
- O caso de uso exige transações ACID no datalake. StarRocks é OLAP, não OLTP. Mantenha a aplicação no Postgres e use o datalake para análise.
- O caso de uso exige latência sub-segundo ponta-a-ponta (motor de pricing tick-a-tick, alerting de fraude em milissegundos). A janela típica do CDC é de 15 segundos a 2 minutos. para dashboards e BI sobra; para tick analytics, não.
- A aplicação só roda on-premise sem viabilidade de cloud nem de hospedagem co-locada. possível, mas exige projeto dedicado.
Perguntas frequentes
_deleted_at em UTC. Preserva auditoria, atende LGPD para histórico e permite reconstruir o estado em qualquer ponto. Hard delete é configurável caso o caso exija.Avaliar a arquitetura para o seu caso
Cada operação tem topologia, volume e prioridades diferentes. A primeira reunião serve para projetar números específicos para o seu cenário.