CC BY
50
нагрузки для энергоблоков генерирующих компаний, график поставок компаний поставщиков и график потребления с системных позиций для учасников энергорынка.
Выводы. Современное состояние производства, распределения, поставок и потребления электроэнергии в условиях перехода к рыночным отношениям требует формирования новых механизмов балансирования спроса и предложений с позиций эффективности составляющих бизнес-процессов всех уровней. Проведенный анализ содержания и взаимодействия рассматриваемых процессов в электроэнергетике позволил выделить критерии и основные ограничения задачи планирования производства, поставок и потребления электроэнергии в рыночных условиях. Результаты решения формализованного представления данной оптимизационной задачи могут быть использованы для формирования графика нагрузки энергоблоков генерирующих компаний с учетом уровня поставок и потребления электроэнергии в рыночных условиях при составлении долгосрочных и краткосрочных контрактов, а также для обеспечения эффективности балансирующего рынка электроэнергии в составе функциональных подсистем управления.
Литература
1. Постанова №1789 Про схвалення Концепції функціонування та розвитку оптового ринку електричної енергії України. - К. : Каб. Мін. України, 2002. - 53 с.
2. Программа экономических реформ Украины на 2010-2014 гг. // Комитет по экономическим реформам при Президенте Украины. - Офиц. изд. - К.: 2010 г. - 99 с.
3. Шевченко С. В., Пивненко А. М. Формирование планов производства электроэнергии с учетом динамики изменения состояния энергосистемы // Вісник Національного технічного університету «ХПІ». Зб.наук.праць. Тематичний випуск «Системний аналіз, управління та інформаційні технології». - Х.:
НТУ ХПИ. - 2010. - № 67. - С. 196-202.
УДК 012.4.03
СНИЖЕНИЕ СОВОКУПНОЙ СТОИМОСТИ ВЛАДЕНИЯ ИНФОРМАЦИОННО-АНАЛИТИЧЕСКОЙ СИСТЕМОЙ ЗА СЧЕТ СОЗДАНИЯ СИСТЕМЫ ИНТЕГРАЦИИ ДАННЫХ
К. А. Лычагин, начальник сектора создания и сопровождения подсистем интеграции данных аналитических систем ЗАО «ЕС-лизинг»
Тел.: (495) 319 1945, e-mail: klychagin@ec-leasing.ru
Б.А. Позин, д. т. н, профессор, технический директор ЗАО «ЕС-лизинг»
Тел.: (495) 319 2136, e-mail: bpozin@ec-leasing.ru ЗАО «ЕС-лизинг» http://www.ec-leasing.ru
The paper describes categories of costs which can be included in total cost of ownership (TCO) of information-analytical system and which are connected with the data integration system (DIS). Some problems of creating DIS are described. The streaming architecture of DIS, which helps to solve problems of stability and scalability of DIS and to lower TCO of IAS is proposed.
В статье рассмотрены категории затрат, входящие в расчет совокупной стоимости владения (ССВ) информационно-аналитической системы (ИАС) и связанные с системами интеграции данных (СИД). Сформулированы некоторые проблемы создания систем интеграции данных. Предложена потоковая архитектура системы интеграции данных, позволяющая решить проблемы устойчивости и масштабируемости СИД, и снизить ССВ ИАС.
Ключевые слова: Совокупная стоимость владения, информационно-аналитические системы, интеграция данных.
Keywords: total cost of ownership, data integration, ETL architecture, parallel processing.
Важной составляющей экономической эффективности информационно-аналитической системы (ИАС) является совокупная стоимость владения ею. Одной из важнейших целей проекта создания и внедрения ИАС является минимизация совокупной стоимости владения (ССВ) ею при заданных параметрах функциональных возможностей[1]. Существенной составляющей ССВ является стоимость экстракции, преобразования и загрузки первичных данных в жизненном цикле ИАС. По оценке специалистов IBM она составляет примерно 70% . Эта функция реализуется комплексом методик и инструментальных средств, которые в данной работе названы системой интеграции данных (СИД). СИД является функциональным компонентом ИАС, а отдельные ее части входят в состав системы обеспечения ее жизненного цикла (ЖЦ) [2].
Категории затрат, связанные с СИД и входящие в состав совокупной стоимости владения
При оценке ССВ должны учитываться нижеприведенные категории затрат, зависящие от качества реализации системы интеграции данных.
Затраты на создание проектирование, реализацию и внедрение СИД. Это затраты на работы по созданию ядра - программной составляющей (в частности ETL процедур) СИД до момента ввода системы в промышленную эксплуатацию. Отметим некоторые характерные для процесса создания СИД виды работ:
а) анализ источников данных, включающий в себя профилирование данных,
б) создание спецификаций преобразования данных,
в) создание вспомогательных метаданных (например, метаданных staging area),
г) реализация ETL процедур,
д) тестирование ETL процедур,
е) внедрение ETL процедур,
Затраты на создание комплекса технических средств (КТС) в части создания СИД. Могут включать затраты на: а) оборудование, которое должно быть закуплено и на котором будет внедряться СИД, б) затраты на монтаж и настройку оборудования.
Стоимость лицензии на покупное программное обеспечение (ПО), используемое на протяжении всего ЖЦ СИД. Вопрос целесообразности использования специализированных инструментов вместо «кодирования» ETL обсуждается, например, в [3][4]. В данную категорию затрат могут входить: а) стоимость лицензий на ETL инструменты; б) стоимость ПО для обеспечения ЖЦ СИД; в) стоимость специализированного ПО для анализа источников данных.
Затраты на сопровождение системы. В эту категорию включены затраты на: внесение изменений в ETL процедуры с повторным циклом тестирования и внедрения; оптимизацию ETL процедур, а также потери из-за простоя системы при проявлении критических ошибок в различных компонентах СИД.
Затраты на развитие системы. В процессе жизненного цикла ИАС (и СИД соответственно) происходит расширение состава обрабатываемой информации, вызванное изменением нормативной базы, расширением потребностей заказчика в аналитической информации. В числе затрат на развитие системы можно выделить затраты на: доработку ETL процедур, вызванную расширением состава обрабатываемых данных и появлением новых источников данных; масштабирование комплекса технических средств и «тюнинг» СИД из-за увеличения объемов поступающих данных и возможной деградации общесистемных нефункциональных характеристик ИАС (например, производительности).
Проблемы создания СИД и задача снижения ССВ
Итерационный процесс внесения изменений в ИАС и соответственно в СИД, вызывает необходимость решения ряда проблем ([4] [5]), среди которых выделим следующие три, которые непосредственно влияют на ССВ ИАС.
Устойчивость архитектуры к изменениям. Заложенная на этапе создания СИД архитектура должна быть рассчитана на возможность подключения новых источников данных и при этом обеспечивать минимальное количество изменений существующих элементов СИД. Невнимание к решению задачи создания устойчивой к изменениям архитектуре СИД приводит к увеличению затрат на развитие системы (в некоторых случаях это может привести к необходимости повторения полного цикла разработки СИД).
Возможности по масштабированию системы и управлению степенью утилизации имеющихся ресурсов. Система должна не только эффективно использовать имеющиеся в составе ИАС ресурсы КТС, но и быть приспособлена к обеспечению требуемой производительности либо путем эффективного распределения имеющихся ресурсов, либо допускать допоставку новых ресурсов (масштабирование КТС) без доработки программного обеспечения ИАС и СИД.
Повторное использование проектных решений (в части БТЬ процедур) для снижения затрат при разработке и развитии СИД. Данная проблема в большинстве реальных проектов не решается^]. Будем в дальнейшем говорить о создании некоторого набора компонентов, каждый из которых построен по некоторому шаблону. При реализации СИД производится настройка шаблона, в результате чего получается исполняемый компонент.
Потоковая архитектура СИД
Для решения вышеперечисленных проблем предлагается архитектура, обладающая свойством устойчивости к изменениям и позволяющая регулировать степень утилизации ресурсов КТС.
Для обеспечения устойчивости архитектуры СИД к изменениям предлагается проектировать СИД, исходя из свойств модели данных ХД, а не свойств данных из источников (обратный подход описан в [6]). В фундаментальной работе по созданию хранилищ данных [7] Б. Инмон дает общую формулировку СИД: набор программ, предназначенный для захвата, преобразования и помещения данных в хранилище данных. В работах [5,6,7,8] описываются различные типичные функциональные компоненты, из которых может состоять каждая программа.
Представим СИД как набор программ (которые в дальнейшем будем называть потоками), каждая из которых захватывает, подготавливает и помещает в ХД информацию только об одном логическом объекте (см. рис.1). Под объектом понимается логическое понятие или их совокупность представляющих некоторый бизнес - объект из предметной области.
В состав набора потоков входят компоненты, реализующие следующие функции:
Ю) предварительное преобразование - сбор из источников всех данных, относящих к экземплярам логических объектов;
ф поиск изменений - поиск новых экземпляров;
у) преобразование кодов - преобразование значений классификаторов из источника в значения, используемые в ХД;
к) создание суррогатных ключей;
ук) построение связей - назначение корректных внешних ключей;
1) конечное преобразование - «раскладывание» данных по конечной структуре физических таблиц
ХД;
1) загрузка данных - помещение данных в базу данных ХД.
ИСТОЧНИКИ данных
о о
-а
а
а
О
фи
Р
L. .
-а
о
й-■ 1
й-
□
а
а
-р О -й
X
p д
a a
H н
и н
Л ы
и X
Щ
e
tO- предварительное преобразование d * поиск изменений v- преобразование кодов к - созда ни е суррогатных ключей
vk - постро енне связей I- конечное преобразование 1-загрузка таблице ХД
; ОдНОТИГШЫе компоненты
- •>■ Исходные данные q объекте
Последовательное _________ __ Ожидание выполнения
исполнение компонент ^ компон енг а ш друтого пот ока
Рис. 1. Архитектура СИД Потоки зависят от исходных данных лишь в компоненте «предварительное преобразование» и могут взаимодействовать между собой только в компонентах «построение связей» и «загрузка данных».
Такая архитектура наиболее эффективна при использовании совместно с аддитивной моделью данных хранилища данных. Под «аддитивной» будем понимать такой класс моделей данных, в которых увеличение состава хранимой информации ведет только к добавлению новых логических и физических объектов, но не приводит к изменению уже имеющихся в составе модели. Примером такой модели является IBM Banking Data Warehouse Model [9].
Пусть к ИАС предъявляются новые требования по составу представляемой пользователю информации. Появление таких требований приводит к изменению модели данных ХД. Так как модель данных аддитивна, то для выполнения требований необходимо будет добавить только новые логические объекты. Существующие логические объекты останутся без изменений, и, следовательно, без изменений останутся и существующие потоки СИД, их загружающие. Быть может, изменится лишь компонент «предварительной обработки» в случае изменения форматов поступающих данных. Для загрузки новых логических объектов необходимо добавить только новые потоки. В результате предложенная архитектура совместно с аддитивной моделью данных приводит к снижению затрат на развитие системы.
Архитектура также может использоваться и с неаддитивными моделями данных. В таком случае появление новых требований может привести к полной переработке некоторых потоков.
Унификация используемых функциональных компонентов системы интеграции. Из всех компонентов потоков преобразования данных только «предварительное преобразование» может потребовать неизвестное количество операций над данными. Состав операций, выполняемых в остальных компонентах, заранее известен и определяется функциями, которые выполняют компоненты. Следовательно, для каждого компонента можно создать шаблон, состоящий из определенного набора операций. В результате система будет состоять из потоков и компонентов однородной структуры, отличающихся лишь описанием входных и выходных объектов (входными и выходными метаданными). Однородность компонентов позволяет специалистам по сопровождению системы легче анализировать причины возникновения нештатных ситуаций, что приводит к снижению затрат на сопровождение системы.
Поступление данных. В случае, когда все данные доступны на момент начала работы ИАС, СИД может состоять из одного компонента предложенной архитектуры. Если же данные поступают из разных источников в течение продолжительного времени и данные необходимо загрузить в ХД сразу после поступления, то СИД может состоять из нескольких компонент, каждый из которых будет иметь предложенную архитектуру.
Возможности по масштабируемости СИД и управлению степенью утилизации. Проблему масштабируемости СИД можно решить за счет проектирования ее архитектуры, обеспечивающей высокую степень параллелизма на этапе выполнения и возможность управления степенью параллельности, что приводит к уменьшению времени простоя системы и, тем самым, к снижению затрат на создание комплекса технических средств. Распараллеливание процессов позволяет эффективно использовать имеющиеся аппаратные ресурсы, и позволяет эффективно задействовать тельные ресурсы при развитии системы.
В предложенной архитектуре потоки СИД взаимодействуют между собой в двух типах компонентов, при этом данное взаимодействие сводится к ожиданию завершения работы предыдущего компонента другого потока (например, на рис.1. компонент 'В' ожидает завершения работы компонента ‘А’). При ожидании система не простаивает, так как параллельно работают другие потоки. Архитектура позволяет регулировать число параллельно исполняемых потоков для уменьшения/увеличения утилизации ресурсов системы. Потоки могут выполняться и на распределенных физических ресурсах (например, в ОМБ-архитектуре).
Процесс разработки СИД. При применении предложенной архитектуры процесс разработки системы интеграции можно разделить на этапы: а) анализ модели данных хранилища данных (ХД), выделение логических объектов с определением бизнес - ключей, внешних ключей и информационных атрибутов, которые необходимо в дальнейшем извлечь из системы - источника; б) создание шаблонов потоков и компонентов обработки данных; в) анализ источников данных с целью определить алгоритмы извлечения необходимой информации о логических объектах; г) проектирование области предварительной обработки данных; д) конечная адаптация шаблонов.
В работе предложен метод построения архитектуры системы интеграции данных. Основным результатом является потоковая архитектура системы интеграции данных, наиболее эффективно работающая в условиях аддитивности модели данных хранилища данных и слабо зависящая от свойств входных данных. Предложенная архитектура устойчива к расширению состава источников данных и составу обрабатываемой информации. Она позволяет при необходимости распараллеливать обработку входных данных и регулировать степень утилизации ресурсов, выделенных для системы интеграции данных. В работе показано, что применение потоковой архитектуры обеспечивает снижение совокупной стоимости владения.
Информационные войны
Литература
1. Кляшторная О. Оценка ИТ - проектов. Что выбрать? // Журнал “Директор ИС”, N6, 2003
2. ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем.
3. JoyMundy Kimball University: Should You Use An ETL Tool? // InformationWeek , April 6, 2008
4. David Waddington Data Integration: TCO Really Matters http://www.scribd.com/doc/4587250/Data-Integration-Total-Cost-of-Ownership-Really-Matters-
5. Kimball R. The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming, and Delivering Data / R. Kimball, J. Caserta. - Wiley Publishing Inc., 2004.
6. IBM Guidelines for Extraction Transformation and Loading the BFMDW Release 7.0 First Edition (December 2006) BFMDW70019
7. Ryan Sousa, Claudia Imhoff, W. H. Inmon Corporate Information Factory 2e // Wiley Publishing Inc.,
2000
8. Bob Becker Kimball University: The Subsystems of ETL Revisited // InformationWeek , Oct. 21, 2007 9. Материалы сайта IBM: http://www.ibm.com/industries/financialservices/ru/banking/solutions/bdw.shtml
УДК 316.3 330.46
СТОХАСТИЧЕСКИЕ МОДЕЛИ РАСПРОСТРАНЕНИЯ НОВЫХ ИДЕЙ В СОЦИАЛЬНЫХ СЕТЯХ
Л.Л. Делицын, к.т.н., доцент МГУКИ Тел.: 8(906)764-76-41, e-mail: L.Delitsin@yahoo.com Т. А. Подлесная, аспирант МГУКИ Тел.: +7(495)5703322, e-mail:podlesnayata@gmail.com Московский Государственный Университет Культуры и Искусств
http://www.mguki.ru
The stochastic model of the expansion of new ideas in social networks on the basis of Markov process with continuous time is studied. A new method of obtaining deterministic Bass model of innovation diffusion in a homogenous clique from a general stochastic model is proposed.
Исследуется модель распространения новых идей в социальных сетях на основе марковских процессов с непрерывным временем. Предложен новый способ доказательства утверждения о том, что в однородной клике (полносвязанном графе) при бесконечно большом количестве коммуницирующих индивидов математическое ожидание доли информированных индивидов описывается логистической моделью Ф. Басса.
Ключевые слова: диффузия инноваций, социальные сети, стохастические модели
Key words: innovation diffusion, social networks, stochastic models
Предлагается простейшая модель распространения информации в социальных сетях, которая позволяет получить распределение вероятности осведомленности каждого элемента произвольной социограммы, описывающей связи между небольшим числом коммуникантов и реципиентов. В этой модели каждый субъект может находиться только в двух состояниях: полной осведомленности и полной неосведомленности, а структура связей между субъектами не меняется во времени.
На рис. 1 изображен полный набор возможных состояний системы из трех субъектов, попарно общающихся между собой. Число возможных состояний системы равно восьми, и оно не зависит от связей между элементами (поскольку мы считаем связи неизменными). Черным кружкам соответствуют осведомленные субъекты, а белым - неосведомленные.
