Это готовые к использованию решения поддерживающие одну или несколько технологий интеграции данных

Интеграция данных

Интеграция данных (англ. — Data integration) — процесс объединения данных из различных источников для получения их согласованного представления, в широком смысле — процесс организации регулярного обмена данными между различными ИС предприятия.

Содержание

Предпосылки возникновения проблемы

Проблема интеграции данных является неотъемлемым аспектом проблематики развития информационной инфраструктуры предприятия.

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

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

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

С разрастанием участков автоматизации начинают в полной мере сказываться недостатки «лоскутной» автоматизации — отсутствие единого подхода к организации АИС, выбору платформы и инструментов, моделям организации данных приводят к нарастанию дублирования однотипных данных в различных АИС в рамках одного предприятия. Примером может служить ситуация, когда пользователь вынужден повторно вводить аналогичные или близкие данные в несколько смежных по функционалу систем. При этом организации взаимодействия систем на программном уровне часто мешает отсутствие Application Programming Interface (API). Помимо собственно роста трудозатрат на повторный ввод и нарастания рассогласованности данных в разных системах и числа ошибок, фрагментарность хранения данных приводит к отсутствию единой картины деятельности предприятия.

С появлением концепции BI и аналитических систем, в том числе, OLAP становится явной необходимость специальной подготовки данных для таких систем, обусловленная как фрагментарностью источников данных для анализа, так и особыми требованиями к организации данных для целей анализа, сформулированными Эдгаром Коддом (Edgar Codd) в рамках 12 правил OLAP, уточненными Найджелом Пендсом (Nigel Pendse) в рамках тестам FASMI и другими.

Подходы к интеграции данных

В настоящее время интеграцию данных принято делить по направлению распространения на три типа — консолидацию, федерализацию и обмен данными.

Консолидация

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

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

Источник

Интеграция данных

Содержание

Уровни интеграции данных

Системы интеграции данных могут обеспечивать интеграцию данных на физическом, логическом и семантическом уровне. Интеграция данных на физическом уровне с теоретической точки зрения является наиболее простой задачей и сводится к конверсии данных из различных источников в требуемый единый формат их физического представления. Интеграция данных на логическом уровне предусматривает возможность доступа к данным, содержащимся в различных источниках, в терминах единой глобальной схемы, которая описывает их совместное представление с учетом структурных и, возможно, поведенческих (при использовании объектных моделей) свойств данных. Семантические свойства данных при этом не учитываются. Поддержку единого представления данных с учетом их семантических свойств в контексте единой онтологии предметной области обеспечивает интеграция данных на семантическом уровне. [1]

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

Возникающие задачи

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

Архитектуры систем интеграции

Консолидация

В случае консолидации данные извлекаются из источников, и помещаются в Хранилище данных. Процесс заполнения Хранилища состоит из трех фаз — извлечение, преобразование, загрузка (Extract, Transformation, Loading — ETL). Во многих случаях именно ETL понимают под термином «интеграция данных». Еще одна распространенная технология консолидации данных — управление содержанием корпорации (enterprise content management, сокр. ECM). Большинство решений ECM направлены на консолидацию и управление неструктурированными данными, такими как документы, отчеты и web-страницы.

Консолидация — однонаправленный процесс, то есть данные из нескольких источников сливаются в Хранилище, но не распространяются из него обратно в распределенную систему. Часто консолидированные данные служат основой для приложений бизнес-аналитики (Business Intelligence, BI), OLAP-приложений.

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

Федерализация

При использовании медиатора создается общее представление (модель) данных. Медиатор — посредник, поддерживающий единый пользовательский интерфейса на основе глобального представления данных, содержащихся в источниках, а также поддержку отображения между глобальным и локальным представлениями данных. Пользовательский запрос, сформулированный в терминах единого интерфейса, декомпозируется на множество подзапросов, адресованных к нужным локальным источникам данных. На основе результатов их обработки синтезируется полный ответ на запрос. Используются две разновидности архитектуры с посредником — Global as View и Local as View. [1]

