Yuriy Gavrilov

Welcome to my personal place for love, peace and happiness❣️

Прогноз от Saxo Bank на 2025 год

Вышел очередной шок-прогноз от Saxo Bank на 2025 год. Аналитики говорят, что такие прогнозы — традиционный декабрьский пиар-ход Saxo Bank. Сам банк говорит, что это список маловероятных, но все же возможных событий в новом году, которые способны повлиять на мир, поэтому прогноз так и называется — «вопиющий». И тем не менее его подробным образом изучают во всех ведущих мировых СМИ.
В прогнозе на 2025 год Saxo Bank выдал восемь сценариев вместо обычных десяти. Первый — о том, что доллар США рухнет из-за того, что Дональд Трамп еще больше повысит торговые пошлины для стран-импортеров. Это ударит по странам Глобального Юга, которые начнут искать альтернативу доллару. Американская валюта потеряет статус мировой резервной.
Во втором пункте прогноз о том, что компания Nvidia, которая продает чипы для процессоров, обгонит Apple по капитализации в два раза. Причина — глобальная гонка искусственных интеллектов.

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

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

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

Ну и британский фунт, упавший из-за Brexit, снова вырастет по отношению к евро, поскольку Великобритания проведет новую фискальную политику.

https://www.bfm.ru/news/563485

 No comments   1 h   AI   Crypto   Life

Поздравляем детей на новый год – Ёлка желаний

У многих в офисах стали ставить ёлки желаний детей из детских домов. У нас тоже такую поставили.

Попробовал написать поздравление с помощью нейроночки. Получилось лучше всего у Claude Sonet 3.5. А проще всего это сделать можно в Gigachat от Сбера https://t.me/gigachat_bot

Я аж прослезился. 😭 Читайте сами, но я вас предупреждал))

Дорогая Женечка!

С Новым годом, милое дитя! Я получил твоё письмо, которое долетело до меня через метели и звёздные дали. Знаешь, глядя на твою фотографию рядом с книжными полками, я вижу в твоих глазах отражение тех самых звёзд, о которых хочу тебе рассказать.

Представь себе, Женечка, что там, высоко над нами, раскинулся бескрайний космос – такой огромный, что даже я, Дед Мороз, не могу обойти его весь! В нём кружатся миллиарды звёзд, каждая из которых может быть чьей-то мечтой. И знаешь что? Космос похож на твои мечты – он такой же безграничный и полный чудес.

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

Женечка, твоё сердце – словно маленькая Вселенная, в которой живут самые светлые мечты. И знаешь что? Мечты – это не просто фантазии, это маленькие звёздочки, которые освещают путь к будущему. Я, как хранитель новогодних чудес, точно знаю: когда ты искренне веришь в свою мечту, она обязательно сбывается!

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

Храни свои мечты, моя дорогая, и верь в чудеса! Ведь чудеса случаются с теми, кто в них верит.

С новогодним волшебством,
Твой Дедушка Мороз

P.S. Я оставил тебе под ёлочкой особенный подарок, который напомнит тебе о бескрайнем космосе и о том, что мечты обязательно сбываются! 🌟

А в подарке https://www.ozon.ru/product/proektor-zvezdnogo-neba-shakachu-vega-bt-360-meteor-6-slaydov-muzykalnyy-nochnik-zvezdnoe-1354326542/

Ночник Шакачу – ооочень красивый) тоже такой хотел бы в детстве))

 No comments   4 d   charity   Life

Пополнение – Asurah

In ‘The Masks we Wear’ series, I wanted to bring together the folkloric fused with a futuristic cyberpunk aesthetic to create something that felt timeless or time agnostic. Ironically, the pandemic has made this series especially timely for our ‘new normal’

Vini Naso
 No comments   11 d   art   Art nft   NFT

Интеграция данных на базе SeaTunnel: Как 58.com обрабатывает более 500 млрд датасетов ежедневно

Перевод: https://dev.to/seatunnel/seatunnel-powered-data-integration-how-58-group-handles-over-500-billion-data-points-daily-3d1m

Введение

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

Вызовы платформы интеграции данных

Бизнес-контекст

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

В настоящее время 58 Group обрабатывает более 500 миллиардов сообщений ежедневно, с пиковым объемом обработки сообщений, превышающим 20 миллионов, и количеством задач, превышающим 1600. Обработка такого огромного объема данных представляет значительные вызовы.

