review check procedure

[epogrebnyak]

https://github.com/mini-kep/parser-rosstat-kep/blob/dev/src/kep/parsing_definition/checkpoints.py and https://github.com/mini-kep/parser-rosstat-kep/blob/dev/src/kep/vintage.py

ideas for work:

• [x] vintage should not have is_found function, should go to checkpoints
• [ ] we do not have the stats, how many of the resulting indicators are checked
• [ ] maybe more checkpoints are needed per indicator

[epogrebnyak]

https://github.com/mini-kep/parser-rosstat-kep/blob/3ff0686fe12924ea60ea22677f4b5a814b407fbe/src/kep/parsing_definition/checkpoints.py#L3-L32

[epogrebnyak]

для проверки что должны делать? Я так понимаю, что функция validate должна кидать исключение, если обнаружены дополнительные столбцы в данных, которых нет в чекпойнтах, или, наоборот, если какие-то чекпойнты не использованы. Так? Либо же должны быть отдельные функции, которые возвращают список различий, к примеру?

Скорее второе.

1. Нужна функция для проверки "Есть ли в фреймах переменные (столбцы), для которые нет проверочного значения" - это проверка. Это может быть warning или exception.

2. Справочная функция - есть ли среди проверочных значений те, которые не понадобились для проверки? Это информация о том, что проверочные значения, возможно, устаревают, из-за пересмотра состава переменных. Это warning.

3. В целом нужен набор правил, которые мы считаем "валидацией целостности" набора данных. @0nkery, можете предложить?

[epogrebnyak]

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

flags = [is_found(df, c) for c in checkpoints]

[epogrebnyak]

Текущая цель валидации:

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

[epogrebnyak]

Правила контроля целостности набора данных (0.0.1)

Компоненты

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

Валидация (контрольные точки)

Сейчас:

Все контрольные точки есть в фреймах.

Требуется:

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

Проблемы

1. мы не знаем все ли переменные во фреймах охвачены контрольными точками

2. нас удовлетворяют пустые значения в контрольной точке и в фрейме (нужны контрольные токи вне 1999 года для некоторых переменных)

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

Что еще можно проверять

• переменная не должна сильно вылетать за пределы своих значений
• некоторые переменные не могут быть равны 0 (все значения)
• может быть еще что-то?

[0nkery]

• [x] Проверить, есть ли во фреймах переменные, отсутствующие в контрольных точках. Функция бросает исключение со списком переменных, которые нужно покрыть контрольными точками.
• Контрольные точки за другие годы помимо 1999:
• [x] Для пустых значений (INDPRO_yoy, PPI_rog) нужны дополнительные строки с контрольными точками, привязанные к конкретному году и механизм объединения получившихся словарей для валидации датафреймов.
• [x] Нужно так же учитывать, что контрольные точки могут не подходить для некоторых релизов данных. Пример: учет показателя ведется с 2016 года - релизы данных для более ранних годов не имеют этого показателя, что нормально. Решение: игнорировать контрольные точки "из будущего". Проверки, требующие более тщательного проектирования:
• [ ] Проверка, что переменная находится в пределах своих значений (не изменяется слишком сильно).
• [ ] Проверка на наличие нулевых значений (нужно как-то отличать отсутствующие значения от нулевых (неверных)).

[0nkery]

Вариант решения задачи валидации переменных в релизах данных по нескольким контрольным точкам.

Если брать контрольную точку ближе по времени, ее значение может меняться через месяц или квартал ( было / не было данных + уточнили данные ).

Можно задать базовые контрольные точки, общие для всех релизов данных. В каждом отдельном релизе данных, при необходимости, можно указывать "переопределения" отдельных контрольных точек, которые объединяются с базовыми (перезаписывая отдельные контрольные точки). Полученная структура данных уже используется для валидации датафреймов.