Deductor. Руководство администратора

Руководство администратора

© BaseGroup Labs 1998-2005 www.basegroup.ru

© BaseGroup Labs 1998-2005 В руководстве описана аналитическая платформа Deductor 4.3: технические особенности платформы, установка, настройка и обслуживание системы, построенной на ее основе, разрешение проблем и ответы на основные вопросы, возникающие в ходе интеграции Deductor в информационную систему предприятия. Книга предназначена для администраторов и IT-специалистов, которые обслуживают информационную систему. Специальных знаний в области анализа данных не требуется, но предполагается, что читатель знаком с основами работы платформы Deductor и может работать с операционной системой на уровне администратора.

Содержание Введение ....................................................................................................................................... 4 Установка Deductor ........................................................................................................................ 6 Установка программы................................................................................................................. 6 Установка ключа ........................................................................................................................ 6 Настройка доступа к сетевому ключу.......................................................................................... 6 Подготовка данных ........................................................................................................................ 9 Хранилище................................................................................................................................... 11 Когда создавать хранилище ..................................................................................................... 11 Создание хранилища................................................................................................................ 11 Процессы, измерения, факты и свойства .................................................................................. 12 Загрузка данных....................................................................................................................... 15 Оптимизация хранилища .......................................................................................................... 16 Резервирование и обслуживание.............................................................................................. 17 Оптимизация работы и создания сценариев ................................................................................. 19 Какие источники использовать ................................................................................................. 19 Кэширование ........................................................................................................................... 19 Динамические фильтры............................................................................................................ 20 Быстрая подготовка сценариев (скрипты)................................................................................. 21 Перенастройка узла ................................................................................................................. 23 Что делать при возникновении ошибок .................................................................................... 24 Пакетная обработка ..................................................................................................................... 26 Пакетное выполнение .............................................................................................................. 26 Пакетное обучение................................................................................................................... 26 Диагностика пакетной обработки ............................................................................................. 27 Тиражирование знаний ................................................................................................................ 29 Использование Viewer .............................................................................................................. 29 Разграничение прав с помощью Viewer..................................................................................... 29 Интеграция со сторонними системами .......................................................................................... 31 Импорт данных ........................................................................................................................ 31 Экспорт данных........................................................................................................................ 32 Заключение ................................................................................................................................. 33

Введение В процессе внедрения платформы Deductor в разных компаниях часто возникают вопросы, касающиеся не столько различных аспектов анализа данных, сколько чисто технической стороны работы с платформой. Например, каким образом настроить хранилище данных для сетевого доступа, как работать с аппаратным ключом защиты от копирования, как повысить производительность системы и устранить возникающие ошибки. Решение этих вопросов обычно возлагается на IT-специалиста – администратора системы – и не касается аналитика и, тем более, конечного пользователя. Это Руководство планировалось как сборник ответов на самые частые вопросы по установке и обслуживанию системы, призванный помочь администратору в развертывании аналитической платформы Deductor на предприятии. Вопросы анализа данных, построения сценариев, генерации отчетов, работы с визуализаторами подробно освещаются в «Руководстве аналитика». Здесь же акцент сделан на технической стороне интеграции платформы в информационную систему предприятия. Структура Руководства построена таким образом, чтобы вместе с читателем последовательно пройти все шаги, от первоначальной установки системы и разработки сценариев до оптимизации ее работы и текущего обслуживания. Руководство предназначено для ITспециалиста, уже знакомого с платформой Deductor, достаточно хорошо понимающего ее архитектуру и основные принципы работы. Процесс установки, настройки и обслуживания аналитической платформы Deductor включает несколько этапов, представленных на рисунке. На нем показаны также те аспекты разработки информационной системы, на которые следует обратить внимание на каждом этапе. Установка Deductor

Создание хранилища данных Оптимизация Создание сценариев обработки

Устранение ошибок

Настройка автоматической обработки

Обеспечение безопасности

Тиражирование знаний

Обслуживание

Каждый из этих этапов подробно рассматривается в соответствующих главах Руководства. Руководство в основном рассчитано на пользователей программ Deductor Professional, т.к. Deductor Lite сам по себе не нуждается в администрировании. Тем не менее, все разделы, за исключением установки и настройки ключа защиты от копирования, применимы и к версии Lite. В дальнейшем информация относится ко всем версиям программы, если явно не говорится об обратном. В главах Руководства освещаются следующие вопросы. В первом разделе «Установка Deductor» описывается процесс установки программы (для всех версий программы) и настройки аппаратного ключа защиты от копирования (для версии Deductor

4

Professional). Особое внимание уделяется настройки сетевого доступа к ключу. Здесь же можно найти информацию о порядке обновления Deductor. В главе «Хранилище» описывается работы с хранилищем данных с точки зрения администратора системы. Речь в ней пойдет о создании хранилища, настройке доступа к нему, оптимизации, текущем обслуживании и резервном копировании базы данных хранилища. В следующем разделе «Оптимизация работы и создания сценариев» подробно рассказывается об источниках данных, используемых Deductor, о механизмах быстрой разработки и настройки сценариев анализа данных. Здесь же говорится о типичных ошибках, встречающихся на этапе настройки платформы, создания сценариев и эксплуатации системы, и способах их устранения. Этот раздел в равной мере относится к аналитику и администратору системы. В главе «Пакетная обработка» речь пойдет о запуске Deductor в режиме автоматического переобучения нейронных сетей и автоматического выполнения сценариев, получивших общее название пакетная обработка. Раздел «Тиражирование знаний» посвящен вопросу использования программы Deductor Viewer, предназначенной для просмотра отчетов конечными пользователями аналитической информации. Здесь рассказывается о причинах использования Viewer и даются рекомендации по обеспечению безопасности информации при использовании платформы Deductor. В главе «Интеграция со сторонними системами» рассказывается о распространенном способе использования Deductor как промежуточной системы обработки и анализа данных. В этом случае потребуется интеграция Deductor с другими информационными системами. О способах такой интеграции и механизмах, включенных для этого в Deductor, рассказано в этом разделе.

5

Установка Deductor Перед началом работы с системой потребуется установить Deductor на рабочее место аналитика или пользователя. Обратим внимание на некоторые особенности этого этапа.

Установка программы Для установки Deductor следует запустить программу установки и следовать в дальнейшем ее инструкциям. На странице «Выбор компонентов» программы установки предоставляется выбор, какую программу из пакета Deductor установить на компьютер: Deductor Studio или Deductor Viewer. Studio предназначен для установки на рабочее место аналитика, в то время как Viewer устанавливается на компьютер конечного пользователя. Здесь же можно дополнительно указать, следует ли устанавливать «Руководство аналитика» и файлы примеров. Для программ серии Professional доступна установка драйверов Guardant. Для работы программы эти драйвера обязательно должны быть установлены. Кроме собственно драйверов при выборе этой опции выполняется копирование некоторых нужных для работы программы библиотек, поэтому отменять ее выбор не рекомендуется. По окончании копирования файлов программа установки выведет окно «Завершение Мастера установки Deductor». В случае работы программы с локальным ключом защиты от копирования (см. раздел «Установка ключа») при первой установке программы на компьютер здесь следует отметить флажок «Установить драйверы Guardant», чтобы были установлены драйверы ключа защиты от копирования. При повторной установке этого не требуется, так же как и при работе программы с сетевым ключом.

Установка ключа После установки программ серии Professional дополнительно потребуется настроить работу ключа защиты от копирования. Рассмотрим подробнее установку ключа защиты от копирования. Программы Deductor серии Professional работают только с установленным в системе аппаратным USB-ключом Guardant. В отличие от них, демонстрационные версии Deductor Lite работают без использования средств защиты от копирования, но позволяют оперировать только со 150 записями. Существуют два вида ключей – локальный и сетевой. Локальный ключ устанавливается на том же компьютере, что и Deductor, и работать с ним можно только с этой рабочей станции. Сетевой ключ устанавливается на сервере, и к нему могут подключаться несколько пользователей одновременно (количество пользователей ограничивается типом приобретаемой лицензии). Для настройки локального ключа нужно в процессе установки Deductor поставить галочку «Установить драйвера» и установить флажок «Установить драйверы Guardant» на появляющейся после окончания копирования файлов странице Мастера установки. После этого ключ следует установить в любой свободный порт USB, и программа полностью готова к работе. Драйвера для ключа будут загружаться автоматически каждый раз, когда ключ будет присоединяться к порту. Для настройки сетевого ключа на выделенном сервере устанавливается и запускается программа сервера Guardant, которая находится в файле nnksrv32.exe дистрибутива сервера. После этого рабочие станции получают доступ к сетевому ключу. Алгоритм работы программы с сетевым ключом несколько сложнее, чем с локальным. В следующем разделе особенности настройки сетевого ключа обсуждаются более подробно.

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

6

