PostHog abandona DuckDB tras alcanzar 2 PB y un billón de filas
Why we're moving our warehouse off DuckDB
PostHog reconstruyó su data warehouse sobre DuckDB para dar a cada cliente su propia instancia, pero subestimó la complejidad de las cargas. Con DuckLake, una escritura podía tardar más de tres minutos y el 99% de las estadísticas del catálogo correspondían a tablas inexistentes. Ahora migra a una versión propia de Trino y a HogLake, su formato de tabla abierto, probado primero a escala de petabytes.
Lo que importa es la experiencia que te da, no la tecnología que hay detrás.
- Aurornis
> Hace cinco meses, reconstruimos nuestro almacén de datos sobre DuckDB en lugar de ClickHouse
Se pasaron de ClickHouse a DuckDB hace cinco meses, ¿y luego de DuckDB a su propio derivado de Trino?
El artículo termina antes de decir si la nueva configuración resolvió sus problemas.
Es genial que ahora podamos hacer estas migraciones con poco tiempo de inactividad (¿supongo?) y probar cosas diferentes, pero me gustaría haber leído más sobre las pruebas que hicieron antes de lanzarse. El hecho de que se pasaran a DuckDB sin darse cuenta de que no iba a funcionar a su escala y que solo lo usaran unos meses antes de volver a cambiar no es convincente.
Espero que haya más en esta historia que simplemente no llegó a las publicaciones del blog. Tal como está escrito, me trae recuerdos de algunos equipos con los que trabajé que cambiaban de stack tecnológico cada seis meses porque les gustaba más migrar que ajustar y mantener.
- 0c3ca83
¿Me estoy perdiendo algo aquí, o el único detalle técnico en la publicación es "un billón de filas es muchos datos, quizás probar Trino funcione esta vez"?
Parece mucho movimiento y pocas mediciones o ingeniería.
- bitpush
> Hace cinco meses, reconstruimos nuestro almacén de datos [1] sobre DuckDB en lugar de ClickHouse.
¿Por qué escribieron esta publicación si ni siquiera habían dejado que las cosas se asentaran? Suena como si alguien quisiera cantar victoria (¿y promocionarse?)
- kwillets
A veces una empresa simplemente no es capaz de gestionar un almacén de datos; he trabajado para algunas.
Incluso hice una entrevista telefónica con esta, pero no pude cubrir su loca colcha de requisitos; en ese momento también buscaban a alguien para reescribir el optimizador de ClickHouse, y estaban atascados tratando de redistribuir su clúster, lo que debería llevar una tarde.
Sigo apreciando la empresa porque su propuesta de negocio me recuerda a lo que hacíamos en 2009, una especie de organización de analítica federada sobre un almacén de datos centralizado que permite desarrollar muchas herramientas rápidamente a gran escala.
Pero maldita sea, siguen eligiendo estas plataformas a medio funcionar y dando bandazos de una a otra. En 2010 estábamos aplastando millones de consultas contra tablas de 2 billones de filas en Vertica, y solo ha mejorado para las aplicaciones de datos orientadas al cliente, que es lo que es PostHog. La empresa no parece tener una línea base de qué esperar; el mercado está demasiado saturado de herramientas lentas que bajan las expectativas.
- hasyimibhar
Me pregunto si han considerado volver a ClickHouse. El soporte de ClickHouse Iceberg ha mejorado mucho en los últimos meses. Puedes ejecutar fácilmente ClickHouse sin estado sobre Iceberg. Esto resuelve el problema de multiinquilino, y puede manejar fácilmente escala de petabytes [1].
[1] https://clickhouse.com/blog/jump-trading-uses-clickhouse-wit...
- avree
No he visto el sitio web de PostHog en un tiempo. Vaya, es horrible.
- whinvik
La idea clave que saco de esto es que a medida que las migraciones se vuelvan más fáciles de hacer con agentes, habrá muchas más.
Pero lo más importante es que muchas ocurrirán porque todos estaremos más predispuestos a iniciar una. Por otro lado, tampoco sé si a escalas como las de PostHog se puede probar una migración exitosa sin hacerla toda.
- yukIttEft
No estoy seguro de que sus clientes de nodo único estén contentos con Trino
https://benchmark.clickhouse.com/#system=+Hoaus|ucqs|Tuts&ty...