ClickHouse peut accepter et renvoyer des données dans différents formats. Un format pris en charge pour l'entrée peut être utilisée pour analyser les données fournies à `INSERT`s, pour effectuer `SELECT`s à partir d'une table sauvegardée par fichier, telle Qu'un fichier, une URL ou un HDFS, ou pour lire un dictionnaire externe. Un format pris en charge pour la sortie peut être utilisé pour organiser
les résultats d'une `SELECT` et pour effectuer `INSERT`s dans une table sauvegardée par fichier.
Vous pouvez contrôler certains paramètres de traitement de format avec les paramètres ClickHouse. Pour plus d'informations, lisez le [Paramètre](../operations/settings/settings.md) section.
Au format TabSeparated, les données sont écrites par ligne. Chaque ligne contient des valeurs séparées par des onglets. Chaque valeur est suivie par un onglet, à l'exception de la dernière valeur dans la ligne, qui est suivi par un saut de ligne. Les flux de ligne strictement Unix sont supposés partout. La dernière ligne doit également contenir un saut de ligne à la fin. Les valeurs sont écrites au format texte, sans guillemets et avec des caractères spéciaux échappés.
Le `TabSeparated` le format est pratique pour le traitement des données à l'aide de programmes et de scripts personnalisés. Il est utilisé par défaut dans L'interface HTTP et dans le mode batch du client de ligne de commande. Ce format permet également de transférer des données entre différents SGBD. Par exemple, vous pouvez obtenir un dump de MySQL et le télécharger sur ClickHouse, ou vice versa.
Le `TabSeparated` format prend en charge la sortie des valeurs totales (lors de L'utilisation avec des totaux) et des valeurs extrêmes (lorsque ‘extremes’ est réglé sur 1). Dans ces cas, les valeurs totales et les extrêmes sont sorties après les données principales. Le résultat principal, les valeurs totales et les extrêmes sont séparés les uns des autres par une ligne vide. Exemple:
Les nombres entiers sont écrits sous forme décimale. Les numéros peuvent contenir un supplément “+” caractère au début (ignoré lors de l'analyse, et non enregistré lors du formatage). Les nombres non négatifs ne peuvent pas contenir le signe négatif. Lors de la lecture, il est permis d'analyser une chaîne vide en tant que zéro, ou (pour les types signés) une chaîne composée d'un signe moins en tant que zéro. Les nombres qui ne correspondent pas au type de données correspondant peuvent être analysés comme un nombre différent, sans message d'erreur.
Les nombres à virgule flottante sont écrits sous forme décimale. Le point est utilisé comme séparateur décimal. Les entrées exponentielles sont prises en charge, tout comme ‘inf’, ‘+inf’, ‘-inf’, et ‘nan’. Une entrée de nombres à virgule flottante peut commencer ou se terminer par une virgule décimale.
Pendant le formatage, la précision peut être perdue sur les nombres à virgule flottante.
Les Dates sont écrites au format AAAA-MM-JJ et analysées dans le même format, mais avec tous les caractères comme séparateurs.
Les Dates avec les heures sont écrites dans le format `YYYY-MM-DD hh:mm:ss` et analysé dans le même format, mais avec des caractères comme séparateurs.
Tout cela se produit dans le fuseau horaire du système au moment où le client ou le serveur démarre (selon lequel d'entre eux formate les données). Pour les dates avec des heures, l'heure d'été n'est pas spécifiée. Donc, si un vidage a des temps pendant l'heure d'été, le vidage ne correspond pas sans équivoque aux données, et l'analyse sélectionnera l'une des deux fois.
Lors d'une opération de lecture, les dates et dates incorrectes avec des heures peuvent être analysées avec un débordement naturel ou en tant que dates et heures nulles, sans message d'erreur.
À titre d'exception, l'analyse des dates avec des heures est également prise en charge au format d'horodatage Unix, si elle se compose exactement de 10 chiffres décimaux. Le résultat n'est pas dépendant du fuseau horaire. Les formats AAAA-MM-JJ hh:mm:ss et NNNNNNNNNN sont différenciés automatiquement.
Les chaînes sont sorties avec des caractères spéciaux échappés par une barre oblique inverse. Les séquences d'échappement suivantes sont utilisées pour la sortie: `\b`, `\f`, `\r`, `\n`, `\t`, `\0`, `\'`, `\\`. L'analyse prend également en charge les séquences `\a`, `\v`, et `\xHH` (séquences d'échappement hexadécimales) et `\c` séquences, où `c` est un caractère (ces séquences sont convertis à `c`). Ainsi, la lecture de données prend en charge les formats où un saut de ligne peut être écrit comme `\n` ou `\` ou comme un saut de ligne. Par exemple, la chaîne `Hello world` avec un saut de ligne entre les mots au lieu de l'espace peut être analysé dans l'une des variantes suivantes:
L'ensemble minimum de caractères que vous devez échapper lors du passage de données au format TabSeparated: tab, saut de ligne (LF) et barre oblique inverse.
Les tableaux sont écrits sous la forme d'une liste de valeurs séparées par des virgules entre crochets. Le nombre d'éléments dans le tableau sont formatés comme normalement. `Date` et `DateTime` les types sont écrits entre guillemets simples. Les chaînes sont écrites entre guillemets simples avec les mêmes règles d'échappement que ci-dessus.
Pendant l'analyse, la première ligne est complètement ignorée. Vous ne pouvez pas utiliser les noms de colonnes pour déterminer leur position ou vérifier leur exactitude.
(La prise en charge de l'analyse de la ligne d'en-tête peut être ajoutée à l'avenir.)
Diffère de la `TabSeparated` format que les noms de colonne sont écrits à la première ligne, tandis que les types de colonne sont dans la deuxième rangée.
Il utilise les paramètres `format_template_resultset`, `format_template_row`, `format_template_rows_between_delimiter` and some settings of other formats (e.g.`output_format_json_quote_64bit_integers` lors de l'utilisation de `JSON` s'échapper, voir plus loin)
`Search phrase: ${SearchPhrase:Quoted}, count: ${c:Escaped}, ad price: $$${price:JSON};`
les valeurs de `SearchPhrase`, `c` et `price` colonnes, qui sont échappées comme `Quoted`, `Escaped` et `JSON` imprimées (pour sélectionner) ou sera prévu (insert) entre `Search phrase:`, `, count:`, `, ad price: $` et `;` délimiteurs respectivement. Exemple:
`Search phrase: 'bathroom interior design', count: 2166, ad price: $3;`
Le `format_template_rows_between_delimiter` paramètre spécifie délimiteur entre les lignes, qui est imprimé (ou attendu) après chaque ligne, sauf la dernière (`\n` par défaut)
Paramètre `format_template_resultset` spécifie le chemin d'accès au fichier, qui contient une chaîne de format pour resultset. Format string for resultset a la même syntaxe qu'une chaîne de format pour row et permet de spécifier un préfixe, un suffixe et un moyen d'imprimer des informations supplémentaires. Il contient les espaces réservés suivants au lieu des noms de colonnes:
-`data` est les lignes avec des données dans `format_template_row` format, séparés par des `format_template_rows_between_delimiter`. Cet espace doit être le premier espace réservé dans la chaîne de format.
-`rows_before_limit` est le nombre minimal de lignes qu'il y aurait eu sans limite. Sortie uniquement si la requête contient LIMIT. Si la requête contient GROUP BY, rows\_before\_limit\_at\_least est le nombre exact de lignes qu'il y aurait eu sans limite.
-`time` est le temps d'exécution de la requête en secondes
Réservé `data`, `totals`, `min` et `max` ne doit pas avoir de règle d'échappement spécifiée (ou `None` doit être spécifié explicitement). Les espaces réservés restants peuvent avoir une règle d'échappement spécifiée.
Si l' `format_template_resultset` paramètre est une chaîne vide, `${data}` est utilisé comme valeur par défaut.
`PageViews`, `UserID`, `Duration` et `Sign` à l'intérieur des espaces réservés sont des noms de colonnes dans la table. Les valeurs après `Useless field` en rangées et après `\nTotal rows:` dans le suffixe sera ignoré.
Tous les séparateurs dans les données d'entrée doivent être strictement égal à délimiteurs dans les chaînes de format.
Semblable à `Template`, mais ignore les espaces entre les séparateurs et les valeurs dans le flux d'entrée. Toutefois, si les chaînes de format contiennent des espaces, ces caractères seront attendus dans le flux d'entrée. Permet également de spécifier des espaces réservés vides (`${}` ou `${:None}`) pour diviser un délimiteur en parties séparées pour ignorer les espaces entre eux. Ces espaces réservés sont utilisés uniquement pour ignorer les caractères d'espace.
Il est possible de lire `JSON` l'utilisation de ce format, si les valeurs des colonnes ont le même ordre dans toutes les lignes. Par exemple, la requête suivante peut être utilisée pour insérer des données à partir d'un exemple de format de sortie [JSON](#json):
Similaire à TabSeparated, mais affiche une valeur au format name = value. Les noms sont échappés de la même manière qu'au format TabSeparated, et le symbole = est également échappé.
Quand il y a un grand nombre de petites colonnes, ce format est inefficace, et il n'y a généralement pas de raison de l'utiliser. Néanmoins, ce n'est pas pire que JSONEachRow en termes d'efficacité.
Both data output and parsing are supported in this format. For parsing, any order is supported for the values of different columns. It is acceptable for some values to be omitted – they are treated as equal to their default values. In this case, zeros and blank rows are used as default values. Complex values that could be specified in the table are not supported as defaults.
Lors du formatage, les lignes sont entourées de guillemets doubles. Un guillemet double à l'intérieur d'une chaîne est affiché sous la forme de deux guillemets doubles dans une rangée. Il n'y a pas d'autres règles pour échapper les caractères. Date et date-heure sont entre guillemets. Les nombres sont produits sans guillemets. Les valeurs sont séparées par un caractère délimiteur, qui est `,` par défaut. Le caractère délimiteur est défini dans le paramètre [format\_csv\_delimiter](../operations/settings/settings.md#settings-format_csv_delimiter). Les lignes sont séparées à L'aide du saut de ligne Unix (LF). Les tableaux sont sérialisés au format CSV comme suit: tout d'abord, le tableau est sérialisé en une chaîne comme au format TabSeparated, puis la chaîne résultante est sortie au format CSV entre guillemets doubles. Les Tuples au format CSV sont sérialisés en tant que colonnes séparées (c'est-à-dire que leur imbrication dans le tuple est perdue).
\*Par défaut, le délimiteur est `,`. Voir la [format\_csv\_delimiter](../operations/settings/settings.md#settings-format_csv_delimiter) réglage pour plus d'informations.
Lors de l'analyse, toutes les valeurs peuvent être analysés avec ou sans guillemets. Les guillemets doubles et simples sont pris en charge. Les lignes peuvent également être organisées sans guillemets. Dans ce cas, ils sont analysés jusqu'au caractère délimiteur ou au saut de ligne (CR ou LF). En violation de la RFC, lors de l'analyse des lignes sans guillemets, les espaces et les onglets de début et de fin sont ignorés. Pour le saut de ligne, les types Unix (LF), Windows (CR LF) et Mac OS Classic (CR LF) sont tous pris en charge.
`NULL` est formaté en tant qu' `\N` ou `NULL` ou une chaîne vide non cotée (voir paramètres [input\_format\_csv\_unquoted\_null\_literal\_as\_null](../operations/settings/settings.md#settings-input_format_csv_unquoted_null_literal_as_null) et [input\_format\_defaults\_for\_omitted\_fields](../operations/settings/settings.md#session_settings-input_format_defaults_for_omitted_fields)).
Semblable à [Modèle](#format-template), mais il imprime ou lit toutes les colonnes et utilise la règle d'échappement du paramètre `format_custom_escaping_rule` et délimiteurs de paramètres `format_custom_field_delimiter`, `format_custom_row_before_delimiter`, `format_custom_row_after_delimiter`, `format_custom_row_between_delimiter`, `format_custom_result_before_delimiter` et `format_custom_result_after_delimiter`, pas à partir de chaînes de format.
Sorties de données au format JSON. Outre les tables de données, il génère également des noms et des types de colonnes, ainsi que des informations supplémentaires: le nombre total de lignes de sortie et le nombre de lignes qui auraient pu être sorties s'il n'y avait pas de limite. Exemple:
Le JSON est compatible avec JavaScript. Pour ce faire, certains caractères sont en outre échappés: la barre oblique `/` s'est échappée comme l' `\/`; sauts de ligne alternatifs `U+2028` et `U+2029`, qui cassent certains navigateurs, sont échappés comme `\uXXXX`. Les caractères de contrôle ASCII sont échappés: retour arrière, flux de formulaire, saut de ligne, retour chariot et tabulation horizontale sont remplacés par `\b`, `\f`, `\n`, `\r`, `\t` , ainsi que les octets restants dans la plage 00-1F en utilisant `\uXXXX` sequences. Invalid UTF-8 sequences are changed to the replacement character <20> so the output text will consist of valid UTF-8 sequences. For compatibility with JavaScript, Int64 and UInt64 integers are enclosed in double-quotes by default. To remove the quotes, you can set the configuration parameter [output\_format\_json\_quote\_64bit\_integers](../operations/settings/settings.md#session_settings-output_format_json_quote_64bit_integers) à 0.
Lorsque vous utilisez ce format, ClickHouse affiche les lignes en tant qu'objets JSON séparés et délimités par des retours à la ligne, mais les données dans leur ensemble ne sont pas JSON valides.
INSERT INTO UserActivity FORMAT JSONEachRow {"PageViews":5, "UserID":"4324182021466249494", "Duration":146,"Sign":-1} {"UserID":"4324182021466249494","PageViews":6,"Duration":185,"Sign":1}
ClickHouse ignore les espaces entre les éléments et les virgules après les objets. Vous pouvez passer tous les objets en une seule ligne. Vous n'avez pas à les séparer avec des sauts de ligne.
Si `DEFAULT expr` clickhouse utilise différentes règles de substitution en fonction de [input\_format\_defaults\_for\_omitted\_fields](../operations/settings/settings.md#session_settings-input_format_defaults_for_omitted_fields) paramètre.
Considérons le tableau suivant:
``` sql
CREATE TABLE IF NOT EXISTS example_table
(
x UInt32,
a DEFAULT x * 2
) ENGINE = Memory;
```
- Si `input_format_defaults_for_omitted_fields = 0`, alors la valeur par défaut pour `x` et `a` égal `0` (la valeur par défaut pour le `UInt32` type de données).
- Si `input_format_defaults_for_omitted_fields = 1`, alors la valeur par défaut pour `x` égal `0` mais la valeur par défaut de `a` égal `x * 2`.
Lors de l'insertion de données avec `insert_sample_with_metadata = 1`, ClickHouse consomme plus de ressources de calcul, par rapport à l'insertion avec `insert_sample_with_metadata = 0`.
Contrairement à l' [JSON](#json) format, il n'y a pas de substitution de séquences UTF-8 non valides. Les valeurs sont échappés de la même manière que pour `JSON`.
Tout ensemble d'octets peut être sortie dans les cordes. L'utilisation de la `JSONEachRow` formater si vous êtes sûr que les données de la table peuvent être formatées en tant que JSON sans perdre aucune information.
Si vous avez une table avec [Imbriqué](../sql-reference/data-types/nested-data-structures/nested.md) colonnes de type de données, vous pouvez insérer des données JSON avec la même structure. Activer cette fonctionnalité avec le [input\_format\_import\_nested\_json](../operations/settings/settings.md#settings-input_format_import_nested_json) paramètre.
CREATE TABLE json_each_row_nested (n Nested (s String, i Int32) ) ENGINE = Memory
```
Comme vous pouvez le voir dans la `Nested` description du type de données, ClickHouse traite chaque composant de la structure imbriquée comme une colonne distincte (`n.s` et `n.i` pour notre table). Vous pouvez insérer des données de la manière suivante:
``` sql
INSERT INTO json_each_row_nested FORMAT JSONEachRow {"n.s": ["abc", "def"], "n.i": [1, 23]}
Pour insérer des données en tant qu'objet JSON hiérarchique, définissez [input\_format\_import\_nested\_json=1](../operations/settings/settings.md#settings-input_format_import_nested_json).
Le format le plus efficace. Les données sont écrites et lues par des blocs au format binaire. Pour chaque bloc, le nombre de lignes, le nombre de colonnes, les noms et types de colonnes et les parties de colonnes de ce bloc sont enregistrés les uns après les autres. En d'autres termes, ce format est “columnar” – it doesn't convert columns to rows. This is the format used in the native interface for interaction between servers, for using the command-line client, and for C++ clients.
Vous pouvez utiliser ce format pour générer rapidement des vidages qui ne peuvent être lus que par le SGBD ClickHouse. Cela n'a pas de sens de travailler avec ce format vous-même.
Rien n'est sortie. Cependant, la requête est traitée et, lors de l'utilisation du client de ligne de commande, les données sont transmises au client. Ceci est utilisé pour les tests, y compris les tests de performance.
Évidemment, ce format n'est approprié que pour la sortie, pas pour l'analyse.
Affiche les données sous forme de tables Unicode-art, en utilisant également des séquences d'échappement ANSI pour définir les couleurs dans le terminal.
Chaque bloc de résultat est sorti sous la forme d'une table séparée. Ceci est nécessaire pour que les blocs puissent être sortis sans résultats de mise en mémoire tampon (la mise en mémoire tampon serait nécessaire pour pré-calculer la largeur visible de toutes les valeurs).
Exemple (montré pour le [PrettyCompact](#prettycompact) format):
``` sql
SELECT * FROM t_null
```
``` text
┌─x─┬────y─┐
│ 1 │ ᴺᵁᴸᴸ │
└───┴──────┘
```
Les lignes ne sont pas échappées dans les formats Pretty\*. Exemple est montré pour la [PrettyCompact](#prettycompact) format:
``` sql
SELECT 'String with \'quotes\' and \t character' AS Escaping_test
```
``` text
┌─Escaping_test────────────────────────┐
│ String with 'quotes' and character │
└──────────────────────────────────────┘
```
Pour éviter de déverser trop de données sur le terminal, seules les 10 000 premières lignes sont imprimées. Si le nombre de lignes est supérieur ou égal à 10 000, le message “Showed first 10 000” est imprimé.
Le joli format prend en charge la sortie des valeurs totales (lors de L'utilisation avec des totaux) et des extrêmes (lorsque ‘extremes’ est réglé sur 1). Dans ces cas, les valeurs totales et les valeurs extrêmes sont sorties après les données principales, dans des tableaux séparés. Exemple (montré pour le [PrettyCompact](#prettycompact) format):
Diffère de [PrettyCompact](#prettycompact) dans ce cas, jusqu'à 10 000 lignes sont mises en mémoire tampon, puis sorties en tant que table unique, pas par blocs.
Diffère de Pretty en ce que les séquences d'échappement ANSI ne sont pas utilisées. Ceci est nécessaire pour afficher ce format dans un navigateur, ainsi que pour utiliser le ‘watch’ utilitaire de ligne de commande.
Le tableau est représenté sous la forme d'une longueur varint (non signée [LEB128](https://en.wikipedia.org/wiki/LEB128)), suivie par les éléments de la matrice.
Pour [NULL](../sql-reference/syntax.md#null-literal) un soutien, un octet supplémentaire contenant 1 ou 0 est ajouté avant chaque [Nullable](../sql-reference/data-types/nullable.md) valeur. Si la valeur est 1, alors la valeur est `NULL` et cet octet est interprétée comme une valeur distincte. Si 0, la valeur après l'octet n'est pas `NULL`.
Imprime chaque ligne entre parenthèses. Les lignes sont séparées par des virgules. Il n'y a pas de virgule après la dernière ligne. Les valeurs entre parenthèses sont également séparées par des virgules. Les nombres sont produits dans un format décimal sans guillemets. Les tableaux sont affichés entre crochets. Les chaînes, les dates et les dates avec des heures sont affichées entre guillemets. Les règles d'échappement et l'analyse sont similaires à [TabSeparated](#tabseparated) format. Pendant le formatage, les espaces supplémentaires ne sont pas insérés, mais pendant l'analyse, ils sont autorisés et ignorés (sauf pour les espaces à l'intérieur des valeurs de tableau, qui ne sont pas autorisés). [NULL](../sql-reference/syntax.md) est représentée comme `NULL`.
Imprime chaque valeur sur une ligne distincte avec le nom de colonne spécifié. Ce format est pratique pour imprimer une ou plusieurs lignes si chaque ligne est constituée d'un grand nombre de colonnes.
Semblable à [Vertical](#vertical), mais avec échapper désactivé. Ce format ne convient que pour la sortie des résultats de requête, pas pour l'analyse (recevoir des données et les insérer dans la table).
Si le nom de colonne n'a pas un format acceptable, juste ‘field’ est utilisé comme le nom de l'élément. En général, la structure XML suit la structure JSON.
Les tableaux sont produits comme `<array><elem>Hello</elem><elem>World</elem>...</array>`,et n-uplets d' `<tuple><elem>Hello</elem><elem>World</elem>...</tuple>`.
Les messages Cap'n Proto sont strictement typés et ne sont pas auto-descriptifs, ce qui signifie qu'ils ont besoin d'une description de schéma externe. Le schéma est appliqué à la volée et mise en cache pour chaque requête.
Les messages imbriqués conviennent à l'entrée ou à la sortie d'un [structures de données imbriquées](../sql-reference/data-types/nested-data-structures/nested.md).
Clickhouse entrées et sorties messages protobuf dans le `length-delimited` format.
Cela signifie avant que chaque message devrait être écrit sa longueur comme un [varint](https://developers.google.com/protocol-buffers/docs/encoding#varints).
Voir aussi [comment lire / écrire des messages protobuf délimités par la longueur dans les langues populaires](https://cwiki.apache.org/confluence/display/GEODE/Delimiting+Protobuf+Messages).
ClickHouse Avro format prend en charge la lecture et l'écriture [Fichiers de données Avro](http://avro.apache.org/docs/current/spec.html#Object+Container+Files).
Le tableau ci-dessous montre les types de données pris en charge et comment ils correspondent à ClickHouse [types de données](../sql-reference/data-types/index.md) dans `INSERT` et `SELECT` requête.
Pour trouver la correspondance entre les colonnes de table et les champs du schéma Avro ClickHouse compare leurs noms. Cette comparaison est sensible à la casse.
Les types de données des colonnes de la table ClickHouse peuvent différer des champs correspondants des données Avro insérées. Lors de l'insertion de données, ClickHouse interprète les types de données selon le tableau ci-dessus, puis [jeter](../sql-reference/functions/type-conversion-functions.md#type_conversion_function-cast) les données au type de colonne correspondant.
Pour sélectionner des données de la table ClickHouse dans un fichier Avro:
``` bash
$ clickhouse-client --query="SELECT * FROM {some_table} FORMAT Avro" > file.avro
```
Les noms de colonnes doivent:
- commencer avec `[A-Za-z_]`
- par la suite contenir uniquement `[A-Za-z0-9_]`
Sortie Avro fichier de compression et sync intervalle peut être configuré avec [output\_format\_avro\_codec](../operations/settings/settings.md#settings-output_format_avro_codec) et [output\_format\_avro\_sync\_interval](../operations/settings/settings.md#settings-output_format_avro_sync_interval) respectivement.
## AvroConfluent {#data-format-avro-confluent}
Avroconfluent prend en charge le décodage des messages Avro à objet unique couramment utilisés avec [Kafka](https://kafka.apache.org/) et [Confluentes Schéma De Registre](https://docs.confluent.io/current/schema-registry/index.html).
L'URL du registre de schéma est configurée avec [format\_avro\_schema\_registry\_url](../operations/settings/settings.md#settings-format_avro_schema_registry_url)
Pour vérifier rapidement la résolution du schéma, vous pouvez utiliser [kafkacat](https://github.com/edenhill/kafkacat) avec [clickhouse-local](../operations/utilities/clickhouse-local.md):
[Apache Parquet](http://parquet.apache.org/) est un format de stockage colonnaire répandu dans L'écosystème Hadoop. ClickHouse prend en charge les opérations de lecture et d'écriture pour ce format.
Le tableau ci-dessous montre les types de données pris en charge et comment ils correspondent à ClickHouse [types de données](../sql-reference/data-types/index.md) dans `INSERT` et `SELECT` requête.
Clickhouse prend en charge la précision configurable de `Decimal` type. Le `INSERT` requête traite le Parquet `DECIMAL` tapez comme le ClickHouse `Decimal128` type.
Types de données Parquet non pris en charge: `DATE32`, `TIME32`, `FIXED_SIZE_BINARY`, `JSON`, `UUID`, `ENUM`.
Les types de données des colonnes de table ClickHouse peuvent différer des champs correspondants des données de Parquet insérées. Lors de l'insertion de données, ClickHouse interprète les types de données selon le tableau ci-dessus, puis [jeter](../query_language/functions/type_conversion_functions/#type_conversion_function-cast) les données de ce type de données qui est défini pour la colonne de la table ClickHouse.
[Apache ORC](https://orc.apache.org/) est un format de stockage colonnaire répandu dans L'écosystème Hadoop. Vous ne pouvez insérer des données dans ce format à ClickHouse.
Le tableau ci-dessous montre les types de données pris en charge et comment ils correspondent à ClickHouse [types de données](../sql-reference/data-types/index.md) dans `INSERT` requête.
Clickhouse prend en charge la précision configurable de la `Decimal` type. Le `INSERT` requête traite de l'ORC `DECIMAL` tapez comme le ClickHouse `Decimal128` type.
Les types de données des colonnes de la table ClickHouse ne doivent pas correspondre aux champs de données Orc correspondants. Lors de l'insertion de données, ClickHouse interprète les types de données selon le tableau ci-dessus, puis [jeter](../sql-reference/functions/type-conversion-functions.md#type_conversion_function-cast) les données du type de données défini pour la colonne clickhouse table.
il peut être omis et dans ce cas, le format de schéma ressemble `schemafile:MessageType`.
Si vous entrez ou sortez des données via le [client](../interfaces/cli.md) dans le [mode interactif](../interfaces/cli.md#cli_usage) le nom de fichier spécifié dans le format de schéma
peut contenir un chemin absolu, soit un chemin relatif au répertoire courant sur le client.
Si vous utilisez le client dans le [mode batch](../interfaces/cli.md#cli_usage), le chemin d'accès au schéma doit être relatif pour des raisons de sécurité.
doit être situé dans le répertoire spécifié dans [format\_schema\_path](../operations/server-configuration-parameters/settings.md#server_configuration_parameters-format_schema_path)
Certains formats tels que `CSV`, `TabSeparated`, `TSKV`, `JSONEachRow`, `Template`, `CustomSeparated` et `Protobuf` pouvez ignorer brisé ligne si erreur d'analyse s'est produite et poursuivre l'analyse à partir du début de la ligne suivante. Voir [input\_format\_allow\_errors\_num](../operations/settings/settings.md#settings-input_format_allow_errors_num) et
- En cas d'erreur d'analyse `JSONEachRow` ignore toutes les données jusqu'à la nouvelle ligne (ou EOF), donc les lignes doivent être délimitées par `\n` pour compter les erreurs correctement.
-`Template` et `CustomSeparated` utilisez delimiter après la dernière colonne et delimiter entre les lignes pour trouver le début de la ligne suivante, donc sauter les erreurs ne fonctionne que si au moins l'une d'entre elles n'est pas vide.
