Ирина Эланс

Автор который поможет с любыми образовательными и учебными заданиями

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

Введение

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

Решение этих проблем – оперативная, согласованная и легкодоступная информация.

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

Без интеграции данных в единое целое информационное пространство сложно говорить о пространстве знаний предприятия и об инновационном развитии в целом.

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

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

Цели и задачи интеграции данных

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

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

создание новых знаний;
использование имеющихся знаний при принятии решений;
обеспечение доступа к ценным знаниям за пределами организации;
воплощение знаний в процессах, продуктах и/или услугах;
представление знаний в документах, базах данных, программном обеспечении и т. д.;
передача знаний из одного подразделения организации в другое;
измерение ценности интеллектуальных активов (knowledge assets) или/и влияния управления знаниями на результаты бизнеса.

Основные проблемы в области интеграции данных

Основными проблемами в области интеграции данных являются:

Качество данных;
Вопросы безопасности;
Недостаток экономических моделей;
Неразвитая инфраструктура интеграции данных;

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

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

Причины неудач глобальных интеграционных проектов

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

Разнообразие и лавинообразный рост информации.

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

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

Постоянные изменения бизнеса.

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

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

Технологические проблемы.

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

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

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

Противоречия между "глобальными" и "локальными" требованиями.

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

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

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

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

Неизбежный риск крупных проектов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оглавление

Введение