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

Проблемы объединения разнородных источников данных, часто называемых информационными силосами, под единый интерфейс запросов существуют уже давно. В начале 1980-х годов учёные приступили к разработке систем обеспечения совместимости гетерогенных баз данных^[5].

Первая система интеграции данных, ориентированная на структурированные метаданные, была создана в 1991 году в Университете Миннесоты для проекта Integrated Public Use Microdata Series (IPUMS). Здесь применялся подход хранилища данных, предусматривающий извлечение, преобразование и загрузку информации из разнородных источников в единую логическую схему, позволяющую сделать совместимыми данные из разных источников. Сделав совместимыми тысячи демографических баз, проект IPUMS показал принципиальную реализуемость крупномасштабной интеграции данных. Такой подход — жёсткая связность, так как объединённые данные физически находятся в едином репозитории, и большинство запросов выполняется очень быстро^[6].

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

С 2009 года всё большую популярность получает подход слабосвязной архитектуры данных^[7], с единым интерфейсом запросов для доступа к данным в режиме реального времени через посредническую схему (см. рис. 2). Это согласуется с подходами сервис-ориентированной архитектуры, актуальными для того времени. Здесь задействованы отображения между посреднической схемой и схемами первоисточников, а запрос разбивается на составляющие для разных систем. Существуют два основных способа организации сопоставлений: «Global-as-View» (GAV, «Глобальное как представление»), когда отображения идут от глобальной схемы к источникам^[8], и «Local-as-View» (LAV, «Локальное как представление»), когда сопоставления строятся в обратную сторону — от источников к посреднической схеме^[9]. Второй подход требует более сложных алгоритмов при обработке запросов, но упрощает добавление новых источников в стабильную схему.

По состоянию на 2010 год, часть исследований в области интеграции данных была посвящена проблеме семантической интеграции. Эта задача не структурная, а смысловая: как разрешать смысловые конфликты между источниками. Например, объединяя схемы двух компаний после слияния, понятие «доход» может означать в одной БД прибыль в долларах (тип — число с плавающей запятой), в другой — число продаж (целое). Стандартной стратегией решения выступает использование онтологий, явно определяющих термины схемы и помогающих разрешить конфликты. Такой подход называется интеграция на основе онтологий. В научных областях, напр. биоинформатике, важным аспектом становится сопоставление результатов по единому критерию, что позволяет сравнивать разнородные данные и интегрировать их даже при различиях в экспериментах^[10].

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

С 2011 года всё больший интерес вызывают «центры данных» — наборы данных с частично структурированной архитектурой, тогда как традиционные корпоративные хранилища (Enterprise Data Warehouses) уступают им по популярности. С 2013 года возросла популярность подхода «озёр данных». Эти подходы объединяют разнородные, включая неструктурированные, данные в одном месте, не требуя строгой схемы^[11].

В 2014 году ключевым фактором развития стала концепция больших данных (Big Data). Компании столкнулись с необходимостью интегрировать традиционные реляционные базы данных с новыми системами для обработки неструктурированных данных, такими как Hadoop^[12][13]. Это стимулировало развитие облачных технологий, в частности баз данных как сервиса (DBaaS), и появление новых версий СУБД с поддержкой вычислений в оперативной памяти (in-memory) и улучшенной интеграцией с облаком, как, например, в SQL Server 2014^[12].

В последующие годы (2015—2017) тенденции сместились в сторону «демократизации данных». Широкое распространение получили инструменты самообслуживания (self-service), позволяющие бизнес-пользователям самостоятельно готовить и интегрировать данные^[14]. Рост числа облачных приложений привёл к высокому спросу на гибридную интеграцию и платформы iPaaS^[15]. Традиционные ETL-процессы начали уступать место потоковой интеграции в реальном времени, для которой активно применялись такие технологии, как Apache Kafka^[16]. Ключевым элементом автоматизации стали метаданные, а виртуализация данных получила признание как гибкая альтернатива физическому перемещению данных^[17][18].

