ClickHouse como destino de dados: o guia completo para data teams
ClickHouse como destino de dados: entenda o que é, quando faz sentido usar e como ingerir dados em um banco ClickHouse.



Cada vez mais times de dados precisam responder perguntas em milissegundos sobre volumes que crescem todo dia: eventos de produto, logs de aplicação, métricas operacionais, dashboards consultados em tempo real por dezenas de usuários ao mesmo tempo. O data warehouse tradicional continua essencial para modelagem analítica ampla, mas ele não foi desenhado para esse tipo específico de carga. É aí que o ClickHouse entra na conversa.
Neste artigo, vamos cobrir:
O que é o ClickHouse
Por que considerar o ClickHouse como destino de dados
Os principais casos de uso
A diferença entre ClickHouse e um data warehouse tradicional
Como funciona ingestão de dados no ClickHouse
Como ativar o destino ClickHouse na Erathos
O que é o ClickHouse
O ClickHouse é um sistema de gerenciamento de banco de dados open source, orientado a colunas (columnar), desenhado especificamente para consultas analíticas (OLAP) sobre grandes volumes de dados. Ele existe também como serviço gerenciado, o ClickHouse Cloud.
A diferença estrutural em relação a um banco transacional (OLTP) está em como o dado é armazenado e lido. Um banco orientado a linhas otimiza para acessar um registro inteiro rapidamente, o padrão típico de uma aplicação. Um banco orientado a colunas, como o ClickHouse, armazena e comprime cada coluna separadamente, o que permite escanear e agregar bilhões de linhas tocando apenas as colunas necessárias para a query, com execução vetorizada.
Esse desenho é o motivo pelo qual o ClickHouse virou referência para cargas de trabalho onde velocidade de leitura sobre alto volume é o requisito central, não só volume armazenado.
Por que usar o ClickHouse como destino de dados
Historicamente, "destino de dados" era sinônimo de data warehouse: BigQuery, Snowflake, Redshift, Databricks. Faz sentido, esses sistemas são otimizados para responder pergunta de negócio sobre histórico amplo, com latência de segundos a minutos sendo aceitável para a maioria dos casos de uso analíticos.
Mas existe uma classe de carga de trabalho onde essa latência não é aceitável:
Um dashboard de produto consultado por dezenas de usuários ao mesmo tempo, que precisa responder em milissegundos
Uma pipeline de observabilidade que precisa agregar logs e métricas em tempo real
Uma análise de funil ou cohort sobre uma tabela de eventos com bilhões de linhas, atualizada continuamente
Um caso de uso onde o volume de escrita é alto e constante, e o sistema de destino precisa acompanhar esse ritmo sem degradar a leitura
Nesses casos, forçar um data warehouse tradicional a servir como fonte de leitura direta costuma custar caro de duas formas: latência acima do que o produto tolera, e custo por query que sobe rápido com uso intenso. O ClickHouse existe justamente para esse padrão de acesso, agregação pesada, alta concorrência de leitura, resposta em milissegundos.
Casos de uso para ClickHouse como destino
1. Dashboards de produto em tempo real
Times que expõem métricas de uso, engajamento ou performance dentro do próprio produto, para o cliente final ou para uso interno, precisam de um destino que responda rápido mesmo com consultas concorrentes. Ingerir os dados de origem (produto, CRM, billing) no ClickHouse permite servir esses dashboards sem a latência típica de um warehouse consultado em tempo real.
2. Analytics de eventos e logs em escala
Tabelas de eventos crescem rápido, e a maioria das perguntas sobre elas envolve agregação (contagem, soma, percentil) sobre uma janela de tempo. É exatamente o padrão de acesso para o qual o armazenamento colunar do ClickHouse foi otimizado.
3. Observabilidade e métricas operacionais
Dados de monitoramento, métricas de infraestrutura e logs de aplicação seguem o mesmo padrão de alto volume de escrita com leitura analítica. Consolidar essas fontes no ClickHouse via Erathos evita manter um pipeline de ingestão próprio para cada fonte de telemetria.
4. Análise de funil e cohort em alta cardinalidade
Perguntas como "qual a taxa de conversão por cohort de usuário, segmentada por canal e por semana" exigem agregação sobre dimensões de alta cardinalidade. Em volume alto, esse tipo de query costuma ser onde um data warehouse tradicional começa a custar caro ou demorar demais para retornar.
ClickHouse vs. data warehouse: quando usar cada um
Não é uma questão de substituir um pelo outro. Na prática, os dois costumam coexistir no mesmo stack, cada um resolvendo um tipo de carga.
Critério | Data warehouse tradicional | ClickHouse |
|---|---|---|
Otimizado para | Modelagem analítica ampla, histórico de negócio | Agregações em milissegundos sobre alto volume |
Latência típica | Segundos a minutos | Milissegundos a segundos |
Padrão de consulta ideal | Queries analíticas pontuais, relatórios, BI | Dashboards consultados com alta frequência e concorrência |
Caso de uso ideal | Modeling, BI corporativo, análise histórica ampla | Produto, observabilidade, eventos em escala |
Times maduros costumam operar os dois lado a lado: o warehouse para a camada de modelagem e BI corporativo, o ClickHouse para as cargas onde velocidade de leitura sobre alto volume é o requisito central. A pergunta certa é: quem vai consultar esse dado, com que frequência e com que expectativa de latência?
Como funciona a ingestão de dados no ClickHouse
Existem três caminhos principais para colocar dados em um banco ClickHouse:
Inserts diretos via cliente ou driver. Funciona para volumes baixos e dados gerados pela própria aplicação, mas não escala para consolidar múltiplas fontes externas.
Scripts customizados rodando em cron. Flexível no começo, mas vira passivo de manutenção rápido. Cada fonte nova é um projeto de engenharia à parte, com lógica de retry, alerta de falha e adaptação a mudanças de schema para manter na mão.
Ferramenta de ingestão dedicada. Você aponta a fonte, escolhe o ClickHouse como destino e a plataforma cuida da extração, dos alertas e da observabilidade de cada execução.
Para qualquer cenário em que o ClickHouse precisa receber dados de mais de uma fonte, o caminho 3 é o que evita que a manutenção de ingestão cresça junto com o número de fontes.
Como ativar o destino ClickHouse na Erathos
A Erathos se conecta a qualquer instância ClickHouse, seja no ClickHouse Cloud ou em um deployment self-hosted (VM, Kubernetes, Docker ou qualquer outro ambiente). Em ambos os casos, a conexão usa as mesmas quatro credenciais: Host, Port, Username e Password.
No ClickHouse Cloud, essas informações ficam disponíveis no painel do serviço:
Host: a URL do serviço, geralmente terminando em
.clickhouse.cloudPort: tipicamente
8443para HTTPSUsername: o usuário de acesso ao banco (o padrão costuma ser
default)Password: a senha do serviço, exibida apenas uma vez no momento da criação (se perdida, é necessário resetar nas configurações do serviço)
Em um deployment self-hosted, essas informações vêm da configuração do seu próprio servidor ou do administrador do banco:
Host: o hostname ou IP do seu servidor ClickHouse
Port: a porta exposta pelo servidor (comumente
8123para HTTP ou8443para HTTPS, dependendo da configuração)Username e Password: o usuário com as permissões necessárias e sua senha
É preciso garantir que o servidor esteja acessível pela Erathos, incluindo o IP da plataforma (
35.212.87.86) na whitelist do firewall
Passos rápidos para configurar
Reúna host, porta, usuário e senha (via console do ClickHouse Cloud ou com o administrador do seu ClickHouse self-hosted)
Se estiver usando self-hosted, confirme que o firewall libera o IP da Erathos
Na Erathos, vá em Settings → Destination, selecione ClickHouse e preencha os quatro campos de conexão
Salve a configuração para finalizar a conexão. Ao criar a primeira pipeline apontando uma fonte para o destino ClickHouse, você escolhe também o schema de destino, a plataforma cuida da criação e evolução das tabelas a partir daí
A documentação oficial do destino ClickHouse tem o passo a passo completo.
Conclusão
A pergunta que costumava ser "o warehouse dá conta desse volume?" está virando, cada vez mais, "o warehouse responde rápido o suficiente para esse caso de uso?". Para dashboard de produto, observabilidade e análise de eventos em alto volume, a resposta frequentemente é não, e é aí que o ClickHouse entra como peça complementar do stack, não como substituto. O que muda a experiência de manter esse destino no dia a dia é a mesma coisa que muda para qualquer outro: ingestão com observabilidade real, em vez de um script que só alguém do time entende.
Se você quer ingerir dados no ClickHouse de forma controlada, observável e sem precisar manter scripts próprios, conheça o destino ClickHouse da Erathos.
FAQ
O ClickHouse substitui um data warehouse? Sim, em vários cenários. O ClickHouse é um banco de dados OLAP colunar de altíssima performance, e hoje é usado inclusive para workloads de data warehousing tradicional, não só para casos de nicho. Onde ele se destaca especialmente é em arquiteturas com ingestão massiva e exigência de velocidade extrema: dashboards em tempo real, eventos em escala, observabilidade. Times com ecossistema já consolidado em torno de outro warehouse, ou que priorizam modelagem corporativa ampla acima de latência, costumam operar os dois lado a lado em vez de migrar totalmente.
Posso usar o ClickHouse como destino para qualquer fonte que a Erathos já suporta? Sim, o ClickHouse está disponível como destino junto às demais fontes da plataforma, com a mesma configuração usada para os outros destinos.
Qual a frequência mínima de sincronização? Depende da fonte de origem. A Erathos suporta agendamentos de minutos até diários, a nível de tabela.
Funciona com ClickHouse self-hosted, fora do ClickHouse Cloud? Sim. A Erathos se conecta tanto ao ClickHouse Cloud quanto a deployments self-hosted (VM, Kubernetes, Docker ou qualquer outro ambiente), usando as mesmas quatro credenciais de conexão. Pra self-hosted, é preciso liberar o IP da Erathos no firewall do servidor.
Preciso criar as tabelas manualmente no ClickHouse? Não. A Erathos gerencia a conexão automaticamente: você fornece as credenciais de acesso e escolhe o schema de destino, e a plataforma cuida da criação e evolução das tabelas conforme a fonte muda.
Cada vez mais times de dados precisam responder perguntas em milissegundos sobre volumes que crescem todo dia: eventos de produto, logs de aplicação, métricas operacionais, dashboards consultados em tempo real por dezenas de usuários ao mesmo tempo. O data warehouse tradicional continua essencial para modelagem analítica ampla, mas ele não foi desenhado para esse tipo específico de carga. É aí que o ClickHouse entra na conversa.
Neste artigo, vamos cobrir:
O que é o ClickHouse
Por que considerar o ClickHouse como destino de dados
Os principais casos de uso
A diferença entre ClickHouse e um data warehouse tradicional
Como funciona ingestão de dados no ClickHouse
Como ativar o destino ClickHouse na Erathos
O que é o ClickHouse
O ClickHouse é um sistema de gerenciamento de banco de dados open source, orientado a colunas (columnar), desenhado especificamente para consultas analíticas (OLAP) sobre grandes volumes de dados. Ele existe também como serviço gerenciado, o ClickHouse Cloud.
A diferença estrutural em relação a um banco transacional (OLTP) está em como o dado é armazenado e lido. Um banco orientado a linhas otimiza para acessar um registro inteiro rapidamente, o padrão típico de uma aplicação. Um banco orientado a colunas, como o ClickHouse, armazena e comprime cada coluna separadamente, o que permite escanear e agregar bilhões de linhas tocando apenas as colunas necessárias para a query, com execução vetorizada.
Esse desenho é o motivo pelo qual o ClickHouse virou referência para cargas de trabalho onde velocidade de leitura sobre alto volume é o requisito central, não só volume armazenado.
Por que usar o ClickHouse como destino de dados
Historicamente, "destino de dados" era sinônimo de data warehouse: BigQuery, Snowflake, Redshift, Databricks. Faz sentido, esses sistemas são otimizados para responder pergunta de negócio sobre histórico amplo, com latência de segundos a minutos sendo aceitável para a maioria dos casos de uso analíticos.
Mas existe uma classe de carga de trabalho onde essa latência não é aceitável:
Um dashboard de produto consultado por dezenas de usuários ao mesmo tempo, que precisa responder em milissegundos
Uma pipeline de observabilidade que precisa agregar logs e métricas em tempo real
Uma análise de funil ou cohort sobre uma tabela de eventos com bilhões de linhas, atualizada continuamente
Um caso de uso onde o volume de escrita é alto e constante, e o sistema de destino precisa acompanhar esse ritmo sem degradar a leitura
Nesses casos, forçar um data warehouse tradicional a servir como fonte de leitura direta costuma custar caro de duas formas: latência acima do que o produto tolera, e custo por query que sobe rápido com uso intenso. O ClickHouse existe justamente para esse padrão de acesso, agregação pesada, alta concorrência de leitura, resposta em milissegundos.
Casos de uso para ClickHouse como destino
1. Dashboards de produto em tempo real
Times que expõem métricas de uso, engajamento ou performance dentro do próprio produto, para o cliente final ou para uso interno, precisam de um destino que responda rápido mesmo com consultas concorrentes. Ingerir os dados de origem (produto, CRM, billing) no ClickHouse permite servir esses dashboards sem a latência típica de um warehouse consultado em tempo real.
2. Analytics de eventos e logs em escala
Tabelas de eventos crescem rápido, e a maioria das perguntas sobre elas envolve agregação (contagem, soma, percentil) sobre uma janela de tempo. É exatamente o padrão de acesso para o qual o armazenamento colunar do ClickHouse foi otimizado.
3. Observabilidade e métricas operacionais
Dados de monitoramento, métricas de infraestrutura e logs de aplicação seguem o mesmo padrão de alto volume de escrita com leitura analítica. Consolidar essas fontes no ClickHouse via Erathos evita manter um pipeline de ingestão próprio para cada fonte de telemetria.
4. Análise de funil e cohort em alta cardinalidade
Perguntas como "qual a taxa de conversão por cohort de usuário, segmentada por canal e por semana" exigem agregação sobre dimensões de alta cardinalidade. Em volume alto, esse tipo de query costuma ser onde um data warehouse tradicional começa a custar caro ou demorar demais para retornar.
ClickHouse vs. data warehouse: quando usar cada um
Não é uma questão de substituir um pelo outro. Na prática, os dois costumam coexistir no mesmo stack, cada um resolvendo um tipo de carga.
Critério | Data warehouse tradicional | ClickHouse |
|---|---|---|
Otimizado para | Modelagem analítica ampla, histórico de negócio | Agregações em milissegundos sobre alto volume |
Latência típica | Segundos a minutos | Milissegundos a segundos |
Padrão de consulta ideal | Queries analíticas pontuais, relatórios, BI | Dashboards consultados com alta frequência e concorrência |
Caso de uso ideal | Modeling, BI corporativo, análise histórica ampla | Produto, observabilidade, eventos em escala |
Times maduros costumam operar os dois lado a lado: o warehouse para a camada de modelagem e BI corporativo, o ClickHouse para as cargas onde velocidade de leitura sobre alto volume é o requisito central. A pergunta certa é: quem vai consultar esse dado, com que frequência e com que expectativa de latência?
Como funciona a ingestão de dados no ClickHouse
Existem três caminhos principais para colocar dados em um banco ClickHouse:
Inserts diretos via cliente ou driver. Funciona para volumes baixos e dados gerados pela própria aplicação, mas não escala para consolidar múltiplas fontes externas.
Scripts customizados rodando em cron. Flexível no começo, mas vira passivo de manutenção rápido. Cada fonte nova é um projeto de engenharia à parte, com lógica de retry, alerta de falha e adaptação a mudanças de schema para manter na mão.
Ferramenta de ingestão dedicada. Você aponta a fonte, escolhe o ClickHouse como destino e a plataforma cuida da extração, dos alertas e da observabilidade de cada execução.
Para qualquer cenário em que o ClickHouse precisa receber dados de mais de uma fonte, o caminho 3 é o que evita que a manutenção de ingestão cresça junto com o número de fontes.
Como ativar o destino ClickHouse na Erathos
A Erathos se conecta a qualquer instância ClickHouse, seja no ClickHouse Cloud ou em um deployment self-hosted (VM, Kubernetes, Docker ou qualquer outro ambiente). Em ambos os casos, a conexão usa as mesmas quatro credenciais: Host, Port, Username e Password.
No ClickHouse Cloud, essas informações ficam disponíveis no painel do serviço:
Host: a URL do serviço, geralmente terminando em
.clickhouse.cloudPort: tipicamente
8443para HTTPSUsername: o usuário de acesso ao banco (o padrão costuma ser
default)Password: a senha do serviço, exibida apenas uma vez no momento da criação (se perdida, é necessário resetar nas configurações do serviço)
Em um deployment self-hosted, essas informações vêm da configuração do seu próprio servidor ou do administrador do banco:
Host: o hostname ou IP do seu servidor ClickHouse
Port: a porta exposta pelo servidor (comumente
8123para HTTP ou8443para HTTPS, dependendo da configuração)Username e Password: o usuário com as permissões necessárias e sua senha
É preciso garantir que o servidor esteja acessível pela Erathos, incluindo o IP da plataforma (
35.212.87.86) na whitelist do firewall
Passos rápidos para configurar
Reúna host, porta, usuário e senha (via console do ClickHouse Cloud ou com o administrador do seu ClickHouse self-hosted)
Se estiver usando self-hosted, confirme que o firewall libera o IP da Erathos
Na Erathos, vá em Settings → Destination, selecione ClickHouse e preencha os quatro campos de conexão
Salve a configuração para finalizar a conexão. Ao criar a primeira pipeline apontando uma fonte para o destino ClickHouse, você escolhe também o schema de destino, a plataforma cuida da criação e evolução das tabelas a partir daí
A documentação oficial do destino ClickHouse tem o passo a passo completo.
Conclusão
A pergunta que costumava ser "o warehouse dá conta desse volume?" está virando, cada vez mais, "o warehouse responde rápido o suficiente para esse caso de uso?". Para dashboard de produto, observabilidade e análise de eventos em alto volume, a resposta frequentemente é não, e é aí que o ClickHouse entra como peça complementar do stack, não como substituto. O que muda a experiência de manter esse destino no dia a dia é a mesma coisa que muda para qualquer outro: ingestão com observabilidade real, em vez de um script que só alguém do time entende.
Se você quer ingerir dados no ClickHouse de forma controlada, observável e sem precisar manter scripts próprios, conheça o destino ClickHouse da Erathos.
FAQ
O ClickHouse substitui um data warehouse? Sim, em vários cenários. O ClickHouse é um banco de dados OLAP colunar de altíssima performance, e hoje é usado inclusive para workloads de data warehousing tradicional, não só para casos de nicho. Onde ele se destaca especialmente é em arquiteturas com ingestão massiva e exigência de velocidade extrema: dashboards em tempo real, eventos em escala, observabilidade. Times com ecossistema já consolidado em torno de outro warehouse, ou que priorizam modelagem corporativa ampla acima de latência, costumam operar os dois lado a lado em vez de migrar totalmente.
Posso usar o ClickHouse como destino para qualquer fonte que a Erathos já suporta? Sim, o ClickHouse está disponível como destino junto às demais fontes da plataforma, com a mesma configuração usada para os outros destinos.
Qual a frequência mínima de sincronização? Depende da fonte de origem. A Erathos suporta agendamentos de minutos até diários, a nível de tabela.
Funciona com ClickHouse self-hosted, fora do ClickHouse Cloud? Sim. A Erathos se conecta tanto ao ClickHouse Cloud quanto a deployments self-hosted (VM, Kubernetes, Docker ou qualquer outro ambiente), usando as mesmas quatro credenciais de conexão. Pra self-hosted, é preciso liberar o IP da Erathos no firewall do servidor.
Preciso criar as tabelas manualmente no ClickHouse? Não. A Erathos gerencia a conexão automaticamente: você fornece as credenciais de acesso e escolhe o schema de destino, e a plataforma cuida da criação e evolução das tabelas conforme a fonte muda.