OLAP Redefinido: A Distribuição em 2026
Há dez anos, OLAP era sinônimo de grandes clusters distribuídos e centralizados como Vertica, Redshift e Snowflake. O cenário de 2026 mudou completamente. O ClickHouse Cloud, agora serverless, alcança escala em segundos; o DuckDB processa centenas de GB em um único processo; e tornou-se realidade consultar Parquet no S3 diretamente do navegador via DuckDB rodando em WASM.
Dos 23 projetos de infraestrutura analítica que a KGA recebeu no primeiro trimestre de 2026, apenas 9 adotaram desde o início a arquitetura tradicional de "centralizar tudo no Snowflake/BigQuery". Os outros 14 optaram por uma arquitetura híbrida: um data warehouse central (Snowflake ou BigQuery) dividindo responsabilidades com um OLAP leve na ponta (ClickHouse ou DuckDB). Na prática, separar os casos de uso reduz o custo total em 30 a 50% com frequência.
O Posicionamento do ClickHouse Cloud em 2026
O ClickHouse Cloud atingiu o mais alto patamar de equilíbrio entre facilidade operacional e desempenho com o suporte a serverless em 2024, o SharedMergeTree (separação completa de computação e armazenamento) em 2025, e o Query Condition Cache e a automação do Parallel Replica em 2026. Em um cliente de veiculação de anúncios da KGA, ele sustenta a ingestão de 2 milhões de eventos por segundo e consultas de dashboard com resposta em segundos, com um custo 40% menor em relação ao modelo anterior.
O ClickHouse se destaca de forma avassaladora nos workloads que reúnem todas as seguintes características.
- Séries temporais/logs de eventos append-only: impressões de anúncios, eventos de jogos, telemetria IoT, traces APM, analytics web.
- Consultas de agregação predominantemente em uma ou poucas tabelas: GROUP BY, SUM, COUNT, PERCENTILE.
- Dashboards interativos de baixa latência: casos de uso que exigem resposta abaixo de 500 ms no P95.
- Agregação em dimensões de alta cardinalidade: análise por user_id, session_id, trace_id.
Por outro lado, workloads com muitos JOINs entre tabelas, UPDATE/DELETE frequentes e exploração ad-hoc são mais adequados ao Snowflake/BigQuery. O ClickHouse de 2026 melhorou bastante a tolerância a JOINs com a maturação do Parallel Hash Join e do Grace Hash Join, mas em esquemas estrela com mais de 10 tabelas outros MPPs ainda se saem melhor.
O Impacto do DuckDB 1.2
O DuckDB é um "banco de dados OLAP in-process" que pode ser embutido como biblioteca em aplicações. Três avanços no 1.2 são importantes.
Modo HTTP server: O DuckDB, que era somente library, agora pode ser iniciado como servidor HTTP. Tornou-se estável a configuração de enviar consultas via HTTP a partir de Python, Go ou TypeScript e receber resultados em JSON ou Arrow IPC. Como backend de uma API de dados leve, é mais rápido de implementar do que o ClickHouse.
Leitura e escrita em Iceberg/Delta: A leitura do Iceberg foi implementada na versão 1.1, e a escrita na 1.2. Tabelas Iceberg no S3 podem ser lidas e escritas diretamente pelo DuckDB, viabilizando acesso leve ao lakehouse.
Desempenho WASM: O DuckDB-WASM rodando no navegador passou a alcançar 60 a 70% do desempenho da versão desktop, graças à otimização com SIMD e ao suporte a Workers paralelos. Ferramentas de BI como Observable, Evidence.dev e Perspective são construídas sobre isso, tornando possível "analisar 100 GB de Parquet somente no navegador".
Em um cliente de órgão público da KGA, implementamos um dashboard de visualização de dados abertos com DuckDB-WASM. O Parquet público no S3 é lido diretamente pelo navegador, e toda a agregação e visualização ocorre no lado do cliente. Zero de recursos de computação no servidor, e custo de escala essencialmente zero. Passou nos testes de carga com 1 milhão de usuários.
A Consolidação Comercial do MotherDuck
O MotherDuck é um serviço gerenciado construído sobre o DuckDB que, após o beta em 2024 e o GA em 2025, se estabeleceu em 2026 como uma alternativa real ao Snowflake/BigQuery para workloads analíticos de pequeno a médio porte.
Sua principal característica é a "execução híbrida". Uma parte da consulta (leitura de arquivos, filtros) é executada na nuvem, e o restante no DuckDB local, minimizando a transferência de dados enquanto aproveita os recursos de computação locais. Para desenvolvedores Python, a experiência de fazer um `attach motherduck` dentro de um notebook e realizar JOINs entre tabelas grandes na nuvem e CSVs/Parquets locais de forma transparente é difícil de encontrar em outro lugar.
O preço também é atrativo: dados abaixo de 10 GB podem ser operados no tier gratuito. Para análises entre 100 GB e 1 TB, o custo fica em torno de 1/5 do Snowflake. Porém, para volumes acima de 10 TB ou dashboards com mais de 50 usuários simultâneos, o Snowflake/ClickHouse é mais adequado que o MotherDuck.
A Rota Própria do Turso e do LibSQL
O Turso é um banco de dados SQL distribuído no edge, baseado no LibSQL (um fork do SQLite). Estritamente falando, é mais OLTP do que OLAP, mas a extensão Analytics introduzida em 2026 (um mecanismo que usa armazenamento em linha e em coluna simultaneamente, semelhante ao AlloyDB Columnar) passou a atender também análises de pequeno a médio porte.
Seu diferencial é a configuração multi-tenant que replica o banco em edges ao redor do mundo. A força está na capacidade de consultar com latência de poucos milissegundos a partir do Cloudflare Workers ou do Vercel Edge Functions. É a escolha certa em casos onde a responsividade para usuários geograficamente distribuídos é um problema, como fabricantes de dispositivos IoT ou dashboards de SaaS.
Como OLAP puro, é inferior ao DuckDB/ClickHouse, mas é o primeiro candidato quando se quer "resolver OLTP e análise leve com um único banco de dados" ou "implantar no edge".
Tiered Storage e Design Hot/Cold
O que se tornou indispensável na operação de OLAP em 2026 é o tiered storage (armazenamento em camadas). O ClickHouse Cloud adota como padrão uma estrutura em que S3/GCS é o armazenamento primário e NVMe local é a camada de cache com o SharedMergeTree. O Snowflake/BigQuery tem estrutura semelhante, mas o diferencial do ClickHouse é permitir o ajuste explícito da política de cache.
Em um cliente de publicidade da KGA, adotamos um design de 3 camadas — "últimos 30 dias = hot (NVMe cache residente), 31 a 180 dias = warm (S3, carregado para NVMe sob demanda), acima de 180 dias = cold (S3 Glacier, consultado diretamente via Athena)" — e reduzimos os custos de armazenamento em 80%. O desempenho de consulta das camadas hot/warm é praticamente equivalente; apenas a cold é 10 a 20 vezes mais lenta, o que é aceitável pois raramente há necessidade de interagir de forma interativa com dados com mais de 180 dias.
As Armadilhas dos Workloads em Japonês
Listamos cinco desafios específicos da análise de dados em empresas japonesas.
1. Fuso horário: Bugs de deslizamento de um dia na fronteira de datas devido à mistura de JST (UTC+9) e UTC continuam frequentes em 2026. No ClickHouse, use explicitamente o parâmetro de fuso horário `'Asia/Tokyo'` no `DateTime64`; no BigQuery/Snowflake, adote rigorosamente armazenamento em UTC com conversão no momento da exibição. O DuckDB estabilizou isso na versão 1.2 com o tipo `TIMESTAMPTZ`.
2. Caracteres multibyte e collation: A comparação de nomes de clientes/produtos contendo espaços de largura total, alfanuméricos de meia/largura total e kanji arcaicos exige mais do que simples comparação de bytes UTF-8. O ClickHouse usa a extensão ICU; o DuckDB usa funções de normalização NFKC. Quando se usa como chave de agregação, é regra incluir um pipeline de normalização antecipada.
3. Números kanji e eras japonesas: Expressões como "Reiwa sexto ano, março" são inevitáveis em projetos para órgãos governamentais. O ideal é não tentar resolvê-las em nível SQL, mas normalizá-las para ISO 8601 durante a ingestão.
4. CP932/Shift_JIS misturado: Ainda aparece em exportações de CSV de sistemas legados de core business. A opção `encoding` do `read_csv` do DuckDB passou para GA oficial na versão 1.2. No ClickHouse, use a função `INPUT` para conversão.
5. Katakana de meia largura: Ainda presente em dados bancários. A conversão para largura total via NFKC faz "ｶ" e "カ" se tornarem equivalentes, mas isso gera problemas quando os dados originais esperam meia largura como chave. Defina as regras de conversão cedo e documente-as.
A Arquitetura Recomendada para 2026
O "stack moderno de dados analíticos" que a KGA recomenda aos clientes tem a seguinte divisão de responsabilidades.
- DWH central (Snowflake / BigQuery / Databricks): análise transversal da empresa, finanças, métricas de gestão. Abre para o exterior via escrita em lakehouse (Iceberg).
- OLAP em tempo real (ClickHouse Cloud): dashboards em escala de segundos, eventos de anúncio/jogo/IoT, APM.
- Notebook/análise local (DuckDB + MotherDuck): experimentação de cientistas de dados, geração de data marts intermediários.
- Visualização no browser (DuckDB-WASM): dashboards públicos, frontend leve de BI interno.
- OLTP+Analytics no edge (Turso): banco por tenant em SaaS com distribuição geográfica.
Integrar essas 5 camadas com uma Semantic Layer (como Cube.dev) e extrair tudo por linguagem natural a partir de agentes de IA é o ponto de chegada do "modern data stack" versão 2026. Em vez de depender de um único fornecedor, a arquitetura de maior custo-benefício e escalabilidade a longo prazo é aquela que escolhe a ferramenta ideal para cada papel e as conecta por metadados e semântica.