Перейти к основному содержанию
ClickHouse может автоматически определять структуру входных данных почти во всех поддерживаемых входных форматах. В этом документе описано, когда используется автоматическое определение схемы, как оно работает с различными входными форматами и какие настройки позволяют им управлять.

Использование

Автоматическое определение схемы используется, когда ClickHouse нужно прочитать данные в определённом формате, а структура неизвестна.

Табличные функции file, s3, url, hdfs, azureBlobStorage.

У этих табличных функций есть необязательный аргумент structure, задающий структуру входных данных. Если этот аргумент не указан или задан как auto, структура будет автоматически определена по данным. Пример: Допустим, у нас есть файл hobbies.jsonl в формате JSONEachRow в каталоге user_files со следующим содержимым:
ClickHouse может читать эти данные, не указывая их структуру:
Примечание: формат JSONEachRow был автоматически определён по расширению файла .jsonl. Автоматически определённую структуру можно посмотреть с помощью запроса DESCRIBE:

Движки таблиц File, S3, URL, HDFS, azureBlobStorage

Если список столбцов не указан в запросе CREATE TABLE, структура таблицы будет автоматически определена по данным. Пример: Используем файл hobbies.jsonl. Мы можем создать таблицу с движком File, используя данные из этого файла:

clickhouse-local

У clickhouse-local есть необязательный параметр -S/--structure, задающий структуру входных данных. Если этот параметр не указан или имеет значение auto, структура будет определена по данным. Пример: Возьмем файл hobbies.jsonl. Мы можем выполнить запрос к данным из этого файла с помощью clickhouse-local:

Использование структуры таблицы, в которую выполняется вставка

Когда для вставки данных в таблицу используются табличные функции file/s3/url/hdfs, можно брать структуру из таблицы, в которую выполняется вставка, вместо того чтобы извлекать её из данных. Это может повысить производительность вставки, поскольку определение схемы может занимать некоторое время. Кроме того, это полезно, если у таблицы оптимизированная схема, поэтому преобразования между типами не потребуются. Существует специальная настройка use_structure_from_insertion_table_in_table_functions, которая управляет этим поведением. У неё есть 3 возможных значения:
  • 0 - табличная функция будет извлекать структуру из данных.
  • 1 - табличная функция будет использовать структуру таблицы, в которую выполняется вставка.
  • 2 - ClickHouse автоматически определит, можно ли использовать структуру таблицы, в которую выполняется вставка, или нужно определение схемы. Значение по умолчанию.
Пример 1: Создадим таблицу hobbies1 со следующей структурой:
И вставьте данные из файла hobbies.jsonl:
В этом случае все столбцы из файла вставляются в таблицу без изменений, поэтому ClickHouse будет использовать структуру таблицы назначения вместо определения схемы. Пример 2: Создадим таблицу hobbies2 со следующей структурой:
И вставьте данные из файла hobbies.jsonl:
В этом случае все столбцы из запроса SELECT присутствуют в таблице, поэтому ClickHouse будет использовать структуру таблицы, в которую выполняется вставка. Обратите внимание: это работает только для входных форматов, поддерживающих чтение подмножества столбцов, таких как JSONEachRow, TSKV, Parquet и т. д. (например, для формата TSV это не сработает). Пример 3: Давайте создадим таблицу hobbies3 со следующей структурой:
И вставьте данные из файла hobbies.jsonl:
В этом случае столбец id используется в запросе SELECT, но в таблице такого столбца нет (в ней есть столбец с именем identifier), поэтому ClickHouse не может использовать структуру таблицы для вставки, и будет использовано автоматическое определение схемы. Пример 4: Давайте создадим таблицу hobbies4 со следующей структурой:
И вставьте данные из файла hobbies.jsonl:
В этом случае в запросе SELECT над столбцом hobbies выполняются некоторые операции перед вставкой в таблицу, поэтому ClickHouse не может использовать структуру таблицы, в которую выполняется вставка, и будет использоваться автоматическое определение схемы.

