10 anos do open source do ClickHouse
(clickhouse.com)- O ClickHouse foi lançado como open source em 15 de junho de 2016 e, ao longo de 10 anos, recebeu contribuições de mais de 2.000 pessoas, tornando-se um projeto de referência entre os bancos de dados analíticos open source
- Seu objetivo é o open source Nível 3: não apenas publicar o código, mas também guias de contribuição, revisão de código, roadmap, CI, releases e documentação
- O ponto de partida foram as limitações de um sistema de análise web baseado em MySQL, e a experiência com OLAPServer e Metrage levou ao processamento orientado a colunas e ao design do MergeTree
- O ClickHouse não é uma extensão sobre um DBMS existente, mas um DBMS implementado do zero, construído gradualmente desde 2009 com representação em colunas, funções de agregação, table engines, compressão, parser SQL, servidor·cliente e ReplicatedMergeTree
- Depois de processar diariamente centenas de bilhões de registros em produção interna em 2014, o projeto passou por textos públicos e aprovação interna em 2015 antes de ser lançado globalmente em 2016
10 anos desde a abertura como open source
- O ClickHouse foi lançado como open source em 15 de junho de 2016
- Desde então, mais de 2.000 pessoas contribuíram, e ele se tornou “o banco de dados analítico open source mais popular”
- O principal objetivo do projeto é não parar em apenas publicar o código, mas tornar o processo de desenvolvimento e de contribuição o mais aberto possível
O nível de open source que o ClickHouse busca
- Existem vários níveis de open source
- Level 0: o código é publicado para leitura, mas nada além disso. Exemplos são publicações em estilo arquivo ou museu, como Doom e MS-DOS
- Level 1: o código é atualizado por commits em um repositório público, mas não necessariamente aceita contribuições. Exemplos: SQLite e Ladybird
- Level 2: aceita contribuições, mas o processo de desenvolvimento não é necessariamente transparente e aberto. A maioria dos projetos open source ativos está aqui
- Level 3: possui guia de contribuição, rastreamento de trabalho, revisão de código, roadmap de desenvolvimento, testes e CI, ciclo de releases, suporte a usuários e documentação
- O ClickHouse busca ser um projeto open source de Level 3
- Outro objetivo é servir como exemplo de código e de práticas de desenvolvimento para quem quiser criar um novo banco de dados
- O código busca ser modular, ortogonal e documentado
- Quando conceitos complexos são necessários, eles são explicados desde o início nos comentários para que o leitor não precise recorrer a livros, Wikipedia ou IA
Um espaço para desenvolvimento em C++ e experimentos de performance
- O ClickHouse é um dos repositórios open source populares em C++ e busca ser também um lugar para aprender recursos modernos da linguagem, como C++23, além de build systems, integração contínua·testes e práticas de code review
- Experimentos com estruturas de dados e otimização de performance também são um uso importante
- Mesmo Pull Requests experimentais que não têm como objetivo ser mesclados são testados no mesmo nível das releases de produção
- É possível validar no ClickHouse experimentos com novos alocadores de memória, bibliotecas de compressão, hash tables, formatos de dados e algoritmos de ordenação
- O roadmap inclui itens experimentais, estranhos e até mesmo engraçados
- Todos os contribuidores recebem crédito no CHANGELOG e na tabela interna system.contributors do banco de dados
- É comum que recursos cuja implementação inicial era incompleta sejam finalizados em conjunto, e mesmo quando todo o código precisa ser reescrito, a intenção e os casos de uso do autor original são reconhecidos
Os problemas anteriores ao ClickHouse e os protótipos
- O primeiro commit do ClickHouse foi feito em 29 de maio de 2009 e era uma otimização de performance para reduzir o impacto no profiler de funções da libc como
localtime,mktimeegmtime, que eram lentas demais - O ponto de partida foram experimentos de processamento de dados para um sistema de web analytics
- O sistema recebia logs de pageviews enviados por websites, de forma semelhante ao Google Analytics
- Ele usava MySQL, processamento de dados em C++ e estruturas de dados personalizadas em C++ para as partes em que o MySQL não era suficiente
- O banco MySQL armazenava relatórios pré-agregados para clientes, enquanto as estruturas de dados customizadas eram usadas para calcular sessões e histórico de usuários
- Os dados continuavam crescendo, e novos logs chegavam em tempo real; se os logs de 5 minutos não fossem processados em 5 minutos, o atraso se acumulava continuamente
- Vários bancos de dados e bibliotecas também foram testados
- Foram analisados TokuDB, LMDB, Judy Arrays, Hadoop, LZO, QuickLZ, HyperLogLog, materiais sobre compressão de dados e documentação de servidores baseados em event loop
- A necessidade de permitir que usuários montassem relatórios arbitrários expôs os limites dos relatórios pré-agregados e levou à avaliação de bancos orientados a colunas
OLAPServer e Metrage
- A abordagem orientada a colunas consistia em armazenar logs estruturados não agregados e então agregá-los sob demanda enquanto o cliente aguardava o carregamento da página
- Foram testados Infobright e InfiniDB, extensões do MySQL, e também bancos analíticos independentes como Vertica, MonetDB e LucidDB, mas eles não funcionaram sob as condições de carregar 100 bilhões de registros por dia e 500 colunas
- O primeiro protótipo customizado foi o OLAPServer
- Implementado em dezembro de 2008 e implantado em janeiro de 2009
- Armazenava todas as colunas em um único arquivo binário por dia e por website
- Usava hashes em vez de strings e suportava apenas tipos inteiros
- Usava compressão leve e era atualizado uma vez por dia com atraso de algumas horas
- Fornecia uma API para especificar colunas de agrupamento, funções de agregação, filtros e ordenação, e as consultas eram definidas em XML
- O trabalho de “desagregar” os dados agregados antigos do MySQL para preenchê-los de forma a produzir os mesmos resultados foi resolvido por Evgenii Gatov
- O OLAPServer também funcionou em endpoints que analisavam os dados de internet da empresa inteira, e não apenas de um único website, respondendo rápido o bastante para que analistas internos o usassem no lugar do MapReduce interno
- O segundo protótipo foi o Metrage
- Havia cerca de 50 TB de dados em MySQL distribuídos em 50 shards, e muitas estruturas de dados customizadas eram armazenadas como BLOBs
- Para agregar, o programa precisava ler o BLOB, aplicar código customizado e inseri-lo de volta
- Os dados no MySQL não eram comprimidos e também eram lentos de ler porque a ordem de chegada não coincidia com a ordem do intervalo consultado
- O Metrage era uma estrutura de dados customizada para agregação incremental com merges em background, e cada registro era definido como uma struct em C++ com métodos
add,update,merge,serializeText/BinaryedeserializeText/Binary
- O OLAPServer era uma estrutura orientada a colunas e não agregada, enquanto o Metrage era uma estrutura orientada a linhas em tempo real com CRDTs arbitrários
- O ClickHouse começou ao combinar a velocidade de agregação orientada a colunas com atualizações em tempo real e localidade de dados baseadas em merge tree, generalizando isso para suportar uma linguagem de consulta real e tipos de dados reais
Um DBMS criado do zero
- O ClickHouse é um caso raro de DBMS implementado do zero, e não baseado em um banco existente
- Os commits iniciais de 2009 estavam relacionados a otimizações de outras estruturas de dados dentro do mesmo monorepo, e permaneceram no histórico porque o repositório foi separado preservando o histórico durante o processo de abertura do código
- A primeira etapa da implementação do novo DBMS foi a implementação de colunas em memória, onde surgiram as classes
IColumneField, ainda familiares hoje- Isso pode parecer semelhante ao Apache Arrow, mas o Apache Arrow ainda não existia naquela época
- Outros formatos orientados a colunas como RCFile, Trevni, ORC e Parquet também ainda não existiam naquele momento
- Depois vieram as funções de agregação, que até hoje são uma das partes mais importantes do ClickHouse
- Os table engines também foram introduzidos
- No começo, o nome “primary key” foi usado por alguns dias
- Eles permitiram ler e escrever colunas em disco
- O primeiro table engine era parecido com o TinyLog, que existe até hoje
- A compressão usou QuickLZ no início, mas foi trocada por LZ4 após a leitura do blog de Yann Collet
Pipeline de consulta e implementação de SQL
- Os block streams eram componentes do pipeline de processamento de dados que produziam, consumiam e transformavam chunks de colunas em fluxo
- Hoje foram substituídos por Processors
- Eles se tornaram a base para a formatação de resultados e para a implementação de consultas em tabelas
- No mesmo commit,
StorageSystemNumbersfoi adicionado para testes e permanece hoje como a tabelasystem.numbers - O primeiro pipeline de consulta apenas imprimia números em TSV, e o primeiro operador relacional foi
LIMIT - O parser SQL tentou primeiro usar boost::spirit, mas não deu certo; depois foi criado um parser recursivo descendente
- Algumas ideias introduzidas no início foram removidas ou reintroduzidas mais tarde
- Colunas numéricas com codificação de tamanho variável foram removidas por serem lentas, e muito depois foram introduzidos codecs de compressão customizados independentes das colunas
- O tipo de coluna
Variant, para armazenar valores arbitrários de campo, também foi removido por ser lento, e um Variant melhor foi adicionado em 2025 - O tipo de array de tamanho fixo foi removido por baixa necessidade, e atualmente sua reintrodução está sendo considerada
- Fica evidente o princípio de desenvolvimento de que remover código desnecessário é mais importante do que adicionar código novo
Implantação em produção e ReplicatedMergeTree
- A primeira estrutura de tabela real testada no ClickHouse foi a tabela
hits, que hoje também pode ser vista no ClickBench - Durante o processo de leitura e escrita dessa tabela, ficou claro que os C++ iostreams eram lentos, e
WriteBuffereReadBufferforam introduzidos e seguem em uso até hoje - A primeira função de SQL foi a de operadores aritméticos, o que permitiu implementar o primeiro interpretador de consultas
SELECT - O servidor ClickHouse foi introduzido em 9 de março de 2012, e o
clickhouse-clientem 25 de março de 2012 - Com os table engines
Log,TinyLog,Merge,DistributedeMemory, tornou-se possível implantar em produção- O primeiro uso em produção foi armazenar chunks de logs para processamento adicional e executar consultas globais sobre logs brutos
- Ele era usado como uma fila de logs persistente com consultas SQL
- Depois veio o MergeTree
- Mesmo com dados chegando em ordem temporal, ele realizava ordenação incremental em background
- Isso permitiu processar rapidamente consultas por intervalo para um único website
- Tornou possível implantações em produção que substituíram o OLAPServer e o Metrage
- Em 2012, Michael Kolupaev entrou para a equipe como o segundo funcionário e participou da implementação do ReplicatedMergeTree
- A produção foi implantada em vários datacenters regionais, e a equipe de infraestrutura realizava “drills” desligando um datacenter por uma hora uma vez por mês
- Todos os serviços de produção precisavam ter replicação entre múltiplos datacenters
- No início, usava-se double-write simples e backfill após períodos de indisponibilidade
- Para consistência de 100% e recuperação automática, era necessário consenso distribuído
- Foi implementado o ReplicatedMergeTree usando o ZooKeeper como camada de metadados
- O ReplicatedMergeTree permitiu, em 2014, a implantação do ClickHouse em produção para consultas voltadas ao usuário final
O caminho até a abertura do código
- Em 2014, o ClickHouse já armazenava em produção centenas de bilhões de registros por dia e respondia a consultas em tempo real dos clientes
- Cientistas de dados internos da empresa usavam o ClickHouse para calcular tendências da internet, e até uma documentação simples de uso foi publicada
- Outras áreas, como publicidade, e-commerce, infraestrutura e análise de negócios, também experimentaram o ClickHouse, migrando alguns casos de uso antes atendidos por MapReduce interno, MySQL e Postgres
- No fim de 2014, o ClickHouse já era amplamente usado dentro de uma única empresa e, de forma excepcional, também foi implantado pelo CERN em colaboração com o experimento LHCb experiment
- Também ficou claro que engenheiros de outras empresas estavam criando soluções parecidas com OLAPServer ou Metrage porque os bancos existentes não lidavam bem com seus casos de uso
- Em 2015, a publicação de um texto sobre o ClickHouse e sua tradução confirmou ainda mais o interesse
- Antes da abertura do código, foi preparada uma lista de possíveis vantagens e riscos para convencer a direção da empresa
- Após a aprovação, foram preparados o plano de release, o primeiro logo, o primeiro website, post de blog e repositório Debian, e o ClickHouse foi lançado para o mundo em 15 de junho de 2016
- Hoje, o ClickHouse se tornou um banco de dados analítico popular usado por grandes empresas do mundo todo
1 comentários
Opiniões do Hacker News
Descobri o ClickHouse por volta de 2017~2018 e montei uma prova de conceito para substituir o Elasticsearch; em poucas semanas, o uso de armazenamento e as consultas por segundo melhoraram em 5x
Mas os gestores rejeitaram porque não era muito conhecido e parecia “algum banco de dados feito por russos”
Pessoalmente, ainda acho uma pena ter visto esse trem chegar tão cedo e mesmo assim não ter embarcado
A taxa de compressão também era absurda, e o benchmark de custo de armazenamento caiu até o nível do custo do S3
O resultado foi reduzir uma camada de armazenamento que custava milhões de dólares por mês para algo na faixa de milhares por mês
O ClickHouse não é cura para tudo, mas, se você entende como os dados são acessados e consegue organizá-los de acordo com isso, dá para obter uma eficiência enorme
Pelo que entendo, o ClickHouse tende a ajudar só em buscas tipo grep
Para quem usou TimescaleDB por muito tempo, o ClickHouse foi realmente revigorante. O psql é excelente, e também era bom poder depender de um único sistema de banco de dados para tudo, mas manter migrações e lidar com etapas de deploy era bem doloroso
O TimescaleDB também dá a sensação de que a estrutura muda a cada versão, e a direção de desenvolvimento parece um pouco instável, então às vezes parece um produto de qualidade alfa
Ainda estou decidindo se devo apostar forte no espelho do ClickHouse com o PeerDB ou fazer um deploy separado sem adicionar mais uma camada vulnerável
Fico curioso se você realmente não recomenda o TimescaleDB. O PostgreSQL é a parte mais sólida da stack atual, então eu certamente quero evitar o sofrimento de software com qualidade alfa
Do lado do DuckDB, também existe o trabalho do pg_duckdb, e há empresas como a Xata
Para referência, eu trabalho na ParadeDB
O mecanismo de métricas e autoescalonamento da Cloud 66 passou por 5 iterações antes de se fixar no ClickHouse: Redis, Cassandra, implementação própria em Ruby+RabbitMQ, implementação própria em Go+RabbitMQ e ClickHouse
Toda vez surgia algum limite ou uma carga de otimização difícil demais de sustentar, mas o ClickHouse tem sido muito estável nos últimos 4 anos
Só depois de substituir o Loki por ClickHouse é que a stack de observabilidade finalmente pareceu “certa”. É realmente forte para logs e consultas analíticas em geral
Além de ser um ótimo banco de dados OLAP, os conectores embutidos para buscar dados de fontes remotas foram um divisor de águas
Dá para fazer importação automática periódica de uma pasta no S3 com arquivos Parquet/JSON e também conectar diretamente ao Postgres
Em um data warehouse de um jornal de porte médio, trocamos a combinação Druid+Postgres+Trino por um único nó grande de ClickHouse e nunca mais olhamos para trás
É muito mais rápido, mais prático e exige muito menos manutenção
Gosto muito do ClickHouse, e o desempenho é excelente. Tive de ajustar algumas consultas aqui e ali por causa de performance, mas, no geral, ele superou as expectativas
No início, montei uma ingestão de pipeline em tempo real para lidar com grandes cargas incrementais, mas o Redshift que usávamos antes era caro e relativamente lento
Até agora, o ClickHouse tem dado conta tranquilamente de muitos dados e transformações pesadas, então esse pipeline não foi necessário
O único problema foi que havia um recurso de tracing bem pesado ativado na configuração padrão, e isso derrubava bastante o desempenho em máquinas relativamente pequenas
Depois aumentamos a escala e agora ele é o núcleo da nossa stack de dados
Em uma escala realmente enorme talvez eu escolhesse outra coisa, mas, enquanto ficar no nível de alguns nós, a complexidade continua administrável e é prazeroso de usar
“Mesmo sem ter como objetivo fazer merge, é possível abrir pull requests como experimento e eles passam pelo mesmo nível de verificação que os releases de produção. Encontrou um novo alocador de memória, biblioteca de compressão, tabela hash, formato de dados ou algoritmo de ordenação? Traga para o ClickHouse e ele vai revelar tudo por dentro”, isso é impressionante
Ele encontra bugs praticamente por toda parte, incluindo o kernel Linux
Há fuzzers muito rigorosos, vários fuzzers rodando em diferentes níveis, e os testes são executados com uma quantidade absurda de combinações de configuração
O último número que ouvi, cerca de um ano atrás, era que uma execução completa de CI levava cerca de 400 horas para um único commit
Então é um nível de loucura considerável, no bom sentido
É interessante que o post do blog coloque SQLite e Ladybird no espectro, mas deixe de fora o principal concorrente open source, o DuckDB
Concordo que o que gera confiança é o estágio 3
Mas, para se sustentar na era dos bancos de dados feitos por vibe coding, será preciso inventar um novo modelo de negócios
Ao consultar colunas não indexadas, o ClickHouse pode ser facilmente 10x mais rápido que o DuckDB consultando Parquet, e, quando a chave primária entra em jogo, a diferença é praticamente incomparável
Existem muitos textos comparando os dois, mas, na prática, ClickHouse e DuckDB atuam em áreas totalmente diferentes
O DuckDB é um motor analítico poderoso, e o ClickHouse é um sistema completo de gerenciamento de banco de dados, com replicação, mecanismo MergeTree e mais
Na maioria dos casos esse problema de escala não existe, mas, quando existe, a diferença é grande
É uma pena que a página hesite em dizer que o “processamento de dados para um sistema de análise web parecido com o Google Analytics” era, na verdade, algo usado no Yandex
Talvez a intenção seja não fazer propaganda da empresa, mas não entendo muito bem por que isso seria triste
O ClickHouse foi um divisor de águas em algumas empresas onde trabalhei antes. Isso me lembrou o episódio sobre adoção de Rust do podcast Rust in Production
https://open.spotify.com/episode/0TBKDUhO0KihBxEzZqnQx1