Análise de petabytes em tempo real sem impacto na BD
Como analisar petabytes de dados em tempo real sem abrandar a sua base de dados de produção?
Todas as aplicações em crescimento atingem o mesmo ponto de inflexão, onde uma empresa quer consultar uma base de dados PostgreSQL ou MySQL com petabytes de dados, de uma forma para a qual nunca foi concebida.
O resultado: uma consulta de dashboard que deveria demorar 200ms demora 40 segundos, uma vez que a análise verifica 500M de linhas, sobrecarregando a CPU e o I/O. Os utilizadores esperam demasiado tempo pelos resultados das consultas e, no final, todo o acordo de SLA fica em risco.
Não é um problema que possa resolver com ajustes; em vez disso, requer uma mudança na arquitetura: precisa de parar de executar consultas pesadas na sua base de dados de produção.
Neste artigo, aprenderá o padrão de arquitetura para separar OLTP de OLAP, como transmitir dados em segurança para o ClickHouse e porque é que o serviço gerido da OVHcloud é a escolha certa para equipas de SaaS, FinTech, AdTech e comércio eletrónico que escalam para milhares de milhões de linhas.
Porque é que a sua base de dados de produção é o lugar errado para executar análises
Uma instância de base de dados de produção Public Cloud é criada para transações, não para análises. Quando as equipas de negócio começam a pedir dashboards em tempo real, deteção de fraude ou consultas de segmentação de clientes em terabytes de dados históricos... bem, o desempenho colapsa.
Isso acontece não tanto porque a infraestrutura é fraca, mas porque a aplicação está a usar a ferramenta errada para o trabalho.
OLTP vs OLAP
OLTP (processamento de transações online) e OLAP (processamento analítico online) situam-se em extremos opostos do espetro da arquitetura de dados.
Os sistemas OLTP dão prioridade à correção e à precisão ao nível da transação, processando milhares de pequenas escritas e leituras rápidas por segundo. Armazenam dados linha a linha, otimizados para procurar um registo de cliente individual ou atualizar o estado de uma encomenda em milissegundos.
Os sistemas OLAP , pelo contrário, são concebidos para analisar biliões de linhas para agregações complexas. Utilizam armazenamento colunar, onde cada coluna é armazenada de forma independente. Isto significa que, quando consulta SUM(revenue) WHERE date > '2025-01-01', a base de dados lê apenas as colunas de receita e data, ignorando tudo o resto. Portanto, por exemplo no ClickHouse, as operações são executadas em execução vetorizada. O ClickHouse processa matrizes inteiras de valores de uma só vez em vez de linhas individuais, o que reduz drasticamente a sobrecarga da CPU e maximiza a utilização da cache.
Nenhuma quantidade de indexação de dados, otimização de consultas ou atualizações de hardware tornará uma base de dados orientada a linhas eficiente em análises colunares. As arquiteturas são fundamentalmente diferentes.
Porque é que as réplicas de leitura não resolvem o problema
As réplicas de leitura em Public Cloud Databases são a primeira resposta mais comum à pressão analítica sobre bases de dados de produção. Estas aliviam o tráfego de leitura do nó primário, mas não resolvem a incompatibilidade arquitetural.
Uma réplica de leitura pode reduzir a contenção na sua base de dados primária, mas quando executa SELECT SUM(revenue), COUNT(*) FROM events WHERE date >= '2024-01-01' em 500M de linhas, a réplica continua a ler e a descartar quase todas as linhas.
Estas consultas analíticas competem com as transações de produção por CPU, memória e E/S. A latência da aplicação aumenta, os SLAs estão em risco e casos de uso em tempo real, como a deteção de fraude ou a monitorização de anomalias, tornam-se impossíveis.
A consulta de 40 segundos que deveria demorar 200 ms
Eis o cenário típico para uma empresa de plataforma SaaS em expansão ou FinTech que atinge o ponto de inflexão de dados. Uma consulta é executada, com o objetivo de agregar a receita diária por segmento de cliente ao longo de 18 meses (500M de linhas),
O tempo esperado para a execução no modelo de domínio OLAP é de 200 ms, mas o tempo real na plataforma OLTP acaba por ser de 40 segundos. Porquê? Bem, isto é o que acontece em segundo plano:
Leitura completa da tabela: A plataforma PostgreSQL/MySQL tem de ler todas as 500M de linhas porque o índice não ajuda em agregações amplas.
Processamento linha a linha: Cada linha é descomprimida, analisada e avaliada individualmente.
Gargalo de E/S: As leituras de disco dominam — a maior parte dos dados lidos é descartada.
Desperdício de CPU: Ciclos de CPU gastos na análise de linhas em vez da qualidade da agregação.
Pressão de memória: Ordenações grandes e junções hash são despejadas para o disco.
O impacto no negócio é imediato e cumulativo, porque o que deveria ser um dashboard de dados horário pode, na prática, ser gerado apenas uma vez por dia, atrasando as decisões de negócio.
As decisões de negócio são atrasadas porque a análise minuto a minuto torna-se demasiado dispendiosa e as funcionalidades em tempo real tornam-se impossíveis à escala. E isso é importante – a capacidade de resposta em tempo real é essencial para casos de utilização como a deteção de fraudes, personalização e monitorização de anomalias. Estes casos de utilização não são viáveis com uma latência de consulta de 40 segundos.
O padrão de arquitetura: separar OLTP de OLAP
A solução é a separação arquitetural: executar transações numa instância de base de dados OLTP e transmitir dados para uma instância OLAP separada, concebida para analisar milhares de milhões de linhas em menos de um segundo. Cada sistema faz aquilo para que foi concebido, sem comprometer o outro.
Explicação do armazenamento colunar e da execução vetorizada
O PostgreSQL e o MySQL armazenam dados linha a linha, o que faz sentido para transações de engenharia que recuperam registos individuais, mas é terrível para análises que agregam uma coluna em milhares de milhões de linhas. O ClickHouse armazena os dados por coluna.
Ao consultar SUM(revenue) em 5 mil milhões de linhas, lê apenas a coluna revenue, ignorando tudo o resto. Isto reduz a E/S em 90% ou mais e permite uma compressão agressiva, uma vez que os valores numa coluna são semelhantes.
A execução vetorizada é o segundo multiplicador. As bases de dados tradicionais processam uma linha de cada vez. O ClickHouse processa matrizes inteiras de valores de uma só vez, carregando um bloco da coluna revenue para a cache do CPU e aplicando operações em todo o volume do vetor numa única instrução. Isto reduz drasticamente a sobrecarga do CPU.
A combinação permite consultas em menos de um segundo em milhares de milhões de linhas. O armazenamento colunar minimiza as leituras de disco; a execução vetorizada minimiza o trabalho do CPU. O ClickHouse consegue agregar 10 mil milhões de linhas em menos de um segundo, enquanto uma instância de PostgreSQL demora minutos.
Vistas materializadas: pré-agregação no momento da ingestão
Mesmo com armazenamento de dados em colunas, analisar dados brutos de cada vez é dispendioso. As vistas materializadas pré-calculam agregados no momento da ingestão.
No ClickHouse, uma vista materializada é um pipeline ativo, não um instantâneo passivo. Quando insere dados, o ClickHouse avalia automaticamente a consulta da vista e escreve os resultados numa tabela separada.
Se estiver a ingerir 100.000 eventos por segundo com uma vista a agregar por minuto e segmento, o ClickHouse calcula esses agregados em tempo real.
O seu dashboard consulta a tabela pré-agregada em vez de analisar eventos brutos. Isto transfere o custo do tempo de consulta para o tempo de ingestão, aceitando uma pequena sobrecarga de escrita para uma resposta de consulta instantânea. Para dashboards minuto a minuto e deteção de fraude, as vistas materializadas eliminam a latência entre a chegada dos dados e a possibilidade de os consultar.
Também permitem análises de múltiplas resoluções: mantenha dados brutos para forense enquanto mantém agregados horários/diários para dashboards. À medida que os dados envelhecem, consulte agregados mais grosseiros, mantendo o desempenho consistente à medida que escala de terabytes para petabytes.
Armazenamento em níveis para manter os custos lineares à escala de petabytes
Armazenar petabytes em SSDs é proibitivamente caro. O armazenamento em níveis move dados mais antigos para armazenamento de objetos mais barato, mantendo os dados recentes em discos locais rápidos.
Por exemplo, o OVHcloud Managed ClickHouse implementa isto nativamente em ferramentas com processamento de fluxo OVHcloud Object Storage (compatível com S3)*. Os dados recentes (30–90 dias) permanecem em fluxo em SSDs NVMe.
Os dados mais antigos migram automaticamente para um bucket do OVHcloud Object Storage a uma fração do custo, permitindo ainda consultas rápidas, uma vez que o ClickHouse lê apenas as colunas necessárias. Os custos para os engenheiros mantêm-se lineares à medida que escala: cada terabyte adicional custa o mesmo a 10 TB ou 100 TB.
O ClickHouse consulta dados do OVHcloud Object Storage sem Athena, Presto ou Spark. Dados quentes em SSD, dados frios em S3, tudo através da mesma interface SQL. Isto elimina a manutenção de sistemas separados para dados baseados em quentes e frios.
O armazenamento em níveis também simplifica a retenção de dados a longo prazo: mantenha dados brutos indefinidamente para fins de conformidade sem gastar uma fortuna. Consultar dados com 18 meses para investigações? O ClickHouse lê a partir do OVHcloud Object Storage S3*, que é mais lento, mas ainda suficientemente rápido para análises ad-hoc.
Como alimentar dados na sua camada analítica
Assim que separar a instância OLTP das ferramentas OLAP, precisa de mover os dados da sua base de dados de produção para o ClickHouse. Existem três padrões principais, cada um com diferentes compromissos em termos de latência, complexidade e sobrecarga operacional.
ETL em lote com Airflow, dbt ou tarefas cron
O ETL em lote é o ponto de partida mais simples. Extraia dados da sua base de dados de produção de acordo com um agendamento (horário ou diário), transforme-os com dbt e carregue-os para o ClickHouse. O Airflow orquestra o pipeline, ou tarefas cron gerem scripts simples.
Isto funciona quando não precisa de atualizações minuto a minuto. Dashboards horários são adequados para muitos casos de negócio, e o processamento em lote é mais fácil de depurar e monitorizar. Tarefas falhadas são repetidas no agendamento seguinte, e o preenchimento de dados históricos é simples.
O compromisso é a latência que cria. Os dados ficam desatualizados entre lotes, pelo que a deteção de fraude em tempo real ou a personalização em direto não são possíveis. Também está a executar consultas de extração pesadas na produção durante a janela de lote, o que pode causar contenção se não for agendado durante períodos de baixo tráfego. O ETL em lote é adequado quando está a começar com o ClickHouse, não tem experiência em streaming ou tolera dados com uma hora de atraso.
CDC em tempo real com Apache Kafka e Debezium
O Change Data Capture (CDC) transmite cada inserção, atualização e eliminação da produção para o ClickHouse em tempo quase real. O Debezium lê o registo de transações da sua base de dados (WAL para PostgreSQL, binlog para MySQL) e publica as alterações no Apache Kafka. O ClickHouse consome do Kafka e insere imediatamente.
As ferramentas de CDC atingem uma latência de frações de segundo a poucos segundos, permitindo uma análise de dados em tempo real real: deteção de fraude que deteta e bloqueia transações à medida que ocorrem, monitorização de anomalias que alerta em segundos, personalização que reage instantaneamente para apoiar o comportamento do utilizador.
Embora a complexidade da configuração seja maior, o CDC é o padrão para análise em tempo real à escala. A sobrecarga justifica-se quando as decisões de negócio dependem da frescura dos dados. Muitas equipas utilizam Kafka gerido para reduzir a carga, ou começam com lotes e migram para CDC assim que o valor em tempo real é validado.
Escritas diretas da aplicação de forma eficiente para cargas de trabalho puramente orientadas a eventos
A sua aplicação escreve diretamente para as ferramentas do ClickHouse juntamente com a sua base de dados OLTP crítica. Isto funciona melhor para cargas de trabalho orientadas a eventos onde cada ação do utilizador é um evento que vale a pena analisar: visualizações de página, cliques, chamadas de API, dados de sensores. A aplicação envia o evento para ambos os sistemas em paralelo, ou utiliza o ClickHouse como principal e sincroniza com o PostgreSQL para transações.
Isto elimina totalmente a camada de ETL. Sem Kafka, sem Debezium, sem tarefas em lote. A aplicação escreve uma vez, os dados são imediatamente consultáveis e a latência é mínima.
Porque é que o ClickHouse é o motor OLAP certo para análise em tempo real
O ClickHouse foi construído de raiz para análise em tempo real em conjuntos de dados massivos. Ao contrário dos armazéns de dados de propósito geral que otimizam para cargas de trabalho em lote ou se você ou aqueles que otimizam para BI interativo, o ClickHouse prioriza a latência de consulta inferior a um segundo, mesmo ao analisar milhares de milhões de linhas.
Isto torna-o a escolha certa para empresas de SaaS, FinTech, AdTech e comércio eletrónico que necessitam de análises que acompanhem os seus sistemas de produção.
Desempenho de consulta inferior a um segundo :
O ClickHouse atinge uma latência inferior a um segundo em consultas que analisam milhares de milhões de linhas graças ao armazenamento colunar, execução vetorizada e compressão agressiva. Consegue agregar 10 mil milhões de linhas em menos de um segundo, enquanto o PostgreSQL demora minutos e outros armazéns demoram segundos a dezenas de segundos.
ClickHouse vs Redshift vs BigQuery :
O ClickHouse oferece um tarifário estável baseado em recursos, com elevada concorrência e escalabilidade eficiente, ideal para análises interativas em tempo real. O Redshift é o mais adequado para armazenamento de dados orientado a lotes com cargas de trabalho previsíveis e infraestrutura AWS existente. O BigQuery destaca-se na análise sem servidor com consultas esporádicas e equipas que pretendem zero custos operacionais.
SQL do ClickHouse:
O ClickHouse utiliza um dialeto SQL que é 90% compatível com a experiência de desenvolvimento SQL padrão, mas existem diferenças fundamentais. As funções de agregação utilizam tabelas MergeTree com sintaxe de motor específica. A maioria das consultas SELECT traduz-se diretamente, mas JOINs complexos e subconsultas podem necessitar de otimização.
As dicas de migração a gerir incluem testar primeiro as consultas num conjunto de dados anfitrião representativo, utilizar o EXPLAIN do ClickHouse para otimizar os planos de execução de sessão e tirar partido de vistas materializadas para pré-calcular agregações complexas da pilha de ferramentas.
Porquê escolher o ClickHouse Gerido da OVHcloud
O ClickHouse Gerido da OVHcloud é o único ClickHouse gerido nativo oferecido por um fornecedor de cloud europeu, a par das nossas Bases de Dados Geridas para PostgreSQL estabelecidas. Isto significa que não há encaminhamento de dados por terceiros, nem dependência do ClickHouse Cloud, nem fluxos de dados entre fornecedores.
ClickHouse Gerido de um fornecedor da UE: A OVHcloud é o único fornecedor de cloud da região europeia a oferecer um motor ClickHouse gerido nativo. Ao contrário dos concorrentes, onde teria de encaminhar através de serviços de terceiros, a OVHcloud executa o ClickHouse diretamente na sua infraestrutura.
Automático para o Object Storage da OVHcloud: Os dados frios migram automaticamente para o Object Storage da OVHcloud compatível com S3*, mantendo os custos lineares à escala de petabytes. Os dados recentes (30–90 dias) permanecem em SSDs NVMe para a máxima velocidade, enquanto os dados mais antigos são movidos para o Object Storage da OVHcloud a uma fração do custo. Crucialmente, não existem taxas de saída.
Implementações em 3-AZ em Paris e Milão : Os clusters de produção funcionam em três zonas de disponibilidade em Paris ou Milão com um SLA de 99,99% em 3 Z-A, suporte técnico 24/7 incluído e replicação multi-nó para elevada disponibilidade. O serviço Gen3 (desde agosto de 2025) oferece 5× mais armazenamento, 4× mais largura de banda, 2× mais TPS e um arranque 1,5× mais rápido em comparação com a geração anterior; tudo isto é melhor para o escalonamento.
RGPD por conceção, sem exposição ao Cloud Act: A OVHcloud é uma empresa francesa sujeita apenas à legislação francesa/da UE. Todos os dados analíticos permanecem em centros de dados europeus, sem exposição ao Cloud Act que afete os fornecedores dos EUA. Isto é especialmente relevante para dados comportamentais, transações financeiras e dados abrangidos pelo RGPD.
Além disso, os serviços da OVHcloud possuem certificação ISO/IEC 27001/27017/27018/27701 e estão em conformidade com a HDS, com a SecNumCloud em curso. Isso inclui o nosso Managed Apache Kafka para pipelines CDC e o nosso OVHcloud Object Storage (compatível com S3)*.
Para empresas europeias de SaaS, FinTech, AdTech e comércio eletrónico que lidam com dados de clientes da UE, esta garantia de soberania elimina o risco legal de as autoridades dos EUA acederem a dados armazenados em fornecedores de nuvem americanos.
Comece agora: implemente o ClickHouse e ligue-o à sua base de dados de produção
Está pronto para libertar a sua base de dados de produção de consultas analíticas pesadas? A implementação do OVHcloud Managed ClickHouse demora apenas alguns minutos através do painel de controlo ou da API.
Asseguramos que os seus dados permanecem em centros de dados europeus para garantir a privacidade e a observabilidade total, sem taxas de saída, e o armazenamento em níveis para o OVHcloud Object Storage compatível com S3 garante que os custos permanecem previsíveis à medida que escala de terabytes para petabytes.
Inicie hoje o seu cluster de software ClickHouse e veja porque é que mais de 2.000 empresas, incluindo a Tesla, a Bloomberg e a Anthropic, confiam no ClickHouse para análises em tempo real.
*S3 é uma marca registada da Amazon Technologies, Inc. Os serviços da OVHcloud não são de forma alguma patrocinados, aprovados ou filiados à Amazon Technologies, Inc.