Migración de Snowflake a ClickHouse

Los usuarios que trasladan datos entre ClickHouse y Snowflake notarán de inmediato que ClickHouse ofrece una mayor granularidad en la definición de tipos numéricos. Por ejemplo, Snowflake ofrece el tipo Number para valores numéricos. Esto requiere que el usuario especifique una precisión (número total de dígitos) y una escala (dígitos a la derecha del separador decimal), hasta un total de 38. Las declaraciones de enteros son equivalentes a Number y simplemente definen una precisión y una escala fijas, con el mismo rango. Esta comodidad es posible porque modificar la precisión (la escala es 0 para enteros) no afecta al tamaño de los datos en disco en Snowflake: se utilizan los bytes mínimos necesarios para un rango numérico en el momento de la escritura, a nivel de micropartición. Sin embargo, la escala sí afecta al espacio de almacenamiento, aunque esto se compensa con compresión. Un tipo Float64 ofrece un rango más amplio de valores, a costa de precisión.

En contraste, ClickHouse ofrece múltiples precisiones con signo y sin signo para flotantes y enteros. Con ellas, puedes especificar de forma explícita la precisión necesaria para los enteros a fin de optimizar el almacenamiento y el uso de memoria. Un tipo Decimal, equivalente al tipo Number de Snowflake, también ofrece el doble de precisión y escala, hasta 76 dígitos. Además de un valor Float64 similar, ClickHouse también proporciona un Float32 para los casos en que la precisión es menos crítica y la compresión es prioritaria.

ClickHouse y Snowflake adoptan enfoques distintos para el almacenamiento de datos de cadenas. El VARCHAR de Snowflake almacena caracteres Unicode en UTF-8, lo que permite al usuario especificar una longitud máxima. Esta longitud no afecta al almacenamiento ni al rendimiento, ya que siempre se utiliza el número mínimo de bytes para almacenar una cadena, y más bien solo impone restricciones útiles para las herramientas posteriores. Otros tipos, como Text y NChar, son simplemente alias de este tipo. ClickHouse, por el contrario, almacena todos los datos de cadena como bytes sin procesar con un tipo String (no es necesario especificar una longitud), dejando la codificación en manos del usuario, con funciones en tiempo de consulta disponibles para distintas codificaciones. Remitimos al lector a "Opaque data argument" para entender la motivación de este enfoque. Por tanto, la implementación de String en ClickHouse es más comparable al tipo Binary de Snowflake. Tanto Snowflake como ClickHouse admiten “collation”, lo que permite a los usuarios definir cómo se ordenan y comparan las cadenas.

Snowflake admite los tipos VARIANT, OBJECT y ARRAY para datos semiestructurados.

ClickHouse ofrece los tipos equivalentes Variant, Object (actualmente obsoleto en favor del tipo JSON nativo) y Array. Además, ClickHouse cuenta con el tipo JSON, que sustituye al ya obsoleto tipo Object('json') y destaca especialmente por su rendimiento y eficiencia de almacenamiento en comparación con otros tipos JSON nativos.

ClickHouse también admite Tuples con nombre y arrays de Tuples mediante el tipo Nested, lo que permite a los usuarios mapear explícitamente estructuras anidadas. Esto permite aplicar codecs y optimizaciones de tipos en toda la jerarquía, a diferencia de Snowflake, que requiere que el usuario utilice los tipos OBJECT, VARIANT y ARRAY para el objeto externo y no permite el tipado interno explícito. Este tipado interno también simplifica las consultas sobre valores numéricos anidados en ClickHouse, que no necesitan convertirse mediante cast y pueden usarse en definiciones de índices.

En ClickHouse, los codecs y los tipos optimizados también pueden aplicarse a subestructuras. Esto ofrece la ventaja adicional de que la compresión con estructuras anidadas sigue siendo excelente y comparable a la de los datos aplanados. En cambio, debido a la imposibilidad de aplicar tipos específicos a las subestructuras, Snowflake recomienda aplanar los datos para lograr una compresión óptima. Snowflake también impone restricciones de tamaño para estos tipos de datos.

Por último, ClickHouse ofrece la capacidad única de almacenar el estado de las funciones de agregación. Este estado es específico de la implementación, pero permite almacenar el resultado de una agregación y consultarlo posteriormente (con las funciones de combinación correspondientes). Normalmente, esta funcionalidad se usa mediante una vista materializada y, como se muestra a continuación, permite mejorar el rendimiento de consultas específicas con un coste de almacenamiento mínimo al almacenar el resultado incremental de las consultas sobre los datos insertados (más detalles aquí).