Оригинал: https://medium.com/alchemesh/alchemesh-data-mesh-framework-the-genesis-aaa9aba2f7bd
Или тут: alchemesh data mesh framework the genesis

Очень ждем эту любопытную балалайку 🔥 и надеемся, что ребята ее выложат в Open Source в скором времени и не сделают её сильно или неудобно платной.

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

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

Однако реализация Data Mesh представляет собой множество вызовов и требует поддержки платформы.

Data Mesh: За пределами технологии

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

1. Владение доменом: Децентрализация владения аналитическими данными к бизнес-доменам, ближайшим к источнику данных или основным потребителям, и независимое управление жизненным циклом данных на основе этих доменов. Этот подход согласовывает бизнес, технологии и данные, обеспечивая масштабируемость, гибкость, точность и устойчивость за счёт сокращения узких мест и обеспечения локализованного управления изменениями.

2. Данные как продукт: Доменно-ориентированные данные делятся как продукт напрямую с пользователями данных, придерживаясь таких характеристик, как обнаруживаемость, адресуемость, понятность, достоверность, нативный доступ, взаимодействие, композиционность, внутренняя ценность и безопасность. Каждый автономный продукт данных предоставляет явные, простые в использовании контракты на обмен данными и управляется независимо, вводя концепцию “кванта данных”, которая инкапсулирует все необходимые компоненты для обмена данными, направленную на предотвращение информационных завалов, развитие культуры, ориентированной на данные, и повышение устойчивости к изменениям.

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

4. Федеративное вычислительное управление: Федеративная модель управления с представителями доменов, членами платформы данных и экспертами для балансировки автономии доменов и глобальной совместимости, полагаясь на автоматическое обеспечение политики. Она направлена на извлечение ценности из совместимых продуктов данных, смягчение рисков децентрализации, интеграцию требований управления и сокращение ручного синхронизационного накладных расходов.

Поддержка перехода к Data Mesh

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

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

Множество вызовов

Когда вы начинаете углубляться в реализацию Data Mesh, вы начинаете понимать, что перед вами стоит множество вызовов, таких как:

• Контракты данных: Они становятся важными для формализации зависимостей между командами и их продуктами. Контракты данных проясняют ожидания и обязанности, обеспечивая эффективную коммуникацию и сотрудничество.

• Полисеми: Эти элементы позволяют различным продуктам данных общаться с использованием общих сущностей, облегчая взаимодействие и согласованность данных в организации.

• Продукты данных: В основе Data Mesh лежат продукты данных, которые должны быть надлежащим образом документированы, поддерживаемы и принадлежать командам. Это включает определение метаданных, стандартов качества и механизмов обновления и версионирования.

Вызовы автономии

Хотя автономия команд важна, она неизбежно приводит к расхождениям в используемых технологиях и принятых лучших практиках. Некоторые могут быть склонны к рецентрализации решений через единую платформу / технический стек (например, проект DBT с экземпляром Airflow). Однако это может просто перенести проблему на уровень платформы. Важно принимать и поддерживать эту автономию, определяя чёткие интерфейсы для продуктов данных и предоставляя платформу, которая способствует этой динамике.

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

Наша видение: Фреймворк для Data Mesh

Учитывая эти идеи и основываясь на моих предыдущих обсуждениях о переходе от современного стека данных к принципам Data Mesh, я решил разработать фреймворк для управления Data Mesh. Цель не в том, чтобы предложить универсальный продукт, а в том, чтобы предоставить гибкий и модульный инструмент. Фреймворк направлен на:

• Стандартизация интерфейсов: Предоставление общей рабочей рамки для доменов данных, продуктов данных, выходных портов, контрактов данных и т.д., тем самым облегчая ассимиляцию и понимание.

• Поддержка команд платформы: Помощь в создании платформ самообслуживания данных через стандартизацию компонентов, оставаясь при этом независимым от реализации.

• Предоставление модульных компонентов: Поставка “конструкторских” компонентов платформы, позволяющих пользователям выбирать, как они хотят переводить ресурсы Data Mesh на платформу.

Этот фреймворк разработан как модульный и адаптируемый, позволяя компаниям использовать его в соответствии с их конкретными потребностями. Будь то стандартизация процессов, поддержка команд или предложение модульных решений, фреймворк направлен на предоставление прочной основы для реализации и управления Data Mesh.