Для того чтобы ускорить процесс поиска сетевого ключа, нужно немного изменить настройки клиента Guardant, используемые по умолчанию. Для этого в текстовом редакторе следует открыть файл $(Deductor)\Bin\Gnclient.ini из каталога установки Deductor (по умолчанию $(Deductor) = C:\Program Files\BaseGroup\Deductor). В этом файле можно изменить следующие параметры: Используемый протокол для взаимодействия с сервером Guardant: в разделе [PROTOCOLS] находятся доступные протоколы (TCP/IP и NetBIOS). Приоритетом обладает протокол с меньшим номером. По умолчанию первым используется протокол TCP/IP. В разделе [TIMEOUT] находятся тайм-ауты для различных событий, связанных с взаимодействием клиента и сервера: тайм-аут запроса, тайм-аут ответа и тайм-аут широковещательного запроса. Изменять их следует на свой страх и риск, так как при загруженной сети пакеты в пути между клиентом и сервером могут находиться достаточно долго. В разделе [SERVER] находится информация о сервере Guardant, на основании которой клиент пытается установить соединение. Для взаимодействия клиенту и серверу требуются один порт TCP и два порта UDP. Причем номера соответствующих портов у клиента и сервера должны совпадать. Изменять значения по умолчанию имеет смысл, только если во внутренней сети эти порты уже используются другими службами. В этом же разделе находятся поля для задания IP-адреса сервера Guardant и широковещательного адреса. Здесь же указывается NetBIOS-имя сервера и включается или отключается широковещательный поиск. Чтобы отказаться от использования широковещательного запроса при поиске сетевого ключа, достаточно указать IP-адрес сервера и установить параметр SEARCH в значение OFF (SEARCH=OFF). Теперь клиент Guardant будет искать ключ только на указанном сервере. Аналогично можно поступить при использовании протокола NetBIOS – параметру NB_NAME присвоить NetBIOS имя сервера и отключить широковещательный поиск. Нужно отметить, что в сети не должно быть двух серверов Guardant с одинаковыми именами NetBIOS, иначе работать совместно они не смогут. Кроме того, можно заменить широковещательный адрес другим, например, групповым. В этом случае запрос при поиске сервера будет отправлен только на некоторые узлы сети. Необходимо отметить, что часто проблемы при настройке сетевых ключей возникают из-за установленного брандмауэра (файрвола). В этом случае Deductor не будет загружаться, выдавая через некоторое время после попытки запуска сообщение об отсутствии ключа. Кроме того, могут появляться окна брандмауэра с сообщениями о попытках доступа к портам, используемым Guardant, или появляться соответствующие записи в логе. В любом случае при установленном брандмауэре нужно проследить за тем, чтобы порты взаимодействия между клиентом и сервером были открыты на обоих компьютерах. В настройках брандмауэра можно указать приложения, которым разрешен доступ в сеть по указанным портам. На компьютере-клиенте это должен быть Deductor Studio или Viewer, на сервере – сервер Guardant. Еще одна особенность сетевых ключей состоит в том, что они могут поддерживать ограниченное число сессий (максимальное число определяется типом лицензии). Бывают ситуации, когда в результате некорректного завершения работы клиента на рабочей станции сессии на сервере не закрываются. То есть сервер считает, что к нему присоединен какой-то клиент, хотя в реальности это соединение уже не существует. В результате может наступить момент, когда все сессии ключа окажутся исчерпанными, и соединение с ним установить не удастся. В дистрибутив сервера Guardant входит программа «Монитор Guardant Net». Три версии этой программы находятся соответственно в файлах nnkmon.exe (консольная версия), nnkmonw.exe (оконное приложение) и nnkmon32.exe (усложненная версия двух предыдущих программ). После запуска каждая из этих программ ищет в локальной сети все установленные ключи Guardant и выводит получаемую от них информацию, в том числе о максимальном и текущем количестве открытых сессий. В nnkmon.exe и nnkmonw.exe они выводятся в столбцах «Макс.ресурс» и «Текущ.ресурс» соответственно, а в nnkmon32.exe в строке с информацией о ключе в следующем виде: «(Текущ.ресурс/ Макс.ресурс)». Если число текущих сессий равно максимальному, то открыть новое подключение к серверу Guardant будет невозможно. Чтобы не дожидаться, пока сервер сам автоматически отключит неиспользуемые сессии, в такой ситуации можно перезапустить службу сервера. Для этого следует щелчком мыши на значке сервера Guardant в трее вызвать всплывающее меню и выбрать пункт «Перезапустить сервер». После этого все сессии ключа будут завершены.

7

Замечание: при перезапуске сервера все реальные открытые сессии также будут принудительно закрыты, так что предварительно следует убедиться, не работают ли в это время с Deductor другие пользователи. Новые версии платформы Deductor Lite доступны для свободного скачивания на сайте компании http://www.basegroup.ru/. Обновление ключа для программ версии Professional может быть как платным, так и бесплатным, в зависимости от текущей поддерживаемой версии программы. Подробные инструкции по обновлению ключа находятся в документе «Порядок обновления ключа», поставляемом с версией Deductor Professional. Отсутствующую в нем информацию о возможности и порядке обновления можно узнать, отправив письмо по адресу [email protected].

8

Подготовка данных После установки программы начинается работа аналитика. Непосредственно анализ данных не связан с вопросами, касающимися администратора системы. Тем не менее, в процессе подготовки данных, создания хранилища, разработки сценариев и тиражирования полученных знаний у аналитика могут возникнуть трудности, которые потребуют вмешательства администратора. Они связаны в основном с низкоуровневой частью платформы или специфическими особенностями разработки сценариев, понять которые IT-специалисту будет проще. Сбор данных является одним из важнейших этапов анализа. Это касается не только формирования требований к тому, какие данные требуются для анализа, но и формы их представления. Deductor работает с данными, представленными в виде плоских таблиц. Источниками данных могут служить текстовые файлы с разделителями, файлы в формате приложений MS Access и MS Excel, базы данных Oracle, Interbase и MS SQL, к которым осуществляется прямой доступ, базы данных, поддерживающие доступ через драйверы ADO и ODBC, бизнес-приложения 1С:Предприятия и, наконец, хранилище данных Deductor Warehouse. Одним из назначений Deductor является консолидация данных, собранных из различных источников и имеющих разную природу, структуру, форму и назначение. Поэтому одним из первых этапов является приведение данных к одной форме представления. Это касается единой системы кодов, одинаковых типов и формата данных. Перекодировка, приведение типов и преобразование форматов данных могут осуществляться как внешними программами, так и средствами самого Deductor. Приведение типов и преобразование форматов данных может осуществляться средствами обработчиков «Калькулятор» и «Настройка набора данных». В «Калькуляторе» можно произвести расчет по любым формулам, в том числе с использованием логических и строковых функций, чтобы изменить тип или представление столбцов данных. В «Настройке набора данных» можно быстро поменять вид данных (дискретный или непрерывный), имя и метку столбца, тип данных. Данные в исходных таблицах должны быть представлены в простом виде, т.е. без сводных таблиц, агрегированных строк, примечаний и т.п. Данные в столбце должны быть одного типа. Недопускается, чтобы в одном поле в двух строках содержались данные разных типов, например, вещественного и строкового. Такие ситуации могут возникнуть со сложными источниками данных типа таблиц Excel. Перед импортом данных в Deductor следует предварительно проверить исходные таблицы на наличие таких проблем и устранить их. Следует особо обратить внимание на представление данных в таблицах Excel. С точки зрения Excel в таблицу входят все ячейки, в которые введена какая-либо информация; т.е. лист представляет собой одну системную таблицу, которая ограничивается заполненными ячеками. Поэтому на листе, данные с которого импортируются в Deductor, не должно быть никакой лишней информации, например, примечаний в конце таблицы или сводных строк. На листе должны находиться строка заголовка таблицы, а под ней – строки данных. Типы данных должны быть одинаковы для всех ячеек поля (это можно проверить в окне настройки формата ячеек). Если для импорта в Deductor предназначена таблица, занимающая лишь часть листа, то следует выделить эту таблицу и назначить ей имя в строке «Имя» панели инструментов. Тогда при импорте Deductor сможет получить доступ к этому диапазону ячеек, как к отдельной таблице. Требования к ее формату остаются теми же, что и для целого листа Excel.

Пример. Для примера на следующих двух рисунках представлены правильно оформленные для импорта данных в Deductor таблицы Excel.

Задание имени диапазону ячеек:

9

На следующих трех рисунках показаны примеры неверно оформленных таблиц.

В таблице не должно быть примечаний

В таблице не должно быть сводных строк

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

10

Хранилище После подготовки таблиц с исходными данными можно перейти к следующему этапу – созданию хранилища данных. В стандартном варианте решения Deductor получает данные для анализа из хранилища, но существуют ситуации, в которых создавать его не требуется. Решение этого вопроса ложится на плечи администратора системы.

