Ничего так магазинчик https://atmosfera.store/ крафтовые штуки, есть интересные, но хочется больше конечно. Электроники например.

Оригинал: https://medium.com/alchemesh/alchemesh-console-the-core-concepts-160511dee3b0
Или тут: alchemesh console the 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; она, естественно, подлежит изменению по мере разработки и реализации новых функций. ⚠️

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

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

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 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 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!

Оригинал: 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. 😇

Оригинал: https://www.sitra.fi/en/publications/technology-landscape-of-data-spaces/#foreword
Или тут: sitra technology landscape of data spaces

Предисловие
Резюме
1. Пространства данных как развивающаяся технологическая область
1.1. Основные концепции для понимания пространств данных
1.2. Изучение развивающегося технологического ландшафта
2. Снимок технологий пространств данных
2.1 Существующие инструменты и решения (не специфичные для пространств данных)
2.2 Инициативы по технологиям пространств данных
2.3 Коммерческие предложения, ориентированные на пространства данных
2.4 Опыт пользователя и доверие
3. Рекомендации для создателей пространств данных
3.1 Рекомендация: Поддержка участников с несколькими ролями в пространствах данных
3.2 Рекомендация: Тестирование бизнес-кейсов на основе существующих зрелых решений
3.3 Рекомендация: Мониторинг рынка и предоставление обратной связи
3.4 Рекомендация: Обратите внимание на опыт пользователя
Глоссарий
Литература
Приложение 1. Организации, изображенные на диаграмме ландшафта
Приложение 2. Оценка ключевых инициатив по технологиям пространств данных

Предисловие

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

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

Европейская стратегия данных предполагает, что наша экономика данных скоро получит импульс от обмена данными между всеми заинтересованными компаниями и организациями с использованием нового подхода к обмену данными, называемого “пространства данных”. Что такое пространства данных и какие бизнес- и проблемы обмена данными они решают? Как будет работать управление потоками данных в этих новых средах? Если вы хотите построить пространство данных, как вы к этому приступите? Это лишь некоторые из вопросов, которые мы хотим понять в Sitra. Как финский инновационный фонд, наша цель — обеспечить конкурентоспособность финских компаний в европейской экономике данных. Мы с радостью делимся нашим опытом с остальной Европой и за ее пределами.

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

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

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

Ансси Комулайнен
Директор проекта, Gaia-X Финляндия, Sitra

Резюме

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

Обмен и объединение данных между организациями является предварительным условием для таких бесшовных сервисов. Надежная передача данных между различными организациями требует так называемой “мягкой инфраструктуры”, то есть новых типов технических, административных и бизнес-решений. Пространство данных — это мягкая инфраструктура, которая обеспечивает надежный и легкий обмен данными через границы организаций.

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

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

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

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

1. Пространства данных как развивающаяся технологическая область

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

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

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

1.1. Основные концепции для понимания пространств данных

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

Эта рабочая статья использует термины и определения из глоссария Центра поддержки пространств данных (DSSC). Sitra является партнером DSSC, проекта, финансируемого Европейским союзом.

Глоссарий DSSC определяет пространства данных следующим образом:

“Распределенная система, определяемая управленческим фреймворком, которая обеспечивает безопасные и доверенные транзакции данных между участниками, поддерживая доверие и суверенитет данных. Пространство данных реализуется одной или несколькими инфраструктурами и обеспечивает один или несколько кейсов использования.”

Кейс использования пространства данных — это потенциальный сценарий использования, создающий ценность для данных, предоставляемых через пространство данных. Кейсы использования создают спрос на инфраструктуру пространства данных, которая поддерживает эффективную реализацию этих кейсов использования. Пространство данных — это общая инфраструктура для одного или нескольких кейсов использования. Они могут ускорить разработку кейсов использования в данной области (например, логистика, туризм, навыки), потому что кейсы использования часто требуют одних и тех же источников данных. Если данные, необходимые для одного кейса использования, продуцируются (вместо того, чтобы быть адаптированными к одному кейсу использования), данные-продукты могут быть использованы непосредственно в последующих кейсах использования. Готовые данные-продукты также облегчают идентификацию новых кейсов использования и разработку инноваций.

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

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

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

КЕЙС
Maritime Data Space Finland

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

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

1.2. Изучение развивающегося технологического ландшафта

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

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

Мы интервьюировали экспертов из трех организаций, участвующих в разработке пространств данных: Mtech Digital Solutions Oy, которая является поставщиком решений для финской продовольственной цепочки поставок, Agdatahub, французского сельскохозяйственного пространства данных, и Fit Our Future, голландской консалтинговой компании по устойчивости энергетики. Мы также интервьюировали три компании, имеющие коммерческие предложения, ориентированные на пространства данных: Dataspace Europe, Nexyo Io и Sovity. Проекты по созданию пространств данных, финансируемые ЕС, не были включены в интервью.

2. Снимок технологий пространств данных

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

Хотя отдельные стандарты и технологии, связанные с пространствами данных, развиваются быстро, общая структура ландшафта более статична.

На изображении ландшафта ниже показаны три основных направления, которые могут рассмотреть люди, принимающие решения о технологиях для инициатив по созданию пространств данных:

• Существующие инструменты и решения (не специфичные для пространств данных),
• Инициативы по технологиям пространств данных,
• Коммерческие предложения, ориентированные на пространства данных.

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

Рисунок 1. Технологический ландшафт пространств данных состоит из трех направлений.

2.1 Существующие инструменты и решения (не специфичные для пространств данных)

Итерационное тестирование бизнес-кейсов в области развивающихся технологий, таких как пространства данных, проще, чем поиск рабочего бизнес-кейса от начала до конца. Большинство инноваций в пространствах данных связаны с юридическими, сервисными и бизнес-дизайном. Эти инновации часто, если не всегда, можно протестировать с использованием стандартных и существующих технологий, таких как управление идентификацией и доступом клиентов (CIAM), CRM, хранилище данных, управление API, каталоги данных и сервисов и т.д.

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

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

Data products, data space и data mesh

Data meshes набирают популярность в архитектуре данных предприятий. Data meshes и data spaces имеют много общего – data meshes фокусируются на управлении данными внутри организаций, а data spaces – на управлении данными через границы организаций. Одно из фундаментальных принципов data meshes – восприятие данных как продукта.

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

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

Data mesh – это современный подход к созданию распределенной архитектуры данных для предприятий. Он имеет четыре принципа: владение доменом, данные как продукт, самообслуживающаяся платформа данных и федеративное (и вычислительное) управление. Zhamak Dehghani ввела термин data mesh в 2019 году. Она заимствовала идеи из предметно-ориентированного проектирования и строится на программных парадигмах, которые поощряют гибкие, функциональные команды с автономией и ответственностью. Data mesh – это пример внутрикомпании, как экосистема пространства данных может работать.

Data mesh и data space могут слиться, чтобы создать более целостную парадигму управления данными, которая строится на основе data products и охватывает внутренний и внешний обмен и использование данных. Возможности управления данными, авторизации и подключения пространств данных дополняют возможности data mesh. Идея о мышлении о рынке данных, который охватывает внутреннее использование, переходя через границы организаций, может стать значительным драйвером для обмена данными и принятия пространств данных.

Также возможно сравнить пространства данных и meshes для прогнозирования развития рынка в этих областях. Хотя data mesh новый и его практическая реализация все еще растет, в отрасли много ажиотажа вокруг него. Многие ИТ-фирмы поддерживают его, продвигая свои возможности data mesh, а консалтинговые компании продвигают, как они могут помочь компаниям в их путешествии по трансформации data mesh. В пространствах данных коммерческое предложение только начинает появляться. Внутренний обмен данными в бизнесе стимулирует спрос на решения data mesh. По мере того как компании созревают в своих внутренних возможностях работы с данными, следующим шагом будет фокусировка на обмене данными между организациями. Это создаст спрос на пространства данных в сочетании с data meshes.

2.2 Инициативы по технологиям пространств данных

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

Несколько игроков в области технологий пространств данных работают над стандартами, специфичными для пространств данных, и общими технологическими фреймворками. Когда начинаешь изучать пространства данных, эти имена быстро всплывают: International Data Spaces Association (IDSA), Gaia-X, iSHARE, Eclipse Cross Federation Services Components (XFSC), Gaia-X Web3 Ecosystem (Pontus-X), Eclipse Dataspace Components (EDC) и FIWARE. Знание этих инициатив по технологиям пространств данных дает хорошую основу для оценки других. Чтобы дать создателям пространств данных отправной точку для их исследований, мы сделали первоначальные усилия по оценке зрелости, принятия и потенциала некоторых ключевых инициатив по технологиям пространств данных (Приложение 2).

