Formats de données d’entrée et de sortie

Aperçu des formats de données pris en charge en entrée et en sortie dans ClickHouse

​

Formats des données d’entrée et de sortie

ClickHouse prend en charge la plupart des formats de données textuels et binaires courants. Cela permet de l’intégrer facilement à presque n’importe quel pipeline de données afin de tirer parti des avantages de ClickHouse.

​

Formats d’entrée

Les formats d’entrée sont utilisés pour :

• Analyser les données fournies aux instructions INSERT
• Exécuter des requêtes SELECT à partir de tables basées sur des fichiers, telles que File, URL ou HDFS
• Lire des dictionnaires

Choisir le bon format d’entrée est essentiel pour une ingestion de données efficace dans ClickHouse. Avec plus de 70 formats pris en charge, sélectionner l’option la plus performante peut avoir un impact significatif sur la vitesse d’insertion, l’utilisation du CPU et de la mémoire, ainsi que sur l’efficacité globale du système. Pour vous aider à vous y retrouver parmi ces options, nous avons évalué les performances d’ingestion selon les formats, ce qui fait ressortir les points clés suivants :

• Le format Native est le format d’entrée le plus efficace, offrant la meilleure compression, la plus faible consommation de ressources et un minimum de surcoût de traitement côté serveur.
• La compression est essentielle - LZ4 réduit la taille des données avec un coût CPU minimal, tandis que ZSTD offre un taux de compression plus élevé au prix d’une utilisation supplémentaire du CPU.
• Le prétri a un impact modéré, car ClickHouse trie déjà efficacement.
• Le traitement par lots améliore considérablement l’efficacité - des lots plus volumineux réduisent le surcoût des insertions et améliorent le débit.

Pour une analyse détaillée des résultats et des bonnes pratiques, consultez l’analyse complète du benchmark. Pour consulter l’ensemble des résultats des tests, explorez le tableau de bord en ligne FastFormats.

​

Formats de sortie

Les formats de sortie pris en charge servent à :

• Organiser les résultats d’une requête SELECT
• Effectuer des opérations INSERT dans des tables basées sur des fichiers

​

Aperçu des formats

Les formats pris en charge sont :