Когда создавать хранилище Хранилище данных предназначено для консолидации разрозненных данных и оптимизации доступа к ним. Загрузка данных в хранилище производится гораздо (на порядки) медленнее, чем извлечение данных. Объясняется это самой целью его создания. Загрузка данных в хранилище может производиться в ночное время или выходные, без отрыва пользователей от работы. Извлечение же должно осуществляться с минимальными задержками, чтобы обеспечить возможность экспресс-анализа и снизить задержки для пользователей. Deductor может работать с Deductor Warehouse, совершенно так же, как с любым другим источником данных. Тем не менее, существует несколько причин создания хранилища. Основным достоинством хранилища с точки зрения аналитика является удобное представление данных. Оно обеспечивает семантическую прослойку между реляционной базой данных и предметной областью. В результате работа с данными из хранилища осуществляется в терминах предметной области (в бизнес-терминах). Удобство такого представления для анализа данных трудно переоценить, и это является наиболее частой причиной создания хранилища. Вторая причина, по которой может потребоваться создание хранилища, появляется в тех случаях, когда данные для анализа находятся в разных источниках. Например, на предприятии есть две разные учетные системы для бухгалтерии и управления складом, а в анализе и при построении отчетов используются данные из двух сразу. Хранение данных в одном месте ускоряет доступ к данным, позволяет еще на этапе консолидации избежать появления дублирующихся или противоречивых данных, значительно упрощает разработку сценариев. Кроме того, гораздо проще становится внесение изменений в аналитическую систему – при переходе, например, на другую учетную систему не потребуется перенастройка всех существующих сценариев, достаточно будет изменить сценарий загрузки данных в хранилище. Третья причина – используется медленный источник данных. Например, данные для анализа забираются из ADO-источника или конфигурации 1С:Предприятия. В этом случае каждый раз при выполнении сценария потребуется импортировать данные из медленного источника, что приведет к заметным задержкам в работе системы. Применяя хранилище данных в этом случае, можно всего один раз загрузив в него данные, в дальнейшем быстро забирать их оттуда по мере необходимости. Хранилище данных не требуется, когда исходные данные для анализа находятся в быстрой базе данных предприятия уже в нужном виде и их дублирование в новом источнике не имеет смысла. Кроме того, оно может стать излишним, когда Deductor используется для некоторой промежуточной обработки данных, результаты которой будут сохраняться в БД, и при работе с данными малого объема (например, при «прогоне» нескольких строк данных через построенную модель). Решение о необходимости создания хранилища должно приниматься индивидуально в каждом случае, в зависимости от особенностей существующей информационной системы предприятия и задач анализа, стоящих перед платформой.

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

11

расположены источники данных, а уже после переместить хранилище на сервер. Объясняется это очень просто. Во время первой загрузки в хранилище обычно перекачивается очень большой объем накопленных в учетных системах данных, что занимает много времени. При этом могут возникнуть проблемы с производительностью сети. Кроме того, локальная загрузка в общем случае будет происходить быстрее. В дальнейшем при добавлении в хранилище новых порций данных таких проблем возникать не будет, так как их объем, скорее всего, будет на порядки меньше того, который загружается первоначально. Перемещение хранилища с одного компьютера на другой осуществляется обычным копированием файла хранилища. После этого следует в Deductor настроить параметры доступа к хранилищу (подключение к хранилищу). Создание локального хранилища и подключение к нему подробно описаны в «Руководстве аналитика Deductor» в главе «Архитектура Deductor Warehouse – многомерное хранилище данных». Сейчас более подробно рассмотрим вопрос подключения к Deductor Warehouse по локальной сети. Подключение производится, как и в случае локального хранилища, на панели «Источники данных». Для начала с помощью пункта всплывающего меню «Добавить хранилище данных» из списка «Добавить источник данных» следует создать новый узел хранилища данных. После этого в дереве источников данных откроем двойным щелчком мыши на созданном узле окно свойств хранилища. В нем производятся все настройки подключения. Имя и описание хранилища указываются так же, как и для локального хранилища. Имя может состоять из латинских символов, цифр и знака подчеркивания, причем не может начинаться с цифры. Описание представляет собой произвольную текстовую строку. В поле «База данных» требуется указать опции подключения к удаленной базе данных, в которой находится хранилище. в правой Для этого следует вызвать расширенный диалог редактора строки щелчком на кнопке части строки. В появившемся окне следует выбрать удаленное подключение и указать сетевой протокол. Протоколом, скорее всего, будет TCP, хотя возможен выбор других вариантов (IPX или named pipes). В строке «Сервер» следует ввести IP-адрес или имя сервера, на котором находится хранилище данных. Содержание этого поля зависит от выбранного протокола. Для TCP указывать символьное имя сервера нельзя. В поле «База данных» следует указать путь к файлу хранилища, как он выглядит для самого сервера. Например, D:\BaseGroup\Warehouse\Warehouse.gdb, где «D:» - имя локального диска сервера (не сетевого диска!). По окончании редактирования параметров подтверждаем внесенные изменения нажатием кнопки «Ok» и проверяем соединение с помощью «Тестирование». При появлении окна с сообщением «Тестирование соединения прошло кнопки успешно» настройку подключения к хранилищу можно считать законченной. Осталось сохранить настройки источников данных и можно приступать к работе с хранилищем.

Процессы, измерения, факты и свойства Первым этапом после настройки подключения к хранилищу данных является проектирование его структуры, т.е. создание в хранилище процессов и измерений. Этому важному вопросу уделяется большое внимание в «Руководстве аналитика» (глава «Многомерное представление данных»). Здесь внимание будет заострено на том, как грамотное построение хранилища может сказаться на администрировании и быстродействии системы. Процессы в хранилище создаются, исходя из требований предметной области и задач анализа. Но следует четко понимать, что избыток данных в хранилище может быстро привести к проблемам, связанным с потерями производительности и требованиями к огромному дисковому пространству. Например, в хранилище не следует загружать информацию об остатках товаров на каждый день, неделю или месяц. Такие данные имеют громадный объем и несут мало практически ценной информации. Они разрастаются с высокой скоростью, быстро превращая хранилище в свалку. Остатки товаров стоит хранить только на текущий момент времени или через большие периоды времени (например, по итогам месяца, года). Информация об остатках на произвольный момент времени требуется очень редко, и проще бывает получить ее посредством учетной системы. В крайнем случае, можно рассчитать остатки на основании других данных, например, о начальных остатках и проведенных транзакциях. При работе только с текущими остатками перед загрузкой новых данных следует удалять из хранилища старые. Для этого процесс «Остатки» очищается по специально созданному фиктивному измерению, например, с именем «Текущие остатки» и значением «1» во всех записях. В этом случае перед началом загрузки строится список уникальных значений измерения «Текущие

12

остатки», имеющихся в наборе исходных данных. Такое значение будет одно – «1». Затем из процесса хранилища удаляются все записи, у которых значение измерения «Текущие остатки» находится в этом списке (равны 1), т.е. процесс полностью очищается. Таким образом, перед новой загрузкой все данные из процесса «Остатки» будут автоматически удаляться. При создании процессов часто возникают два вопроса – когда следует использовать вспомогательную таблицу и очистку по измерению. Вспомогательная таблица предназначена для ускорения доступа к данным. Она позволяет значительно (на порядок) ускорить операции по извлечению данных из хранилища. Тем не менее, создавать вспомогательную таблицу следует не всегда. Во-первых, она не требуется при работе с маленькими процессами (мало измерений, мало данных), в этом случае прирост производительности не будет заметен. Во-вторых, вспомогательную таблицу следует создавать только после загрузки всех данных в процесс. Т.е. если в сценарии данные загружаются в процесс по частям, в нескольких узлах, то создавать вспомогательную таблицу следует только в последнем узле загрузки. В противном случае будет бессмысленно затрачено лишнее время, так как перед каждой загрузкой данных в процесс она будет удаляться, а затем создаваться заново. Очистка процесса по измерению используется для значительного (на один-два порядка) ускорения загрузки данных в хранилище. В этом случае не выполняются проверки на существование записи в процессе, а сразу же выполняется ее загрузка. Тем не менее, иногда могут возникать проблемы, связанные с потерей данных. Суть их состоит в следующем. Если производится обновление данных, то загружаемый блок данных должен содержать все записи по удаленному измерению. Рассмотрим следующий пример. В процессе хранилища содержатся записи книги продаж. При загрузке данных в хранилище производится очистка процесса по дате продажи. За 20 июня 2005 года содержатся 10 записей. Потребовалось изменить количество проданного товара в одной из этих записей, для чего эта запись загружается в хранилище. В этом случае из процесса будут удалены все записи за 20 число, а потом загружена только одна, в которой требовалось изменить количество. Получается, что остальные записи будут потеряны. В этом случае следовало, не устанавливая флаг очистки по измерению, просто загрузить нужную запись. При установке флага очистки по измерению всегда стоит иметь в виду, что добавление или обновление данных по существующему значению измерения может корректно проводиться только при загрузке всех строк для этого значения измерения. В предыдущем примере при установленном флаге очистки по измерению для корректного обновления данных в процесс следовало загрузить все 10 записей. В этом случае у записей за 20 июня были бы обновлены факты, а потерь информации при этом бы не произошло. Если в скрипте производится загрузка данных в процесс частями, то флаг очистки по измерению следует указывать только в первом узле загрузки. Таким образом, для сложного сценария загрузки данных в процесс следует использовать следующую последовательность операций: Очистить процесс по измерению при загрузке

