Оригинал: https://medium.com/alchemesh/alchemesh-console-the-core-concepts-160511dee3b0
Или тут: alchemesh console the core concepts

Alchemesh core concepts

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

Цель состоит в том, чтобы через эти статьи поделиться нашей интерпретацией Data Mesh, представить наш подход к разработке, получить обратную связь по нашим выборам и, самое главное, попытаться вместе подумать о вызовах, связанных с реализацией Data Mesh.
Консоль Alchemesh: Стандартизация интерфейсов для облегчения ассимиляции и понимания
Как мы уже говорили, одна из целей фреймворка, и особенно консоли, — это предоставить поддержку и структуру, чтобы помочь различным стейкхолдерам понять, взаимодействовать и принять Data Mesh.
Наше решение должно быть средством для передачи концепций Data Mesh! Это для нас серьезный вызов, особенно с таким широким подходом, как у Data Mesh.

Множество концепций вступают в игру: data product, data domain, data contract, полисемия, адресация, достоверность, владение, автономия и т.д.
Возникает множество вопросов: какие взаимодействия между различными концепциями? Какой компонент должен нести какую информацию? И так далее.
В такой ситуации сложно гарантировать, что у всех есть общее минимальное понимание, и минимизировать риск чрезмерной интерпретации или несогласованности среди стейкхолдеров. Кроме того, важно определить четкие и хорошо определенные пространства, чтобы команды могли понять концепции и делать сильные предложения через запросы функций.
Для нас было естественным выбором решить эти вопросы через консоль, стандартизируя определение основных концепций Data Mesh и их взаимодействий, все это переведенное в интерфейс.
Alchemesh: Моделирование основных концепций
⚠️ Версия, которую мы представляем здесь, соответствует тому, что мы определили на этапе проектирования MVP; она, естественно, подлежит изменению по мере разработки и реализации новых функций. ⚠️

Консоль Alchemesh: Моделирование основных концепций

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

• Разработчик data product: Учитывая широкий спектр навыков — от универсальных разработчиков с общими навыками программирования до специализированных инженеров данных.
• Потребители data product: Охватывает множество ролей, у которых есть одно общее, они нуждаются в доступе и использовании данных для выполнения своей работы (например, дата-сайентисты, дата-аналитики, разработчики приложений).
• Владелец data product: Отвечает за доставку и продвижение успешных data product для своих конкретных доменов.
• Разработчик data platform: Отвечает за доставку сервисов платформы как продукта с лучшим пользовательским опытом.
• Владелец data platform: Создает и управляет data platform, а также использует ее. Разработчики data platform, которые работают над сервисами плоскости опыта data product.

Alchemesh: Пользователи

Data domains

Владение данными домена является основой масштабирования в сложной системе, такой как современные предприятия. Стратегическое проектирование в DDD (Domain Driven Design) принимает моделирование на основе нескольких моделей, каждая из которых контекстуализирована для конкретного домена, называемого
bounded context.

• Bounded context — это “ограниченная применимость конкретной модели [которая] дает членам команды четкое и общее понимание того, что должно быть согласовано, а что может развиваться независимо”.
  Мы поддерживаем 3 типа data domains:
  Source aligned domain: Аналитические данные, отражающие бизнес-факты, генерируемые операционными системами, ответственными за предоставление правды своих бизнес-доменов как данных source-aligned domain.

• Aggragated domain: Аналитические данные, являющиеся агрегатом нескольких upstream domains.

• Consumer aligned domain: Аналитические данные, трансформированные для удовлетворения потребностей одного или нескольких конкретных use cases. Это также называется fit-for-purpose domain data.

Помимо уточнения роли домена в отношении data product, которые он производит, это также позволит федеративному data governance определить вычислительные политики для надлежащего управления сеткой (например, установление правила, что data product из source-aligned domain, не опирающиеся на какую-либо систему источника, теряют ценность) или помочь в определении приоритетов реорганизации доменов.