Эти инициативы не являются напрямую сопоставимыми альтернативами друг другу. Они вносят вклад в технологический ландшафт пространств данных на разных уровнях, от архитектур ссылок до фреймворков доверия и компонентов с открытым исходным кодом. IDSA определяет архитектуру ссылок (IDS Reference Architecture Model), части которой реализованы EDC, FIWARE и другими поставщиками соединителей IDS (отчет IDSA о соединителях). Gaia-X также определяет архитектуру ссылок (Gaia-X Architecture model), с которой согласованы GXFS-DE, Pontus-X, а в некоторой степени EDC и iSHARE. Вместе они образуют сеть переплетенных и совместно развивающихся инициатив, которые продвигают технологии пространств данных.

Техническая конвергенция относится к интеграции ранее отдельных технологий, функциональностей или стандартов, что приводит к созданию целостного фреймворка. Техническая конвергенция происходит в рамках инициатив по технологиям пространств данных. Коллективный форум, Data Spaces Business Alliance (DSBA), работает над общим технологическим фреймворком ссылок на основе технической конвергенции существующих архитектур и моделей от Gaia-X, IDSA и FIWARE. Это сотрудничество направлено на достижение взаимодействия и переносимости решений между пространствами данных путем гармонизации технологических компонентов и других элементов. В более широком контексте, проект, финансируемый ЕС, Data Spaces Support Centre (DSSC), также внесет свой вклад в техническую конвергенцию, анализируя и рекомендуя существующие технологии и предоставляя руководство создателям пространств данных через общую схему.

Ключевым выводом из интервью является положительная корреляция между опытом разработчика и принятием фреймворка или технологии. Инструмент или технология с хорошим веб-сайтом разработчика, релевантными компонентами с открытым исходным кодом и активными каналами обратной связи будут иметь больше шансов на успех на рынке, чем решения, которые не обладают ни одним из этих аспектов. С точки зрения опыта разработчика, некоторые инициативы по технологиям пространств данных продвинулись дальше, чем другие, но ни одна из них еще не выделяется. Например, документация может быть технически доступна, но удобство использования не на уровне, который мог бы стимулировать принятие разработчиками. Документация должна быть более доступной для разработчиков и сопровождаться конкретными примерами использования сервисов и концепций. Одним из заметных способов поддержки принятия является сеть национальных хабов, которые имеют Gaia-X, IDSA и FIWARE.

2.3 Коммерческие предложения, ориентированные на пространства данных

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

Упомянутые ранее архитектуры ссылок (IDS и Gaia-X) продолжают развиваться, создавая трудности для разработчиков. Реализации могут быть лучше согласованы с более старыми версиями архитектур ссылок. С другой стороны, реализации также продвигают архитектуры вперед. Создатели пространств данных должны иметь надлежащее планирование версий. Коммерческие предложения, ориентированные на пространства данных, могут оказать ценную поддержку в работе с развивающимися версиями архитектур и программного обеспечения.

В настоящее время небольшое, но стабильно растущее количество компаний фокусируется в основном на пространствах данных или запускает продукты и услуги, специфичные для пространств данных, как часть более широкого портфолио. Несколько игроков предлагают форму решения “пространство данных как услуга”, которая позволяет настроить полноценное пространство данных с меньшими техническими препятствиями. В рамках этого исследования мы связались со следующими коммерческими поставщиками пространств данных: Advaneo, Dataspace Europe, deltaDAO, IONOS, nexyo, OKP4, sovity и TrustRelay (Приложение 1).

2.4 Опыт пользователя и доверие

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

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

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

Это создает двойную проблему для пользователей:

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

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

3. Рекомендации для создателей пространств данных

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

3.1 Рекомендация: Поддержка участников с несколькими ролями в пространствах данных

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

3.2 Рекомендация: Тестирование бизнес-кейсов на основе существующих зрелых решений

Бизнес-кейс для пространства данных должен быть протестирован с использованием существующих инструментов и решений, где это возможно, и новые инструменты, специфичные для пространств данных, должны быть приняты только в том случае, если существующие варианты недостаточны. Большинство инноваций в пространствах данных связаны с юридическими, сервисными и бизнес-дизайном. Их часто можно протестировать с использованием существующих технологий, таких как управление идентификацией и доступом клиентов (CIAM), CRM, хранилище данных, управление API, каталоги данных и сервисов и т.д.

3.3 Рекомендация: Мониторинг рынка и предоставление обратной связи

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

3.4 Рекомендация: Обратите внимание на опыт пользователя

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

Глоссарий

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

Инициатива по созданию пространства данных — это совместный проект консорциума или сети ответственных партнеров по инициированию, разработке и поддержанию пространства данных.

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

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

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

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

Владелец прав на данные (роль) — это сторона, которая имеет (юридические) права и/или обязательства использовать, предоставлять доступ к или делиться определенными персональными или неперсональными данными. Владельцы прав на данные могут передавать такие права другим.

Поставщик данных (роль) — это участник транзакции, который в контексте конкретной транзакции данных технически предоставляет данные получателям данных, которые имеют право или обязанность получить доступ к и/или получить эти данные.

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

Пользователь данных (роль) — это физическое или юридическое лицо, которое имеет законный доступ к определенным персональным или неперсональным данным и имеет право, включая право в соответствии с Регламентом (ЕС) 2016/679 в случае персональных данных, использовать эти данные для коммерческих или некоммерческих целей (DGA Art.2)

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

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

Data product — это стандартизированная единица данных, упаковывающая соответствующие ресурсы и услуги данных в потребляемую форму, соответствующую спецификациям data product.

Источник: Глоссарий Центра поддержки пространств данных (DSSC) 2.0

Литература

BDVA. 2019. Towards a European Data Sharing Space. (доступно 26 июня 2023).

Curry E., Scerri S., Tuikka T. 2022. Data Spaces: Design, Deployment, and Future Directions

DSSC. 2023. Starter Kit for Data Space Designers. Data Spaces Support Centre (DSSC). (доступно 2 июля 2023).

DSSC. 2023. Data Spaces Blueprint Version 0.5. Data Spaces Support Centre (DSSC). (доступно 26 октября 2023).

DSSC. 2023. Glossary 2.0. Data Spaces Support Centre (DSSC). (доступно 26 октября 2023).

EC. 2022. Staff working document on data spaces. Европейская комиссия. (доступно 26 июня 2023).

EHDS. 2022. European Health Data Space (веб-сайт). Европейская комиссия. (доступно 26 июня 2023).

Nagel L., Lycklama D. 2021. Design Principles for Data Spaces. Position Paper. Version 1.0. (доступно 26 июня 2023).

Otto B., Hompel M., Wrobel S. 2022. Designing Data Spaces: The Ecosystem Approach to Competitive Advantage

Pitkänen O, Luoma-Kyyny J. 2022. Rulebook for a fair data economy. Sitra.

Steinbuss, S. et al. 2023. Data Spaces Landscape – Overview and relations of data spaces initiatives, standards, and tools (1.0). International Data Spaces Association. (доступно 26 июня 2023).

Приложение 1. Организации, изображенные на диаграмме ландшафта

Инициативы по технологиям пространств данных

Data Spaces Support Centre (DSSC) — это проект, финансируемый Европейской комиссией в рамках программы Digital Europe. DSSC исследует потребности инициатив по пространствам данных, определяет общие требования и устанавливает лучшие практики для ускорения формирования суверенных пространств данных как важного элемента цифровой трансформации во всех областях.

International Data Spaces Association (IDSA) предоставляет архитектуру ссылок, которая обеспечивает экосистему для суверенного обмена данными с четко определенными правами использования.

Gaia-X стремится создать экосистему пространств данных, где данные делятся в надежной среде, чтобы пользователи сохраняли контроль и суверенитет над данными. Он разрабатывает технический фреймворк Gaia-X, схему соответствия и реализации с открытым исходным кодом. См. документацию и репозитории.

iSHARE — это европейская сеть доверия для международного и суверенного обмена бизнес-данными, управляемая Фондом iSHARE. Фреймворк доверия iSHARE обеспечивает федеративное управление доверием пространств данных. Он предоставляет компоненты пространств данных в соответствии с принципами проектирования пространств данных из проекта Open DEI, Международной ассоциации пространств данных и Gaia-X. См. документацию и репозитории.

Eclipse Cross Federation Services Components (XFSC) — это проект с открытым исходным кодом, разрабатывающий базовые компоненты, необходимые для создания федеративных систем обмена данными. До перехода в Фонд Eclipse проект был известен как Gaia-X Federation Services (GXFS). См. документацию и репозитории.

Pontus-X, экосистема Gaia-X Web3, под управлением институтов-членов Gaia-X, стремится обеспечить децентрализованный и федеративный подход к управлению данными, позволяя безопасно создавать, собирать, делиться и монетизировать данные, программное обеспечение, инфраструктуру и услуги федерации. См. документацию Gen-X, Ocean protocol и Polygon, а также репозитории deltaDAO, Ocean protocol и Polygon.

