9. Проверка форматно-логического контроля

Проверка форматно-логического контроля включает в себя:

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

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

Таблица 9.1 Список реализованных проверок

Наименование проверки	Код ошибки	Кириллическое описание
Проверка уникальности	dublicate	Дубликат файла/группы
Проверка парсинга файла	parsingErr	Ошибка парсинга: текст ошибки
Проверка кодирования	encodingErr	Кодировка файла не соответствует кодировке UTF-8
Проверка превышения предельного размера файла (больше 512 Мб)	tooLargeFile	Слишком большой файл
Проверка наличия данных в файле	emptyFile	Пустой файл
Проверка соответствия заголовков инфосхеме	wrongMetadata	Структура файла не соответствует схеме
Проверка соответствия числа столбцов в строке	wrongFieldsCount	Некорректное число столбцов в строке
Проверка соответствия типам полей	wrongFieldType	Значение не соответствует типу требуемый тип
Проверка уникальности полей	nonUniq	Значение не отвечает требованиям уникальности
Проверка регулярных выражений	nonMatchRegex	Значение не соответствует регулярному выражению регулярное выражение
Проверка соответствия условию	nonMatchConstant	Значение не соответствует условию условие
Таймаут валидации	validationTimeout	Истек таймаут валидации файла

9.1. Синхронная проверка ФЛК

Примечание

• синхронные проверки выполняются вне зависимости от настроек модуля REST-Uploader;

• синхронные проверки являются блокирующими;

• ошибки синхронных проверок возвращаются в теле ответа по REST-API.

К синхронным проверкам относятся:

• проверка соответствия инфосхеме:

  • проверка соответствия имен и количества полей в заголовках;

  • проверка типа данных;

  • проверка экранирования данных: проверка соответствия числа столбцов по каждой строке;

• проверка соответствия файла кодировке UTF-8 , отсутствие BOM (при наличии BOM при загрузке удаляются начальные байты ef bb bf);

• проверка размера файла и наличия данных:

  • проверка предельного размера загружаемого файла 512Мб;

  • проверка наличия данных в файле.

9.2. Асинхронная проверка

Примечание

• асинхронные проверки выполняются в зависимости от настроек модуля;

• проверки не являются блокирующими (поведение при их наличии определяется конфигурацией модуля);

• список проверок уникален для каждой таблицы и хранится в Zookeeper в виде отдельного YAML файла.

К асинхронным проверкам относятся:

• проверка уникальности полей:

  • по сочетанию атрибутов (для комплексных ключей);

  • по заданному атрибуту;

• сравнение значения с константой;

• соответствие регулярному выражению.

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

9.2.1. Проверка уникальности по одному или по сочетанию полей

Проверка уникальности проводится:

• в рамках группы файлов, если заданы headers - для проверки в рамках группы обязательно заполнения всех полей:

  • group_id;

  • group_file_num;

  • group_file_count.

Пример запроса для проверки уникальности по группе файлов:

--проверка по сочетанию полей
fields:
  id:
    uniq: true
    uniq-with: [type,region]
--проверка уникальности по одному полю
  snils:
    match: "/^[-\s\d]{11}$/"
    uniq: true

9.2.2. Проверка соответствия заданному значению

• проверка соответствия заданному значению проводится для каждого файла вне зависимости от наличия group_id;

• проверка осуществляется для значений каждого поля в соответствии с заданным правилом;

• проверка соответствия заданному значению включает в себя:

• • проверку сравнения с константой (>, <, >=, <=, =, !=);

  • проверку соответствия регулярному выражению (должна выполняться на основе Java Util Regexp https://docs.oracle.com/javase/7/docs/api/java/util/regex/package-summary.html )

9.2.3. Поведение в случае таймаута валидации

Период выполнения асинхронных проверок определяется конфигурационным параметром validation-timeout и по умолчанию составляет 60 минут.

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

В случае возникновения подобной ошибки рекомендуется:

• проверить регулярные выражения, по которым происходит проверка, так как неверно заданное регулярное выражение кратно увеличивает скорость проверки;

• увеличить значение validation-timeout и повторить загрузку данных.

10. Статусная модель

Статус запроса к модулю REST-Uploder можно получить, выполнив запрос с передачей идентификатора запроса GET '/v2/requests/:requestId/status'.

В ответ возвращается три поля:

• code - код статуса;

• errorMessage - сообщение об ошибке, заполняется лишь в случае ошибочного статуса;

• description - описание ошибки, заполняется лишь в случае ошибочного статуса.

Пример ответа на запрос статуса:

{"code":2,"description":null,"errorMessage":null}

{"code":3,"description":"Успешно обработан","errorMessage":null}

{"code":4,"description":"Ошибка обработки запроса","errorMessage":"ru.itone.dtm.data.uploader.upload.UploadException: ru.itone.dtm.prostore.rest.api.ProstoreRestException: Error executing query [insert into univer.slots select resource_id,slot_id,tag_type,tag_age,available_date,duration,slot_create_ts,slot_update_ts,slot_status,sys_op from univer.slots_upload_ext]: All of the connectors are failed\n\tat"}

{"code":5,"description":"Идентификатор запроса не обнаружен","errorMessage":null}

{"code":7,"description":"Ошибки ФЛК","errorMessage":null}

Идентификатор запроса можно получить в ответ от REST-Uploader:

• POST'/v2/datamarts/{datamart_name}/tables/{table_name}/upload;

• POST'/v2/datamarts/{datamart_name}/tables/{table_name}/delete.

Таблица 10.1 Статусная модель

Код статуса	Описание статуса	Действия при получении данного статуса
-1	Загрузка данных в буфер	Данный статус клиентскому приложению не возвращается, ответ вернется после того как загружаемые данные будут сохранены приложением REST-Uploader для дальнейшей загрузки
0	Запрос буферизирован	Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30 сек.
1	Ожидает открытия дельты	Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30 сек.
2	В обработке (модулем DATA-Uploader)	Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30 сек.
3	Успешно обработан	Дополнительных действий не требуется
4	Ошибка обработки запроса	Необходимо: изучить содержимое вернувшегося поля description если суть проблемы не ясна из предыдущего пункта, изучить содержимое логов приложений на предмет наличия ошибок: REST-Uploader; DATA-Uploader; используемого коннектора (kafka-postgres-writer или kafka-jet-writer [1]_ )
5	Идентификатор запроса не обнаружен	Использовать действующий идентификатор запроса
6	Форматно-логический контроль	Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30 сек.
7	Ошибки ФЛК	В процессе ФЛК выявлены ошибки, необходимо запросить отчет ФЛК, обратившись к REST-Uploader c запросом GET '/v2/requests/{request_id}/report/' Далее проанализировать и устранить выявленные недочеты в загружаемых данных или скорректировать проверки ФЛК

[1] Указанные коннекторы используются для обратной совместимости по ETL: для перехода Компонета с версии 1.х на версию 2.х без изменений ETL. По умолчанию настроено без использования Kafka и коннекторов к нему.