Единая точка доступа к данным предприятия

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

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

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

Логическая витрина данных(logical data warehouse, data mart или dashboard) — архитектура интегрирующей системы, при которой все данные не меняют своего физического местоположения в исходных системах и хранилищах. Витрина имеет доступ к каждому источнику, «осведомлена» о его структуре, способна запрашивать сведения из систем-источников и преобразовывать их в соответствии с единой структурой, автоматически объединять данные, поступившие из разных источников, и предоставлять их пользователю. Пользователь, в свою очередь, может обращаться к витрине с запросами, которые она интерпретирует не как набор искомых слов, а как логическое выражение, как вопрос, на который должен быть дан точный ответ. Итак:

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

Фактически, витрина для пользователя — это универсальная точка доступа ко всей корпоративной информации, объединенной в единый виртуальный массив.

Чтобы «понимать» смысл вопросов, витрина должна «говорить» с пользователем на его языке, следовательно, требуется формализованное описание предметной области. Например, если организация имеет дело с трубопроводами, приборами учета и их показаниями, то эти термины должны быть включены в концептуальную модель, с которой работает система. Для создания и представления концептуальных моделей применяются технологии онтологического моделирования (стандарт OWL и др. [3]).

После того как модель построена, необходимо описать правила извлечения данных из источников и их преобразования в соответствии с элементами модели. Например, если в таблице одной из баз хранится перечень приборов учета, то в настройках витрины должно быть задано правило, указывающее на то, что каждая запись этой таблицы представляет объект типа «Прибор учета», обладающий определенными характеристиками. Информация об одних и тех же объектах обычно рассеяна между разными источниками: в одном месте может храниться перечень приборов с точки зрения учета материальных ценностей, в другом — в качестве источников показаний расхода ресурсов, а в третьем — в виде проектной и эксплуатационной документации на технологическую инфраструктуру, частями которой они являются. При наличии правил сопоставления структур витрина способна объединить все сведения. Например, для сущности «Прибор учета» могут быть определены следующие правила: перечень приборов технического учета расхода жидкости в трубопроводах хранится в таблице control_devices базы данных «Системы управления производственными активами», причем колонка id содержит идентификаторы устройств, number — их серийные номера, а last_check — дату последней поверки; перечень приборов коммерческого учета носителя, отпускаемого потребителям, хранится в одной из баз на платформе «1С» в справочнике «Справочник.ПриборУчета» с реквизитами «Идентификатор», «СерийныйНомер» и «ДатаПоверки». Когда витрина построена, пользователь сможет задавать свои вопросы (см. рисунок).

Рисунок. Пример обработки запроса к витрине

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

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

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

Почему же практическое создание витрин стало реально только сейчас? Прежде всего достигнут определенный уровень зрелости технологий построения и обработки онтологических моделей, инструментов хранения и преобразования данных, обладающих большей гибкостью, чем реляционные СУБД. Появилась парадигма OBDA (ontology based data access): пользователь формулирует запросы к данным в терминах онтологической модели, а специальный слой связующего ПО трансформирует их в запросы к источникам данных. В качестве примера можно привести проект компании Statoil [4]. Если ранее подобные технологии применялись только для обработки метаданных — составления систематизированного описания данных, размещенных в разных хранилищах с целью упрощения их поиска, то сегодня можно говорить и об организации доступа непосредственно к самим данным.

Технологии онтологического моделирования и набор связанных с ними технологических стандартов, таких как язык запросов к графовым базам данных SPARQL, стали ключом к реализации логических витрин данных не только потому, что представляют в формализованном виде концептуальные модели, но и  потому,  что позволяют «говорить с пользователем на одном языке» и описывать разные точки зрения на одни и те же объекты и процессы. В онтологической модели структура и содержание данных технологически однородны, то есть работа с ними осуществляется при помощи одних и тех же инструментов. Добавить новый тип сущностей, атрибут или связь — не сложнее, чем создать новую запись о конкретном объекте. Это обеспечивает гибкость структуры информации, недостижимую для реляционных СУБД, и позволяет делать запросы к структуре информации, чего не позволяют noSQL-хранилища. Онтологические модели допускают отнесение каждого объекта более чем к одному типу, задание нескольких значений для атрибутов объектов, обеспечивают контроль логической целостности данных при помощи развитых механизмов логического вывода (построения формальных доказательств истинности или ложности утверждений). Наконец, механизмы логических вычислений позволяют автоматически дополнять содержание базы знаний новыми фактами на основе известных предпосылок и заданных пользователем правил получения выводов.

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

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

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

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

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

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

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

***

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

Литература

1. Виктор Борисов. Хранилище для МВД // Открытые системы. СУБД. — 2007. — № 5. — С. 68–71. URL: www.osp.ru/os/2007/05/4265018 (дата обращения: 21.10.2018).
2. Леонид Черняк. Что делать с хаосом данных? // Открытые системы. СУБД. — 2013. — № 9. — С.16–20. URL: https://www.osp.ru/os/2013/09/13038279 (дата обращения: 29.10.2018).
3. Горшков С.В. Введение в онтологическое моделирование. 2015. URL: trinidata.ru/files/SemanticIntro.pdf (дата обращения: 29.10.2018).
4. Kharlamov E. et al. Ontology Based Data Access in Statoil // Web Semantics: Science, Services and Agents on the World Wide Web. — 2017. — Vol. 44. — P. 3–36.

Сергей Горшков (serge@trinidata.ru) — директор, компания «ТриниДата». Статья подготовлена на основе материалов выступления на конференции «Технологии управления данными — 2018».