Eclipse Dataspace Components (EDC) — это проект с открытым исходным кодом, целью которого является реализация стандарта International Data Spaces (IDS) и соответствующих протоколов и требований, связанных с Gaia-X, тем самым обеспечивая реализацию и обратную связь для этих инициатив. См. документацию и репозитории.

FIWARE — это технология с открытым исходным кодом, используемая для разработки интеллектуальных решений, цифровых двойников и пространств данных в нескольких областях цифровой трансформации. См. документацию, репозитории и маркетплейс.

Коммерческие предложения, ориентированные на пространства данных

Advaneo предлагает комплексное решение для участия в пространствах данных. Компании могут легко использовать их компоненты для создания инновационных бизнес-моделей и продуктов. Их Data Marketplace содержит около 2,5 миллионов наборов данных, рабочую станцию AI и решение для хакатона для открытой инновации. Их Trusted Data Hub позволяет использовать конфиденциальные данные без раскрытия необработанных данных. Data Catalog, Data Marketplace и Trusted Data Hub предоставляют инфраструктуру для суверенного обмена данными через строительные блоки решения пространств данных.

Dataspace Europe предоставляет услугу посредничества Tritom для обеспечения совместного использования данных и улучшения операционных возможностей игроков индустрии.

deltaDAO создала экосистему Gaia-X Web3 “Pontus-X” на основе Ocean Protocol и распределенной технологии блокчейн в 2021 году. deltaDAO обеспечила первый уровень мгновенной ликвидности для потребления данных, программного обеспечения и инфраструктурных услуг в Gaia-X с использованием евро. deltaDAO была первой, кто интегрировал фреймворк доверия Gaia-X.

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

nexyo DataHub соединяет децентрализованные источники данных через соединители EDC и предлагает дополнительные услуги, которые позволяют нетехническим пользователям быть частью развивающихся экосистем данных или создавать экосистемы самостоятельно. Цель состоит в том, чтобы обеспечить межкорпоративную и межотраслевую инновацию для бизнес-моделей, основанных на данных, сохраняя при этом автономию и суверенитет данных.

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

sovity предоставляет компаниям доступ к суверенитету данных, позволяя им создавать новые бизнес-модели, основанные на данных, и разрабатывать инновационные продукты на основе технологий пространств данных. С помощью своего комплексного и удобного в использовании программного обеспечения, Connector-as-a-Service клиенты могут легко участвовать в экосистемах данных, делясь данными и сохраняя полный контроль.

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

Приложение 2. Оценка ключевых инициатив по технологиям пространств данных

Поскольку концепция пространства данных все еще развивается, оценка состояния технологий пространств данных представляет собой сложную задачу во многих аспектах. Несмотря на известные трудности, мы предприняли первую попытку оценить зрелость, принятие и потенциал некоторых ключевых инициатив по технологиям пространств данных: International Data Spaces Association (IDSA), iSHARE, Eclipse Cross Federation Services Components (XFSC), Gaia-X Web3 Ecosystem (Pontus-X), Eclipse Dataspace Components (EDC) и FIWARE. Согласно интервью, это наиболее актуальные сегодня инициативы по технологиям пространств данных, о которых должен знать каждый создатель пространства данных.

Текущая оценка не является сравнением выбранных инициатив. Как описано ранее (Глава 2), эти инициативы не являются взаимозаменяемыми альтернативами друг другу, поскольку они предоставляют активы, которые полезны для создателей пространств данных, но на очень разных уровнях: архитектуры ссылок (IDSA), фреймворки доверия (iSHARE), фреймворки с открытым исходным кодом (XSFC, Pontus-X, EDC, FIWARE). Каждая инициатива отличается и оценивается на своих собственных достоинствах. Эта предварительная оценка дает создателям пространств данных отправной точку для собственных исследований.

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

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

Таблица 1. Рейтинги для оцениваемых инициатив по технологиям пространств данных.

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

Шкала и рейтинги для зрелости, принятия и текущего потенциала.

Детали публикации

Название
Технологический ландшафт пространств данных

Авторы
Антти Поикола (Sitra), П. Дж. Ласзковвич, Вилле Таканаен и Теему Тойвонен (Futurice)

Место публикации
Хельсинки

Год публикации
2023

Издатель
Sitra

Прогноз
23

ISBN (PDF)
978-952-347-327-0

ISSN (PDF)
2737-1042

Серия
Рабочий документ

Хорошая статья очерк: https://habr.com/ru/articles/846296/

Хотя конечно хочется чуть менее пыльного сравнения, например добавить всякие новинки типа DataOps и тп.

Я тут помучал немного ии и вот что он дал:

Дата-концепции и нарративы: описание, плюсы, минусы, применение, период популярности

1. Data Warehouse (DWH)

* Описание: Централизованная база данных, оптимизированная для аналитических запросов. Данные в DWH структурированы и нормализованы для эффективного хранения и быстрого доступа.
* Плюсы:

• Структурированность и нормализация данных
• Высокая производительность запросов
• Поддержка сложных аналитических задач
• Зрелая экосистема инструментов и технологий
  * Минусы:
• Высокая стоимость владения
• Сложность масштабирования
• Задержки при интеграции новых источников данных
• Ограниченная поддержка неструктурированных данных
  * Применение: Корпоративный анализ, отчетность, бизнес-аналитика.
  * Период популярности: 1990-е – 2010-е годы.

2. Data Lake

* Описание: Хранилище больших объемов данных в исходном формате, включая структурированные, неструктурированные и полуструктурированные данные.
* Плюсы:

• Гибкость и масштабируемость
• Низкая стоимость хранения
• Поддержка разнообразных форматов данных
• Возможность экспериментировать с данными
  * Минусы:
• Отсутствие структуры и нормализации
• Сложность управления и обеспечения качества данных
• Риск создания “болота данных” (data swamp)
• Сложность аналитики на “сырых” данных
  * Применение: Хранение данных, машинное обучение, исследовательский анализ.
  * Период популярности: 2010-е годы – настоящее время.

3. Lakehouse

* Описание: Гибридная архитектура, сочетающая в себе черты Data Lake и Data Warehouse. Lakehouse использует хранилище Data Lake для хранения данных и добавляет к нему метаданные, управление транзакциями и другие возможности DWH.
* Плюсы:

• Сочетание гибкости и масштабируемости Data Lake с производительностью и структурированностью DWH
• Поддержка разнообразных форматов данных
• Улучшенное управление и качество данных
• Возможность использования одного хранилища для разных задач
  * Минусы:
• Относительно новая концепция, не все решения полностью зрелы
• Сложность интеграции с существующими системами
• Потенциально более высокая стоимость владения по сравнению с Data Lake
  * Применение: Аналитика, машинное обучение, хранение данных.
  * Период популярности: 2020-е годы – настоящее время.

4. Data as a Code (DaaC)

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

• Улучшенная воспроизводимость и отслеживаемость данных
• Автоматизация рутинных задач
• Упрощение совместной работы над данными
• Использование знакомых инструментов разработчиков
  * Минусы:
• Сложность внедрения в существующие процессы
• Необходимость обучения сотрудников новым инструментам и практикам
• Потенциальное увеличение сложности инфраструктуры
  * Применение: Data Engineering, Data Science, машинное обучение.
  * Период популярности: 2010-е годы – настоящее время.

5. Data Mesh

* Описание: Архитектурный подход, основанный на децентрализации ответственности за данные. В Data Mesh данные рассматриваются как продукты, которыми владеют и управляют автономные команды.
* Плюсы:

• Улучшенная масштабируемость и гибкость
• Более тесная связь между данными и бизнесом
• Улучшенное качество данных за счет ответственности владельцев данных
• Возможность использования разнообразных технологий
  * Минусы:
• Сложность внедрения и управления
• Риск дублирования данных и несогласованности
• Необходимость изменения культуры и процессов организации
  * Применение: Крупные организации с большим объемом данных и сложной бизнес-структурой.
  * Период популярности: 2020-е годы – настоящее время.

Другие нарративы и концепции:

* DataOps: Практики и инструменты для улучшения совместной работы между командами Data Engineering, Data Science и бизнесом.
* MLOps: Практики и инструменты для улучшения разработки, развертывания и эксплуатации моделей машинного обучения.
* Data Governance: Набор политик, процедур и инструментов для управления качеством, безопасностью и использованием данных.
* Data Lineage: Отслеживание происхождения данных, их преобразований и использования.
* Data Catalog: Инструмент для обнаружения, понимания и управления метаданными.

Заключение:

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

Второй заход

Дата-концепции и нарративы: описание, плюсы, минусы, применение, период популярности

1. Data Warehouse (DWH)