Загрузка данных без дополнительных параметров

Загрузка данных без дополнительных параметров

Загрузка данных с созданием вспомогательной таблицы

13

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

Процесс Точка в пространстве с координатами (Измерение 1; Измерение 2; Измерение 3). Свойством точки является ее цвет.

Измерение 1 Измерение 2

На практике часто встречаются ситуации, когда данные в процессе работы могут изменяться. Например, поменялось наименование клиента. Если наименование клиента было измерением, то обновить его в хранилище не удастся. В этом случае возможны три варианта действий. Во-первых, при загрузке данных в хранилище можно преобразовывать новое наименование клиента к старому. Во-вторых, ввести в хранилище нового клиента. И, в-третьих, удалить все данные из процесса и загрузить их заново, с измененным наименованием. У каждого из этих вариантов множество недостатков, и ни один из них полностью не решает проблемы. Обычно в таких ситуациях на этапе проектирования структуры хранилища для наименования, которое может изменяться в процессе работы, создается числовой индекс. Этот индекс является измерением, а все важные атрибуты объекта, включая наименование, при этом хранятся в свойствах.

Пример. Дана такая исходная таблица отгрузок некоторого товара клиентам. Дата

Клиент

Количество

01.01.2004

ООО «Стройсервис»

10

01.01.2004

ЧП «Иванов»

12

02.01.2004

ЧП «Иванов»

14

03.01.2004

ООО «Стройсервис»

9

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

14

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

Таблица 2

Индекс

Клиент

Дата

Клиент

Количество

1

ЧП «Иванов»

01.01.2004

1

10

2

ООО «Стройсервис»

01.01.2004

2

12

02.01.2004

2

14

03.01.2004

1

9

Таблицу 1 в хранилище загрузим как измерение «Клиенты», а таблицу 2 – как процесс «Отгрузки». Теперь при импорте данных из процесса нельзя отфильтровать выборку по наименованию клиента. Зато в измерении «Клиенты» наименование любого клиента можно легко поменять или добавить к нему новые свойства, например, регион.

Загрузка данных После создания структуры хранилища нужно заполнить его данными. Данные будут выбираться из исходных таблиц, сформированных на этапе «Подготовка данных» и загружаться в созданные на этом шаге объекты хранилища. Существуют два типа загрузки данных в хранилище – первоначальная и инкрементная. Первоначальная загрузка осуществляется при первом после установки системы заполнении хранилища, она помещает в хранилище большой объем данных, накопленных в учетной системе. Такая загрузка обычно осуществляется только один раз, при настройке системы. Из-за большого объема загружаемых данных она может занимать длительное время. Инкрементная загрузка выполняется регулярно, она добавляет в хранилище вновь появившиеся или измененные с момента последней загрузки хранилища данные. Объем загружаемых данных здесь сравнительно невелик, поэтому времени такая загрузка занимает гораздо меньше первоначальной. Дополнительно ускорить инкрементную загрузку можно с помощью очистки процесса по измерению (см. предыдущий раздел). Инкрементная загрузка обычно производится в автоматическом режиме, по расписанию. Для этого создается отдельный сценарий загрузки хранилища, и с помощью какой-либо программыпланировщика (например, Windows Scheduler) планируется запуск Deductor в пакетном режиме для его выполнения. Загрузку данных удобно осуществлять в ночное время или выходные дни, когда свободны сетевые ресурсы и хранилище не используется для работы. Схематично процесс загрузки изображен на рисунке.

15

Создание сценария загрузки

Планировщик В День:Час выполнить: Deductor.exe /run

Загрузка данных в хранилище

Сценарий загрузки должен выполнять следующие функции: 1. Импорт данных в Deductor из базы данных, учетной системы или предопределенных файлов; 2. Опциональная предобработка данных, например, очистка или преобразование формата; 3. Загрузка данных в измерения и процессы хранилища. Перед импортом данных в Deductor они могут быть обработаны любой другой программой и сохранены в согласованном со сценарием загрузки формате. Например, в предопределенные таблицы базы данных или в определенные файлы заданного каталога. В таком случае сценарий загрузки данных настраивается на использование в качестве источников данных этих временных таблиц или файлов. Каталог Файл 1 Файл 2 …

Сценарий загрузки данных

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

Сценарий загрузки данных

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

Файл N

База данных Таблица 1 Таблица 2 … Таблица N

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

Оптимизация хранилища Может оказаться, что созданное и загруженное хранилище данных работает очень медленно. Объясняется это тем, что для повышения быстродействия хранилища требуется выполнить несколько дополнительных операций с СУБД, на которой построено Deductor Warehouse. Хранилище данных Deductor Warehouse основано на свободно распространяемой реляционной СУБД Firebird ver.1.5. В пакет установки Deductor включена динамическая библиотека для доступа

16

к базам данных Firebird. С помощью этой библиотеки возможен как прямой доступ к базе данных, так и подключение к серверу СУБД. Без установки сервера Firebird возможна работа только с локальным хранилищем данных, причем Deductor будет подключаться к нему в монопольном режиме, то есть работать с хранилищем в каждый момент времени сможет только одно приложение. Установка сервера Firebird на компьютер, на котором расположено хранилище, позволяет не только открыть доступ к удаленному хранилищу, но и значительно ускорить работу с локальным. Скачать последнюю версию сервера Firebird и документацию к нему можно с сайта разработчиков http://www.ibphoenix.com/. Первое, что следует сделать после установки сервера, это скопировать в подкаталог Udf каталога установки Firebird (при установке по умолчанию – в каталог C:\Program Files\Firebird\Udf) динамическую библиотеку для работы со строками rfunc.dll. Эта библиотека находится в каталоге $(Deductor)\Bin\Udf (при установке по умолчанию – в каталоге C:\Program Files\BaseGroup\Deductor\Bin\Udf). Использование этой библиотеки обработка увеличивает сокрость обработки строковой информации в базе данных хранилища в несколько раз. Теперь нужно изменить некоторые параметры в файле настроек сервера. Файл настроек Firebird находится в каталоге установки (по умолчанию C:\Program Files\Firebird) в файле firebird.conf. В нем следует сделать следующие настройки. Во-первых, следует установить количество кэшируемых в памяти страниц базы данных. Для этого параметру DefaultDbCachePages следует присвоить нужное значение. Выбирать его следует, исходя из доступного объема оперативной памяти. Объем памяти, занимаемый кэшем базы данных, равен значению DefaultDbCachePages, умноженному на размер страницы базы данных (по умолчанию 4 кб). Это значение не должно превышать размер свободной памяти, остающейся после загрузки операционной системы и приложений. В противном случае операционная система начнет выгружать кэш базы данных на жесткий диск и лишь еще больше замедлит обращения к базе. Firebird активно использует временные файлы для хранения промежуточных данных, например, при сортировке. Серьезно поднять скорость работы при выполнении подобных операций можно, если использовать для создания этих временных файлов раздел в оперативной памяти (так называемый memory disk). Существуют различные инструменты для создания таких разделов. Например, RamDisk. После создания диска в памяти следует указать Firebird, чтобы тот использовал диск в ОЗУ для хранения временных файлов. Для этого параметру TempDirectories из файла настроек следует присвоить имя созданного диска, после чего будет происходить кэширование временных файлов в памяти. Остальные параметры сервера Firebird не оказывают заметного влияния на производительность системы. Однако для того чтобы работа хранилища не замедлялась с течением времени, дополнительно потребуется производить текущее обслуживание базы данных хранилища.