Вид data domain

Технические команды
В зависимости от размера определенных data domains, организация может решить определить несколько кросс-функциональных команд для управления наборами data product. Чтобы удовлетворить эту потребность, мы решили ввести концепцию технической команды, объединяющей людей, вносящих вклад в один и тот же scope в рамках домена.
Мы различаем несколько видов команд:

• Data product team: Stream aligned team, отвечает за полноценную доставку сервисов (инжекция, потребление, обнаружение и т.д.), требуемых data product.
• Platform team: Ее цель — обеспечить возможность stream-aligned доставлять свою работу с существенной автономностью.
• Governance group: Enabling team, ее ключевая роль — облегчить принятие решений вокруг глобальных политик. Эти политики затем реализуются вычислительно и принимаются командами data product.

Технические команды

Система источника
В случае source-aligned data domains, операционный и аналитический миры объединены в одном домене, и это отражено в кросс-функциональных командах. Важно, чтобы консоль материализовала эту связь.
Намерение явно не в том, чтобы управлять операционными задачами в рамках платформы data mesh, но важно материализовать эту связь, чтобы преодолеть разрыв между двумя мирами, не ограничиваясь организационно.

Data product
С владельцем домена (поддерживаемым технической командой), данные, ориентированные на домен, делятся как продукт напрямую с пользователями данных.
Data as a product вводит новую единицу логической архитектуры, называемую data quantum, контролирующую и инкапсулирующую все структурные компоненты, необходимые для обмена данными как продуктом.
Приняв продуктовый подход, мы будем сообщать о состоянии нашего предложения:

• Lifecycle state: На каком этапе жизненного цикла находится data product — находится ли он в разработке, в обнаружении, стабилен или находится в процессе вывода из эксплуатации.
• Maturity level: Продукт, считающийся стабильным, но с небольшим историческим использованием, не имеет такого же уровня зрелости, как стабильный data product, который использовался многими потребителями в течение нескольких лет.

Входные порты
В контексте source-aligned data product, данные будут нуждаться в потреблении из операционной системы, чтобы сделать их доступными как входные данные для внутреннего обработчика data product. Эта интеграция будет выполнена через входной порт (платформенный компонент, предназначенный для этой интеграции, предоставленный платформой или реализованный командами домена).
Чтобы дать конкретный пример, предположим, что операционные данные доступны в топике Kafka и должны быть доступны на проекте GCP. Входной порт может включать предоставление бакета GCS и NiFi dataflow, который потребляет данные из топика Kafka.
Семантическая модель
Описываем семантические модели, которые data product будет предлагать.
Определение модели, читаемое машинами и людьми, которое захватывает модель домена данных: как data product моделирует домен, какие типы сущностей включает данные, свойства сущностей и т.д.
Выходные порты
Эти модели будут представлены как активы через выходной порт. Проще говоря, выходной порт — это пара, состоящая из системы хранения (объектное хранилище, колоночная таблица, топик потоковой передачи и т.д.) и прокси, который позволяет получить доступ через различные протоколы и языки (SQL, REST API, GraphQL и т.д.).
Одно из наших позиций по этому вопросу заключается в том, что выходной порт не обязательно будет представлять все модели, управляемые data product.
Код
Это основная работа разработчика data product, который часто слишком отдален от данных, которые он производит в устаревших инструментах и архитектурах данных. Data mesh ставит код, который создает ценность data product, в центр, и это естественно то, что мы делаем. Эта логика позволяет начать с входных данных для генерации выходных активов.
В data product ответственность за правильное определение data product, потребление и представление данных через стандартные порты, а также поддержание связанных метаданных лежит на разработчиках data product.
В свою очередь, все, что происходит внутри (код), полностью оставлено на усмотрение команды: Dagster Blog job, Airflow DAG, Kestra DAG, простой Python job в Lambda… Выбор и ответственность лежат на владельце (это то, что мы называем автономией).