Отображение данных из источника в общую модель выполняется при каждом запросе специальной оболочкой (wrapper). Для этого необходима интерпретация запроса к отдельным источникам и последующее отображение полученных данных в единую модель. Сейчас этот способ также относят к федеративным БД. [3]

Интеграция корпоративной информации (Enterprise information integration, сокр. EII) — это пример технологии, которая поддерживает федеративный подход к интеграции данных.

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

Распространение данных

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

Сервисный подход

Сервисно-ориентированная архитектура SOA (Service Oriented Architecture), успешно применяемая при интеграции приложений, применима и при интеграции данных. Данные также остаются у владельцев и даже местонахождение данных неизвестно. При запросе происходит обращение к определённым сервисам, которые связаны с источниками, где находится информация и ее конкретный адрес.

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

Имея соответствующие учетные данные системы безопасности, потребитель может осуществить выборку любых данных из источника через почти неограниченное количество различных запросов SQL. Но для этого потребитель должен иметь представление о модели источника данных и способе создания результата с использованием этой базовой модели. Чем сложнее модель источника данных, тем более сложной может оказаться эта задача. [4]

Кроме того

В [1] описан пример гибридного подхода.

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

Вне зависимости от выбранных технологии и метода интеграции данных, остаются вопросы, связанные с их смысловой интерпретацией и различиями в представлении одних и тех же вещей. Именно, приходится разрешать несоответствие схем данных [6] и несоответствие самих данных.

Типы несоответствия схем данных

Структурные и семантические конфликты выливаются в следующие проблемы:

Типы несоответствия собственно данных

Источник

Интеграция данных и Хранилища

Подготовлено Intersoft Lab по материалам зарубежных сайтов

Для того чтобы принимать обоснованные решения, организации необходима надежная система данных. Такая система должна включать как текущие, так и исторические данные из операционных систем, чтобы можно было выявлять тенденции и прогнозировать будущие результаты. Технология интеграции данных является ключевым фактором для объединения этих данных и создания информационной инфраструктуры, удовлетворяющей стратегическим проектам Business Intelligence (BI). Такая информационная инфраструктура включает Хранилища данных, витрины данных и операционные склады данных. Создание Хранилища данных (или, в более ограниченном масштабе, витрины данных, содержащей данные только об одном предмете) существенно упрощает доступ к необходимым данным. Сбор и консолидация данных, необходимых для Хранилища или витрины данных, и периодическое пополнение их содержимого новыми значениями при сохранении более ранних величин является практическим приложением технологии интеграции данных.

Характеристики интеграции данных

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

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

Рис. 1. Методы интеграции данных

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

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

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

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

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

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

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

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

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

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

Необходимо отметить, что в англоязычной литературе термин federated data warehouse сейчас используется в двух разных значениях. Часть специалистов подразумевает под федеративным Хранилищем создание виртуальной структуры, оперирующей с выборками данных. Другие называют федеративным Хранилищем единый физический репозиторий, работающий с копиями данных, который другими словами может быть назван распределенным Хранилищем. Именно о таких физически цельных структурах мы писали в предыдущих материалах нашего Журнала (см. также статью «Новый подход к построению корпоративного Хранилища данных: разрешение сложностей при подготовке отчетности на всех уровнях организации» в №36).

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

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

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

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

Интеграция оперативных данных в Хранилище имеет несколько преимуществ. Хранилище данных может создаваться в следующих целях:

Оперативный склад данных создается в следующих целях:

Анализ текущих значений и тенденций

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

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

Данные как активы корпорации

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

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

Различия в определениях данных и бизнес-правилах

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

Поддержка производительности и времени реагирования операционных систем

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

Интегрированные данные обеспечивают структуру, которая помогает организации:

Заключение

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

Источник