суббота, 11 февраля 2012 г.

Мечта о системе управления показателями

решил зафиксить мысль, тк в конторе мысль не нужна.

Цель снизить затраты на механическую обработку данных в аналитике.

Задача: уметь хранить, извлекать и обрабатывать данные собираемые из статистических рядов. Источники стат рядов: данные предоставляемые статистическими ведомствами, результаты опросов и прочее.

Потребители: аналитики и работники служб отчетности в организации.

Почему нужен новый продух и нет радости от существующего, например от SQL баз? Проблема в том, что SQL не проходит по двум причинам: 1) данные между рядами из разных источников могут быть противоречивы, в РМД можно противоречивы данные хранить, но хочется упростить затраты на создание схемы данных учитывающей неконсистентность данных с точки зрения полноты и точности; 2) заранее не известно какие данные может потребоваться хранить в системе и выделять из данных ключи и поддерживать ссылочную целостность.

Важно, что речь не идет о необходимости хранении данных из слабо пересекающихся предметных областей, а хранении данных из одной предметной области (только очень большой, например системы образования).

Требования для системы управления показателями:

1. нужно уметь формировать систему показателей: для каждого показателя указать что это, как собирается, кто источник данных, когда порождены, единицы измерений, как связаны с другими показателями (связь по ссылочной целостности, вычисляются, проверяются и пр). то есть система показателей образует онтологию   (в смысле машиночитаемое описание представлений о мире, проще не парится и брать в качестве основы промышленный стандарт ISO 15926). С онтологией системы показателей нужно уметь работать: изменять, трансформировать и версионировать (тут засада, проблема не обсуждалась на уровне теории, типа мне про это не известно :( ). Задача решаемая, топовые онтологии есть (ISO 15926, Gellish), ПО для работы есть (triple store), будет проблема с версионированием, но можно найти решения для работы.

Работа архитектора над такой системе будет сводится к продумыванию изменений онтологии при появлении новых параметров.

2. значения показателей чаще всего образуют временные ряды: те что наблюдались в реальности (взяты из КИС), вбиты из текстовых справок, взяты с потолка и отданы наружу. Значения должны версионироваться и для них должны хранится срезы в какой документ конкретное значение с конкретным источником было выдано.

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

Результат отдали наружу, и зачем где и как соврали, можем даже написать почему соврали.

3. Для сбора данных из КИС пишем конекторы, которые сосут данные, для людей модуль опросы. Важно значения живут в моделе Bunge-Wand-Weber (то есть тройками значение-отношение-значение), но хранятся в РБД, схема которой изменяется с изменением данных без потерь значений и информации автоматом по онтологии. Очень напоминает то что делается в платформе (речь идет о внутреннем фреймворке используемом на фирме), только на более высоком уровне. Плюс работа с данными строится в терминах привычного языка выборок который работает напрямую с РБД, проблему с модификациями запросов нужно думать. Технологии тоже уже есть, некоторые в экспериментальном виде.

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

То что написано выше напоминает то как работают финансовые и прочие аналитики, но у них нет явной задачи работать с противоречивыми значениями и темпоральной логикой над ними я пытался найти в мире статистики похожую систему, но не нашел возможно системы пока в зачаточном состоянии.
Ближайшее что нашел это  http://wikiposit.org/w , но немного не то нет возможности связать данные из разных наборов, например вытащить все что есть по перечню вузов.

То что описано выше это страшная смесь системы управления записями поверх кусков реляционной модели склеенной онтологией и все вместе живет в машине вывода :(.

много буков, и счастья нет :)

2 комментария:

Leeho комментирует...

Марк, а ты уверен, что решение будет иметь практический смысл? Не исключено, что задачу в такой постановке не пытались решать именно потому, что она должна сводиться к более простой. Я сильно сомневаюсь, например, что будет достаточное число потребителей решения - аналитиков, которые смогут управляться с нечеткими, да еще и изменяющимися во времени значениями.

Не говоря уже об этике построения системы.

Ведь у тебя вся задача получается из посылки "одно и то же число может иметь разные значения", которая следует из идеи подделки отчетных данных. Причем сложность подделки и ее необходимость прямо продиктованы идиотскими нумерологическими играми Минобра. Смысла в играх нет, так есть ли смысл писать систему, которая решает задачу, производную от бессмысленной?

Mark Akoev комментирует...

Ок, спасибо за первый вменяемый комент :)

по пунктам:

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

2. По поводу этичности системы, вопрос скорее должен ставится в плоскости применения системы. "Игра в цифирь" практикуемая госорганизациями никуда не исчезает, если будет удобный инструмент то его будут использовать.

Но я думал об инструменте который позволит сделать две вещи:

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

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

2.2 управляет версиями ответов не на уровне документоцентрики, а на уровне датацентрики :) см http://ailev.livejournal.com/934700.html