Por qué ClickHouse va ganando en la guerra de la observabilidad

 (matduggan.com)
3 puntos por GN⁺ 6 시간 전 | 1 comentarios | Compartir por WhatsApp
  • A diferencia de la experiencia de grep en sistemas pequeños, cuando aumentan los servicios y los consumidores, en los logs se combinan gran volumen, falta de estructura y consultas impredecibles, lo que los convierte en los datos más difíciles de manejar en observabilidad
  • ClickHouse empezó como una base de datos para análisis de clickstream, pero encaja bien con los patrones de uso de los logs: alto volumen, escrituras principalmente append-only, orden temporal y lecturas agregadas
  • El almacenamiento orientado a columnas permite leer solo las columnas necesarias y, en datos reales de observabilidad, muestra tasas de compresión de 10–14x, frente a 2–3x de Elasticsearch
  • A escala de 1 TB/día, varias stacks son viables, pero al crecer a 5 TB/día y 10 TB/día, Elasticsearch, LGTM y Datadog cambian mucho en arquitectura o costo, mientras que ClickHouse escala sobre todo agregando shards
  • ClickHouse exige diseño inicial del esquema y complejidad en el motor de consultas, pero incluso cuando los datos crecen varias veces, el modelo operativo no se altera demasiado

Por qué los logs son difíciles en observabilidad

  • Los desarrolladores tienen expectativas altas sobre la búsqueda en logs porque, en sistemas pequeños, tuvieron la experiencia de manejarlos rápido con grep, jq y tail -f
  • Ese enfoque funciona bien cuando el sistema es pequeño, el volumen de logs es bajo y quien consulta escribió directamente las líneas de log
  • Cuando la escala crece, aparecen al mismo tiempo schema drift, explosión de cardinalidad, consumidores entre equipos y requisitos de dashboards
  • Quien escribe logs no es solo el desarrollador
    • El equipo de soporte al cliente necesita encontrar eventos como un pago fallido de un usuario específico
    • El equipo de datos puede construir dashboards de negocio sobre líneas de log que un ingeniero de backend puede cambiar
    • Quien está de guardia espera que la barra de búsqueda funcione de inmediato, sin tener que aprender un nuevo lenguaje de consultas o patrones de índices
  • Desde el punto de vista técnico, el volumen de datos es grande, la forma es irregular y es difícil predecir qué consultas van a llegar
  • Los desarrolladores quieren inmediatez, operaciones arbitrarias y esquemas flexibles; los usuarios no técnicos quieren dashboards estables y una UI tolerante

La estructura de ClickHouse encaja con los logs

  • ClickHouse fue creado en Yandex para procesar consultas analíticas a gran escala sobre datos de clickstream
  • No fue diseñado específicamente para observabilidad, pero los datos de clickstream y los de observabilidad tienen mucho en común
    • Datos masivos
    • Escrituras centradas en append
    • Enfoque en orden temporal
    • Lecturas principalmente agregadas
    • Patrones de uso donde a veces hay que encontrar registros específicos
  • También hay varias opciones de operación
    • Se puede ejecutar directamente con un Helm chart
    • Se puede usar el plugin de ClickHouse para Grafana, su propia web UI o un frontend construido por cuenta propia
    • Con el exporter de ClickHouse para OpenTelemetry Collector se pueden insertar directamente datos OTLP y delegar el manejo inicial del esquema
  • Está diseñado para escanear miles de millones de filas y recolectar volúmenes de datos muy grandes
  • El lenguaje de consultas no es uno nuevo y específico, sino SQL