Кэш определения схемы

Для большинства входных форматов при определении схемы считывается часть данных, чтобы определить их структуру, и этот процесс может занимать некоторое время. Чтобы не определять одну и ту же схему каждый раз, когда ClickHouse считывает данные из одного и того же файла, определённая схема кэшируется, и при повторном обращении к тому же файлу ClickHouse использует схему из кэша. Существуют специальные настройки, которые управляют этим кэшем:
  • schema_inference_cache_max_elements_for_{file/s3/hdfs/url/azure} - максимальное количество кэшированных схем для соответствующей табличной функции. Значение по умолчанию — 4096. Эти настройки следует задавать в конфигурации сервера.
  • schema_inference_use_cache_for_{file,s3,hdfs,url,azure} - позволяет включать или отключать использование кэша для определения схемы. Эти настройки можно использовать в запросах.
Схема файла может измениться при изменении данных или настроек формата. Поэтому кэш определения схемы идентифицирует схему по источнику файла, имени формата, используемым настройкам формата и времени последнего изменения файла. Примечание: некоторые файлы, к которым обращаются по URL через табличную функцию url, могут не содержать информацию о времени последнего изменения; для таких случаев есть специальная настройка schema_inference_cache_require_modification_time_for_url. Отключение этой настройки позволяет использовать схему из кэша без времени последнего изменения для таких файлов. Также есть системная таблица schema_inference_cache со всеми текущими схемами в кэше и системный запрос SYSTEM CLEAR SCHEMA CACHE [FOR File/S3/URL/HDFS], который позволяет очищать кэш схем для всех источников или для конкретного источника. Примеры: Давайте попробуем определить структуру примера набора данных из S3 github-2022.ndjson.gz и посмотрим, как работает кэш определения схемы:
Как видите, второй запрос выполнился почти мгновенно. Давайте попробуем изменить некоторые настройки, которые могут повлиять на определяемую схему:
Как видите, кэшированная схема не была использована для того же файла, потому что был изменён параметр, который может влиять на автоматически определяемую схему. Давайте проверим содержимое таблицы system.schema_inference_cache:
Как видите, для одного и того же файла есть две разные схемы. Мы можем очистить кэш схемы с помощью системного запроса:

Текстовые форматы

Для текстовых форматов ClickHouse читает данные построчно, извлекает значения столбцов в соответствии с форматом, а затем использует рекурсивные парсеры и эвристики, чтобы определить тип каждого значения. Максимальное количество строк и байтов, считываемых из данных при определении схемы, задаётся настройками input_format_max_rows_to_read_for_schema_inference (по умолчанию 25000) и input_format_max_bytes_to_read_for_schema_inference (по умолчанию 32Mb). По умолчанию все автоматически определённые типы — Nullable, но это можно изменить с помощью настройки schema_inference_make_columns_nullable (см. примеры в разделе настроек).

Форматы JSON

В форматах JSON ClickHouse разбирает значения в соответствии со спецификацией JSON, а затем пытается подобрать для них наиболее подходящий тип данных. Рассмотрим, как это работает, какие типы могут быть выведены автоматически и какие специальные настройки можно использовать в JSON formats. Примеры Здесь и далее в примерах будет использоваться табличная функция format. Integers, Floats, Bools, Strings:
Даты, DateTimes:
Arrays:
Если массив содержит null, ClickHouse определит типы на основе остальных элементов массива:
Если массив содержит значения разных типов и параметр input_format_json_infer_array_of_dynamic_from_array_of_different_types включён (по умолчанию он включён), такой массив получит тип Array(Dynamic):
Именованные Tuple: Когда включен параметр input_format_json_try_infer_named_tuples_from_objects, при определении схемы ClickHouse попытается вывести именованный Tuple из объектов JSON. Полученный именованный Tuple будет содержать все элементы из всех соответствующих объектов JSON в выборке данных.
Безымянные Tuple: Если настройка input_format_json_infer_array_of_dynamic_from_array_of_different_types отключена, в форматах JSON массивы Array с элементами разных типов рассматриваются как безымянные Tuple.
Если некоторые значения равны null или пусты, мы используем типы соответствующих значений из других строк:
Maps: В JSON можно считывать объекты со значениями одного типа как значения типа Map. Примечание: это работает только при отключённых настройках input_format_json_read_objects_as_strings и input_format_json_try_infer_named_tuples_from_objects.
Вложенные сложные типы:
Если ClickHouse не может определить тип для какого-либо ключа, поскольку данные содержат только null/пустые объекты/пустые массивы, будет использован тип String, если включена настройка input_format_json_infer_incomplete_types_as_strings; в противном случае будет сгенерировано исключение:

