Migration de Snowflake vers ClickHouse

Référence de traduction SQL

​

Types de données

​

Numériques

Les utilisateurs qui déplacent des données entre ClickHouse et Snowflake remarqueront immédiatement que ClickHouse offre une granularité plus fine pour la déclaration des types numériques. Par exemple, Snowflake propose le type Number pour les valeurs numériques. Cela oblige l’utilisateur à spécifier une précision (nombre total de chiffres) et une échelle (nombre de chiffres à droite de la virgule), jusqu’à un total de 38. Les déclarations d’entiers sont synonymes de Number et définissent simplement une précision et une échelle fixes, tout en conservant la même plage de valeurs. Cette commodité est possible, car la modification de la précision (l’échelle est de 0 pour les entiers) n’a pas d’incidence sur la taille des données sur disque dans Snowflake : le nombre minimal d’octets requis pour une plage numérique donnée est utilisé au moment de l’écriture, au niveau de la micro-partition. L’échelle a toutefois un impact sur l’espace de stockage, partiellement compensé par la compression. Un type Float64 offre une plage de valeurs plus étendue, au prix d’une perte de précision.

À l’inverse, ClickHouse propose plusieurs niveaux de précision, signés et non signés, pour les flottants et les entiers. Avec ces types, vous pouvez spécifier explicitement la précision requise pour les entiers afin d’optimiser le stockage et la surcharge mémoire. Un type Decimal, équivalent au type Number de Snowflake, offre également une précision et une échelle deux fois plus élevées, jusqu’à 76 chiffres. En plus d’une valeur Float64 similaire, ClickHouse propose aussi un Float32 lorsque la précision est moins critique et que la compression est primordiale.

​

Chaînes

ClickHouse et Snowflake adoptent des approches opposées pour le stockage des données textuelles. Le VARCHAR de Snowflake contient des caractères Unicode en UTF-8, ce qui permet à l’utilisateur de spécifier une longueur maximale. Cette longueur n’a aucun impact sur le stockage ni sur les performances : le nombre minimal d’octets est toujours utilisé pour stocker une chaîne, et elle sert uniquement à imposer des contraintes utiles aux outils en aval. D’autres types, tels que Text et NChar, sont simplement des alias de ce type. À l’inverse, ClickHouse stocke toutes les données de chaîne sous forme d’octets bruts avec le type String (aucune indication de longueur n’est requise), en laissant à l’utilisateur la gestion de l’encodage, avec des fonctions à l’exécution de la requête disponibles pour différents encodages. Pour en comprendre la logique, nous renvoyons le lecteur à “Opaque data argument”. Le type String de ClickHouse est donc, dans son implémentation, davantage comparable au type Binary de Snowflake. Snowflake et ClickHouse prennent tous deux en charge la « collation », ce qui permet aux utilisateurs de redéfinir la manière dont les chaînes sont triées et comparées.

​

Types semi-structurés

Snowflake prend en charge les types VARIANT, OBJECT et ARRAY pour les données semi-structurées.

ClickHouse propose les types équivalents Variant, Object (désormais obsolète au profit du type JSON natif) et Array. En outre, ClickHouse propose le type JSON qui remplace le type Object('json'), désormais obsolète, et qui offre d’excellentes performances ainsi qu’une grande efficacité de stockage par rapport à d’autres types JSON natifs.

ClickHouse prend également en charge les Tuples nommés et les tableaux de Tuple via le type Nested, ce qui permet aux utilisateurs de mapper explicitement des structures imbriquées. Cela permet d’appliquer des codecs et des optimisations de type à toute la hiérarchie, contrairement à Snowflake, qui oblige l’utilisateur à utiliser les types OBJECT, VARIANT et ARRAY pour l’objet externe et ne permet pas le typage interne explicite. Ce typage interne simplifie également les requêtes sur les valeurs numériques imbriquées dans ClickHouse, qui n’ont pas besoin d’être converties et peuvent être utilisées dans des définitions d’index.

