Data Mesh и Microservice: плюсы и минусы каждого подхода

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

Что такое микросервисная архитектура?

Термин Microservice Architecture (микросервисная архитектура, или МСА) описывает способ дизайна приложений в виде набора независимо развертываемых сервисов. Единого точного описания нет, но существует набор общих характеристик: организация сервисов вокруг бизнес-потребностей, модульность, автоматическое развертывание, использование шины данных для обмена и децентрализованный контроль над данными, симметричная архитектура: микросервисы взаимодействуют друг с другом однорангово, а не иерархически.

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

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

• Продуктовое/иерархическое управление — как проекция симметричной архитектуры MCA.
  
• Корпорация/франшиза — как пример модульности, делегирования обязанностей и прав на локальный уровень.
  
• Унитарное государство/федерация — как система контрактов внутри сервисного и межсервисного взаимодействия.

MCА в мире хранилищ данных: Data Mesh

Так же, как и другие области ИТ, хранилища данных (ХД) не обошли стороной этап, основанный на принципах построения на базе монолитных архитектур. При появлении в компаниях средних и больших данных монолитное ХД как концепция начинает сбоить и приводит к удорожанию и/или усложнению подобных систем по экспоненте. Логичным этапом эволюции архитектурной мысли стала «адаптация» микросервисной архитектуры под мир хранилищ данных.

Сформулируем общеизвестные принципы Data Mesh.

• Децентрализованная архитектура с учетом доменов. Вместо централизованного подхода к управлению данными Data Mesh предлагает организовать ответственность за данные вокруг бизнес-функций или доменов. Это позволяет более эффективно управлять данными в сложных и масштабных средах.
  
• Данные как продукт. Data Mesh рассматривает данные как продукт, который предоставляется пользователям. Это подразумевает, что данные на доменном уровне должны быть высококачественными, документированными и доступными через самообслуживание. 
• Самообслуживаемая инфраструктура данных. Data Mesh предполагает создание платформы для самообслуживания, где пользователи могут легко находить и использовать данные — без необходимости обращения к централизованным командам. Реализуется через наборы сервисов, именуемые платформой данных.
  
• Федеративные инструменты управления. Data Mesh включает фиксированные политики, которые регулируют доступ к данным и их использование. Это позволяет обеспечить согласованность, прозрачность и безопасность. Реализуется через системы управления данными.

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

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

Учитывая такое внимание к процессам и управлению, Data Mesh не определяется через Data WareHouse, Data Lake или LakeHouse. А также не определяется инструментами, используемыми для запросов, интеграции или каталогизации. Это скорее подход к проектированию данных. Микросервисная архитектура расширяет возможности команд, позволяя им самим решать, как лучше всего реализовать свой сервис. Data Mesh обещает аналогичные свободы, где детали реализации любых конвейеров или процессов имеют второстепенное значение. В мире ячеек данных важны наборы данных и способ их представления.

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

Еще одним местом энтропии является беспорядок между ограниченными контекстами. В случае с МСА это API и capability. Data Mesh зависит от возможности идентифицировать дискретные, независимые области данных, которые могут быть реализованы отдельными частями бизнеса. Концепция «ограниченного контекста» из предметно-ориентированного проектирования (DDD) позволяет этим управлять. DDD признает, что по мере роста организации становится труднее построить единую модель всей области. Вместо этого крупную систему можно разделить на набор связанных и автономных «ограниченных контекстов» (микросервисов), каждый из которых имеет отдельную собственность.

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

Принципы организации Data Mesh: пример из практики

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

Стратегии

• Разделение на домены

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

• Единая инфраструктура самообслуживания

И создание коммунальных сервисов базовых дата-тулзов в виде *aaS. В компании были разработаны схемы автоматизации сервисов: оркестрирования (Airflow aaS), хранения (S3ааS, DBaaS), компьют-ресурсов на базе k8s, созданы соответствующие линии поддержки по каждому сервису. Кроме того, была разработана схема конвейера данных от сырья до витрин данных — жесткий сценарий «проливки» данных по слоям, использования сервисов *aaS, а также коммунального кластера колоночной БД с обязательной изоляцией по ресурсам между источниками данных доменов. От теоретического принципа полностью раздельного хранения наборов данных пришлось отойти, чтобы сэкономить на однородной поддержке коммунальной системы.

Дополнительный бонус — разработанные *aaS-инструменты используются не только в аналитической платформе, но и в продуктах, не связанных с анализом данных.

Читайте также

Цифровизация в России: тренд или шаг вперед для рынка

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

• Сквозные инструменты управления / контроля данных (Data Catalog и Data Quality)

Был разработан свой Data Catalog, ставший source of truth для всей метаинформации о доменах и всех источников данных. Расползание метаинформации является одной из частых проблем при переходе от монолита к распределенным системам. Поэтому очень важно на старте работ определить единый source of truth для всей метаинформации.

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

Тактики

• Исповедуем принцип подобия. Была выделена атомарная единица вычислений (ETL). Она подобна в разных измерениях: по слоям (raw, ods, dds) и по источникам. Таким образом, сервисы обработки данных имеют одинаковые интерфейсы, логирование и этапы обработки. Это позволяет унифицировать сервисы платформы данных, чтобы вести разработку быстрее и эффективнее.
  
• Независимость по ресурсам. Между источниками и объектами источника, в хранении, в вычислительных ресурсах, в CI/CD, во владении данными. Проблемы в одном источнике не должны влиять на конвейеры соседних источников. Эта тактика локализует проблему до объекта источника, без остановки всего конвейера данных.
  
• Дата-контракты на входе в дата-платформу. Данные обязаны быть детерминированы. Для этого была разработана система контрактов для всех схем данных, которые попадают в платформу: она увеличивает входной порог для команды источника при подключении. Взамен мы получаем прозрачные схемы данных, что позволяет экономить на внутренних проверках при реализации сервисов обработки данных. Проще код — меньше ошибок.
  
• Контроль эволюции схем данных. Через заранее определенную таблицу эскалации. На старте зафиксировали сценарии эволюции схем данных. Некоторые сценарии запретили директивно — например, физическое удаление данных в источнике. Подход добавляет немного сложности для источников и снижает функциональность, однако заметно повышает стабильность при изменении структуры данных.

Получается, что вместо классической централизованной команды хранилища данных, которая отвечала как за сервисы и практики, так и за сами данные, появились децентрализованные команды в каждом из доменов. Число источников увеличилось со 100 до 250 и постоянно растет, объем данных вырос до 1 Пбайт, однако на смену постоянно растущему бэклогу и «гонке приоритетов» между разными подразделениями пришла ситуация, когда команда может грамотно расходовать свои ресурсы. Основная сложность — бизнес-логика — остается в доменах, а техническая логика максимально шаблонизирована и подобна от источника к источнику. Внедренные стратегии и тактики позволяют поддерживать платформу данных малой командой — около 10 человек. А time-to-market сократился с полугода до нескольких недель.

***

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

Data Mesh имеет некоторое сходство с микросервисами — и это повод воспринимать проблемы архитектуры как предупреждение. Монолиты могут быть громоздкими, но распределенные монолиты, вероятно, еще хуже. Расширение прав и возможностей на местном уровне может показаться разумным, но это сопряжено с риском создания множества несовместимых хранилищ данных.

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