Настройки JSON

input_format_json_try_infer_numbers_from_strings
При включении этой настройки числа могут определяться по строковым значениям. По умолчанию эта настройка отключена. Пример:
input_format_json_try_infer_named_tuples_from_objects
Включение этой настройки позволяет определять именованные Tuple по объектам JSON. Получившийся именованный Tuple будет содержать все элементы из всех соответствующих объектов JSON в выборке данных. Это может быть полезно, когда данные JSON не являются разреженными, и выборка данных содержит все возможные ключи объектов. Эта настройка включена по умолчанию. Пример
Query
Response
Query
Response
input_format_json_use_string_type_for_ambiguous_paths_in_named_tuples_inference_from_objects
Включение этой настройки позволяет использовать тип String для неоднозначных путей при выводе именованных Tuple из объектов JSON (если включен параметр input_format_json_try_infer_named_tuples_from_objects) вместо генерации исключения. Это позволяет считывать объекты JSON как именованные Tuple даже при наличии неоднозначных путей. По умолчанию отключено. Примеры Если настройка отключена:
Query
Response
При включенной настройке:
Query
Response
input_format_json_read_objects_as_strings
Включение этой настройки позволяет считывать вложенные JSON-объекты как строки. Эту настройку можно использовать для чтения вложенных JSON-объектов без использования типа объект JSON. Эта настройка включена по умолчанию. Примечание: эта настройка вступит в силу, только если отключена настройка input_format_json_try_infer_named_tuples_from_objects.
input_format_json_read_numbers_as_strings
При включении этой настройки числовые значения можно считывать как строки. Эта настройка включена по умолчанию. Пример
input_format_json_read_bools_as_numbers
При включении этого параметра значения Bool можно читать как числа. Этот параметр включен по умолчанию. Пример:
input_format_json_read_bools_as_strings
При включении этой настройки значения Bool можно считывать как строки. Эта настройка включена по умолчанию. Пример:
input_format_json_read_arrays_as_strings
При включении этого параметра значения JSON-массива можно считывать как строки. Этот параметр включен по умолчанию. Пример
input_format_json_infer_incomplete_types_as_strings
Включение этой настройки позволяет использовать тип String для ключей JSON, которые в выборке данных при определении схемы содержат только Null/{}/[]. В форматах JSON любое значение можно считывать как String, если включены все соответствующие настройки (по умолчанию они все включены), и за счёт использования типа String для ключей с неизвестными типами можно избежать ошибок вида Cannot determine type for column 'column_name' by first 25000 rows of data, most likely this column contains only Nulls or empty Arrays/Maps при определении схемы. Пример:
Query
Response

CSV

