10 años del open source de ClickHouse
(clickhouse.com)- ClickHouse se publicó como open source el 15 de junio de 2016 y, durante 10 años, más de 2,000 personas han contribuido a convertirlo en un proyecto referente entre las bases de datos analíticas open source
- No busca solo publicar el código, sino un open source de nivel 3 que también haga públicos la guía de contribución, las revisiones de código, la hoja de ruta, CI, los lanzamientos y la documentación
- Su punto de partida fueron las limitaciones de un sistema de analítica web basado en MySQL, y la experiencia con OLAPServer y Metrage llevó al procesamiento orientado a columnas y al diseño de MergeTree
- ClickHouse no es una extensión sobre un DBMS existente, sino un DBMS implementado desde cero desde 2009, construyendo paso a paso la representación en columnas, funciones de agregación, motores de tabla, compresión, parser SQL, servidor·cliente y ReplicatedMergeTree
- Tras procesar cientos de miles de millones de registros diarios en producción interna desde 2014, se publicó globalmente en 2016 después de un artículo público en 2015 y un proceso interno de aprobación
10 años desde su publicación como open source
- ClickHouse se publicó como open source el 15 de junio de 2016
- Desde entonces, más de 2,000 personas han contribuido, y se convirtió en “la base de datos analítica open source más popular”
- El objetivo central del proyecto no es solo publicar el código, sino hacer lo más públicos posible el proceso de desarrollo y el proceso de contribución
El nivel de open source al que aspira ClickHouse
- Hay varios niveles de open source
- Level 0: se publica el código para que pueda leerse, pero no hay nada más. Ejemplos: publicaciones de archivo o museo como Doom y MS-DOS
- Level 1: se actualiza con commits en un repositorio público, pero no necesariamente acepta contribuciones. Ejemplos: SQLite, Ladybird
- Level 2: acepta contribuciones, pero el proceso de desarrollo no es transparente ni público. La mayoría de los proyectos open source activos entran aquí
- Level 3: cuenta con guía de contribución, seguimiento de trabajo, revisiones de código, hoja de ruta de desarrollo, tests y CI, ciclo de lanzamientos, soporte a usuarios y documentación
- ClickHouse aspira a ser un proyecto open source de Level 3
- También busca servir como ejemplo de código y de prácticas de desarrollo para quienes quieran crear una nueva base de datos
- El código busca ser modular, ortogonal y documentado
- Cuando se necesitan conceptos complejos, se explican desde cero en los comentarios para que el lector no tenga que recurrir a libros de texto, Wikipedia o IA
Un espacio para desarrollo en C++ y experimentos de rendimiento
- ClickHouse busca ser uno de los repositorios open source populares de C++ donde también se pueda aprender sobre trabajo base como funciones modernas del lenguaje como C++23, sistemas de build, integración y pruebas continuas, y prácticas de revisión de código
- Los experimentos con estructuras de datos y optimización de rendimiento también son una forma importante de uso
- Incluso los Pull Request experimentales que no buscan ser fusionados se prueban con el mismo nivel que un release de producción
- En ClickHouse pueden validarse experimentos con nuevos allocators de memoria, librerías de compresión, tablas hash, formatos de datos y algoritmos de ordenamiento
- La hoja de ruta también incluye elementos experimentales, extraños e incluso ridículos
- Todos los contribuidores reciben crédito en el CHANGELOG y en la tabla interna system.contributors de la base de datos
- También hay muchos casos en los que se terminan funciones cuya implementación inicial estaba incompleta, y aunque haya que reescribir todo el código, se reconocen la intención y los casos de uso del autor original
Los problemas previos y los prototipos antes de ClickHouse
- El primer commit de ClickHouse se creó el 29 de mayo de 2009, y fue una optimización de rendimiento para reducir problemas que aparecían en el profiler porque funciones de libc como
localtime,mktimeygmtimeeran demasiado lentas - El punto de partida fueron experimentos de procesamiento de datos para un sistema de analítica web
- El sistema recibía logs de pageviews enviados desde sitios web, de forma similar a Google Analytics
- Se usaban MySQL, procesamiento de datos en C++ y estructuras de datos personalizadas en C++ para las partes donde MySQL no alcanzaba
- La base de datos MySQL almacenaba reportes preagregados para clientes, y las estructuras de datos personalizadas se usaban para calcular sesiones e historial de usuarios
- Los datos seguían creciendo y los logs nuevos llegaban en tiempo real; si no se lograban procesar logs de 5 minutos en menos de 5 minutos, el retraso seguía acumulándose
- También se probaron varias bases de datos y librerías
- Se revisaron TokuDB, LMDB, Judy Arrays, Hadoop, LZO, QuickLZ, HyperLogLog, materiales sobre compresión de datos y documentación de servidores con event loop
- El requerimiento de permitir que los usuarios construyeran reportes arbitrarios dejó en evidencia los límites de los reportes preagregados, lo que llevó a evaluar bases de datos orientadas a columnas
OLAPServer y Metrage
- El enfoque orientado a columnas consistía en almacenar logs estructurados no agregados y luego agregarlos al vuelo mientras el cliente esperaba que cargara la página
- Se probaron extensiones de MySQL como Infobright e InfiniDB, y bases de datos analíticas independientes como Vertica, MonetDB y LucidDB, pero no funcionaban bajo condiciones de carga de 100 mil millones de registros por día y 500 columnas
- El primer prototipo personalizado fue OLAPServer
- Se implementó en diciembre de 2008 y se desplegó en enero de 2009
- Guardaba todas las columnas en un único archivo binario por día y por sitio web
- Usaba hashes en lugar de strings y solo soportaba tipos enteros
- Usaba compresión ligera y se actualizaba una vez al día con varias horas de retraso
- Ofrecía una API para especificar columnas de agrupación, funciones de agregación, filtros y ordenamiento, y las consultas se definían en XML
- El trabajo de “desagregar” datos agregados históricos de MySQL para llenar el sistema y obtener los mismos resultados lo resolvió Evgenii Gatov
- OLAPServer también funcionó en un endpoint que analizaba datos de internet de toda la empresa, no de un solo sitio web, y respondía lo bastante rápido como para que analistas internos lo usaran en lugar de MapReduce interno
- El segundo prototipo fue Metrage
- Había unos 50TB de datos en MySQL repartidos en 50 shards, y muchas estructuras de datos personalizadas se almacenaban como BLOB
- Durante la agregación, el programa tenía que leer el BLOB, aplicar código personalizado y volver a insertarlo
- Los datos de MySQL no estaban comprimidos, y como el orden de llegada no coincidía con el orden de los rangos de consulta, la lectura también era lenta
- Metrage era una estructura de datos personalizada para agregación incremental con merges en background, y cada registro se definía como una struct de C++ con métodos
add,update,merge,serializeText/BinaryydeserializeText/Binary
- OLAPServer era una estructura orientada a columnas no agregada, y Metrage era una estructura orientada a filas en tiempo real con CRDT arbitrarios
- ClickHouse comenzó al combinar la velocidad de agregación orientada a columnas con actualizaciones en tiempo real y localidad de datos basadas en merge tree, generalizándolo además para soportar un lenguaje de consultas real y tipos de datos
Un DBMS hecho desde cero
- ClickHouse es un caso poco común de DBMS implementado desde cero, no basado en una base de datos existente
- Los commits iniciales de 2009 están relacionados con optimización de otras estructuras de datos dentro del mismo monorepositorio, y permanecen porque, al publicar el open source, se separó el repositorio preservando el historial
- La primera etapa de implementar el nuevo DBMS fue crear columnas en memoria, y allí aparecieron las clases
IColumnyField, familiares hasta hoy- Puede parecerse a Apache Arrow, pero Apache Arrow no existía en ese momento
- Tampoco existían entonces otros formatos orientados a columnas como RCFile, Trevni, ORC o Parquet
- Después se introdujeron las funciones de agregación, que siguen siendo una de las partes más importantes de ClickHouse
- También se introdujeron los motores de tabla
- Al principio usaron durante unos días el nombre “primary key”
- Hicieron posible leer y escribir columnas en disco
- El primer motor de tabla era parecido al TinyLog que sigue existiendo hoy
- Al principio la compresión usaba QuickLZ, pero luego se cambió a LZ4 tras leer el blog de Yann Collet
Pipeline de consultas e implementación de SQL
- Los block streams eran componentes del pipeline de procesamiento de datos que producían, consumían y transformaban chunks de columnas en forma de stream
- Hoy fueron reemplazados por Processors
- Sirvieron de base para el formateo de resultados y la implementación de consultas sobre tablas
- En el mismo commit se agregó
StorageSystemNumberspara testing, y hoy permanece como la tablasystem.numbers - El primer pipeline de consultas imprimía números en TSV, y el primer operador relacional fue
LIMIT - El parser SQL primero intentó usar boost::spirit, pero fracasó, y luego se creó un parser descendente recursivo
- También hubo ideas introducidas al inicio que luego se eliminaron o se reintrodujeron más adelante
- Las columnas numéricas con codificación de longitud variable se eliminaron por lentas, y mucho después se introdujeron códecs de compresión personalizados independientes de las columnas
- El tipo de columna
Variantpara guardar valores arbitrarios de campo también se eliminó por lento, y un mejor Variant se agregó en 2025 - El tipo de arreglo de tamaño fijo se eliminó por su baja necesidad, y hoy se está reconsiderando su regreso
- Aquí se ve un principio de desarrollo: eliminar código innecesario es más importante que agregar código nuevo
Despliegue en producción y ReplicatedMergeTree
- La primera estructura de tabla real probada en ClickHouse fue la tabla
hits, que hoy también puede verse en ClickBench - Al leer y escribir esta tabla quedó claro que los iostreams de C++ eran lentos, por lo que se introdujeron
WriteBufferyReadBuffer, que siguen en uso hoy - La primera función de SQL fue el operador aritmético, y con ello se implementó el primer intérprete de consultas
SELECT - El servidor de ClickHouse se introdujo el 9 de marzo de 2012, y
clickhouse-clientel 25 de marzo de 2012 - Con los motores de tabla
Log,TinyLog,Merge,DistributedyMemory, ya fue posible desplegarlo en producción- Su primer uso en producción fue almacenar chunks de logs para procesamiento adicional y hacer consultas globales sobre logs crudos
- Se usaba como una especie de cola de logs persistente con consultas SQL
- Después se añadió MergeTree
- Aunque los datos entraran en orden temporal, hacía ordenamiento incremental en background
- Permitía procesar rápidamente consultas por rango para un solo sitio web
- Hizo posible un despliegue en producción que reemplazó a OLAPServer y Metrage
- En 2012, Michael Kolupaev se unió al equipo como el segundo empleado y participó en la implementación de ReplicatedMergeTree
- La producción se desplegó en centros de datos de varias regiones, y el equipo de infraestructura hacía “drills” en los que apagaba un centro de datos durante una hora una vez al mes
- Todos los servicios de producción debían tener replicación entre múltiples centros de datos
- Al principio se usaba simple double-write y backfill tras caídas
- Para lograr consistencia al 100% y recuperación automática se necesitaba consenso distribuido
- Así se implementó ReplicatedMergeTree usando ZooKeeper como capa de metadatos
- ReplicatedMergeTree hizo posible en 2014 el despliegue en producción de ClickHouse para consultas orientadas al usuario final
El camino hasta su publicación como open source
- En 2014, ClickHouse ya almacenaba cientos de miles de millones de registros diarios en producción y respondía consultas en tiempo real de clientes
- Científicos de datos internos de la empresa usaban ClickHouse para calcular tendencias de internet, e incluso se publicó documentación simple de uso
- Otras áreas, como publicidad, ecommerce, infraestructura y analítica de negocio, también empezaron a probar ClickHouse y migraron algunos casos de uso desde MapReduce interno, MySQL y Postgres
- A finales de 2014, ClickHouse se usaba ampliamente dentro de una sola empresa, y de manera excepcional CERN también lo desplegó durante la colaboración del experimento LHCb
- También se confirmó que ingenieros de otras empresas estaban construyendo algo parecido a OLAPServer o Metrage porque las bases de datos existentes no resolvían bien sus casos de uso
- En 2015, la publicación de un artículo sobre ClickHouse y su traducción confirmó aún más el interés
- Antes de publicarlo, se preparó una lista de ventajas y riesgos potenciales para convencer a la dirección de la empresa
- Tras obtener la aprobación, se prepararon el plan de lanzamiento, el primer logo, el primer sitio web, la entrada de blog y el repositorio Debian, y ClickHouse se publicó para todo el mundo el 15 de junio de 2016
- Hoy ClickHouse se ha convertido en una base de datos analítica popular usada por grandes empresas de todo el mundo
1 comentarios
Opiniones en Hacker News
Descubrí ClickHouse por ahí de 2017~2018 e hice una prueba de concepto para reemplazar Elasticsearch, y en unas semanas mejoraron 5 veces tanto el espacio de almacenamiento como las consultas por segundo
Pero los administradores lo rechazaron porque no era muy conocido y les parecía “alguna base de datos hecha por rusos”
En lo personal, todavía me pesa bastante haber visto venir ese tren tan temprano y no haberme subido
La tasa de compresión también era ridícula, y el benchmark de costo de almacenamiento bajó hasta niveles del costo de S3
Una capa de almacenamiento que costaba millones de dólares al mes terminó bajando a miles de dólares al mes
ClickHouse no es la cura para todo, pero si entiendes cómo se accede a los datos y puedes organizarlos en función de eso, se puede obtener una eficiencia enorme
Según entiendo, ClickHouse más bien ayuda solo con búsquedas tipo grep
Desde la perspectiva de alguien que usó TimescaleDB durante mucho tiempo, ClickHouse fue realmente refrescante. psql es lo máximo, y también me gustaba poder depender de un solo sistema de base de datos para todo, pero el mantenimiento de migraciones y las etapas de despliegue eran bastante dolorosos
Además, TimescaleDB da la impresión de que su estructura cambia con cada versión, y su dirección de desarrollo se siente algo inestable, así que a veces parece un producto de calidad alfa
Todavía estoy viendo si conviene llevar un espejo grande de ClickHouse con PeerDB o desplegarlo por separado sin otra capa vulnerable adicional
Me pregunto si eres de los que directamente no recomiendan TimescaleDB. PostgreSQL es la parte más sólida del stack actual, así que de verdad quisiera evitar el dolor de software con calidad alfa
Del lado de DuckDB también está el trabajo de pg_duckdb, y también lugares como Xata
Por cierto, trabajo en ParadeDB
El motor de métricas y autoescalado de Cloud 66 pasó por 5 iteraciones antes de asentarse en ClickHouse: Redis, Cassandra, una implementación propia con Ruby+RabbitMQ, una implementación propia con Go+RabbitMQ, y ClickHouse
Cada vez se topaban con algún límite o con una carga de optimización imposible de sostener, pero ClickHouse ha sido muy estable durante los últimos 4 años
No fue hasta que reemplazamos Loki con ClickHouse que por fin sentimos que nuestro stack de observabilidad estaba “bien”. Es realmente potente para logs y consultas analíticas generales
Además de ser una gran base de datos OLAP, sus conectores integrados para traer datos desde fuentes remotas fueron un cambio total de juego
Puedes hacer importaciones automáticas periódicas desde una carpeta de S3 con archivos Parquet/JSON, y también puede conectarse directamente a Postgres
En el data warehouse de un periódico de tamaño mediano cambiamos una combinación de Druid+Postgres+Trino por un solo nodo grande de ClickHouse, y no hemos mirado atrás
Es mucho más rápido, más práctico y requiere muchísimo menos mantenimiento
Me gusta muchísimo ClickHouse y su rendimiento es excelente. Tuve que ajustar algunas consultas por temas de rendimiento, pero en general estuvo por encima de lo esperado
Al principio armé una ingesta de pipeline en tiempo real para manejar cargas incrementales grandes, y el Redshift que usábamos antes era caro y relativamente lento
Hasta ahora ClickHouse ha manejado sin problema grandes volúmenes de datos y transformaciones pesadas, así que ese pipeline ya no hizo falta
El único problema fue que en la configuración predeterminada venía activada una función de trazado bastante pesada, y en equipos relativamente pequeños eso sí afectaba mucho el rendimiento
Después escalamos el tamaño y ahora es el núcleo de nuestro stack de datos
Si fuera una escala realmente enorme tal vez elegiría otra cosa, pero mientras siga en el orden de unos cuantos nodos, la complejidad es manejable y da gusto usarlo
Eso de “aunque no tengas como meta que se haga merge, puedes abrir un pull request como experimento y recibirá el mismo nivel de validación que un release de producción. ¿Encontraste un nuevo asignador de memoria, biblioteca de compresión, tabla hash, formato de datos o algoritmo de ordenamiento? Tráelo a ClickHouse y dejará todo al descubierto” está impresionante
Encuentra bugs prácticamente por todos lados, incluido el kernel de Linux
Tiene fuzzers muy estrictos, varios fuzzers ejecutándose en distintos niveles, y corre pruebas con una cantidad ridícula de combinaciones de configuración
La última cifra que escuché, hace como un año, era que una ejecución completa de CI tomaba unas 400 horas por un solo commit
Así que sí, está bastante loco, pero en el buen sentido
Es interesante que la entrada del blog ponga a SQLite y Ladybird en el espectro, pero deje fuera a DuckDB, que es un competidor open source clave
Estoy de acuerdo en que la confianza está en la etapa 3
Pero para ser sostenible en la era de las bases de datos hechas con vibe coding, va a haber que inventar un nuevo modelo de negocio
Al consultar columnas no indexadas, ClickHouse puede ser fácilmente 10 veces más rápido que DuckDB consultando Parquet, y cuando tocas la clave primaria básicamente ni se comparan
Hay muchos textos comparándolos, pero en la práctica ClickHouse y DuckDB están en territorios completamente distintos
DuckDB es un motor analítico muy potente, y ClickHouse es un sistema completo de gestión de bases de datos con replicación y motores como MergeTree
La mayoría no tiene ese problema de escala, pero cuando aparece, la diferencia es grande
Da algo de pena que en la página eviten decir que “el procesamiento de datos para un sistema de analítica web similar a Google Analytics” en realidad se usó en Yandex
Supongo que la idea es no hacerle publicidad a esa empresa, pero no termino de entender por qué eso sería triste
ClickHouse fue un game changer en algunas empresas donde trabajé antes. Me acordó al episodio sobre adopción de Rust del podcast Rust in Production
https://open.spotify.com/episode/0TBKDUhO0KihBxEzZqnQx1