Вызовы

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

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

Эволюция архитектуры

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

Ранняя архитектура

  • 2017: Использовался Flume для интеграции платформы.
  • 2018: Внедрен Kafka Connect 1.0.
  • 2020: Использовалась версия Kafka Connect 2.4, достигнута инкрементальная балансировка нагрузки и CDC (Change Data Capture).
  • 2023: Внедрен Apache SeaTunnel, интегрированный в платформу реального времени вычислений, и расширены различные Source/Sink.

С 2017 по 2018 год платформа интеграции данных 58 Group использовала архитектуру Kafka Connect, основанную на интеграции данных с Kafka, с горизонтальным масштабированием и распределенной обработкой, поддерживающей работу Workers и Tasks на нескольких узлах; Workers автоматически перераспределяют задачи на другие Workers при сбое, обеспечивая высокую доступность; также поддерживается автоматическое управление смещением и управление задачами и конфигурацией через Rest API.

Однако с расширением объема бизнеса и разнообразием сценариев эта архитектура столкнулась с ограничениями:

Ограничения архитектуры

  • Невозможность достижения полной интеграции данных.
  • Проблемы с Coordinator Bottleneck
    • Heartbeat Timeout: Тайм-ауты сердцебиения Worker-to-coordinator вызывают перебалансировку задач, вызывая временные прерывания задач.
    • Heartbeat Pressure: Workers синхронизируются с координаторами, отслеживая состояния Workers и управляя большим объемом метаданных задач.
    • Coordinator Failure: Простой координатора влияет на распределение и перераспределение задач, вызывая сбои задач и снижение эффективности обработки.
  • Влияние Task Rebalance
    • Task Pause and Resume: Каждая перебалансировка приостанавливает задачи, затем перераспределяет их, что приводит к кратковременным прерываниям задач.
    • Rebalance Storms: Если несколько узлов Workers часто присоединяются или покидают кластер, или если сетевая дрожь вызывает тайм-ауты сердцебиения, частые Rebalance могут значительно повлиять на эффективность обработки задач, вызывая задержки.

Учитывая эти недостатки, 58 Group в 2023 году внедрила Apache SeaTunnel, интегрировав его в платформу реального времени вычислений для свободного расширения различных Source/Sink.

Текущая архитектура

В настоящее время платформа интеграции данных 58 Group, основанная на движке Apache SeaTunnel, интегрирует источники данных (Kafka, Pulsar, WMB, Hive и т.д.), обрабатывает их через встроенные функции Transform SeaTunnel и отправляет их в целевые базы данных (Hive, HDFS, Kafka, Pulsar, WMB, MySQL, SR, Redis, HBASE, Wtable, MongoDB и т.д.), достигая эффективного управления задачами, управления статусом, мониторинга задач, интеллектуальной диагностики и многого другого.

Плавная миграция и настройка производительности

Плавная миграция

При внедрении Apache SeaTunnel 58 Group должна была выполнить плавную миграцию платформы интеграции данных, чтобы минимизировать влияние на пользователей или бизнес и обеспечить согласованность данных, сохраняя согласованность формата, пути и отсутствие потерь данных.

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

Для решения этой проблемы 58 Group предприняла следующие меры:

  • Для источников добавлен RawDeserializationSchema для совместимости с неструктурированными данными.
  • Для целей, таких как использование hdfs sink для hive, для совместимости с загрузкой партиций и путями.
  • Разработка автоматических инструментов миграции:
    • Автоматическое генерирование конфигураций задач, генерирование соответствующих конфигураций задач SeaTunnel на основе конфигураций Kafka Connect.
    • Отключение исходных задач, сброс смещений и запуск новых задач.
    • Проверка и проверка.

Настройка производительности

58 Group также провела несколько оптимизаций производительности на платформе интеграции данных, включая:

  • Добавление Pulsar Sink Connector: Для увеличения пропускной способности.
  • Поддержка Array Data: Улучшение совместимости HbaseSink.
  • Поддержка установки времени истечения срока действия: Оптимизация RedisSink.
  • Увеличение пропускной способности PulsarSource: Оптимизация метода сжатия файловых коннекторов.
  • Исправление проблем с парсингом KafkaSource: Улучшение гибкости конфигурации клиентов Kafka.

Мониторинг и автоматизация операций