Резервирование и обслуживание В процессе добавления и удаления данных из базы данных хранилища, возможна ее фрагментация. Сильная фрагментация базы может значительно замедлить ее работу, поэтому рекомендуется проводить периодическое обслуживание хранилища. Для этого следует проводить резервирование и восстановление базы данных с помощью дополнительных инструментов. Одним из них является свободно распространяемая программа IBExpert от HK Software, доступная для скачивания на сайте http://www.ibexpert.com/. Рекомендуется проводить подобную операцию каждый раз при добавлении больших объемов данных в хранилище. Резервирование базы может проводиться не только для дефрагментации, но и для сохранения копии на случай сбоя сервера. В этом случае после восстановления потребуется загрузить в хранилище только информацию, обновленную с момента последнего резервирования. Для выполнения резервирования и дефрагментации данных в базах Firebird в автоматическом режиме существует набор командных файлов от группы разработчиков Polaris Software под общим названием ibbat. Свободно скачать этот продукт можно на сайте группы http://polesoft.narod.ru/. Для установки этих скриптов следует распаковать архив с файлами в один каталог. В файле readme.txt находится подробная информация о настройке и использовании этих скриптов. Настройки вносятся в файле ibsettings.bat. Для базы данных хранилища они будут следующими:

17

set ibserver=fb set ibversion=6 set ibpath= set basepath= set backuppath= set user= set password=

Остальные параметры конфигурации можно оставить без изменений, конечно, при условии, что соответствующие настройки сервера Firebird не менялись самостоятельно. Для создания резервной копии базы данных хранилища теперь всего лишь нужно запустить командный файл ibbackup.bat. Для восстановления из резервной копии – файл ibrestore.bat. Для дефрагментации базы данных предназначен скрипт ibrefresh.bat. Для проверки физической целостности и восстановления базы данных в случае незначительных повреждений служат файлы ibvalid.bat и ibrepair.bat. Таким образом, для периодической дефрагментации базы данных хранилища следует настроить Windows Scheduler на запуск в нужное время скрипта ibrefresh.bat. Для резервирования базы с проверкой целостности и автоматическим исправлением ошибок следует подготовить в каталоге со скриптами еще один командный файл следующего содержания: : Параметры: : 1 - имя GDB-файла без расширения @echo off call ibsettings.bat if not %2.==. set password=%2 echo Проверка базы данных... %ibpath%gfix -validate -full -user %user% -pass %password% %basepath%%1.gdb if errorlevel 1 goto exit echo *** Проверка базы данных %1 закончена! echo *** Обнаружены ошибки в базе данных %1. Исправление… call ibrepair.bat %1 :exit call ibbackup.bat %1 :end

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

18

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

Какие источники использовать Deductor может одинаково успешно работать с большим количеством разнообразных источников данных. Однако скорость извлечения данных во многом определяется типом используемого источника. При создании законченного решения этот фактор становится очень важным, так как оперативность получения аналитической информации имеет большое значение на практике. Самыми быстрыми источниками данных являются хранилище Deductor Warehouse, базы данных, подключаемые напрямую (MS SQL, Oracle) или через драйверы ODBC, и прямой доступ к текстовым файлам и файлам dbf. Остальные источники работают значительно медленнее. Использовать для получения данных источники, подключаемые через интерфейс ADO, следует только в крайнем случае, при отсутствии других возможностей доступа, как, например, к таблицам MS Excel и MS Access. На больших объемах данных доступ к текстовому файлу через ADO гораздо медленнее прямого доступа. Кроме того, при прямом доступе можно указать большое число настроек разбора текстового файла. Подключение к базам данных через ADO приводит к тому, что загрузка данных в процесс хранилища из таблицы DBF занимает в 10-12 раз больше времени по сравнению с прямым доступом к этой таблице. Очень медленным источником данных является конфигурация 1С:Предприятия. Тем не менее, удобство работы с ней напрямую часто превосходит недостаточное быстродействие. Для того чтобы ускорить загрузку в Deductor данных из 1С:Предприятия следует пользоваться механизмом внешних отчетов 1С. В этом случае подготавливается отчет, в котором нужные данные выгружаются в таблицы dbf (гораздо быстрее использования текстового файла), и уже из них производится загрузка данных в Deductor. Если для загрузки данных в хранилище применять пакетную загрузку, настроив ее запуск на ночное время, то создание промежуточных отчетов может и не потребоваться. Объем данных, хранимых в конфигурациях 1С:Предприятия обычно не очень велик (сотни тысяч строк в документах, тысячи в регистрах и справочниках). Вдобавок к этому документы будут загружаться только за последний период, и это не займет много времени. Справочники можно загружать изредка, только при появлении в них изменений. Поэтому наибольшее время займет загрузка регистров. По опыту работы, 1С:Предприятие с базами на основе MS SQL работает при прямой выгрузке данных быстрее, чем при использовании баз dbf. В случае неизбежности получения данных из медленных источников (ADO, 1С:Предприятие) обычно следует их загружать в хранилище Deductor Warehouse. При активной работе с данными это позволит гораздо меньше задумываться о вопросах производительности при импорте данных в программы Deductor.

Кэширование Значительно увеличить скорость выполнения сценариев может установка в «узких» местах кэша данных в оперативной памяти. Кэширование данных включается при установке в узле «Настройка набора данных» флажка «Кэшировать выходной набор данных». В результате данные, получаемые на выходе этого узла, будут полностью загружены в память. Обращение к ним будет происходить гораздо быстрее, но за счет дополнительных затрат памяти. По умолчанию Deductor работает с данными таким образом, чтобы минимизировать объем используемой памяти. Каждый раз, когда какому-нибудь узлу требуется новая порция данных, он обращается к родительскому узлу с запросом на ее предоставление. Если в родительском узле данные не закэшированы, он в свою очередь отправляет запрос вверх по иерархии, и так далее, пока данные не будут получены. В предельном случае, узлом, предоставляющим данные, может стать узел импорта данных. Таким образом, в Deductor применен подход уменьшения требуемого объема памяти за счет роста количества вычислений, необходимых для получения каждой порции данных.

19

Обычно внутренняя организация работы программы не имеет особого значения. Тем не менее, могут возникать такие ситуации, когда хранение полной копии данных в некотором узле может радикально повысить скорость выполнения сценария. Для примера рассмотрим следующие ситуации. В узле «Калькулятор» (или любом другом) производятся сложные и объемные расчеты, причем данные из этого узла и его потомков активно используются при визуализации в интерактивном режиме. В этом случае каждый раз при отображении данных могут возникать задержки, связанные с тем, что каждый раз в «Калькуляторе» производятся расчеты. Установка узла кэширования после него позволит работать при каждом обращении к данным с единожды рассчитанными результатами. Узел является родительским для нескольких ветвей обработки. В этом случае каждая ветка будет независимо от остальных запрашивать данные у этого узла. Ему, в свою очередь, потребуется обращение на верхние уровни. Таким образом, одни и те же данные будут многократно запрашиваться и обрабатываться вышестоящими узлами. В этом случае удобней было бы после этого узла установить узел кэширования, и уже из него наследовать ветви последующей обработки. Существуют некоторые ситуации, в которых кэширование данных приведет лишь к избыточным ненужным затратам памяти: Кэширование данных после узла импорта не имеет смысла, так как в узле импорта уже присутствуют все данные внешнего источника. Не имеет смысла кэшировать данные после каждого узла обработки. Это не даст большого прироста скорости, но на больших объемах данных очень быстро исчерпает имеющиеся ресурсы памяти. Кэширование следует применять только в «узких» местах сценария, где это действительно дает заметный прирост производительности. Не имеет смысла кэширование данных перед узлами, выполняющими нормализацию данных. Это узлы, построенные на нейронных сетях (Нейросеть, карты Кохонена), Ассоциативные правила, Дерево решений, Линейная регрессия и Пользовательская модель. При нормализации в любом случае осуществляется преобразование данных, после которого они кэшируются в память специальным образом. Следует отметить, что кэшировать имеет смысл относительно небольшие объемы данных, размер которых не превышает свободные ресурсы оперативной памяти. Если в результате установки кэша данные не поместятся полностью в оперативную память, операционная система начнет выгружать их на жесткий диск в файл подкачки. В результате обращений к жесткому диску работа сценария может замедлиться даже по сравнению с работой в отсутствие кэша.

Динамические фильтры Ключевым моментом, сказывающимся на скорости получения результатов, служит объем анализируемых данных. В некоторых случаях существует возможность значительно уменьшить объем получаемых из хранилища по запросу пользователя данных, установив в узле импорта данных пользовательский фильтр. При построении отчета часто возникает ситуация, когда пользователю требуется просмотреть его в некотором узком разрезе. Например, его интересует информация по конкретному поставщику и товару, или продажи за последний месяц, или отчет по работе одного дилера. Так как заранее предсказать конкретный запрос пользователя и создать на каждый запрос отдельный отчет физически невозможно, появляется необходимость в динамической генерации отчетов. Отчасти такую проблему решает использование OLAP-кубов. При этом можно посмотреть доступные данные в любом разрезе, отфильтровав ненужное. Минусом такого подхода является то, что из хранилища данных в этом случае выбирается большой объем избыточной информации. Если пользователю нужен отчет по одному поставщику, из хранилища все равно будут выбраны данные по всем поставщикам. При активной работе с хранилищем нескольких пользователей это может значительно замедлить получение ими затребованной информации. Кроме того, избыток измерений в кубе усложняет работу с ним и увеличивает усилия, затрачиваемые на получение каждого отчета. Для решения этой проблемы в Deductor введен механизм динамических (или пользовательских) фильтров. Эти фильтры становятся доступными при импорте данных из хранилища. При создании