К 2018 году, с введением в ЕС Общего регламента по защите данных (GDPR), резко возросла значимость управления данными (Data Governance)^[19]. В этот период началось активное применение машинного обучения для автоматизации процессов интеграции^[16], а также зародилась концепция «фабрики данных» (Data Fabric) как архитектуры для унифицированного управления распределённой информацией^[20]. Стратегия «сначала облако» (cloud-first) стала доминирующей, а интеграция данных с устройств Интернета вещей (IoT) — новым вызовом^[21].

В 2020—2022 годах архитектура Data Fabric стала одной из главных тенденций, предлагая гибкую среду для доступа к данным независимо от их местоположения^[22]. Укрепился подход «дополненной интеграции» (Augmented Data Integration), подразумевающий активное использование ИИ для автоматизации сопоставления схем и контроля качества. Также наблюдался сдвиг от ETL к подходу ELT (Extract, Load, Transform), при котором «сырые» данные сначала загружаются в целевое хранилище (часто облачное), а преобразуются уже по мере необходимости для конкретных аналитических задач. Более 80 % руководителей бизнес-операций к 2020 году считали интеграцию данных критически важной для своей деятельности^[23].

Начиная с 2023 года, наряду с развитием Data Fabric, набирает популярность децентрализованная архитектура Data Mesh («сетка данных»). Этот подход рассматривает данные как продукт и передаёт ответственность за них доменным командам (например, маркетинга или финансов). Генеративный искусственный интеллект стал активно применяться для автоматизации до 70 % задач по обработке данных^[24]. В качестве альтернативы REST для API стал чаще использоваться GraphQL, позволяющий клиентам запрашивать только необходимые данные^[25]. К 2025 году, по прогнозам Gartner, более 85 % организаций будут придерживаться принципа «сначала облако»^[26].

В последние годы рост числа используемых приложений и критичность интеграции между ними привёл к появлению унифицированных API (Unified APIs), которые упрощают задачу интеграции для разработчиков, а новые протоколы типа Model Context Protocol — MCP берут этот процесс на новый уровень для агентов искусственного интеллекта.

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

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

Интеграционное решение может рассматривать внешние ресурсы как материализованные представления над виртуальной посреднической схемой, что приводит к «виртуальной интеграции данных». Разработчик приложения моделирует виртуальную схему (mediated schema), максимально отражающую интересы пользователей, и пишет специальные обёртки (wrappers) или адаптеры для каждого источника. Адаптер преобразует результаты локального запроса в формализованный вид (см. рис. 2). Когда пользователь делает запрос, система преобразует его в соответствующие запросы к каждому источнику, а виртуальная база объединяет результаты.

Такой подход позволяет легко добавлять новые источники — достаточно создать для них адаптер. Это отличие от систем ETL или монолитных БД, где доинтеграция набора требует ручного обновления всей схемы. Виртуальные ETL-решения используют виртуальную посредническую схему для гармонизации данных, копируя значения из объявленного «мастер-источника» в целевые данные по полям. Продвинутые решения виртуализации строятся на принципах объектно-ориентированного моделирования и используют архитектуру hub-and-spoke.

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

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

Теория интеграции данных^[1] является разделом теории баз данных, формализует ключевые понятия задачи с помощью средств логики первого порядка. Теоретические модели позволяют судить о реализуемости и сложности интеграции. Несмотря на известную абстрактность, эти определения достаточно широки для всех классов систем интеграции^[29], включая работающие с вложенными реляционными (XML) БД^[30], либо трактующие БД как программы^[31]. Способы связи с практическими системами (например, JDBC) не входят в теоретические построения.

