Система сбора и анализа первичных данных - 1

Постановка задачи, сбор и хранение данных

Предложено типовое решение для системы сбора, хранения и анализа первичных данных ручного ввода на основе IBM Forms для ручного ввода форм и IBM InfoSphere Warehouse для хранения данных. Анализ собранных данных с использованием аналитических средств IBM InfoSphere Warehouse и IBM Cognos рассмотрен во второй части статьи 1 . Предлагаемый подход может быть использован в качестве основы разнообразных решений для разных отраслей и предприятий.

Сабир Асадуллаев, исполнительный архитектор SWG IBM EE/A, IBM

Photo sabirСабир Асадуллаев более 25 лет работает в информационных технологиях. Является специалистом в области проектирования хранилищ данных и ведения корпоративных метаданных. Руководил ИТ проектами в нефтегазовой отрасли, в банковской сфере, на транспорте, в науке и других областях в Европе и в Северной Америке. Обладает опытом организации коллективной разработки программного обеспечения и создания офиса управления проектами (PMO). Работая в IBM c 2006г, подготовил ряд ключевых архитектурных решений для крупнейших клиентов IBM. Окончил физический факультет МГУ (1979), кандидат физ-мат. наук (1986), сертифицированный руководитель проектов (2001), лучший архитектор CEMAAS IBM (2006), сертифицированный архитектор корпоративных решений IBM (2008), исполнительный архитектор (2010). Автор более 30 публикаций в ИТ, астрономии и биологии.



17.02.2011

Введение

Компания-дистрибутор закупает товар и распределяет его по своим региональным потребителям. Для планирования новых закупок необходима информация с мест об остатках товара. Данные вводятся на местах вручную. Это приводит к тому, что, несмотря на обучения, распоряжения, напоминания, данные вводятся не так, как ожидалось. В результате, в центральном офисе компании целый отдел выверяет данные, перезваниваясь с региональными представителями.

Транспортная компания располагает обширным парком грузовых перевозочных средств. Несмотря на наличие автоматической диагностики, данные о техническом состоянии подвижного состава ведутся вручную на бумажных бланках и затем заносятся в компьютер. За время между обнаружением неисправности и занесением с бумажного носителя в информационную систему возможна случайная или намеренная подача неисправного транспортного средства под погрузку. Штрафы, предусмотренные за подобную ситуацию, ведут к убыткам транспортной компании и обеспечивают фирму - отгрузчик прибылью, заработанной не вполне корректным образом.

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

Список подобных примеров может быть продолжен. Например, злоумышленник может угнать автомобиль в одном регионе, совершить ограбление во втором, незаконно приобрести оружие в третьем, и его преступления могут быть не объединены в одно дело из-за мелких ошибок при регистрации инцидентов. Или предприниматель может проживать в одном регионе, открыть предприятие в другом, а налоги платить в третьем.

Эти примеры объединяют одинаковые функциональные требования:

  • необходим сбор первичных, статистических, или отчетных показателей с удаленных рабочих мест;
  • необходима проверка данных на рабочем месте до отправки в центр.
  • собранные показатели должны выверяться и храниться в течение времени, определенного нормативными документами;
  • для выявления закономерностей и принятия управленческих решений необходимо выполнение аналитических вычислений на основе собранной статистики;
  • для оценки состояния дел в регионах необходимо формирование управленческой отчетности.

В данной статье мы рассмотрим типовое решение для системы сбора, хранения и анализа первичных данных ручного ввода. Несмотря на очевидные ограничения, этот подход может быть использован в качестве основы самых разных решений для различных отраслей и предприятий.

Требования к системе

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

Информационные системы, эксплуатируемые в регионах, являются внешними по отношению к разрабатываемой системе «Сбор и анализ первичных данных» и не взаимодействуют с ней.

Требуемая информация должна вводиться вручную с помощью экранных форм. Формы должны максимально точно отражать существующие и утвержденные бумажные формы сбора данных. Должна быть возможность проверки ошибок заполнения до отсылки формы.

Заполненная форма из региона всегда отправляется в центральный офис. В случае выявления ошибки в заполнении, форма отправляется повторно целиком.

Заполненную форму не требуется сохранять целиком для аудита или следования требованиям законодательства. Сохраняются только данные, содержащиеся в полях формы. Поэтому нет необходимости отправлять в центр всю форму, можно отсылать только извлеченные из нее данные.

