Выгрузка и импорт данных: форматы и типичные ошибки

При переносе данных между сервисами файл может открыться без ошибок — и всё равно испортить значения: артикул 00127 превратится в 127, дата сменит порядок дня и месяца, а пустое поле станет нулём. Для обмена таблицами обычно выбирают CSV, для построчной передачи объектов — JSONL, для аналитических наборов — Parquet. Ниже — практические критерии выбора и проверки, которые помогают не обнаружить потерю данных после загрузки в рабочую систему.

Сначала зафиксируйте, что именно переносите

Формат отвечает на вопрос, как записать данные в файл, но не определяет, что считать пустым значением, датой или уникальной записью. Эти правила нужно согласовать отдельно. До экспорта запишите схему: названия и типы столбцов, обязательные поля, допустимые значения и правила для пустых данных.

Материал относится к форматному уровню, а не к конкретной библиотеке или команде загрузки. Для CSV ориентир — RFC 4180, для JSON — RFC 8259; у Parquet проверьте, какие версии формата поддерживают оба ваших инструмента. Имена настроек и команды импорта различаются между СУБД, облачными хранилищами и программами, поэтому не переносите параметры из одной системы в другую без проверки документации.

• Объём и назначение. Файл для человека и обмена небольшими таблицами — не то же самое, что набор для аналитического конвейера.
• Типы данных. Уточните, где число, дата, логическое значение, а где текст с цифрами — например, телефон или код товара.
• Правила пустых значений. Различайте пустую строку, отсутствующее поле и явное значение null.
• Проверка результата. Заранее решите, как сравнить исходник и импорт: число строк, контрольные суммы, уникальные ключи, суммы по важным полям.

CSV, JSONL или Parquet

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

CSV — это не «таблица, в которой запятые всегда разделяют столбцы». Внутри значения могут встречаться разделитель, кавычки и переносы строк; корректная обработка зависит от правил экранирования. В русскоязычных выгрузках разделителем нередко оказывается точка с запятой, поэтому импорт по умолчанию может сдвинуть все поля. Кодировка тоже важна: неверно прочитанный UTF-8 даст нечитаемые символы, а BOM в начале файла некоторые инструменты показывают как часть первого заголовка.

JSONL удобен тем, что получатель может обрабатывать строки последовательно, не загружая весь набор целиком. Но один объект на строку — соглашение JSON Lines, а не отдельная часть синтаксиса RFC 8259: обычный JSON-документ может содержать массив объектов, который нельзя автоматически читать как JSONL. Parquet хранит данные в колоночном формате и рассчитан на инструменты, которые его поддерживают. Для универсального ручного обмена он обычно менее удобен, чем CSV.

Надёжный импорт начинается не с кнопки «Загрузить», а с договорённости: какое значение означает пустоту, как читается дата и по какому ключу запись считается той же самой.

Ошибки, которые меняют смысл данных

Числа, похожие на текст

Артикул, почтовый индекс и телефон могут состоять из цифр, но это не делает их числами. Если импортёр решит, что поле числовое, он уберёт ведущие нули, а иногда и изменит длинные значения. Укажите текстовый тип для идентификаторов и после загрузки сравните их не только по количеству, но и по исходным строкам.

Даты и часовые пояса

Значение 03/04/2025 неоднозначно без договорённости о порядке дня и месяца. Для обмена используйте единый формат даты, например ISO 8601, и отдельно задайте, в каком часовом поясе записано время. Проверьте записи около полуночи: преобразование часового пояса способно перенести событие на соседний календарный день.

Пустая строка — не всегда null

В одном источнике пустое поле может означать, что значения нет, в другом — что пользователь намеренно оставил пустую строку. Если получатель превращает оба случая в null, исходное различие пропадёт. До переноса определите, сохраняете ли вы это различие и как оно кодируется в выбранном формате.

Дубли при повторном запуске

Если импорт прервался, повторная загрузка может добавить те же записи ещё раз. Это особенно опасно для платежей, заказов и событий, где дубликат меняет итоговые суммы. Продумайте ключ записи и режим повторного запуска: обновлять существующие строки, пропускать совпавшие или загружать сначала во временную область для последующей сверки.

Практический порядок переноса

1. Зафиксируйте схему и правила. Согласуйте тип каждого поля, формат дат, кодировку, разделитель и трактовку пустых значений. Проверка: отправитель и получатель могут одинаково описать каждый столбец.
2. Сделайте небольшую тестовую выгрузку. Возьмите записи с кириллицей, кавычками, переносами строк, нулями в начале, пустыми полями и датами. Проверка: после пробного импорта эти значения сохранили исходный смысл.
3. Загрузите тест в отдельную таблицу или тестовую среду. Не начинайте с перезаписи рабочих данных. Проверка: ошибок чтения нет, а структура и типы совпадают с согласованной схемой.
4. Сверьте содержимое. Сравните количество строк, число уникальных ключей и важные агрегаты — например, сумму по числовому полю. Проверка: расхождения либо отсутствуют, либо объяснены и задокументированы.
5. Только после сверки запускайте рабочую загрузку. Сохраните исходный файл и зафиксируйте, какой набор и каким способом импортировали. Проверка: повторный запуск не создаёт неожиданных дублей.

Если набор большой, добавьте контроль по частям: число строк и агрегаты для каждого файла или диапазона. Иначе совпавшая общая сумма может скрыть пропуск одних записей и дублирование других.

Когда какой формат выбирать

• CSV — когда данные плоские, их нужно открыть в табличном редакторе и обе стороны могут явно согласовать диалект: кодировку, разделитель и правила кавычек.
• JSONL — когда записи передаются потоком или обрабатываются построчно, а вложенные поля важны. Зафиксируйте схему отдельно и проверяйте, что структура объектов не меняется незаметно.
• Parquet — когда данные идут в аналитический процесс, а источники и получатели подтверждают совместимость формата и типов. Для обмена с человеком или неизвестной системой сначала проверьте, сможет ли получатель прочитать файл.

Не выбирайте формат только по размеру выгрузки. Сжатый файл, который получатель не может прочитать, экономит место, но добавляет ручной этап и риск ошибки. Для оперативного переноса важнее совместимость и возможность проверить результат; для регулярной аналитики — согласованная схема и поддержка нужных инструментов.

Диалект CSV — набор правил чтения CSV-файла: в частности, кодировка, символ-разделитель, кавычки и способ экранировать их внутри значения. Два файла с расширением .csv могут использовать разные диалекты.

Что проверить дальше

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