Comments 14
Важно помнить, что "интеграция" ( в общем как и всякий другой выбор) имеет под собой trade-off. Да, писать и поддерживать интеграции требует существенных затрат, но это позваляет описывать контракты для взаимодействия разных систем. Как следствие, с этими контрактами можно говорить о понижении связности, и как следствие возмоности независимой эволюции систем, ситгерированных таким способом.
Обычно, далеко не все системы обновляются или измениются регулярно. Меняются же те, где бизнес пытается выделиться на рынке. Как следствие, если "корневая" или "центральная" модель поменяется, прийдётся обновлять и те системы, которые трогать бы не хотелось.
Корректно спроектированные интеграции позволяют разным бизнес областям эволюционировать более независимо.
Но в наше время для очень многих бизнесов скорость адаптации к изменениям становится критичной, а возможность быстрого сбора комплексной аналитики по внезапно возникающим запросам (отчет нужен завтра, а не через месяц!) и извлечения ценности из накопленных данных — реальной возможностью обогнать конкурентов или просто выжить. А когда гибкость важнее стабильности, стоит и ИТ-архитектуру строить так, чтобы как можно меньше зависеть от конкретных приложений, а в использовании данных иметь наибольшую свободу.
Поддерживать множество API для работы с данными, включая REST, GraphQL, SPARQL? тоже красиво звучит, пока объемы данных умеренные, пока вам нужны единичные объекты из базы. А как только вам нужно работать с терабайтами, пусть даже в сутки, так сразу выясняется, что кроме условной кафки особо и выбора-то нет никакого. А условный JSON как формат обмена увеличивает размер данных насколько, что вы смотрите на стоимость железа, и думаете — а не ну ли его нафиг? А в итоге — применяются типовые более-менее низкоуровневые бинарные протоколы доступа к БД вроде JDBC или там ODBC. Ну и интеграции, кудаж без них? ESB и все такое — причем чем больше объемы, тем все нетривиальнее.
Ну т.е. что я хочу сказать? Я поверю в такое, как только на этой идее будет реализовано что-то типа биллинга, например, в масштабах оператора сотовой связи, или там карточный процессинг на уровне хотя бы среднего банка, не говоря уже о большом. А в меньших масштабах — отчего бы и нет.
И порассказывать про такое да, можно красиво. А вот пример живой можно, и побольше размером?
Проблемы с доступом к данным вендорских приложений, или, еще лучше, самописных приложений заказчика — возникают, но решаются. Часто удается получить прямой доступ к СУБД, иногда работаем через предоставляемые приложениями веб-сервисы.
Во множестве API я не перечислил менеджеры очередей, но в нашей платформе есть поддержка Kafka и RabbitMQ.
Что касается объема данных — есть примеры реализации приложений, обрабатывающих событийную информацию, в том числе работающих с временными рядами показаний различных датчиков. Этих данных, действительно, очень много, они хранятся в БДРВ (база данных реального времени), которая может находиться как под управлением дата-центрической платформы, так и вне ее — с доступом в режиме логической витрины данных. В ответе на следующий комментарий я написал о том, что платформа физически хранит данные в хранилище, наиболее подходящем для данных того или иного типа. Избыточная нагрузка, создаваемая самой платформой при доступе к таким данным, невелика и не увеличивает радикально требования к оборудованию для размещения системы.
Зато появляется возможность легко построить бизнес-приложение под конкретную задачу, не думая о том, как собрать необходимые данные из десятков систем. Например, для мониторинга состояния промышленной установки кроме показаний датчиков нужны сведения о ремонтах и техобслуживании, нарядах на выполнение работ, персонале и его допусках, о конструкции установки — на обычном предприятии все эти данные находятся в разных бизнес-приложениях, и их интеграция является не тривиальной задачей.
В нашем же случае все это на себя берет платформа. Пусть на первом этапе данные продолжают находиться внутри старых бизнес-приложений, важно то, что для нового дата-центричного бизнес-приложения они представлены как единый граф. В результате написание приложения мониторинга состояния промышленной установки сводится к задаче создания фронт-энда, который будет отображать уже готовые данные.
У вас просто пост и так получился немного рекламный, просто рекламирует он идею, я думаю ничего страшного, если я его слегка разбавил описанием пары сложностей, возникающих при реализации похожих идей?
Что меня еще смущает всегда — так это то, что наличие общей модели для компании не приводит автоматически к тому, что хоть кто-то начинает эту общую модель понимать. Вот скажем живой пример — я наблюдал как-то живьем в проекте некую ER диаграмму, которая нормально читалась примерно в размере 2х2 метра (в напечатанном виде). Т.е. там были сотни сущностей, даже без атрибутов это много. При этом это всего-навсего модель процесса выдачи кредитов, и даже меньше — описание залогов для среднего банка. Ну т.е. с одной стороны — оно достаточно большое, чтобы никто не понимал его целиком, а с другой — достаточно маленькое, так как это лишь кусочек одного приложения.
В итоге, кстати, на той модели через месяцы разработки вылез баг постановки задачи — все считали, что владелец объекта залога — это просто атрибут этого объекта, строка, грубо говоря. А на самом деле это были владельцы, и их могло быть много, и каждый из них это некая сущность (уж не помню, ФЛ там, или ЮЛ, или кто еще). Ну т.е. наличие модели не спасает от вот таких довольно тривиальных багов.
Кроме того, для работы с моделями вот такого масштаба (сотни сущностей) нужен инструмент, какого я лично никогда не видел живьем. Обычные редакторы ER лажают по ряду причин — в том числе, коллективная работа не на высоте, а с большой моделью по определению будут работать много людей, и не по очереди, а сразу.
Мы практически никогда не визуализируем всю модель на одной диаграмме, только по кусочкам.
Если обращаться к методологии «сборки» онтологии под конкретные задачи, то мы используем следующие принципы:
- берем за основу онтологию верхнего уровня, например BFO (Basic Formal Ontology);
- берем готовые фрагменты из подходящих стандартных и отраслевых онтологий, таких как FOAF, Organization, SOSA/SSN и др.;
- достраиваем недостающие фрагменты.
Конечно, это всегда очень творческий процесс, одну и ту же предметную область можно смоделировать множеством разных способов. Некоторые вопросы методологии моделирования мы обсудили в нашей книжке «Онтологическое моделирование предприятий: методы и технологии».
Что касается инструментов — мы используем свой редактор, работающий с подмножеством OWL, которое мы считаем достаточным для создания корпоративных моделей. Физически модель располагается в хранилище триплетов RDF, например Apache Fuseki. Программно мы с ней работаем через собственную платформу-прослойку. Для визуализации используем сторонние инструменты, от WebVOWL для непосредственной визуализации графа до yEd Graph Editor для построения концептуальных диаграмм.
И второй интересный вопрос — а как делать дедупликацию модели? Ну т.е. если над ней работают много людей соазу, они вполне могут понять друг друга неверно. Опа — и у нас уже два атрибута с одним смыслом. И как понять, что с одним?
При совместной работе над моделью, действительно, возникают недоразумения. Прежде всего, мы заставляем аналитиков перед созданием нового класса или свойства обязательно проверять, нет ли уже такого в модели. Для описания точного смысла классов и свойств используются аннотационные свойства, такие как rdfs:comment, rdfs:isDefinedBy и другие, а также документация на модель. Можно использовать процедуру одобрения изменений в модель, такой программный инструмент у нас тоже есть: один аналитик предлагает, другой подтверждает.
Если дублирующий по смыслу атрибут появился, выполняется рефакторинг: все ссылки на ошибочно введенный атрибут заменяются на тот, который должен был быть использован. В графовой СУБД это очень просто сделать, в случае с мульти-модельным хранилищем сложнее, но с помощью созданных для этого инструментов — можно.
мне скорее технически было интересно. вот как в модели на примере Fuseki вы можете понять, что вот эта часть — то что относится к данной установке? На основании чего?
>нет ли уже такого в модели
В реальности эта задача — для хомо сапиенса, а ему свойственно ошибаться. Вы спокойно можете иметь два атрибута, похожих по описанию, и не сможете просто определить, это одно и тоже, или же нет. Ну т.е. rdfs:comment на мой взгляд тут мало поможет. Вы исходите из того, что над задачей работают скажем два аналитика, причем они оба из одного проекта?
Я же исхожу из того, что лишь по одной системе, которую я видел в прошлом проекте, этих аналитиков было десяток минимум, и никто из них не видел картины в общем — им хватало своей части выше крыши. А в проекте было еще штук пять других немелких систем, и у каждой свои аналитики, и зачастую — не один.
Не хочу сказать что это нормально и правильно, но это вполне обычно. Я поэтому и спрашиваю, что обычные инструменты тут мало помогают.
>Интересующие фрагменты модели определяем в зависимости от задачи.
мне скорее технически было интересно. вот как в модели на примере Fuseki вы можете понять, что вот эта часть — то что относится к данной установке? На основании чего?
Каждый объект в онтологической модели имеет идентификатор, записанный в форме URI. Например, наша установка может иметь такой URI: zavod.com/model/Unit1 (на самом деле URI может быть совершенно любой, он не несет смысловой нагрузки и не обязан дереференсироваться).
Соответственно, все триплеты, первым элементом которых является этот URI, сообщают нам что-то о свойствах и связях этой установки. Пройдя на какую-то глубину по связям, мы можем получить и все связанные с ней объекты, например — описание частей установки, фаз ее жизненного цикла и т.д.
>нет ли уже такого в модели
В реальности эта задача — для хомо сапиенса, а ему свойственно ошибаться. Вы спокойно можете иметь два атрибута, похожих по описанию, и не сможете просто определить, это одно и тоже, или же нет. Ну т.е. rdfs:comment на мой взгляд тут мало поможет. Вы исходите из того, что над задачей работают скажем два аналитика, причем они оба из одного проекта?
Часто над моделью работает более двух аналитиков, причем из разных команд — например, наши сотрудники и персонал заказчика. Тут помогает обычная дисциплина, четкое следование методологии, а также механизмы аудита — отслеживание уже внесенных в модель изменений. Проблемы случаются, но не так уж часто.
Еще помогают обсуждения изменений в модели и семинары, предназначенные для того, чтобы все аналитики представляли себе общую структуру модели.
Уточните пожалуйста, а как с точки онтологической модели должен быть организован процесс обновления данных? Один объект в DC-хранилище может быть изменен разными приложениями? Как в таком случае обойтись без физических персистентных срезов?
Раз несколько приложений могут изменять одни и те же свойства одних и тех же объектов, нужен механизм получения уведомлений о таких изменениях в реальном времени. Это может быть и websocket-соединение, и уведомления через брокеры типа Kafka.
И, совершенно верно, должны персистентно храниться состояния объектов после любой операции, с возможностью получить от платформы все состояния объекта, все операции, которые его изменяли, конкретное состояние на любой момент времени.
Я бы посмотрел на какое-нибудь реально используемое приложение с открытым кодом, сделанное с таким подходом (в котором основная база — это графовое хранилище с OWL). Не на академический пример, а на инструмент, который для практических целей применяют люди, вообще не знающие, что такое OWL. Как wordpress какой-нибудь. Это должно демонстрировать преимущества такой системы в чисто практическом, а не идеологическом смысле, а ведь только таковые и имеют значение. Знаю про data.world, но это всё-таки немного не то — ближе к СУБД, чем к приложению для конечного пользователя.
Domain Driven Design учит нас, что программная система есть воплощение модели предметной области. Сущностям в реальном мире соответствуют сущности в программе. Но более аккуратно будет сказать, что модель в системе почти никогда не бывает одна — их всегда много, потому что разные организации, подразделения одной организации и даже разные группы пользователей видят мир по-разному. Для одной и той же ситуации в реальности можно изобрести бесконечное количество моделей, и применимость каждой из них зависит от поставленной цели.
Например, сущность InventoryItem для склада имеет одни параметры (местоположение, объём занятого места, владелец, ...). Для мастерской она отображается в разные сущности, например, Part, Tool, RawMaterial,… — которые, хотя и лежат на складе, но в процессах мастерской совсем разные функции выполняют.
Выбирая правильную модель для данных, вы смотрите на то, какие типичные операции с этими данными будут производиться и, следовательно, решаете, как должны храниться данные, чтоб указанные операции были возможны. Хотя бы на глаз оцениваете вычислительную сложность этих операций. Изучаете требования к правам доступа, потому что бывает, что требуется хранить, условно, имя в одном месте, а email в другом, в изолированных друг от друга хранилищах. Иначе вы не получите контракт.
Я не верю, что может существовать один-единственный наилучший способ создавать модели данных, хранить их, делать запросы, и всё это — эффективно.
Имея сколько-то миллиардов иммутабельных строк в таблице, я скорее всего возьму колоночную СУБД. В другом месте — документ-ориентированное хранилище, потому что надо динамически менять схему. В третьем — ElasticSearch для поиска, где-то ещё — Redis для кэша, и так далее.
Это не бинарная шкала, это континуум применимости разных моделей к разным кусочкам реального мира для разных целей. Здесь нет ничего чёрно-белого, ничего единственно правильного, никакой генеральной линии партии.
Data centric manifesto, однако же, выглядит очень чёрно-белым: за всё хорошее и против всего плохого, — и крайне хайповым. Data centric revolution… сам этот апломб опускает уровень обсуждения с технического на идеологический; не люблю такого. С чего авторы решили, что это революция? Чем это принципиально отличается от привычной для больших организаций схемы, когда в центре стоит какая-нибудь Oracle, а вокруг неё крутится сотня приложений? Схемы, от которой люди годами пытаются уйти, потому что взаимные зависимости между приложениями сводят их с ума? Вы поменяли табличку (или каокой-нибудь rdfs:domain) в интересах приложения X, и у вас приложения Z, P и N стали валиться удивительным и необычным образом. Мы это уже проходили и заработали некое количество седых волос, нет?
Потом, конечно, появился новый хайп в виде микросервисов, которые тоже подходят не всегда. Но когда-нибудь же надо позврослеть? Осознать, что серебряной пули нет и никогда не будет. Реальный мир сложен. Наша профессия как его отражение тоже сложна. Хватит качаться, повиснув на маятнике моды, в поиске универсальных решений сложных проблем, и метаться то туда, то сюда, снова и снова, и конца этому не видно. Нет таких решений. Надо в каждом отдельном случае думать головой, анализировать, опираться на опыт, подлечивать граблями набитые шрамы.
Моё мнение заключается в том, что семантические технологии могут быть полезны скорее для общения между системами, которые могут хранить данные и манипулировать ими внутри так, как им заблагорассудится, потому что метод этой манипуляции данными внутри приложения может быть в таком случае оптимизирован до предела, радуя программистов, сокращая carbon footprint и генерируя квадриллионы розовых пони в фемтосекунду.
Кроме того, не потребуется тогда даже переписывать гигатонны существующего кода в угоду очередной сверкающей блёстками идеологии, что было бы астрономически дорого.
Мы уже несколько лет занимаемся созданием дата-центрических решений, в которых управление данными происходит с помощью онтологических инструментов. Пока в нашей практике нет предприятий, которые бы полностью перешли на такую архитектуру, но есть вполне убедительные примеры их реализации для конкретных и довольно сложных областей практической деятельности. Как правило, наши заказчики — крупные предприятия, которые в силу уникальности своих задач имеют дело с большим количеством не стандартного и/или самописного ПО, и думают о том, как с точки зрения архитектуры упростить его дальнейшее развитие, интеграцию и сопровождение.
Примеров проектов с открытым кодом, реализующих дата-центрические принципы, к сожалению, сходу не назову.
Вы правы, когда говорите, что разные группы пользователей видят мир по-разному. В «традиционном» подходе это приводит к созданию разных информационных представлений одних и тех же бизнес-объектов и их обработке в разных приложениях. Идея дата-центричности в сочетании с использованием онтологического моделирования как раз позволяет остаться в рамках одной связной модели, отражая несколько взглядов на каждый объект. При этом можно сохранить то общее, что видят в объекте все пользователи (начиная с названия/идентификационных данных сущности), и одновременно отразить различия — в его принадлежности типам/классам, наборе свойств, конструкции (наборе составляющих объектов).
Обычный подход к проектированию модели данных состоит, как вы верно указали, в том, чтобы построить структуру данных в хранилище, исходя из набора операций, которые с этими данными нужно будет выполнять. В онтологическом моделировании мы стараемся создавать модель так, чтобы она была наиболее близка структуре представлений бизнес-пользователей о реальности, на этапе моделирования совершенно не думая о том, в какой структуре данные будут представлены физически. Это позволяет сократить разрыв между тем, какими категориями и понятиями мыслит пользователь, и структурой данных, упрощает аналитические задачи.
Но, разумеется, на этапе проектирования хранилища мы не можем не думать о том, какой объем данных будет представлен в той или иной структуре, и как мы их будем обрабатывать. Сама по себе идея дата-центричности на этот вопрос не отвечает, но на него могут ответить производители конкретных платформ. Было бы идеально хранить всю информацию в одной графовой базе данных, но на практике это сейчас невозможно. Поэтому, например, наш продукт с логической точки зрения представляет собой мульти-модельное хранилище, которое может использовать реляционную, колоночную, документ-ориентированную или любую другую модель физического хранения для объектов разных классов. Для этого платформа подключается к множеству СУБД разных типов. На уровне настроек платформы указывается, в какой СУБД должны храниться объекты тех или иных классов. Эти настройки довольно детальны: например, если мы выбираем в качестве хранилища таблицу Postgres, мы можем использовать ее со стандартной для платформы структурой, которая не требует создания столбцов для каждого свойства (используем колонку типа jsonb), или же создать конкретные столбцы для каждого свойства и настроить по ним индексы, сегментирование и т.д. При этом колонка jsonb все равно существует — она предназначена для хранения значений тех свойств, которые будут созданы в модели «на лету», и для которых администратор еще не успел настроить мэппинг на конкретные колонки.
Конечно, это уже технические детали конкретной реализации. Идея же состоит в том, что платформа управления данными может абстрагировать приложение-клиент от физических деталей хранения информации, и в то же время обеспечить гибкость управления этими деталями для администратора платформы, отделить процесс моделирования предметной области от процесса настройки физической структуры данных. С точки зрения бизнес-приложения все данные представляют собой единый граф, а физически могут находиться где угодно.
Про черно-белое и хайп: полностью с вами согласен. Конечно, применение каждой технологии, в том числе дата-центрической архитектуры, оправдано только в определенных условиях. В нашем случае предпосылкой является очень сложная и быстро изменяющаяся модель данных, содержащая десятки тысяч типов сущностей и свойств. Но я говорю об этом уверенно, т.к. события последнего времени, включая пандемию, показали, насколько быстро могут возникать новые виды данных, критически влияющих на бизнес, насколько быстро их нужно включать в обработку в ИТ-системах. У нас есть свои «истории успеха», связанные с очень быстрой реализацией обработки сложных данных за пару недель в условиях, когда обычный процесс проектирования и реализации изменений в ИТ-системах занял бы месяцы.
И манифест, и эта статья намеренно имеют провокационную составляющую. И, конечно, словосочетание «волшебная пуля» я употребляю с иронией. Несмотря на это, все приведенные в статье и комментариях рассуждения по сути вопроса имеют рациональную основу и подкреплены практикой.
Дата-центрическая архитектура: «волшебная пуля» от интеграционных проблем