Внутренними потребителями управленческой отчетности являются сотрудники и руководители компании. Управленческая отчетность предоставляется в электронной и бумажной формах.

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

Количество пользователей в каждом регионе ограничено одним пользователем (оператор ввода данных) в каждый момент времени (то есть, для функционирования системы в каждом регионе достаточно одно рабочее место). Количество регионов примем равным 1000.

Количество пользователей системы в центральном офисе компании на текущий момент - до 100 аналитиков.

Количество утвержденных входных форм: 10 ежедневных форм по 100 полей каждая. Для оценки потоков данных можно ограничиться следующими приблизительными значениями. Как показывает опыт, в среднем на одно поле приходится 3 – 5 Кбайт форм.

Таким образом, размер одной формы можно оценить в 300 - 500 Кбайт, а ежедневный поток с одного рабочего места составляет 3 - 5 Мбайт/сут. Учитывая, что формы заполняются вручную в течение рабочего дня, минимально необходимая пропускная способность канала связи должна обеспечивать передачу примерно 1 формы в час, то есть, около 1 кбит/с. Суммарный ежедневный поток от регионов составляет 3 – 5 Гбайт/сут. Пиковый часовой объем передачи данных в случае недостаточной полосы пропускания может быть снижен за счет разности в часовых поясах регионов и утвержденного графика передачи данных.

Длительность хранения данных для оперативного доступа составляет 5 лет, после чего данные переносятся в архив. Продолжительность хранения информации в архивах 50 лет.

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

Задачи проекта

В процессе выполнения проекта должны быть решены следующие задачи:

  • Разработка экранных форм для утвержденных форм
  • Разработка экранных форм для новых форм
  • Разработка средств хранения детализированных показателей
  • Разработка аналитических средств
  • Разработка средств отчетности и визуализации
  • Обеспечение информационной безопасности
  • Резервное копирование данных
  • Архивирование информации
  • Журналирование событий в системе

Разработка экранных форм для утвержденных форм

Должны быть разработаны экранные формы, соответствующие утвержденным формам сбора статистических показателей. Должны быть предоставлены возможности ввода форм как в автономном (offline), так и в неавтономном (online) режимах. Основной режим ввода данных – неавтономный (online).

Разработка экранных форм для новых форм

Должны быть предоставлены средства простой, интуитивно понятной разработки новых форм сбора статистических показателей для доработки системы находящейся в промышленной эксплуатации. Потребности в упрощенных средствах разработки новых форм нет, можно пользоваться стандартными средствами.

Возможна разработка новых форм как с привлечением сторонних организация, так и собственными силами Заказчика. Заказчик должен быть полностью независимым от партнера, иметь возможность сменить партнера или предоставить ему прямой доступ к механизмам разработки и тестирования форм и приложений.

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

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

Хранилище данных должно быть ориентировано на хранение не отдельных форм, а показателей, из которых формы должны составляться. Поэтому показатели форм должны быть взаимно согласованы. По сути, формы должны составляться из показателей.

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

Для данных длительного хранения можно проводить их агрегацию в более масштабные показатели. К примеру, для данных, срок хранения которых превышает 5 лет, объединять показатели по 5 лет, для данных, срок хранения которых превышает год, объединять показатели по году, для данных со сроком хранения меньше года – оставлять показатели по месяцу.

Разработка аналитических средств

Средства аналитических вычислений на основе собранной статистики должны предоставлять следующие возможности:

  • статистический анализ, причем достаточно простой. Например, расчет эффективности использования различных ресурсов;
  • сценарные и прогнозные расчеты.

Средства аналитических вычислений на основе собранной статистики должны предоставлять следующие возможности:

Разработка средств отчетности и визуализации

Средства отчетности и визуализации должны обеспечивать

  • Генерацию экранных отчетов
  • Генерацию бумажных отчетов
  • Визуализацию отчетов в графической форме через Веб-интерфейс (браузер),
  • Группирование графиков в необходимый набор (панель управления - dashboard),

Обеспечение информационной безопасности

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

Резервное копирование данных

Резервное копирование должно выполняться встроенными средствами баз данных и хранилищ данных.

Архивирование информации

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

Журналирование событий в системе

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