В формате CSV ClickHouse извлекает значения столбцов из строки в соответствии с разделителями. ClickHouse ожидает, что все типы, кроме чисел и строк, будут заключены в двойные кавычки. Если значение заключено в двойные кавычки, ClickHouse пытается разобрать данные внутри кавычек с помощью рекурсивного парсера, а затем определить для них наиболее подходящий тип данных. Если значение не заключено в двойные кавычки, ClickHouse пытается разобрать его как число, а если значение не является числом, ClickHouse рассматривает его как строку. Если вы не хотите, чтобы ClickHouse пытался определять сложные типы с помощью парсеров и эвристик, можно отключить настройку input_format_csv_use_best_effort_in_schema_inference, и тогда ClickHouse будет рассматривать все столбцы как String. Если настройка input_format_csv_detect_header включена, ClickHouse попытается определить заголовок с именами столбцов (и, возможно, типами) при определении схемы. Эта настройка включена по умолчанию. Примеры: Целые числа, числа с плавающей точкой, логические значения, строки:
Строки без кавычек:
Даты, DateTimes:
Массивы:
Если массив содержит NULL, ClickHouse будет использовать типы остальных элементов массива:
Map:
Вложенные массивы и Map:
Если ClickHouse не может определить тип значения в кавычках, поскольку данные содержат только значения NULL, ClickHouse будет считать его String:
Пример с отключённой настройкой input_format_csv_use_best_effort_in_schema_inference:
Примеры автоматического определения заголовка (когда input_format_csv_detect_header включен): Только имена:
Имена и типы:
Обратите внимание: заголовок можно определить только если есть хотя бы один столбец с типом, отличным от String. Если все столбцы имеют тип String, заголовок не определяется:

Настройки CSV

input_format_csv_try_infer_numbers_from_strings
Включение этой настройки позволяет определять числа в строковых значениях. По умолчанию эта настройка отключена. Пример:

TSV/TSKV

В форматах TSV/TSKV ClickHouse извлекает значение столбца из строки в соответствии с табличными разделителями, а затем разбирает извлечённое значение с помощью рекурсивного парсера, чтобы определить наиболее подходящий тип. Если тип определить не удаётся, ClickHouse обрабатывает это значение как String. Если вы не хотите, чтобы ClickHouse пытался определять сложные типы с помощью парсеров и эвристик, можно отключить настройку input_format_tsv_use_best_effort_in_schema_inference, и ClickHouse будет обрабатывать все столбцы как Strings. Если включена настройка input_format_tsv_detect_header, ClickHouse при определении схемы попытается определить заголовок с именами столбцов (и, возможно, типами). По умолчанию эта настройка включена. Примеры: Целые числа, числа с плавающей точкой, булевы значения, строки:
Даты, DateTimes:
Массивы:
Если массив содержит NULL, ClickHouse будет использовать типы остальных элементов массива:
Tuple:
Map:
Вложенные Array, Tuple и Map:
Если ClickHouse не может определить тип, поскольку данные содержат только значения NULL, ClickHouse будет считать их типом String:
Пример с отключённой настройкой input_format_tsv_use_best_effort_in_schema_inference:
Примеры автоопределения строки заголовков (когда input_format_tsv_detect_header включен): Только имена:
Имена и типы:
Обратите внимание, что заголовок может быть определён только при наличии хотя бы одного столбца с типом, отличным от String. Если все столбцы имеют тип String, заголовок не определяется:

Значения

В формате Values ClickHouse извлекает значение столбца из строки и затем разбирает его с помощью рекурсивного парсера — аналогично тому, как разбираются литералы. Примеры: Целые числа, числа с плавающей точкой, булевы значения, строки:
Даты, DateTimes:
Массивы:
Если массив содержит null, ClickHouse определит типы на основе остальных элементов массива:
Tuple:
Map-значения:
Вложенные Array, Tuple и Map:
Если ClickHouse не может определить тип, поскольку данные содержат только значения NULL, будет сгенерировано исключение:
Пример при отключённой настройке input_format_tsv_use_best_effort_in_schema_inference:

CustomSeparated

