Мартин Фаулер в мае 2019 года опубликовал статью Zhamak Dehghani, а затем, свою статью, в которой ссылаясь на оригинал описал свои мысли по поводу оригинальной статьи. Автор описывает подход к работе с озером данных — data mesh. Тут надо рассказать о моём понимании происходящего: если вы записываете данные в подготовленном виде, например, в таблицы своей СУБД, то есть вы трансформируете их перед записью, то вы используете хранилища данных, если вы складываете сырые данные как есть, например логи веб-серверов, на сервера amazon s3, без какой-либо трансформации (ведь вы не знаете что именно из этих данных вам понадобится), кроме вас это делают и другие команды компании, то можно говорить что вы используете озеро данных. Можно сказать что мы определяем схему данных при чтении работая с озером данных и при записи работая с хранилищем данных. Под схемой данных понимается то, что за данные мы хотим получить, откуда, какой объём, когда нам это нужно… Существует опасность накопить неактуальные, ненужные данные в озере, за этим нужно следить, но как преимущество мы получим возможность спускаясь на любую глубину озера получать нужные нам данные заранее не зная (при записи) что нам понадобится.

Автор начинает с описания видов данных (data planes): операционные и аналитические, где первые используются приложениями, а вторые аналитиками. Данные перетекают через ETL в аналитические хранилища которые тоже делятся на хранилища данных и на озера данных, с этого я начал. Статья не о том, какова разница между двумя этими технологическими стеками, а о том, что data mesh может быть применён к обоим подходам. Цель data mesh — создать почву для извлечения данных в любых масштабах. Для достижения этой цели предлагается 4 принципа:

• домен-ориентированная архитектура;
• данные как продукт;
• инфраструктура самообслуживающихся данных как платформа;
• централизованное управление;

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

Domain ownership

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

Data as product

Одна из проблем аналитики данных — разобраться со скоплением данных, ведь те, кто эти данные накапливают могут по-разному понимать цели и по-своему представлять зачем это нужно. Поэтому в обязанности data owner’а входит: понимание для кого эти данные собираются, кто их потребители и каким способом они хотели бы их получать. Все data products должны иметь стандартизированные интерфейсы. Каждый домен включает в себя роль data product developer отвечающую за распространение и обслуживание данных. Data product это узел data mesh содержащий 3 структурных компонента:

Код

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

Данные и метаданные

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

Инфраструктура

Позволяет нам собирать, распространять и запускать весь наш data product.

Прошлая парадигма, когда пайплайны для работы с данными существовали «сами по себе», работали со всеми данными и управлялись отдельно, противопоставляется data mesh когда все компоненты (код, данные и инфра) рассматриваются как единое целое. Эта мысль напомнила мне о том, что совсем недавно появилась профессия DevOps и работа команд изменилась таким образом что сейчас команда сама разрабатывает, деплоит код и обеспечивает инфраструктуру. Можно вспомнить как было раньше, когда разработчики отдавали код в отдел администрирования который по документации сам производить миграции, деплоил код и мониторил продукт, в этом случае команды как бы противостояли друг против друга.

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

Self-serve data platform

Существует множество аспектов при разработке ПО в IT: сборка, подготовка, распространение, мониторинг, управление доступом … и data product добавляется сюда же. Поэтому, чтобы не добавлять сложностей, важно иметь возможность управления данными на высоком уровне абстракции, этот принцип называется Self-serve data infrastructure as a platform to enable domain autonomy, наверное это можно перевести как самообслуживающаяся инфраструктура данных как платформа должна позволять доменам быть автономными. Вообще говоря, все эти принципы, они не про то, что нужно взять и поставить определенные программы и как-то их настроить, а про то, к чему мы должны стремится в построении data mesh. Автор упоминает историю о том, что, например, разработчики деплоят через докер и оркестрируют через кубер, а есть там же аналитики которые используют spart job и всех этих ребят надо «поженить», так вот этот принцип про то, что это должно быть реализовано.

Поговорим о том, что self-serve платформа может обслуживаться разными способами

• Data infrastructure provisioning plane — самый низкоуровневый способ требующий много усилий, поскольку приходится думать о распространении файлов с данными, уровней доступа, учетных записей…
• Data product developer experience plane — этот уровень поддерживает декларативный интерфейс управления жизненным циклом, что повышает уровень абстракции и снижает сложность из-за отсутствия погружения на подлежащий уровень инфраструктуры.
• Data mesh supervision plane — как несложно догадаться, это наиболее высокий уровень абстракции.

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

Federated computational governance

Data mesh следует распределенной архитектуре: набор независимых data products, с независимым жизненным циклом, сборкой, деплоем и независимыми командами. Однако, эта система нуждается в управлении, в существовании единых правил, но федеративно управляемых. Традиционные системы управления достигают своих целей через централизованные решения, причем решения не могут быть подвержены изменениям или неточным толкованиям. Federated governance наоборот поддерживает изменения, эксперименты и различные толкования правил.

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