Критерии успеха

Экранные формы сбора информации должны соответствовать утвержденному перечню форм ввода информации. Выполняемые процедуры должны следовать согласованному с Заказчиком бизнес-процессу сбора, обработки, хранения и предоставления информации.

Электронные и бумажные формы вывода информации должны соответствовать утвержденному перечню форм управленческой отчетности.

Должно быть обеспечено журналирование процессов ввода информации для отслеживания своевременности предоставления отчетности.

Достоверность информации должна быть не хуже качества собранных данных.

Архитектуры системы сбора, хранения и анализа данных

В данной работе мы рассматриваем типовую задачу без учета специфических требований различных проектов. Поэтому предлагаемая архитектура основана на максимально простой конфигурации программного обеспечения. Сбор данных осуществляется с помощью IBM Lotus Forms. Хранение, анализ и предоставление отчетов реализованы на IBM InfoSphere Warehouse. Для управления корпоративной эффективностью и интерпретации данных необходимо включение в архитектуру продукта Cognos.

Разделение подсистем на ввод данных, их сбор, хранение и анализ позволяет строить различные архитектуры в зависимости от потребностей задачи и требований к корпоративной инфраструктуре. На Рис.1. представлена централизованная архитектура системы сбора, хранения и анализа данных, которая предполагает, что ввод данных может осуществляться удаленно, а все серверы сбора данных Lotus Forms, хранения данных InfoSphere Warehouse и анализа и интерпретации данных Cognos установлены в едином центре обработки данных. Аналитики могут работать как локально, так и дистанционно, благодаря тому, что Cognos предоставляет Веб-интерфейс для подготовки и выполнения аналитических расчетов.

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

Большой объеме произвольных (ad hoc) запросов при выполнении аналитических работ может потребовать создания распределенной инфраструктуры серверов Cognos. В этом случае данные из централизованного хранилища могут заблаговременно передаваться в региональные центры, где размещены серверы Cognos. Такая архитектура обеспечивает приемлемое время отклика и высокую производительность выполнения аналитических работ на местах, даже при отсутствии высокоскоростных каналов связи.

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

Рис. 1. Централизованная архитектура системы сбора, хранения и анализа данных.
Централизованная архитектура системы сбора, хранения и анализа данных.

Посмотреть в увеличенном варианте.

Сбор данных

Lotus Forms - это набор продуктов, который позволяет организациям использовать электронные формы для ручного ввода данных и передавать собранные данные в другие системы 2. Сервер приложений Lotus Forms может быть в дальнейшем интегрирован с репозиториями данных (например, IBM DB2, Oracle, MS SQL Server), различными системами документооборота и с репозиториями документов (например, IBM File Net).

Архитектура сбора первичных данных на основе Lotus Forms представлена на Рис. 2.

Рис. 2. Сбор первичных данных на основе Lotus Forms
Сбор первичных данных на основе Lotus Forms

Разработчик форм, используя продукт Lotus Forms Designer, готовит формы для ввода данных. Формы сохраняются в репозитории форм в формате XFDL 3, 4, который является утвержденным стандартом W3C.

Разработчик приложений разрабатывает логику приложений Forms, сервлеты Webform Server Servlet и картирование для Transformation Extender (TX), который ставит в соответствие поля форм и значения в базе данных.

Транслятор переводит формы из формата XFDL на язык HTML и JavaScript для пользователей, использующих тонкий клиент (браузер).

Пользователи, у которых установлен Lotus Form Viewer (толстый клиент) могут работать с формами в формате XFDL, минуя трансляцию на HTML.

Пользователи в регионах вводят данные с помощью Lotus Form Viewer или браузера. Данные могут проходить несколько этапов верификации:

  • на компьютере пользователя во время подготовки формы с использованием логики встроенной в форму
  • на сервере Lotus Forms с помощью логики приложений
  • при загрузке данных в базу данных.

Данные передаются в базу данных InfoSphere Warehouse по протоколам CLI, ODBC, JDBC.

Хранение данных