Dans ClickHouse, des codecs et des types optimisés peuvent aussi être appliqués aux sous-structures. Cela offre aussi l’avantage supplémentaire de maintenir une excellente compression avec les structures imbriquées, comparable à celle des données aplaties. En revanche, du fait de l’impossibilité d’appliquer des types spécifiques aux sous-structures, Snowflake recommande d’aplatir les données pour obtenir une compression optimale. Snowflake impose également des restrictions de taille pour ces types de données.

​

Référence des types

Snowflake	ClickHouse	Remarque
NUMBER	Decimal	ClickHouse prend en charge une précision et une échelle deux fois plus élevées que Snowflake : 76 chiffres contre 38.
FLOAT, FLOAT4, FLOAT8	Float32, Float64	Dans Snowflake, tous les nombres à virgule flottante sont codés sur 64 bits.
VARCHAR	String
BINARY	String
BOOLEAN	Bool
DATE	Date, Date32	DATE dans Snowflake offre une plage de dates plus étendue que ClickHouse ; par exemple, la valeur minimale de Date32 est 1900-01-01, et celle de Date, 1970-01-01. Dans ClickHouse, Date offre un stockage plus économique (deux octets).
TIME(N)	Pas d’équivalent direct, mais peut être représenté par DateTime et DateTime64(N).	DateTime64 utilise les mêmes notions de précision.
TIMESTAMP - TIMESTAMP_LTZ, TIMESTAMP_NTZ, TIMESTAMP_TZ	DateTime et DateTime64	DateTime et DateTime64 peuvent éventuellement avoir un paramètre TZ défini pour la colonne. S’il n’est pas présent, le fuseau horaire du serveur est utilisé. De plus, un paramètre --use_client_time_zone est disponible pour le client.
VARIANT	JSON, Tuple, Nested	Le type JSON est expérimental dans ClickHouse. Ce type déduit les types des colonnes au moment de l’insertion. Tuple, Nested et Array peuvent aussi être utilisés pour définir explicitement des structures typées, comme alternative.
OBJECT	Tuple, Map, JSON	OBJECT et Map sont tous deux comparables au type JSON dans ClickHouse, où les clés sont des String. ClickHouse exige que la valeur reste cohérente et fortement typée, tandis que Snowflake utilise VARIANT. Cela signifie que les valeurs associées à différentes clés peuvent être de types différents. Si c’est nécessaire dans ClickHouse, définissez explicitement la hiérarchie à l’aide de Tuple ou utilisez le type JSON.
ARRAY	Array, Nested	ARRAY dans Snowflake utilise VARIANT pour ses éléments, un supertype. À l’inverse, dans ClickHouse, ils sont fortement typés.
GEOGRAPHY	Point, Ring, Polygon, MultiPolygon	Snowflake impose un système de coordonnées (WGS 84), tandis que ClickHouse l’applique au moment de la requête.
GEOMETRY	Point, Ring, Polygon, MultiPolygon

Type ClickHouse	Description
IPv4 et IPv6	Types spécifiques aux IP, permettant potentiellement un stockage plus efficace que dans Snowflake.
FixedString	Permet d’utiliser une longueur fixe d’octets, ce qui est utile pour les hachages.
LowCardinality	Permet d’encoder n’importe quel type sous forme de dictionnaire. Utile lorsque la cardinalité attendue est < 100k.
Enum	Permet un encodage efficace de valeurs nommées sur 8 ou 16 bits.
UUID	Pour un stockage efficace des UUID.
Array(Float32)	Les vecteurs peuvent être représentés sous forme d’Array de Float32 avec des fonctions de distance prises en charge.

Enfin, ClickHouse offre la capacité unique de stocker l’ état des fonctions d’agrégation. Cet état est spécifique à l’implémentation, mais il permet de stocker le résultat d’une agrégation pour l’interroger ultérieurement (avec les fonctions de fusion correspondantes). En général, cette fonctionnalité est utilisée via une vue matérialisée et, comme illustré ci-dessous, permet d’améliorer les performances de requêtes spécifiques avec un coût de stockage minimal en stockant le résultat incrémental de requêtes sur des données insérées (plus de détails ici).