Data mesh подходит только для аналитических данных?
Data mesh подходит только для аналитических данных? Это один из самых распространенных вопросов, возникающих при обсуждении data mesh с моими клиентами. Несмотря на то, что data mesh в основном ассоциируется исключительно с аналитическими данными, многие ее принципы могут быть эффективно применены и к операционным данным. В данной статье мы рассмотрим, как data mesh можно использовать как для аналитических, так и для операционных задач.
Операционные данные - это данные, которые используются для управления бизнесом в режиме реального времени, например, транзакционные данные и данные о клиентах. Применяя принципы data mesh к операционным данным, организации получают возможность обеспечить высокое качество данных, их доступность и возможность оперативного использования для принятия бизнес-решений.
Архитектура операционных данных отличается от архитектуры аналитических данных, поскольку операционная область обрабатывает сравнительно простые команды и требует обработки небольших наборов данных в режиме реального времени, а аналитическая область сфокусирована на чтении данных и требует сложного анализа данных, который использует большие наборы данных и может быть растянут во времени. Однако у этих концепций есть много общего.Ваши бизнес-возможности одинаковы, если смотреть на архитектуру Ваших данных через призму операционной или аналитической деятельности. За соответствующими приложениями стоят команды, которые управляют ими и обеспечивают их работоспособность. Язык, который команда использует для разработки этих приложений, один и тот же. В конечном итоге уникальный контекст, повлиявший на разработку того или иного приложения, соответствует контексту, оказывающему влияние на разработку Ваших продуктов данных, событий и API. Кроме того, переход к приложениям и автономным командам в рамках управления событиями и API аналогичен тому, что лежит в основе перехода к архитектуре data mesh. Поэтому вполне целесообразно применять схожие передовые практики для управления данными, событиями и API.
Данные и область интеграции
В контексте построения архитектуры data mesh landing zone или инфраструктурные чертежи являются основными строительными блоками для создания современной платформы данных. По сути, это стандартизированный и автоматизированный подход к развертыванию облачных рабочих нагрузок. Эти landing zone/ инфраструктурные чертежи помогают организациям достичь стандартизации как для аналитических, так и для операционных рабочих нагрузок.
На схеме, представленной ниже, изображена landing zone, предназначенная как для операционных, так и для аналитических целей. Она включает в себя компоненты хранения, обработки данных в режиме реального времени и в автономном режиме, компоненты анализа и потребления данных, а также элементы управления.
В рамках самой архитектуры можно применять различные паттерны как для аналитических, так и для операционных целей:
Паттерн распределения данных: В аналитическом паттерне данных (data mesh) каждая команда владеет и управляет собственными продуктами аналитических данных. Данные предоставляются другим командам, например, через каталог данных. Каждая команда отвечает за обеспечение качества и надежности своего продукта данных. Данные могут потребляться с помощью различных паттернов потребления, таких как API паттерн или паттерн легкого запроса виртуализации.
Паттерны интеграции приложений: В операционной модели каждая команда владеет и управляет собственными операционными событиями и продуктами API. Каждая команда отвечает за обеспечение качества и надежности своих продуктов данных. API могут использоваться для команд и последовательного чтения. События могут использоваться для установления асинхронной связи.
Обратите внимание на то, что перечисленные выше модели могут между собой пересекаться. Слой процессов и интеграции может подключаться к любому слою базовой архитектуры данных. Например, событие может вызвать логическое приложение, которое считывает данные из серебряного слоя по обогащению данных. Отсюда слой обработки передает данные напрямую в другие домены и системы.
Диаграмма принятия тактических решений
Разработка хорошего приложения и решения по интеграции данных - задача довольно сложная, поскольку существует несколько возможных "правильных" и взаимодополняющих решений. Очень часто это определенный компромисс между различными параметрами: производительностью, удобством обслуживания, гибкостью управления, стоимостью, устойчивостью и так далее. Эти аспекты требуют от Вас глубокого понимания бизнес-задачи, которую Вы пытаетесь решить. Представленная ниже диаграмма объединяет все основные паттерны, которые обсуждались ранее, что делает ее ценным ресурсом при принятии обоснованных тактических решений.
Хотя продукты данных, API и события предназначены для различных вариантов использования, при задействовании всех этих паттернов в одних и тех же границах происходит дублирование в контексте домена. Поэтому лично я рекомендую согласовать все Ваши интеграционные сервисы и сервисы данных с точки зрения руководства по проектированию, документации, регистрации моделей данных и интерфейсов. Если все сделано правильно, все атрибуты интерфейса должны быть связаны с одним и тем же набором элементов или бизнес-терминов в Вашем каталоге.
Заключение
В заключение хотелось бы еще раз подчеркнуть тот факт, что data mesh - это не только про аналитические данные. Операционные сценарии использования также могут извлечь из нее пользу. Рассматривая данные как продукт и применяя децентрализованный подход к архитектуре данных, организации могут заметно повысить производительность операций с данными и эффективность бизнеса в целом.