В формате CustomSeparated ClickHouse сначала извлекает из строки все значения столбцов в соответствии с указанными разделителями, а затем пытается определить тип данных для каждого значения на основе правила экранирования. Если включена настройка input_format_custom_detect_header, ClickHouse при определении схемы попытается обнаружить заголовок с именами столбцов (и, возможно, типами). Эта настройка включена по умолчанию. Пример
Пример автоматического определения заголовка (если input_format_custom_detect_header включен):

Template

В формате Template ClickHouse сначала извлекает из строки все значения столбцов в соответствии с указанным шаблоном, а затем пытается определить тип данных каждого значения по правилу его экранирования. Пример Допустим, у нас есть файл resultset со следующим содержимым:
И файл row_format со следующим содержанием:
Затем можно выполнить следующие запросы:

Regexp

Как и в формате Template, в формате Regexp ClickHouse сначала извлекает все значения столбцов из строки в соответствии с указанным регулярным выражением, а затем пытается определить тип данных для каждого значения в соответствии с указанным правилом экранирования. Пример

Настройки текстовых форматов

input_format_max_rows_to_read_for_schema_inference/input_format_max_bytes_to_read_for_schema_inference

Эти настройки определяют объём данных, считываемых при определении схемы. Чем больше строк/байтов считывается, тем больше времени занимает определение схемы, но тем выше вероятность правильно определить типы (особенно если данные содержат много значений NULL). Значения по умолчанию:
  • 25000 для input_format_max_rows_to_read_for_schema_inference.
  • 33554432 (32 Mb) для input_format_max_bytes_to_read_for_schema_inference.

column_names_for_schema_inference

Список имён столбцов, используемых при определении схемы для форматов без явных имён столбцов. Указанные имена будут использоваться вместо значений по умолчанию c1,c2,c3,.... Формат: column1,column2,column3,.... Пример

schema_inference_hints

Список имён столбцов и типов, используемых при определении схемы вместо автоматически определённых типов. Формат: ‘column_name1 column_type1, column_name2 column_type2, …’. Этот параметр можно использовать, чтобы указать типы столбцов, которые не удалось определить автоматически, или для оптимизации схемы. Пример

schema_inference_make_columns_nullable $

Управляет тем, будут ли выведенные типы объявляться как Nullable при выводе схемы для форматов, не содержащих информации о допустимости NULL. Возможные значения:
  • 0 - определённый тип никогда не будет Nullable,
  • 1 - все автоматически определённые типы будут Nullable,
  • 2 или ‘auto’ — для текстовых форматов тип будет выведен как Nullable только в том случае, если столбец содержит NULL в выборке, разбираемой при автоматическом определении схемы; для форматов со строгой типизацией (Parquet, ORC, Arrow) информация о допустимости NULL берётся из метаданных файла,
  • 3 - для текстовых форматов используйте Nullable; для строго типизированных форматов используйте метаданные файла.
По умолчанию: 3. Примеры

input_format_try_infer_integers

Этот параметр не применяется к типу данных JSON.
Если параметр включен, ClickHouse будет пытаться определять целые числа вместо чисел с плавающей точкой при определении схемы для текстовых форматов. Если все числа в столбце из выборочных данных являются целыми, результирующим типом будет Int64; если хотя бы одно число является числом с плавающей точкой, результирующим типом будет Float64. Если выборочные данные содержат только целые числа и хотя бы одно из них является положительным и выходит за пределы Int64, ClickHouse определит тип UInt64. Включен по умолчанию. Примеры

input_format_try_infer_datetimes

Если включено, ClickHouse будет пытаться определять тип DateTime или DateTime64 по строковым полям при определении схемы для текстовых форматов. Если все поля столбца в выборочных данных были успешно разобраны как значения даты и времени, результирующим типом будет DateTime или DateTime64(9) (если у какого-либо значения даты и времени есть дробная часть), если хотя бы одно поле не удалось разобрать как значение даты и времени, результирующим типом будет String. Включено по умолчанию. Примеры

input_format_try_infer_datetimes_only_datetime64