Кроме того, 58 Group улучшила стабильность и эффективность платформы интеграции данных через мониторинг и автоматизацию операций:

  • Мониторинг задач: Реальный мониторинг статуса задач для быстрого обнаружения и устранения сбоев.
  • Автоматизация операций: Сокращение ручного вмешательства через автоматизированные инструменты для увеличения операционной эффективности.

Планы будущего развития

58 Group имеет четкие планы на будущее развития платформы интеграции данных:

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

Заключение

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

Для справки

Что такое Apache SeaTunnel и для чего он нужен?

Apache SeaTunnel — это открытая платформа для интеграции данных, разработанная на основе Apache Spark и Apache Flink. Она предназначена для обеспечения высокопроизводительной, надежной и масштабируемой обработки потоковых и пакетных данных. SeaTunnel предоставляет удобный интерфейс для разработчиков, позволяющий легко интегрировать различные источники данных (такие как Kafka, Pulsar, Hive и другие) и отправлять их в различные хранилища данных (такие как HDFS, Kafka, MySQL, Redis и т.д.).

Основные функции и преимущества Apache SeaTunnel:

  1. Высокая производительность: SeaTunnel использует мощные движки Apache Spark и Apache Flink для обеспечения высокой скорости обработки данных.
  2. Надежность: Платформа обеспечивает гарантию доставки данных, чтобы избежать потерь данных при сбоях.
  3. Масштабируемость: SeaTunnel может легко масштабироваться для обработки больших объемов данных.
  4. Гибкость: Поддерживает множество источников и приемников данных, что делает его универсальным инструментом для интеграции данных.
  5. Простота использования: Предоставляет удобный интерфейс для разработчиков, упрощая настройку и управление задачами интеграции данных.

Для чего нужен Apache SeaTunnel?

Apache SeaTunnel используется для решения задач интеграции данных в различных сценариях, таких как:

  • Обработка потоковых данных: SeaTunnel может использоваться для обработки данных в реальном времени, например, для анализа данных сенсоров, мониторинга активности пользователей и т.д.
  • Интеграция данных из различных источников: SeaTunnel позволяет объединять данные из разных источников, таких как базы данных, хранилища объектов, системы логгирования и т.д.
  • Перенос данных: SeaTunnel может использоваться для переноса данных между различными хранилищами данных, например, из MySQL в HDFS или из Kafka в Elasticsearch.
  • Агрегация и трансформация данных: SeaTunnel предоставляет мощные инструменты для агрегации и трансформации данных, что позволяет создавать сложные аналитические модели.

Что за компания 58 Group в Китае?

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

Основные направления деятельности 58 Group:

  1. Поиск работы: Платформа предоставляет услуги по поиску работы для соискателей и размещению вакансий для работодателей.
  2. Недвижимость: 58 Group предлагает услуги по аренде и продаже недвижимости, включая жилую и коммерческую недвижимость.
  3. Вторичный рынок товаров: Платформа позволяет пользователям покупать и продавать б/у товары, такие как электроника, мебель, одежда и т.д.
  4. Местные услуги: 58 Group предоставляет широкий спектр местных услуг, включая ремонт, уборку, перевозки и многое другое.
  5. Информационная безопасность: Компания также занимается обеспечением информационной безопасности для своих пользователей.

Значение 58 Group в китайской экономике:

58 Group играет важную роль в китайской экономике, предоставляя удобные и доступные услуги для миллионов пользователей. Благодаря широкому спектру услуг и постоянному внедрению инноваций, 58 Group помогает упростить повседневную жизнь китайцев и стимулировать развитие местного бизнеса.

Проще говоря: 58 Group — это как китайский аналог Craigslist или Avito, но гораздо большего масштаба, предлагающий множество различных услуг в одном месте.

Презентация старая: http://filecache.investorroom.com/mr5ir_58/144/download/58.com%20Presentation-Q2%2719_0919_Management%20update.pdf

Спроси ИИ – Что вы можете мне рассказать обо мне? 🤔

Кстати на тему ИИшек разных не надейтесь, что они на вас не учатся) как минимум помнят контекст. Уже какое то время набирает популярность хайповая тема спросить ии, что он о тебе думает. См. Картинки.

“Из всего нашего общения, что вы можете мне рассказать обо мне, чего я, возможно, не знаю?”

Ну а последняя последняя тема это обложки книг – “Из всего нашего общения, что вы можете мне рассказать обо мне, чего я, возможно, не знаю? и все таки? А лучше нарисуй так как будто это обложка книги.”