La diferencia que crean el almacenamiento por columnas y la compresión

  • Por la forma de los datos, los logs son cercanos a append-only
    • Las líneas de log no se actualizan
    • Casi no hay borrados individuales; cuando termina el período de retención, se eliminan en bloque
    • En general llegan en orden temporal, aunque no completamente ordenados
  • Los patrones de lectura cambian de forma explosiva durante incidentes o análisis
    • Puede pasar que nadie los mire por días, pero durante una falla se quiera revisar miles de millones en segundos
    • Es común mirar varios campos en una ventana de tiempo estrecha o agregar en una ventana amplia con pocos filtros
    • Es raro el patrón de encontrar una sola fila por un ID específico, como en una base de datos transaccional
  • Las bases de datos orientadas a filas como Elasticsearch, Postgres o MySQL almacenan juntos todos los campos de una línea de log
    • Aunque solo se necesiten 3 de 40 campos, en disco se terminan leyendo los 40
  • ClickHouse guarda cada columna por separado
    • Una consulta que usa solo timestamp, service y status_code lee únicamente esas columnas
    • Aunque haya decenas de atributos, en datos de observabilidad donde una consulta concreta usa solo 3 o 4 columnas, la diferencia en volumen de lectura es grande
  • Los datos por columna se comprimen bien porque los valores dentro de una misma columna suelen parecerse entre sí
    • En una columna service_name, incluso con miles de millones de filas, puede haber solo unos cientos de strings únicos
    • En datos reales de observabilidad es común ver tasas de compresión de 10–14x
    • Eso contrasta claramente con el 2–3x de Elasticsearch

En 1 TB/día, la mayoría de las stacks son viables

  • A una escala de 1 TB/día, las stacks modernas de observabilidad en general son utilizables; hay diferencias, pero todavía no llegan a un punto doloroso

  • Elasticsearch

    • Se puede operar con un clúster de Elasticsearch relativamente básico y buffering con Logstash
    • La búsqueda de texto completo es una fortaleza de Elasticsearch y en esta escala funciona bien
    • En datos mixtos existe el riesgo de mapping explosion, así que hay que desactivar dynamic mapping o definir con cuidado las plantillas
    • Las políticas ILM de hot → warm → delete ya son imprescindibles en esta escala
    • El costo ronda aproximadamente los $6–9K al mes

  • LGTM

    • Alloy unifica la recolección en un solo daemon
    • Loki funciona bien si se educa a los desarrolladores para que apliquen labels útiles
    • Mimir y Tempo cumplen en general con el rol esperado
    • El costo ronda aproximadamente los $3.5–5K al mes

  • Datadog

    • En 1 TB/día, la experiencia de uso es buena: basta con instalar el agente y mirar los dashboards
    • Ya aparecen temas como metered pipeline, la distinción entre indexed vs ingested logs y el costo de cardinalidad en custom metrics, pero en esta escala son manejables
    • El costo ronda aproximadamente los $45–75K al mes, aunque las diferencias por precio negociado son grandes y conviene tomar la cifra como referencia amplia
    • La lógica de precios de Datadog es que te ahorra un ingeniero dedicado

  • ClickHouse

    • En 1 TB/día, ClickHouse no es menos complejo que otras opciones
    • Requiere diseño de esquema desde el principio, y la clave ORDER BY es muy importante
    • Con ZSTD y códecs adecuados se puede lograr compresión de 10–14x
    • Altinity Operator maneja la coordinación con keeper y todo corre en unos 7 pods
    • No hay PromQL nativo; el flujo de métricas pasa por el plugin de Grafana o por chproxy y un adapter
    • El costo ronda aproximadamente los $1.5–2.5K al mes

