CC BY
60II. ИНФОРМАЦИОННЫЕ СИСТЕМЫ. АВТОМАТИЗАЦИЯ И СИСТЕМЫ УПРАВЛЕНИЯ
УДК 004.891.2 И.В. Ананченко1, А.В. Гайков2, А.А. Мусаев3
Введение
Современные технологии анализа данных, прогнозирования и поддержки принятия решений (DSS, decision support systems) ориентированы на обработку больших и сверхбольших (терабайты) массивов данных, полученных в процессе мониторинга изучаемых или управляемых предметных сред. При этом исходные массивы формируются на основе данных, хранящихся в распределенных источниках, доступных через глобальную сеть Internet и/или локальные компьютерные сети. Указанные источники информации содержат разнородные данные, представляемые различными форматами, структурами и реализуемыми на разнотипных платформах.
Основными факторами разнородности данных и их источников являются:
- различные типы данных (логический, целый, вещественный, объектный и др.);
- различная природа данных (числовые массивы, тексты, медиа данные);
- различные типы (модели) баз данных (БД) - реляционные, иерархические, объектно-ориентированные, сетевые, многомерные и т.п.;
- различные форматы представления данных;
- различия в степени распределенности систем хранения данных;
- различной природы данных (например, тексты, изображения, сигналы);
- различная степень достоверности и точности данных, измеряемых в различных масштабах и единицах измерения;
ТЕХНОЛОГИИ СЛИЯНИЯ ГЕТЕРОГЕННОЙ ИНФОРМАЦИИ ИЗ РАЗНОРОДНЫХ ИСТОЧНИКОВ (DATA FUSION)
Санкт-Петербургский государственный технологический институт (технический университет) 190013, Санкт-Петербург, Московский пр., д. 26
Настоящая статья представляет собой краткий обзор технологии Data Fusion, ориентированной на решения задач объединения больших массивов разнородной информации, хранящейся в различных источниках. Особое внимание уделено сбору данных, доступных через глобальную сеть Интернет и/или локальные компьютерные сети. Приведен пример практичсекой реализации технологии Data Fusion для задачи сбора данных из сетевых архивов.
Ключевые слова: базы данных, хранилища данных, слияние данных, гетерогенная информация, разнородные источники.
- различная степень и форма структурированности данных и т.п.
Главной задачей технологии слияния данных (Data Fusion) является объединение данных из разных источников в интересах решения последующих содержательных задач: принятие решений, классификация, определение состояния объектов, оценка ситуации и т.д.
Среди собственных задач, связанных с объединением данных, наиболее значимыми являются:
- создания и развития метамоделей распределенных источников данных;
- создания и развития моделей объединения решений;
- построения и упорядочивания архитектуры
данных.
Концептуальные вопросы слияния данных из гетерогенных источников
В соответствии с общепринятой точкой зрения, процесс слияния данных и информации - это многоуровневый процесс, включающий в себя пять базовых уровней [1-3]:
- нулевой уровень - уровень объединения сигналов датчиков, предназначенный для получения данных, указывающих на семантически понятные и интерпретируемые атрибуты объектов и участвующих в приложениях выполняемого исследования;
- первый уровень - уровень "Data Fusion Level", направлен на обработку данных нулевого уровня с целью
1 Гайков Андрей Владимирович, канд. техн. наук, доцент каф. системного анализа, заместитель декана ф-та информационных технологий и управления, e-mail: av489@yandex.ru
2 Ананченко Игорь Викторович, канд. техн. наук, доцент каф. системного анализа, e-mail: aiv123@webmail.ru
3 Мусаев Александр Азерович, д-р техн. наук, профессор каф. системного анализа, декан ф-та информационных технологий и управления, e-mail: amusaev@technolog.edu.ru
Дата поступления - 21 декабря 2012 года
принятия решения по классам рассматриваемых объектов и состояниям данных объектов;
- второй уровень - уровень "Information Fusion", предназначенный для оценки ситуации, включающий в себя уровни нулевой и первый. Используется для оценки ситуационного взаимодействия объектов, рассматриваемых как единое целое.
- третий уровень - уровень оценки взаимодействия ("Impact Assessment"), предназначен для выполнения антагонистической оценки, на основе предсказания развития ситуации;
- четвертый уровень - уровень обратных связей, оценивающий возможность использования обратных связей в рассматриваемой системе;
- пятый уровень - верхний уровень, уровень человеко-машинного взаимодействия, реализующий возможность корректирующих действий оператора, направленных на управление системой.
Анализ публикаций за прошедшие годы показал, что программные разработки в области Data Fusion сосредоточены, главным образом, на вопросах слияния данных, представленных цифровыми изображениями и массивами данных [4-6].
В настоящее время интерес к Data Fusion возрастает. В практическом плане увеличивается число комплексных программно-аппаратных решений. В центре внимания находится решение различных ситуативных прикладных задач.
В качестве примера применения технологии Data Fusion можно назвать использование специализированных датчиков сбора разнородной информации.
Важными сферами применения технологии слияния разнородных данных могут служить:
- сбор гетерогенных данных для обнаружения вторжений в компьютерные сети;
- анализ и прогнозирование возникновения и динамики развития естественных природных и искусственных техногенных катастроф;
- систем анализа биржевых котировок, выявление несогласованности данных, поступающих от разных дилинговых центров;
- консолидация и анализ данных, поступающих с систем видеонаблюдения и телеметрии;
- военные разработки и системы двойного назначения, например, слияние и обработка данных для нейронной сети, получающей информацию от этих различных датчиков и позволяющей делать выводы о присутствии и идентификации биологических объектов;
- навигационные робототехнические системы, например, обработка информации о расстоянии от объектов вокруг робота и форм поверхностей объектов окружающей среды; объединяя эти данные, робот может получить детализированную информацию о среде погружения и принять оптимальное решение о перемещении в ней;
- информационная система «Умный дом», как средство обеспечения безопасности, экономии и комфорта; консолидируются и обрабатываются данные от звуковых датчиков, видеокамер, ультразвуковых датчиков, температурных датчиков, датчиков дыма, вибрационных и инфракрасных датчиков.
Разработка технологии и программной реализации консолидации гетерогенной информации из различных источников требует получения ответов на следующие вопросы:
- каким образом может быть решена проблема слияния данных, полученных из распределенных источников, содержащих гетерогенные данные;
- каким образом можно обеспечить однозначное понимание сообщений, которыми обмениваются агенты гетерогенной системы слияния данных;
- как может быть решена проблема идентификации данных об одном и том же объекте, представленном фрагментами в различных БД;
- каким образом можно справиться с разнообразием шкал измерения и структур представления данных в различных источниках;
- каким образом решается задача распределенного обучения, в частности, каким образом организуется слияние данных, полученных на основе локальных источников данных, использующих различные данные и методы классификации;
- какова архитектура системы слияния данных, и каким образом целесообразно распределить различные задачи между ее компонентами?
С учетом архитектурной составляющей в широком смысле в постановке задачи слияния данных можно выделить три основные задачи, имеющие большое значение:
первая задача - развитие метамодели распределенных хранилищ данных;
вторая задача - развитие метамодели объединяющихся решений, произведенных на основе особых хранилищ данных;
третья задача - собственно проблема архитектуры данных.
Первые две задачи решаемы, если остановиться на полном развитии распределенной онтологии приложения, играющего основную роль в эффективном решении многих проблем, вызванных разнородностью и распределением данных. В свою очередь, связанное с онтологией решение сильно коррелирует с архитектурой соответствующего программного обеспечения [2, 7, 8].
Системная архитектура определяет связь слияния данных с системой в целом. Для достижения выполнения всех требований и повышения уровня доступности данных, необходимо объединить в сеть, как службы поставщиков источников данных, так и службы потребителей данных. Разработку приложений можно разделить на несколько объединенных модулей.
Слияние данных и модулей решений
Для выявления изменений в окружающей среде и обеспечения динамической доступности ресурсов, система, основанная на интеграции с сетью, использует три типа компонентов (компоненты уровня сети, компоненты среднего уровня и компоненты приложения). Система должна адаптироваться к доступности датчиков и им соответствующих сигналов, также система должна приспособиться непосредственно к изменениям в измерениях.
На рисунке 1 приведена блок-схема системы: датчики (поставщики данных) и приложение (в этом случае потребитель службы), узлы сети, средний уровень -программное обеспечение, соединяющее датчики с приложением через сеть.
Приложение включает в себя два интегрированных модуля: модуль слияния данных и модуль принятия решения. Приложение посылает свои требования в средний уровень, который, в свою очередь, посылают данные о датчике в приложение. Затем анализируется архитектура слияния данных и модуля решения для рассматриваемой системы.
Таксономия слияния данных выделяет основные типы слияния данных: данные, переменные и объединение данных и переменных. Основная технологическая идея слияния - это деление на уровни, разделяющие данные и переменные.
Данные - это информация о каких-то параметрах, полученная от датчика или другого источника. Уровень переменных определяется анализом данных путем выделения функциональных признаков.
Возможно получение одной или более переменных на основе одного типа данных. Например, анализируя изображения (необработанные данные), приложение может определить, содержит ли оно фигуру человека (переменная представляет человека), животного (переменная представляет животное) или другого объекта (переменная представляет объект). Решение этих задач может быть промежуточным шагом или основной целью приложения.
Определение переменной достигается использованием алгоритма анализа данных или вероятностного подхода. Примером может быть применение нейронной сети, собирающей входные данные и предлагающей на их основе вероятностную оценку содержания анализируемого изображения (например, человек, животное или другой объект).
Рисунок 1. Связь приложения с сетью и средним уровнем.
Таким образом, решение задачи выполняется на трех уровнях:
- на уровне процесса слияния данных перед их анализом (на уровне данных);
- на среднем уровне, когда данные анализируются (уровень переменных);
- на уровне комбинирования необработанных данных и переменных (смешанный уровень).
SSIS - пример программного инструментария для слияния данных
Как уже отмечалось, хранение данные в разнородных хранилищах данных создает серьезную проблему в процессе извлечения информации из разных источников и слияния ее в единый согласованный набор данных. Причины возникновения такой ситуации могут быть различными, отметим некоторые из них:
- многие организации сохраняют неоперативные данные в форме архивов в традиционных системах хранения. Архивные данные могут быть не актуальными для текущих операций, но могут представлять высокую ценность, например, для анализа динамики поведения трендов (когда для их определения необходимы данные за длительный исторический период);
- использование главными офисами и филиалами организаций разных технологий хранения и обработки оперативных данных;
- одни и те же данные могут храниться в различных БД, использующих разные схемы их представления.
В качестве специального инструмента консолидации и обработки данных, может быть использован аналитический модуль СУБД SQL Server 2005/2008/2008 R2/2012: SQL Server Integration Services (SSIS). Данный программный продукт предлагает инструментарий для решения типовых задач, поддерживается обработка контейнеров, преобразование и обработку данных бизнес-
логики приложений. Используя SSIS, можно решать сложные проблемы ETL, бизнес-аналитики, управления базами данных, проблемы копирования объектов SQL Server с одного экземпляра СУБД в другой.
Службы SSIS могут подключаться к множественным типам источников данных, включая разнообразные источники данных одного пакета. Осуществляется поддержка различных поставщиков данных, в том числе: NET, OLE DB, драйверы ODBC, плоские файлы, файлы Excel, проекты служб Analysis Services и др. Также реализована поддержка извлечения данных из таблиц и представлений реляционных БД.
Как правило, данные видоизменяются с помощью преобразований, содержащихся в службах Integration Services. Службы Integration Services содержат назначения для загрузки данных в плоские файлы, необработанные файлы, а также реляционные БД. Данные также могут быть загружены в набор записей, хранимых в памяти, и быть доступны для других элементов пакета. Службы SSIS поддерживают массовую загрузку данных из разнородных файлов (в том числе из плоских файлов). Если источник данных для таблицы измерения хранится в нескольких источниках данных, то пакет SSIS может объединить данные в один набор и загрузить таблицу измерения в течение одного процесса, вместо использования отдельных процессов для каждого источника данных. Обновление данных в хранилищах и витринах данных является сложной задачей, так как оба типа хранения данных обычно содержат медленно изменяющиеся измерения, которыми сложно управлять с помощью преобразования данных.
Служба SSIS поддерживает задачи преобразования данных и может обрабатывать информационные кубы и измерения служб Analysis Services. Автоматическая обработка кубов и измерений помогает предоставлять текущие данные для пользователей обеих сред: пользователям, которые получают данные из кубов и измерений, и пользователям, которые получают доступ к данным в реляционной БД. Осуществляется поддержка вычисляемых функций перед загрузкой данных в выбранное назначение.
Для хранилищ и витрин данных, содержащих статистические данные и пакет служб, SSIS поддерживает работу с такими функциями, как SUM, AVERAGE, COUNT и др. Преобразование служб SSIS позволяет консолидировать реляционные БД или преобразовать их в менее нормализованный формат, являющийся более совместимым с табличными структурами хранения данных.
Пакет служб SSIS позволяет выполнять очистку данных путем замены значений в столбцах на значения ссылочной таблицы, используя уточняющие запросы или нечеткие уточняющие запросы для поиска значений в ссылочной таблице. Возможна работа с использованием элементов нечеткой логики. Например, пакет сначала пытается выполнить поиск названия продукта в ссылочной таблице, используя значение первичного ключа. Если этот поиск не смог вернуть название продукта, то пакет повторяет попытку с применением нестрогого соответствия наименования продукта. Можно выполнять очистку данных с помощью группирования похожих значений набора данных. Эта возможность актуальна при распознавании записей, которые могут быть дубликатами и поэтому не должны быть включены в БД без дальнейшей оценки. Например, сравнивая адреса в списке записей клиентов, можно найти несколько дублирующих записей.
Процесс преобразования данных требует от встроенной логики динамичного реагирования на данные для обработки и доступа. Данным может потребоваться суммирование, преобразование, а также распространение на основе их значений. Процесс может также отвергнуть данные на основе оценки значений столбцов.
Для выполнения этих требований логикой пакета должны поддерживаться следующие типы задач:
- слияние данных из нескольких источников;
- вычисление данных и применение преобразований;
- разбиение данных на несколько наборов на основе значений данных;
- применение статистических выражений к различным подмножествам набора данных;
- загрузка подмножеств данных к различным или нескольким назначениям.
Контейнеры поддерживают повторение потоков операций с помощью перечисления файлов или объектов, а также оценки выражений. Преобразования могут производить оценку выражений и затем, в зависимости от результата, посылать строки набора данных по различным назначениям. После того, как данные разделены, пакет может применить различные преобразования к каждому подмножеству набора данных. Например, выражение может произвести оценку данных столбца, добавить данные продаж за соответствующий период и затем сохранить только сводные данные.
Поддерживается возможность отправки данные нескольким пунктам назначения, различные преобразования одних и тех же данных. Например, один набор преобразований может обобщать данные, а другой может одновременно дополнять их данными из других источников, производя поиск значений в ссылочных таблицах.
Администрирование среды базы данных OLTP (online treatment processing) или OLAP (online analytical processing) часто включает в себя процесс загрузки данных. Службы интеграции содержат несколько задач, облегчающих массовую загрузку данных. Пакет служб интеграции позволяет запускать другие пакеты.
Решение преобразования данных, включающее множество административных функций, может быть разделено на несколько пакетов для облегчения управления и повторного использования пакетов. Пакет, обрабатывающий данные, может использовать циклы для перечисления серверов и выполнения одинаковых функций на нескольких компьютерах. Возможен запуск пакетов служб интеграции по расписанию с использованием заданий агента SQL Server.
Архитектура типового приложения обработки и консолидации данных на примере архитектуры SSIS
Типовая архитектура приложения обработки и консолидации данных, состоящая из различных компонентов, представлена на рисунке 2.
Среда выполнения служб приложения сохраняет макет пакетов, выполняет пакеты и обеспечивает поддержку ведения журналов, точек останова, настройки, соединений и транзакций. Исполняемые объекты времени выполнения служб приложения - это пакеты, контейнеры, задачи и обработчики событий, содержащиеся в службах приложения. К числу исполняемых объектов среды выполнения принадлежат также разрабатываемые пользовательские задачи.
Задача потока данных инкапсулирует подсистему обработки потока данных. Подсистема обработки потока данных предоставляет размещенные в памяти буферы для перемещения данных из источника на целевой объект и вызова средств для извлечения данных из файлов и реляционных БД. Подсистема обработки потока данных также управляет преобразованиями, которые изменяют данные, и назначениями, которые загружают данные или делают их доступными для других процессов.
Компонентами потока данных служб приложения являются источники, преобразования и назначения, включенные в службы приложения. Можно также добавлять к потоку данных пользовательские компоненты.
Модель объектов служб приложения включает управляемые прикладные программные интерфейсы (например, API, COM и GUI) для создания пользовательских компонентов, используемых в пакетах, или пользовательских приложений для создания, загрузки, выполнения пакетов и управления ими. Разработчик может написать пользовательские приложения, пользовательские задачи или преобразования, применяя любой язык, совместимый со средой CLR (Common Language Runtime).
Службы приложения могут включать дополнительные средства, мастера и программы командной строки для выполнения пакетов служб приложения и управления ими.
Пакет представляет собой объект, который реализует функциональность служб SSIS по извлечению, преобразованию и загрузке данных, и включает в себя следующие компоненты:
- элементы потока управления - эти обязательные элементы выполняют различные функции, поддерживают структуру и управляют порядком выполнения элементов. Основными элементами потока управления являются задачи, контейнеры и управления очередностью. В пакете должен быть, по крайней мере, один элемент потока управления;
- элементы потока данных - эти необязательные элементы извлекают, изменяют и загружают данные в источники данных. Основными элементами потока данных являются источники, преобразования и назначения. Присутствие каких-либо элементов потока данных в пакете необязательно.
Пакет состоит из потока управления, а также может включать один или более потоков данных. Службы SSIS предоставляют три различных типа элементов потока управления:
контейнеры, которые обеспечивают структуры в
пакетах;
задачи, которые обеспечивают функциональность;
элементы управления очередностью, соединяющие выполняемые компоненты, контейнеры и задачи в упорядоченный поток управления.
На рисунке 3 приведен пример потока управления, который имеет один контейнер и шесть задач. Пять задач пакетного уровня и одна задача уровня контейнера. Задача находится в контейнере.
Рисунок 2. Типовая архитектура приложения.
Рисунок 3. Типовая схема потока управления.
Архитектура служб приложения поддерживает работу с вложенными е контейнерами. Поток управления может включать множество уровней вложенных контейнеров. Таким образом, пакет может содержать контейнер, например контейнер "цикл по каждому элементу”, который в свою очередь может содержать другой контейнер "цикл по каждому элементу" и т.д.
Контейнеры обеспечивают структуру в пакетах и службах для задач в потоке управления. Приложение содержит следующие типы контейнеров для группирования задач и внедрения повторяющихся потоков управления:
- контейнер "цикл по каждому элементу" перечисляет коллекцию данных и повторяет этот поток управления для каждого члена коллекции;
- задачи подготовки данных копируют файлы и каталоги, загружают файлы и данные, сохраняют данные, возвращенные при помощи веб-методов, или работают с ХМЬдокументами;
- задачи технологического процесса связываются с другими процессами для загрузки пакетов или программ, отправляют и получают сообщения между пакетами, отправляют сообщения электронной почты, считывают данные инструментария управления Windows ^М1) или наблюдают за событиями WMI;
- задачи службы приложения позволяют получить доступ, копировать, вставлять, удалять или изменять объекты или данные различных СУБД.
- задачи служб приложения позволяют создать, изменить, удалить или обработать объекты служб приложения;
- задачи сценариев расширяют функциональные возможности пакета посредством использования пользовательских сценариев;
- задачи обслуживания выполняют административные функции: резервное копирование и сжатие баз данных различных СУБД, восстановление и перестройка индексов, а также выполнение заданий агента сервера базы данных.
Службы приложения, например, ББК, могут предоставлять различные типы компонентов потока данных: источники, преобразования и целевые объекты. Например, источники извлекают данные из хранилищ, таких как таблицы и представления реляционных БД, файлы и БД служб системной аналитики (например, ББДБ). Преобразования изменяют, объединяют и очищают данные.
Целевые объекты загружают данные в хранилища или создают наборы данных в памяти. Кроме того, службы приложения предоставляют пути, соединяющие выход одного компонента с входом другого. Пути определяют последовательность компонентов и дают возможность добавлять заметки к потоку данных или просматривать источник столбца.
На рисунке 4 приведен пример потока данных с источником, преобразованием с одним входом и одним выходом и целевым объектом. На диаграмме присутствуют входы, выходы, выходы ошибок, а также входные, выходные и внешние столбцы.
ражение не примет значение FALSE;
- контейнер последовательности позволяет определить подмножества потока управления и управлять задачами и контейнерами как модулями.
Пакет служб приложения состоит из одной или более задач. Если в пакете несколько задач, они связаны и упорядочены в потоке управления с помощью управления очередностью. Можно также создавать пользовательские задачи на языке программирования, поддерживающем COM, например на Visual Basic, или на языке программирования для платформы .NET, например на C#.
Конструктор служб, например, графическое средство служб SSlS для работы с пакетами - предоставляет область конструктора для создания потока управления пакета и специальные редакторы для настройки задач. Можно также использовать объектную модель служб SSIS для программного создания пакетов.
Службы приложения могут включать в себя следующие типы задач для выполнения разнообразных функций:
- задача потока данных определяет и выполняет потоки данных, которые извлекают данные, применяют преобразования и загружают данные;
о -ты эв Файлы СУБД
Источник
Выход
Вывод ошибок
Вход 1
Преобразование
Выход Вывод ошибок
Вход
Назначение
Вывод ошибок
Входные столбцы Назначение
Входные столбцы Назначение
Входные столбцы Назначение
Рисунок 4. Пример потока данных.
Компонент потока данных обслуживает данные, поступающие из внешнего источника, делая их доступными для других компонентов.
У источника потока данных обычно есть один стандартный выход. В стандартном выходе содержатся
выходные столбцы, которые источник добавляет к потоку данных. Стандартный выход ссылается на внешние столбцы. Внешним называется столбец в источнике. Метаданные внешних столбцов хранят информацию об имени исходного столбца, типе и длине хранящихся в нем данных.
Выход ошибок источника хранит те же столбцы, что и стандартный выход, а также два дополнительных столбца, предоставляющих информацию об ошибках. Объектная модель служб приложения не ограничивает число стандартных выходов и выходов ошибок, которые могут быть связаны с источником.
У большей части источников, включенных в службы приложения (за исключением компонента сценария) имеется один стандартный выход; у многих также есть один выход ошибок. Пользовательские источники могут быть спроектированы так, чтобы содержать несколько выходов ошибок и стандартных выходов. Все выходные столбцы доступны в качестве входных столбцов для следующего компонента потока данных.
Возможности преобразований очень разнообразны. В частности, могут выполняться такие задачи, как обновление, очистка, слияние и распространение данных, сбор статистики о них. Входы и выходы преобразований определяют столбцы входных и выходных данных. В зависимости от выполняемых операций над данными у одних преобразований может быть один вход и несколько выходов, а у других - несколько входов и один выход.
У преобразований также могут быть выходы ошибок, которые предоставляют информацию о произошедших ошибках, и сами данные, вызвавшие ошибку. Например, строковые данные, которые не могут быть преобразованы в целое число. Объектная модель служб ББ1Б не ограничивает число входов, стандартных выходов и выходов ошибок, которые могут быть связаны с преобразованием. Пользовательские преобразования могут реализовывать любое сочетание входов, стандартных выходов и выходов ошибок.
Вход преобразования определяется как один, так и более входных столбцов. Некоторые преобразования служб ББ1Б также могут ссылаться на внешние входные столбцы. Например, вход преобразования включает в себя внешние столбцы. Выходным называется столбец, который добавляется преобразованием в поток данных. Стандартные выходы, и выходы ошибок содержат выходные столбцы. Эти выходные столбцы, в свою очередь, служат входными столбцами для следующего компонента потока данных, другого преобразования или целевого объекта.
Целевым объектом называется компонент потока данных, записывающий данные из потока в указанное хранилище или создающий набор данных в памяти. У целевого объекта служб приложения должен быть, по крайней мере, один вход. Вход содержит входные столбцы, предоставляющие другим компонентам потока данные. Входные столбцы сопоставляются со столбцами целевого объекта. У многих целевых объектов есть также один выход ошибок. Выход ошибок назначения содержит выходные столбцы, которые обычно хранят информацию об ошибках, произошедших во время записи в целевое хранилище данных.
Ошибки могут происходить по разным причинам. Например, столбец может содержать значение ШИ., а целевой столбец этого не допускает.
Объектная модель служб приложения не ограничивает число стандартных входов и выходов ошибок, которые могут быть связаны с целевым объектом, пользовательские назначения могут реализовывать комбинации из нескольких стандартных входов и выходов ошибок.
При создании потока данных в пакете с помощью конструктора служб приложения, метаданные из источни-
ков и целевых объектов копируются во внешние столбцы источников и целевых объектов и играют роль моментального снимка схемы. Когда службы приложения проверяют правильность пакета, конструктор служб приложения сравнивает этот снимок со схемой источника или целевого объекта и в зависимости от изменений сообщает об ошибках и предупреждениях. Проект служб приложения должен поддерживать работу в автономном режиме. При работе в автономном режиме соединения с используемыми пакетом источниками и целевыми объектами не устанавливаются, а метаданные внешних столбцов не обновляются.
У источников данных есть выходы, у целевых объектов - входы, у преобразований есть и входы, и выходы. Кроме того, многие компоненты потока данных могут быть настроены для использования вывода ошибок.
Вход содержит один или более входных столбцов, которые могут ссылаться на внешние столбцы, если компонент потока данных настроен так, чтобы использовать их. Входы могут быть настроены для контроля и управления потоком данных: например, можно определить, что компонент должен прервать нормальный ход работы в ответ на ошибку, или пропускать ошибки, или перенаправлять строки, содержащие ошибки, на вывод ошибок. Можно также задавать описание входа или обновлять имя входа.
Выход содержит один или более выходных столбцов, которые могут ссылаться на внешние столбцы, если компонент потока данных настроен так, чтобы использовать их. Выходы могут предоставлять информацию, полезную при последующей обработке данных.
Например, можно указать, что данные на выходе отсортированы. Можно также задавать описание выхода или обновлять имя выхода. Можно определить, как компонент потока данных будет реагировать на ошибки в каждом входном и выходном столбце. Если во время выполнения произошла ошибка или усечение данных, а компонент потока данных настроен так, чтобы перенаправлять строки, то строки данных, содержащие ошибки, будут отправлены на выход ошибок.
Пути соединяют компоненты потока данных. В конструкторе приложения можно просматривать и изменять свойства путей, просматривать выходные метаданные для начальной точки пути и связывать с путем средства просмотра данных.
Практическое использование технологии Data Fusion на примере сбора данных из сетевых архивов
Рассмотрим практическое использование технологий слияния гетерогенной информации из разнородных источников (Data Fusion) применительно к проблеме сбора данных и оценки качества информации на примере биржевых котировок валютных пар рынка Форекс на выбранных исторических периодах.
В настоящее время для торговли на рынке Форекс широко используется автоматизированная система торговли (АТС). Для функционирования АТС необходимо наличие результатов мониторинга состояния рынка и торговой среды, что является необходимым, но далеко не достаточным условием для формирования эффективных решений. Дело в том, что результаты мониторинга могут либо не содержать сведений (даже косвенных), необходимых для подготовки качественной прогностической оценки состояния рынка, либо отображать их не достаточно корректно. Причины данного несоответствия можно классифицировать по двум группам:
- причины, обусловленные неполнотой или техническим несовершенством процесса мониторинга;
- причины, обусловленные человеческим фактором.
Котировки валютных пар формируются ведущими дилинговыми центрами (ДЦ) и будучи практически одинаковыми на таймфреймах, начиная от минутного и старше, могут отличаться на уровне тиковых (например, секундных) данных. Отличия по котировкам конкретного ДЦ могут достигать максимально нескольких десятков процентов («шпилька») в сравнении с усредненными данными от других ДЦ. Такие выбросы могут быть вызваны техническими причинами или человеческим фактором (недобросовестностью сотрудников ДЦ). Котировки изменяются по своим экономическим и иным законам, содержащим сильные стохастические составляющие, а тренды представляют собой некоторые ментальные представления, определяемые наличием участков знакопостоянства первой производной системной составляющей, выбранной торговой стратегией и ее параметрами. Для данных биржевых котировок актуальны методы очистки исходных данных, полученных в результате мониторинга состояния торгового процесса, и анализа характеристик финансовых потоков, путем выполнения следующих функциональностей:
1. выявление одиночных и групповых пропусков данных (лакун, hiatus) и восстановление пропущенных значений в соответствии с выбранным алгоритмом (технологией) восстановления;
2. выявление и обработка аномальных наблюдений, статистический учет возникновения аномалий, восстановление аномальных значений параметров в соответствии с выбранным алгоритмом (технологией) восстановления;
3. обнаружение скрытых несоответствий (gaps) наблюдений, противоречащих структуре корреляционных взаимосвязей между параметрами ТП, восстановление несоответствующих значений параметров;
4. сглаживание (последовательная фильтрация) рядов наблюдений;
5. выявление мультиколлинеарности в исходных
данных.
Данные по биржевым котировкам могут быть получены по текущему состоянию (тиковые данные) из информационного потока котировок поступающих на торговый терминал (например, терминалы МТ4 или МТ5).
Для оптимальной оценки необходимо решение задачи по одновременному съему тиковой информации по выбранной валютной паре или парам, поступающим на вход 5-10 терминалов работающих с разными ДЦ. Следует учесть, что региональное время разных ДЦ может отличаться, так же как и точность представления данных -использование четырехзначных или пятизначных котировок (число цифр после запятой) и это тоже необходимо учитывать. Исторические данные могут быть получены из архивных файлов котировок (внутренний формат представления данных hst терминалов МТ4 или МТ5), а так же из файлов структуры Excel (.csv, пример записи "2007.04.23,19:30, 1.35730,1.35760,1.35730,1.35750,51"),
таблиц СУБД SQL Server (.mdb) или Access разных версий, а так же могут быть представлены архивными текстовыми файлами плоской структуры с записями вида "<TICKER>,<DTYYYYMMDD>, <TIME>, <OPEN>, <HIGH>, <LOW>, <CLOSE>, <VOL> AUDUSD, 20010102, 230100,
0.5617, 0.5617, 0.5617, 0.5617,4".
Для обработки данных на объектноориентированном языке Паскаль в среде визуальной разработки Delphi была разработана программа, выполняющая консолидацию, анализ, обработку (на рисунке 5 приведен фрагмент интерфейса программы) и загрузку получаемых данных в БД base.mdb, выполняемою под управлением SQL Server 2008 R2 (редакция Enterprise).
Рисунок 5. Фрагмент интерфейса разработанной программы (модуль конвертации данных).
Пример фрагмента кода Delphi для создания
таблицы
ADOCommand1.CommandText:=’CREATE TABLE dbo.'+Edit2.Text+'
(time decimal(14, 0) NOT NULL, otkz nvarchar(15) NULL, kmax nvarchar(15) NULL, kmin nvarchar(15) NULL, zakr nvarchar(15) NULL, vol nvarchar(15) NULL) ON [PRIMARY]’; и определения индекса таблицы ADOCommand1.CommandText:=’ALTER TABLE dbo.'+Edit2.Text+' ADD CONSTRAINT PK_'+Edit2.Text+' PRIMARY KEY CLUSTERED (time) WITH( STATIS-TICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, AL-LOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]’;
Были разработаны модули-пакеты формата dtsx, позволяющие осуществляться загрузку данных из архивов ДЦ с разными форматами представления данных (см. рисунок 6).
Рисунок 6. Пакет ББНдля ввода информации по котировкам с использованием блока преобразования.
В БД содержатся таблицы по ведущим (мажорным) валютным парам с глубиной охвата с 2000 г. на таймфреймах М1, М5, М15, М30, Н1, Н4 и й, а также тиковые данные с 2011 г. Задача сбора данных в целом решена достаточно успешно, продолжается работа над функционалом программы, реализующим сглаживание рядов
наблюдений и выявление мультиколлинеарности в исходных данных.
Литература
1.Multi-agent Data Fusion Systems: Design and Imple-
mentation Issues. Vladimir Gorodetski, Oleg Karsayev, Vladimir Samoilov. Intelligent System Laboratory, SPIIRAS. Электронный ресурс: http://space.iias.spb.su/webarchive/ai/publications/
2002-GKS-MADFS.pdf.
2. Data Fusion - Resolving Data Conflicts for Integration. Xin (Luna) Dong, AT&T Labs Inc., Florham Park, NJ, USA, lunadong@research.att.com, Felix Naumann, Hasso Plattner Institute (HPI), Potsdam, Germany, naumann@ hpi. unipotsdam.de. Электронный ресурс: http://www2.research.att.com/~lunadong /publication/fusion _ vldbTutorial.pdf.
3. A General Data Fusion Architecture, Hervaldo S. Carvalho, Center For Future Health University of Rochester Rochester, NY, U.S.A., hervaldo_carvalho@ futurehealth.rochester.edu. Wendi B., Heinzelman Electrical and Comp. Eng. Dept. University of Rochester, NY, U.S.A. wheinzel@ece.rochester.edu, Amy L. Murphy, Computer Science Dept. University of Rochester, Rochester, NY, U.S.A., murphy@cs.rochester.edu, Claudionor J. N., Coe-lho Dept. of Computer Science, Federal University of Minas, Gerais Belo Horizonte, MG, Brazil, coelho@dcc.ufmg.br. Электронный ресурс: http://www.ece.rochester.edu/projects/wcng/pap-ers/conference/DF2003.pdf.
4. Data Fusion. Jens Bleiholder, Felix Naumann, ACM
Comput. Surv., v.41, 1, Article 1. (December 2008), 41 pages. Электронный ресурс: http://doi.acm.org
/10.1145/1456650.1456651.
5. Data Fusion for classification and object extraction. B. C. Gruber-Geymayer, A. Klaus, K Karner, VRVis Research Center for Virtual Reality and Visualization, Graz, Austria -gruber@vrvis.at , Klaus@vrvis.at, karner@vrvis.at Электронный ресурс: www.researchgate.net
6. From Data Fusion to Situation Analysis. Jean Roy. Decision Support Systems Section. Defence Research Establishment Valcartier. 2459 Pie-XI Blvd. North, Val-Belair, Quebec, Canada, jean.roy@drev.dnd.ca Электронный ресурс: www. researchgate.net .
7. The Anatomy Of Data Fusion. Roland Soong, Kantar
Media Research Michelle de Montigny, Kantar Media Research and TGI Latina Электронный ресурс:
www.printanddigitalresearchforum.com
8. Dynamic Data Fusion. Ted Diamond, Elizabeth D. Liddv, TextWise LLC, 2-212 Center for Science and Technology, Syracuse, NY 13244, liz@textwise.com, ted@textwise.com Электронный ресурс: aclweb.org/anthology-new