В состав IBM InfoSphere Warehouse Enterprise Edition 4, 5 входят следующие продукты:

  • InfoSphere Warehouse Design Studio, который включает IBM Data Server Developer Workbench - подмножество компонент IBM Rational Data Architect.
  • InfoSphere Warehouse SQL Warehousing Tool
  • InfoSphere Warehouse Administration Console, являющийся частью Integrated Solutions Console.
  • DB2 Enterprise Server Edition для Linux, UNIX и Windows
  • InfoSphere Warehouse Cubing Services
  • DB2 Query Patroller
  • InfoSphere Warehouse Intelligent Miner
  • IBM Alphablox и сопутствующая документация
  • WebSphere Application Server

Архитектура хранения данных в IBM InfoSphere Warehouse представлена на Рис. 3.

Design Studio предоставляет общую среду проектирования для создания физических моделей, кубов OLAP и моделей интеллектуального анализа данных, проектирования потоков данных и управляющих потоков SQL, а также для аналитических приложений Alphablox Blox Builder. Design Studio разработан на платформе Eclipse.

Разработчик приложений с помощью InfoSphere Warehouse Design Studio разрабатывает и размещает на сервере приложения, обеспечивающие обработку данных в соответствии с требуемой бизнес - логикой.

The SQL Warehousing Tool (SQW) – это графический инструмент, который, заменяя ручное кодирование SQL, генерирует SQL код для поддержки и администрирования хранилища данных. На основе визуальных потоков операторов, смоделированных в Design Studio, SQW автоматически создает SQL код, специфичный для DB2. Интеграция SQW с IBM WebSphere DataStage расширяет возможности создания аналитических систем на базе DB2.

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

Рис.3. Хранение данных в IBM InfoSphere Warehouse.
Хранение данных в IBM InfoSphere Warehouse .

Посмотреть в увеличенном варианте.

Администратор использует Administration Console, которая является приложением WebSphere, для размещения и управления приложениями, созданными в Design Studio. Administration Console позволяет:

  • создавать и управлять ресурсами базы данных, просматривать журналы и управлять процессами SQW.
  • Исполнять и контролировать работу приложений БД, просматривать историю их развертывания и статистику исполнений.
  • Управлять сервисами кубов, импортировать и экспортировать кубы и их модели, а также исполнять OLAP Metadata Optimization Advisor.
  • Обеспечивать работу БД для интеллектуального анализа данных, загружать, импортировать и экспортировать модели интеллектуального анализа.

DB2, IBM Alphablox, и WebSphere Application Server располагают собственными средствами администрирования, но оно может быть исполнено из той же Integrated Solutions Console.

Администратор использует DB2 Query Patroller для динамического управления потоками запросов к базе данных DB2. Query Patroller позволяет регулировать нагрузку на базу данных так, что короткие запросы, или запросы с высоким приоритетом, будут исполняться в первую очередь, обеспечивая эффективное использование ресурсов. Кроме того, администратор может собирать и анализировать информацию о выполненных запросах для определения временных закономерностей, часто используемых таблиц и индексов, а также ресурсоемких приложений.

Заключение

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

Варианты решений для анализа данных с помощью средств IBM InfoSphere Warehouse и IBM Cognos BI будет выполнен во второй части статьи.

Автор благодарит М.Баринштейна, В.Иванова, М.Озерову, Д.Савустьяна, А.Сона и Е.Фищукову за полезные обсуждения.

Литература

1 Асадуллаев С. “Система сбора и анализа первичных данных – II. Анализ первичных данных”, 2011, developerWorks http://www.ibm.com/developerworks/ru/library/sabir/warehouse-2/index.html

2 IBM Forms documentation, 09.07.2009. https://www.ibm.com/developerworks/lotus/documentation/forms/

3 Boyer J., Bray T., Gordon M. “Extensible Forms Description Language (XFDL) 4.0”. 1998, , http://www.w3.org/TR/1998/NOTE-XFDL-19980902

4 IBM, “XFDL 8 Specification”, 2010,http://www-10.lotus.com/ldd/lfwiki.nsf/xpViewCategories.xsp?lookupName=XFDL%208%20Specification

5 IBM, “InfoSphere Warehouse overview 9.7”, 2010, http://publib.boulder.ibm.com/infocenter/idm/v2r2/index.jsp?topic=/com.ibm.isw.release.doc/helpindex_isw.html

6 IBM DB2 Database for Linux, UNIX, and Windows Information Center”, 2011,http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.doc/welcome.html

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=627225
ArticleTitle=Система сбора и анализа первичных данных - 1
publish-date=02172011