Data Mesh: Топологии и гранулярность доменов
Прошедший год работы в Microsoft был, мягко говоря, интересным! Я принимал участие в многочисленных переговорах с заказчиками, семинарах и сессиях по проектированию архитектуры данных. В ходе этих мероприятий data mesh часто становилась главной темой для обсуждения.
Я понял, что data mesh – тема относительно новая. Это концепция, которая должна формироваться с учетом уникальных требований компаний к организации данных, их безопасности, темпам изменений, технологиям и управлению соответствующими затратами. Сбалансировать все эти требования нелегко, поэтому компании выбирают общую архитектуру, соответствующую большинству из них.
В этой статье я хочу рассказать Вам о различных паттернах проектирования архитектуры данных и о том, какие соображения следует учитывать при выборе каждого из них. Я объясню, что именно движет компаниями, и почему они отдают предпочтение тому или иному паттерну.
Сценарий 1: Мелкозернистая полностью федеративная сетка
Первый шаблон проектирования заключается в том, как Zhamak Dehghani описывает data mesh в ее чисто теоретическом виде. Она является мелкозернистой, высокофедеративной и использует множество небольших и независимых развертываемых компонентов. На рисунке ниже приведен абстрактный пример такой архитектуры.
В приведенной выше модели распределение данных происходит по принципу "равный-равному", а все метаданные, связанные с управлением, логически централизованы. Данные в этой топологии принадлежат каждому отдельному домену, управляются им и совместно используются. Домены остаются гибкими и не зависят от центральной команды в вопросах координации и распределения данных.
В мелкозернистой и полностью федеративной топологии каждый продукт данных рассматривается как архитектурный квант. Проще говоря, это означает, что Вы можете создавать множество различных архитектур продуктов данных для обслуживания и передачи данных между доменами. Изображение того, как же это работает, Вы найдете ниже.
Мелкоструктурная и полностью федеративная сетка обеспечивает тонкую специализацию доменов. Она обеспечивает организационную гибкость и меньшее количество зависимостей, поскольку взаимодействие осуществляется по принципу "многие-ко-многим". Наконец, она способствует интенсивному повторному использованию данных, поскольку существует высокая степень создания продуктов данных. Каждый продукт данных становится архитектурным квантом.
Хотя мелкозернистая и полностью федеративная сетка выглядит идеально, при более глубоком рассмотрении у компаний все же возникают опасения. Во-первых, топология требует согласования со всеми доменами с точки зрения стандартов, метаданных, особенностей управления и безопасности. Процесс стандартизации по всем этим параметрам, увы, не происходит спонтанно. Это достаточно сложный процесс, требующий преодоления различных границ. Для этого необходимо провести свою архитектуру и методы работы через различные этапы: предварительную концептуализацию, концептуализацию, обсуждение, написание и внедрение. При этом важно иметь поддержку со стороны широкой аудитории.
Кроме того, компании опасаются дублирования возможностей и высокой загрузки сети. Многие архитектуры продуктов данных резко увеличивают количество инфраструктурных ресурсов. Это может сделать архитектуру дорогостоящей. Гранулярность архитектур продуктов данных также становится проблематичной при интенсивном выполнении междоменного поиска данных и проверке их качества. Гранулярность данных и их децентрализация не идут рука об руку…
Мелкозернистая полностью федеративная сетка - отличный вариант, … но труднодостижимый. Я часто вижу такую топологию в компаниях, которые «родились» в облаке, работают в мультиоблаке, являются относительно молодыми и имеют много высококвалифицированных инженеров-программистов. Подобная топология также может быть хорошим выбором, если в компании УЖЕ существует высокая степень автономии.
Сценарий 2: Мелкозернистая и полностью управляемая сетка
Чтобы преодолеть проблемы федерации, многие компании корректируют предыдущую топологию, добавляя центральный уровень распространения. Хотя эта топология и не реализует полноценную архитектуру сетки данных, она все же соответствует многим ее принципам: каждый домен имеет четкую границу и автономное право собственности на свои приложения и продукты данных, но эти продукты должны распространяться через центральную логическую структуру.
Топология, представленная выше, решает некоторые проблемы, наблюдаемые в мелкозернистой полностью федеративной сетке. Например, проблему распределения и гравитации данных. Доменам при этом не нужно распределять большие исторические наборы данных, поскольку они хранятся в более тесном контакте на общем уровне хранения.
Компании также считают, что подобная топология легче решает проблемы конформации. Например, можно заблокировать распространение или потребление данных, обеспечить доставку метаданных или потребовать определенного способа работы. Топология "несколько рабочих пространств - общее озеро" является лучшей практикой, которая довольно часто применяется компаниями. Домены управляют и создают продукты данных в своих собственных рабочих пространствах, но распространение среди других доменов происходит через центральный уровень хранения с использованием специфических для домена контейнеров.
Кроме того, существуют компании, предоставляющие централизованно управляемые вычислительные услуги. Например, преобразования, специфичные для каждого домена, применяются в каждом домене с использованием выделенных вычислительных ресурсов, а обработка исторических данных производится централизованно с использованием общих пулов вычислительных ресурсов. Надо признаться, что такой подход значительно снижает затраты.
Также следует учитывать и более сильную централизацию и конформацию, обусловленную подобной топологией. Это приведет к увеличению времени выхода на рынок и усилит взаимосвязь между доменами. Я также считаю, что данная топология будет более сложной в мультиоблачных средах, поскольку она требует разработки центрального и распределенного логического объекта, который будет беспрепятственно перемещать данные, соблюдая при этом все стандарты управления. Реализовать это с помощью "облачных" стандартов сложно, учитывая характер того, ЧТО предлагают сегодня поставщики облачных решений.
Тем не менее, я вижу, что многие компании выбирают полностью управляемую топологию. В основном ее используют финансовые учреждения и государственные органы, а также другие компании, для которых качество данных и соответствие нормативным требованиям гораздо важнее оперативности.
Сценарий 3: Гибридная федеративная сетка
Далеко не все компании могут похвастаться наличием большого числа высококвалифицированных инженеров-программистов. Многие компании довольствуются устаревшими унаследованными системами, которые трудно поддерживать. Подобные компании зачастую внедряют сетки данных, как показано на рисунке ниже.
Что именно отличает эту топологию от других топологий? В ней меньше федерации и больше централизации. Есть центральный экземпляр платформы, на которой поддерживаются и создаются продукты данных. В тех случаях, когда команда домена не обладает необходимыми навыками или ресурсами, ответственность за продукты данных берет на себя команда поддержки или платформы.
В отношении потребляемых данных обычно наблюдается более высокая степень автономности и распределение по типу сетки. Различные команды могут работать над различными сценариями использования и нести ответственность за свои преобразованные данные и аналитические приложения. Полученные результаты или вновь созданные продукты данных распространяются между пользователями или возвращаются в центральную платформу.
При использовании данной топологии необходимо учитывать, что домены, связанные с исходными системами, требуют больших затрат на управление, так как их, скорее всего, будет обслуживать центральная команда. Организации, использующие такую архитектуру, скорее всего, будут страдать от различных операционных моделей и более сложных руководств и принципов. Кроме того, могут существовать противоречивые правила распределения данных, поскольку потребляющие домены часто становятся предоставляющими доменами.
Сценарий 4: Сетка, ориентированная на цепочку создания стоимости
Организации, специализирующиеся на управлении цепочками поставок, разработке продукции или транспортировке, в значительной степени уважают цепочки создания стоимости. Что именно характеризует все эти компании? То, что они требуют гиперспециализации или выравнивания потоков для создания ценности для своих клиентов. Такие цепочки создания стоимости часто тесно взаимосвязаны и оперативны по своей природе. Кроме того, они обычно обрабатывают данные в прямом и обратном направлении: от операционных к аналитическим и обратно к операционным.
В данной структуре цепочка создания стоимости рассматривается как группа небольших доменов, тесно взаимодействующих между собой. Такие цепочки требуют более высокого уровня автономии и поэтому могут рассматриваться как более крупные домены. В такой топологии, как правило, различают внутридоменные и междоменные продукты данных. Только при пересечении границ цепочки создания ценности обеспечивается соблюдение центральных стандартов. Можно также разрешить или смешать различные типы моделей управления: строгое соблюдение стандартов в одном домене - ослабленный контроль в других доменах.
При использовании цепочек создания стоимости следует учитывать, что подобная модель требует более четкого руководства со стороны архитекторов данных, поскольку границы могут быть не всегда явными.
Сценарий 5: Крупнозернистая выровненная сетка
Некоторые организации получили масштаб за счет органического роста, слияний и поглощений. Такие организации, как правило, имеют сложные ландшафты, включающие сотни и даже тысячи приложений и систем. Внутри этих сложных структур наблюдаются различные уровни управления, согласования и декомпозиции. Некоторые структуры могут быть самостоятельными и функционировать автономно, в то время как другие являются более интегрированными.
Структуры, наблюдаемые в таких крупных компаниях, как правило, достаточно велики; считается, что домены содержат десятки, сотни приложений. Такую топологию я определяю как крупнозернистую выровненную сетку.
Сложность такой топологии заключается в том, что границы не всегда четко выражены. Данные не совпадают с границами доменов и бизнес-функций. Это может привести к политическим распрям по поводу того, кто контролирует данные и какой суверенитет необходим.
Еще одна проблема, связанная с топологией сетки крупнозернистых данных, - это дублирование возможностей. Вполне вероятно, что каждый крупнозернистый домен использует свою собственную платформу данных для приема, преобразования и распространения данных. Подобный подход к внедрению множества платформ для крупных доменов приводит к дублированию возможностей. Например, управление качеством данных и управление основными данными, скорее всего, потребуется в масштабах всего предприятия. Такой федеративный подход может привести к многочисленным реализациям управления качеством данных и основными данными на всех платформах данных. Для обеспечения последовательной реализации этих услуг на всех платформах необходимо тесное сотрудничество и руководство.
Такой многоплатформенный подход часто порождает множество вопросов: Как откалибровать платформы данных и домены? Могут ли более крупные домены совместно использовать платформу данных? Как справиться с перекрывающимися требованиями к данным, если одни и те же данные требуются на разных платформах? Как эффективно распределить данные между этими большими доменами и экземплярами платформ? Хорошей отправной точкой является правильная декомпозиция домена организации перед внедрением сетки данных. Далее следует установить права собственности на приложения и данные. Затем - сформулировать четкие рекомендации по созданию продуктов данных.
При рассмотрении топологии крупнозернистой сетки важно четко определить переход к сетке данных. Эта топология характеризуется более высоким уровнем автономии и, следовательно, требует более жестких политик управления и возможностей платформы самообслуживания данных. Например, регистрация и обеспечение возможности обнаружения продукта данных может потребовать специальных указаний, основанных на технологиях и возможностях взаимодействия, выбранных доменами. В противном случае может ухудшиться видимость между платформами или возрасти стоимость в связи с ростом числа доменов.
Крупнозернистая автономия противоречит истинной реализации сетки данных. Это создает риск того, что данные будут объединены и интегрированы до распространения продуктов данных. Возникает риск создания больших монолитов. Такие крупные монолиты создают дополнительные связи между системами. Кроме того, они вносят путаницу в права собственности на данные, поскольку продукты данных распространяются с помощью систем-посредников, что затрудняет определение реального источника их происхождения. Для снижения этих рисков необходимо внедрить такие принципы, как сбор только уникальных данных и сбор данных непосредственно из источника происхождения с использованием его уникального доменного контекста.
Сценарий 6: Крупнозернистые управляемые сетки
Некоторые крупные и сложные организации стремятся преодолеть сложность, одноранговое распределение и отклонения в совместимости путем создания центрального уровня распределения, который располагается между этими более крупными структурами.
В этой топологии команды или организационные структуры договариваются о платформе распространения или рынке, через который можно публиковать и потреблять продукты данных.
Все подходы, описанные выше, требуют высокой зрелости от команды разработчиков платформы данных. Компоненты должны быть самообслуживаемыми и хорошо интегрироваться между центральным слоем распределения и доменными платформами. Управление метаданными, стандарты и политики управления имеют решающее значение. Если центральная группа по архитектуре и управлению не имеет сильного мандата, то такие архитектуры могут потерпеть неудачу.
Заключение
Data mesh может полностью переосмыслить значение управления данными. Вместо централизованного управления всеми областями управления данными команда становится ответственной за определение того, что представляет собой эффективное управление данными и что является платформой самообслуживания данных.
При переходе к федеративной сетке компании идут на определенные компромиссы. Одни организации предпочитают высокую степень автономии, другие - качество и контроль. Одни компании имеют относительно простую структуру данных, другие - большую и сложную. Создать идеальную архитектуру данных не так-то просто, поэтому я рекомендую рассматривать сетку данных как основу. Здесь нет правильного или неправильного. Сетка данных включает в себя лучшие практики и принципы. Некоторые из них могут Вам понравиться, другие - нет. Поэтому внедряйте то, что больше всего подходит именно Вам.