* Описание: Централизованная база данных, оптимизированная для аналитических запросов. Данные в DWH структурированы и нормализованы для эффективного хранения и быстрого доступа.
* Плюсы:

• Структурированность и нормализация данных
• Высокая производительность запросов
• Поддержка сложных аналитических задач
• Зрелая экосистема инструментов и технологий
  * Минусы:
• Высокая стоимость владения
• Сложность масштабирования
• Задержки при интеграции новых источников данных
• Ограниченная поддержка неструктурированных данных
  * Применение: Корпоративный анализ, отчетность, бизнес-аналитика.
  * Период популярности: 1990-е – 2010-е годы.

2. Data Lake

* Описание: Хранилище больших объемов данных в исходном формате, включая структурированные, неструктурированные и полуструктурированные данные.
* Плюсы:

• Гибкость и масштабируемость
• Низкая стоимость хранения
• Поддержка разнообразных форматов данных
• Возможность экспериментировать с данными
  * Минусы:
• Отсутствие структуры и нормализации
• Сложность управления и обеспечения качества данных
• Риск создания “болота данных” (data swamp)
• Сложность аналитики на “сырых” данных
  * Применение: Хранение данных, машинное обучение, исследовательский анализ.
  * Период популярности: 2010-е годы – настоящее время.

3. Lakehouse

* Описание: Гибридная архитектура, сочетающая в себе черты Data Lake и Data Warehouse. Lakehouse использует хранилище Data Lake для хранения данных и добавляет к нему метаданные, управление транзакциями и другие возможности DWH.
* Плюсы:

• Сочетание гибкости и масштабируемости Data Lake с производительностью и структурированностью DWH
• Поддержка разнообразных форматов данных
• Улучшенное управление и качество данных
• Возможность использования одного хранилища для разных задач
  * Минусы:
• Относительно новая концепция, не все решения полностью зрелы
• Сложность интеграции с существующими системами
• Потенциально более высокая стоимость владения по сравнению с Data Lake
  * Применение: Аналитика, машинное обучение, хранение данных.
  * Период популярности: 2020-е годы – настоящее время.

4. Data as a Code (DaaC)

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

• Улучшенная воспроизводимость и отслеживаемость данных
• Автоматизация рутинных задач
• Упрощение совместной работы над данными
• Использование знакомых инструментов разработчиков
  * Минусы:
• Сложность внедрения в существующие процессы
• Необходимость обучения сотрудников новым инструментам и практикам
• Потенциальное увеличение сложности инфраструктуры
  * Применение: Data Engineering, Data Science, машинное обучение.
  * Период популярности: 2010-е годы – настоящее время.

5. Data Mesh

* Описание: Архитектурный подход, основанный на децентрализации ответственности за данные. В Data Mesh данные рассматриваются как продукты, которыми владеют и управляют автономные команды.
* Плюсы:

• Улучшенная масштабируемость и гибкость
• Более тесная связь между данными и бизнесом
• Улучшенное качество данных за счет ответственности владельцев данных
• Возможность использования разнообразных технологий
  * Минусы:
• Сложность внедрения и управления
• Риск дублирования данных и несогласованности
• Необходимость изменения культуры и процессов организации
  * Применение: Крупные организации с большим объемом данных и сложной бизнес-структурой.
  * Период популярности: 2020-е годы – настоящее время.

6. Small Data

* Описание: Подход, фокусирующийся на анализе небольших, но высококачественных наборов данных. В отличие от Big Data, Small Data ориентирован на глубокое понимание конкретных проблем и принятие обоснованных решений.
* Плюсы:

• Высокое качество данных
• Возможность глубокого анализа
• Меньше затрат на хранение и обработку
• Более простая визуализация и интерпретация результатов
  * Минусы:
• Ограниченная статистическая мощность
• Риск смещения выборки
• Необходимость в высококвалифицированных аналитиках
  * Применение: Маркетинг, медицина, финансы, управление проектами.
  * Период популярности: 2010-е годы – настоящее время.

7. DataOps

* Описание: Практики и инструменты для улучшения совместной работы между командами Data Engineering, Data Science и бизнесом. DataOps фокусируется на автоматизации, улучшении качества и скорости доставки данных.
* Плюсы:

• Улучшенная совместная работа и коммуникация
• Автоматизация рутинных задач
• Улучшенное качество и скорость доставки данных
• Улучшенная воспроизводимость и отслеживаемость данных
  * Минусы:
• Сложность внедрения в существующие процессы
• Необходимость обучения сотрудников новым практикам
• Потенциальное увеличение сложности инфраструктуры
  * Применение: Data Engineering, Data Science, бизнес-аналитика.
  * Период популярности: 2010-е годы – настоящее время.

8. Big Data

* Описание: Термин, описывающий большие объемы данных, которые трудно или невозможно обработать с помощью традиционных методов. Big Data характеризуется тремя “V”: объем (Volume), скорость (Velocity) и разнообразие (Variety).
* Плюсы:

• Возможность анализа больших объемов данных
• Выявление скрытых закономерностей и трендов
• Поддержка принятия решений на основе данных
• Возможность использования разнообразных источников данных
  * Минусы:
• Высокая стоимость инфраструктуры и ресурсов
• Сложность обработки и анализа данных
• Риск получения неточных или нерелевантных результатов
• Необходимость в специализированных навыках
  * Применение: Реклама, финансы, здравоохранение, интернет-магазины.
  * Период популярности: 2010-е годы – настоящее время.

9. Data Governance

* Описание: Набор политик, процедур и инструментов для управления качеством, безопасностью и использованием данных. Data Governance направлена на обеспечение доступности, целостности и конфиденциальности данных.
* Плюсы:

• Улучшенное качество данных
• Повышение безопасности данных
• Соответствие нормативным требованиям
• Улучшенная управляемость и эффективность использования данных
  * Минусы:
• Сложность внедрения и управления
• Необходимость в ресурсах и бюджете
• Риск бюрократизации процессов
  * Применение: Организации любого размера и отрасли.
  * Период популярности: 2010-е годы – настоящее время.

10. Data Lineage

* Описание: Отслеживание происхождения данных, их преобразований и использования. Data Lineage помогает понять, откуда поступают данные, как они изменяются и кто их использует.
* Плюсы:

• Улучшенное понимание данных
• Повышение прозрачности и подотчетности
• Помощь в устранении ошибок и улучшении качества данных
• Поддержка соответствия нормативным требованиям
  * Минусы:
• Сложность реализации и поддержки
• Необходимость в ресурсах и бюджете
• Риск создания избыточной информации
  * Применение: Data Engineering, Data Science, бизнес-аналитика.
  * Период популярности: 2010-е годы – настоящее время.

11. Data Catalog

* Описание: Инструмент для обнаружения, понимания и управления метаданными. Data Catalog помогает пользователям находить нужные данные, понимать их смысл и использовать их эффективно.
* Плюсы:

• Улучшенное обнаружение и понимание данных
• Повышение эффективности использования данных
• Поддержка Data Governance и Data Lineage
• Улучшенная совместная работа над данными
  * Минусы:
• Сложность наполнения и поддержки каталога
• Необходимость в ресурсах и бюджете
• Риск создания избыточной информации
  * Применение: Data Engineering, Data Science, бизнес-аналитика.
  * Период популярности: 2010-е годы – настоящее время.

12. Data Virtualization

* Описание: Технология, позволяющая объединять данные из разных источников без физического копирования. Data Virtualization предоставляет виртуальное представление данных, которое обновляется в режиме реального времени.
* Плюсы:

• Улучшенная гибкость и масштабируемость
• Сокращение времени и затрат на интеграцию данных
• Улучшенная доступность и актуальность данных
• Поддержка разнообразных источников данных
  * Минусы:
• Сложность реализации и поддержки
• Риск снижения производительности запросов
• Необходимость в специализированных навыках
  * Применение: Корпоративный анализ, бизнес-аналитика, интеграция данных.
  * Период популярности: 2010-е годы – настоящее время.

13. Data Fabric

* Описание: Архитектурный подход, основанный на создании единой, гибкой и масштабируемой инфраструктуры для работы с данными. Data Fabric объединяет различные технологии и практики для обеспечения унифицированного доступа к данным.
* Плюсы:

• Улучшенная гибкость и масштабируемость
• Сокращение времени и затрат на интеграцию данных
• Улучшенная доступность и актуальность данных
• Поддержка разнообразных источников данных
  * Минусы:
• Сложность реализации и поддержки
• Необходимость в специализированных навыках
• Риск создания избыточной инфраструктуры
  * Применение: Крупные организации с большим объемом данных и сложной бизнес-структурой.
  * Период популярности: 2020-е годы – настоящее время.

14. Data Democratization

* Описание: Процесс предоставления доступа к данным широкому кругу пользователей, включая тех, кто не является специалистами по данным. Data Democratization направлена на повышение эффективности и инноваций в организации.
* Плюсы:

