Типовые ошибки при загрузке данных

Ошибки, которые могут возникать при загрузке данных в Витрину, чаще всего устраняются достаточно легко. Наиболее распространёнными из них являются следующие:

• Ошибки, связанные с кодировкой
• Использование Postgres вместо Prostore
• Некорректный тип данных
• Нарушен порядок полей
• Ошибки при работе с дельтами
• Нестандартные решения при работе с REST-uploader.

Рассмотрим подробнее эти случаи и способы устранения ошибок.

Кодировка

Распространенная ошибка при загрузке CSV-файлов – некорректная кодировка.

  Примечание

 Данные в файле CSV, предназначенные для загрузки в Витрину, должны быть в кодировке UTF-8.

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

Пример:

Рисунок 1 – CSV-uploader. Ошибка обработки входящего запроса

Проверить кодировку в файле можно с помощью приложения Notepad++. Для этого откройте CSV-файл в приложении, перейдите на вкладку Кодировки и просмотрите список кодировок. В списке отобразится действующая кодировка. В примере на Рисунке 2 – Кодировка ANSI.

Рисунок 2 – Notepad++. Выбор кодировки

Для изменения кодировки в файле на корректную на этой же вкладке нажмите Преобразовать в UTF-8, в результате кодировка в файле будет изменена на нужную (см. Рисунок 3).

Рисунок 3 – Notepad++. Выбор кодировки 

​Postgres вместо Prostore

При первом знакомстве с Витриной данных и первых попытках загрузки данных пользователи часто по ошибке подключаются не к Prostore (Ядру Витрины данных), а к БД Postgres. Вследствие этого загруженные данные не появляются в Prostore и недоступны для дальнейшей работы через Ядро.

Во избежание таких ошибок необходимо:

  1.   Учитывать номера портов, используемых по умолчанию:

• для подключения к Prostore: 9090
• для подключения к Postgres: 5432

  2.   Четко понимать, что все операции записи, корректировки и удаления следует проводить исключительно через Prostore, так как при вставке данных через Prostore система автоматически добавляет служебные поля sys_op, sys_from и sys_to и их значения.

  Примечание

 Описание данных служебных полей можно найти на официальном сайте Prostore.

Некорректный тип данных

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

          1)     Формат даты и времени

• несоответствие типов даты и времени в загружаемом файле и БД. Например, ожидается только дата, а в данные файле имеют формат «таймстамп» (дата и время);
• попытка загрузить дату и время с признаком часового пояса ('2024-12-01 10:20:00+02'): Prostore не поддерживает таймзоны.

          2)     Varchar вместо Integer

• загрузка текстового значения (varchar) в поле с числовым типом данных (integer, bigint, double и т.д.).

Порядок полей

При загрузке данных следует обращать внимание на порядок полей в файле.

Чтобы понять, в какой последовательности должны идти данные, можно действовать одним из следующих способов:

• Посмотреть в DDL-запросе, которым создавалась целевая таблица.
• Использовать запрос:

GET_ENTITY_DDL([db_name.]entity_name)

где:

• db_name – имя логической базы данных, которой принадлежит запрашиваемая сущность. Опционально, если выбрана логическая БД, используемая по умолчанию.
• entity_name – имя таблицы или представления, по которому запрашивается информация.

Успешный ответ содержит объект ResultSet с одной строкой, в которой представлен DDL-запрос на создание сущности с соответствующим порядком полей. 

Работа с дельтами

Дельта — целостная совокупность изменений в логической базе данных, позволяющая сгруппировать операции записи в целостный набор изменений. Изменять данные логической БД также можно без группировки по дельтам. Рассмотрим самые частые ошибки при работе с дельтами в системе Prostore.

  1.   Ошибка при ручном открытии дельты: выполнение команды открытия дельты, когда она уже открыта. В результате возникает  соответствующая ошибка:

Рисунок 4 – Ошибка выполнения команды открытия дельты, если дельта уже открыта

В логе Prostore можно увидеть более развернутое сообщение об ошибке. Например:

Caused by: ru.datamart.prostore.jdbc.exception.DtmSqlException: The delta 11 is not committed.

Для устранения ошибки в данном случае следует:

• если требуется открыть новую дельту – сначала закрыть открытую дельту, выполнив команду commit delta;
• если новую дельту открывать не требуется – продолжить работу с уже открытой дельтой.

  2.   Ошибка и при ручном закрытии дельты: выполнение команды закрытия дельты, когда она уже закрыта. Пример ошибки:

Рисунок 5 – Ошибка выполнения команды закрытия дельты, если дельта уже закрыта

Пример сообщения об ошибке в логе:

Caused by: ru.datamart.prostore.jdbc.exception.DtmSqlException: Delta is already committed.

В данном случае для устранения ошибки ничего делать не требуется – дельта закрыта, и система находится в штатном режиме работы.

  3.   Очень редкое закрытие дельт: физическое ограничение на количество операций записи в рамках одной открытой дельты равно 24000. Крайне важно не доводить количество операций записи в одной дельте до этого предела. Речь идет именно о количестве операций, а не о строках в рамках одной операции. В соответствии с вышесказанным, при проектировании логики наполнения Витрины данными рекомендуется обратить внимание на функционал открытия-закрытия дельт.

В качестве вспомогательных команд в Prostore можно использовать:

• begin delta
• commit delta
• get_delta_ok()
• get_delta_hot()

Подробнее об этих командах Prostore можно прочитать в официальной документации, поставляемой вместе с Типовым ПО «Витрина данных».

Нестандартные решения при работе с REST-uploader

Модуль асинхронной загрузки данных из сторонних источников REST-uploader предназначен для параллельной загрузки данных в виде CSV-файлов в кодировке UTF-8 с независимым масштабированием REST-интерфейса. Наиболее частыми ошибками, которые приводят к существенному замедлению загрузки данных через REST-uploader или даже к сбоям, являются следующие ситуации:

          1)     Неверное использование функциональности массовой загрузки файлов
Создание на стороне ИС большого количества CSV-файлов, содержащих по одной строке, увеличивает общее время загрузки. Это связано с тем, что и в логике, и в самой работе модуля естественно присутствуют критически необходимые микротаймауты, например, для поднятия коннектов со смежными модулями или на предобработку самого CSV-файла.

Потому настоятельно рекомендуется на стороне ИС формировать более емкие файлы, накапливать их и отправлять в REST-uploader. Количество записей или время накопления файлов зависит строго от временных допусков бизнес-процессов.

Базовые рекомендации по формированию CSV-файлов:

• максимальный размер одного файла: 512Мб;
• количество записей в одном файле: 100000 строк;
• избегать дублирования записей в рамках одного файла по первичному ключу.

  Важно!

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

Удалять данные, которые предстоит заменить новыми, не требуется и может быть нецелесообразным. Более важным является создание корректных первичных ключей, чтобы вставка новых данных в таблицу обновляла только то, что нужно.