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

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

Типичный процесс интеграции данных

Итак, что подразумевается под интеграцией данных, поступающих от делового партнера? Этот новый источник данных требует организации полного цикла работ по проектированию и разработке, причем у вас скорее всего не будет доступа к системе-источнику и ее разработчикам. Кроме того, вам нужно найти (или создать) безопасное, надежное место хранения данных, доступное и вам, и вашему деловому партнеру. Если для вас надежность — жизненно важная характеристика информационного хранилища, то задача усложняется: вам придется управлять процессом, ход которого лишь наполовину зависит от вас.

Мы рекомендуем начать интеграцию с планирования и проектирования. Прежде всего следует договориться о том, какие, собственно, данные вы собираетесь извлекать: моментальные снимки в определенные моменты времени или наборы транзакций. Определите, что должны представлять собой отдельные файлы — полное обновление или только сведения об изменениях, и за какой период оцениваются изменения.

Затем следует определить формат и содержание файла. В данной ситуации вы всего лишь получатель данных из системы-источника, к которой нет прямого доступа, поэтому вам понадобятся ответы на множество вопросов: какие могут быть имена и значения отдельных элементов файла, какие поля являются ключевыми, как взаимосвязаны различные поля, может ли в поле содержаться пустое значение (“null”), когда это происходит и что означает.

Не забудьте провести ревизию соглашений об именовании для информационного хранилища и проверить, все ли имена полей имеют осмысленное значение. Например, что хранится в поле «Дата»? Может быть, вы имели в виду «дату начала подписки» или «последнюю дату выставления счета», а может — «дату запуска пакетного файла извлечения данных»? Если это «дата начала подписки», возможно, следует уточнить: «исходная дата начала подписки» или «последняя дата начала подписки».

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

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

Предусмотрите возможность тестовой загрузки. Различать тестовые и рабочие загрузки можно на уровне файлов — на основании метаданных или имен файлов.

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

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

Архитектура

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

Установка

Многие компании используют два межсетевых экрана, создавая двойную линию защиты. В данном примере сервер FTP располагается между экранами в так называемой демилитаризованной зоне сети (DMZ). Обеспечение безопасности при наличии доступа к Интернету следует поручать экспертам — воспользуйтесь их услугами, чтобы настроить ваш сервер.

Сконфигурировав FTP-сервер, создайте учетную запись пользователя и пароль и предоставьте этому пользователю доступ только к каталогу, предназначенному для данного партнера по интеграции. Позаботьтесь о безопасной передаче назначенного имени пользователя и пароля своему партнеру. На этом этапе можно попросить его создать тестовый файл и закачать в указанный каталог. Имейте в виду, что ваш партнер должен создать для доставки данных полноценную, устойчивую программу с обработкой ошибок и исключений, — только так обеспечивается генерация корректных данных в соответствии с оговоренным расписанием. Часть общего процесса, выполняющаяся на стороне партнера, очень похожа на стандартную ETL-процедуру (Extraction, Transformation and Loading — извлечение, преобразование и загрузка) извлечения данных из стандартного информационного хранилища. Правда, в данном случае процедура усложняется, поскольку пересылка данных осуществляется между организациями.

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

Обработка исключений

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

Обманчивая простота

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

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

Уоррен Торнтвэйт (Warren Thornthwaite) начал свою карьеру специалиста по информационным хранилищам в компании Metaphor в 1984 году. Один из авторов книги Data Warehouse Lifecycle Toolkit. (Wiley, 1998). Преподает в университете Kimball и является соучредителем компании InfoDynamics LLC. С ним можно связаться по e-mail: warrent@infodynamics-LLC.com.