Format	Entrée	Sortie
TabSeparated	✔	✔
TabSeparatedRaw	✔	✔
TabSeparatedWithNames	✔	✔
TabSeparatedWithNamesAndTypes	✔	✔
TabSeparatedRawWithNames	✔	✔
TabSeparatedRawWithNamesAndTypes	✔	✔
Template	✔	✔
TemplateIgnoreSpaces	✔	✗
CSV	✔	✔
CSVWithNames	✔	✔
CSVWithNamesAndTypes	✔	✔
CustomSeparated	✔	✔
CustomSeparatedWithNames	✔	✔
CustomSeparatedWithNamesAndTypes	✔	✔
SQLInsert	✗	✔
Values	✔	✔
Vertical	✗	✔
JSON	✔	✔
JSONAsString	✔	✗
JSONAsObject	✔	✗
JSONStrings	✗	✔
JSONColumns	✔	✔
JSONColumnsWithMetadata	✔	✔
JSONCompact	✔	✔
JSONCompactStrings	✗	✔
JSONCompactColumns	✔	✔
JSONEachRow	✔	✔
PrettyJSONEachRow	✗	✔
JSONEachRowWithProgress	✗	✔
JSONStringsEachRow	✔	✔
JSONStringsEachRowWithProgress	✗	✔
JSONCompactEachRow	✔	✔
JSONCompactEachRowWithNames	✔	✔
JSONCompactEachRowWithNamesAndTypes	✔	✔
JSONCompactEachRowWithProgress	✗	✔
JSONCompactStringsEachRow	✔	✔
JSONCompactStringsEachRowWithNames	✔	✔
JSONCompactStringsEachRowWithNamesAndTypes	✔	✔
JSONCompactStringsEachRowWithProgress	✗	✔
JSONObjectEachRow	✔	✔
BSONEachRow	✔	✔
TSKV	✔	✔
Pretty	✗	✔
PrettyNoEscapes	✗	✔
PrettyMonoBlock	✗	✔
PrettyNoEscapesMonoBlock	✗	✔
PrettyCompact	✗	✔
PrettyCompactNoEscapes	✗	✔
PrettyCompactMonoBlock	✗	✔
PrettyCompactNoEscapesMonoBlock	✗	✔
PrettySpace	✗	✔
PrettySpaceNoEscapes	✗	✔
PrettySpaceMonoBlock	✗	✔
PrettySpaceNoEscapesMonoBlock	✗	✔
Prometheus	✗	✔
Protobuf	✔	✔
ProtobufSingle	✔	✔
ProtobufList	✔	✔
Avro	✔	✔
AvroConfluent	✔	✔
Parquet	✔	✔
ParquetMetadata	✔	✗
Arrow	✔	✔
ArrowStream	✔	✔
ORC	✔	✔
One	✔	✗
Npy	✔	✔
RowBinary	✔	✔
RowBinaryWithNames	✔	✔
RowBinaryWithNamesAndTypes	✔	✔
RowBinaryWithDefaults	✔	✗
RowBinaryWithNamesAndTypesAndDefaults	✔	✗
Native	✔	✔
Buffers	✔	✔
Null	✗	✔
Hash	✗	✔
XML	✗	✔
CapnProto	✔	✔
LineAsString	✔	✔
LineAsStringWithNames	✗	✔
LineAsStringWithNamesAndTypes	✗	✔
Regexp	✔	✗
RawBLOB	✔	✔
MsgPack	✔	✔
MySQLDump	✔	✗
GeoJSON	✔	✗
DWARF	✔	✗
Markdown	✗	✔
Form	✔	✗

Vous pouvez contrôler certains paramètres de traitement des formats à l’aide des paramètres de ClickHouse. Pour plus d’informations, consultez la section Paramètres.

​

Schéma de format

Le nom du fichier contenant le schéma de format est défini par le paramètre format_schema. Il est nécessaire de définir ce paramètre lorsque l’un des formats Cap'n Proto ou Protobuf est utilisé. Le schéma de format est une combinaison d’un nom de fichier et du nom d’un type de message dans ce fichier, séparés par deux-points, par ex. schemafile.proto:MessageType. Si le fichier possède l’extension standard du format (par exemple, .proto pour Protobuf), celle-ci peut être omise et, dans ce cas, le schéma de format prend la forme schemafile:MessageType.

Si vous importez ou exportez des données via le client en mode interactif, le nom du fichier spécifié dans le schéma de format peut contenir un chemin absolu ou un chemin relatif au répertoire courant sur le client. Si vous utilisez le client en mode batch, le chemin du schéma doit être relatif pour des raisons de sécurité.

Si vous importez ou exportez des données via l’interface HTTP, le nom du fichier spécifié dans le schéma de format doit se trouver dans le répertoire indiqué par format_schema_path dans la configuration du serveur.

​

Ignorer les erreurs

Certains formats tels que CSV, TabSeparated, TSKV, JSONEachRow, Template, CustomSeparated et Protobuf peuvent ignorer une ligne corrompue en cas d’erreur d’analyse et reprendre l’analyse au début de la ligne suivante. Consultez les paramètres input_format_allow_errors_num et input_format_allow_errors_ratio. Limites :

• En cas d’erreur d’analyse, JSONEachRow ignore toutes les données jusqu’au saut de ligne (ou à la fin du fichier), donc les lignes doivent être délimitées par \n pour que les erreurs soient correctement comptabilisées.
• Template et CustomSeparated utilisent le délimiteur après la dernière colonne et le délimiteur entre les lignes pour repérer le début de la ligne suivante ; l’ignorance des erreurs ne fonctionne donc que si au moins l’un des deux n’est pas vide.