• Улучшенное использование данных
• Повышение эффективности и инноваций
• Улучшенное понимание бизнеса
• Улучшенная ответственность и подотчетность
  * Минусы:
• Риск несанкционированного доступа и утечки данных
• Риск неправильного использования данных
• Необходимость в инструментах и обучении
  * Применение: Организации любого размера и отрасли.
  * Период популярности: 2010-е годы – настоящее время.

15. Data Monetization

* Описание: Процесс превращения данных в ценный актив, который можно использовать для получения дохода. Data Monetization включает в себя продажу данных, предоставление доступа к данным и создание продуктов на основе данных.
* Плюсы:

• Новые источники дохода
• Улучшенное понимание рынка и клиентов
• Улучшенная конкурентоспособность
• Улучшенная эффективность бизнеса

.... дальше он устал) видимо решил, что человечеству еще рано знать эти технологии видимо)) не стал переписывать промт.

Оригинал: https://medium.com/@simon.thelin90/query-plans-analyse-sql-performance-in-trino-97ac1e8f8044

Или тут: https://a.gavrilov.info/data/posts/Query%20Plans%20—%20Analyse%20SQL%20Performance%20In%20Trino%20%7C%20by%20Simon%20Thelin%20%7C%20Medium.pdf Query Plans — Analyse SQL Performance In Trino

Ещё одно воскресенье и ещё одна #датаболь для обсуждения.
Сегодня я хочу углубиться в то, как мы можем понять план запроса в Trino.

Исследование плана запроса
Порядок выполнения SQL — Давайте вспомним
Прежде чем мы начнем рассматривать это, давайте вспомним порядок выполнения в SQL-запросе.
FROM, JOIN
WHERE
GROUP BY
HAVING
SELECT
DISTINCT
ORDER BY
LIMIT
Это поможет нам, когда будем читать план запроса.
Как определить, является ли ваш SQL производительным?⚡
Прежде чем запрос может быть запланирован, движок также должен:
Идентифицировать таблицы
Идентифицировать столбцы, использованные в запросе
SQL, простой подсчёт названий должностей, где мы группируем по департаменту.
EXPLAIN ANALYZE WITH

count_titles AS (
SELECT
department,
COUNT(job_title) AS count_job_titles
FROM lakehouse.bronze.jobs
GROUP BY 1
)

SELECT * FROM count_titles
SQL-запрос использует Общую Табличную Выражение (CTE) под именем count_titles для упрощения структуры и улучшения читаемости запроса.
Он начинается с выбора данных из таблицы lakehouse.bronze.jobs.
Внутри CTE данные группируются по столбцу department.
Для каждой группы департаментов подсчитывается количество вхождений job_title и обозначается как count_job_titles.
После определения CTE основной запрос выбирает все столбцы из count_titles CTE.
Основная цель запроса — получить количество названий должностей для каждого департамента из таблицы lakehouse.bronze.jobs.
План запроса 📣
В очереди: 1.84ms, Анализ: 85.69ms, Планирование: 58.35ms, Выполнение: 450.11ms
Фрагмент 1 [HASH]
CPU: 7.57ms, Запланировано: 11.12ms, Заблокировано: 1.80s (Вход: 933.53ms, Выход: 0.00ns), Вход: 8 строк (176B); на задачу: ср.: 4.00, отклонение: 2.00, Выход: 3 строки (67B)
Количество входных данных, обработанных рабочими для этого этапа, может быть перекошено
Выходная структура: [department, count]
Разделение выхода: SINGLE []
Агрегат[тип = FINAL, ключи = [department]]
│ Расклад: [department:varchar, count:bigint]
│ Оценки: {строк: 3 (68B), cpu: 226, память: 68B, сеть: 0B}
│ CPU: 3.00ms (15.00%), Запланировано: 3.00ms (6.52%), Заблокировано: 0.00ns (0.00%), Выход: 3 строки (67B)
│ Ср. вход: 1.00 строки, стандартное отклонение входа: 132.29%
│ count := count(count_0)
└─ LocalExchange[разделение = HASH, аргументы = [department::varchar]]
│ Расклад: [department:varchar, count_0:bigint]
│ Оценки: {строк: 10 (226B), cpu: 226, память: 0B, сеть: 0B}
│ CPU: 1.00ms (5.00%), Запланировано: 1.00ms (2.17%), Заблокировано: 716.00ms (31.49%), Выход: 8 строк (176B)
│ Ср. вход: 1.00 строки, стандартное отклонение входа: 86.60%
└─ RemoteSource[идентификаторы источников = [2]]
Расклад: [department:varchar, count_0:bigint]
CPU: 0.00ns (0.00%), Запланировано: 1.00ms (2.17%), Заблокировано: 933.00ms (41.03%), Выход: 8 строк (176B)
Ср. вход: 1.00 строки, стандартное отклонение входа: 86.60%

Фрагмент 2 [HASH]
CPU: 11.24ms, Запланировано: 19.46ms, Заблокировано: 860.54ms (Вход: 444.24ms, Выход: 0.00ns), Вход: 10 строк (362B); на задачу: ср.: 5.00, отклонение: 2.00, Выход: 8 строк (176B)
Количество входных данных, обработанных рабочими для этого этапа, может быть перекошено
Выходная структура: [department, count_0]
Разделение выхода: HASH [department]
Агрегат[тип = PARTIAL, ключи = [department]]
│ Расклад: [department:varchar, count_0:bigint]
│ Оценки: {строк: 10 (226B), cpu: ?, память: ?, сеть: ?}
│ CPU: 4.00ms (20.00%), Запланировано: 7.00ms (15.22%), Заблокировано: 0.00ns (0.00%), Выход: 8 строк (176B)
│ Ср. вход: 1.25 строки, стандартное отклонение входа: 118.32%
│ count_0 := count(job_title)
└─ Агрегат[тип = FINAL, ключи = [department, job_title]]
│ Расклад: [department:varchar, job_title:varchar]
│ Оценки: {строк: 10 (362B), cpu: 362, память: 362B, сеть: 0B}
│ CPU: 1.00ms (5.00%), Запланировано: 2.00ms (4.35%), Заблокировано: 0.00ns (0.00%), Выход: 10 строк (362B)
│ Ср. вход: 1.25 строки, стандартное отклонение входа: 118.32%
└─ LocalExchange[разделение = HASH, аргументы = [department::varchar, job_title::varchar]]
│ Расклад: [department:varchar, job_title:varchar]
│ Оценки: {строк: 10 (362B), cpu: 362, память: 0B, сеть: 0B}
│ CPU: 0.00ns (0.00%), Запланировано: 0.00ns (0.00%), Заблокировано: 181.00ms (7.96%), Выход: 10 строк (362B)
│ Ср. вход: 1.25 строки, стандартное отклонение входа: 190.79%
└─ RemoteSource[идентификаторы источников = [3]]
Расклад: [department:varchar, job_title:varchar]
CPU: 0.00ns (0.00%), Запланировано: 0.00ns (0.00%), Заблокировано: 444.00ms (19.53%), Выход: 10 строк (362B)
Ср. вход: 1.25 строки, стандартное отклонение входа: 190.79%

Фрагмент 3 [SOURCE]
CPU: 11.49ms, Запланировано: 32.68ms, Заблокировано: 0.00ns (Вход: 0.00ns, Выход: 0.00ns), Вход: 10 строк (382B); на задачу: ср.: 10.00, std.dev.: 0.00, Выход: 10 строк (362B)
Выходная структура: [department, job_title]
Разделение выхода: HASH [department, job_title]
Агрегат[тип = PARTIAL, ключи = [department, job_title]]
│ Расклад: [department:varchar, job_title:varchar]
│ Оценки: {строк: 10 (362B), cpu: ?, память: ?, сеть: ?}
│ CPU: 1.00ms (5.00%), Запланировано: 3.00ms (6.52%), Заблокировано: 0.00ns (0.00%), Выход: 10 строк (362B)
│ Ср. вход: 10.00 строк, std.dev.: 0.00%
└─ Сканирование таблицы[таблица = lakehouse:bronze.jobs]
Расклад: [job_title:varchar, department:varchar]
Оценки: {строк: 10 (362B), cpu: 362, память: 0B, сеть: 0B}
CPU: 10.00ms (50.00%), Запланировано: 29.00ms (63.04%), Заблокировано: 0.00ns (0.00%), Выход: 10 строк (382B)
Ср. вход: 10.00 строк, std.dev.: 0.00%
job_title := job_title:varchar:ОБЫЧНО
department := department:varchar:ОБЫЧНО
Вход: 10 строк (382B), Физический вход: 1.32kB, Время физического входа: 7.50ms
Общая информация о выводе и плане запроса

Высокоуровневый вывод выполнения.