Интеграционная система формально определяется как кортеж ${\displaystyle \left\langle G,S,M\right\rangle }$, где ${\displaystyle G}$ — глобальная (или посредническая) схема, ${\displaystyle S}$ — множество исходных схем, а ${\displaystyle M}$ — отображение между запросами по схеме ${\displaystyle G}$ и по ${\displaystyle S}$. Оба множества — ${\displaystyle G}$ и ${\displaystyle S}$ — определяются языками на алфавитах, включающих все их реляционные отношения. Отображение ${\displaystyle M}$ задаётся через соответствия между запросами к ${\displaystyle G}$ и ${\displaystyle S}$. Пользователь выполняет запросы к ${\displaystyle G}$, а система сопоставляет и преобразует их относительно источников через ${\displaystyle M}$.

База данных над схемой определяется как совокупность множеств (наборов) кортежей для каждого отношения. Соответственно, над схемой ${\displaystyle S}$ определяется «исходная БД» (объединяющая реальные источники), а над ${\displaystyle G}$ — «глобальная БД», которая обязана удовлетворять отображениям ${\displaystyle M}$. Допустимость сопоставления определяется видом соответствия между ${\displaystyle G}$ и ${\displaystyle S}$; выделяют два варианта: GAV (Global as View) и LAV (Local as View).

GAV-системы интерпретируют глобальную БД как набор представлений над ${\displaystyle S}$: ${\displaystyle M}$ сопоставляет каждому элементу ${\displaystyle G}$ запрос к ${\displaystyle S}$. Обработка запросов сводится к подстановке, а сложность падает на медиаторы — программистов, реализующих логику выборки из источников. При добавлении новых источников часто приходится переконфигурировать медиатор, поэтому GAV эффективен для относительно стабильных систем.

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

В случае LAV источники трактуются как представления над ${\displaystyle G}$, а ${\displaystyle M}$ сопоставляет каждому элементу ${\displaystyle S}$ запрос к ${\displaystyle G}$. Здесь структура ассоциаций нестрогая, и вся сложность ложится на обработчик запросов, а не на проектировщика. Добавление новых источников в этом подходе требует намного меньше усилий — LAV предпочтителен для нестабильных (развивающихся) схем^[1].

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

Теория обработки запросов в интеграционных системах строится на конъюнктивных запросах и языке Datalog, декларативном логико-программирующем языке^[33]. Интуитивно конъюнктивный запрос — это логическая функция типа «${\displaystyle f(A,B)}$ где ${\displaystyle A<B}$». Если замена кортежей делает выражение истинным, ответ включается в выборку. Формальные Datalog-запросы компактны, но и обычные SQL-запросы также могут рассматриваться как конъюнктивные.

Для интеграции критично понятие «содержимости запроса»: запрос ${\displaystyle A}$ содержит ${\displaystyle B}$ (обозначается ${\displaystyle A\supset B}$), если для любой БД множество ответов ${\displaystyle B}$ входит в ${\displaystyle A}$. Равенство множеств определяет эквивалентность запросов. Это важно, так как во всех GAV и LAV системах пользовательские запросы формулируются над виртуальной схемой (наборами представлений, либо материализованных запросов), а задача интеграции — переписать запросы так, чтобы обеспечить максимальное их соответствие пользовательскому запросу. Эта задача называется «ответы на запросы с помощью представлений»^[34].

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

В системах LAV запрос обрабатывается более сложно, поскольку нет жёсткой схемы сопоставлений — обработчик выполняет поиск в пространстве всех возможных переписок, чтобы найти максимально приближённую. Итог может быть только максимально покрывающим, не обязательно эквивалентным, а некоторые кортежи могут быть потеряны. По состоянию на 2011 год самым эффективным алгоритмом переписывания запросов для LAV был алгоритм GQR^[35].

