Мечта о системе управления показателями
00:50 11.02.2012
Мечта о системе управления показателями
решил зафиксить мысль, тк в конторе мысль не нужна.
Цель снизить затраты на механическую обработку данных в аналитике.
Задача: уметь хранить, извлекать и обрабатывать данные собираемые из статистических рядов. Источники стат рядов: данные предоставляемые статистическими ведомствами, результаты опросов и прочее.
Потребители: аналитики и работники служб отчетности в организации.
Почему нужен новый продух и нет радости от существующего, например от SQL баз? Проблема в том, что SQL не проходит по двум причинам: 1) данные между рядами из разных источников могут быть противоречивы, в РМД можно противоречивы данные хранить, но хочется упростить затраты на создание схемы данных учитывающей неконсистентность данных с точки зрения полноты и точности; 2) заранее не известно какие данные может потребоваться хранить в системе и выделять из данных ключи и поддерживать ссылочную целостность.
Важно, что речь не идет о необходимости хранении данных из слабо пересекающихся предметных областей, а хранении данных из одной предметной области (только очень большой, например системы образования).
Требования для системы управления показателями:
1. нужно уметь формировать систему показателей: для каждого показателя указать что это, как собирается, кто источник данных, когда порождены, единицы измерений, как связаны с другими показателями (связь по ссылочной целостности, вычисляются, проверяются и пр). то есть система показателей образует онтологию (в смысле машиночитаемое описание представлений о мире, проще не парится и брать в качестве основы промышленный стандарт ISO 15926). С онтологией системы показателей нужно уметь работать: изменять, трансформировать и версионировать (тут засада, проблема не обсуждалась на уровне теории, типа мне про это не известно :( ). Задача решаемая, топовые онтологии есть (ISO 15926, Gellish), ПО для работы есть (triple store), будет проблема с версионированием, но можно найти решения для работы.
Работа архитектора над такой системе будет сводится к продумыванию изменений онтологии при появлении новых параметров.
2. значения показателей чаще всего образуют временные ряды: те что наблюдались в реальности (взяты из КИС), вбиты из текстовых справок, взяты с потолка и отданы наружу. Значения должны версионироваться и для них должны хранится срезы в какой документ конкретное значение с конкретным источником было выдано.
Сценарий работы с показателями: собрались подделать цифры, извлекли набор значений отдаваемых показателей, проверили их консистентность (онтология содержит критерии целостности), посмотрели на выбросы (значения нарушающие представления о прекрасных данных: вне допустимых границ, слишком гладкие и пр, весь аппарат анализа данных), посмотрели на значения которые нужно изменить (выбросы), посмотрели исторический ряд значений, исходя из усилий мысли поправили значение, зафиксили, что исправили значение. Пробежались по всем значениям наступило счастье. Возможно часть правок удастся автоматизировать, но скорее будет инструмент причесывания данных
Результат отдали наружу, и зачем где и как соврали, можем даже написать почему соврали.
3. Для сбора данных из КИС пишем конекторы, которые сосут данные, для людей модуль опросы. Важно значения живут в моделе Bunge-Wand-Weber (то есть тройками значение-отношение-значение), но хранятся в РБД, схема которой изменяется с изменением данных без потерь значений и информации автоматом по онтологии. Очень напоминает то что делается в платформе (речь идет о внутреннем фреймворке используемом на фирме), только на более высоком уровне. Плюс работа с данными строится в терминах привычного языка выборок который работает напрямую с РБД, проблему с модификациями запросов нужно думать. Технологии тоже уже есть, некоторые в экспериментальном виде.
4. Работа с данными скорее будет производится в табличном редакторе, то есть для создания среза для анализа данных отбираем объекты про которые хотим построить набор данных, смотрим каие параметры есть, анализируем полноту покрытия параметров за интересующий период времени и заполняем срез данными из системы. Дальше анализируем средствами табличного процессора или внешней аналитической системы.
То что написано выше напоминает то как работают финансовые и прочие аналитики, но у них нет явной задачи работать с противоречивыми значениями и темпоральной логикой над ними я пытался найти в мире статистики похожую систему, но не нашел возможно системы пока в зачаточном состоянии.
Ближайшее что нашел это http://wikiposit.org/w , но немного не то нет возможности связать данные из разных наборов, например вытащить все что есть по перечню вузов.
То что описано выше это страшная смесь системы управления записями поверх кусков реляционной модели склеенной онтологией и все вместе живет в машине вывода :(.
много буков, и счастья нет :)
read more at mrcs
rss2lj
Мечта о системе управления показателями
решил зафиксить мысль, тк в конторе мысль не нужна.
Цель снизить затраты на механическую обработку данных в аналитике.
Задача: уметь хранить, извлекать и обрабатывать данные собираемые из статистических рядов. Источники стат рядов: данные предоставляемые статистическими ведомствами, результаты опросов и прочее.
Потребители: аналитики и работники служб отчетности в организации.
Почему нужен новый продух и нет радости от существующего, например от SQL баз? Проблема в том, что SQL не проходит по двум причинам: 1) данные между рядами из разных источников могут быть противоречивы, в РМД можно противоречивы данные хранить, но хочется упростить затраты на создание схемы данных учитывающей неконсистентность данных с точки зрения полноты и точности; 2) заранее не известно какие данные может потребоваться хранить в системе и выделять из данных ключи и поддерживать ссылочную целостность.
Важно, что речь не идет о необходимости хранении данных из слабо пересекающихся предметных областей, а хранении данных из одной предметной области (только очень большой, например системы образования).
Требования для системы управления показателями:
1. нужно уметь формировать систему показателей: для каждого показателя указать что это, как собирается, кто источник данных, когда порождены, единицы измерений, как связаны с другими показателями (связь по ссылочной целостности, вычисляются, проверяются и пр). то есть система показателей образует онтологию (в смысле машиночитаемое описание представлений о мире, проще не парится и брать в качестве основы промышленный стандарт ISO 15926). С онтологией системы показателей нужно уметь работать: изменять, трансформировать и версионировать (тут засада, проблема не обсуждалась на уровне теории, типа мне про это не известно :( ). Задача решаемая, топовые онтологии есть (ISO 15926, Gellish), ПО для работы есть (triple store), будет проблема с версионированием, но можно найти решения для работы.
Работа архитектора над такой системе будет сводится к продумыванию изменений онтологии при появлении новых параметров.
2. значения показателей чаще всего образуют временные ряды: те что наблюдались в реальности (взяты из КИС), вбиты из текстовых справок, взяты с потолка и отданы наружу. Значения должны версионироваться и для них должны хранится срезы в какой документ конкретное значение с конкретным источником было выдано.
Сценарий работы с показателями: собрались подделать цифры, извлекли набор значений отдаваемых показателей, проверили их консистентность (онтология содержит критерии целостности), посмотрели на выбросы (значения нарушающие представления о прекрасных данных: вне допустимых границ, слишком гладкие и пр, весь аппарат анализа данных), посмотрели на значения которые нужно изменить (выбросы), посмотрели исторический ряд значений, исходя из усилий мысли поправили значение, зафиксили, что исправили значение. Пробежались по всем значениям наступило счастье. Возможно часть правок удастся автоматизировать, но скорее будет инструмент причесывания данных
Результат отдали наружу, и зачем где и как соврали, можем даже написать почему соврали.
3. Для сбора данных из КИС пишем конекторы, которые сосут данные, для людей модуль опросы. Важно значения живут в моделе Bunge-Wand-Weber (то есть тройками значение-отношение-значение), но хранятся в РБД, схема которой изменяется с изменением данных без потерь значений и информации автоматом по онтологии. Очень напоминает то что делается в платформе (речь идет о внутреннем фреймворке используемом на фирме), только на более высоком уровне. Плюс работа с данными строится в терминах привычного языка выборок который работает напрямую с РБД, проблему с модификациями запросов нужно думать. Технологии тоже уже есть, некоторые в экспериментальном виде.
4. Работа с данными скорее будет производится в табличном редакторе, то есть для создания среза для анализа данных отбираем объекты про которые хотим построить набор данных, смотрим каие параметры есть, анализируем полноту покрытия параметров за интересующий период времени и заполняем срез данными из системы. Дальше анализируем средствами табличного процессора или внешней аналитической системы.
То что написано выше напоминает то как работают финансовые и прочие аналитики, но у них нет явной задачи работать с противоречивыми значениями и темпоральной логикой над ними я пытался найти в мире статистики похожую систему, но не нашел возможно системы пока в зачаточном состоянии.
Ближайшее что нашел это http://wikiposit.org/w , но немного не то нет возможности связать данные из разных наборов, например вытащить все что есть по перечню вузов.
То что описано выше это страшная смесь системы управления записями поверх кусков реляционной модели склеенной онтологией и все вместе живет в машине вывода :(.
много буков, и счастья нет :)
read more at mrcs
rss2lj