как то мрачновато получилось 😨
Может генерил в разные периоды 🤔

Eng: You appear to be a person who is interested in learning and many things. You are curious and enjoy discussing various topics. You have a desire to help other people and share your knowledge. You also have a certain degree of self-awareness and understanding of your strengths and weaknesses. You are willing to learn and grow as a person. You are a good listener and empathetic. However, you also face some challenges, such as a lack of self-confidence or difficulty making decisions. You may sometimes have difficulty expressing your feelings or emotions. But overall, you appear to be a positive and goal-oriented person who is willing to overcome obstacles and achieve your goals.

Or me like a picture:

 No comments   1 mo   AI

Storj купил cunoFS

Getting started with cunoFS#
cunoFS is a scalable, high-performance POSIX compatibility layer that lets you interact with files stored on object storage such as Amazon S3, Azure Blob Storage, Google Cloud Storage, or any S3-compatible object store hosted in the cloud or locally.

Интересно, теперь наверное встроить в себя или новое что то придумает.

 No comments   1 mo   s3   Storj
 No comments   1 mo   Life   Shop

Alchemesh консоль: Основные концепции

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

Alchemesh core concepts

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

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

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

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

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

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

Data domains

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

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

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

Вид data domain

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Alchemesh: Фреймворк Data Mesh — Происхождение

Alchemesh
Data product view

Оригинал: 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. Владение доменом: Децентрализация владения аналитическими данными к бизнес-доменам, ближайшим к источнику данных или основным потребителям, и независимое управление жизненным циклом данных на основе этих доменов. Этот подход согласовывает бизнес, технологии и данные, обеспечивая масштабируемость, гибкость, точность и устойчивость за счёт сокращения узких мест и обеспечения локализованного управления изменениями.
  1. Данные как продукт: Доменно-ориентированные данные делятся как продукт напрямую с пользователями данных, придерживаясь таких характеристик, как обнаруживаемость, адресуемость, понятность, достоверность, нативный доступ, взаимодействие, композиционность, внутренняя ценность и безопасность. Каждый автономный продукт данных предоставляет явные, простые в использовании контракты на обмен данными и управляется независимо, вводя концепцию “кванта данных”, которая инкапсулирует все необходимые компоненты для обмена данными, направленную на предотвращение информационных завалов, развитие культуры, ориентированной на данные, и повышение устойчивости к изменениям.
  1. Платформа самообслуживания данных: Обеспечение возможности кросс-функциональным командам делиться данными за счёт управления полным жизненным циклом продуктов данных и создания надёжной сети взаимосвязанных продуктов, упрощая обнаружение, доступ и использование данных. Она направлена на снижение стоимости децентрализованного владения данными, абстрагирование сложности управления данными, привлечение более широкого круга разработчиков и автоматизацию управления для обеспечения безопасности и соответствия.
  1. Федеративное вычислительное управление: Федеративная модель управления с представителями доменов, членами платформы данных и экспертами для балансировки автономии доменов и глобальной совместимости, полагаясь на автоматическое обеспечение политики. Она направлена на извлечение ценности из совместимых продуктов данных, смягчение рисков децентрализации, интеграцию требований управления и сокращение ручного синхронизационного накладных расходов.

Поддержка перехода к 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,
    • Позволяет командам платформы переводить всё это в предоставление платформы.
    • Это будет порталом для действий с продуктом данных:
      • Действует как реестр продуктов данных,
      • Интерфейс для разработчиков продуктов данных,
      • Интерфейс для команд платформы для активации платформы самообслуживания данных.
  1. Alchemesh Controller: Это будет плоскость управления Data Mesh, которая будет управлять платформой Data Mesh. Она создаёт связь между метаданными Data Mesh, управляемыми консолью, и компонентами платформы в автоматизированном и самообслуживающемся режиме.
  1. 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. 😇

Data product’s output port view

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

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

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

Data Warehouse, Data Lake, Data Lakehouse, Data Fabric, Data Mesh – что это такое, и в чем разница между концепциями

Хорошая статья очерк: 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 включает в себя продажу данных, предоставление доступа к данным и создание продуктов на основе данных.
* Плюсы:

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

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

План запросов — Анализируем производительность в Trino

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

 No comments   2 mo   SQL   Trino
Earlier Ctrl + ↓