Este documento ofrece una introducción a la migración de datos de Snowflake a ClickHouse.Snowflake es un data warehouse en la nube centrado principalmente en migrar a la nube cargas de trabajo heredadas de data warehousing on-premise. Está bien optimizado para ejecutar informes de larga duración a gran escala. A medida que los conjuntos de datos migran a la nube, los propietarios de los datos empiezan a pensar en qué otras formas pueden extraer valor de ellos, incluido el uso de estos conjuntos de datos para impulsar aplicaciones en tiempo real en casos de uso internos y externos. Cuando esto ocurre, a menudo se dan cuenta de que necesitan una base de datos optimizada para la analítica en tiempo real, como ClickHouse.
Comparación
Similitudes
Diferencias
- Los recursos de cómputo en Snowflake se proporcionan mediante el concepto de warehouses. Estos constan de varios nodos, cada uno de un tamaño determinado. Aunque Snowflake no publica la arquitectura específica de sus warehouses, se acepta generalmente que cada nodo consta de 8 vCPU, 16 GiB y 200 GB de almacenamiento local (para caché). El número de nodos depende de un tamaño predefinido; por ejemplo, un x-small tiene un nodo, un small 2, medium 4, large 8, etc. Estos warehouses son independientes de los datos y pueden utilizarse para consultar cualquier base de datos alojada en almacenamiento de objetos. Cuando están inactivos y no reciben carga de consultas, los warehouses se ponen en pausa y se reanudan cuando llega una consulta. Aunque los costes de almacenamiento siempre se reflejan en la facturación, los warehouses solo se cobran cuando están activos.
- ClickHouse Cloud utiliza un principio similar de nodos con almacenamiento de caché local. En lugar de tamaños predefinidos, los usuarios implementan un servicio con una cantidad total de cómputo y RAM disponible. Esto, a su vez, se escala automáticamente de forma transparente (dentro de límites definidos) según la carga de consultas, ya sea verticalmente, aumentando (o reduciendo) los recursos de cada nodo, o horizontalmente, aumentando o reduciendo el número total de nodos. Los nodos de ClickHouse Cloud tienen una relación CPU-memoria de 1, a diferencia de la de Snowflake. Aunque es posible un acoplamiento más flexible, los servicios están acoplados a los datos, a diferencia de los warehouses de Snowflake. Los nodos también se pondrán en pausa si están inactivos y se reanudarán cuando reciban consultas. También puede cambiar manualmente el tamaño de los servicios si es necesario.
- La caché de consultas de ClickHouse Cloud es específica de cada nodo, a diferencia de la de Snowflake, que se ofrece en una capa de servicio independiente del warehouse. Según benchmarks, la caché de nodos de ClickHouse Cloud ofrece mejor rendimiento que la de Snowflake.
- Snowflake y ClickHouse Cloud adoptan enfoques distintos para el escalado con el fin de aumentar la concurrencia de consultas. Snowflake lo aborda mediante una funcionalidad conocida como multi-cluster warehouses. Esta funcionalidad le permite añadir clústeres a un warehouse. Aunque esto no ofrece ninguna mejora en la latencia de las consultas, sí proporciona paralelización adicional y permite una mayor concurrencia de consultas. ClickHouse lo consigue añadiendo más memoria y CPU a un servicio mediante escalado vertical u horizontal. No exploramos las capacidades de estos servicios para escalar a niveles más altos de concurrencia en este blog, sino que nos centramos en la latencia, pero reconocemos que este trabajo debería realizarse para contar con una comparación completa. Sin embargo, cabría esperar que ClickHouse rindiera bien en cualquier prueba de concurrencia, ya que Snowflake limita explícitamente el número de consultas concurrentes permitidas para un warehouse a 8 de forma predeterminada. En comparación, ClickHouse Cloud permite ejecutar hasta 1000 consultas por nodo.
- La capacidad de Snowflake para cambiar el tamaño del cómputo de un dataset, junto con los rápidos tiempos de reanudación de los warehouses, hace que la experiencia para consultas ad hoc sea excelente. Para casos de uso de data warehouse y lago de datos, esto proporciona una ventaja sobre otros sistemas.
Analítica en tiempo real
- Latencia de consulta: Las consultas de Snowflake tienen una mayor latencia incluso cuando se aplica clustering a las tablas para optimizar el rendimiento. En nuestras pruebas, Snowflake requiere más del doble de capacidad de cómputo para lograr un rendimiento equivalente al de ClickHouse en consultas en las que se aplica un filtro que forma parte de la clave de clustering de Snowflake o de la clave primaria de ClickHouse. Aunque la persistent caché de consultas de Snowflake compensa parte de estos problemas de latencia, resulta ineficaz en los casos en que los criterios de filtrado son más diversos. La eficacia de esta caché de consultas también puede verse afectada por cambios en los datos subyacentes, ya que las entradas de la caché se invalidan cuando cambia la tabla. Aunque este no es el caso en el benchmark de nuestra aplicación, una implementación real requeriría que se insertaran datos nuevos y más recientes. Tenga en cuenta que la caché de consultas de ClickHouse es específica de cada nodo y no es transactionally consistent, lo que la hace más adecuada para la analítica en tiempo real. Los usuarios también tienen un control granular sobre su uso, ya que pueden controlarla por consulta, su tamaño preciso, si una consulta se almacena en caché (límites de duración o número mínimo de ejecuciones), y si solo se usa pasivamente.
- Menor costo: Los warehouses de Snowflake pueden configurarse para suspenderse después de un período de inactividad de las consultas. Una vez suspendidos, no se generan cargos. En la práctica, esta comprobación de inactividad solo puede reducirse a 60 s. Los warehouses se reanudan automáticamente en varios segundos una vez que se recibe una consulta. Como Snowflake solo cobra por los recursos cuando un warehouse está en uso, este comportamiento se adapta a workloads que suelen permanecer inactivos, como las consultas ad hoc. Sin embargo, muchos workloads de analítica en tiempo real requieren ingestión continua de datos en tiempo real y consultas frecuentes que no se benefician de quedar inactivos (como los dashboards orientados al cliente). Esto significa que los warehouses a menudo deben estar completamente activos y generando cargos. Esto elimina la ventaja de costos del estado inactivo, así como cualquier ventaja de rendimiento que pueda estar asociada con la capacidad de Snowflake para recuperar un estado operativo con mayor rapidez que las alternativas. Este requisito de estado activo, combinado con el menor costo por segundo de ClickHouse Cloud en ese estado, hace que ClickHouse Cloud ofrezca un costo total significativamente menor para este tipo de workloads.
-
Precios predecibles de las funcionalidades: Funcionalidades como las vistas materializadas
y el clustering (equivalente al
ORDER BYde ClickHouse) son necesarias para alcanzar los niveles más altos de rendimiento en casos de uso de analítica en tiempo real. Estas funcionalidades generan cargos adicionales en Snowflake, lo que exige no solo un tier superior, que incrementa los costos por crédito en 1,5 veces, sino también costos de mantenimiento en segundo plano difíciles de predecir. Por ejemplo, las vistas materializadas generan un costo de mantenimiento en segundo plano, al igual que el clustering, que es difícil de prever antes de su uso. En contraste, estas funcionalidades no generan ningún costo adicional en ClickHouse Cloud, salvo un mayor uso de CPU y memoria en el momento de la inserción, normalmente insignificante fuera de casos de uso con altas cargas de inserción. Hemos observado en nuestro benchmark que estas diferencias, junto con menores latencias de consulta y una mayor compresión, dan como resultado costos significativamente más bajos con ClickHouse.