После 2011 года исследования были направлены на повышение масштабируемости существующих алгоритмов и их адаптацию к новым задачам. Значительное внимание уделялось более общим гибридным моделям, таким как GLAV (Global-Local-as-View), объединяющим преимущества GAV и LAV^[36]. Ключевым направлением стало применение методов переписывания в системах доступа к данным на основе онтологий (Ontology-Based Data Access, OBDA), где онтология выступает в роли глобальной схемы^[37]. В рамках этого подхода были разработаны практические системы, такие как Ontop, транслирующие запросы с языка SPARQL в оптимизированные SQL-запросы к исходным базам данных^[38]. Также были предложены новые теоретические концепции, например, «ограниченное переписывание запросов» (bounded query rewriting), актуальное для работы с большими данными^[39], и велись работы по адаптации алгоритмов для гетерогенных хранилищ («полисторов»), содержащих данные в разных форматах, включая JSON и массивы^[40].

Начиная с 2022 года, в области переписывания запросов произошёл сдвиг парадигмы, связанный с развитием больших языковых моделей (LLM). Хотя классические алгоритмы остаются теоретической основой, LLM стали активно применяться для автоматической оптимизации и переписывания запросов. Модели используются для улучшения неэффективных SQL-запросов^[41], повышения релевантности поиска в диалоговых системах и системах с дополненной генерацией (RAG)^[42]. Примером является система GenRewrite (2024), которая использует LLM для преобразования запросов на основе правил, сформулированных на естественном языке, что позволяет обрабатывать более сложные и новые шаблоны запросов по сравнению с традиционными методами^[43].

В общем случае задача переписывания запросов NP-полна^[34]. Однако если число возможных трансляций ограничено, даже сотни источников не представляют проблемы.

Крупные вопросы современной науки, такие как данные реального мира, глобальное потепление, распространение инвазивных видов, истощение ресурсов, требуют объединения разнородных наборов данных для метаанализа. Интеграция данных здесь особенно сложна из-за отсутствия согласованных метаданных и большого разнообразия типов данных. Инициативы Национального научного фонда США, например, программа Datanet (Sustainable Digital Data Preservation and Access Network Partners), были нацелены на упрощение интеграции данных с помощью киберинфраструктуры и введения стандартов. К началу 2020-х годов программа была официально заархивирована^[44], а её миссия была продолжена в рамках новых инициатив, таких как «Интегрированные системы и сервисы данных» (IDSS), запущенная в 2025 году^[45][46].

В рамках Datanet было поддержано пять крупных проектов, судьба которых сложилась по-разному^[47]:

• DataONE (Data Observation Network for Earth)^[48] под руководством Уильяма Миченера (Университет Нью-Мексико) — наиболее устойчивый проект, который продолжает активно функционировать и в 2025 году. После завершения второй фазы финансирования от NSF 30 сентября 2020 года^[49], он перешёл на модель, поддерживаемую сообществом^[50].
• Terra Populus, возглавлявшийся Стивеном Рагглзом (Миннесотский университет), эволюционировал в проект IPUMS Terra^[51] и также продолжает активную работу по интеграции данных о населении и окружающей среде^[52].
• Data Conservancy^[53] во главе с Саидом Чоудхури (Университет Джонса Хопкинса) завершил основной этап финансирования в 2014 году^[54]. Его пилотные проекты были прекращены (с arXiv в 2013 году, репозиторий — в 2015 году), а сам проект стал неактивен в первоначальном виде^[55].
• SEAD (Sustainable Environment through Actionable Data) под руководством Маргарет Хедстром (Мичиганский университет) также завершил свою активную фазу, однако его наследие сохранилось в виде «Виртуального архива SEAD», который стал одним из репозиториев-членов сети DataONE^[48].
• DataNet Federation Consortium (DFC) во главе с Рейганом Муром (Университет Северной Каролины) завершил свой грант в 2016 году^[56]. Хотя сам консорциум неактивен, его базовая технология iRODS продолжает активно развиваться.

Research Data Alliance^[57] позже начал разрабатывать глобальные инфраструктурные схемы интеграции данных. Проект OpenPHACTS, финансируемый ЕС (Innovative Medicines Initiative), создал платформу для поиска лекарств через связку баз European Bioinformatics Institute, Royal Society of Chemistry, UniProt, WikiPathways, DrugBank.