QuintoAndar: dados de cliente, da arquitetura Lambda para um único caminho no ClickHouse

01 · CONTEXTO

A plataforma de dados de cliente do QuintoAndar

A equipe da plataforma de dados de cliente (CDP) do QuintoAndar coleta, integra e unifica dados sobre inquilinos, proprietários e corretores. Segundo o líder técnico da equipe, a plataforma coleta mais de 1 bilhão de eventos por mês de mais de 14 milhões de usuários, com quase 900 milhões de eventos brutos mensais indo para o ClickHouse.

Esses dados voltam para chatbots e serviços internos em cerca de 300 milhões de requisições de API por mês. Eles nascem no rastreio de usuários em dispositivos móveis e na captura de mudanças (CDC) de bancos transacionais, transmitidos por Kafka, e chegam a um gateway de eventos próprio, onde a equipe aplica governança, executa transformações e enriquece os eventos no caminho.

02 · ARQUITETURA ANTERIOR

Lambda clássica: um caminho quente e um frio

A arquitetura anterior se dividia nas linhas clássicas da arquitetura Lambda. O caminho quente era o Datazord, outro serviço próprio baseado em Postgres, que consumia os tópicos de saída do gateway e servia informações de usuário a chatbots e outros consumidores internos pelo seu próprio banco Postgres, escolhido para leituras de baixa latência.

O caminho frio usava Kafka Connect para despejar tudo numa zona de pouso no data lake, onde workflows Databricks ativos o tempo todo o processavam numa camada silver. Dessa camada podiam puxar os ETLs analíticos e o Hightouch, a ferramenta de ativação de usuários da empresa.

1. Eventos de rastreio móvel e de CDC chegam ao gateway de eventos, que aplica governança, transformações e enriquecimento.

2. No caminho quente, o Datazord consome os tópicos de saída e serve chatbots e consumidores internos pelo seu próprio Postgres.

3. No caminho frio, o Kafka Connect despeja os dados na zona de pouso e os workflows Databricks geram a camada silver.

4. Os ETLs analíticos e o Hightouch leem da camada silver do caminho frio.

5. Os pontos de dor da época: operações MERGE INTO constantes sobre tabelas Delta no caminho frio e um Postgres que parecia a ferramenta errada para o volume de eventos no caminho quente.

03 · O PROBLEMA

O custo de manter dois caminhos

Segundo o líder técnico, havia três problemas. Primeiro, a equipe mantinha duas bases de código separadas, um imposto conhecido de quem já operou uma arquitetura Lambda. Segundo, no caminho frio, volumes enormes de eventos duplicados exigiam operações MERGE INTO constantes sobre tabelas Delta. Terceiro, a instância Postgres da camada quente começava a parecer a ferramenta errada para o volume de eventos que passava por ela.

Nas palavras dele, duplicar todos esses milhões de eventos a cada vez ficava caro, não só em custo, mas em tempo.

04 · A DECISÃO

Um gateway gravando direto no ClickHouse

A resposta da equipe foi deixar de tratar os tópicos Kafka como a saída do pipeline e fazer o gateway de eventos gravar direto no ClickHouse. Na nova arquitetura, o Datazord passaria a atender suas requisições de API a partir do ClickHouse, em vez do próprio Postgres, ainda respondendo em menos de um segundo. Isso eliminaria a zona de pouso, as operações MERGE INTO constantes e a necessidade de uma segunda base de código.

1. O gateway de eventos grava direto no ClickHouse, e os tópicos de saída deixam de ser o destino do pipeline.

2. O Datazord passa a servir a API a partir do ClickHouse, e não mais de um Postgres próprio.

3. Com esse desenho, saem a zona de pouso, os MERGE INTO constantes e a segunda base de código.

4. Trino e Spark alcançam as tabelas do CDP pelos conectores, e o ClickHouse lê tabelas Delta do data lake.

A equipe temia se isolar do restante da organização de dados, que usa Superset sobre Trino. Na prática, os conectores do ClickHouse permitiram que Trino e Spark alcançassem as tabelas do CDP, e o ClickHouse também lê tabelas Delta do data lake da empresa.

05 · O OBSTÁCULO

Onde está o ClickHouse?

O time de marketing queria usar o Customer Studio, do Hightouch, para montar audiências, segmentar usuários, rodar testes A/B e montar jornadas de várias etapas. Só que a lista de fontes que o recurso suporta, com Snowflake, Databricks, BigQuery, Redshift, Athena, Synapse, MS SQL Server, PostgreSQL, Greenplum e Microsoft Fabric, não trazia o ClickHouse.

O Databricks era o único mecanismo compatível já presente na stack, mas a equipe central de dados havia decidido sair do Databricks SQL Warehouse pelo custo alto, preferindo alternativas de código aberto como o Trino. O Trino também não era suportado, e sobrou uma opção: Postgres.

06 · A PONTE

Postgres gerenciado como interface universal

O mecanismo é a extensão pg_clickhouse. Segundo o líder, a configuração é simples: criar a extensão, criar um servidor externo apontando para o ClickHouse, criar um esquema e importar as tabelas externas. Depois disso, as tabelas do ClickHouse podem ser consultadas como tabelas Postgres comuns, com junções e agregações empurradas para o ClickHouse em vez de trazidas de volta ao Postgres.

1. O Hightouch não tinha o ClickHouse entre as fontes do Customer Studio.

2. Como o Trino também não era suportado, restou conectar o Hightouch a um Postgres.

3. O Postgres gerenciado empurra as consultas analíticas para o ClickHouse, onde o gateway já grava os eventos.

4. O estado do Lightning Sync, com uma tabela de planejamento e uma de auditoria, fica no próprio Postgres, em armazenamento NVMe.

5. Para o caso do Hightouch, o líder diz que o ida e volta entre Postgres e ClickHouse é desprezível.

Para o líder, a conexão faz dois trabalhos: o Postgres persiste dados como um banco OLTP, enquanto as consultas analíticas rodam no ClickHouse. Isso não abre tudo: ainda é preciso criar usuários e papéis e conceder o acesso desejado.

Com isso, o ClickHouse vira um banco plug-and-play ao qual se conecta qualquer ferramenta de terceiros que suporte Postgres.

07 · LIÇÕES

O que levar para a sua entrevista