С.В. Горин, В.В. Мастюлин, А.В. Науменко, А.Ю. Тандоев
Компания "АлконсСофт", тел.: (+095) 362-5138, 918-1380, alcons@glas.apc.org
В современных условиях перед нефтегазодобывающими компаниями остро стоят задачи информационного обеспечения принятия решений. Для управленческих решений требуется анализировать значительный объем информации, собираемый во всех узлах таких предприятий. При этом необходимо обеспечить надежность, непротиворечивость и оперативность поступления данных в условиях распределенного хранения данных и встречной направленности информационных потоков.
В статье рассматриваются основные принципы построения информационной системы поддержки принятия решений, предложенные авторами для одного из предприятий нефтегазодобывающей отрасли Западной Сибири. Так как система является сложной и содержит большое число функций, основное внимание в статье уделено технологиям обмена данными в распределенной структуре как наиболее важному технологическому элементу системы.
Структура нефтегазодобывающего объединения
Организационная структура нефтегазодобывающего объединения (компании) Западной Сибири включает в себя одно или более нефтегазодобывающих управлений (НГДУ). Каждое НГДУ состоит из нескольких цехов. С точки зрения обмена данными наиболее интересны:
- цеха добычи нефти и газа (ЦДНГ);
- цеха поддержания пластового давления (ЦППД);
- цеха подготовки и перекачки нефти (ЦППН).
Существующая структура информационных потоков показана на Рис. 1.
Рисунок 1.
Существующая структура информационных потоков.
Основные функции обработки информации распределяются между подразделениями следующим образом:
- Персонал цехов собирает информацию о состоянии подведомственных объектов (регистрирует события и проведенные мероприятия, например, остановы и пуски скважин; снимает показания с приборов - расходомеров, индикаторов уровня и т. п.; проводит лабораторные исследования - состав нефти, процент воды и т. п.; получает данные с помощью приборов телеметрии). Период получения различных показателей может быть от десятков минут до нескольких суток.
- Собранная в цехах информация передается для последующей обработки. Как правило, обработкой информации занимается вычислительный центр (ВЦ). Обработка информации заключается в обобщении данных по специальным алгоритмам и получении ряда отчетных форм. Периоды получения отчетных форм: сутки, месяц и год.
- На основании форм специалистами НГДУ принимаются в большинстве своем оперативные решения по управлению процессом производства и выдаются плановые задания цехам.
- Обработанная (обобщенная) информация возвращается в цеха в виде отчетных форм, где используется специалистами для принятия оперативных решений.
- Определенная информация выходит из аппарата НГДУ и должна быть доведена до сведения персонала цехов (плановые задания, сведения о новых объектах и т. п.)
- Собранная со всех НГДУ и обобщенная информация в виде отчетных форм поступает в аппарат компании, где принимаются стратегические решения.
Таким образом, стоит задача обеспечения специалистов и аппарата управления данными для принятия решений. Особенности этой задачи: © -Данные формируются в разных узлах (например, данные о добыче - в цехе, управляющие данные - в НГДУ или в аппарате компании); © -В каждом из узлов системы для принятия решения нужны данные из других узлов. Это - достаточно сложная задача многоуровневого сбора и доставки данных, в которой различные объекты и подразделения разбросаны на большой территории.
Унаследованное программное обеспечение
В настоящее время на многих уровнях иерархии предприятий для решения частных задач используются локальные АРМ, никак не связанные между собой. Они используют различные модели данных и даже различные СУБД, как правило, не промышленного класса. Для передачи данных из одного узла в другой используется обычно пересылка дискет, передача файлов по модемной связи или по телефону (голосом).
Описанная ситуация порождает целый комплекс проблем. Наиболее существенная - потенциальная возможность получения противоречивых данных. Такая возможность непосредственно вытекает из несогласованности информационных моделей в различных узлах. Так, например, различная информация о состоянии скважин обрабатывается несколькими программами. Формат представления даже однотипных данных в них различен. Для согласования любых изменений в данных между такими программами используются механизмы экспорта/импорта.
Другая проблема - затрудненность обмена данными и, как следствие, несвоевременность поступления информации. Используемый в настоящее время регламентный обмен данными не может обеспечить оперативности поступления информации. Не используются потенциальные возможности локальных и глобальных сетей. Оперативные данные с промыслов поступают в НГДУ после обработки в вычислительном центре объединения. При этом задержка составляет как минимум сутки, в то время как оперативно принятое решение в определенных случаях позволяет избежать потерь, измеряемых десятками тысяч долларов.
В условиях сегодняшней ценовой конкуренции дальнейшая эксплуатация существующих АРМ не позволяет предприятию работать над снижением затрат и получать отдачу от использования информационных технологий, адекватную вложенным средствам.
Выход из создавшегося положения - возложение функции тиражирования данных на существующие специализированные программные средства. Внедрение технологии тиражирования данных обеспечивает гарантированную доставку, своевременность и целостность передаваемых данных. Поэтому центральным вопросом проектирования является выбор технологии распределенной обработки и доставки данных.
Технологии распределенной обработки и доставки данных
Централизованное хранение данных и доступ к центральной БД в условиях географически распределенной системы приводят к необходимости установления соединений между центральным сервером, хранящим данные, и компьютерами-клиентами. Большинство компьютеров-клиентов отделены от центрального сервера медленными и недостаточно надежными линиями связи и работа в режиме удаленного клиента становится почти невозможной. Этим можно объяснить существующую ситуацию, когда в узлах распределенной системы функционируют группы автоматизированных рабочих мест (АРМ), и эти группы не связаны друг с другом.
Содержательная сторона задачи обычно требует обмена данными между группами АРМ, так как изменения в данные могут вноситься в одной группе АРМ (например в НГДУ), а использоваться эти данные могут в другой группе (например в цехе). Обмен данными на практике реализуется регламентной передачей файлов, либо через модемное соединение, либо "с курьером".
То, что данные доставляются к месту назначения не системными средствами, а путем экспорта/импорта файлов, приводит к необходимости участия человека в процессе обмена, что влечет за собой неоперативность поступления данных и необходимость реализации внешних механизмов контроля целостности и непротиворечивости. Результатом является высокая вероятность ошибок. Кроме того, реализация всех алгоритмов обмена данными и контроля в этом случае возлагается на прикладных программистов, проектирующих АРМ. Объем работ по программированию и отладке подпрограмм обмена соответствует числу различных АРМ. Это также приводит к повышению вероятности ошибок в системе.
В современной технологии АРМ объединены в локальную сеть. АРМ-клиент выдает запросы на выборку и обновление данных, а СУБД исполняет их. Запросы клиента в соответствии с требованиями задачи сгруппированы в логические единицы работы (транзакции). Если все операции с базой данных, содержащиеся внутри транзакции, выполнены успешно, транзакция в целом выполняется успешно (фиксируется). Если хотя бы одна из операций с БД внутри транзакции не выполнилась успешно, то все изменения в БД, произведенные к этому моменту из транзакции, отменяются (происходит откат транзакции). Такое функционирование обеспечивает логическую целостность данных в базе данных.
При распределенной обработке изменения, проводимые приложением-клиентом, могут затрагивать более чем один сервер СУБД. Для поддержания целостности и в этом случае необходимо применение того или иного транзакционного механизма, реализуемого системными средствами, а не прикладной программой.
Большинство производителей современных промышленных СУБД обеспечивают в той или иной мере поддержку распределенной обработки транзакций. Распределенная обработка данных основывается на синхронных или асинхронных механизмах обработки распределенных транзакций. Эти механизмы могут использоваться совместно. Выбор того или иного механизма зависит от требований конкретной подзадачи, так как каждый механизм обладает сильными и слабыми сторонами.
Двухфазная фиксация
Исторически первым появился метод синхронного внесения изменений в несколько БД, называемый двухфазной фиксацией (2PC - two-phase commit). Этот механизм реализован сейчас практически у всех производителей СУБД.
Метод двухфазной фиксации состоит в том, что при завершении транзакции серверы БД, участвующие в ней, получают команду "приготовиться к фиксации транзакции". После получения подтверждений от всех серверов транзакция фиксируется на каждом из них. Таким образом, в любой момент времени обеспечивается целостность данных в распределенной системе. Платой за это является требование доступности всех участвующих серверов и линий связи во время проведения транзакции и невозможность работы приложений-клиентов при недоступности, например, удаленного сервера. Кроме того, требуется высокое быстродействие линий связи для обеспечения приемлемого времени реакции у приложения-клиента.
В распределенной системе идеальным являлось бы состояние, когда каждая программа-клиент обращается только к тем серверам, которые находятся в пределах ее локальной сети, а передача данных и обеспечение целостности осуществляется системными средствами и не требуют специальных действий со стороны прикладной программы. Такое распределение функций возможно и на практике реализуется с помощью механизма асинхронного тиражирования транзакций.
Асинхронное тиражирование транзакций
Синхронное проведение изменений в участвующих в распределенной транзакции базах данных не всегда необходимо. Рассмотрим, например, случай ввода данных с измерительного оборудования в цехе и последующего анализа их на уровне управления. Здесь важно обеспечить достаточно малый (но, возможно, ненулевой) интервал времени между изменениями в исходных данных и изменениями в их копии в другом узле системы, где происходит построение отчетов.
Механизм асинхронного тиражирования транзакций (репликации) гарантирует доставку измененных данных на вторичные серверы непосредственно после завершения транзакции, если сервер доступен, или сразу после подключения сервера к сети. Такой подход предполагает хранение дублирующей информации в различных узлах сети и может обеспечить, по сравнению с другими подходами к репликации, снижение трафика, улучшение времени ответа системы, а также позволяет оптимизировать нагрузку на серверы. Асинхронная репликация не делает линии связи более надежными или скоростными. Она перекладывает передачу данных, обеспечение их целостности и ожидание при передаче данных с прикладной программы и пользователя на системный уровень.
Асинхронная репликация, в отличие от 2РС, не обеспечивает полной синхронности информации на всех серверах в любой момент времени. Синхронизация происходит через некоторый, обычно небольшой, интервал времени, величина которого определяется быстродействием соответствующего канала связи. Для большинства задач кратковременное наличие устаревших данных в удаленных узлах вполне допустимо.
Вместе с тем, асинхронная репликация транзакций принципиально обеспечивает целостность данных, так как объектом обмена данными здесь является логическая единица работы - транзакция, а не просто данные из измененных таблиц.
Репликационный сервер Sybase
Репликационный сервер, входящий в состав Sybase System 10, использует асинхронную модель репликации транзакций. При разработке модели данных проектируются и правила репликации. Затем проводится конфигурирование системы. При работе прикладной программы изменения данных отслеживаются системными средствами и в соответствии с конфигурацией требуемые данные передаются в удаленную СУБД (Рис. 2).
Рисунок 2.
Взаимодействие системных компонент при репликации транзакций.
Репликационный сервер представляет собой отдельную задачу, запускаемую одновременно с СУБД. Он имеет свой входной язык и стандартный для продуктов SYBASE сетевой интерфейс Open Server. Такое разделение снижает нагрузку на СУБД и делает систему в целом более открытой.
Репликация использует интуитивно понятный принцип "публикации" изменяемых данных и "подписки" на изменения.
Транзакция может вносить изменения (т. е. добавлять, удалять и изменять записи) в одну или несколько таблиц базы данных. Выбранные для репликации таблицы специальным образом помечаются. Для каждой такой таблицы или группы ее строк, выбранной по заданному условию, определяется один узел (СУБД), в котором данные таблицы являются первичными. Это тот узел, в котором происходит наиболее активное обновление данных. Репликационному серверу, обслуживающему БД с первичными данными, задается описание тиражирования (replication definition). В этом описании, в частности, могут быть заданы интервалы значений первичного ключа таблицы (или другое условие на первичный ключ), при выполнении которого измененные данные будут тиражироваться от этого узла к подписчикам. Если условие не задано, то описание тиражирования действует для всех записей таблицы.
Возможность тиражирования группы записей таблицы означает, в частности, что часть записей таблицы может быть первичными данными в одном узле, а часть - в других.
В одном или нескольких узлах (СУБД), которым нужны измененные данные, в обслуживающем его репликационном сервере создается подписка (subscription) на соответствующее описание тиражирования. Здесь будет поддерживаться (с небольшой задержкой) копия первичных данных.
Современные СУБД используют системный журнал, в который делаются записи о изменениях в базе данных и завершении транзакций. Журнал используется сервером БД для отката или прокрутки транзакций после сбоев и для резервного копирования. Репликация данных в Sybase также использует журнал как источник информации о завершенных транзакциях.
В узле, содержащем первичные данные, для каждой тиражируемой базы данных запускается специальная компонента - менеджер журнала транзакций (Log Transfer Manager - LTM). Он подключается к серверу БД и получает от него уведомления о завершении транзакций. Измененные данные из журнала передаются репликационному серверу, обслуживающему этот узел. Репликационный сервер в соответствии с описанием тиражирования и подписками отправляет данные по месту назначения - соответствующим репликационным серверам в удаленных узлах.
Именно в этом месте - между репликационными серверами - связь может быть медленной или недостаточно надежной. Передаваемые данные в составе транзакции при недоступности узла-получателя записываются в стабильные очереди на диске и затем передаются по мере возможности. Данные могут передаваться в удаленный узел по маршруту, содержащему несколько репликационных серверов. Данная возможность лежит в основе построения иерархических систем репликации.
По умолчанию репликационный сервер сохраняет смысл операций. Это значит, что удаление записи из первичной таблицы (выполнение оператора DELETE) приведет к выполнению такого же оператора DELETE в узле, хранящем копию таблицы; выполнение INSERT или UPDATE над первичной таблицей точно так же приведет, соответственно, к добавлению или обновлению записи в копии таблицы в результате работы системы репликации. Имеется гибкий механизм конфигурирования так называемых функциональных строк (function strings), которые переопределяют любую операцию на макроязыке с подстановкой параметров.
В одной базе данных могут содержаться как первичные данные, так и данные-копии. Приложение-клиент, работающее со своей СУБД, может вносить изменения напрямую (операторами INSERT, DELETE, UPDATE) только в первичные данные. Для изменения копии данных предназначен механизм асинхронного вызова процедур.
Для работы механизма асинхронного вызова процедур в нескольких базах данных создаются процедуры с одинаковым именем и параметрами, но, возможно, с различным текстом. В одной базе данных процедура помечается как предназначенная к репликации. Вызов этой процедуры вместе со значениями параметров через журнал и механизм репликации передается к узлам-подписчикам и в их базах данных вызывается одноименная процедура с теми же значениями параметров.
Таким образом, для обновления "чужих" для узла данных (копии данных) прикладная программа-клиент вместо выполнения оператора UPDATE вызывает заранее определенную в этом узле хранимую процедуру и передает ей параметры (например, значение первичного ключа и новые значения для обновляемых колонок). Тело этой процедуры пустое и она не выполняет никаких действий, однако ее вызов записывается в журнал. Механизм репликации обеспечивает вызов на узле, содержащем первичные данные, одноименной процедуры с подстановкой параметров. В теле этой процедуры может быть записан оператор UPDATE, обновляющий первичные данные. Тот же механизм репликации передаст изменения в данных узлу, инициировавшему операцию.
Репликационный сервер и Log Transfer Manager реализованы в виде отдельных модулей и могут выполняться не на том же компьютере, что сервер базы данных. Включение в систему репликационного сервера практически не увеличивает время ответа сервера первичной базы данных.
Важно, что репликационный сервер тиражирует транзакции, а не отдельные изменения в базе данных. Метод тиражирования транзакций гарантирует целостность внутри транзакции и, как следствие, невозможность нарушения ссылочной целостности. Схема обновления первичных данных и копий данных исключает возможность возникновения конфликтов (конфликты могут быть вызваны только неправильным проектированием системы или аппаратным сбоем).
Распределенная обработка для гетерогенной среды - Sybase OmniConnect
В различных узлах предприятия используются базы данных от разных производителей. Например, в системе принятия решений это может быть Sybase, а в геоинформационной системе - Oracle.
Компонент OmniConnect из Sybase System 10 осуществляет унифицированный доступ приложений к разнородным источникам данных. Специальные шлюзовые компоненты организуют работу в системе с любой промышленной СУБД, включая Oracle и Informix. Приложения-клиенты при этом работают только с сервером Omni на диалекте SQL фирмы Sybase (TransactSQL), а необходимая трансляция и преобразование типов данных автоматически осуществляется шлюзовыми модулями.
OmniConnect хранит информацию о размещении таблиц на том или ином сервере БД. Централизованно хранятся и исполняются глобальные хранимые процедуры. Приложение-клиент может осуществлять транзакции, в которых участвуют таблицы из различных БД, а также выполнять процедуры, которые OmniConnect при работе с СУБД, отличными от Sybase, прозрачно преобразует к соответствующему диалекту SQL.
Создание рабочих мест пользователей
Рабочие места пользователей реализуются на PC в среде Windows. Для создания приложений, работающих с базами данных, используется высокоуровневое средство разработки 4GL - PowerBuilder фирмы Powersoft [2].
Доступ к данным от технологического и измерительного оборудования
На предприятии используются данные, поставляемые внешними источниками, например собираемые с измерительных приборов. Желательно обеспечить к ним доступ из приложений-клиентов и хранимых процедур.
Технология и библиотеки OpenServer, входящая в состав Sybase System 10, позволяет разрабатывать собственные приложения, использующие данные от технологического оборудования. Для приложений клиента такие программы "выглядят" как хранимые процедуры на Sybase-совместимом сервере базы данных.
На базе технологии OpenServer реализуется специальный драйвер, обеспечивающий доступ к ODBC-источникам данных. Приложение может подключаться к этому драйверу как к обычному серверу Sybase и выполнять на нем операции Transact SQL Sybase. Драйвер самостоятельно выполняет приведение команд Transact SQL к стандарту ODBC. Использование подобных драйверов позволяет включать в систему не только промышленные СУБД других производителей, но и desktop-СУБД (dBase, Access и т. д.).
Другим примером применения технологии OpenServer может служить реализация доступа к электронной почте.
Характерные черты информационной системы
На Рис. 3 показана структура информационной системы нефтегазодобывающего предприятия.
Рисунок 3.
Схема взаимодействия компонентов системы.
В системе используется распределенное хранение данных. В такой модели для каждой части структуры определяется первичный узел хранения. В рассматриваемой задаче первичными узлами хранения данных о добыче нефти являются цеха, которые осуществляют сбор данных. В этих узлах собирается и хранится информация о происходящих событиях, а также данные, собранные автоматическим способом (с приборов). Для их включения в систему используется технология OpenServer.
Если в узле используются ранее накопленные данные, хранящиеся в формате непромышленных СУБД (ЦЕХ 2), то используется технология Open Server для обеспечения прозрачного доступа к этим данным со стороны репликационного сервера и сервера базы данных. Приложения, работающие в узле, подключаются к серверу базы данных Sybase и работают только с ним. Первичные данные о добыче и событиях на промыслах передаются из цехов в НГДУ с помощью репликационного сервера. Данные от цехов обобщаются в НГДУ, после чего интегральные показатели передаются в аппарат компании.
Данные, связанные с управленческими решениями и рекомендациями, а также интегральные данные являются первичными в аппарате компании - для НГДУ и в НГДУ - для цехов. Тиражирование этих данных выполняется в обратном направлении по сравнению с данными о добыче.
Заключение
Создание распределенных информационных систем является весьма актуальной задачей. Это связано прежде всего с возрастающими требованиями к оперативности и достоверности информации. Доступ к централизованным информационным серверам накладывает нереалистично жесткие требования надежности всех узлов и быстродействию линий связи. Эффективное построение распределенных систем возможно при использовании современных технологий репликации данных.
Для большого класса задач невозможность работы в централизованной архитектуре и ненадежность "самодельных" средств обмена данными приводит к необходимости выбора современных технологий и методов построения распределенных систем.
Литература
- Тандоев А. Ю. Архитектура продуктов клиент-сервер фирмы Sybase. СУБД N 1, 1995, с. 62-69.
- Горин С. В., Тандоев А. Ю. Среда разработки приложений PowerBuilder. DBMS/Russian Edition, N 1, 1995.
- Горин С. В., Тандоев А. Ю. Применение CASE-средства ERwin 2.0 для информационного моделирования в системах обработки данных. СУБД, N 3, 1995.