Este artículo no describe un incidente específico, sino una serie de desafíos operacionales y lecciones aprendidas a lo largo de seis años de gestión de clusters ClickHouse a escala de petabytes. La causa raíz subyacente de muchos de los problemas descritos es la complejidad inherente de operar un sistema OLAP distribuido como ClickHouse, especialmente cuando se intenta adaptarlo a arquitecturas modernas de separación de cómputo y almacenamiento (compute-storage separation) o cuando se realizan actualizaciones.
Los problemas recurrentes giran en torno a la gestión de la ingesta de datos, la configuración de almacenamiento, las actualizaciones de versiones y la optimización del rendimiento. La falta de soporte maduro para cloud storage en ClickHouse open source obliga a soluciones personalizadas y a lidiar con ineficiencias (ej., alto número de operaciones de escritura en S3). Las actualizaciones, aunque "fáciles" ahora, requirieron años de desarrollo de procesos y herramientas para lograr cero downtime y evitar regresiones. La ingesta es un punto crítico, donde un diseño deficiente de tablas, un batching incorrecto o una gestión ineficaz de los merges pueden llevar a OOMs, pérdida de datos o tablas en modo read-only.
Las salvaguardas estándar a menudo fallan o son insuficientes debido a la naturaleza específica de ClickHouse. Por ejemplo, la dependencia de ZooKeeper para la replicación introduce un punto de fallo crítico que, si se sobrecarga o falla, puede paralizar el cluster. La falta de un sistema de backpressure robusto y nativo para la ingesta de datos significa que los picos de tráfico pueden desbordar el sistema, resultando en pérdida o duplicación de datos. La necesidad de leer el código fuente para operar ClickHouse de manera efectiva subraya la madurez relativa del ecosistema y la complejidad de sus "entrañas", lo que dificulta la operación sin un conocimiento profundo.