X

Блог Oracle в России и СНГ

Как распределенная Data Mesh может быть одновременно ориентирована на данные и основана на событиях

Автор: Луиджи Скаппин (Luigi Scappin)

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

— прогноз для облачных решений от компании IDC, 2021 г.

От ориентации на программный код к ориентации на данные

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

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

В архитектуре, ориентированной на код, семантика данных встроена и находится в коде приложений, тогда как в архитектуре, ориентированной на данные, семантика данных управляется как основной актив вместе с данными, независимо от кода приложений.

Доменная архитектура с ориентацией на данные

Мне понравилась статья Жамака Дехгани (Zhamak Dehghani) «Как перейти от монолитного озера данных к распределенной Distributed Data Mesh», в которой предлагается применить принципы проектирования на основе доменов к платформам данных. Вы также можете обратиться к этой статье по следующей ссылке:

Безусловно, если и производители и потребители данных — это приложения и компании типа черного ящика, тогда третья сторона должна запрашивать данные у производителя, чтобы предоставлять их потребителю. Эту работу обычно выполняет основная команда, которая отвечает за озеро данных или хранилище данных и при необходимости выполняет преобразования, очистку или корреляцию данных.

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

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

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

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

Не только производители операционных данных и не только потребители аналитических данных

Мне также понравилась статья того же автора «Принципы Data Mesh и логическая архитектура». Я согласен с большей частью статьи, однако не совсем понимаю, зачем автор постоянно подчеркивает разницу между управлением операционными и аналитическими данными.

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

Аналитики придумали новые термины, например «транслитический», пытаясь описать совместное управление «транзакционными» и «аналитическими» данными.

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

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

Центры гравитации данных

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

С резким ростом объема данных их перемещение становится все более трудным, медленным и дорогостоящим. Гораздо проще перемещать приложения в данные, чем данные в приложения. Центры гравитации данных «притягивают» не только приложения, но и другие данные, требующие согласованности, и их необходимо тщательно учитывать при проектировании архитектуры данных.

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

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

Виртуализация данных: преимущества и недостатки

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

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

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

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

 

Метод на основе событий — вот выход

Итак, как же построить Distributed Data Mesh, не столкнувшись с проблемой гравитации данных? Давайте попробуем сделать это, используя архитектуру на основе событий при сохранении подхода, ориентированного на данные.

В статье Бена Стопфорда (Ben Stopford) «Дихотомия данных» представлена концепция совместного использования данных из разных предметных областей (доменов) в потоках событий. Давайте посмотрим, можно ли применить эту концепцию для построения распределенной архитектуры даже тогда, когда домены приложений разъединены не полностью, а совместно используют некоторые данные.

Идея кажется многообещающей, но с учетом известной статьи Мартина Фоулера (Martin Fowler) «Источник событий», неудивительно, что фокус здесь в основном на микросервисах и, следовательно, используется подход, сильно ориентированный на код, и предпринимается попытка «создавать сервисы на основе магистрали событий», как описано в другой статье Бена Стопфорда. Попытаемся обобщить основные концепции из этой статьи: сервисы могут взаимодействовать друг с другом тремя способами: команды, события и запросы:

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

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

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

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

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

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

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

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

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

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

При таком подходе каждый домен может легко управлять своими основными данными, совместно используемыми его сервисами, а также может предоставлять другим доменам свои основные данные почти в режиме реального времени. Один и тот же домен может также согласованно использовать данные только для чтения и данные почти в режиме реального времени, предоставляемые другими доменами.

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

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

В заключение отмечу, что лучший способ реализовать Distributed Data Mesh — это построить архитектуру на основе событий, с использованием масштабируемой магистрали на основе событий, такой как Kafka, для обработки событий как на уровне сервиса, так и на уровне базы данных, как внутри, так и за пределами доменов. Однако архитектура на основе событий должна быть также ориентирована на данные, в максимально возможной степени используя способность баз данных преобразовывать транзакции в согласованные потоки событий, а затем обратно в копию базы данных почти в реальном времени, что резко снижает потребность в поиске в коде логики данных.

Подведем итог

Как я уже упомянул в начале, в прогнозе для облачных решений от компании IDC за 2021 год говорится:

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

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

Я думаю, что хорошим примером этого является описанная в этой статье Distributed Data Mesh.

 

 

 

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.