CC BY
116
УДК 621.Т121 ББК 32.973.26-018.2 М 61
Ю.В. Минин, И.А. Зауголков
Модуль анализа информационной системы поддержки принятия решений в коммерческом банке
(Рецензирована)
Аннотация:
Рассматривается построение программного модуля поиска оптимальных управляющих воздействий на кредитно-депозитную деятельность коммерческого банка, внедряемый в систему поддержки принятия решений. Модуль основывается на технологии клиент/сервер, предназначенный для распределения вычислений, с использованием модели доступа на основе отсоединенных данных, а также интерфейсом передачи сообщений.
Ключевые слова:
Информационная система, система поддержки принятия решений, задача многокритериальной оптимизации, масштабируемая система, распределенные вычисления.
Ключевым звеном развития и успешного функционирования рыночной экономики, необходимой предпосылкой ее роста и стабильности в целом является устойчивая банковская система. В настоящее время наблюдается постоянное усложнение этой системы, усовершенствование банковского законодательства, значительное усиление конкуренции в банковской среде и снижение уровня доходности банков. В связи с этим возникает необходимость выбора стратегии развития с сочетанием в единое целое различных приоритетов коммерческого банка и различных интересов всех субъектов экономической деятельности, так или иначе заинтересованных в бизнесе банка.
Существуют различные стратегии управления активами и пассивами в любом коммерческом банке [1]. Так, например, в одних случаях, когда банк стремится к повышению надежности, происходит
формирование перестраховочной структуры активов, что снижает их прибыльность, а соответственно ограничивает способность банка к развитию. В других случаях, при ориентации банка на получение максимальной прибыли от вложения активов существенно
уменьшается показатель надежности. Таким образом, в настоящее время актуальной является задача управления деятельностью банка, рассматриваемая с позиций сбалансированности многих критериев.
Пример математической постановки подобной многокритериальной задачи представлен в работе [2]. В общем случае задача представляется в виде задачи векторной оптимизации (1) при ограничениях (2)
Q(U)® max, i = 1,NQ , (1)
gj (U)> 0, j = 1,2,..., Ng, (2)
где Q = (Q1, Q2,.., Qnq ) - вектор критериев оптимизации, NQ - количество критериев в задаче, gj - функциональные ограничения, условия физической и логической непротиворечивости, прямые ограничения на
управляющие воздействия U, Ng -количество ограничений в задаче, t = (0,1,...,8) - номер этапа расчетов, продолжительностью 3 месяца (один квартал) на промежутке времени 2 года.
Рисунок 1 - Блок-схема алгоритма поиска оптимальных управленческих воздействий
Решение задачи представлено следующим алгоритмом (рис. 1). В блоке 1-2 задаются начальные значения объекта. В блоке 3 устанавливается номер первого из Nt узла на этапе і. В блоке 4 генерируется множество управляющих воздействий для узла і на этапе
і. В блоке 5 рассчитываем характеристики (параметры) узлов на этапе і + 1, в которые переходит объект из узла с номером і на этапе і под воздействием управляющих воздействий
и'(’1 . В блоке 6, 7 переходим к следующему г + 1 узлу на этапе t, при условии что текущий узел не последний на этапе. В блоке 8 определяем пробные точки на основе ЛП, -последовательности в п -мерном
параллелепипеде [3] среди всех узлов на данном этапе
и() = (и(и), и(,2),..., и™), г = , п = 34,
по формуле и(’1) = а1 + [ь1 - а1 , где а 1, Ь1
- ограничения на 7 -ый варьируемый параметр, т.е. а7 < и(’1) < Ь7, а параметр Цу -координаты точки искомой
последовательности в единичном п-мерном кубе
к=1
■‘*"21 [ 2 {/ 2-'}] [2 '12к -')]!
2 1=к \
1,2,..., п
'= к для 7 =
(3)
.(')
образом, на каждый момент времени у нас остаются только эффективные точки, т.е. точки являющиеся Парето-оптимальными.
В блоке 12 осуществляем определение
О. ^ т т*
параметров управленческих воздействий и максимизирующий критерий Q1 на всем
Ql -
наиболее мнению лица, Данный поиск функциональных
где т = '+[ 1п(г)/1п(2)], а значения чисел Г
приведены в [3].
Среди найденных в блоке 8 пробных точек осуществляем поиск приближенно
эффективного узлов в блоке 9. Вычисляем значения критериев для каждого -ого узла на этапе t + 1. Пометим пробную точку и сравниваем ее со всеми остальными точками, исключая такие ] -ые точки, которые безусловно хуже, чем помеченная, т.е. такие для которых Qkгl) ^ 1), к = 1, 1, и хотя бы
при одном к имеет строгое неравенство. Далее из оставшихся точек помечаем 2 и сравниваем ее со всеми оставшимися точками (включая ), исключая безусловно худшие. После перебора у нас останутся лишь помеченные точки. Эти точки являются приближенно эффективными по Парето или Парето-оптимальными. Таким
промежутке времени, где важный критерий, по принимающего решения. основан на применении уравнений Беллмана.
Переход объекта из одного состояния в другое можно отобразить в схеме переходов объекта (рис.2). На схеме управляющее воздействие и ’1 переходит объект из узла с номером г на этапе t в узел с номером ] на этапе t + 1.
Реализация разработанного алгоритма заключается в разработке программного модуля, внедряемого в систему поддержки принятия решений (СППР).
СППР являются достаточно новым классом автоматизированных информационных систем, предназначенная для автоматизации деятельности конкретных должностных лиц при выполнении ими своих должностных (функциональных) обязанностей в процессе управления персоналом и (или) техническими средствами [4].
Рисунок 2 - Схема переходов объекта из одного состояния в следующее под воздействием управляющих воздействий
Для выполнения своих функций СППР должна накапливать информацию, обладая средствами ее ввода и хранения. Таким образом, можно выделить три основные задачи, решаемые в СППР: ввод данных; хранение данных; анализ данных. Обобщенная архитектура СППР может быть представлена следующим образом (рис. 3).
В подсистеме ввода данных (OLTP)
реализуется операционная (транзакционная) обработка данных. Для реализации подсистемы хранения используют современные СУБД и концепцию хранилищ данных (ХД). В работе [5] ХД определяется как предметно-ориентированный, интегрированный, неизменчивый, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений.
Рисунок 3 - Обобщенная архитектура системы поддержки принятия решений
В основе ХД лежит идея разделения данных, используемых для оперативной обработки и для решения задач анализа. Это позволяет применять структуры данных, которые удовлетворяют требованиям их хранения с учетом использования в OLTP-системах и системах анализа. СУБД, созданная для поддержки оперативной обработки транзакций, обычно рассматривается как непригодная для организации ХД, поскольку к
этим двум типам систем предъявляются совершенно разные требования. Системы OLTP проектируются с целью обеспечения максимально интенсивной обработки
фиксированных транзакций, тогда как ХД -прежде всего для обработки единичных произвольных запросов. В табл. 1 для сравнения приведены основные
характеристики типичных систем OLTP и ХД [6].
Таблица 1
Сравнение основных характеристик OLTP-систем и ХД
Система OLTP ХД
Содержит текущие данные Содержит исторические данные
Хранит подробные сведения Хранит подробные сведения, а также частично и полностью обобщенные данные
Данные являются динамическими Данные в основном являются статическими
Повторяющийся способ обработки данных Нерегламентированный, неструктурированный и эвристический способ обработки данных
Высокая интенсивность обработки транзакций Средняя и низкая интенсивность обработки транзакций
Предсказуемый способ использования данных Непредсказуемый способ использования данных
Предназначена для обработки транзакций Предназначено для проведения анализа
Ориентирована на прикладные области Ориентировано на предметные области
Поддержка принятия повседневных решений Поддержка принятия стратегических решений
Обслуживает большое количество работников Обслуживает относительно малое количество
исполнительного звена
работников руководящего звена
Подсистема анализа может быть построена на основе подсистем информационно-поискового анализа на базе реляционных СУБД и статических запросов с использованием языка SQL, а также подсистем оперативного анализа. Для реализации таких подсистем применяется технология оперативной аналитической обработки данных, а также подсистемы интеллектуального анализа. [4]
Разрабатываемый программный модуль относится к подсистеме интеллектуального анализа. Решение поставленной задачи сопровождается большим количеством вычислений. Ускорение получения конечного результата возможно при использовании технологии распределенных вычислений. Для обоснования применения подобных вычислений обратим внимание на ускорение параллельной системы по сравнению с однопроцессорной.
Ускорение R описывается выражением: R = Т\ /Тп, где Т\ - время решения задачи на однопроцессорной системе, а Тп - время решения той же задачи на п - процессорной системе. Пусть Ж Жск + Жпр, где Ж - общее
число операции в задаче,
- число
операций, которые можно выполнять
параллельно, а Жск - число скалярных (нераспараллеливаемых) операций.
Выражение (4, 5) представляет собой закон Амдала [7]:
R =
Wt
1
a +
1 - a
n
(4)
(5)
где a = WCk/W - удельный вес скалярных
t -
время выполнения одной
операций, операции.
Закон Амдала определяет принципиально важные для параллельных вычислений положения: ускорение зависит от
потенциального параллелизма задачи (величина \/а и параметров аппаратуры (числа
процессоров n ); предельное ускорение определяется свойствами задачи.
В приведенном выше алгоритме решения наиболее трудоемки и длительны по времени вычисления, связанные с определением всех состояний объекта, в которых он может находиться на каждом этапе. Именно эти вычисления должны быть распараллелены в первую очередь. Также можно воспользоваться возможностями распараллеливания
вычислений при поиске Парето-оптимальных узлов. Таким образом, доля операций, которые можно выполнять параллельно достаточно велика.
Далее рассмотрим принципы построения масштабируемых систем, для выбора архитектуры распределенных вычислений и параметров аппаратуры.
К параллельным масштабируемым системам можно отнести мультикомпьютеры, вычислительные кластеры, симметричные мультипроцессоры с общей памятью (SMP), системы с распределенной разделяемой памятью (DSM) и массово-параллельные системы (МРР) (табл. 2.) [8].
Мультикомпьютер - совокупность объединенных сетью отдельных
вычислительных модулей, каждый из которых управляется своей операционной системой (ОС). Взаимодействие процессов реализуется с помощью явно заданных операций связи между отдельными вычислителями, например с помощью библиотеки MPI. Обычно в мультикомпьютере реализуется согласованный сетевой протокол и нет единой очереди выполняющихся процессов. В отличие от традиционных вычислительных сетей, как локальных, так и глобальных, мультикомпьютер может рассматриваться пользователем как общий ресурс, выполняющий отдельные части его параллельной программы.
Кластер - набор компьютеров, рассматриваемый ОС, системным
программным обеспечением, программными приложениями и пользователями как единая система [9]. По существу кластер образуется из отдельных «полноценных» узлов, включающих процессоры, память, подсистему ввода/вывода, ОС и т. д. При объединении компьютеров в
кластер чаще всего поддерживаются прямые межузловые коммуникации, осуществляемые посредством передачи сообщений.
Коммуникационные системы могут быть как довольно простыми (например, на основе сети Ethernet), так и довольно сложными, реализуемыми такими высокоскоростными сетями, как SCI, Memory Channel, ServerNet, Myrinet. Наиболее эффективной областью применения кластеров являются хорошо
структурируемые, как правило, научные
приложения. С позиций удобства масштабирования кластерные архитектуры
допускают практически неограниченное наращивание числа узлов. Однако для управления кластером необходимы
специальные инструменты адми-
нистрирования, поддерживающие образ единого ресурса, в частности система пакетной обработки заданий.
Таблица 2
Основные характеристики масштабируемых вычислительных систем
Характеристика Тип системы
Мультикомпьютер Кластер SMP, DSM МРР
Порядок числа N узлов \0-\000 до \00 10-100 100-1000
Сложность узла В широком диапазоне: от компьютера и выше Компьютер, рабочая станция Один или несколько процессоров От процессорного элемента до компьютера
Взаимодействие узлов Разделяемые файлы, удаленный вызов процедуры, обмен сообщениями, уровень процессов Обмен сообщениями Общая разделяемая (SMP) или распределенная (DSM) память Обмен сообщениями или разделение переменных распределенной памяти
Планирование вычислительных работ Независимые очереди процессов Множество скоординирован ных очередей Одна очередь Одна очередь на хост-узле
Поддержка образа единой системы Частично Да Да (SMP) или иногда (NUMA) Частично
Тип и наличие копий ОС N копий распределенной ОС N копий или N разных ОС или микроядер 1 монолитная (SMP), от 1 до N в DSM N микроядер монолитной ОС или N копий распределенной ОС
Адресное пространство Множественное Множественное или единое Единое Множественное или единое (DSM)
SMP-системы состоят из нескольких десятков процессоров, разделяющих общую основную (оперативную) память и объединенных коммуникационной системой. Существуют варианты SMP-архитектур с одной и несколькими системными шинами, а также со специальным коммутатором для связи процессоров, памяти и подсистемы ввода/вывода. Каждый процессор имеет доступ ко всей основной памяти, может прерывать другие процессоры и выполнять операции
ввода/вывода. Пропускная способность коммуникационной системы достаточна для поддержания быстрого доступа к памяти. У отдельных процессоров имеется один или несколько уровней собственной кэш-памяти. Достаточный объем кэша и сравнительно небольшое количество процессоров в SMP-системах позволяют удовлетворить обращения к основной памяти, поступающие от нескольких процессоров, так что время доступа к общей памяти примерно одинаково для всех
процессоров. Это объясняет еще одно название таких архитектур - UMA (Uniform Memory Access), т. е. однородный доступ к памяти. В них имеется одна ОС, а программное обеспечение работает с единым адресным пространством общей памяти, несмотря на реально существующую иерархию «кэш -основная память».
Разумеется, передача данных между кэшами разных процессоров в SMP-системах выполняется значительно быстрее, чем обмен данными между узлами кластера или мультикомпьютера. Поэтому SMP-архитектуры хорошо масштабируются с целью увеличения производительности при обработке большого числа коротких транзакций, свойственных банковским приложениям. Что же касается удобства масштабирования и уровня готовности, то SMP-системы уступают кластерам. Ограничения в наращивании числа процессоров обусловлены, прежде всего, наличием общей основной, нераспределенной по процессорам памяти и поддержанием моделей строгой, последовательной или процессорной согласованности.
DSM-системы могут быть реализованы различными способами. Общим является наличие, помимо кэша, локальной памяти в каждом процессорном узле. Узел может состоять из нескольких процессоров и иметь архитектуру SMP. Поддерживается общее
адресное пространство памяти. Однако при этом память является распределенной по узлам, и время доступа зависит от места расположения данных. Поэтому некоторые DSM-системы получили название NUMA (Non-Uniform Memory Access), что означает неоднородный доступ к памяти. По сравнению с SMP-системами программирование NUMA-архитектур усложняется. Механизмы программной поддержки компилятором когерентности данных ограничены, и существующие методы применимы к программам с хорошо структурированным параллелизмом на уровне циклов.
Проведенный анализ информационной инфраструктуры ряда коммерческих банков Тамбовской области, таких как Тамбовский филиал ОАО АКБ “РОСБАНК”, Тамбовский ОСБ №8594, ОАО АКБ
«Тамбовкредитпромбанк» выявил общие черты в организации и количестве компьютеров. Для примера приведем информационную инфраструктуру ОАО АКБ
«Тамбовкредитпромбанка», структура которой состоит из SQL сервера, почтового сервера, сервера 1С, маршрутизатора, нескольких коммутаторов, и более 100 персональных компьютеров, представляющих
автоматизированные рабочие места
сотрудников банка (рис.4).
В описанной выше инфраструктуре нас интересуют персональные компьютеры коммерческого банка, связанные между собой локальной вычислительной сетью (ЛВС), так как на основе их можно построить масштабируемую систему для параллельных вычислений. Из выше перечисленных вариантов построения подобных систем нас устраивают системы в виде мультикомпьютера и кластера, так как построение такой системы не несет дополнительных материальных затрат для коммерческого банка при внедрении модуля в СППР в отличие от SMP- или MPP-систем, для которых необходима покупка мультипроцессорных/многоядерных вычислительных систем.
Структура модуля должна быть построена на основе технологии клиент/сервер, где приложение-сервер отвечает за функции ввода информации в модуль, хранения результатов вычисления, распределения вычислений между приложениями-клиентами, выдачей результатов, а приложения-клиенты выполняют возложенные на них вычисления.
Приложение-сервер и приложения-клиенты находятся на разных персональных компьютерах ЛВС банка. Рассмотрим организацию передачи данных между сервером и клиентами, а также организацию ввода данных в модуль.
Ввод данных в модуль необходим для задания начальных значений при расчете оптимальных управляющих воздействий, а также в случае проверки соответствия текущего состояния с оптимальным расчетным. Информация о деятельности коммерческого банка хранится в ХД, как показано выше. Значения данных, которые являются результатом прогнозирования аналитиками и руководством банка, вводятся в ручную. Если с последним способом ввода все понятно, то с получением данных ХД стоит разобраться подробнее.
Основным способом получения доступа к данным баз данных заключается в использовании интерфейса прикладного программирования (API). В настоящее время разработчик может воспользоваться большим количеством API доступа к данным. Наиболее часто используемыми до настоящего времени являлись следующие API: ODBC, DAO, OLE DB, ADO. Эти технологии доступа к данным по умолчанию обеспечивают доступ к данным через постоянное соединение с источником. В подобной модели приложение открывает соединение с БД и не закрывает его до завершения работы приложения или по крайней мере до завершения работы с источником данных. По мере роста сложности приложений число клиентов, обслуживаемых БД, неуклонно возрастает, при этом технология доступа к данным, использующая постоянное соединение, становится неудобной в силу следующих причин: поддержание соединения с БД накладно, с точки зрения использования системных ресурсов: чем больше открытых соединений приходится поддерживать, тем ниже производительность системы; приложения, использующие доступ к данным через постоянное соединение, очень плохо масштабируются. Такое приложение хорошо обслуживает соединения с двумя клиентами, с трудом справляется с 10 и совершенно не годится для 100.
В ADO.NET эти проблемы решаются использованием по умолчанию модели доступа на основе отсоединенных данных. В этой модели соединение с источником данных открыто только до завершения необходимых действий над данными. Например, если приложение запрашивает данные из БД, соединение устанавливается только на время загрузки данных, после чего сразу же закрывается, Аналогично при обновлении БД соединение открывается на время исполнения команды UPDATE, а затем закрывается. Поддерживая соединения открытыми в течение минимально необходимого времени, ADO.NET экономно использует системные ресурсы и позволяет масштабировать инфраструктуру доступа к данным - производительность снижается при этом незначительно.
Таким образом, в качестве технологии доступа к данным выбрана ADO.NET на основании выше представленной информации. Эту технологию также можно использовать для связи приложения-сервера с приложениями-клиентами, передавая данные необходимые для проведения вычислений, так как технология основана на работе с отсоединенными данными, что уменьшает нагрузку на ЛВС и тем самым потерю времени.
Передачу управляющих данных от приложения-сервера к клиентам можно осуществлять двумя способами: собственное программирование сокетов [10] или использование библиотеки функций MPI, являющейся интерфейсом передачи сообщений между процессами [11].
Результатом исследования является разработанный программный модуль для поиска оптимальных управляющих воздействий на кредитно-депозитную деятельность коммерческого банка, внедряемый в СППР коммерческого банка. Для ускорения вычислений использована технология распределенных вычислений (мультикомпьютер/кластер). Модуль реализован на основе технологии клиент/сервер. Передача управляющих данных основана на MPI, в связи с легкостью программирования, все остальные данные извлекаются и передаются на основе технологии ADO.NET.
Примечания:
1. Егорова, Н.Е., Смулов А.М. Предприятие и банки: Взаимодействие, экономический анализ, моделирование. М., Дело, 2002. - 456с.
2. Минин, Ю.В., Шамкин В.Н. Алгоритм поиска оптимальных управляющих воздействий в векторной задаче оптимизации деятельности коммерческого банка / Материалы IV Всероссийской научной конференции молодых ученых. Часть II. Майкоп: изд-во АГУ. 2007. С. 202-205.
3. Соболь, И.М., Статников Р.Б. Выбор оптимальных параметров в задачах со многими критериями. М., Наука, 1981. 128 с.
4. Уткин, В.Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В.Б. Уткин, К.В. Балдин. М.: Издательский центр «Академия». 2004. 288 с.
5. Inmon, W.H. Building the Data Warehouse Toolkit. Jhon Wiley & Sons, 2002.
6. Singh, H.S. Data Warehousing: Concepts, Technologies, Implementation and Management. Upper Saddle River, NJ: Prentice-Hall, 1997.
7. Шпаковский, Г.И. Организация параллельных ЭВМ и суперскалярных процессоров: Учебное пособие. Мн.: Белгосуниверситет, 1996. 284 с.
8. Корнеев, В.В. Параллельные вычислительные системы. М.: “Нолидж”, 1999. 320 с.
9. High perfomance cluster computing / Ed.R. Buyya. V.1. Archtectures and systems. V.2. Programming and application. New Jersey: Prentice Hall PTR, 1999.
10. Снейдер, И. Эффективное программирование TCP/IP. СПб.: Питер, 2001. 320 с.
Антонов, А.С. Параллельное программирование с использованием технологии MPI: Учебное пособие. М.: Изд-во МГУ, 2004. 71 с.