20

узла импорта на странице настройки среза есть возможность для каждого фильтра установить флаг «Определить при выполнении». Его установка включает пользовательский фильтр. Когда узел импорта будет выполняться в следующий раз, на экран будет выведено окно настройки среза с предложением указать нужный разрез извлекаемых данных. Пользователь имеет выбор, оставить разрез, предлагаемый аналитиком по умолчанию, или задать свои настройки выбираемых данных. После задания разреза и закрытия этого окна программа начнет импорт данных из хранилища. При этом будут извлекаться только данные, которые удовлетворяют условиям фильтрации, заданным пользователем. Если пользователь выбрал одного поставщика, то будут получены данные только по этому поставщику, благораря чему нагрузки на сервер хранилища данных и сеть заметно уменьшаются. Сценарий затем обрабатывает полученные данные в обычном режиме и выдает на выходе отчет в ранее определенном виде, но уже только в том разрезе, в котором он затребован пользователем. Другой механизм создания динамических отчетов заключается в использовании фильтров за период. Например, часто возникает задача сравнить два последних отчетных периода (месяца, квартала или года). В этом случае при импорте из хранилища или в обработчике «Фильтрация» по измерению «Дата» устанавливается фильтр, в котором указывается условие – отобрать два последних месяца от имеющихся данных. На выходе фильтра получим выборку, содержащую только эти два периода. Фильтр «от имеющихся данных» позволяет работать только с фактически имеющимися в фильтруемом измерении периодами времени. Если в измерении «Дата» присутствуют данные за период с 10 января 2005 по 27 мая 2005, а сегодняшнее число 14 июля 2005, то в предыдущем примере получим данные за апрель и май 2005 года. Указав тот же период, но от текущей даты, получим данные уже за июнь и июль. В приведенном примере, так как информации за эти месяцы еще нет в хранилище, то на выходе получим пустой набор данных. Фильтр «от даты» позволяет использовать в качестве точки отсчета конкретную дату. При построении прогноза часто бывает так, что данные за последний и первый периоды не полные. Например, при месячном прогнозе есть данные только за период с 14 числа первого месяца по 10 число последнего. Если учитывать их при построении модели прогноза, то получим резкое падение продаж за последний месяц, а это может сильно исказить результаты прогноза. Влияние первого месяца значительно слабее, но также может сказаться, например, при выявлении сезонности. Поэтому перед тем, как строить прогноз, следует удалить эти данные из выборки. Для этого можно воспользоваться фильтром при импорте данных из хранилища или обработчиком «Фильтрация» с динамическими фильтрами «кроме первого периода от имеющихся данных» и «кроме последнего периода от имеющихся данных».

Быстрая подготовка сценариев (скрипты) Оптимизировать требуется не только источники данных или сценарии обработки, но и работу аналитика по подготовке проектов анализа данных. Deductor включает в себя инструменты, использование которых поможет в разы ускорить создание сценариев и избавить аналитика от рутинной работы. Ускорить разработку сценариев и предоставить возможность повторного использования однажды созданной модели призван обработчик «Скрипт». Он является аналогом функции или процедуры в языках программирования. Алгоритм работы скрипта определяется последовательностью настроенных обработчиков, входящих в его состав, а входным параметром служит поступающий набор данных. При добавлении в проект узла «Скрипт» требуется указать начальный и конечный узлы, находящиеся на одной ветви обработки. В скрипт войдут все узлы от начального до конечного включительно. В скрипте нельзя выполнить настройку отдельного узла. Скрипт является законченным блоком обработки. Изменить работу скрипта можно, только поменяв настройки узлов в его ветви-оригинале. Внесенные в нее настройки сказываются на работе скрипта. Исходя из сказанного, переобучать нейронные сети, входящие в состав скрипта, также можно только в веткеоригинале. В состав скрипта может войти любой узел, кроме узла импорта данных, то есть он может включать и другие скрипты. Импорт данных не может входить в состав скрипта по тем соображениям, что основное назначение скрипта состоит в обработке нового набора данных на уже существующей модели. Поэтому не имеет смысла пропускать через него те же данные, что и в оригинальной модели. На рисунке показана схема выполнения ветви со скриптом, включающим три узла из другой ветки сценария. Сначала, до узла со скриптом, последовательно выполняются узлы второй ветки. Затем

21

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

Ветка 2 Выполнение ветки 1 Выполнение ветки 2

1 2

Скрипт

3

На основе скриптов могут быть реализованы три этапа обработки данных: предобработка, анализ и постобработка. После импорта данных в программу осуществляется их предобработка (1 этап). Предобработка может быть одинаковой для различных наборов данных (например, сглаживание, очистка, фильтрация, сортировка и т.д.), поэтому в других ветвях можно выполнить ее с помощью скрипта. Затем данные проходят через построенную аналитическую модель, например, строится прогноз на базе линейной регрессии (2 этап). Если данные подчиняются одним и тем же закономерностям (в этом примере временной ряд является линейным), то аналитическую модель можно построить только для одного набора данных, а для остальных использовать обработку на основе скриптов. После окончания этапа анализа данные подвергаются постобработке (3 этап), для того чтобы перевести их на язык предметной области и представить пользователю в удобном виде. Этот этап также может быть реализован в виде скриптов. Схема возможного включения скриптов в ветви сценария показана на рисунке.

22

Ветка 1

Ветка 2

Импорт данных

Предобработка

Импорт данных

Скрипт предобработки

Скрипт анализа Анализ

Постобработка

Скрипт постобработки

Любой из этих скриптов может отсутствовать, а между двумя скриптами могут находиться произвольные узлы обработки. Дополнительное преимущество, даваемое применением скриптов в проектах, состоит в возможности избежать ошибок и легкости модернизации сразу всех моделей обработки данных. При обнаружении ошибки достаточно исправить ее в одном месте, в ветке-оригинале, и она автоматически исправляется во всех остальных ветвях, где используется скрипт. Аналогично изменение исходной модели синхронно скажется на всех ветвях обработки, построенных на скриптах. Наряду с уменьшением размера файла проекта и ускорением его загрузки, простота внесения изменений является основным преимуществом использования скриптов перед копированием ветви сценария (см. «Руководство аналитика», глава «Подготовка сценариев»).

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

23

Что делать при возникновении ошибок В ходе обработки данных с использованием Deductor могут возникать различные ошибки. Иногда определить причину возникновения той или иной ошибки нелегко, но существуют некоторые рекомендации, которые помогут определить место и причину появления ошибки и исправить ее. Локализация и устранение ошибок в равной мере ложатся на плечи аналитика и администратора системы. В процессе выполнения сценария обработки возможно появление различных ошибок, о которых Deductor будет сообщать пользователю. Рассмотрим способы решения некоторых из них. Первое, что следует сделать при появлении окна с сообщением об ошибке – это установить источник сообщения. Если сообщение об ошибке исходит от операционной системы, значит, возникли серьезные неполадки в ее работе или работе программы. К сообщениям операционной системы, в частности, относятся все, связанные с ошибками доступа к памяти (access violation). В этом случае следует перезапустить программу, возможно, с перезагрузкой компьютера. Если ошибка не исчезает, отправьте описание своих действий, текст сообщения об ошибке, конфигурацию используемых аппаратных и программных средств и, по возможности, набор входных данных разработчикам программы по адресу [email protected]. Описывать ошибку следует как можно более подробно, так чтобы разработчики смогли ее повторить и установить причину возникновения. Информация о способах устранения ошибки будет выслана в ответном письме. Эти же действия следует выполнить, если Deductor некорректно самостоятельно завершает работу («падает») или зависает. Если сообщение об ошибке исходит от Deductor, следует определить место и причину ее возникновения. Ошибка, как правило, возникает при выполнении какого-либо определенного узла. В интерактивном режиме этот узел можно определить вручную, последовательно выполняя все узлы сценария. В пакетном режиме – с помощью подробного лога, в который записывается информация о выполнении каждого узла. После определения места возникновения ошибки следует внимательно ознакомиться с текстом сообщения. В нем обычно есть краткая информация о причинах ошибки. Например, сообщение «Столбец XXX должен существовать в исходном источнике данных» говорит о том, что столбец, обрабатываемый в узле, был удален из набора данных, либо у него просто поменялось имя. Такая ошибка возникает при перенастройке вышестоящих узлов или появлении изменений в источнике данных. Для ее устранения нужно либо откатить внесенные перенастройкой изменения, либо перенастроить узел, вызывающий ошибку, на работу с новым набором данных. Часто ошибки вызываются тем, что в наборе данных появляются пустые значения (NULLзначения). Многие обработчики не способны работать с полями, содержащими пустые значения. Это касается, прежде всего, обработчиков группы Data Mining. Пустые значения могут появиться из-за изменений в источнике данных, перенастройки узлов, особенностей обработки некоторых граничных значений в узлах и т.д. От пустых значений следует избавляться с помощью фильтрации или табличной замены. Фильтрация полностью убирает из набора данных строки, содержащие пустые значения в указанных полях. С помощью же табличной замены можно поменять пустые значения на другие, нейтральные для дальнейшей обработки, например, на ноль. При импорте данных из текстового файла и экспорте данных в хранилище по окончании операции возможно появление лог-файла, открываемого в текстовом редакторе. При импорте такой лог создается в случае появления ошибок преобразования типов. Например, в качестве разделителя целой и дробной части числа была указана точка, в то время как в действительности им является запятая. В результате Deductor не сможет выполнить преобразование прочитанного из файла числа к вещественному типу и добавит сообщение в лог. При экспорте в хранилище лог создается при наличии в наборе данных NULL-значений или в случае, когда тип загружаемых данных не соответствует типу данных объекта хранилища. При работе Deductor под ОС Windows 9x может наступить исчерпание ресурсов системы. Так как Deductor активно работает с графической информацией, то в системе может наступить дефицит графических ресурсов. Это вызовет появление бесконечного числа окон с сообщениями об ошибках. В такой ситуации следует по возможности закрыть окна визуализаторов и другие приложения, выполняющиеся в системе. После этого сообщения об ошибках пропадут. В критических случаях поможет принудительная перезагрузка системы. Такая проблема не касается операционных систем с архитектурой Windows NT.

