Проблемы интеграции данных

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

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

3. Методы  интеграции данных

     Существует три основных метода интеграции данных.

3. Консолидация данных

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

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

     Конечные  места хранения данных, содержащие данные с большими временами отставания (например, более одного дня), создаются  с помощью пакетных приложений интеграции данных, которые извлекают данные из первичных систем с определенными, заранее заданными интервалами. Такой подход использует запросы  к данным, которые получают периодические "мгновенные снимки" первичных  данных. Хотя подобные запросы получают текущие данные, они не отражают тех изменений, которые произошли  между двумя последовательными  запросами. А за это время данные могли обновляться несколько  раз.

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

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

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

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

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

     Консолидация  данных - это основной подход, который  используется приложениями Хранилищ данных для построения и поддержки оперативных  складов данных и корпоративных  Хранилищ. Консолидация данных также  может найти применение для создания зависимой витрины данных, но в  этом случае в процессе консолидации используется только один источник данных (например, корпоративное Хранилище). В среде Хранилищ данных одной  из самых распространенных технологий поддержки консолидации является технология ETL (извлечения, преобразования и загрузки - extract, transform, and load). Еще одна распространенная технология консолидации данных - управление содержанием корпорации (enterprise content management, сокр. ECM). Большинство решений ECM направлены на консолидацию и управление неструктурированными данными, такими как документы, отчеты и web-страницы.

3. Федерализация данных

     Обеспечивает единую виртуальную картину одного или нескольких первичных файлов данных. Если бизнес-приложение генерирует запрос к этой виртуальной картине, то процессор федерализации данных извлекает данные из соответствующих первичных складов данных, интегрирует их таким образом, чтобы они отвечали виртуальной картине и требованиям запроса, и отправляет результаты бизнес-приложению, от которого пришел запрос. По определению, процесс федерализации данных всегда заключается в извлечении данных из первичных систем на основании внешних требований. Все необходимые преобразования данных осуществляются при их извлечении из первичных файлов. Интеграция корпоративной информации (Enterprise information integration, сокр. EII) - это пример технологии, которая поддерживает федеративный подход к интеграции данных.

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

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

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

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

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

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

     Необходимо  отметить, что в англоязычной литературе термин federated data warehouse сейчас используется в двух разных значениях. Часть специалистов подразумевает под федеративным Хранилищем создание виртуальной структуры, оперирующей с выборками данных. Другие называют федеративным Хранилищем единый физический репозиторий, работающий с копиями данных, который другими словами может быть назван распределенным Хранилищем.

3. Приложения распространения данных

     Осуществляют копирование данных из одного места в другое. Эти приложения обычно работают в оперативном режиме и производят перемещение данных к местам назначения, т.е. зависят от определенных событий. Обновления в первичной системе могут передаваться в конечную систему синхронно или асинхронно. Синхронная передача требует, чтобы обновления в обеих системах происходили во время одной и той же физической транзакции. Независимо от используемого типа синхронизации, метод распространения гарантирует доставку данных в систему назначения. Такая гарантия - это ключевой отличительный признак распространения данных. Большинство технологий синхронного распространения данных поддерживают двусторонний обмен данными между первичными и конечными системами. Примерами технологий, поддерживающих распространение данных, являются интеграция корпоративных приложений (Enterprise application integration, сокр. EAI) и тиражирование корпоративных данных (Еnterprise data replication, сокр. EDR).

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

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

3. Гибридный подход

       Методы, используемые приложениями  интеграции данных, зависят как  от нужд бизнеса, так и от  технологических требований. Достаточно  часто приложение интеграции  данных использует так называемый  гибридный подход, который включает  несколько методов интеграции. Хороший  пример такого подхода - интеграция  данных о клиентах (customer data integration, сокр. CDI), целью которой является  обеспечение согласованной картины  информации о клиентах.