Инфраструктура
Data product может зависеть от инфраструктуры, которая должна быть предоставлена для выполнения его обработки, такой как объектное хранилище, промежуточный набор данных и т.д., которые не связаны с тем, как выполняется код, данные потребляются или данные представляются. Этот интерфейс позволяет указать платформе, что data product нуждается в этом.
Метаданные

Актив
Мы считаем активом инстанцирование модели data product через выходной порт.
После того как data product развернут и функционирует, код должен поддерживать определенную информацию о состоянии, чтобы информировать своих потребителей о его состоянии:

• Общее состояние: операционное, в инциденте, выключено
• Состояние активов: их техническое качество данных (точность, полнота, своевременность, достоверность) и их свежесть.

Data product

Data contract
У нас есть data product в нашем data domain, принадлежащий технической команде, с данными, потребляемыми из операционной системы через входной порт и представляющими ценность data product, сгенерированную кодом, через выходные порты. Отлично!
Но прежде чем потреблять этот data product, я, как потребитель, хочу знать, на что я соглашаюсь, и как производитель, кто соглашается потреблять от меня! Вот где вступают в игру data contracts.
Выходной порт
Data contract применяется к выходному порту data product, а не ко всему data product. Есть несколько причин для этого:

• Ожидания различаются между потоком потоковой передачи и объектом, хранящимся в data lake (в терминах времени отклика, частоты обновления, точности и т.д.).
• Не все выходные порты несут одни и те же модели, поэтому обязательство к потреблению не одно и то же.

Тип доступа
В зависимости от природы data product, доступ к нему не будет разрешен одинаково. Мы поддерживаем три типа:

• Ограниченный доступ: Это означает, что владелец data product должен рассмотреть и одобрить любые запросы на доступ.
• Внутренний доступ: Это означает, что все запросы из одного и того же домена автоматически одобряются; в противном случае они требуют одобрения владельца.
• Публичный доступ: Это означает, что все запросы автоматически одобряются без рассмотрения или одобрения владельца.

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

• Время безотказной работы
• Частота обновлений
• Время отклика

Условия
Это также обязательство по тому, как будет потребляться продукт данных с точки зрения:

• Использования
• Выставления счетов
• Период уведомления для адаптации потребления

Тест качества данных

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

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

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

• SLA
• Использование
• Выставление счетов
• Результаты тестов качества данных

Контракт данных

Запрос на доступ к контракту данных
Контракт данных готов; теперь пришло время запросить доступ, чтобы подписаться на него! Это роль запроса на доступ, который будет включать:

• Кто хочет потреблять?: Продукт данных, Техническая команда, Одиночный пользователь или Домен данных
• В чем цель?

Запрос на доступ

Компоненты платформы
Я не буду вдаваться в подробности этой части, не потому что она неинтересна, а потому что, по моему мнению, она заслуживает отдельной статьи.
Важно то, что мы хотим использовать эти ресурсы для предоставления интерфейсов между разработчиками продуктов данных и командами платформы (Data Product Experience Plane и Infrastructure Utils Plane) для поддержки предоставления платформы самообслуживания, обеспечивая автономию разработчиков, предлагая децентрализацию через компоненты платформы, реализованные и предоставленные платформой (наши знаменитые LEGO).

Заключение
Вот и все — мы рассмотрели основные концепции, которые консоль будет поддерживать, чтобы позволить командам реализовать свою data mesh. Давайте не забудем одно: мы все еще на самом начальном этапе разработки, стремясь к MVP с базовыми концепциями, чтобы начать вводить data mesh! Многие концепции, необходимые для масштабирования data mesh и в долгосрочной перспективе, такие как полисемии, петли обратной связи, вычислительные политики и т.д., все еще отсутствуют. Мы доберемся до этого!
Концепции на месте; следующим шагом является северная звезда архитектуры Alchemesh!