Если параметр включен, ClickHouse всегда будет определять DateTime64(9), когда включен input_format_try_infer_datetimes, даже если значения datetime не содержат дробной части. По умолчанию отключено. Примеры
Примечание: при автоматическом определении схемы обработка значений даты и времени учитывает настройку date_time_input_format

input_format_try_infer_dates

Если включено, ClickHouse будет пытаться определять тип Date по строковым полям при определении схемы для текстовых форматов. Если все поля столбца в выборке данных были успешно разобраны как даты, результирующим типом будет Date, если хотя бы одно поле не удалось разобрать как дату, результирующим типом будет String. Включено по умолчанию. Примеры

input_format_try_infer_exponent_floats

Если включен, ClickHouse будет пытаться распознавать числа с плавающей точкой в экспоненциальной записи в текстовых форматах (кроме JSON, где числа в экспоненциальной записи распознаются всегда). По умолчанию отключен. Пример

Самоописывающие форматы

Самоописывающие форматы содержат информацию о структуре данных в самих данных: это может быть заголовок с описанием, бинарное дерево типов или какая-либо таблица. Чтобы автоматически вывести схему из файлов в таких форматах, ClickHouse считывает часть данных, содержащую информацию о типах, и преобразует её в схему таблицы ClickHouse.

Форматы с суффиксом -WithNamesAndTypes

ClickHouse поддерживает некоторые текстовые форматы с суффиксом -WithNamesAndTypes. Этот суффикс означает, что перед самими данными в них содержатся две дополнительные строки с именами столбцов и типами. При определении схемы для таких форматов ClickHouse считывает первые две строки и извлекает из них имена столбцов и типы. Пример

JSON-форматы с метаданными

Некоторые JSON-форматы ввода (JSON, JSONCompact, JSONColumnsWithMetadata) содержат метаданные с именами и типами столбцов. При определении схемы для таких форматов ClickHouse читает эти метаданные. Пример

Avro

В формате Avro ClickHouse считывает схему из данных и преобразует её в схему ClickHouse, используя следующие соответствия типов: Другие типы Avro не поддерживаются.

Parquet

В формате Parquet ClickHouse считывает схему из данных и преобразует её в схему ClickHouse в соответствии со следующими соответствиями типов: Другие типы Parquet не поддерживаются.

Arrow

В формате Arrow ClickHouse считывает схему из данных и преобразует её в схему ClickHouse в соответствии со следующими типами: Другие типы Arrow не поддерживаются.

ORC

В формате ORC ClickHouse считывает схему из данных и преобразует её в схему ClickHouse в соответствии со следующим соответствием типов: Другие типы ORC не поддерживаются.

Native

Формат Native используется внутри ClickHouse и содержит схему в самих данных. При автоматическом определении схемы ClickHouse считывает её из данных без каких-либо преобразований.

Форматы с внешней схемой

Для таких форматов требуется отдельный файл со схемой, описывающей данные на определённом языке схем. Чтобы автоматически определить схему по файлам в таких форматах, ClickHouse считывает внешнюю схему из отдельного файла и преобразует её в схему таблицы ClickHouse.

Protobuf

При автоматическом определении схемы для формата Protobuf ClickHouse использует следующие соответствия типов:

CapnProto

При автоматическом определении схемы для формата CapnProto ClickHouse использует следующие соответствия типов:

Строго типизированные двоичные форматы

В таких форматах каждое сериализованное значение содержит информацию о своём типе (а возможно, и о своём имени), но информация обо всей таблице отсутствует. При автоматическом определении схемы для таких форматов ClickHouse читает данные строка за строкой (до input_format_max_rows_to_read_for_schema_inference строк или input_format_max_bytes_to_read_for_schema_inference байт) и извлекает тип (и, возможно, имя) каждого значения из данных, а затем преобразует эти типы в типы ClickHouse.

MsgPack

