# Форматы входных и выходных данных ClickHouse может принимать (`INSERT`) и отдавать (`SELECT`) данные в различных форматах. Поддерживаемые форматы и возможность использовать их в запросах `INSERT` и `SELECT` перечислены в таблице ниже. Формат | INSERT | SELECT -------|--------|-------- [TabSeparated](#tabseparated) | ✔ | ✔ | [TabSeparatedRaw](#tabseparatedraw) | ✗ | ✔ | [TabSeparatedWithNames](#tabseparatedwithnames) | ✔ | ✔ | [TabSeparatedWithNamesAndTypes](#tabseparatedwithnamesandtypes) | ✔ | ✔ | [CSV](#csv) | ✔ | ✔ | [CSVWithNames](#csvwithnames) | ✔ | ✔ | [Values](#values) | ✔ | ✔ | [Vertical](#vertical) | ✗ | ✔ | [VerticalRaw](#verticalraw) | ✗ | ✔ | [JSON](#json) | ✗ | ✔ | [JSONCompact](#jsoncompact) | ✗ | ✔ | [JSONEachRow](#jsoneachrow) | ✔ | ✔ | [TSKV](#tskv) | ✔ | ✔ | [Pretty](#pretty) | ✗ | ✔ | [PrettyCompact](#prettycompact) | ✗ | ✔ | [PrettyCompactMonoBlock](#prettycompactmonoblock) | ✗ | ✔ | [PrettyNoEscapes](#prettynoescapes) | ✗ | ✔ | [PrettySpace](#prettyspace) | ✗ | ✔ | [RowBinary](#rowbinary) | ✔ | ✔ | [Native](#native) | ✔ | ✔ | [Null](#null) | ✗ | ✔ | [XML](#xml) | ✗ | ✔ | [CapnProto](#capnproto) | ✔ | ✔ | ## TabSeparated В TabSeparated формате данные пишутся по строкам. Каждая строчка содержит значения, разделённые табами. После каждого значения идёт таб, кроме последнего значения в строке, после которого идёт перевод строки. Везде подразумеваются исключительно unix-переводы строк. Последняя строка также обязана содержать перевод строки на конце. Значения пишутся в текстовом виде, без обрамляющих кавычек, с экранированием служебных символов. Этот формат также доступен под именем `TSV`. Формат `TabSeparated` удобен для обработки данных произвольными программами и скриптами. Он используется по умолчанию в HTTP-интерфейсе, а также в batch-режиме клиента командной строки. Также формат позволяет переносить данные между разными СУБД. Например, вы можете получить дамп из MySQL и загрузить его в ClickHouse, или наоборот. Формат `TabSeparated` поддерживает вывод тотальных значений (при использовании WITH TOTALS) и экстремальных значений (при настройке extremes выставленной в 1). В этих случаях, после основных данных выводятся тотальные значения, и экстремальные значения. Основной результат, тотальные значения и экстремальные значения, отделяются друг от друга пустой строкой. Пример: ``` sql SELECT EventDate, count() AS c FROM test.hits GROUP BY EventDate WITH TOTALS ORDER BY EventDate FORMAT TabSeparated`` ``` ``` 2014-03-17 1406958 2014-03-18 1383658 2014-03-19 1405797 2014-03-20 1353623 2014-03-21 1245779 2014-03-22 1031592 2014-03-23 1046491 0000-00-00 8873898 2014-03-17 1031592 2014-03-23 1406958 ``` ### Форматирование данных Целые числа пишутся в десятичной форме. Числа могут содержать лишний символ "+" в начале (игнорируется при парсинге, а при форматировании не пишется). Неотрицательные числа не могут содержать знак отрицания. При чтении допустим парсинг пустой строки, как числа ноль, или (для знаковых типов) строки, состоящей из одного минуса, как числа ноль. Числа, не помещающиеся в соответствующий тип данных, могут парсится, как некоторое другое число, без сообщения об ошибке. Числа с плавающей запятой пишутся в десятичной форме. При этом, десятичный разделитель - точка. Поддерживается экспоненциальная запись, а также inf, +inf, -inf, nan. Запись числа с плавающей запятой может начинаться или заканчиваться на десятичную точку. При форматировании возможна потеря точности чисел с плавающей запятой. При парсинге, допустимо чтение не обязательно наиболее близкого к десятичной записи машинно-представимого числа. Даты выводятся в формате YYYY-MM-DD, парсятся в том же формате, но с любыми символами в качестве разделителей. Даты-с-временем выводятся в формате YYYY-MM-DD hh:mm:ss, парсятся в том же формате, но с любыми символами в качестве разделителей. Всё это происходит в системном часовом поясе на момент старта клиента (если клиент занимается форматированием данных) или сервера. Для дат-с-временем не указывается, действует ли daylight saving time. То есть, если в дампе есть времена во время перевода стрелок назад, то дамп не соответствует данным однозначно, и при парсинге будет выбрано какое-либо из двух времён. При парсинге, некорректные даты и даты-с-временем могут парситься с естественным переполнением или как нулевые даты/даты-с-временем без сообщения об ошибке. В качестве исключения, поддерживается также парсинг даты-с-временем в формате unix timestamp, если он состоит ровно из 10 десятичных цифр. Результат не зависит от часового пояса. Различение форматов YYYY-MM-DD hh:mm:ss и NNNNNNNNNN делается автоматически. Строки выводятся с экранированием спецсимволов с помощью обратного слеша. При выводе, используются следующие escape-последовательности: `\b`, `\f`, `\r`, `\n`, `\t`, `\0`, `\'`, `\\`. При парсинге, также поддерживаются последовательности `\a`, `\v`, а также `\xHH` (hex escape-последовательности) и любые последовательности вида `\c`, где `c` - любой символ - такие последовательности преобразуется в `c`. Таким образом, при чтении поддерживаются форматы, где перевод строки может быть записан как `\n` и как `\` и перевод строки. Например, строка `Hello world`, где между словами вместо пробела стоит перевод строки, может быть считана в любом из следующих вариантов: ``` Hello\nworld Hello\ world ``` Второй вариант поддерживается, так как его использует MySQL при записи tab-separated дампа. Минимальный набор символов, которых вам необходимо экранировать при передаче в TabSeparated формате: таб, перевод строки (LF) и обратный слеш. Экранируется лишь небольшой набор символов. Вы можете легко наткнуться на строковое значение, которое испортит ваш терминал при выводе в него. Массивы форматируются в виде списка значений через запятую в квадратных скобках. Элементы массива - числа форматируются как обычно, а даты, даты-с-временем и строки - в одинарных кавычках с такими же правилами экранирования, как указано выше. [NULL](../query_language/syntax.md#null-literal) форматируется в виде `\N`. ## TabSeparatedRaw Отличается от формата `TabSeparated` тем, что строки выводятся без экранирования. Этот формат подходит только для вывода результата выполнения запроса, но не для парсинга (приёма данных для вставки в таблицу). Этот формат также доступен под именем `TSVRaw`. ## TabSeparatedWithNames Отличается от формата `TabSeparated` тем, что в первой строке пишутся имена столбцов. При парсинге, первая строка полностью игнорируется: вы не можете использовать имена столбцов, чтобы указать их порядок расположения, или чтобы проверить их корректность. (Поддержка обработки заголовка при парсинге может быть добавлена в будущем.) Этот формат также доступен под именем `TSVWithNames`. ## TabSeparatedWithNamesAndTypes Отличается от формата `TabSeparated` тем, что в первой строке пишутся имена столбцов, а во второй - типы столбцов. При парсинге, первая и вторая строка полностью игнорируется. Этот формат также доступен под именем `TSVWithNamesAndTypes`. ## TSKV Похож на TabSeparated, но выводит значения в формате name=value. Имена экранируются так же, как строки в формате TabSeparated и, дополнительно, экранируется также символ =. ``` SearchPhrase= count()=8267016 SearchPhrase=интерьер ванной комнаты count()=2166 SearchPhrase=яндекс count()=1655 SearchPhrase=весна 2014 мода count()=1549 SearchPhrase=фриформ фото count()=1480 SearchPhrase=анджелина джоли count()=1245 SearchPhrase=омск count()=1112 SearchPhrase=фото собак разных пород count()=1091 SearchPhrase=дизайн штор count()=1064 SearchPhrase=баку count()=1000 ``` [NULL](../query_language/syntax.md#null-literal) форматируется в виде `\N`. ``` sql SELECT * FROM t_null FORMAT TSKV ``` ``` x=1 y=\N ``` При большом количестве маленьких столбцов, этот формат существенно неэффективен, и обычно нет причин его использовать. Он реализован, так как используется в некоторых отделах Яндекса. Поддерживается как вывод, так и парсинг данных в этом формате. При парсинге, поддерживается расположение значений разных столбцов в произвольном порядке. Допустимо отсутствие некоторых значений - тогда они воспринимаются как равные значениям по умолчанию. При этом, в качестве значений по умолчанию используются нули, пустые строки и не поддерживаются сложные значения по умолчанию, которые могут быть заданы в таблице. При парсинге, в качестве дополнительного поля, может присутствовать `tskv` без знака равенства и без значения. Это поле игнорируется. ## CSV Формат comma separated values ([RFC](https://tools.ietf.org/html/rfc4180)). При форматировании, строки выводятся в двойных кавычках. Двойная кавычка внутри строки выводится как две двойные кавычки подряд. Других правил экранирования нет. Даты и даты-с-временем выводятся в двойных кавычках. Числа выводятся без кавычек. Значения разделяются символом-разделителем, по умолчанию — `,`. Символ-разделитель определяется настройкой [format_csv_delimiter](../operations/settings/settings.md#format_csv_delimiter). Строки разделяются unix переводом строки (LF). Массивы сериализуются в CSV следующим образом: сначала массив сериализуется в строку, как в формате TabSeparated, а затем полученная строка выводится в CSV в двойных кавычках. Кортежи в формате CSV сериализуются, как отдельные столбцы (то есть, теряется их вложенность в кортеж). ``` clickhouse-client --format_csv_delimiter="|" --query="INSERT INTO test.csv FORMAT CSV" < data.csv ``` *По умолчанию — `,`. См. настройку [format_csv_delimiter](/operations/settings/settings/#format_csv_delimiter) для дополнительной информации. При парсинге, все значения могут парситься как в кавычках, так и без кавычек. Поддерживаются как двойные, так и одинарные кавычки. В том числе, строки могут быть расположены без кавычек - тогда они парсятся до символа-разделителя или перевода строки (CR или LF). В нарушение RFC, в случае парсинга строк не в кавычках, начальные и конечные пробелы и табы игнорируются. В качестве перевода строки, поддерживаются как Unix (LF), так и Windows (CR LF) и Mac OS Classic (LF CR) варианты. `NULL` форматируется в виде `\N`. Формат CSV поддерживает вывод totals и extremes аналогично `TabSeparated`. ## CSVWithNames Выводит также заголовок, аналогично `TabSeparatedWithNames`. ## JSON Выводит данные в формате JSON. Кроме таблицы с данными, также выводятся имена и типы столбцов, и некоторая дополнительная информация - общее количество выведенных строк, а также количество строк, которое могло бы быть выведено, если бы не было LIMIT-а. Пример: ``` sql SELECT SearchPhrase, count() AS c FROM test.hits GROUP BY SearchPhrase WITH TOTALS ORDER BY c DESC LIMIT 5 FORMAT JSON ``` ```json { "meta": [ { "name": "SearchPhrase", "type": "String" }, { "name": "c", "type": "UInt64" } ], "data": [ { "SearchPhrase": "", "c": "8267016" }, { "SearchPhrase": "bathroom interior design", "c": "2166" }, { "SearchPhrase": "yandex", "c": "1655" }, { "SearchPhrase": "spring 2014 fashion", "c": "1549" }, { "SearchPhrase": "freeform photos", "c": "1480" } ], "totals": { "SearchPhrase": "", "c": "8873898" }, "extremes": { "min": { "SearchPhrase": "", "c": "1480" }, "max": { "SearchPhrase": "", "c": "8267016" } }, "rows": 5, "rows_before_limit_at_least": 141137 } ``` JSON совместим с JavaScript. Для этого, дополнительно экранируются некоторые символы: символ прямого слеша `/` экранируется в виде `\/`; альтернативные переводы строк `U+2028`, `U+2029`, на которых ломаются некоторые браузеры, экранируются в виде `\uXXXX`-последовательностей. Экранируются ASCII control characters: backspace, form feed, line feed, carriage return, horizontal tab в виде `\b`, `\f`, `\n`, `\r`, `\t` соответственно, а также остальные байты из диапазона 00-1F с помощью `\uXXXX`-последовательностей. Невалидные UTF-8 последовательности заменяются на replacement character � и, таким образом, выводимый текст будет состоять из валидных UTF-8 последовательностей. Числа типа UInt64 и Int64, для совместимости с JavaScript, по умолчанию выводятся в двойных кавычках, чтобы они выводились без кавычек можно установить конфигурационный параметр output_format_json_quote_64bit_integers равным 0. `rows` - общее количество выведенных строчек. `rows_before_limit_at_least` - не менее скольких строчек получилось бы, если бы не было LIMIT-а. Выводится только если запрос содержит LIMIT. В случае, если запрос содержит GROUP BY, rows_before_limit_at_least - точное число строк, которое получилось бы, если бы не было LIMIT-а. `totals` - тотальные значения (при использовании WITH TOTALS). `extremes` - экстремальные значения (при настройке extremes, выставленной в 1). Этот формат подходит только для вывода результата выполнения запроса, но не для парсинга (приёма данных для вставки в таблицу). ClickHouse поддерживает [NULL](../query_language/syntax.md#null-literal), который при выводе JSON будет отображен как `null`. Смотрите также формат JSONEachRow. ## JSONCompact Отличается от JSON только тем, что строчки данных выводятся в массивах, а не в object-ах. Пример: ```json { "meta": [ { "name": "SearchPhrase", "type": "String" }, { "name": "c", "type": "UInt64" } ], "data": [ ["", "8267016"], ["интерьер ванной комнаты", "2166"], ["яндекс", "1655"], ["весна 2014 мода", "1549"], ["фриформ фото", "1480"] ], "totals": ["","8873898"], "extremes": { "min": ["","1480"], "max": ["","8267016"] }, "rows": 5, "rows_before_limit_at_least": 141137 } ``` Этот формат подходит только для вывода результата выполнения запроса, но не для парсинга (приёма данных для вставки в таблицу). Смотрите также формат `JSONEachRow`. ## JSONEachRow Выводит данные в виде отдельных JSON объектов для каждой строки (newline delimited JSON). ```json {"SearchPhrase":"","count()":"8267016"} {"SearchPhrase":"интерьер ванной комнаты","count()":"2166"} {"SearchPhrase":"яндекс","count()":"1655"} {"SearchPhrase":"весна 2014 мода","count()":"1549"} {"SearchPhrase":"фриформ фото","count()":"1480"} {"SearchPhrase":"анджелина джоли","count()":"1245"} {"SearchPhrase":"омск","count()":"1112"} {"SearchPhrase":"фото собак разных пород","count()":"1091"} {"SearchPhrase":"дизайн штор","count()":"1064"} {"SearchPhrase":"баку","count()":"1000"} ``` В отличие от формата JSON, нет замены невалидных UTF-8 последовательностей. В строках может выводиться произвольный набор байт. Это сделано для того, чтобы данные форматировались без потери информации. Экранирование значений осуществляется аналогично формату JSON. При парсинге, поддерживается расположение значений разных столбцов в произвольном порядке. Допустимо отсутствие некоторых значений - тогда они воспринимаются как равные значениям по умолчанию. При этом, в качестве значений по умолчанию используются нули, пустые строки и не поддерживаются сложные значения по умолчанию, которые могут быть заданы в таблице. Пропускаются пробельные символы между элементами. После объектов может быть расположена запятая, которая игнорируется. Объекты не обязательно должны быть разделены переводами строк. ## Native Самый эффективный формат. Данные пишутся и читаются блоками в бинарном виде. Для каждого блока пишется количество строк, количество столбцов, имена и типы столбцов, а затем кусочки столбцов этого блока, один за другим. То есть, этот формат является "столбцовым" - не преобразует столбцы в строки. Именно этот формат используется в родном интерфейсе - при межсерверном взаимодействии, при использовании клиента командной строки, при работе клиентов, написанных на C++. Вы можете использовать этот формат для быстрой генерации дампов, которые могут быть прочитаны только СУБД ClickHouse. Вряд ли имеет смысл работать с этим форматом самостоятельно. ## Null Ничего не выводит. При этом, запрос обрабатывается, а при использовании клиента командной строки, данные ещё и передаются на клиент. Используется для тестов, в том числе, тестов производительности. Очевидно, формат подходит только для вывода, но не для парсинга. ## Pretty Выводит данные в виде Unicode-art табличек, также используя ANSI-escape последовательности для установки цветов в терминале. Рисуется полная сетка таблицы и, таким образом, каждая строчка занимает две строки в терминале. Каждый блок результата выводится в виде отдельной таблицы. Это нужно, чтобы можно было выводить блоки без буферизации результата (буферизация потребовалась бы, чтобы заранее вычислить видимую ширину всех значений.) [NULL](../query_language/syntax.md#null-literal) выводится как `ᴺᵁᴸᴸ`. ``` sql SELECT * FROM t_null ``` ``` ┌─x─┬────y─┐ │ 1 │ ᴺᵁᴸᴸ │ └───┴──────┘ ``` Для защиты от вываливания слишком большого количества данных в терминал, выводится только первые 10 000 строк. Если строк больше или равно 10 000, то будет написано "Showed first 10 000." Этот формат подходит только для вывода результата выполнения запроса, но не для парсинга (приёма данных для вставки в таблицу). Формат Pretty поддерживает вывод тотальных значений (при использовании WITH TOTALS) и экстремальных значений (при настройке extremes выставленной в 1). В этих случаях, после основных данных выводятся тотальные значения, и экстремальные значения, в отдельных табличках. Пример (показан для формата PrettyCompact): ``` sql SELECT EventDate, count() AS c FROM test.hits GROUP BY EventDate WITH TOTALS ORDER BY EventDate FORMAT PrettyCompact ``` ``` ┌──EventDate─┬───────c─┐ │ 2014-03-17 │ 1406958 │ │ 2014-03-18 │ 1383658 │ │ 2014-03-19 │ 1405797 │ │ 2014-03-20 │ 1353623 │ │ 2014-03-21 │ 1245779 │ │ 2014-03-22 │ 1031592 │ │ 2014-03-23 │ 1046491 │ └────────────┴─────────┘ Totals: ┌──EventDate─┬───────c─┐ │ 0000-00-00 │ 8873898 │ └────────────┴─────────┘ Extremes: ┌──EventDate─┬───────c─┐ │ 2014-03-17 │ 1031592 │ │ 2014-03-23 │ 1406958 │ └────────────┴─────────┘ ``` ## PrettyCompact Отличается от `Pretty` тем, что не рисуется сетка между строками - результат более компактный. Этот формат используется по умолчанию в клиенте командной строки в интерактивном режиме. ## PrettyCompactMonoBlock Отличается от [PrettyCompact](#prettycompact) тем, что строки (до 10 000 штук) буферизуются и затем выводятся в виде одной таблицы, а не по блокам. ## PrettyNoEscapes Отличается от Pretty тем, что не используются ANSI-escape последовательности. Это нужно для отображения этого формата в браузере, а также при использовании утилиты командной строки watch. Пример: ```bash watch -n1 "clickhouse-client --query='SELECT event, value FROM system.events FORMAT PrettyCompactNoEscapes'" ``` Для отображения в браузере, вы можете использовать HTTP интерфейс. ### PrettyCompactNoEscapes Аналогично. ### PrettySpaceNoEscapes Аналогично. ## PrettySpace Отличается от [PrettyCompact](#prettycompact) тем, что вместо сетки используется пустое пространство (пробелы). ## RowBinary Форматирует и парсит данные по строкам, в бинарном виде. Строки и значения уложены подряд, без разделителей. Формат менее эффективен, чем формат Native, так как является строковым. Числа представлены в little endian формате фиксированной длины. Для примера, UInt64 занимает 8 байт. DateTime представлены как UInt32, содержащий unix timestamp в качестве значения. Date представлены как UInt16, содержащий количество дней, прошедших с 1970-01-01 в качестве значения. String представлены как длина в формате varint (unsigned [LEB128](https://en.wikipedia.org/wiki/LEB128)), а затем байты строки. FixedString представлены просто как последовательность байт. Array представлены как длина в формате varint (unsigned [LEB128](https://en.wikipedia.org/wiki/LEB128)), а затем элементы массива, подряд. Для поддержки [NULL](../query_language/syntax.md#null-literal) перед каждым значением типа [Nullable](../data_types/nullable.md#data_type-nullable) в строке добавлен дополнительный байт, который содержит 1 или 0. Если 1, то значение — `NULL` и этот байт трактуется как отдельное значение. Если 0, то после байта идёт не `NULL`-значение. ## Values Выводит каждую строку в скобках. Строки разделены запятыми. После последней строки запятой нет. Значения внутри скобок также разделены запятыми. Числа выводятся в десятичном виде без кавычек. Массивы выводятся в квадратных скобках. Строки, даты, даты-с-временем выводятся в кавычках. Правила экранирования и особенности парсинга аналогичны формату [TabSeparated](#tabseparated). При форматировании, лишние пробелы не ставятся, а при парсинге - допустимы и пропускаются (за исключением пробелов внутри значений типа массив, которые недопустимы). [NULL](../query_language/syntax.md#null-literal) представляется как `NULL`. Минимальный набор символов, которых вам необходимо экранировать при передаче в Values формате: одинарная кавычка и обратный слеш. Именно этот формат используется в запросе `INSERT INTO t VALUES ...`, но вы также можете использовать его для форматирования результатов запросов. ## Vertical Выводит каждое значение на отдельной строке, с указанием имени столбца. Формат удобно использовать для вывода одной-нескольких строк, если каждая строка состоит из большого количества столбцов. [NULL](../query_language/syntax.md#null-literal) выводится как `ᴺᵁᴸᴸ`. Пример: ``` sql SELECT * FROM t_null FORMAT Vertical ``` ``` Row 1: ────── x: 1 y: ᴺᵁᴸᴸ ``` Этот формат подходит только для вывода результата выполнения запроса, но не для парсинга (приёма данных для вставки в таблицу). ## VerticalRaw Отличается от формата `Vertical` тем, что строки выводятся без экранирования. Этот формат подходит только для вывода результата выполнения запроса, но не для парсинга (приёма данных для вставки в таблицу). Примеры: ``` :) SHOW CREATE TABLE geonames FORMAT VerticalRaw; Row 1: ────── statement: CREATE TABLE default.geonames ( geonameid UInt32, date Date DEFAULT CAST('2017-12-08' AS Date)) ENGINE = MergeTree(date, geonameid, 8192) :) SELECT 'string with \'quotes\' and \t with some special \n characters' AS test FORMAT VerticalRaw; Row 1: ────── test: string with 'quotes' and with some special characters ``` Для сравнения - формат Vertical: ``` :) SELECT 'string with \'quotes\' and \t with some special \n characters' AS test FORMAT Vertical; Row 1: ────── test: string with \'quotes\' and \t with some special \n characters ``` ## XML Формат XML подходит только для вывода данных, не для парсинга. Пример: ```xml SearchPhrase String count() UInt64 8267016 интерьер ванной комнаты 2166 яндекс 1655 весна 2014 мода 1549 фриформ фото 1480 анджелина джоли 1245 омск 1112 фото собак разных пород 1091 дизайн штор 1064 баку 1000 10 141137 ``` Если имя столбца не имеет некоторый допустимый вид, то в качестве имени элемента используется просто field. В остальном, структура XML повторяет структуру в формате JSON. Как и для формата JSON, невалидные UTF-8 последовательности заменяются на replacement character � и, таким образом, выводимый текст будет состоять из валидных UTF-8 последовательностей. В строковых значениях, экранируются символы `<` и `&` как `<` и `&`. Массивы выводятся как `HelloWorld...`, а кортежи как `HelloWorld...`. ## CapnProto Cap'n Proto - формат бинарных сообщений, похож на Protocol Buffers и Thrift, но не похож на JSON или MessagePack. Сообщения Cap'n Proto строго типизированы и не самоописывающиеся, т.е. нуждаются во внешнем описании схемы. Схема применяется "на лету" и кешируется для каждого запроса. ``` sql SELECT SearchPhrase, count() AS c FROM test.hits GROUP BY SearchPhrase FORMAT CapnProto SETTINGS schema = 'schema:Message' ``` Где `schema.capnp` выглядит следующим образом: ``` struct Message { SearchPhrase @0 :Text; c @1 :Uint64; } ``` Файлы со схемами находятся в файле, который находится в каталоге указанном в параметре [format_schema_path](../operations/server_settings/settings.md#server_settings-format_schema_path) конфигурации сервера. Десериализация эффективна и обычно не повышает нагрузку на систему. [Оригинальная статья](https://clickhouse.yandex/docs/ru/interfaces/formats/)