Интеграция информационных систем
Ни для кого не секрет, что «уже все сделано до нас». Осталась всего-то малость «собрать фрагменты» для решения поставленной задачи. И тут оказывается, что интегрировать разобщенные части не редко сложнее, чем их написать. Почему же так происходит? Что можно с этим сделать?
Все программисты любят делать системы с нуля, когда мысль может свободно себе изобретать любые формы и средства, когда можно принимать решения без оглядки на легаси. Конечно, сконструированная цельно система, при условии, что ее делал специалист, всегда выглядит монолитно и радует глаз. Но ведь реальность у нас текучая и со временем, любая концептуальная идиллия нарушается в ходе развития бизнеса, изменения процессов, поглощения или слияния предприятий, внедрения новых систем, смены аппаратных или программных платформ и даже законодательства.
Кто поддерживал и внедрял системы, а уж тем более, занимался доработкой, реинженерингом и интеграцией, тот знает, что более двух третей всех усилий в ИТ (внимания, времени и денег) уходит на «склейку» несовместимого и попытки «подружить» модули, написанные разными людьми, в разное время, на разных языках и технологиях, под разные платформы.
- Ускорение процессов. Развитие организации требует все чаще и чаще менять структуры данных, бизнес-процессы, не говоря уже о дизайне и пользовательском интерфейсе, который просто постоянно находится в изменении. Вот, как раз в таких динамичных областях, где “изменчивость” является самой сутью и природой системы, задача интеграции усугубляется и превращается в серьезную проблему.
- Распределенность. Организации становятся все более крупными, а решаемые задачи все более комплексными, появляется логическая, организационная и географическая рассредоточенность.
- Гетерогенность. В крупном проекте, почти никогда нет возможности придерживаться платформ и инструментов от одного производителя, поэтому приходится учитывать и поддерживать особенности нескольких платформ.
- Наследственность. Невозможность полностью отказаться от легаси систем, морально устаревших технологий, старого аппаратного обеспечения, корторые, кстати, иногда дают вполне хорошие показатели по надежности и производительности но уж ни как не способствуют интеграции.
- Хаотичность. Не всегда есть возможность полностью формализовать, специфицировать и структурировать данные, и часть модели остается “слабо-связанной”, не поддающейся или слабо поддающейся машинной обработке, анализу, индексации, обсчету.
- Обусловленность. К сожалению, информационные системы ограничены не только техническими рамками, но и привычками людей (которых сложно переучивать), особенностями законодательства (которое просто не готово к появлению таких систем), множеством других факторов, не зависящих от разработчиков.
- Интерактивность. Потребитель информации постоянно повышает свои ожидания о скорости реакции системы, быстродействии и оперативности доставки информации. Большинство процессов стремятся к выполнению в реальном времени.
- Мобильность. Пользователь систем стал передвигаться быстрее, а взаимодействие с ним ведется через каналы связи общего пользования в транспорте, дома и на улице, в общественных местах и повсеместно.
- Безопасность. Пока данные хранились на носителе внутри охраняемого помещения, то особо ни кто не беспокоился о шифровании, но теперь сетевые пакеты летают в воздухе и это нельзя оставлять без внимания.
- Высоконагруженность. На сложность интеграции влияют: количество пользователей в системе, интенсивность потока обработки данных, объемы данных и ресурсоемкость вычислений.
- Непрерывность цикла работы. Интеграция и апгрейд систем почти всегда должны проводиться без остановки их функционирования, плавно, постепенно и незаметно для организации и ее клиентов.
- Межсистемная интеграция. Задачи стыковки не ограничены рамками организации, все чаще нужно интегрироваться с партнерами, клиентами, поставщиками, подрядчиками и даже государственными структурами.
- Концептуальная разница — основывается та том, что разработчики разных систем изначально приняли разные решения, предположения и допущения, которые концептуально не стыкуются между собой. Решается введением еще одного слоя абстракции, который концептуально не противоречит обоим подходам. При этом, есть два варианта реализации: (а) когда получившаяся система становится централизованной, а две и более интегрируемых системы превращаются в подсистемы и (б) когда мы используем архитектуру брокера (посредника, не являющегося центром), при этом системы остаются независимыми, а брокер обеспечивает прослойку между ними.
- Технологическая разница — когда мы имеем несовместимые форматы обмена данными, протоколы взаимодействия и интерфейсы. Решается написанием конвертов, прослоек, брокеров и других примочек, не вполне красивых, но достаточно надежных.
- Несовместимость лицензий. Подробнее останавливаться на этом не буду, так как не специалист я в этом вопросе, а решение может быть в каждом случае индивидуальное, на организационном уровне.
- Стандартизация — нужно и важно использовать как можно больше международных, государственных и отраслевых стандартов, а если каких-то не хватает, а они явно просятся, то нужно вводить корпоративные стандарты, а часто имеет смысл и продвигать их в соответствующих организациях для скорейшего распространения и популяризации.
- Интеграция на уровне брокеров. Преимущества: универсальность — практически всегда можно создать дополнительный программный модуль, который будут обращаться в обе системы, еще и разными способами (например, в одну через базу данных, а в другую через RPC). Недостатки: сложность, трудоемкость, а следовательно высокая стоимость разработки, внедрения и владения.
- Интеграция на уровне данных — то есть несколько приложений могут обращаться в одну базу данных или в несколько баз данных, связанных репликациями. Преимущества: низкая стоимость интеграции, а при использовании одной СУБД это становится очень заманчивым решением. Недостатки: если база данных не экранирована хранимыми процедурами и не имеет необходимых ограничений целостности (в виде указания каскадных операций и триггеров), то разные приложения могут приводить данные в противоречивые состояния. Если же база экранирована и целостность обеспечивается, то и в этом случае, в параллельно работающих с одной БД приложениях, будут дублирующиеся части кода, выполняющие одинаковые или похожие операции. Кроме того, при изменениях структуры базы мы будем отдельно переписывать код всех приложений, с ней работающих.
- Интеграция на уровне сервисов — это красивая интеграция, основанная на фиксации интерфейсов и форматов данных с двух сторон и позволяющая наладить быструю отработку межкорпоративной бизнес-логики. Есть и недостатки: все же, присутствует фиксация, а если структуры или процессы изменяются, то образуются проблемы и узко специализированные, частные решения.
- Интеграция на уровне пользователя — это крайний случай, не автоматизированная интеграция, когда пользователи перемещают данные между системами через копипаст, файлы, почту и другие безобразия. Мы такие методы не рассматриваем, но они, к сожалению, часто применяются в тот период, пока программные системы не готовы, а развитие компании не позволяет ждать.
- Динамическая интерпретация метаинформации — об этом мы поговорим в отдельной статье.
- архитектура
- интеграция
- сервисы
- информационные системы
- взаимодействие
Что такое интеграция данных?
Интеграция данных – это процесс обеспечения согласованного доступа и доставки для данных любого типа на предприятии. Все отделы в организации собирают большие объемы данных, имеющие различные структуры, форматы и функции. Интеграция данных включает в себя архитектурные методы, инструменты и практики, которые позволяют объединить разрозненные данные для выполнения анализа. В результате организации получают комплексное представление своих данных для извлечения ценной бизнес-аналитики.
Почему интеграция данных настолько важна?
Обычно в современных организациях есть множество инструментов, технологий и сервисов, которые собирают и хранят данные. Фрагментация данных становится причиной разрозненности и проблем с доступом.
Например, приложению для бизнес-аналитики требуются маркетинговые и финансовые данные для улучшения рекламных стратегий. Однако эти наборы данных хранятся в разных форматах. Поэтому нужна внешняя система, которая очистит, отфильтрует наборы данных и переведет их в нужный формат перед проведением анализа. Кроме того, инженеры по обработке данных могут выполнять определенные задачи обработки вручную, что приводит к дальнейшим задержкам. Несмотря на эти усилия, приложение может пропустить критически важный набор данных, потому что аналитическое подразделение не знало о его существовании.
Интеграция данных призвана решить эти проблемы с использованием различных методов обеспечения стабильности доступа. Например, все аналитики данных и приложения для бизнес-аналитики используют единую, унифицированную платформу для доступа к разрозненным данным из различных бизнес-процессов. Ниже перечислены некоторые преимущества интеграции данных.
- Повышение эффективности управления данными и увеличение коэффициента использования
- Повышение качества и целостности данных
- Ускорение получения ценной аналитической информации, основанной на точных и релевантных данных.
Каковы варианты использования интеграции данных?
Компании применяют решения по интеграции данных для нескольких примеров использования. Ниже мы рассмотрим этот вопрос подробнее.
Машинное обучение
Машинное обучение – это обучение программного обеспечения для искусственного интеллекта (ИИ) на основе большого объема точных данных. Данные в процессе интеграции извлекаются в централизованное местоположение и преобразуются в форматы, поддерживающие машинное обучение. Например, Mortar Data предоставляет компаниям современные технологии обработки данных для обучения моделей машинного обучения с использованием консолидации данных в Amazon RedShift.
Прогнозная аналитика
Прогнозная аналитика – это подход, заключающийся в прогнозировании отдельной тенденции с использованием новейших исторических данных. Например, компании используют прогнозную аналитику для составления расписаний обслуживания оборудования до того, как случится сбой. Они анализируют исторические эксплуатационные данные для выявления аномальных тенденций и принятия мер по их устранению.
Миграция в облако
Компании используют технологии интеграции данных для беспрепятственного перехода к использованию облачных технологий. Перенос всех устаревших баз данных в облако – это сложный процесс, который может стать причиной прерывания экономической деятельности. Вместо этого компании используют стратегии интеграции данных, такие как интеграция промежуточного программного обеспечения, чтобы обеспечить постепенный перенос данных в облачное хранилище и гарантировать непрерывность деятельности.
Каков принцип работы интеграции данных?
Интеграция данных – это сложная отрасль, в которой используются различные инструменты и решения, применяющие различные подходы к решению проблемы. В прошлом решения были сконцентрированы на физическом хранилище данных. Данные физически преобразовывались и перемещались в центральный репозиторий в унифицированном формате. Со временем были разработаны виртуальные решения. Центральная система предоставляла унифицированное представление всех данных, не изменяя базовые физические данные. В недавнее время внимание переместилось на федеративные решения, такие как сетки данных. Каждое бизнес-подразделение управляет своими данными независимо от других, но предоставляет их в формате, утвержденном на центральном уровне.
В решениях по интеграции данных на рынке также применяются различные подходы. Вы найдете некоторые инструменты, в которых используются новые подходы для повышения эффективности традиционных технологий. К сожалению, сложившаяся фрагментация решений на рынке привела к фрагментации подходов на крупных предприятиях. В различных подразделениях для выполнения специфических требований используются различные инструменты. Обычно крупные организации содержат как устаревшие, так и современные системы интеграции данных, что приводит к наложению и избыточности данных.
Какие подходы используются для интеграции данных?
Архитекторы данных используют для интеграции данных следующие подходы.
Консолидация данных
В процессе консолидации данных используются инструменты для извлечения, очищения и хранения физических данных в конечном хранилище. Этот процесс устраняет разрозненность данных и сокращает затраты на инфраструктуру. Существует два основных типа инструментов для консолидации данных.
ETL
Аббревиатура ETL расшифровывается как «extract, transform and load» и означает извлечение, преобразование и загрузку данных. Сначала в процессе ETL выполняется извлечение данных из различных источников. Затем производится преобразование данных в соответствии с бизнес-правилами, форматами и соглашениями. Например, инструмент для ETL может перевести все значения по транзакциям в доллары США, даже если продажи осуществлялись в другой валюте. В итоге преобразованные данные загружаются в целевую систему, например хранилище данных.
ELT
Аббревиатура ELT расшифровывается как «extract, load and transform» и означает извлечение, загрузку и преобразование данных. Этот процесс подобен ETL, но в ELT два последних шага обработки данных меняются местами. Все данные загружаются в неструктурированную систему данных, например озеро баз данных, и преобразуются только по требованию. ELT пользуется преимуществами эффективности облачных вычислений и масштабируемости облака, чтобы обеспечить интеграцию в режиме реального времени.
Репликация данных
В процессе репликации данных (также называемого распространением данных) вместо физического перемещения данных из одной системы в другую производится их дублирование. Эта технология эффективна для малых и средних предприятий, у которых не особо много источников данных. Например, предприятие, занимающееся розничной продажей оборудования могло бы использовать репликацию корпоративных данных для копирования определенных таблиц из базы данных склада в базу данных продаж.
Виртуализация данных
При виртуализации данных они не перемещаются из одной системы в другую. Вместо этого создается единое виртуальное представление, в котором интегрированы все источники данных. При виртуализации данных не производится их передача между базами данных в системах хранения. Вместо этого после получения запроса панель управления заполняется данными из нескольких источников.
Федерация данных
Федерация данных подразумевает создание виртуальной базы данных на основе нескольких источников данных. Она работает подобно виртуализации данных, но при федерации не производится интегрирование источников данных. Вместо этого после получения запроса система извлекает данные из соответствующих источников и упорядочивает их согласно стандартной модели данных в режиме реального времени.
В чем разница между интеграцией данных и интеграцией приложений?
Интеграция приложений – это процесс, который позволяет двум или более программным приложениям взаимодействовать друг с другом. Это предполагает создание общей коммуникационной структуры или API, которая позволяет одному приложению получать доступ к функциям другого приложения. API – это программа-посредник, которая позволяет программам общаться друг с другом.
Интеграция приложений расширяет возможности существующей программы путем ее интеграции с другой программой. Например, вы можете интегрировать автоответчик электронной почты с приложением для управления взаимоотношениями с клиентами (CRM). Между тем интеграция данных извлекает, объединяет и загружает все данные о клиентах из многочисленных систем-источников в облачное хранилище данных.
Как AWS помогает в интеграции данных?
Аналитика в AWS предоставляет всю инфраструктуру, необходимую для сложных решений по интеграции данных. Мы предоставляем самый широкий выбор аналитических сервисов для создания специализированных приложений интеграции данных с наилучшей производительностью, масштабируемостью и минимальными затратами.
Если говорить о готовом решении, то AWS Glue – это инструмент интеграции данных, который позволяет компаниям извлекать, очищать и консолидировать данные в масштабе. Он позволяет архитекторам данных интегрировать данные с помощью различных методов, таких как извлечение, преобразование и загрузка (ETL); извлечение, загрузка и преобразование (ELT); пакетная обработка и потоковая передача.
- Каталог данных AWS Glue позволяет специалистам по исследованию данных эффективно запрашивать данные и наблюдать за тем, как они изменяются со временем
- AWS Glue DataBrew предлагает визуальный интерфейс, позволяющий аналитикам данных преобразовывать данные без написания кода
- Функция обнаружения конфиденциальных данных AWS Glue автоматически идентифицирует, обрабатывает и маскирует конфиденциальные данные
- AWS Glue DevOps позволяет разработчикам более последовательно отслеживать, тестировать и развертывать задания по интеграции данных
Начните работу с интеграцией данных на AWS, зарегистрировав аккаунт AWS уже сегодня.
Интеграция данных
Интеграция данных (англ. — Data integration) — процесс объединения данных из различных источников для получения их согласованного представления, в широком смысле — процесс организации регулярного обмена данными между различными ИС предприятия.
Традиционная интеграция данных
Предпосылки возникновения проблемы
Проблема интеграции данных является неотъемлемым аспектом проблематики развития информационной инфраструктуры предприятия.
Исторические корни проблемы тесно переплетаются с эволюцией подходов к автоматизации бизнеса. Неавтоматизированное хранение данных не предполагало широкой постановки вопроса о их повторном использовании — для использования данных, созданных в процессе деятельности предприятия и зафиксированных в бумажной или ином неэлектронной носителе, повторно на другом участке деятельности требовалось их дублирование в нужной форме.
Первые проекты автоматизации бизнеса, технологически связанные с использованием мэйнфреймов, предполагали автоматизацию конкретных функциональных задач без задела под их расширение и интеграцию в рамках процессов предприятия. Кроме того, решения этого этапа полагались при необходимости на повторный ввод однотипных данных, как за счет доминирования унаследованного от неавтоматизированных процессов работы с данными подходов, так и за счет того, что трудозатраты на повторный ввод в денежном выражении долгое время были несравнимо ниже затрат на организацию хранения данных в машинной памяти. Не была на этом этапе широко осознана и ценность реальных данных о бизнесе, которая в настоящее время иногда оценивается как равная (или превосходящая) ценности алгоритмов их анализа. 29 ноября министр цифрового развития Максут Шадаев и CIO крупнейших компаний выступят на TAdviser SummIT
По мере возникновения информационных систем, базирующихся аппаратно на миникомпьютерах и, впоследствии, ПК, расширился как круг предприятий, способных позволить себе внедрение таких систем, так и круг задач решаемых такими АИС. Однако, подавляющее превалирование логики разработчиков над логикой бизнеса и доминирующий подход по автоматизации функциональных задач, приводили к тому, что такие АИС становились участками так называемой «лоскутной» автоматизации, не предполагающей осознанного системного подхода к автоматизации бизнеса. При этом уже учитывается необходимость хранения данных конкретных АИС и их резервирования, часть систем реализуется с учетом многопользовательского доступа и на основе клиент-серверной архитектуры. Необходимость «обмена данными» между различными АИС предприятия, однако, практически не принимается в расчёт и по-прежнему в основном снимается за счет повторного ввода с редкими исключениями в виде отдельных специфичных решений.
С разрастанием участков автоматизации начинают в полной мере сказываться недостатки «лоскутной» автоматизации — отсутствие единого подхода к организации АИС, выбору платформы и инструментов, моделям организации данных приводят к нарастанию дублирования однотипных данных в различных АИС в рамках одного предприятия. Примером может служить ситуация, когда пользователь вынужден повторно вводить аналогичные или близкие данные в несколько смежных по функционалу систем. При этом организации взаимодействия систем на программном уровне часто мешает отсутствие Application Programming Interface (API). Помимо собственно роста трудозатрат на повторный ввод и нарастания рассогласованности данных в разных системах и числа ошибок, фрагментарность хранения данных приводит к отсутствию единой картины деятельности предприятия.
С появлением концепции BI и аналитических систем, в том числе, OLAP становится явной необходимость специальной подготовки данных для таких систем, обусловленная как фрагментарностью источников данных для анализа, так и особыми требованиями к организации данных для целей анализа, сформулированными Эдгаром Коддом (Edgar Codd) в рамках 12 правил OLAP, уточненными Найджелом Пендсом (Nigel Pendse) в рамках тестам FASMI и другими.
Подходы к интеграции данных
В настоящее время интеграцию данных принято делить по направлению распространения на три типа — консолидацию, федерализацию и обмен данными.
Консолидация
Консолидация — сбор данных из нескольких источников (обычно — учётных систем) в единое место хранения. Консолидированные данные чаще всего используются для целей анализа или подготовки отчётности, как, например, в случае с организацией хранилищ данных для BI. При этом специфика сбора разнородной информации из нескольких источников обсуловила ряд особенностей консолидации данных, в частности, задержку обновления данных в целевом месте хранения по сравнению с системами-источниками данных. Эта задержка вызвана как необходимостью согласования циклов обновлений в различных системах-источниках данных, так и необходимостью преобразования данных из различных форматов в формат целевого места хранения данных, которое во многих реальных приложениях является нетривиальной задачей. Для классических целей BI-приложений, небольшая задержка в обновлении данных в целевом месте хранения не являлась проблемной, так как аналитика и прогнозирование предполагали оперирование более широкими интервалами времени, нежели учетные системы. Однако, по мере появления требований к увязке бизнес-аналитики с операционным менеджментом, требования к скорости преобразования данных приобретают всё большую важность, предъявляя новые требования к технологиям, использующим консолидацию и заставляя искать альтернативные подходы.
Наиболее часто используемой технологией консолидации данных можно считать ETL (Extract Transform Load), предполагающей извлечение данных из внешних источников, их преобразование в соответствии с требованиями бизнес-модели, загрузку преобразованных данных в целевую систему. При этом современные ETL-системы под преобразованием (transformation) понимают не только техническое преобразование форматов, но и возможности унификации разнородных данных с точки зрения соответствующих регламентов, обеспечение единства применяемых систем кодирования информации, классификаторов и справочников.
Что такое интеграция приложений?
Интеграция приложений — это процесс, который позволяет независимо разработанным приложениям и системам работать вместе. Это может помочь сократить расходы, получить аналитические данные, повысить эффективность и создать больше возможностей для организации.
Определение интеграции приложений
Организации редко полагаются только на одно приложение, но управление несколькими приложениями вместе со всеми их данными может быть трудоемкой, утомительной и сложной работой. Например, типичная крупная организация может иметь тысячи различных типов приложений, таких как наборы приложения, которые покупают клиенты, приложения для локального выполнения или приложения, которые предлагаются в качестве услуги (программное обеспечение как услуга (SaaS)). Клиенты также создают свои собственные приложения в облаке. В результате управление этими различными типами приложений может оказаться сложной задачей, поскольку для них требуются администраторы и ресурсы.
Именно в таких случаях интеграция приложений может изменить ситуацию. Интеграция приложений управляет всеми интеграциями между приложениями в одном месте, контролируя аутентификацию и авторизацию этих интеграций.
Без интеграции приложений перемещение данных между приложениями было бы сложным и чрезвычайно утомительным; это потребовало бы ввода одних и тех же данных несколько раз, а также увеличило бы вероятность человеческой ошибки. Средства сопряжения для интеграции приложений имеют возможность преобразовывать данные в формат, совместимый с существующей ИТ-архитектурой организации, чтобы данные можно было ввести всего один раз и подключить к нескольким приложениям, без необходимости думать о том, сможет ли каждое приложение взаимодействовать друг с другом. Таким образом обеспечивается определенный уровень гибкости, так чтобы организация могла выбирать нужные ей приложения, а не покупать их у конкретного поставщика.
Разница между интеграцией приложений и интеграцией данных
Хотя термины «интеграция приложений» и «интеграция данных» иногда используются как взаимозаменяемые, важно объяснить, чем они отличаются.
Проще говоря, интеграция данных заключается в сборе информации из разрозненных источников с целью создания более единообразного представления о данных в организации. Хотя интеграция данных может происходить в режиме реального времени, она может выполняться и постепенно в течение длительного времени, поскольку при этом происходит сбор большого количества данных, их хранение и последующая пакетная обработка. Это позволяет перемещать и анализировать данные внутри приложений с целью устранения избыточности.
Интеграция приложений обычно более ограничена и привязана к рабочим процессам между приложениями. Например, передача информации о потенциальных клиентах из маркетинговой системы в систему управления продажами. Это также обычно происходит на уровне отдельных транзакций. Интеграция данных обычно происходит на уровне хранилища данных или базы данных — где целые таблицы, каталоги, файлы, потоки или другие типы данных агрегируются и преобразуются по мере необходимости.