В формате MsgPack между строками нет разделителя, поэтому для использования автоматического определения схемы для этого формата следует указать количество столбцов в таблице с помощью настройки input_format_msgpack_number_of_columns. ClickHouse использует следующие соответствия типов: По умолчанию все выведенные типы имеют обёртку Nullable, но это можно изменить с помощью настройки schema_inference_make_columns_nullable.

BSONEachRow

В формате BSONEachRow каждая строка данных представлена BSON-документом. При автоматическом определении схемы ClickHouse читает BSON-документы по одному и извлекает из данных значения, имена и типы, а затем преобразует эти типы в типы ClickHouse, используя следующие соответствия типов: По умолчанию все определённые типы оборачиваются в Nullable, но это можно изменить с помощью настройки schema_inference_make_columns_nullable.

Форматы с постоянной схемой

В таких форматах данные всегда имеют одну и ту же схему.

LineAsString

В этом формате ClickHouse считывает всю строку данных в один столбец с типом данных String. Для этого формата тип всегда определяется как String, а имя столбца — line. Пример

JSONAsString

В этом формате ClickHouse считывает из данных весь объект JSON в один столбец с типом данных String. Определённый для этого формата тип всегда — String, а имя столбца — json. Пример

JSONAsObject

В этом формате ClickHouse считывает весь объект JSON из данных в один столбец с типом данных JSON. Определённый для этого формата тип всегда — JSON, а имя столбца — json. Пример

Режимы автоматического определения схемы

Автоматическое определение схемы по набору файлов данных может работать в 2 разных режимах: default и union. Режим задаётся настройкой schema_inference_mode.

Режим по умолчанию

В режиме по умолчанию ClickHouse считает, что у всех файлов одна и та же схема, и пытается определить её, читая файлы один за другим, пока это не удастся. Пример: Допустим, у нас есть 3 файла data1.jsonl, data2.jsonl и data3.jsonl со следующим содержимым: data1.jsonl:
data2.jsonl:
data3.jsonl:
Давайте попробуем применить автоматическое определение схемы к этим 3 файлам:
Query
Response
Как видим, у нас нет field3 из файла data3.jsonl. Это происходит потому, что ClickHouse сначала попытался вывести схему по файлу data1.jsonl, но не смог из-за того, что в поле field2 были только значения NULL, а затем попытался вывести схему по data2.jsonl и успешно справился, поэтому данные из файла data3.jsonl не были прочитаны.

Режим union

В режиме union ClickHouse предполагает, что у файлов могут быть разные схемы, поэтому определяет схемы всех файлов, а затем объединяет их в одну общую схему. Допустим, у нас есть 3 файла data1.jsonl, data2.jsonl и data3.jsonl со следующим содержимым: data1.jsonl:
data2.jsonl:
data3.jsonl:
Давайте попробуем автоматически определить схему для этих 3 файлов:
Query
Response
Как видим, у нас есть все поля из всех файлов. Примечание:
  • Поскольку в некоторых файлах могут отсутствовать отдельные столбцы из итоговой схемы, режим union поддерживается только для форматов, которые позволяют читать подмножество столбцов (например, JSONEachRow, Parquet, TSVWithNames и т. д.), и не будет работать с другими форматами (например, CSV, TSV, JSONCompactEachRow и т. д.).
  • Если ClickHouse не сможет вывести схему для одного из файлов, будет сгенерировано исключение.
  • Если файлов много, чтение схемы из всех них может занять много времени.

Автоматическое определение формата

Если формат данных не указан и его нельзя определить по расширению файла, ClickHouse попытается определить формат файла по содержимому. Примеры: Допустим, у нас есть data со следующим содержимым:
Мы можем просмотреть этот файл и выполнить к нему запрос, не указывая формат или структуру:
ClickHouse может автоматически определять лишь некоторые форматы, и это требует времени, поэтому формат всегда лучше указывать явно.
Последнее изменение 25 июня 2026 г.