В очереди: 1.84ms
Анализ: 85.69ms
Планирование: 58.35ms
Выполнение: 467.68ms
Разделение на фрагменты
Выполнение запроса делится на три главные фрагмента. Каждый фрагмент представляет этап в процессе выполнения.
Фрагмент 1 [HASH]

HASH
Роль: Этот фрагмент обрабатывает окончательную агрегацию результатов.
Производительность:
CPU: 7.57ms
Запланировано: 11.12ms
Заблокировано: 1.80s (главным образом ожидание данных от других фрагментов)
Вход/Выход:
Вход: 8 строк (176B)
Выход: 3 строки (67B)
Выходная структура: [department, count]
Операции:
Агрегация: Окончательная агрегация по департаменту для вычисления общего количества названий должностей.
Локальный обмен: Перераспределение данных по департаменту для подготовки к окончательной агрегации.
Фрагмент 2 [HASH]

Роль: Этот фрагмент выполняет частичную агрегацию названий должностей по департаменту.
Производительность:
CPU: 11.24ms
Запланировано: 19.46ms
Заблокировано: 860.54ms
Вход/Выход:
Вход: 10 строк (362B)
Выход: 8 строк (176B)
Выходная структура: [department, count_0]
Операции:
Частичная агрегация: Подсчитывает названия должностей по департаменту.
Локальный обмен: Перераспределение данных по департаменту, job_title для дальнейшей агрегации.
Фрагмент 3 [SOURCE]

SOURCE — Сканирование таблицы
Роль: Этот фрагмент читает данные из исходной таблицы.
Производительность:
CPU: 11.49ms
Запланировано: 32.68ms
Вход/Выход:
Вход: 10 строк (382B)
Выход: 10 строк (362B)
Выходная структура: [department, job_title]

Операции:
Сканирование таблицы: Чтение столбцов department и job_title из таблицы lakehouse.bronze.jobs.
Частичная агрегация: Группировка данных по департаменту и job_title и подготовка их к дальнейшей обработке.

Ключевые выводы
Чтение плана запроса: Этапы представлены в порядке от наименьшего значения этапа к последнему шагу, и от наибольшего значения этапа к первому шагу. Это также связывается с порядком выполнения, который мы упомянули выше.

Время блокировки: Значительное время блокировки указывает на ожидание передачи данных между фрагментами, особенно в Фрагменте 1 и Фрагменте 2. Это часто является признаком задержек передачи данных или неравенства во времени обработки между фрагментами.
Перекос данных: Обратите внимание на перекос в количестве данных, обрабатываемых рабочими на различных этапах, что приводит к тому, что некоторые рабочие обрабатывают больше данных, чем другие. Это может вызывать неэффективность.
Шаги агрегации: Запрос включает несколько этапов частичных и окончательных агрегаций, которые можно оптимизировать, если возможно, уменьшив переброс данных между фрагментами.
CPU и планирование: Время работы CPU и планирования относительно низкое по сравнению с заблокированным временем, что предполагает, что ресурсы CPU не являются узким местом.
Настройка SQL: Измените ваш SQL и изучите план запроса, чтобы найти правильный баланс между этими факторами.

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

Оригинал: https://medium.com/thedeephub/how-do-we-run-kafka-100-on-the-object-storage-521c6fec6341
А тут pdf’ка

Не стал переводить

Оригинал: https://blog.det.life/no-data-engineers-dont-need-dbt-30573eafa15e

Нужно ли мне изучать dbt? Я часто вижу этот вопрос на Reddit, и он меня путает. Звучит просто. Использует ли ваша компания dbt? Если да, то да. Если нет, то нет. Как и любой другой инструмент, dbt лучше всего использовать в тех сценариях, где он хорошо подходит. В то же время, я часто читаю мнения людей, которые говорят, что dbt не приносит пользы. Затем они начинают перечислять десять инструментов, которые они используют вместо этого. Должен быть какой-то средний путь.

Видите ли, здесь важен именно аспект «хорошей подгонки», а не необходимость. Мы используем инструменты для решения проблем. Позвольте повторить это. Мы используем инструменты для решения проблем. Не потому, что они крутые или мы хотим добавить их в наш набор навыков, или потому что все остальные их используют. Инструменты помогают нам решать проблемы. Давайте рассмотрим проблемы, которые помогает решать dbt, и случаи, когда он подходит. Черт возьми. Давайте также поговорим о сценариях, в которых он не подходит.

Что такое dbt — лучшее определение?
Существует распространенное заблуждение, что dbt — это инструмент ELT, который позволяет извлекать, загружать и преобразовывать данные. Это неверно. Dbt — это всего лишь инструмент для преобразования данных с использованием SQL. Если вы не используете SQL для преобразования данных, использование dbt станет огромным изменением. Возможно, это не для вас. Если у вас есть хранилище данных, где SQL является общим языком, то dbt может быть хорошим вариантом.

Говорить, что dbt — это просто инструмент для преобразования, недооценивает его ценность, потому что преобразование данных — это большая задача в корпоративной среде. Так что давайте дадим ему лучшее определение:
Dbt — это набор утилит, который позволяет управлять преобразованием данных с использованием динамического SQL в гибком языке шаблонов.

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

Управление зависимостями
Динамический код
Материализация
Тестирование – качество данных и проверка кода
Генерация документация ( плюс от меня )

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

Не большая проблема для решения, но самодельные решения будут нуждаться в реализации какой-то системы управления зависимостями. Dbt делает это с помощью функции ref(). Вот пример того, как это работает у меня на работе. Если я использую ref() в WHERE clause, dbt автоматически подберет нужную таблицу для среды, в которой мы работаем.

dev: dev_lgodin_dw.common.date_d
staging: dw_staging.common.date_d
prod: dw.common.date_d

```sql
select
date,
year,
month
from {{ ref(‘date_d’) }}
```

Управление зависимостями – это гораздо больше, чем просто идентификация полностью квалифицированного имени таблицы. Мы должны понимать порядок выполнения преобразований. Например, fact_sales должна выполняться перед fact_sales_monthly. Использование ref() автоматически решает эту задачу. Фактически, dbt создает граф зависимостей каждый раз при его запуске. Посмотрите на зависимости ниже для dbt-fake.

Граф зависимостей dbt

Давайте надеяться, что вы никогда не увидите что-то подобное в вашем хранилище данных. Я использую это для создания фальшивых данных, поэтому это не типичный сценарий. Используя ref() в моих моделях, dbt фиксирует зависимости за меня. Он выполнит эти модели в четыре этапа, используя параллелизм, когда это возможно.

fake_companies, fake_dates и fake_numbers
companies_base
employees_base
enterprise_orders_base

Теперь представьте хранилище данных с сотнями источников и сотнями моделей. Ручное определение зависимостей было бы непростой задачей. Вам понадобилась бы какая-то утилита для управления зависимостями. Dbt решает эту задачу из коробки. Если вы хотите пойти дальше, вы можете изучить зависимости с помощью переменной graph или manifest.json в dbt.

Динамический SQL
```sql
{{
config(
materialized = ‘incremental’,
unique_key = [‘order_date’, ‘user_id’, ‘product_id’],
)
}}

select
date as order_date,
user_id,
product_id,
num_items,
sum(num_items) over (partition by user_id) as total_weekly_items,
current_timestamp() as created_at,
current_timestamp() as updated_at
from {{ get_date_filtered_subquery(
source_model=ref(‘stg_orders’),
target_model=this,
run_at_date=get_run_at_date()) }}
```

Моя главная жалоба на SQL заключается в его слабой поддержке для написания динамических запросов. Каждый поставщик реализует свои собственные методы для динамической генерации SQL путем склеивания строк и запуска некоторых команд exec. Dbt интегрирует Jinja-SQL как часть комплексного пакета для преобразования данных. Это значит, что мы можем писать динамический SQL на языке шаблонов.

Хотели ли вы когда-нибудь использовать цикл for в SQL для написания повторяющегося кода? Вы можете сделать это. Я часто использую метаданные для генерации больших запросов. Например, у нас есть таблица Customer 360 с ~200 столбцами. Эта таблица строится динамически с использованием CSV для метаданных и Jinja для генерации SQL. Это не только экономит время, но и значительно уменьшает количество ошибок, вызванных ручным вводом.

Как насчет автоматизации логики дат в ваших преобразованиях? Да, динамический SQL спасает положение. Нужно ли запускать ваши задания для конкретных дат, возможно, для обеспечения идемпотентности? Dbt поможет. Суть в том, что SQL хорош, но динамический SQL позволяет писать запросы, как программист. С Jinja мы можем создавать переиспользуемые компоненты, называемые макросами. Мы можем использовать циклы для написания повторяющегося кода. Мы можем думать о SQL как о результате нашей работы, а не только об усилиях.

Автоматическая Материализация

