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

Сергей Горшков
Сергей Горшков, руководитель компании «ТриниДата»

Что препятствует практической реализации методологии управления качеством данных, которая во многих организациях не продвигается дальше организационных мер?

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

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

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

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

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

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

Как именно решаются задачи управления качеством данных?

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

Какие технологии используются для создания и выполнения правил логического вывода?

Первые решения по автоматизации логического вывода были созданы еще в 1970-е годы (язык Prolog). В последние десятилетия шел активный поиск путей создания средств получения логических выводов, которые могут быть интегрированы в современные программные архитектуры. Сначала был разработан синтаксис правил SWRL, выполняемых на онтологиях с помощью «машин логического вывода» (Reasoner). Затем появился проект спецификации SPIN, идея которой состоит в том, что правила являются такой же частью онтологии, что и сама концептуальная модель и представленные в соответствии с ней данные. Развитием этой идеи стала спецификация SHACL — актуальное на сегодняшний день средство представления правил логического контроля, утвержденное консорциумом W3C. Поскольку эта спецификация позволяет представлять правила в виде запросов к графовой базе данных (такие базы — наиболее естественный способ хранения онтологий и фактов, представленных в соответствии с ними), то фактически не требуется создавать машину логического вывода как отдельный компонент. Это дает возможность легко встраивать правила SHACL в состав любого программного комплекса, работающего с онтологиями и графовыми базами данных.

Графовые СУБД вряд ли могут хранить и обрабатывать всю корпоративную информацию. Как контролировать данные, которые остаются вне графа?

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

Наша компания выбрала именно такой путь логического объединения корпоративных данных, причем раньше, чем к нему пришли многие западные вендоры. Подход, реализованный в платформе управления данными «АрхиГраф», оказался наиболее целостным. Кроме того, он лишен ряда типичных недостатков, которые некоторые другие продукты унаследовали из предыдущей фазы развития технологий.

Как же выглядит на практике управление качеством данных средствами платформы «АрхиГраф»?

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

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

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

Как решать, например, задачи отслеживания происхождения данных (data lineage)?

Для этого в «АрхиГрафе» предусмотрено хранение метаданных о каждом информационном объекте, попадающем в хранилища. Метаданные содержат сведения о дате и способе попадания объекта в платформу, а также историю всех его изменений. Кстати, со временем обязательно будет меняться и концептуальная модель, в соответствии с которой данные структурируются. Изменения также отражаются в истории, которую хранит платформа. Это позволяет работать не только с текущим состоянием модели и данных, но и с любым из предыдущих. На сегодняшний день существует немного хранилищ, обеспечивающих полноценное хранение данных с учетом времени как «четвертого измерения».

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

Как сравнивать данные, хранящиеся в разных автоматизированных системах?

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

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

В чем состоит основное преимущество предлагаемого вами подхода?

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