En 5 TB/día, las diferencias de arquitectura se amplían

  • En 5 TB/día, la curva de crecimiento se vuelve más empinada en la mayoría de las stacks, y la diferencia frente a ClickHouse se nota más

  • Elasticsearch

    • Kafka se vuelve prácticamente obligatorio
    • Si se escribe directo a Elasticsearch, durante picos de tráfico el clúster puede caerse por bulk reject y backpressure
    • Con un target shard de 50 GB, incluyendo réplicas, se generan alrededor de 200 shards por día, y el tamaño mismo del cluster state pasa a ser un problema
    • Por searchable snapshot y frozen tier, prácticamente se necesita la licencia comercial de Elastic
    • El costo ronda los $40–55K al mes antes de la licencia

  • LGTM stack

    • Pasa a un modo de microservicios con más de 65 pods y tres sistemas separados
    • Cada sistema tiene su propio pipeline de compaction, hash ring y capa de memcached
    • El ring basado en gossip/memberlist se vuelve una preocupación operativa real
    • El rollout de ingesters requiere ajustar -ingester.autoforget-unhealthy, y si se hace mal puede haber pérdida o duplicación de datos
    • El costo ronda aproximadamente los $22–32K al mes

  • Datadog

    • La complejidad operativa sigue siendo baja porque no se administran servidores directamente
    • Pero a cambio hace falta un equipo dedicado de pipelines para reducir el costo de Datadog
    • Aparecen mecanismos como exclusion filter, sampling rule, cardinality cap y tag allow-list
    • El costo ronda aproximadamente los $180–350K al mes, según qué tan agresivo sea el equipo de pipelines
    • La relación pasa a ser la de bajar costos mirando los documentos de facturación del proveedor SaaS

  • ClickHouse

    • El cambio más grande es agregar shards
    • El operator, el motor de consultas, el lenguaje de consultas y el modelo mental siguen igual
    • Después de agregar shards, el rebalanceo sigue siendo manual; la mayoría de los equipos lo evita con aprovisionamiento anticipado o con weighting en tablas Distributed
    • Las materialized views para rollups de dashboards pasan de ser algo conveniente a algo casi obligatorio
    • El costo ronda aproximadamente los $7–11K al mes

En 10 TB/día, el modelo operativo se separa

  • 10 TB/día es una escala en la que muchas soluciones empiezan a no soportar bien la carga operativa

  • Elasticsearch

    • Se terminan operando 3 clústeres separados de Elasticsearch para logs, metrics y APM, unidos con Cross-Cluster Search
    • El costo de NVMe en el hot tier domina la factura
    • En esta escala, los equipos empiezan a evaluar seriamente alternativas, y muchas migraciones recientes a ClickHouse salen de aquí
    • El costo ronda aproximadamente los $95–140K al mes además de la licencia comercial
    • Operar Elasticsearch a esta escala requiere expertos de verdad

  • LGTM

    • Se necesitan más de 180 pods, configuración zone-aware, split-and-merge compaction, límites por tenant y shuffle sharding para evitar noisy neighbors
    • Prácticamente se requiere un equipo dedicado de plataforma de observabilidad de 3 a 5 personas
    • El costo ronda aproximadamente los $55–85K al mes

  • Datadog

    • Sigue siendo fácil en el sentido de que no hay servidores propios que administrar, pero la factura mensual puede llegar a cifras de 6 o 7 dígitos
    • Es muy probable que la organización forme un equipo de pipelines de preprocesamiento para reducir la factura
    • Muchas empresas de este tamaño usan una configuración híbrida: Datadog para APM y métricas de alto valor, y logs en infraestructura autohospedada
    • Cada vez más, ese destino autohospedado es ClickHouse
    • El resultado es una estructura donde coexisten la simplicidad de Datadog, la complejidad del pipeline y una segunda stack autohospedada
    • El costo varía mucho y puede superar $1M al mes

  • ClickHouse

    • La configuración de 1 TB/día y el panorama general siguen siendo básicamente los mismos; la diferencia es que hay más shards
    • Las materialized views para rollups dejan de ser opcionales y pasan a ser obligatorias
    • Los errores de diseño de esquema cometidos hace 2 años pueden doler mucho en esta escala
    • El rebalanceo después de agregar shards sigue siendo manual
    • La mayoría de los equipos hace aprovisionamiento anticipado o usa clickhouse-copier y migraciones con dual-write
    • Para ingestas con picos muy marcados, Kafka se vuelve útil como buffer, aunque no es obligatorio
    • El costo ronda aproximadamente los $18–28K al mes

Criterios de elección

  • En 1 TB/día, casi cualquier stack funciona razonablemente bien, así que conviene elegir lo que el equipo ya conoce
  • La pregunta importante no es si funciona hoy, sino si dentro de 2 años mantendrá la misma forma cuando los datos se multipliquen por 5, el equipo se duplique y la persona que hizo el diseño inicial ya no esté
  • Elasticsearch y LGTM cambian de arquitectura a medida que crecen
  • Datadog es simple en operación, pero en costos termina convirtiéndose en algo que requiere un equipo aparte de finanzas y pipelines
  • ClickHouse crece agregando shards
  • El precio a pagar es asumir desde el inicio el diseño del esquema y la complejidad del motor de consultas
  • Si se paga ese costo, la experiencia de desarrolladores y operadores en general se mantiene incluso cuando los datos crecen mucho más

