Мониторинг качества данных в компании
Способы мониторинга качества данных. Формирование функциональных требований к системе мониторинга консистентности данных. Документирование требований к системе мониторинга консистентности данных. Написание скриптов проверок для системы мониторинга.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 26.08.2017 |
| Размер файла | 387,3 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Оглавление
Введение
1. Теоретические аспекты управления качеством данных
1.1 Определение понятия качества данных и анализ подходов к его изучению
1.2 Определение измерений и показателей качества данных
1.3 Анализ подходов и способов мониторинга качества данных в информационных системах
Выводы по первой главе
2. Формирование требований к автоматизации процесса мониторинга качества данных в компании ХХХ
2.1 Анализ процесса мониторинга качества данных
2.2 Обоснование необходимости автоматизации
2.3 Формирование функциональных требований к системе мониторинга консистентности данных
2.4 Формирование нефункциональных требований к системе мониторинга консистентности данных
2.5 Документирование требований к системе мониторинга консистентности данных
Выводы по второй главе
3. Разработка и введение в эксплуатацию системы мониторинга консистентности данных
3.1 Написание скриптов проверок для системы мониторинга
3.2 Анализ результатов внедрения системы мониторинга консистентности данных в эксплуатацию
Заключение
Список литературы
Приложение 1 Техническое задание на создание системы мониторинга консистентности данных
Приложение 2 SQL-скрипты проверок
Введение
мониторинг качество данные скрипт
Компания ХХХ является одним из самых узнаваемых онлайн-ритейлеров в сфере моды и занимает лидирующие позиции среди интернет-магазинов одежды и обуви в России и странах СНГ.
Число клиентов компании растет большими темпами, с ростом количества заказов необходимо думать о производительности и отказоустойчивости сервисов, искать новые возможности для автоматизации процессов, протекающих в компании.
Одной из особенностей компании ХХХ является ее ИТ-инфраструктура. На данный момент в ИТ-департаменте более 300 сотрудников, работающих в двух центрах разработки: Вильнюс (Литва) и Москва (Россия), где проектируются, разрабатываются и внедряются ИТ-решения. В компании используется большое количество систем собственной разработки: e-commerce платформа, складская система, система управления доставкой, а также внедряются такие системы, как ERP и BI-платформа.
Для принятия взвешенных управленческих решений в компании возникла необходимость в объединении данных, находящихся на вышеперечисленных источниках, и предоставлении этих данных пользователям в унифицированном виде. Было принято решение о формировании департамента Business Intelligence, который на данный момент занимается разработкой платформы для удовлетворения информационных потребностей бизнес-пользователей. Платформа состоит из двух частей: хранилище данных (Oracle) и аналитическое приложение (SAP Business Objects).
Сбор данных в корпоративное хранилище происходит при помощи ETL-процессов (Extract, Transform, Load), обеспечивающих перенос данных с систем-источников, а также их трансформацию в соответствии с заданными правилами.
В ходе построения корпоративного хранилища данных аналитики и разработчики столкнулись с проблемой несоответствия данных на различных источниках. Причинами таких несоответствий зачастую были операторские ошибки (опечатки при вводе, неправильно проведенная транзакция), потеря актуальности данных одним из источников, технические сбои при передаче информации из одной системы в другую и т.д. Разрешение этих проблем вручную практически невозможно, однако имеются некоторые способы их автоматизации.
Для решения проблемы несоответствия данных руководством компании было принято решение о создании автоматизированной системы, которая должна выявлять несоответствия и ошибки в системах-источниках и уведомлять о них ответственные лица. Такая система должна повысить качество данных, а значит и качество предоставляемой отчетности, на основе которой руководство компании будет способно принимать грамотные и оперативные стратегические и управленческие решения.
Объектом исследования данной работы являются процессы мониторинга качества данных информационных систем, функционирующих внутри компании, а предметом исследования - средства автоматизации процессов мониторинга.
Целью работы является повышение качества предоставляемых данных путем автоматизации процесса их мониторинга в системах-источниках. Эта цель подразумевает выполнение ряда задач:
· Анализ и моделирование процесса мониторинга качества данных в информационных системах;
· Формирование требований к системе мониторинга;
· Написание технического задания на разработку системы;
· Ввод в эксплуатацию системы мониторинга и получение первых результатов ее применения.
Практическая значимость работы заключается в повышении качества и достоверности предоставляемых отчетов департаментом Business Intelligence, что в свою очередь позволит иметь более точное и полное представление об актуальном положении дел в компании, оперативно реагировать на неожиданные ситуации.
1. Теоретические аспекты управления качеством данных
Одной из основных проблем корпоративных аналитических систем и систем бизнес-анализа является обеспечение качества данных, которые консолидируются для анализа из различных систем-источников. Если не уделить достаточно внимания этой проблеме, есть риск свести на нет преимущество самых современных инструментов анализа и усилия специалистов, создающих аналитические решения. Сами решения могут быть отдаленными от реальности и исказить реальное положение дел в организации. При этом выработанные управленческие решения могут нанести ущерб бизнесу. Именно поэтому необходимо производить мониторинг качества данных и их преобразование на всех этапах аналитического процесса: от извлечения данных из источников до их обработки в аналитических системах.
1.1 Определение понятия качества данных и анализ подходов к его изучению
Первые исследования вопросов качества, в частности, продуктового, начались в 1950-х годах.
Первым и наиболее популярным определением качества данных является определение Дж. Джурана [7]: данные имеют высокое качество, если они пригодны для их предполагаемого использования в операциях, принятии решений и планировании.
Еще одно определение было дано в 1996 году профессором информационных технологий Массачусетского технологического института Ричардом Вонгом [1] и формулировалось как «пригодность к использованию» («fitness for use») - степень, с которой данные подходили для использования пользователям, или потребителям, данных.
Гораздо позже, в 2008 году, Генеральная администрация по надзору за качеством [2] ввела общую формулировку понятия качества данных - степень, с которой определенные характеристики данных удовлетворяют заявленным и предполагаемым потребностям.
Многие исследователи в области качества данных предлагали разные определения этому понятию, а также различные методы измерения качества данных. Так, Ричард Вонг, профессор информационных технологий и основатель группы Управления качеством данных в Школе Менеджмента при Массачусетском технологическом институте, ввел термин «пригодность к использованию», подчеркивая важность точки зрения потребителя данных, который решает, подходят ли они для дальнейшего использования и принесут ли они пользу. В то же время, группой был разработан опрос, благодаря которому удалось определить и разбить на группы важные с точки зрения потребителей данных характеристики:
1. Внутренние характеристики включали точность, объективность и достоверность;
2. Контекстуальные характеристики подразумевали релевантность, своевременность, полноту и соответствие;
3. Репрезентативные характеристики состояли из интерпретируемости и простоты понимания;
4. Доступность и защищенность.
Национальный Институт Статистических Наук (США) в 2001 году опубликовал доклад [4], в котором определил основные принципы качества данных:
1. Данные - это продукт, со своими потребителями, для которых они несут какую-либо пользу и имеют ценность;
2. Как и любой другой продукт, данные имеют качество;
3. Качество данных является многомерным понятием и включает в себя внутренние, контекстуальные, репрезентативные характеристики, а также характеристики доступа;
4. Качество данных может быть измерено и улучшено, но технологий и программных средств недостаточно;
5. Понимание важности качества данных выражено не в полной мере. Большинство организаций беспокоятся о своих данных и их качестве, но только некоторые из них способны охарактеризовать влияние, которое оказывают некорректные данные на бизнес и принимаемые решения, и еще меньше организаций внедряют программное обеспечение для отслеживания показателей качества данных и их последующей корректировки.
На тот момент существовало несколько существенных пробелов в изучении качества данных. Во-первых, проверка качества данных должна проходить на нескольких уровнях: на уровне записей в таблицах баз данных, на уровне одной базы данных и на уровне совокупности интегрированных баз данных. Проверка качества данных на низких уровнях агрегации, например, на уровне отдельных записей, может быть осуществлена в рамках настроек таблиц, в которых эти записи хранятся. Но как осуществлять проверку на более высоких уровнях агрегации - не вполне очевидно. Во-вторых, для того, чтобы проводить подобные проверки, необходима реализация определенных моделей и алгоритмов, которые, в свою очередь, требуют автоматизации посредством программных средств и приложений. Эти инструменты необходимы для измерения и совершенствования качества данных и должны состоять из алгоритмов и средств визуализации.
Управление качеством данных может быть определено как «качественно-ориентированный подход к управлению данными как активом». Это подразумевает «применение концепции всеобщего управления качеством (TQM) для того, чтобы улучшить качество данных и информации, включающее определение принципов качества данных, измерение качества данных (его аудит и сертификация), анализ качества данных, очистка и корректировка данных, а также дальнейшее совершенствование процессов управления качеством данных» [8]. Чтобы сделать процесс управления качеством данных более эффективным, он должен фокусироваться не только на корректировке некачественных данных, но и стараться предотвращать проблемы на протяжении всего жизненного цикла данных внутри организации для удовлетворения информационных потребностей пользователей и заинтересованных сторон. Более того, необходимо обеспечить эффективное взаимодействие между бизнес-единицами и ИТ-инфраструктурой компании, чтобы учитывать как бизнес аспекты управления данными, так и технические.
Согласно Л. Инглишу [9] издержки использования некачественных данных могут быть классифицированы следующим образом:
· Затраты на ошибки и сбои в процессах, которые возникают в результате того, что процессы протекают не должным образом из-за низкого качества данных;
· Затраты на переделывание работы и устранение неполадок для достижения желаемого уровня качества;
· Альтернативные издержки, связанные с упущенными выгодой и возможностями.
Далее будут рассмотрены наиболее важные аспекты концепции качества данных, а также некоторые подходы и методологии, используемые организациями для оценки и улучшения качества данных.
Согласно DAMA [8], под «управлением данными» («data management») чаще всего подразумевается:
1. Бизнес-функция, в рамках которой разрабатываются стратегии, планы и проекты по контролю, защите, поддержке и повышению ценности данных;
2. Программное приложение по реализации и оценке эффективности функций управления данными;
3. Должностные лица, выполняющие функции управления данными.
На основе анализа научной и исследовательской литературы о качестве данных, была сформирована Таблица 1, в которой представлена классификация основных концепций, лежащих в основе управления данными.
Таблица 1
Концепции и понятия управления данными
|
Концепция |
Значение |
|
|
Управление данными (Data Governance) |
· Совокупность людей, процессов и технологий, позволяющая организации использовать данные как ресурс предприятия [10] · Высокоуровневое планирование и контроль управления данными, координирующее взаимодействие между бизнес- и ИТ-подразделениями предприятия [11] |
|
|
Управление качеством данных (Data Quality Management) |
Применение концепции всеобщего управления качеством (TQM) для того, чтобы улучшить качество данных и информации, включающее определение принципов качества данных, измерение качества данных (его аудит и сертификация), анализ качества данных, очистка и корректировка данных, а также дальнейшее совершенствование процессов управления качеством данных [8] |
|
|
Методология качества данных (Data Quality Methodology) |
Набор принципов и методов, определяющих наиболее рациональный процесс оценки и улучшения качества данных [12] |
|
|
Методы обеспечения качества данных (Data Quality Techniques) |
Могут быть ориентированы как на сами данные, так и на процессы, связанные с этими данными. В первом случае это могут быть алгоритмы и процессы, направленные на решение конкретных проблем, связанных с качеством данных (удаление дубликатов или приведение данных к стандартному виду). Процессно-ориентированные методики используются для анализа и реинжиниринга процессов производства информации [12] |
|
|
Инструменты обеспечения качества данных (Data Quality Tools) |
Программные продукты, обеспечивающие удовлетворение основных требований к качеству данных, в частности, реализующие стандартизацию, очистку, мониторинг и корректировку данных [13] |
|
|
Контроль качества данных |
Часть управления качеством данных которая отвечает за контроль соответствия качества данных заявленным требованиям [14] |
Данная работа будет сфокусирована на таких разделах управления качеством данных как контроль качества данных (или мониторинг), а также методы и инструменты обеспечения качества данных.
1.2 Определение измерений и показателей качества данных
Согласно предложенному выше определению, «данные имеют высокое качество, если они пригодны для их предполагаемого использования в операциях, принятии решений и планировании». Несмотря на широкое признание, это определение нуждается в более глубокой спецификации, поскольку качество данных является многомерной концепцией и вводится в действие при помощи измерений - определенных характеристик данных, которые представляют ценность для конечных потребителей этих данных. О них и пойдет речь в этом разделе.
Для того, чтобы систематизировать проблемы, связанные с данными, выделим следующие уровни [15]:
1. Технический уровень. Подразумевает нарушения, связанные со структурой данных, их полнотой и целостностью, а также некорректными форматами.
2. Аналитический уровень. Включает факторы, которые мешают корректному анализу данных, такие как аномальные значения, дубликаты, противоречивые данные.
3. Концептуальный уровень. Проблемы возникают в связи с тем, стратегия сбора данных была изначально неверная. Данные не содержат полной информации о бизнес-процессах и положении компании. Данных может быть мало - в этом случае используются алгоритмы обогащения данных; иногда бывает, что данных слишком много, а полезной является только часть из них - тогда используются различные методы «очистки» данных.
На основе выделенных уровней качества данных была сформирована Таблица 2, содержащая сравнительную характеристику этих уровней.
Таблица 2
Уровни качества данных
|
Уровень |
Факторы |
Проявление |
Место борьбы |
|
|
Технический |
· нарушения в структуре данных; · некорректное наименование таблиц или полей; · некорректные форматы данных; · нарушение полноты и целостности; · противоречия и дубликаты на уровне таблиц; |
Мешают консолидированию и интегрированию данных в хранилище данных и аналитические системы |
ETL |
|
|
Аналитический |
· аномальные значения, опечатки; · шумы; · противоречия и дубликаты на уровне записей; |
Влияют на достоверность данных, искажают результаты анализа. |
Источники данных, ETL, аналитические системы |
|
|
Концептуальный |
Собранных данных недостаточно для анализа бизнес-процессов |
Данных недостаточно для анализа |
Разработка аналитических проектов |
Для того, чтобы в полной мере оценить качество данных, необходимо акцентировать внимание на всех трех уровнях.
В 2012 году международная Ассоциация Управления Данными сформировала рабочую группу, которая должна была рассмотреть вопрос измерения качества данных и предложить список параметров для оценки качества данных на основании лучших практик. Рабочая группа выпустила статью [5], в которой определялись шесть ключевых измерений для оценки. Организации должны оценивать состояние своих данных, используя эти параметры, однако это совсем не обязательно использовать все шесть из них. Некоторые параметры могут быть опущены за необходимостью, остальные должны выбираться в зависимости от потребностей бизнеса.
Таким образом, согласно исследованию рабочей группы, шестью ключевыми параметрами для оценки качества данных являются полнота, уникальность, своевременность, валидность («пригодность»), точность и консистентность (согласованность).
1. Полнота данных означает, что каждому атрибуту присваивается определенное значение в наборе данных. Степень полноты данных может быть вычислена путем подсчета отсутствующих (нулевых или пустых) значений атрибутов.
2. Уникальность подразумевает, что ключевые поля записей в наборе данных не могут быть записаны дважды.
3. Своевременность - это свойство данных соответствовать нуждам потребителей в нужный для них момент времени.
4. Валидность означает, что данные соответствуют синтаксису (по формату, типу, диапазону значений и тд). Определить степень пригодности данных можно сравнив эти данные с документацией к ним.
5. Точность - это степень, с которой данные корректно описывают объект реального мира.
6. Согласованность означает отсутствие различий между одними и теми же данными, хранящихся на разных источниках. Два значения атрибута, принадлежащие разным наборам данных, не должны противоречить друг другу.
В своем исследовании группа, изучавшая параметры оценки качества данных, рекомендует организациям выбирать только те показатели, которые необходимо отслеживать в контексте бизнеса и бизнес-требований. Каждая организация должна определить для себя, в какой степени каждый показатель содействует улучшению качества данных в рамках конкретной компании.
1.3 Анализ подходов и способов мониторинга качества данных в информационных системах
Прежде чем приступать к анализу данных, необходимо провести комплекс мероприятий, получивших название «очистка» данных, который основывается на знаниях о характере данных и структуре источников, в которых они хранятся.
Однако прежде чем выполнять очистку данных, необходимо предварительно провести ее оценку, для того чтобы выявить наиболее характерные проблемы и степень их сложности, для того чтобы в дальнейшем выработать верную стратегию их очистки. Вероятно, после подобной оценки будет принято решение отказаться от очистки некоторых данных, ввиду того, что это слишком сложно, дорого и не принесет никаких существенных результатов. Кроме того, некоторые методы очистки могут только ухудшить ситуацию, а предварительная оценка уровня качества данных позволит избежать подобных случаев.
Очень частой является ситуация, когда проекты по очистке данных начинаются тогда, когда данные являются настолько некачественными, что их анализ становится практически невозможным по каким-либо техническим причинам или недостоверности получаемых результатов. Для того, чтобы избежать подобных ситуаций, необходимо комплексно подходить к проблеме качества данных: разрабатывать стратегию сбора и консолидации данных одновременно с их мониторингом и оценкой качества, поиском причин, которые влияют на качество данных и выработкой стратегии по их устранению.
В результате развития такого комплексного подхода к поддержанию качества данных на должном уровне, появилась новая дисциплина - управление качеством данных на предприятии. Развитие этой дисциплины можно обосновать тем фактом, что многие организации потерпели неудачу из-за низкого качества данных и невозможности принимать своевременные управленческие решения на их основе. Как уже было сказано ранее, управление качеством данных стало частью общего процесса управления качеством на предприятии TQM (Total Quality Management).
Оценка качества данных может быть осуществлена тремя способами [15]:
1. Единовременная оценка качества. Проводится единоразово для какого-то массива данных, после чего к нему применяется определенная стратегия очистки, либо данные признаются качественными и остаются без изменений.
2. Мониторинг. Специальные программы поиска ошибок в данных непрерывно сканируют поток данных, из различных источников.
3. Визуальная оценка. Используется в отдельных случаях, когда специализированным программам не удалось повысить качество данных. Чаще всего это способ используется во время предобработки данных, поступивших в аналитическую систему: аналитик при помощи таблиц и графиков определяет аномальные значения в данных, пропуски и прочие противоречия. Такой способ реально использовать только в единичных случаях и с небольшим объемом данных.
В процессе разработки методики оценки качества данных в конкретной организации необходимо определиться, где именно эта оценка будет происходить. Возможны следующие варианты [15]:
1. В источниках данных выполняется поиск орфографических ошибок, пропущенных значений, противоречий и дубликатов на уровне записей и таблиц. Преимуществом этого варианта является то, что соответствующие методы очистки могут применяться на этапе ETL-процессов, а в хранилище данных поступят уже очищенные данные. Но тем не менее, качество данных может вновь ухудшиться в результате объединения источников.
2. В процессе ETL выявляются проблемы в данных во время процесса их переноса в хранилище данных, однако таким образом есть риск загрузить информационную систему предприятия.
3. В аналитической системе оценка может производиться аналитиком при помощи таблиц, графиков и диаграмм, а также на основе статистических оценок.
Оценивать качество данных лучше всего на всех перечисленных выше этапах. Так, в источниках удобно идентифицировать ошибки ввода данных; в процессе ETL можно проследить нарушения структуры и полноты данных; в аналитической системе данные оцениваются с точки зрения их пригодности для решения конкретной аналитической задачи.
Оценка качества данных, контроль ошибок и анализ проблем - обязательные этапы любого проекта по бизнес-аналитике. Таким образом появилась необходимость в облегчении выполнения этих этапов путем автоматических проверок, которые должны осуществляться при помощи специальных инструментов. Эти инструменты должны помочь выявить отклонения у объектов, атрибутов и отношений в хранилищах данных и базах данных.
Основываясь на исследовании компании Gartner [16], рынок программного обеспечения по контролю и мониторингу качества данных стремительно растет (Рисунок 1).
Рисунок 1 The Gartner 2016 Magic Quadrant for Data Quality Tools
Выводы по первой главе
В рамках Главы 1 были рассмотрены история исследования и определение понятия качества данных. Так, качество данных - это степень, с которой определенные характеристики данных удовлетворяют заявленным и предполагаемым потребностям. Далее были рассмотрены концепции управления данными. В рамках работы основное внимание будет уделено концепции мониторинга качества данных, а также методам и инструментам контроля качества данных.
Для того, чтобы измерить качество данных, необходимо отслеживать следующие показатели: полнота, уникальность, своевременность, валидность («пригодность»), точность и консистентность (согласованность). Также были рассмотрены варианты измерения этих показателей.
2. Формирование требований к автоматизации процесса мониторинга качества данных в компании ХХХ
ХХХ -- крупная компания сектора e-commerce, осуществляющая онлайн-продажу и доставку модной одежды, обуви, аксессуаров, косметики и парфюмерии. Стартовав в 2011 году, проект стал одним из ведущих игроков сферы интернет-торговли и занял лидирующую позицию среди российских интернет-магазинов одежды и обуви.
Как уже было сказано ранее, компания имеет довольно развитую ИТ-инфраструктуру. На данный момент в ИТ-департаменте более 300 сотрудников, работающих в двух центрах разработки: Вильнюс (Литва) и Москва (Россия), где проектируются, разрабатываются и внедряются ИТ-решения. В компании используется большое количество систем собственной разработки: e-commerce платформа, складская система, система управления доставкой, а также внедряет такие решения, как учетная система и платформа Business Intelligence. Во всех этих системах ежедневно фиксируются огромные массивы данных, которые при правильной обработке и последующем анализе могут помочь найти новые стратегические возможности для бизнеса.
Между информационными системами компании происходит постоянный обмен данными. Например, когда заказ отменяется клиентом, эта информация поступает в систему управления заказами, оттуда - в систему управления складом. В случае, если произойдет какой-либо технический сбой, складская система не получит вовремя информацию об отмене заказа, операторы начнут формировать заказ, в котором уже нет нужды, в результате - потеря времени на лишние действия.
В случае возникновения каких-либо технических или операторских ошибок возникает риск не только получить некорректные результаты при анализе этих данных, но и снизить показатели результативности компании.
Аналитиками и разработчиками отдела бизнес-анализа в процессе непрерывной работы с данными были обнаружены проблемы несоответствия одинаковых данных на соответствующих источниках. В качестве основных причин таких несоответствий можно выделить следующие:
1. Человеческий фактор. Сотрудники компании непрерывно формируют потоки «грязных», некачественных данных. Самые элементарные и незначительные ошибки в вводе данных могут привести к большим искажениям информации о ходе бизнеса. С одной стороны, процент подобных ошибок можно снизить, максимально автоматизировав процессы и минимизировав ручной ввод информации в системы. Также можно давать сотрудникам четкие инструкции по вводу данных. Однако все эти меры не решат проблему кардинально.
2. Технические сбои. Как уже было сказано ранее, компания ХХХ отличается большим количеством информационных систем, которые ежедневно фиксируют миллионы транзакций и совершают постоянный обмен данными друг с другом. Периодически системы перегружаются, и такие перегрузки могут являться причинами некоторых сбоев при передаче данных.
3. Потеря актуальности данных одним из источников.
Так возникла необходимость в автоматизации процесса отслеживания таких несоответствий и проектировании системы мониторинга.
Таким образом, целью построения системы мониторинга консистентности данных является:
1. Улучшить качество поступающих данных.
2. Снизить число расхождений в данных между системами.
3. Повысить качество и достоверность формируемой отчетности.
4. Повысить бизнес-результаты компании за счет обеспечения руководителей отчетностью, необходимой для принятия управленческих решений.
Для выявления узких мест в текущем процессе мониторинга качества данных был проведен ряд интервью с аналитиками и разработчиками департамента бизнес-анализа, которые курируют процессы оценки качества данных в компании.
По итогам был сформирован список требований к системе, описание процессов мониторинга качества данных и написано техническое задание на разработку системы.
2.1 Анализ процесса мониторинга качества данных
На данный момент контроль качества данных осуществляется по пяти показателям (полнота, уникальность, своевременность, валидность, точность) на этапе сбора данных из систем, а также в процессе их консолидации и преобразовании в процессе ETL. На Рисунке 3 представлена обобщенная схема процесса ETL.
Рисунок 2 Схема ETL-процесса
На этапе извлечения данные запрашиваются из одного или нескольких источников и подготавливаются к преобразованию. На этапе преобразования производится преобразование форматов и кодировки данных, а также их обобщение и очистка. На этапе загрузки - запись преобразованных данных в хранилище данных.
В рамках процесса ликвидируются ошибки, связанные с:
· корректностью форматов и представлений данных;
· уникальностью первичных ключей;
· полнотой и целостностью данных;
· соответствием некоторым аналитическим ограничениям и т.д.
Поиск и исправление ошибок происходит на уровнях: отдельной ячейки, отдельной записи, отдельной таблицы и отдельной базы данных. В Таблице 3 представлена информация об исправляемых ошибках на каждом из перечисленных уровней.
Таблица 3
Корректировка ошибок
|
Уровень |
Ошибки |
|
|
Отдельная ячейка |
· Орфографические ошибки или опечатки · Пропуски данных · Фиктивные значения (данные, не имеющие смысла) · Логические несоответствия (значение ячейки не соответствует смыслу поля) |
|
|
Отдельная запись |
Противоречивость данных в различных ячейках записи |
|
|
Отдельная таблица |
Дублирующие и противоречивые записи |
|
|
Отдельная база данных |
Нарушение целостности данных (различные объекты базы не согласуются между собой) |
В результате анализа процесса мониторинга качества данных в компании был выявлен ряд недостатков. Во-первых, согласно оценке разработчиков хранилища данных департамента бизнес-аналитики, полностью очистить данные удается очень редко. Использование очень сложных алгоритмов очистки увеличивает время переноса данных в хранилище до недопустимой величины. В связи с этим, приходится обеспечивать компромисс между сложностью алгоритмов, затратами на вычисление, временем очистки и результатами проверки.
2.2 Обоснование необходимости автоматизации
После анализа текущего процесса мониторинга качества данных в компании ХХХ, было предложено внести в него ряд корректировок.
Согласно экспертной оценке ведущих разработчиков хранилища данных департамента бизнес-анализа компании, интеграция процесса мониторинга консистентности данных в процессы консолидации данных из систем-источников и процессы ETL может стать причиной замедления этих процессов. Для того, чтобы выявлять несоответствия, необходимо проводить сверки между несколькими системами-источниками по множеству атрибутов, что может стать причиной перегрузки процессов ETL и консолидации данных.
Использование одного из готовых решений по контролю качества данных, представленных на рынке информационных систем, также посчиталось нецелесообразным. Аналитиками департамента бизнес-анализа была проведена оценка готовых средств и сделаны следующие выводы. Довольно несложно измерить показатели таких параметров, как полнота, уникальность, своевременность или валидность, которые являются наиболее часто запрашиваемыми критериями качества данных. Существующие программные приложения в основном направлены на отслеживание именно этих показателей качества. Однако такой показатель, как консистентность (или согласованность), который и является предметом исследования, такими приложениями не измеряется. Он зависит от определенных ограничений и процессов, характерных конкретной компании, поэтому реализация универсального решения может оказаться сложной или даже невозможной.
В Таблице 4 представлена сравнительная характеристика сильных и слабых сторон двух вариантов реализация процесса мониторинга качества данных - с использованием специализированных инструментов и без их использования.
Таблица 4
Сравнение вариантов реализации контроля качества данных
|
Сильные стороны решения |
Слабые стороны решения |
|
|
Реализация контроля качества данных без применения специализированных инструментов |
||
|
· уменьшение затрат на лицензии; · гибкость в организации процесса разработки; · гибкость по отношению к ИТ системам и форматам данных |
· необходимость обучения специалистов специфике разработанного решения; · затраты на документирование и поддержание документации в актуальном состоянии |
|
|
Реализация контроля качества данных с применением специализированных инструментов |
||
|
· снижение трудозатрат на разработку и реализацию; · наличие поддержки со стороны поставщика |
· увеличение затрат на лицензии; · жесткие условия относительно реализации процесса разработки; · жесткие условия в отношении состава ИТ и форматов данных; · необходимость обучения персонала |
Таким образом, в случае компании ХХХ целесообразно спроектировать собственную систему мониторинга показателей несоответствия данных, обособленно от процесса оценки качества данных во время процесса ETL. Это позволит усовершенствовать процесс мониторинга качества данных в компании ХХХ, добавив контроль одного из ключевых показателей.
Автоматизация процесса мониторинга несоответствий данных позволит сократить количество расхождений одинаковых данных на разных источниках, повысит качество этих данных, а также отчетности, которая строится на основании этих данных, что позволит руководству компании принимать своевременные и правильные управленческие решения и повысит показатели эффективности компании.
2.3 Формирование функциональных требований к системе мониторинга консистентности данных
После проведения анализа процессов мониторинга качества данных в компании ХХХ, в процессах был выявлен ряд недостатков: один из самых важных показателей качества данных - консистентность - никак не отслеживается. В связи с этим было принято решения об усовершенствовании процесса мониторинга качества данных путем автоматизации процесса мониторинга консистентности данных. Одним из важнейших этапов автоматизации процесса является формирование функциональных требований к системе.
Для формирования требований пользователя к системе используются различные методики, такие как методика Карла Вигерса, FURPS, FURPS+, SWEBOK. При документировании требований, как правило, используются корпоративные стандарты, основанные на ГОСТ 34.602-89 «Техническое задание на создание информационной системы» или сам стандарт.
Функциональные требования к разрабатываемой системе будут описаны по методике FURPS+. Данная методика делит требования на функциональные и нефункциональные. Название методики расшифровывается следующим образом:
1. Functionality (Функциональность) - содержат основные функции системы, такие как лицензирование, отчетность, безопасность, поддержка документооборота.
2. Usability (Удобство использования) - это субъективные требования пользователей, например, эстетика интерфейса, стандарты оформления, справочная информация в системе.
3. Reliability (Надежность) - это способность системы выполнять требуемые функции в заданных режимах. Подразумевает такие характеристики, как допустимая частота сбоев, предсказуемость поведения, точность вычислений и тд.
4. Performance (Производительность) - включает такие характеристики, как скорость работы и время отклика, пропускная способность (число одновременно работающих пользователей, количество пользовательских запросов, объем запрашиваемых и передаваемых данных), скорость запуска и завершения работы системы.
5. Supportability (Поддерживаемость) - требования к адаптируемости системы, масштабированию, совместимости с другими системами.
Также в рассматриваемой методике к требованиям были добавлены ограничения, которые должна иметь система.
1. Ограничения проектирования. Ограничения, которые влияют на проектные решения, такие как ограничения по технологиям, средствам разработки и тд.
2. Ограничения разработки. Задают стандарты написания программного кода.
3. Ограничения на интерфейсы - ограничения на взаимодействие с другими системами.
Физические ограничения - ограничения на технические и аппаратные средства системы.
Для формирования требований к системе необходимо построить модель процесса, который она автоматизирует. Процесс мониторинга консистентности данных должен быть осуществлен при помощи четырех модулей - система управления проверками, ETL-средство, база данных системы мониторинга и система визуализации(web-приложение) - следующим образом. Система управления проверками, согласно расписанию проверок, запускает ETL-средство, которое извлекает данные из заданных систем по заданному временному интервалу. Далее извлеченные данные сохраняются в базе данных системы мониторинга. Система управления проверками запускает скрипты проверок к базе данных, результат проверки сохраняется в базе и передается системе управления проверками. Далее система формирует excel- и html-файлы. Excel-файлы рассылаются ответственным лицам, а html-файлы передаются в систему визуализации данных, которая представляет собой web-приложение.
На Рисунке 3 представлена модель описанного процесса.
Рисунок 3 Модель процесса мониторинга консистентности данных
На основании построенной модели были выявлены требования к системе мониторинга консистентности данных. В Таблице 5 представлен список операций, которые должна выполнять система.
Таблица 5
Операции системы мониторинга
|
Операция |
Вход |
Выход |
Описание |
|
|
Запустить загрузку данных с систем-источников |
Расписание проверок |
Список проверяемых источников |
Crontab по установленному расписанию для каждой проверки запускает java-скрипты подсистемы управления проверками, которые в свою очередь запускают ETL-средство |
|
|
Запросить данные из систем-источников |
Список проверяемых источников, временной интервал проверки |
Запрос к базе источника |
ETL-средство получает от Python-приложения информацию о наименованиях систем, из которых необходимо выгрузить данные, а также значение инкремента для вычисления интервала выгрузки |
|
|
Записать запрошенные данные в БД |
Список записей |
Таблица с записями в БД |
ETL-средство передает данные с систем-источников в БД системы мониторинга |
|
|
Сохранить запрошенные данные в БД |
Список записей |
Таблица с записями в БД |
БД системы мониторинга записывает данные из систем источников в промежуточном слое |
|
|
Запустить проверку данных с систем-источников |
Название проверки |
Запрос к базе системы мониторинга |
Python-приложение запускает скрипты проверки к БД системы мониторинга |
|
|
Выполнить запросы проверки данных |
Запрос к базе системы мониторинга |
Список найденных расхождений |
БД системы мониторинга выполняет скрипты, запущенные Python-приложением |
|
|
Зафиксировать результаты сравнения в таблицу расхождений |
Список найденных расхождений |
Таблица со списком расхождений |
БД системы мониторинга сохраняет результаты выполнения запросов Python-приложения в таблицу расхождений |
|
|
Сформировать excel-файл для email-рассылки |
Таблица со списком расхождений |
Excel-файл со списком расхождений |
Python-приложение «забирает» результаты проверки из таблицы расхождений в БД и создает excel-файл |
|
|
Отправить excel-файл с результатами проверки |
Excel-файл со списком расхождений |
Email-нотификация |
Python-приложение получает список email-адресов из специальной таблицы в БД и запускает рассылку созданных excel-файлов |
|
|
Сформировать html-файл для визуализации данных |
Таблица со списком расхождений |
HTML-файл со списком расхождений |
Python-приложение «забирает» результаты проверки из таблицы расхождений в БД и создает HTML-файл |
|
|
Отправить результаты в систему визуализации |
HTML-файл со списком расхождений |
HTML-файл со списком расхождений |
Python-приложение передает сформированные HTML-файлы в подсистему отображения (web-приложение) |
|
|
Отобразить результаты проверки |
HTML-файл со списком расхождений |
Графическая визуализация результатов проверки |
Web-приложение на основании полученных html-файлов отображает результаты проверки |
Разрабатываемая система мониторинга консистентности данных должна состоять из следующих подсистем:
подсистема сбора и преобразования данных;
подсистема управления проверками;
база данных системы мониторинга;
подсистема отображения результатов мониторинга.
Каждая система выполняет свою операцию. В Таблице 6 приведено разделение операций по подсистемам.
Таблица 6
Подсистема - Операция
|
Подсистема |
Операция |
|
|
Подсистема сбора и преобразования данных |
· Запросить данные из систем-источников · Записать запрошенные данные в БД |
|
|
Подсистема управления проверками |
· Запустить загрузку данных с систем-источников · Запустить проверку данных с систем-источников · Сформировать excel-файл для email-рассылки · Отправить excel-файл с результатами проверки · Сформировать html-файл для визуализации данных · Отправить результаты в систему визуализации |
|
|
База данных системы мониторинга |
· Сохранить запрошенные данные в БД · Выполнить запросы проверки данных · Зафиксировать результаты сравнения в таблицу расхождений |
|
|
Подсистема отображения результатов мониторинга |
· Отобразить результаты проверки |
1. Требования к подсистеме сбора и преобразования данных.
1.1. Подсистема сбора и преобразования данных должна обеспечивать возможность извлечения данных из систем-источников, использующих различные виды баз данных (PostgreSQL, MySQL, Oracle и тд.).
1.2. Подсистема сбора и преобразования данных должна поддерживать извлечение данных измененных или добавленных с момента последнего успешного извлечения данных (инкрементальное извлечение данных).
1.3. Подсистема сбора и преобразования данных должна обеспечивать возможность отслеживания статуса ETL-процесса с указанием количества элементов данных, извлеченных из систем-источников.
1.4. Подсистема сбора и преобразования данных должна быть оптимизирована для работы с большим количеством данных.
1.5. Подсистема сбора должна отправлять отчет о работе подсистеме управления проверками.
2. Требования к подсистеме управления проверками
2.1. Подсистема управления проверками должна запускать подсистему сбора и преобразования данных с систем-источников согласно заранее установленному расписанию проверок.
2.2. Подсистема управления проверками должна запускать скрипты проверок к базе данных системы мониторинга.
2.3. Подсистема управления проверками должна формировать excel-файлы с результатами проверок.
2.4. Подсистема управления проверками должна выполнять рассылку excel-файлов с результатами проверок ответственным департаментам.
2.5. Подсистема управления проверками должна формировать html-файлы с результатами проверок для дальнейшей передачи их в подсистему отображения результатов мониторинга.
2.6. Подсистема управления проверками должна передавать html-файлы с результатами проверок в подсистему отображения результатов мониторинга.
3. Требования к базе данных системы мониторинга.
3.1. База данных системы мониторинга должна накапливать и хранить информацию из различных источников, необходимую для решения задач мониторинга консистентности данных.
3.2. В рамках базы данных должны быть реализованы следующие разделы:
3.2.1. Промежуточный раздел, в котором консолидируются данные с систем-источников.
3.2.2. Раздел служебных данных, в котором хранятся настроечные таблицы для функционирования системы:
текущие значения инкрементов;
SQL-скрипты для реализации каждой из проверок;
cписки получателей результатов проверок и тд.
3.2.3. Раздел результатов проверок, в котором содержатся найденные расхождения. Должен включать как список с результатами по каждой проверке, так и уникальный список расхождений.
3.2.4. Раздел, содержащий таблицы, используемые средствами визуализации - подсистемой отображения данных мониторинга.
4. Требования к подсистеме отображения результатов мониторинга.
4.1. Подсистема отображения данных мониторинга должна обеспечивать пользователям доступ через WEB-браузер без установки дополнительного программного обеспечения.
4.2. Подсистема отображения данных мониторинга должна отображать количество найденных за день расхождений по каждой из проверок, а также количество исправленных расхождений.
4.3. Подсистема отображения данных мониторинга должна обеспечивать возможность использования различных динамических представлений информации, такие как графики и диаграммы для более наглядного отображения результатов мониторинга.
2.4 Формирование нефункциональных требований к системе мониторинга консистентности данных
Согласно методологии формирования требований FURPS+, к нефункциональным требованиям относятся удобство использования, надежность, производительность, поддерживаемость.
Требования к надежности и отказоустойчивости
1. Технические средства, обеспечивающие хранение информации в системе мониторинга, должны использовать технологии, обеспечивающие повышенную надежность хранения данных.
2. При возникновении сбоев, включая аварийное отключение электропитания, система мониторинга должна автоматически восстанавливать свою работоспособность после устранения сбоев.
3. Для каждого пользователя системы мониторинга должна быть заведена собственная учетная запись (логин).
4. Должна быть возможность блокирования пользователя системы мониторинга с отключением всех текущих сессий.
Требования к сохранности информации при авариях
1. Система мониторинга должна сохранять свое функционирование при корректном перезапуске виртуальной машины. Должна быть предусмотрена возможность полного резервного копирования данных системы.
2. Должна быть предусмотрена возможность восстановления данных, содержащихся в системе, из резервной копии с последующей дозагрузкой актуальных данных из систем-источников.
Требования к производительности
1. Данные системы мониторинга должны быть доступны пользователям круглосуточно.
2. Загрузка данных из внешних систем-источников должна осуществляться ежедневно согласно расписанию.
3. Должна обеспечиваться возможность единовременной работы до 100 пользователей.
Требования к масштабируемости
1. Должна существовать возможность увеличения объема данных, содержащихся в БД информационной системы, увеличения производительности загрузки и обработки данных.
2. Должна существовать возможность добавления новых информационных систем в качестве источников.
Требования к удобству использования
1. Информационные панели должны обеспечивать наблюдение за состоянием проверок в режиме реального времени.
2. Должна быть предусмотрена возможность фильтрации информационных панелей по типам проверок в режиме реального времени.
2.5 Документирование требований к системе мониторинга консистентности данных
Следующим этапом работы стало формулирование технического задания на создание системы мониторинга консистентности данных. Построение и оформление технического задания будет происходить согласно ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».
ГОСТ 34.602-89 имеет следующие разделы:
1. Общие сведения. Содержит наименование системы, информацию о заказчике и разработчике системы, сроки начала и окончания работ, источники финансирования и т.д.
2. Назначение и цели создания системы. Указывается, для управления какими процессами предназначена система, перечень объектов автоматизации; приводятся значения технических, производственно-экономических и прочих показателей, которые должны быть достигнуты в результате создания АИС.
3. Характеристика объектов автоматизации. Приводятся краткие сведения об области деятельности заказчика и сферы автоматизации.
4. Требования к системе. Состоит из трех подразделов:
4.1. Требования к системе в целом.
4.1.1. Требования к структуре и функционированию системы;
4.1.2. Требования к численности и квалификации персонала системы и режиму его работы;
4.1.3. Показатели назначения;
4.1.4. Требования к надежности;
4.1.5. Требования к эргономике и технической эстетике;
4.1.6. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;
4.1.7. Требования к защите информации от несанкционированного доступа;
4.1.8. Требования по сохранности информации при авариях;
4.1.9. Требования к защите от влияния внешних воздействий;
4.1.10. Дополнительные требования;
4.1.11. Требования безопасности
4.2. Требования к функциям, выполняемым системой. В этом разделе приводят перечень функций и задач по каждой подсистеме, временной регламент по реализации функций и требования к качеству реализации.
4.3. Требования к видам обеспечения.
4.3.1. Требования к математическому обеспечению;
4.3.2. Требования к информационному обеспечению;
4.3.3. Требования к лингвистическому обеспечению;
4.3.4. Требования к программному обеспечению;
4.3.5. Требования к техническому обеспечению;
4.3.6. Требования к метрологическому обеспечению;
4.3.7. Требования к организационному обеспечению;
4.3.8. Требования к методическому обеспечению.
5. Состав и содержание работ по созданию системы. Данный раздел содержит стадии и этапы работ по созданию системы, сроки их выполнения и т.д.
6. Порядок контроля и приемки системы. В этом разделе указывают виды, состав и объем испытаний системы, требования к приемке работ.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. Приводится перечень основных мероприятий, которые следует выполнить при подготовке объекта автоматизации к вводу Системы в действие.
8. Требования к документированию.
9. Источники разработки.
В разработанном техническом задании будут включены следующие разделы:
1. Общие сведения.
2. Назначение и цели создания системы.
3. Характеристика объектов автоматизации.
4. Требования к системе.
a. Требования к системе в целом.
Подобные документы
Выбор сервера базы данных, инструментальных средств разработки клиентского интерфейса и технологий. Описание таблиц базы данных системы мониторинга. Разработка инструментальных средств создания элементов системы. Интерфейс генерации тестов. Расчет затрат.
дипломная работа [1,9 M], добавлен 12.03.2013Небезопасность и ненадежность интернета вещей. Специфика медицинских систем мониторинга в сетях IOT. Высокоуровневая архитектура системы Medicus. Детали реализации обработки внешних данных. Безопасность IOT устройств. Меры защиты персональных данных.
курсовая работа [2,4 M], добавлен 24.07.2016Назначение, принципы построения и архитектура единой системы мониторинга и администрирования. Характеристика аппаратуры цифровой системы передачи данных ВТК-12. Принцип работы шлюза, создание его файлов конфигурации и реализация интерфейсных функций.
дипломная работа [3,2 M], добавлен 28.10.2013Сущность и значение мониторинга и анализа локальных сетей как контроля работоспособности. Классификация средств мониторинга и анализа, сбор первичных данных о работе сети: анализаторы протоколов и сетей. Протокол SNMP: отличия, безопасность, недостатки.
контрольная работа [474,8 K], добавлен 07.12.2010Интерфейс системы онлайн-мониторинга стационарного аппарата. Интерфейс автоматизированного рабочего места мониторинга АПБ Московского метрополитена. Архитектура системы ProView, основные сферы применения. Структура графического интерфейса пользователя.
курсовая работа [1,8 M], добавлен 21.03.2016Общая характеристика деятельности Калининградского филиала федерального государственного бюджетного учреждения "Центр системы мониторинга рыболовства и связи". Инструктаж на рабочем месте. Анализ базы данных предприятия с помощью программы Visual FoxPro.
отчет по практике [18,7 K], добавлен 10.02.2014Общая характеристика и функциональные возможности, внутреннее устройство и принцип работы спутниковых систем мониторинга, особенности их применения в сфере сельского хозяйства. Технология решения задачи мониторинга. Разработка программного обеспечения.
дипломная работа [5,3 M], добавлен 15.05.2014Понятие автоматизированной информационной системы, ее структурные компоненты и классификация. Основные функции систем управления процессом. Применение базы данных процесса для мониторинга и управления. Доступ к базе данных процесса, запросы и протоколы.
реферат [457,1 K], добавлен 18.12.2012Информационная инфраструктура современных предприятий. Регистрация и обработка событий. Сбор, хранение и представление данных. Мастер сканирования сети и принципы его работы. Мониторинг состояния хостов. Способ распространения и мониторинг сетей.
курсовая работа [3,4 M], добавлен 08.01.2011Описание предметной области, определение функциональных требований к системе и построение диаграммы потока данных. Построение модели "сущность-связь", описание сущностей и атрибутов модели. Построение реляционной базы данных и описание ее таблицы.
курсовая работа [624,5 K], добавлен 30.05.2019