24

Часто возникают ситуации, связанные с ошибкой доступа к источнику данных. Например, когда недоступен нужный сетевой ресурс, локальный источник данных был перемещен в другой каталог, переименован настроенный источник данных. В сообщении об ошибке в этом случае обычно находится достаточно информации для локализации и устранения ошибки. При получении сообщения об ошибке вида «Хранилище данных с именем XXX не найдено», «Файл ХХХ не найден» и т.п. следует проверить указанный источник данных на существование и доступность и внести соответствующие изменения в настройки источника. При импорте данных из конфигурации 1С:Предприятия сообщение об ошибке сервера 1С может быть вызвано рядом причин. •

Недоступность сервера в сетевой версии.

•

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

•

Сообщение об ошибке инициализации сервера 1С:Предприятия может быть связано с тем, что после некорректного завершения работы с базой на основе dbf-файлов требуется переиндексирование базы. В этом случае следует самостоятельно запустить 1С:Предприятие в монопольном режиме и выполнить индексирование или отказаться от него.

При работе сценария с хранилищем Deductor Warehouse для импорта данных используются идентификаторы объектов хранилища. Идентификаторы создаются автоматически при создании новых объектов. По этой причине в тех случаях, когда структура хранилища создается заново, у объектов с теми же параметрами и именами, что и в предыдущем хранилище, могут оказаться другие идентификаторы. В результате созданные ранее сценарии не смогут работать с новым хранилищем, выводя сообщения об ошибках при импорте. Таким образом, сценарии по возможности следует настраивать на ту структуру хранилища, которая будет использоваться в будущем. Удалять и создавать новые объекты следует очень аккуратно. Для внесения изменений в существующие объекты хранилища следует использовать возможности Редактора хранилища – добавление фактов и свойств, очистка процессов и измерений (подробное описание см. в «Руководстве аналитика» глава «Создание структуры хранилища с помощью Редактора хранилища»). Только в крайнем случае (добавление в процесс нового измерения или удаление существующего) следует создавать объект заново.

25

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

Пакетное выполнение Под пакетным выполнением понимается запуск Deductor с помощью параметра командной строки /run. В этом случае в автоматическом режиме будет выполнен указанный сценарий, и все результаты работы будут выгружены во внешние приемники данных. Целью такого режима работы является получение результатов анализа во внешнем источнике данных. Пакетное выполнение широко применяется при автоматической инкрементной загрузке данных в хранилище, генерации отчетов во внешних программах (например, публикация в Web), промежуточной обработке данных. Пакетное выполнение сценария запускается с помощью следующей командной строки:

$(Deductor)\Bin\Dstudio.exe /run Здесь:

$(Deductor) – каталог установки программы (по умолчанию C:\Program Files\BaseGroup\Deductor); - имя файла проекта, выполняемого в пакетном режиме; /run – параметр командной строки, запускающий пакетный режим. В результате Deductor выполнит загрузку, обработку всех данных и выгрузит в узлах экспорта результаты в настроенные приемники данных, а затем завершит работу. Пакетное выполнение может быть настроено на запуск по расписанию с помощью планировщика заданий, например, стандартного Windows Scheduler. Такая возможность удобна для автоматического запуска загрузки в хранилище данных из учетной системы в ночное время. Для этого создается ярлык для файла Dstudio.exe, для которого в строке «Объект» вводится командная строка запуска Deductor в пакетном режиме. Затем в Windows Scheduler настраивается время запуска этого ярлыка. Deductor может быть использован для проведения промежуточных расчетов, помещая результаты их выполнения в согласованный приемник данных. В этом случае из внешней программы, управляющей взаимодействием, запускается в пакетном режиме Deductor с нужным сценарием обработки. По окончании выполнения сценария Deductor возвращает в случае успеха вызывающей программе нулевой код завершения работы, и она может использовать результаты обработки по своему усмотрению. Ненулевое возвращаемое значение говорит об ошибке, возникшей в процессе обработки. Дополнительную информацию о возникших проблемах можно узнать из лог-файла (см. раздел «Диагностика пакетной обработки»). В Deductor существует возможность выполнять лишь часть узлов при пакетном выполнении. Регулируется это при разработке сценария с помощью флага «Выполнить» пункта всплывающего меню «Статус пакетной обработки». Если флаг «Выполнить» сброшен, узел и все его потомки исключаются из пакетного выполнения. Это удобно в тех случаях, когда в проекте находится несколько веток, часть из которых используется в ходе разработки и настройки сценария, и которые могут пригодиться в будущем. При установленном флаге «Выполнить» узел будет выполнен только в том случае, если у всех его родителей этот флаг также установлен.

Пакетное обучение После разработки аналитической модели часто возникают ситуации, когда рабочий набор данных начинает отличаться от того, на котором строилась модель. В таких ситуациях существует возможность избежать построения нового сценария за счет того, что в некоторых обработчиках Deductor используются обучающиеся алгоритмы – нейронные сети. Если модель адекватно отражает предметную область, то, возможно, исходные данные просто выходят за пределы выборки, на которой обучалась нейронная сеть. Чтобы сети смогли работать с изменившимися

26

данными, их нужно переобучить. Сделать это можно двумя способами – вручную, путем перенастройки узлов сценария, включающих нейронные сети, и автоматически, путем пакетного обучения. Преимущество ручного переобучения состоит в возможности контроля параметров переобучения модели. В то же время автоматический способ гораздо быстрее и хорошо подходит при незначительных изменениях в исходных данных. Пакетное обучение сценария осуществляется запуском Deductor Studio с параметром /teach:

$(Deductor)\Bin\Dstudio.exe /teach Здесь:

$(Deductor) – каталог установки программы (по умолчанию C:\Program Files\BaseGroup\Deductor); - имя файла проекта, модели в котором требуют переобучения; /teach – параметр командной строки, запускающий переобучение. В результате Deductor выполнит загрузку и предобработку всех данных, как это предусмотрено сценарием, переобучение нейронных сетей, встречающихся в узлах проекта, а затем завершит свою работу. При следующем выполнении сценария будет работать обновленная модель. В Deductor существует возможность обучать лишь часть узлов при переобучении. Регулируется это при разработке сценария с помощью флага «Переобучить» пункта всплывающего меню «Статус пакетной обработки». Если флаг у узла сброшен, он не будет переобучаться при запуске сценария с параметром /teach. Такая возможность может потребоваться, когда некоторые узлы проекта должны оставаться неизменными или требуют исключительно ручного переобучения.