Lecturas relacionadas

1 comentarios

 
GN⁺ 6 시간 전
Opiniones en Lobste.rs

  • Una startup en la que trabajé brevemente en 2019 había construido muchas cosas bastante impresionantes y en ese momento me mostraron un poco de ClickHouse; me dejó una impresión muy fuerte.
    Hasta entonces pensaba que rara vez necesitaría algo que no fuera PostgreSQL, pero ClickHouse me dieron ganas de usarlo.
    También había probado ElasticSearch, InfluxDB y otros, pero siempre me parecieron flojos, quizá porque cada uno había creado su propio lenguaje de consultas desde cero. En cambio, ClickHouse adoptó el SQL familiar y lo extendió adecuadamente solo donde hacía falta.
    Como ocurre con los productos exitosos, en ClickHouse se nota la calidad de implementación y la consideración por el usuario, y hasta los detalles pequeños vienen bien ajustados por defecto.
    En mi empresa actual usamos HyperDX; los gráficos de métricas son algo engorrosos, pero el tracing funciona bastante bien. Pensé que el tracing se volvería rápidamente una herramienta indispensable y aumentaría mucho la productividad, pero viendo que no se adopta tanto como esperaba, quizá no sea una función tan revolucionaria como creía. Aun así, me alegra que ClickHouse se esté volviendo un actor central en este espacio y que eso permita lidiar con menos cosas.

    • Introducir tracing en una organización que venía sobreviviendo solo con métricas y logs es, por experiencia, una subida bastante empinada.
      Hace falta mucha evangelización, recopilar casos de uso y hacer el trabajo difícil de mostrar en persona que ahora se pueden hacer cosas que antes no, y cuánto más fáciles se volvieron las cosas que antes eran complicadas.
      Técnicamente, la adopción también tiene que ser lo más fluida posible, pero según el stack y la situación eso puede ser en sí mismo un gran esfuerzo, y normalmente esa carga recae en la persona que impulsa la adopción.
      No es muy distinto de una iniciativa amplia a nivel organizacional, así que ayuda tener credibilidad personal y una o dos personas verdaderamente convencidas dentro de la empresa que lo difundan.
    • Me pregunto si te refieres al lenguaje de consultas JSON de ElasticSearch. ElasticSearch soporta multiple query languages, incluido un dialecto de SQL.
      No sé qué tan buena sea la calidad de ese soporte, pero lo único que he usado directamente es el lenguaje de consultas JSON, y acabo de enterarme de los otros.
      SQL no es perfecto como lenguaje de consultas. Es molesto que no puedas duplicar cláusulas ni escribirlas en cualquier orden, pero aun así SQL es un lenguaje muy bueno.

  • Mi experiencia es similar a la del autor. La escalabilidad de ClickHouse es sorprendentemente buena y, aun operándolo uno mismo, se siente más como simplemente agregar más cores.
    El costo de configuración inicial puede ser un poco más alto, pero en la práctica el esquema queda casi determinado por la exportación de OTel, así que puedes empezar con eso y luego ir sacando columnas y vistas materializadas cuando necesites más rendimiento en las consultas.
    A cambio, puedes preocuparte menos por escalar, usar todos los datos directamente para análisis e incluso derivar métricas a partir de traces.
    Eso sí, la otra pieza del rompecabezas, la visualización, todavía necesita mejorar mucho. Grafana no es lo óptimo para mostrar y analizar traces si se lo compara con herramientas como Honeycomb. Espero que alguno de los actores existentes lo resuelva pronto; quizá sea HyperDX.

  • Al principio este artículo parecía arrancar fuerte, con una introducción convincente, pero cuando pasó a analizar varias empresas se desmoronó en un texto de listas con un estilo de LLM de bajo esfuerzo muy evidente.
    Al volver a leer la introducción con más ojo crítico, también empecé a ver cada vez más rastros de eso.
    Es un patrón que veo cada vez más seguido en artículos de Lobsters, así que quiero dejarlo como una reflexión breve sobre una observación más general, más que como un ataque a un artículo específico.
    Personalmente no tengo mucha experiencia con herramientas de observabilidad, así que algunas partes del artículo me resultaron interesantes independientemente de cómo estuviera escrito. Pero no quiero caer en el error de confiar en un LLM cuando el tema no me resulta familiar y decir que un texto de LLM es flawed cuando sí conozco el tema.
    Por eso no sé bien si debería confiar factualemente en este artículo o en la mayoría de artículos parecidos. Parece claro que el autor delegó gran parte del razonamiento a la máquina, aunque la idea inicial sí parecía bastante clara.
    También al programar, una idea clara en mi cabeza solo me convence de que le falta algo fundamental cuando realmente escribo el programa y este falla en pruebas de casos límite o no pasa el type checker.
    Con la escritura pasa lo mismo: si no elaboras tú mismo el argumento, armas el conjunto y consideras cuidadosamente las objeciones, creo que no transmites más valor que el de la idea clara original.
    Probablemente sea esto lo que quieren decir quienes proponen escribir código guardando solo prompts para futuros LLM.
    Pero si programar o escribir se reducen por completo a eso, no solo estamos abandonando el pensamiento, sino también el rigor, la honestidad y el respeto.
    No sé muy bien qué debería hacer Lobsters al respecto. La etiqueta vibecoding ya parece una solución sobrecargada. Pero quizá ayudaría tener una etiqueta de olor a LLM como señal para estar atentos a la falta de rigor.

    • Yo tampoco quería poner esto como comentario de primer nivel, pero al entrar al artículo resultó ser simplemente frases hechas estilo LLM, y sentí que había desperdiciado un poco el tiempo que pasé leyendo el inicio.
    • Desde la perspectiva de alguien que ha usado bastante herramientas de observabilidad, el artículo me pareció bastante claro y razonable.
      El argumento central es que cada producto escala de una manera distinta, y muestra con diagramas y explicaciones concretas qué ocurre en cada escala.
      Si hubo una parte en la que sentiste que el razonamiento se abandonó de forma evidente, me gustaría ver un ejemplo.
    • Matthew al menos es alguien bastante versado en observabilidad. Fue tech lead en Braintree y ahora es Principal en SYBO, conocida por Subway Surfers.
      Las partes con groserías también dejan ver en cierta medida su propia voz.
      Si lo pasas por GPTZero, da 71% de probabilidad de LLM y 28% mixto. Aunque, por el límite de caracteres, tuve que recortar la introducción, que era la parte que más humana se leía.
      Entiendo el rechazo, pero parece más bien un texto que sí fue revisado e iterado, solo que no filtró las expresiones que suenan a LLM ni optimizó el tono. Hoy ya no alcanza con no usar em dash para evitar el olor.

  • A quienes tienen experiencia con Honeycomb, me da curiosidad cómo encaja en este contexto.
    Por lo que entiendo, Honeycomb también usa un formato de almacenamiento columnar y depende mucho de compresión y bucketing para saltarse grandes cantidades de datos al leer. Tengo entendido que no usa un índice invertido como Elastic o Datadog, y que Datadog internamente también corre Elastic.

    • Recuerdo que hace algunos años Charity Majors, cofundadora de Honeycomb, dijo en Twitter que si ClickHouse hubiera existido cuando fundaron la empresa, probablemente simplemente lo habrían usado.
      Eso sí, no tengo claro cuánto se superponen conceptualmente los dos sistemas en la práctica. Sería interesante saber si el dominio del problema llevó naturalmente a enfoques parecidos; personalmente esperaría que sí.

  • Puede que a algunas personas les incomode, pero el uso de cierta palabra me resultaba tan distractor que simplemente hice un buscar y reemplazar de esas palabras por otras que no me molestaran, y el texto quedó mucho mejor.
    No voy a decir qué palabra era, pero es una expresión que cada vez se usa de forma más imprecisa y me irrita. Me gustó que con un simple buscar y reemplazar el texto se pudiera leer cómodamente.