Análise de petabytes em tempo real sem abrandar a sua base de dados de produção
Separar as transações da análise
O resultado: uma consulta no painel de controlo que deveria demorar 200 ms demora 40 segundos enquanto a análise percorre 500M de linhas, sobrecarregando o CPU e as 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 se possa resolver com ajustes; em vez disso, exige uma mudança na arquitetura: precisa de parar de executar consultas pesadas na sua base de dados de produção.
Mantenha o PostgreSQL focado em leituras e escritas transacionais, enquanto o OVHcloud Managed ClickHouse trata das consultas analíticas. Para análise de dados de petabytes em tempo real, o armazenamento de objetos compatível com S3 oferece uma camada de capacidade escalável para além do armazenamento primário de alta velocidade, permitindo que o seu ambiente analítico cresça sem expandir a base de dados de produção.
Desempenho e controlo à escala
![[object Object]](https://assets.ovhcloud.com/1fipjkCd6Fynpkj2pu4pL37bz_sYmY1YjFkODJlY2IyOGI5/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_79aa0c4f.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fiX5E4qzpXh67Ljo5AmdpyC4_sOTg4ZGYwMzQ5ZmJhOTY0/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_2d4e9ac8.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fipChngFS3mvuo2AkLC4LAjh_sZGYyMTFhOGIzZGFjOWVm/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_1f60228d.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fid6rzboLjodqmFX8pbmmpr8_sZDc4MTgzZjQ2OTg2NTIw/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_0703c5fb.svg){kind=small}
Por que razão o dimensionamento de bases de dados de produção é insuficiente para a procura analítica
Pressão sobre bases de dados transacionais
As bases de dados transacionais são excelentes para consultas, inserções e atualizações rápidas. A análise de dados em petabytes em tempo real cria uma procura diferente: scans abrangentes, junções complexas e agregações repetidas que competem com o tráfego de produção por CPU, memória e capacidade de armazenamento. Uma instância da base de dados de produção da Cloud Pública é criada para transações, não para análise. Quando as equipas comerciais começam a solicitar painéis de controlo em tempo real, deteção de fraudes ou consultas de segmentação de clientes com base em terabytes de dados históricos... bem, o desempenho entra em colapso.
Limitações das réplicas de leitura
As réplicas de leitura em Bases de Dados de Cloud Pública são a primeira resposta mais comum à pressão analítica exercida sobre as bases de dados de produção. Estas aliviam o tráfego de leitura do nó primário, mas não corrigem a incompatibilidade arquitetónica. 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 I/O. A latência da aplicação aumenta, os SLA estão em risco e os casos de utilização em tempo real, como a deteção de fraudes ou a monitorização de anomalias, tornam-se impossíveis.
Separação duradoura dos volumes de trabalho
Uma abordagem duradoura separa os volumes de trabalho. O Apache Kafka transmite eventos consolidados para uma plataforma dedicada criada para análises à escala de petabytes. As bases de dados de produção continuam a processar transações, enquanto o ambiente analítico se adapta de forma independente para lidar com grandes volumes de dados, análise em tempo real, inteligência artificial e inteligência empresarial.
Atribuir cada volume de trabalho ao motor correto
Armazenam dados linha a linha, otimizados para consultar 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 mil milhões de linhas para agregações complexas. Utilizam o armazenamento colunar, em que 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 «receita» e «data», ignorando tudo o resto. Assim, por exemplo, no ClickHouse, as operações são executadas de forma 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.
Por mais que se faça indexação de dados, otimização de consultas ou atualizações de hardware, uma base de dados orientada por linhas nunca será eficiente em scans colunares. As arquiteturas são fundamentalmente diferentes.
Escolher um padrão de carregamento para cada fonte de dados
Streaming
Realizar eventos de forma contínua quando os painéis operacionais e os alertas dependem de informações com baixa latência.
Processamento em lote
Utilizar o batch ETL com Airflow para agendar preenchimentos históricos, exportações periódicas e carregamentos de fontes em massa.
Captura de Alteração de Dados
Propagar as alterações confirmadas na base de dados, limitando simultaneamente o trabalho adicional na fonte transacional.
Carregamento direto
Permitir que as aplicações escrevem eventos analíticos diretamente quando as suas equipas detêm e gerem o contrato de eventos.
Separar OLTP de OLAP
Quando consulta SUM(revenue) em 5 mil milhões de linhas, lê apenas a coluna «revenue», ignorando tudo o resto. Isto reduz as operações de I/O 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 «receita» na cache da CPU e aplicando operações a todo o volume do vetor numa única instrução. Isto reduz significativamente a sobrecarga do CPU.
Esta combinação permite realizar 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 que uma instância de PostgreSQL demora minutos.
![[object Object]](https://assets.ovhcloud.com/1fiz3Ewd3ACopFnjLbkLvoSdp_sYjBlNTU5YjQyYWVjNjdl/76542f62-8c49-48e5-92ec-910825c8d69c_ima_e302634e.png)
Concebido para garantir rapidez, resiliência e governação
Batch ETL
O Batch ETL é 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 o dbt e carregue-os para o ClickHouse. O Airflow orquestra o pipeline e as tarefas cron geram scripts simples.
Isto funciona quando não é necessária uma atualização minuto a minuto. Os painéis de controlo por hora são adequados para muitos casos de negócio, e o processamento em lote é mais fácil de depurar e monitorizar.
A desvantagem é a latência que acarreta. Os dados ficam desatualizados entre os lotes, pelo que não é possível efetuar a deteção de fraudes em tempo real nem a personalização dinâmica. O Batch ETL é a opção certa para quem está a começar a utilizar o ClickHouse, não tem experiência com o processamento de fluxos de dados ou tolera dados com poucas horas de atraso.
CDC em tempo real
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 dados do Kafka e insere-os imediatamente.
As ferramentas de CDC conseguem uma latência inferior a um segundo ou até mesmo de alguns segundos, possibilitando a análise de dados em tempo real: deteção de fraudes que identifica e bloqueia as transações assim que acontecem, monitorização de anomalias que gera alertas em segundos e personalização que reage instantaneamente para suportar o comportamento do utilizador.
Armazenamento em camadas para manter os custos lineares à escala de petabytes
Armazenar petabytes em SSD é excessivamente caro. O armazenamento em camadas move os dados mais antigos para um 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 armazenados em SSD NVMe.
Os dados mais antigos são migrados automaticamente para um bucket do OVHcloud Object Storage a um custo muito mais baixo, permitindo ainda consultas rápidas, uma vez que o ClickHouse apenas lê as colunas necessárias. Os custos para os engenheiros mantêm-se lineares à medida que a escala aumenta: cada terabyte adicional custa o mesmo, seja com 10 TB ou 100 TB.
Pré-agregação no momento do carregamento
Mesmo com armazenamento de dados colunar, analisar dados brutos de cada vez é dispendioso.
As vistas materializadas pré-calculam agregados no momento do carregamento
No ClickHouse, uma vista materializada é um pipeline ativo, não um instantâneo passivo. Ao introduzir dados, o ClickHouse avalia automaticamente a consulta da vista e grava os resultados numa tabela separada.
Se estiver a carregar 100 000 eventos por segundo com uma vista que agrega por minuto e segmento, o ClickHouse calcula esses agregados em tempo real.
Porque é que o ClickHouse é o motor certo para análise em tempo real
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 de dados demoram de segundos a dezenas de segundos.
O ClickHouse oferece um preço estável baseado em recursos com elevada concorrência e escalabilidade eficiente, ideal para análises interativas em tempo real. O Redshift é a melhor opção para o armazenamento de dados em batch com cargas de trabalho previsíveis e infraestrutura AWS existente. O BigQuery destaca-se em análises sem servidor, com consultas esporádicas e para equipas que desejam zero sobrecarga operacional.
O ClickHouse utiliza um dialeto SQL que é 90 % compatível com a experiência de desenvolvimento SQL standard, 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 JOIN e subconsultas complexas podem necessitar de otimização.
Explore o OVHcloud Managed ClickHouse ou trabalhe com os nossos especialistas para definir uma arquitetura de acordo com o volume, a atualidade, o período de retenção e a simultaneidade das consultas dos seus dados.