review check procedure

[epogrebnyak]

review check procedure

[epogrebnyak]

parser-rosstat-kep/src/kep/parsing_definition/checkpoints.py

Lines 3 to 32 in 3ff0686

	# TODO - coverage of resulting frames by checkpoints
	# https://github.com/mini-kep/parser-rosstat-kep/issues/151
	#
	# Setting (specification - dataframes - checkpoints):
	#
	# - specification has requited labals for parsing, it is guaranteed that parsing results ('dataframes')
	# have this set of labels
	# - Validate(year, month).dfs has three dataframes with parsing results ('dataframes')
	# - we check them with checkpoints.validate() function using CHECKPOINTS datapoints
	# How CHECKPOINTS are constructed?
	# - a checkpoint is basically a frequency-label--date-value dictionary
	# - there are several ways to define uch dictionaries, most explcicit is just a hardcoded constant
	# (in fact that was tried in some branches of repo)
	# - we need a lot of chekpoints and some rather visual way of editing them
	# - given this the checkpoints.CHECKPOINTS are constructued manually just using a printout (repr) of dataframes
	# while this may not be the best way to construct a checkpoint, it is rather verbose.
	# - the problem I see is that the variables that do not have a 1999 value, which start observationlater (eg INDPRO, PPI, some others)
	# - another problem is that we just copy an occasional parsing result to CHEKCPOINTS, not really looking at CSV file
	# is it is really the value in original data source
	# Risks:
	# - dataframes may have parsing results not covered by checkpoints
	# - not all indicators start in 1999, they need other checkpoints
	# - checkpoints not strictly related to interim CSV values
	# - we employ just one control datapoint per time series to ensure data interity, may not be enough to stay sure
	# Immediate tasks:
	# - are all columns in dataframes covered by CHECKPOINTS? (uncovered time series / columns names) - moe important
	# - what are values in CHECKPOINTS that are not in dataframes? (unused checkpoints) - less important

[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]

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

[0nkery]

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

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

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