Alchemesh: Слои

Фреймворк Alchemesh будет состоять из трёх слоёв:

1. Alchemesh Console: Отвечает за предоставление интерфейсов (UI, Rest API и т.д.) для управления метаданными Data Mesh:
   • Позволяет пользователям перемещаться по Data Mesh,
   • Позволяет командам платформы переводить всё это в предоставление платформы.
   • Это будет порталом для действий с продуктом данных:
     • Действует как реестр продуктов данных,
     • Интерфейс для разработчиков продуктов данных,
     • Интерфейс для команд платформы для активации платформы самообслуживания данных.

2. Alchemesh Controller: Это будет плоскость управления Data Mesh, которая будет управлять платформой Data Mesh. Она создаёт связь между метаданными Data Mesh, управляемыми консолью, и компонентами платформы в автоматизированном и самообслуживающемся режиме.

3. Alchemesh Platform Components: Набор “конструкторских” компонентов платформы для самообслуживания. Компоненты платформы разделены на несколько категорий:
   • Infrastructure Platform Component: Определяет основу платформы для поддержки Data Mesh (например, проект/аккаунт облачного провайдера, VPC, реестры, кластер Kubernetes и т.д.).
   • Output Port Platform Component: Создаёт компоненты хранения на инфраструктуре для предоставления данных, созданных продуктами данных, обеспечивая взаимодействие и управление доступом.
   • Input Port Platform Component: Создаёт компоненты для потребления данных из операционных систем и делает их доступными для инфраструктуры продуктов данных, позволяя связанному коду форматировать их и создавать ценность продукта данных.
   • Code Platform Component: Создаёт бизнес-логику на инфраструктуре, позволяя использовать входящие данные для получения желаемого результата.

Открытый исходный код

Пока не ясно, какую стратегию мы будем применять в этом проекте в отношении открытого исходного кода, потому что далеко не ясно, куда пойдёт этот проект, это всё ещё сторонний проект, который близок нашим сердцам. Но мы так много обязаны открытому исходному коду, который помог нам расти, и мы счастливы работать с таким количеством разных людей, как мы делали это в NiFiKop, что некоторые из наших работ будут открыты, безусловно!

Модульность

Каждый из этих трёх слоёв может использоваться независимо и частично!

С возможностью замены каждого из решений на пользовательские, в зависимости от того, как каждый будет использоваться:

• Часть консоли может использоваться как слой метаданных для Data Mesh, затем потребляемый и контролируемый через интерфейсы (Rest, GraphQL, Events)
  • командами платформы компании для интеграции с их системами автоматизации (CI/CD, контроллер GitOps, контроллер Kubernetes и т.д.)
  • для создания связи между метаданными сетки и платформой.

• Контроллер должен иметь возможность управлять компонентами платформы, предлагаемыми Alchemesh, а также теми, которые производятся организацией, использующей решение.

• Компоненты платформы не должны быть специализированы для удовлетворения требований Alchemesh или даже просто Data Mesh.
  • Они могут использоваться вне этого фреймворка, как и любой другой модуль. Например, если у меня есть компонент инфраструктуры, который позволяет мне создать кластер GKE через Terraform, он должен быть пригодным для создания кластера GKE в традиционной среде предприятия Terraform без необходимости использования консоли или контроллера, и то же самое касается выходного порта для управления хранилищем и правами доступа на BigQuery.

Заключение

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

Мы все ещё находимся на ранней стадии разработки этого фреймворка на основе нашего понимания Data Mesh. Реализация продукта также даёт нам рамки для развития нашего размышления, начиная с основных концепций (например, доменов данных, продуктов данных, контрактов данных и т.д.) до обогащения их функциями, продвигаемыми Data Mesh для обеспечения его масштабирования (например, вычислительных политик, контуров обратной связи и т.д.). Эта серия статей позволит нам делиться нашими размышлениями и решениями, которые мы принимали параллельно с разработкой!

В следующей статье мы сосредоточимся на архитектуре “северной звезды”, которую мы в настоящее время используем для разработки этого фреймворка, а затем представим вам моделирование ресурсов (продукты данных, технические команды и т.д.), которые у нас есть для нашего MVP!

Чтобы немного заинтриговать наш продукт, вот несколько набросков консоли AlchmeshIo. 😇