Самое распространенное, что мы делаем в хранилищах данных, — это создаем/обновляем таблицы и представления. Dbt называет это материализацией. Обычно мы используем insert или merge для этого. Хотя эти операторы не сложны, они быстро становятся утомительными. Мы находим себя пишущими один и тот же код снова и снова, просто чтобы записать разные столбцы в базу данных. Какое это пустая трата времени.

С dbt нам никогда не нужно писать операторы insert или merge. Мы пишем запросы и настраиваем материализацию. Хотите представление (view)? materialization = ‘view’. Это инкрементальная таблица? Правильно, materialization = ‘incremental’. Может быть, вам нужна медленно меняющаяся размерность типа-2? Это немного другое, но dbt имеет для этого “снимки” (snapshots). Когда все сказано и сделано, мы настраиваем, как мы хотим материализовать данные, и dbt автоматически обрабатывает это. Это мощно. Давайте посмотрим на пример. Код ниже реализует инкрементальную таблицу.

```sql
{{
config(
materialized = ‘incremental’,
unique_key = [‘order_date’, ‘user_id’, ‘product_id’],
)
}}

select
date as order_date,
user_id,
product_id,
num_items,
sum(num_items) over (partition by user_id) as total_weekly_items,
current_timestamp() as created_at,
current_timestamp() as updated_at
from {{ get_date_filtered_subquery(
source_model=ref(‘stg_orders’),
target_model=this,
run_at_date=get_run_at_date()) }}
```

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

```sql
create or replace table `leogodin217-dbt-tutorial`.`enterprise_sales`.`weekly_orders`
OPTIONS()
as (
select
date as order_date,
user_id,
product_id,
num_items,
sum(num_items) over (partition by user_id) as total_weekly_items,
current_timestamp() as created_at,
current_timestamp() as updated_at
from (
select
*
from `leogodin217-dbt-tutorial`.`enterprise_sales`.`stg_orders`
) as stg_orders
);
```

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

```sql
merge into `leogodin217-dbt-tutorial`.`enterprise_sales`.`weekly_orders` as DBT_INTERNAL_DEST
using (
select
date as order_date,
user_id,
product_id,
num_items,
sum(num_items) over (partition by user_id) as total_weekly_items,
current_timestamp() as created_at,
current_timestamp() as updated_at
from (
select
*
from `leogodin217-dbt-tutorial`.`enterprise_sales`.`stg_orders`
where date between ‘2024-07-07’ and ‘2024-07-13’
) as stg_orders
) as DBT_INTERNAL_SOURCE
on (
DBT_INTERNAL_SOURCE.order_date = DBT_INTERNAL_DEST.order_date
) and (
DBT_INTERNAL_SOURCE.user_id = DBT_INTERNAL_DEST.user_id
) and (
DBT_INTERNAL_SOURCE.product_id = DBT_INTERNAL_DEST.product_id
)

when matched then update set
`order_date` = DBT_INTERNAL_SOURCE.`order_date`,
`user_id` = DBT_INTERNAL_SOURCE.`user_id`,
`product_id` = DBT_INTERNAL_SOURCE.`product_id`,
`num_items` = DBT_INTERNAL_SOURCE.`num_items`,
`total_weekly_items` = DBT_INTERNAL_SOURCE.`total_weekly_items`,
`created_at` = DBT_INTERNAL_SOURCE.`created_at`,
`updated_at` = DBT_INTERNAL_SOURCE.`updated_at`

when not matched then insert
(`order_date`, `user_id`, `product_id`, `num_items`, `total_weekly_items`, `created_at`, `updated_at`)
values
(`order_date`, `user_id`, `product_id`, `num_items`, `total_weekly_items`, `created_at`, `updated_at`)
```

Тестирование. Раз, два, три, тестирование.

Не секрет, что хранилища данных отстают на световые годы от традиционной разработки программного обеспечения в плане тестирования. Существуют множество причин для этого. Во-первых, тестировать хранилища данных на порядки сложнее, чем общее ПО. В Python-приложении мы можем выделить отдельный модуль. Это не применимо в хранилище данных. Нам всегда нужна работающая база данных для тестирования чего-либо. В лучшем случае у нас есть интеграционные или системные тесты. Более того, помимо тестирования нашего кода, нам нужно тестировать сами данные. Это не часто входит в область ответственности разработчиков приложений. Как dbt справляется с этим?

Качество данных

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

Валидация кода

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

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

Финальное определение для dbt

Мы обсудили четыре ключевые проблемы, с которыми сталкиваемся при преобразовании данных и как dbt решает их. У dbt есть много других функций, и стоит посетить их веб-сайт для получения дополнительной информации. Там вы найдете больше о контроле версий, документации, графических операторах для запуска подмножеств моделей и многое другое. Но мы знаем достаточно, чтобы улучшить наше определение.

Что такое dbt?
Dbt — это комплексный пакет, позволяющий инженерам сосредоточиться на реализации бизнес-логики в преобразованиях хранилища данных.

Как работает dbt?
Dbt работает, абстрагируя общие шаблоны хранилищ данных в автоматизацию, управляемую конфигурацией, и предоставляя набор инструментов для упрощения SQL-преобразований, тестов и документации.

Когда dbt вам не нужен

Не существует единого инструмента, который подошел бы всем. Мы говорили об этом. Мы используем инструменты для решения проблем. Dbt не решает все проблемы. В каких случаях dbt не является правильным инструментом для работы?

• У вас уже есть зрелая платформа. Хранилища данных существуют намного дольше, чем dbt. Многие компании создали фантастические среды для преобразований. Эти инженеры не нуждаются в новых инструментах.
• Вы используете ETL вместо ELT. Я знаю, что сейчас ELT в моде, но есть много примеров, когда ETL лучше подходит. Если это ваш рабочий процесс, то dbt не поможет. Dbt только преобразует данные. Он не будет перемещать данные с S3 в Snowflake. Он не будет читать из MongoDB и записывать в Postgres. Это не его задача.( До тех пор пока у вас нет Trino )
• Ваша рабочая нагрузка не принадлежит хранилищу данных. Некоторые источники данных не вписываются в простой ELT-паттерн. Cai Perry-Jones написал пример с сотнями файлов CSV с разными схемами. Модели Python в dbt, конечно, могут справиться с этим, но возможно, лучше сделать это до того, как данные попадут в ваше хранилище данных. Конечно, как только они попадут туда, dbt может быть правильным инструментом для интеграции этих данных в нижележащие таблицы и представления.

Хотите лучше понять dbt? Попробуйте мой список статей по промежуточному и продвинутому уровню dbt.

Нужен ли вам dbt?

Надеюсь, к этому моменту вы поняли, что мы все время задавали неправильный вопрос. Никому не нужен dbt, если это не требуется для их работы. Гораздо лучше задать вопрос: поможет ли dbt решить проблемы, с которыми мы сталкиваемся? Если dbt делает вашу работу проще, то, вероятно, это хороший выбор. Dbt помог нам улучшить качество данных, уменьшить количество сбоев задач и улучшить нашу дисциплину разработки программного обеспечения. По этим причинам он хорошо подходит для нас. Нам не нужен dbt, но он, безусловно, решает множество проблем.

Перевод: https://medium.com/@ashishverma_93245/data-mesh-data-fabric-better-together-15a8b70f4a9e

Оригинал: Data Mesh & Data Fabric : лучше вместе!

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

Отказ от ответственности: высказанные в этой статье мнения являются моими и не представляют взгляды моих предыдущих, текущих или будущих работодателей. В статье несколько раз упоминается Microsoft Fabric, и поскольку на данный момент я работаю в Microsoft, это может рассматриваться как конфликт интересов. Я выделяю Microsoft Fabric, потому что это единственная реализация Data Fabric, с которой я ознакомлен, и считаю, что она эффективно решает поставленные задачи.

Структура обсуждения следующая:

• Обзор Data Mesh
• Обзор Data Fabric
• Взаимодополняющая природа двух подходов
• Реальные сценарии использования Data Mesh и Data Fabric
• Ловушки, которых стоит избегать

1. Обзор Data Mesh
   Общее определение Data Mesh звучит примерно так: «Data Mesh — это децентрализованный подход к архитектуре, который организует данные по конкретным бизнес-доменам, позволяя командам управлять данными как продуктом и обеспечивая самодостаточный доступ в рамках организации». Я считаю полезным рассматривать эти концепции через призму ключевых вызовов, для которых они были созданы. Давайте исследуем проблемы, которые привели к созданию Data Mesh.

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

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

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

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

Data Mesh решает эти вызовы, предлагая следующие принципы:

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