Диагностика пакетной обработки Пакетная обработка не требует вмешательства человека. В этом кроме достоинств есть также и недостаток, состоящий в невозможности непосредственно контролировать ход обработки. Для того чтобы сообщить администратору о возникших проблемах и помочь в оптимизации пакетного выполнения сценария служат инструменты диагностики пакетной обработки. При каждом выполнении Deductor создает лог-файл с информацией о ходе работы. В интерактивном режиме использование лог-файла имеет смысл обычно только для отправки разработчикам сообщений об ошибках приложения (см. раздел «Что делать при возникновении ошибок»). В пакетном же режиме это незаменимый инструмент для выявления ошибок в данных, сценариях, оценки производительности и поиска «узких» мест. По умолчанию в лог-файл пишется только информация о начале и завершении пакетной обработки, а также о возникших в ее процессе ошибках. Однако существует набор параметров командной строки, позволяющих изменить режим создания лога: 1. /log - включить подробный режим лог-файла; в логе будет сохраняться информация о времени начала и окончания обработки каждого узла; 2. /logfile= - указывает имя лог-файла; по умолчанию оно генерируется автоматически; 3. /logmode=overwrite - изменяет режим работы с логом на перезапись; по умолчанию используется режим добавления записей в лог. Если эти параметры управления логом не указаны, по умолчанию используются настройки, сделанные в окне «Вид/Настройка» приложения Deductor Studio. С помощью параметров /logfile и /logmode можно изменять режим создания лог-файлов: создавать при каждом выполнении новый файл, дописывать информацию в один файл или перезаписывать его. Параметр /log позволяет проследить последовательность выполнения узлов (например, для локализации ошибки) и оценить время выполнения каждого узла. Оценка производительности необходима для оптимизации сценария обработки. Сценарий обработки может готовиться на некотором небольшом подмножестве рабочего набора данных. В этом случае встает вопрос оценки эффективности работы сценария на рабочей выборке. Для данных большого объема, которые обрабатываются длительное время, оценивать вручную время выполнения каждого узла слишком

27

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

28

Тиражирование знаний Разработкой сценариев обычно занимается один человек – аналитик. Тем не менее, получаемая аналитическая информация интересна обычно более широкому кругу лиц, которые не имеют необходимых навыков анализа данных, - конечным пользователям информации. Deductor включает в себя инструменты для тиражирования знаний – передачи знаний от аналитика пользователю системы. Основным инструментом для этого служит приложение Deductor Viewer. Несмотря на кажущуюся простоту, Viewer решает еще одну важную задачу – разграничение прав пользователей на доступ к конфиденциальной информации.

Использование Viewer Одна из особенностей платформы Deductor состоит в том, что знания, получаемые с ее помощью, может в дальнейшем использовать человек, не знакомый с особенностями математического аппарата и методов, применяемых при анализе. Ему предоставляется набор отчетов, на основании которых он может принимать конкретное решение в терминах предметной области, а не формальных моделей. Достигаться это может двумя путями: использованием системы отчетов Deductor Studio или специального приложения для просмотра отчетов Deductor Viewer.

Deductor Viewer является облегченной версией Studio, не включающей в свой состав средств для разработки сценариев и проведения анализа. Тем не менее, он имеет точно такие же механизмы исполнения сценариев и визуализации, как и Deductor Studio. В результате получается, что человеку, который будет использовать только готовые сценарии и не станет заниматься их разработкой, предоставляется простой инструмент просмотра подготовленных отчетов. Нужно отметить, что дополнительно он сможет настраивать вид отчетов, то есть он сможет увидеть нужную ему информацию не в виде, скажем, графика, как предполагал аналитик, разрабатывавший сценарий, а в виде OLAP-куба или таблицы. Принцип работы Deductor Viewer состоит в следующем. В программу загружается файл проекта, подготовленного в Deductor Studio. На единственной панели «Отчеты» отображается дерево подготовленных в Studio отчетов. Пользователь может посмотреть любой из них, дважды кликнув на иконке отчета и настроить вид с помощью кнопки «Мастер визуализации» панели инструментов. В случае если пользователю понадобится дополнительная информация, отсутствующая в подготовленных отчетах, он может обратиться к аналитику, который уже в Deductor Studio внесет нужные изменения. Пользователю не требуется владеть формальными методами проведения анализа, ему достаточно уметь на основе полученных знаний принимать решения. Распространение знаний от аналитика к конечным пользователям информации получило название тиражирование знаний. Благодаря такому разделению, не требуется, с одной стороны, обучать пользователей методике анализа данных и с другой – загружать аналитика рутинной работой, связанной с принятием повседневных решений.

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

29

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

Аналитик

Загрузка данных, получение данных

Создание отчетов

отчеты

отчеты

отчеты Хранилище данных

Использование отчетов Deductor Viewer

Deductor Viewer

Deductor Viewer

Тиражирование знаний Отдел 1

Отдел 2

Отдел N

Получение только необходимых данных

Принятие решений

30

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

Импорт данных Интеграция Deductor с другими приложениями для получения от них данных является достаточно распространенной задачей. Передача данных между приложениями возможна через базы данных и файлы различного типа. Хранилище данных и бизнес-приложения здесь не рассматриваются, так как из-за сложной внутренней структуры они не подходят для выполнения функций обмена данными. При работе с базой данных в ней создаются таблицы с определенными и согласованными именами и структурой, на которые настраиваются узлы импорта сценария. В эти таблицы внешнее приложение помещает исходные данные, которые будут извлекаться Deductor. При работе с файлами в определенном каталоге создаются несколько файлов, в которые программа-источник помещает таблицы данных. На эти файлы в Deductor настраивается импорт. Для того чтобы данные во внешней программе и Deductor’е были согласованы, потребуется синхронизация. Она может выполняться двумя путями. Внешнее приложение может самостоятельно после окончания загрузки данных вызвать Deductor в пакетном режиме. Запуск Deductor может осуществляться как из обычной программы, так и из скрипта командного языка (например, из триггера базы данных или скрипта учетной системы). Кроме того, может быть создано отдельное небольшое управляющее приложение, которое сначала исполнит программуисточник, а по окончании ее выполнения запустит Deductor. Подобные механизмы используются, например, при прогнозировании фондовых рынков. Создается приложение, которое с небольшим периодом получает через Internet с определенных сайтов информацию о курсах валют. Затем оно сохраняет полученные данные в файл и запускает Deductor в пакетном режиме. Тот, в свою очередь, пропускает полученные данные через аналитическую модель и выдает прогноз на следующий период. Схема работы подобной системы показана на рисунке.

Internet Получение данных

Данные

Управляющее приложение Запуск в пакетном режиме

Файл обмена

Данные

Пакетный запуск Deductor

Анализ Прогноз

31

Экспорт данных Результаты обработки из Deductor могут экспортироваться в хранилище данных, в базы данных и файлы различного формата. Доступ к хранилищу Deductor Warehouse из других приложений не документируется, поэтому для интеграции Deductor с другими системами лучше использовать экспорт в базы данных или файлы. При работе с базой данных в ней создается набор таблиц с определенными именами и структурой, на которые настраиваются узлы экспорта. Затем внешняя программа может забирать данные из них посредством SQL-запросов. При взаимодействии через файлы в определенных каталогах создаются файлы, в которые Deductor осуществляет экспорт. Затем внешняя программа может получить результаты обработки, независимо от Deductor работая с этими файлами. Таким образом, часть бизнес-логики может быть реализована во внешней программе, например, триггерах базы данных, что может повысить гибкость и эффективность обработки данных. Совместная работа внешней программы и Deductor чревата тем, что в программу могут поступить устаревшие или некорректные (лишь частично обновленные) данные. Чтобы избежать таких ситуаций, требуется синхронизировать их работу. Синхронизация Deductor и программы-приемника может выполняться двумя путями. Во-первых, внешняя программа может сама запускать Deductor в пакетном режиме и, дождавшись корректного окончания выполнения сценария (Deductor вернет нулевой код завершения работы), продолжить обработку результатов. Другой способ – это создание отдельной небольшой программы управления, например, пакетного файла, которая будет сначала запускать Deductor, а затем – программу-приемник. Примером интеграции с внешними приложениями может служить публикация отчетов в Internet. В этом случае периодически (например, с помощью Windows Scheduler) производится загрузка данных в Deductor в пакетном режиме, а затем запуск сценария анализа данных. Последним узлом сценария анализа является экспорт в файл HTML, который Deductor помещает в определенное место в структуре каталогов веб-сервера. Пользователь, таким образом, через свой браузер имеет постоянный доступ к самой последней информации. Схема работы описанной системы представлена на рисунке. Windows Scheduler

Пользователь

Источник данных Получение данных

Запуск в пакетном режиме Пакетный запуск Deductor

Получение отчетов

Internet

Анализ

Файл обмена (HTML)

Публикация отчетов

Web-сервер

32

Заключение Deductor является достаточно сложной системой. Он плотно связан со многими различными технологиями, начиная от СУБД и заканчивая динамическим обменом данных. В связи с этим на практике часто возникают вопросы технического характера по установке, настройке и сопровождению системы. В этом Руководстве даны ответы на наиболее часто возникающие при эксплуатации Deductor вопросы. Тем не менее, на практике могут возникнуть ситуации, которые не описаны здесь. В этом случае нужно обратиться к разработчикам платформы, подробно описав интересующий вопрос или возникшую проблему, по электронной почте [email protected]. Вы получите ответ в ближайшее время и, возможно, в будущем он будет включен в один из разделов этого Руководства.

33