10 ans d’open source pour ClickHouse
(clickhouse.com)- ClickHouse, rendu public le 15 juin 2016, est devenu en 10 ans un projet phare des bases de données analytiques open source, avec plus de 2 000 contributeurs
- L’objectif n’est pas seulement de publier le code, mais de viser un open source de niveau 3 avec guides de contribution, revues de code, roadmap, CI, releases et documentation ouverts
- Le point de départ a été les limites d’un système de web analytics basé sur MySQL, et l’expérience acquise avec OLAPServer et Metrage a conduit au traitement orienté colonnes et à la conception de MergeTree
- ClickHouse n’est pas une extension construite sur un SGBD existant, mais un SGBD implémenté depuis zéro, développé par étapes à partir de 2009 avec représentation en colonnes, fonctions d’agrégation, moteurs de table, compression, parseur SQL, serveur/client et ReplicatedMergeTree
- Après avoir traité en production des centaines de milliards d’enregistrements par jour dès 2014, ClickHouse a été ouvert au monde entier en 2016 après un billet publié en 2015 et un processus d’approbation interne
10 ans depuis la publication en open source
- ClickHouse a été publié en open source le 15 juin 2016
- Depuis, plus de 2 000 personnes y ont contribué, et il est devenu la « base de données analytique open source la plus populaire »
- L’objectif central du projet n’est pas seulement de publier le code, mais de rendre aussi ouverts que possible le processus de développement et le processus de contribution
Le niveau d’open source visé par ClickHouse
- Il existe plusieurs niveaux d’open source
- Level 0 : le code est publié pour pouvoir être lu, mais sans aller plus loin. Doom ou MS-DOS sont des exemples de publication à vocation d’archive ou de musée
- Level 1 : le dépôt public est mis à jour au fil des commits, sans nécessairement accepter des contributions. SQLite et Ladybird en sont des exemples
- Level 2 : les contributions sont acceptées, mais le processus de développement n’est ni transparent ni réellement public. La plupart des projets open source actifs entrent dans cette catégorie
- Level 3 : le projet dispose de guides de contribution, de suivi du travail, de revues de code, d’une roadmap de développement, de tests et CI, d’un cycle de release, d’un support utilisateur et de la documentation
- ClickHouse vise le Level 3 en open source
- L’un des objectifs est aussi de servir d’exemple, à la fois en code et en pratiques de développement, pour les développeurs qui veulent créer une nouvelle base de données
- Le code vise à être modulaire, orthogonal et documenté
- Quand des concepts complexes sont nécessaires, ils sont expliqués depuis la base dans les commentaires afin que le lecteur n’ait pas besoin de se référer à un manuel, à Wikipedia ou à une IA
Un terrain pour le développement C++ et l’expérimentation sur les performances
- ClickHouse se veut aussi un lieu où apprendre, à travers l’un des dépôts open source C++ les plus populaires, les fonctionnalités récentes du langage comme C++23, ainsi que les build systems, l’intégration continue, les tests et les pratiques de revue de code
- L’expérimentation sur les structures de données et l’optimisation des performances est également un usage important
- Même les Pull Requests expérimentales qui ne visent pas une fusion sont testées au même niveau qu’une release de production
- Il est possible de valider dans ClickHouse des expérimentations sur de nouveaux allocateurs mémoire, des bibliothèques de compression, des tables de hachage, des formats de données ou des algorithmes de tri
- La roadmap contient aussi des éléments expérimentaux, étranges, voire franchement absurdes
- Tous les contributeurs sont crédités dans le CHANGELOG et dans la table interne system.contributors
- Il est fréquent que des fonctionnalités incomplètes dans leur implémentation initiale soient finalisées collectivement, et même lorsqu’une réécriture complète du code est nécessaire, l’intention et les cas d’usage de l’auteur initial restent reconnus
Les problèmes d’avant ClickHouse et les prototypes initiaux
- Le premier commit de ClickHouse date du 29 mai 2009 et consistait en une optimisation des performances visant à réduire le poids dans le profiler de fonctions libc comme
localtime,mktimeetgmtime, jugées trop lentes - Le point de départ a été des expérimentations sur le traitement des données dans un système de web analytics
- Le système recevait des logs de pages vues envoyés depuis des sites web, à la manière de Google Analytics
- Il combinait MySQL, du traitement de données en C++, et des structures de données C++ sur mesure pour les parties que MySQL ne couvrait pas suffisamment
- La base MySQL stockait les rapports pré-agrégés destinés aux clients, tandis que les structures personnalisées servaient à calculer les sessions utilisateur et l’historique utilisateur
- Le volume de données ne cessait d’augmenter et de nouveaux logs arrivaient en temps réel ; si les logs d’une tranche de 5 minutes ne pouvaient pas être traités en moins de 5 minutes, le retard s’accumulait en continu
- Diverses bases de données et bibliothèques ont aussi été testées
- TokuDB, LMDB, Judy Arrays, Hadoop, LZO, QuickLZ, HyperLogLog, de la documentation sur la compression de données ou sur les serveurs à boucle d’événements ont été étudiés
- La volonté de laisser les utilisateurs composer des rapports arbitraires a révélé les limites des rapports pré-agrégés et conduit à évaluer les bases de données orientées colonnes
OLAPServer et Metrage
- L’approche orientée colonnes consistait à stocker des logs structurés non agrégés, puis à effectuer les agrégations à la volée pendant que le client attendait le chargement de la page
- Des extensions MySQL comme Infobright et InfiniDB, ainsi que des bases analytiques autonomes comme Vertica, MonetDB et LucidDB ont été testées, mais aucune ne fonctionnait dans des conditions de chargement de 100 milliards d’enregistrements par jour et 500 colonnes
- Le premier prototype sur mesure a été OLAPServer
- Implémenté en décembre 2008 et déployé en janvier 2009
- Toutes les colonnes étaient stockées dans un fichier binaire unique par jour et par site web
- Des hachages étaient utilisés à la place des chaînes, et seuls les types entiers étaient pris en charge
- Il utilisait une compression légère et n’était mis à jour qu’une fois par jour avec plusieurs heures de retard
- Il proposait une API permettant de spécifier colonnes de groupement, fonctions d’agrégation, filtres et tri, les requêtes étant décrites en XML
- Le remplissage à partir d’anciennes données agrégées MySQL, en les « désagrégeant » pour obtenir les mêmes résultats, a été résolu par Evgenii Gatov
- OLAPServer fonctionnait aussi pour des points d’accès analysant l’ensemble des données internet de l’entreprise plutôt qu’un seul site, avec des réponses suffisamment immédiates pour que les analystes internes l’utilisent à la place du MapReduce maison
- Le deuxième prototype a été Metrage
- Environ 50 To de données étaient accumulés dans MySQL sur 50 shards, avec de nombreuses structures de données personnalisées stockées en BLOB
- Lors des agrégations, le programme devait lire les BLOB, appliquer du code personnalisé, puis les réinsérer
- Les données MySQL n’étaient pas compressées, et comme l’ordre d’arrivée différait de l’ordre des plages interrogées, les lectures étaient également lentes
- Metrage était une structure de données personnalisée pour l’agrégation incrémentale avec fusions en arrière-plan, chaque enregistrement étant défini comme une structure C++ disposant des méthodes
add,update,merge,serializeText/Binary,deserializeText/Binary
- OLAPServer était une structure orientée colonnes non agrégée, et Metrage une structure orientée lignes en temps réel avec des CRDT arbitraires
- ClickHouse est né de la volonté de combiner la vitesse d’agrégation orientée colonnes avec les mises à jour en temps réel et la localité des données d’un merge tree, tout en généralisant l’ensemble avec un vrai langage de requête et des types de données pris en charge
Un SGBD construit depuis zéro
- ClickHouse est un cas rare de SGBD implémenté depuis zéro, et non bâti sur une base de données existante
- Les commits initiaux de 2009 étaient liés à d’autres optimisations de structures de données dans le même monorepo ; ils subsistent parce que l’historique a été conservé lors de la séparation du dépôt au moment de l’ouverture en open source
- La première étape de l’implémentation du nouveau SGBD a été la représentation en mémoire des colonnes, avec l’apparition des classes
IColumnetField, toujours familières aujourd’hui- Cela peut rappeler Apache Arrow, mais Apache Arrow n’existait pas encore à l’époque
- D’autres formats orientés colonnes comme RCFile, Trevni, ORC ou Parquet n’existaient pas encore non plus
- Les fonctions d’agrégation ont ensuite été introduites, et restent aujourd’hui l’une des parties les plus importantes de ClickHouse
- Les moteurs de table ont aussi été introduits
- Au départ, le nom « primary key » a été utilisé pendant quelques jours
- Ils ont rendu possible la lecture et l’écriture de colonnes sur disque
- Le premier moteur de table ressemblait au TinyLog qui existe encore aujourd’hui
- La compression utilisait initialement QuickLZ, avant d’être remplacée par LZ4 après la lecture du blog de Yann Collet
Pipeline de requêtes et implémentation SQL
- Les block streams étaient des composants du pipeline de traitement de données produisant, consommant et transformant des flux de blocs de colonnes
- Ils ont depuis été remplacés par Processors
- Ils ont servi de base au formatage des résultats et à l’implémentation des requêtes sur table
- Dans le même commit,
StorageSystemNumbersa été ajouté pour les tests et subsiste aujourd’hui sous la forme de la tablesystem.numbers - Le premier pipeline de requête se limitait à afficher des nombres en TSV, et le premier opérateur relationnel a été
LIMIT - Le parseur SQL a d’abord essayé boost::spirit sans succès, avant qu’un parseur récursif descendant ne soit développé
- Certaines idées ont été introduites très tôt, supprimées ensuite, puis parfois réintroduites plus tard
- Les colonnes numériques à encodage de longueur variable ont été supprimées car trop lentes ; des codecs de compression personnalisés indépendants des colonnes ont été introduits bien plus tard
- Le type de colonne
Variant, capable de contenir des valeurs de champs arbitraires, a lui aussi été supprimé car trop lent, et un meilleur Variant a été ajouté en 2025 - Le type de tableau à taille fixe a été retiré faute de besoin suffisant, et son retour est actuellement à l’étude
- On y voit un principe de développement selon lequel retirer du code inutile est plus important qu’ajouter du nouveau code
Déploiement en production et ReplicatedMergeTree
- La première structure de table réellement testée dans ClickHouse a été la table
hits, que l’on peut encore voir aujourd’hui dans ClickBench - La lecture et l’écriture de cette table ont montré que les iostreams C++ étaient trop lentes, ce qui a conduit à l’introduction de
WriteBufferetReadBuffer, toujours utilisés aujourd’hui - Les premières fonctions SQL ont été les opérateurs arithmétiques, ce qui a permis d’implémenter le premier interpréteur de requêtes
SELECT - Le serveur ClickHouse a été introduit le 9 mars 2012, et
clickhouse-clientle 25 mars 2012 - Avec les moteurs de table
Log,TinyLog,Merge,DistributedetMemory, le déploiement en production est devenu possible- Les premiers usages en production ont consisté à stocker des chunks de logs pour traitement complémentaire et à exécuter des requêtes globales sur des logs bruts
- ClickHouse était utilisé comme une sorte de file de logs persistante interrogeable en SQL
- Puis MergeTree a été ajouté
- Même si les données arrivaient dans l’ordre chronologique, un tri incrémental était effectué en arrière-plan
- Cela a permis d’accélérer fortement les requêtes par plage sur un site web unique
- Un déploiement de production capable de remplacer OLAPServer et Metrage est alors devenu possible
- En 2012, Michael Kolupaev a rejoint l’équipe comme deuxième employé et a participé à l’implémentation de ReplicatedMergeTree
- La production était déployée dans plusieurs data centers régionaux, et l’équipe infrastructure réalisait chaque mois des « drills » consistant à éteindre un data center pendant une heure
- Tous les services de production devaient donc disposer d’une réplication multi-data center
- Au départ, un simple double-write avec backfill après indisponibilité était utilisé
- Une cohérence à 100 % et une récupération automatique exigeaient un consensus distribué
- ReplicatedMergeTree a été implémenté avec ZooKeeper comme couche de métadonnées
- ReplicatedMergeTree a permis en 2014 le déploiement en production de ClickHouse pour des requêtes destinées aux utilisateurs finaux
Le chemin jusqu’à l’ouverture en open source
- En 2014, ClickHouse stockait en production des centaines de milliards d’enregistrements par jour et répondait à des requêtes client en temps réel
- Les data scientists internes de l’entreprise utilisaient ClickHouse pour calculer des tendances internet, et une documentation d’usage simple a aussi été publiée
- D’autres départements, comme la publicité, l’e-commerce, l’infrastructure ou l’analyse métier, ont également essayé ClickHouse et ont migré certains usages depuis le MapReduce interne, MySQL et Postgres
- Fin 2014, ClickHouse était largement utilisé au sein d’une seule entreprise, et fait exceptionnel, CERN l’avait aussi déployé dans le cadre de la collaboration LHCb experiment
- Il a aussi été confirmé que des ingénieurs d’autres entreprises construisaient des outils semblables à OLAPServer ou Metrage parce que les bases de données existantes géraient mal leurs cas d’usage
- En 2015, la publication d’un article sur ClickHouse et de sa traduction a confirmé encore davantage l’intérêt
- Avant l’ouverture, une liste des avantages potentiels et des risques a été préparée pour convaincre la direction de l’entreprise
- Une fois l’approbation obtenue, le plan de release, le premier logo, le premier site web, le billet de blog et le dépôt Debian ont été préparés, puis ClickHouse a été rendu public au monde entier le 15 juin 2016
- Aujourd’hui, ClickHouse est devenu une base de données analytique populaire utilisée par de grandes entreprises du monde entier
1 commentaires
Avis sur Hacker News
J’ai découvert ClickHouse vers 2017-2018 et j’ai réalisé une preuve de concept pour remplacer Elasticsearch, ce qui a permis en quelques semaines d’améliorer de 5 fois l’espace de stockage et le nombre de requêtes par seconde
Mais les responsables l’ont refusé parce que ce n’était pas bien connu et que ça ressemblait à « une base de données faite par des Russes »
Personnellement, je regrette encore de ne pas être monté dans le train alors que je l’avais vu arriver si tôt
Le taux de compression était aussi absurde, et les benchmarks de coût de stockage descendaient jusqu’au niveau du coût de S3
Une couche de stockage qui coûtait plusieurs millions de dollars par mois tombait à quelques milliers de dollars par mois
ClickHouse n’est pas une panacée, mais si l’on comprend comment les données sont consultées et qu’on peut les disposer en conséquence, on peut obtenir une efficacité énorme
D’après ce que je comprends, ClickHouse aide surtout pour les recherches de type grep
ClickHouse a été une vraie bouffée d’air frais après avoir longtemps utilisé TimescaleDB. psql est excellent, et le fait de pouvoir tout faire reposer sur un seul système de base de données est appréciable, mais la maintenance des migrations et les étapes de déploiement étaient assez pénibles
J’ai aussi l’impression que la structure de TimescaleDB change à chaque version, et son orientation de développement semble parfois hésitante, au point que cela ressemble parfois à un produit de qualité alpha
J’hésite encore entre utiliser PeerDB pour avoir un miroir ClickHouse de grande ampleur, ou le déployer séparément sans ajouter de couche de fragilité
Je me demande si tu déconseilles complètement TimescaleDB. PostgreSQL est actuellement la partie la plus solide de notre stack, donc j’aimerais clairement éviter les souffrances d’un logiciel de qualité alpha
Il y a aussi du travail autour de pg_duckdb du côté de DuckDB, ainsi que des acteurs comme Xata
Pour info, je travaille chez ParadeDB
Le moteur de métriques et d’auto-scaling de Cloud 66 est passé par 5 itérations avant de se stabiliser sur ClickHouse : Redis, Cassandra, une implémentation maison en Ruby+RabbitMQ, une implémentation maison en Go+RabbitMQ, puis ClickHouse
À chaque fois, nous nous heurtions à une limite ou à une charge d’optimisation impossible à soutenir, alors que ClickHouse a été très stable pendant les 4 dernières années
Ce n’est qu’après avoir remplacé Loki par ClickHouse que notre stack d’observabilité a enfin semblé « correcte ». C’est vraiment très puissant pour les logs et les requêtes analytiques générales
En plus d’être une excellente base de données OLAP, ses connecteurs intégrés pour aller chercher des données depuis des sources distantes ont changé la donne
On peut configurer l’import automatique périodique d’un dossier S3 contenant des fichiers Parquet/JSON, et il peut aussi se connecter directement à Postgres
Dans le data warehouse d’un journal de taille moyenne, nous avons remplacé un assemblage Druid+Postgres+Trino par un gros nœud ClickHouse unique, et nous n’avons jamais regardé en arrière
C’est bien plus rapide, plus pratique et demande beaucoup moins de maintenance
J’aime vraiment ClickHouse et ses performances sont excellentes. J’ai dû ajuster quelques requêtes ici et là pour des raisons de performance, mais dans l’ensemble cela a dépassé mes attentes
Au départ, j’avais mis en place une ingestion en pipeline temps réel pour gérer de gros chargements incrémentaux, car Redshift était auparavant coûteux et relativement lent
Jusqu’ici, ClickHouse a si bien absorbé de gros volumes de données et de grosses transformations que ce pipeline n’a pas été nécessaire
Le seul problème, c’est qu’une fonctionnalité de traçage assez lourde était activée par défaut, et qu’elle dégradait fortement les performances sur du matériel relativement modeste
Nous avons ensuite changé d’échelle, et c’est maintenant le cœur de notre stack data
À très grande échelle, je choisirais peut-être autre chose, mais tant qu’on reste sur quelques nœuds, la complexité reste gérable et c’est agréable à utiliser
« On peut ouvrir une pull request comme expérimentation sans viser le merge, et elle recevra le même niveau de vérification qu’une release de production. Vous avez trouvé un nouvel allocateur mémoire, une bibliothèque de compression, une table de hachage, un format de données, un algorithme de tri ? Apportez-le à ClickHouse, et il sera disséqué dans les moindres détails », c’est impressionnant
On trouve des bugs pratiquement partout, y compris dans le noyau Linux
Il existe un fuzzer extrêmement strict, avec plusieurs fuzzers à plusieurs niveaux, et des tests exécutés avec un nombre absurde de combinaisons de configuration
Le dernier chiffre que j’ai entendu, il y a environ un an, était qu’une exécution complète de la CI représentait environ 400 heures pour un seul commit
Donc oui, c’est assez fou, dans le bon sens du terme
Il est intéressant que l’article de blog place SQLite et Ladybird sur le spectre, mais omette DuckDB, qui est pourtant un concurrent open source clé
Je suis d’accord sur le fait que la confiance se situe au niveau 3
Mais pour rester durable à l’ère des bases de données codées à la vibe, il faudra inventer un nouveau modèle économique
Quand on interroge des colonnes non indexées, ClickHouse peut facilement être 10 fois plus rapide que DuckDB sur des fichiers Parquet, et dès qu’on touche à la clé primaire, il n’y a pratiquement plus de comparaison possible tant c’est plus rapide
Il existe beaucoup d’articles qui les comparent, mais en pratique ClickHouse et DuckDB occupent des espaces complètement différents
DuckDB est un moteur analytique puissant, tandis que ClickHouse est un système complet de gestion de base de données avec réplication, moteurs MergeTree, etc.
La plupart du temps, ce n’est pas un problème de taille, mais quand cela le devient, la différence est importante
Je trouve dommage que la page évite de dire que le « traitement de données pour un système d’analyse web similaire à Google Analytics » était en réalité utilisé chez Yandex
C’est probablement pour ne pas faire de publicité à cette entreprise, mais je ne vois pas trop pourquoi ce serait triste
ClickHouse a été un game changer dans plusieurs entreprises où j’ai travaillé. Ça me rappelle l’épisode du podcast Rust in Production sur l’adoption de Rust
https://open.spotify.com/episode/0TBKDUhO0KihBxEzZqnQx1