Данные как продукт. Data Mesh продвигает идею обращения с данными как с продуктом, применяя к данным принципы управления продуктом. Data Product включает в себя наборы данных, метаданные, вспомогательную инфраструктуру и механизмы доставки, такие как API или потоки. Data Products подразделяются на два типа: ingestion (выравненные с источником) и consumption (выравненные с задачами). Этот подход обеспечивает эффективное управление, требующее от каждого набора данных выполнять свои функции или быть выведенным из эксплуатации. Продуктовые команды, находящиеся в домене, создают и поддерживают эти Data Products, используя инструменты, предоставляемые центральной командой платформы.

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

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

Вот такими представляют себе Data Mesh (немного больше, чем в кратком изложении).

2. Обзор Data Fabric
   Data Fabric должна рассматриваться как каркас или техническая спецификация дизайна, которая определяет интегрированный набор инструментов для создания полностью функциональной современной платформы данных, обеспечивающей централизованный доступ к распределенным данным. Этот всеобъемлющий набор инструментов направлен на удовлетворение потребностей всех заинтересованных сторон платформы, от инженеров данных, ученых и аналитиков до бизнес-пользователей. Обратите внимание, что задачи, которые решает Data Fabric, касаются в основном организации с большим объемом данных. Чтобы понять Data Fabric немного глубже, давайте поговорим о проблемах, которые она решает.

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

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

b. Дублирование данных. Наборы данных часто копируются несколько раз в различных системах, усложняя стремление найти единый источник истины.

c. Отсутствие стандартизации. Без стандартизированных инструментов организации сталкиваются со сложностями в:
— контроле издержек и обеспечения безопасности
— поддержании единых стандартов качества на уровне всего объема данных
— росте затрат на лицензирование

d. Ограниченная видимость затрат. Обеспечение единого обзора затрат на уровень всего объема данных является редкостью из-за:
— отсутствия механизма отслеживания стоимости на уровне дизайна
— слабая интеграция различных инструментов и панель управления

Это ограничение видимости мешает директорами по технологиям (CTO) и директорами по данным (CDO) выявлять стратегические возможности для инвестиций и области для оптимизации затрат, усложняя эффективное управление объемом данных.

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

3. Взаимодополняющая природа двух подходов — Mesh & Fabric
   Из нашего обсуждения ясно, что Data Mesh и Data Fabric служат различным целям в рамках общего решения. Давайте исследуем это в контексте различных уровней, составляющих конечное. Хотя это и не является стандартной структурой, я нахожу это полезным для понимания, как эти два подхода работают вместе.

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

Ключевые моменты о взаимодополняющей природе Data Mesh и Data Fabric:

• Data Mesh и Data Fabric не конкурируют друг с другом, а служат разным целям при создании окончательного решения.
• Перекрытие на уровне «Люди» между Mesh и Fabric подчеркивает необходимость в квалифицированных ресурсах для обоих подходов.
• Data Mesh определяет архитектуру решений, модель работы и управление.
• Решения Data Fabric (например, Microsoft Fabric) реализуют определенную архитектуру, политику управления и возможности самодостаточного использования.
• Конкретные проектирования модулей (например, потоки данных) диктуются доступными инструментами Fabric.
• Используя оба подхода, вы можете создать комплексное решение, которое использует сильные стороны как методологии Data Mesh, так и Data Fabric.

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

• Реализует Data Fabric, например, Microsoft Fabric
• Устанавливает ключевые компоненты, такие как безопасность, соответствие и интеграции, при поддержании архитектуры Data Mesh и управлении на основе федеративных принципов
• Предоставляет интерфейс самообслуживания для команд, занимающихся продуктами данных

Команды Data Product:

• Используют инструменты самооблуживания для создания продуктов, предназначенных для получения данных и удовлетворения конкретных задач.
• Управляют функциями своих Data Products, чтобы обеспечить их эффективное предоставление значимых результатов для целевых бизнес-кейсов.
• Обновляют свои инструменты продукта с помощью обновлений, таких как патчи безопасности и улучшения производительности, предоставляемые основными командами.
  Этот подход упрощает процессы и позволяет инженерам сосредоточиться на эффективном предоставлении своих задач.

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

1. Недоступность активов данных, сдерживающая инновации : Ключевым преимуществом для зрелой организации данных является то, что их бизнес-персонал обладает высокой мотивацией к исследованию активов данных для извлечения инсайтов для создания новых функций и продуктов. В постиночно выросших больших данных, эта задача самоисследования становится экспоненциально сложнее из-за таких проблем как:
   — надежное обнаружение нужных данных,
   — наличие инструментов для исследования обнаруженных данных в контексте друг друга
   — техническая экспертиза, необходимая для настройки и использования доступных инструментов
   Решение Data Fabric справляется с этими проблемами с помощью двух ключевых функций:
   а. Унифицированный просмотр данных:
   — Предоставляет единое окно для всех организационных данных
   — Позволяет выполнять запросы к любому набору данных без его копирования, используя виртуализацию данных (например, в Microsoft Fabric)

b. Возможности самообслуживания:
— Упрощает исследование данных для нетехнических пользователей
— Включает AI-ассистентов (например, Copilot от Microsoft Fabric) для запросов на естественном языке и отчетности
Решение этих проблем с открытием данных может существенно повлиять на организацию, позволив выявить новые продуктовые линии и источники дохода.

2. Централизованное аналитическое рабочее пространство: Предположим, что платформа Data Mesh в основном обслуживает продукты данных, выровненные с бизнесом и выровненные с источником. Организации может быть полезно вложиться в аналитическое рабочее пространство, которое позволит изучать и обрабатывать все наборы данных — будь то локальные, в облачных хранилищах или как продукты данных — позволяя анализировать данные относительно друг друга без необходимости создания копий. В современную эпоху ИИ данные являются вашим самым ценным активом, и их доступность для анализа может дать значительные преимущества вашей организации. Решения Data Fabric, такие как Microsoft Fabric, идеально подходят для реализации такого рабочего пространства, потому что они:
   — Предоставляют унифицированное рабочее пространство без необходимости настройки отдельных решений для работы друг с другом
   — Обеспечивают бесшовное сотрудничество
   — Предлагают интеграцию AI, которая помогает на всех этапах
   — Гарантируют встроенную безопасность на протяжении всего процесса

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

5. Ловушки, которых стоит избегать при использовании обоих подходов
   Представленная выше структура “Solution Layers” предлагает прочную основу для понимания правильного использования Data Mesh и Data Fabric вместе. При сравнении этих двух подходов важно учитывать, на каком уровне вы решаете проблему. Ниже приведены некоторые общие первопричины, которые следует помнить:
6. Запутывание децентрализации в Data Mesh с централизацией в Data Fabric: Децентрализация в Data Mesh относится к распределенному владению продуктами данных (данными, инструментами и т. д.). Однако это не исключает использование централизованно управляемой технологии для поддержки этих различных продуктов данных. Например, в Azure несколько продуктов данных, принадлежащих различным командам (децентрализованно), могут использовать Azure Data Factory (ADF) для загрузки данных. В таком сценарии Центр выдающихся достижений в области инженерии данных (Data Engineering Center of Excellence) может контролировать общие политики по используемым инструментам для управлением загрузки данных для всех продуктов данных, эффективно централизуя управление технологиями.

Аналогично, решения Data Fabric, такие как Microsoft Fabric, предоставляют интегрированный набор инструментов для операций, таких как загрузка данных, обработка, хранение и визуализация из одного централизованного, универсального решения. Microsoft Fabric расширяет эту концепцию “центрального управления”, предоставляя доступ к обработке данных, хранящихся на других системах, без необходимости их копирования непосредственно в Fabric.

2. Управление: Data Mesh продвигает федеративное вычислительное управление, которое является децентрализованным, в то время как Data Fabric может предложить реализацию более централизованной модели управления. Такой подход может хорошо работать, если у вас есть только одна платформа Data Mesh, реализованная с помощью одного решения Data Fabric. Однако для разнообразного объема данных с Data Mesh, реализованного наряду с существующими хранилищами данных и платформами, может быть более целесообразно рассмотреть возможность использования “каталога каталогов” для обеспечения управления на уровне всего объема данных. Дополнительно, совместимость существующих инструментов управления с выбранным решением Fabric также является важной частью этого уравнения. Конечная цель должна заключаться в том, чтобы определить наилучшую версию модели управления, которая работает для вашей организации, а затем найти наиболее эффективные способы и инструменты для ее реализации.

3. Сосредоточенность на решении бизнес-проблемы, а не инструменте: Я уверен, что вы уже знаете это, но стоит отметить, основная цель не должна заключаться в использовании Fabric и Mesh вместе, а в решении вашей проблемы с наименьшими затратами.

Заключение
В заключение, я верю, что оба этих подхода могут работать вместе для достижения значительной бизнес-ценности. Если у вас есть опыт с такими реализациями, пожалуйста, свяжитесь со мной... мне бы хотелось узнать больше. И, пожалуйста, не стесняйтесь делиться любыми отзывами. Спасибо за внимание!