Later Ctrl + ↑

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 принципах:

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

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

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

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

Поддержка перехода к 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 будет состоять из трёх слоёв:

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

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

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

No comments 2 mo Data Governance Data Mesh Open Source

Технологический ландшафт пространств данных – Антти Поикола (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

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

No comments 2 mo Data Data Governance Data Space

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)

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

2. Data Lake

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

3. Lakehouse

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

4. Data as a Code (DaaC)

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

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

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

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

No comments 2 mo Data Data Governance

План запросов — Анализируем производительность в 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

Птичка 🐦😁

No comments 2 mo Walking

Запуск Kafka на s3

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

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

No comments 2 mo Data Engineer Kafka

Нет, инженерам по обработке данных не НУЖЕН dbt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

fake_companies, fake_dates и fake_numbers
companies_base
employees_base
enterprise_orders_base

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No comments 2 mo Data Data Engineer Data Quality

Data Mesh & Data Fabric : лучше вместе!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команды Data Product:

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

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

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

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

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

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

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

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

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

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

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

No comments 2 mo Data Governance

Хроники Apache SeaTunnel

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

В общем знакомимся: https://seatunnel.apache.org Next-generation high-performance, distributed, massive data integration tool.

Вспомнил я его из за последнего релиза, где добавили LLM трансформер. А изначально была идея делать на нем синхронизацию данных из Кафки в s3 iceberg прямиком. Идея еще жива и потихоньку обрастает пылью. Но когда нибудь наступит час и все случится :) но не сегодня.

Пробуем записать файл 10gb в csv в s3:

Set the basic configuration of the task to be performed

Пишем конфигурацию:

env {
  parallelism = 1
  job.mode = "batch"
 # checkpoint.interval = 30000
 # checkpoint.timeout = 5000
}

# read csv
source {
  LocalFile {
  schema {
    fields {

vendorid	=	string
tpep_pickup_datetime	=	string
tpep_dropoff_datetime	=	string
passenger_count		=	string
trip_distance		=	string
ratecodeid		=	string
store_and_fwd_flag		=	string
pulocationid		=	string
dolocationid		=	string
payment_type		=	string
fare_amount		=	string
extra		=	string
mta_tax		=	string
tip_amount		=	string
tolls_amount		=	string
improvement_surcharge		=	string
total_amount		=	string


    }
  }
  path = "./2018_Yellow_Taxi_Trip_Data.csv"
  file_format_type = "csv"
  field_delimiter = ","
 # datetime_format = "dd/MM/yyyy hh:mm:ss"
  skip_header_row_number = 1

}
}


transform {

}

#  csv to iceberg  
sink {
  iceberg {
    catalog_name = "iceberg"
    iceberg.catalog.config={
      "type"="hive"
      "uri" = "thrift://metastore:9083"
      "warehouse"="s3a://test/iceberg_p_listner5_podman/"
    }
    hadoop.config={
      "fs.s3a.aws.credentials.provider" = "org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider"
      "fs.s3a.endpoint" = "gateway.storjshare.io"
      "fs.s3a.access.key" = "jvrKukurukutratatabq"
      "fs.s3a.secret.key" = "jzwnieshotutblablabla44imhhs"
      "fs.defaultFS" = "s3a://test/iceberg_p_listner5_podman/"
      "fs.s3a.impl"="org.apache.hadoop.fs.s3a.S3AFileSystem"
    }
    namespace = "my_schema_i"
    table = "taxi5"
    iceberg.table.write-props={
      write.format.default="parquet"
      write.parquet.compression-codec="snappy"
      write.target-file-size-bytes=136870912
    }
 #   iceberg.table.primary-keys="id"
#    iceberg.table.upsert-mode-enabled=true
 #   iceberg.table.schema-evolution-enabled=true
 #   case_sensitive=true
 #   result_table_name = "test_table"
 }
}

Запускаем конфигурацию:

./bin/seatunnel.sh --config ./config/V2.LLM.csv-ice1.config.template -m local

пьем чай пару минут

***********************************************
           Job Statistic Information
***********************************************
Start Time                : 2024-09-12 20:38:36
End Time                  : 2024-09-12 20:55:45
Total Time(s)             :                1028
Total Read Count          :           112234626
Total Write Count         :           112234626
Total Failed Count        :                   0
***********************************************

Готово.

Файл был про такси Нью Йорка

VendorID,tpep_pickup_datetime,tpep_dropoff_datetime,passenger_count,trip_distance,RatecodeID,store_and_fwd_flag,PULocationID,DOLocationID,payment_type,fare_amount,extra,mta_tax,tip_amount,tolls_amount,improvement_surcharge,total_amount
1,02/06/2018 02:05:59 PM,02/06/2018 02:13:00 PM,1,1.1,1,N,161,100,2,6.5,0,0.5,0,0,0.3,7.3
1,02/06/2018 02:33:25 PM,02/06/2018 02:43:47 PM,1,1.1,1,N,170,161,1,8,0,0.5,1.75,0,0.3,10.55
1,02/06/2018 02:46:31 PM,02/06/2018 02:53:13 PM,1,0.9,1,N,161,170,2,6.5,0,0.5,0,0,0.3,7.3
1,02/06/2018 02:55:34 PM,02/06/2018 03:13:34 PM,1,6.1,1,N,170,231,1,20.5,0,0.5,2,0,0.3,23.3
1,02/06/2018 02:00:41 PM,02/06/2018 02:16:07 PM,1,1.4,1,N,163,170,1,10.5,0,0.5,2.25,0,0.3,13.55
1,02/06/2018 02:24:55 PM,02/06/2018 02:31:25 PM,1,0.7,1,N,170,161,1,6,0,0.5,1,0,0.3,7.8
1,02/06/2018 02:37:16 PM,02/06/2018 02:53:57 PM,1,2.2,1,N,162,262,2,12.5,0,0.5,0,0,0.3,13.3
1,02/06/2018 02:57:05 PM,02/06/2018 03:10:26 PM,1,1.8,1,N,262,162,1,11,0,0.5,2.35,0,0.3,14.15
1,02/06/2018 02:01:55 PM,02/06/2018 02:04:56 PM,1,0.4,1,N,239,143,2,4,0,0.5,0,0,0.3,4.8
и так далее до 112 234 626 строки

В Трино все хорошо

Строки есть

Каунты хорошие

Но пришлось немного подрулить java в файле ./config/jvm_client_options

# JVM Heap
-Xms556m
-Xmx1512m

Задание после этого шло более стабильно.

Промежуточный контрольный лог выглядит норм:

2024-09-12 20:53:16,054 INFO  [c.h.i.d.HealthMonitor         ] [hz.main.HealthMonitor] - [localhost]:5801 [seatunnel-872250] [5.1] processors=6, physical.memory.total=14.5G, physical.memory.free=419.0M, swap.space.total=0, swap.space.free=0, heap.memory.used=1.0G, heap.memory.free=437.8M, heap.memory.total=1.4G, heap.memory.max=1.4G, heap.memory.used/total=70.25%, heap.memory.used/max=70.25%, minor.gc.count=5327, minor.gc.time=32576ms, major.gc.count=7, major.gc.time=677ms, load.process=40.78%, load.system=41.68%, load.systemAverage=2.35, thread.count=151, thread.peakCount=163, cluster.timeDiff=0, event.q.size=0, executor.q.async.size=0, executor.q.client.size=0, executor.q.client.query.size=0, executor.q.client.blocking.size=0, executor.q.query.size=0, executor.q.scheduled.size=0, executor.q.io.size=0, executor.q.system.size=0, executor.q.operations.size=0, executor.q.priorityOperation.size=0, operations.completed.count=764, executor.q.mapLoad.size=0, executor.q.mapLoadAllKeys.size=0, executor.q.cluster.size=0, executor.q.response.size=0, operations.running.count=0, operations.pending.invocations.percentage=0.00%, operations.pending.invocations.count=0, proxy.count=10, clientEndpoint.count=1, connection.active.count=0, client.connection.count=0, connection.count=0

Важно добавить:
Задание падало не ясно почему. Хазлкаст куда-то девался и писал проблемы с тайм-аутами.
тут все изложил, но пока все описывал нашел ошибки. https://github.com/apache/seatunnel/issues/7650

Писал слишком маленькие файлы и накосячил с полями, они оказывается чувствительные к регистру.

А еще заметил, что когда задание падает, то Селесты в трико не проходят. Точнее показывают пустую таблицу, но вот в s3 файлы есть. Команда optimize ничего не дает, все равно остаются.

в итоге пока не нашел как почистить ошибочные файлы.

а вот еще пример с моделью llm gpt4o. Для доступа к api я использовать сервис http://proxyapi.ru – вроде не очень дорого и удобно платить с России и расходовать по мере использования. Еще пользуюсь этим http://openrouter.ai там большое моделей, но платить чуть сложнее, можно криптой оплатить.

И так, вот пример конфига:

# Set the basic configuration of the task to be performed111
env {
  parallelism = 1
  job.mode = "batch"
 # checkpoint.interval = 30000
 # checkpoint.timeout = 5000
}

# Create a source to connect to Clickhouse
source {
  Clickhouse {
    host = "some-clickhouse-server:8123"
    database = "default"
    sql = "select * from test_table"
    username = ""
    password = ""
    server_time_zone = "UTC"
  #  result_table_name = "test_table"
    clickhouse.config = {
      "socket_timeout": "300000"
    }
  }
}


transform {
  LLM {
    model_provider = OPENAI
    model = gpt-4o
    api_key = sk-GIkitutblablabalkakayatoest5D33l5a
    prompt = "Determine whether someone is Chinese, American or Russian, give a feedback in json string with quatation"
    openai.api_path  = "https://api.proxyapi.ru/openai/v1/chat/completions"
    output_data_type = "STRING"
    
  }
}

# Console printing of the read Clickhouse data
sink {
  iceberg {
    catalog_name = "iceberg"
    iceberg.catalog.config={
      "type"="hive"
      "uri" = "thrift://metastore:9083"
      "warehouse"="s3a://test/iceberg_p_listner5_podman/"
    }
    hadoop.config={
      "fs.s3a.aws.credentials.provider" = "org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider"
      "fs.s3a.endpoint" = "gateway.storjshare.io"
      "fs.s3a.access.key" = "jvr2blablablayjrbq"
      "fs.s3a.secret.key" = "jzwnleotuteshokayayatohrenbilaqskh3323imhhs"
      "fs.defaultFS" = "s3a://test/iceberg_p_listner5_podman/"
      "fs.s3a.impl"="org.apache.hadoop.fs.s3a.S3AFileSystem"
    }
    namespace = "my_schema_i"
    table = "test_table6"
    iceberg.table.write-props={
      write.format.default="parquet"
      write.parquet.compression-codec="snappy"
      write.target-file-size-bytes=536870
    }
    iceberg.table.primary-keys="id"
    iceberg.table.upsert-mode-enabled=true
    iceberg.table.schema-evolution-enabled=true
    case_sensitive=true
 #   result_table_name = "test_table"
 }
}

Таблица в клике была такая:

схемка эта:

CREATE TABLE default.test_table
(
    `id` Int32,
    `name` String
)
ENGINE = MergeTree
ORDER BY id
SETTINGS index_granularity = 8192
......
insert into  `default`.test_table values (7, 'Petya')
insert into  `default`.test_table values (8, 'Dasha')
insert into  `default`.test_table values (9, 'Dima')
insert into  `default`.test_table values (10, 'Tony')
insert into  `default`.test_table values (11, 'Fekla')
insert into  `default`.test_table values (12, 'Jekie Chan')
insert into  `default`.test_table values (13, 'ben')
insert into  `default`.test_table values (14, 'Howard')
insert into  `default`.test_table values (16, 'Semen')
insert into  `default`.test_table values (17, 'Katya')
insert into  `default`.test_table values (18, 'Kostya')
insert into  `default`.test_table values (19, 'Natasha')
insert into  `default`.test_table values (20, 'Tonya')
insert into  `default`.test_table values (21, 'Tanya')
.....

Что выходит в итоге:

Данные были прочитаны из clickhouse и отправлены в модель построчно.
Модель ответила и заполнила колонку llm_outputю.

2024-09-12 21:47:12,075 INFO  [s.c.s.s.c.ClientExecuteCommand] [main] - 
***********************************************
           Job Statistic Information
***********************************************
Start Time                : 2024-09-12 21:46:33
End Time                  : 2024-09-12 21:47:12
Total Time(s)             :                  38
Total Read Count          :                  21
Total Write Count         :                  21
Total Failed Count        :                   0
***********************************************

В общем если хотите пробуйте SeaTunnel. Норм работает и качество улучшается.
Iceberg например не получалось у меня загрузить в прошлой версии 2.3.7, пришлось собрать свежую по рекомендации. в Ней еще надо было добавить пару либ. Они не все нужны, но обязательны для hive внизу плагины hive-exec-3.1.3.jar и libfb303-0.9.3.jar, ну и рабочая либа seatunnel-hadoop3-3.1.4-uber.jar из за которой как раз и пришлось все собирать вручную.

No comments 3 mo big data Data Engineer Data Mesh

Портал продуктов данных: интеграция с вашей платформой данных

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

Пример интерфейса портала продуктов данных

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

Пример в этом блоге основан на AWS. В будущих версиях портала продуктов данных мы планируем добавить поддержку других платформ данных, таких как Databricks, Snowflake, Azure и других. Будем рады вашим вкладам, если вы хотите ускорить разработку!

Концепции портала продуктов данных

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

Как продукты данных взаимодействуют друг с другом

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

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

Как портал стремится объединить платформы данных, управление и людей в единое понятие

Концепции интеграции

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

Концепция интеграции на высоком уровне

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

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

Команды платформ данных могут писать свою собственную логику конфигурации на основе этих концепций, но они также могут использовать логику конфигурации по умолчанию, предоставляемую порталом продуктов данных и написанную в Terraform. С логикой конфигурации по умолчанию мы предлагаем интеграции с AWS и Conveyor из коробки, но намерены расширять эти интеграции для Databricks, Azure, Snowflake, Tableau, Collibra и других релевантных инструментов.

Шаги интеграции

Если вы хотите использовать интеграцию по умолчанию с AWS с использованием terraform, предоставленную порталом продуктов данных, вы можете сделать это, выполнив следующие шаги. Больше информации доступно в нашем репозитории open source.

Заключительные мысли

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

Перевод: https://medium.com/conveyordata/data-product-portal-integrating-with-your-data-platform-41bf9fcf1fc1

No comments 3 mo Data Governance Data Mesh

Airflow 2.10

Введение

Саммит Airflow не за горами (10–12 сентября), и поэтому время было идеальным для нового важного релиза Airflow. Этот минорный релиз, “2.10”, не разочаровывает, и эта короткая статья расскажет о основных функциях и исправлениях, представленных в этом релизе. Если вы хотите изучить все, что предлагает Airflow 2.10, эта статья для вас.

Датасеты в Airflow

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

Динамическое определение датасета

Алиасы датасетов могут использоваться для генерации событий датасета с ассоциацией с алиасами. DAG’и на нижних уровнях могут зависеть от разрешённых датасетов. Эта функция позволяет определять сложные зависимости для выполнения DAG’ов на основе обновлений датасетов.

Представьте, что у вас есть задача, которая генерирует выходные файлы в S3-хранилище, причём расположение этих файлов зависит от даты выполнения (ds). Ранее вам необходимо было определять датасет статически, но с новым DatasetAlias вы можете динамически создавать путь к датасету на основе контекста выполнения:

@task(outlets=[DatasetAlias("my-task-outputs")])
def my_task_with_outlet_events(*, ds, outlet_events):
    outlet_events["my-task-outputs"].add(Dataset(f"s3://bucket/my-task/{ds}"))

@task(outlets=[DatasetAlias("my-task-outputs")])
def my_task_with_metadata(*, ds):
    s3_dataset = Dataset(f"s3://bucket/my-task/{ds}")
    yield Metadata(s3_dataset, extra={"k": "v"}, alias="my-task-outputs")

Датасеты больше не активируют неактивные DAG’и

Ранее, когда DAG был приостановлен или удалён, входящие события датасета всё равно активировали его, и DAG запускался, когда он был возвращён из паузы или добавлен обратно в файл DAG’а. Это было изменено; теперь расписание датасета DAG’а может быть выполнено только событию, которое произошло во время активного состояния DAG’а.

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

Обновление в представлении датасетов

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

Ключевые улучшения:

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

Карточки с информацией о событиях: вместо простой таблицы, события датасетов теперь отображаются в виде карточек с подробной информацией об источнике события, запусках на нижних уровнях и связанными метаданными. Этот более богатый дисплей предоставляет лучшее представление с первого взгляда.
Вкладочный интерфейс: новый интерфейс организует информацию по вкладкам, включая события датасетов, детали, список датасетов и графическое представление. Это разделение позволяет пользователям сосредоточиться на определённом аспекте интересующих их датасетов, без излишней информации.
Навигация с помощью “хлебных крошек”: внедрение навигации с помощью “хлебных крошек” улучшает пользовательский опыт, ясно показывая выбранный датасет или событие, что упрощает перемещение вперёд и назад между представлениями.
Более насыщенные детали датасета: вкладка с деталями датасета теперь включает более полную информацию, такую как дополнительные метаданные, DAG’и-потребители и задачи-производители.Этот уровень детализации помогает пользователям понять полный жизненный цикл своих датасетов.

Гибридные экзекьюторы

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

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

Чтобы определить экзекьютор для задачи, используйте параметр “executor” в операторах Airflow:

BashOperator(
    task_id="hello_world",
    executor="LocalExecutor",
    bash_command="echo 'hello world!'",
)

Тёмный режим

Мы ждали до версии 2.10, чтобы в Airflow появился тёмный режим. “Всё приходит к тем, кто умеет ждать”, как говорится в пословице. Ну, не о чем больше говорить о этой очевидной функции, и далее приведён скриншот этого тёмного режима:

Вы можете переключать тёмный/светлый режим, нажав на значок полумесяца справа от панели навигации.

Новый метод “concat()”

Значительное дополнение — введение метода concat() для объектов XComArg. Эта новая функция улучшает способ манипуляции и объединения данных, передаваемых между задачами в DAG, делая процесс более эффективным и менее ресурсоёмким.

Метод concat() позволяет пользователям объединять несколько ссылок XComArg в один объект XComArg. Этот метод особенно полезен, когда нужно выполнить операцию на нескольких списках или последовательностях элементов, не создавая дополнительных задач в вашем DAG. По сути, concat() работает как itertools.chain в Python, но с дополнительным преимуществом поддержки доступа по индексу к объединённым результатам.

Когда вы вызываете concat() на объекте XComArg, он объединяет его с одним или несколькими другими объектами XComArg, создавая новый объект ConcatXComArg. Этот объект ведёт себя как последовательность, к которой можно получить доступ, используя индексы, что упрощает работу с объединёнными данными, как если бы это был один список или словарь.

Например, если у вас есть два или более XComArg, представляющие списки файлов, вы теперь можете объединить их и затем обработать объединённый список в задаче нижнего уровня, без необходимости вручную объединять списки в отдельной задаче. Это не только упрощает DAG, но также экономит ресурсы, уменьшая количество данных, хранимых в XCom, и объём памяти, необходимый для выполнения задач.

Новые разрешения на уровне DAG

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

В предыдущих версиях Airflow, access_control позволял role-based access management (RBAC) на уровне DAG, но детализация разрешений была ограничена. С новыми обновлениями в версии 2.10, разрешения теперь могут быть назначены не только для DAG’ов в целом, но также для конкретных действий внутри этих DAGов, таких как создание и удаление DAG посещений.

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

with DAG(
    'tutorial',
    ...
    access_control={
        'User': {
            'DAG Runs': {'can_create'}
        }
    }
) as dag:

В этом случае пользователям с ролью “User” предоставляется разрешение создаватирибовать выполнения DAG для DAG tutorial, но не обязательно удалять сам DAG.

with DAG(
    'tutorial2',
    ...
    access_control={
        'User': {'can_delete'}  # Старый стиль: {'DAGs': {'can_delete'}}
) as dag:

Здесь пользователи с ролью “User” могут удалить DAG tutorial2, демонстрируя возможность применения разрешений как на уровне DAG, так и на уровне DAG Run.

UI с выключением кнопок с работающими функциями delete и trigger, когда это разрешено:

Jinja-шаблонизация с ObjectStoragePath

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

Например, теперь вы можете определить ObjectStoragePath следующим образом:

path = ObjectStoragePath("s3://my-bucket/data/{{ ds }}/{{ task_id }}.csv")

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

Цвета для строк логов в UI для ошибок и предупреждений

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

Новые декораторы run_if и skip_if

Airflow 2.10 вводит декораторы run_if и skip_if, предоставляя более краткий и читаемый способ коэффического выполнения или пропуска задач в DAG. Эти декораторы работают как синтаксический сахар, упрощая логику задания выполнения задач на основе конкретных условий.

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

Вот пример, как использовать декоратор run_if:

from __future__ import annotations

from pendulum import datetime

from airflow.decorators import dag, task


@dag(start_date=datetime(2022, 1, 1), schedule=None, catchup=False)
def condition_sample():
    @task.run_if(lambda context: context["task_instance"].task_id.endswith("_do_run"))
    @task.bash()
    def echo() -> str:
        return "echo 'run'"

    echo.override(task_id="echo_do_run")()
    echo.override(task_id="echo_do_not_run")()


condition_sample()

В этом примере DAG задача echo выполнится только если её task_id оканчивается на _do_run. Декоратор run_if оценивает условие, и если оно True, задача выполняется; в противном случае она пропускается.

Заключение

Каждые 4-5 месяцев Airflow выпускает новую минорную версию, и это действительно захватывающее нововведение, чтобы увидеть, как много усилий прикладывается для постоянного улучшения этого отличного инструмента оркестрации с открытым исходным кодом. Сила Airflow заключается в его сильном сообществе и стремлении сделать продукт всегда лучше. Этот релиз пошёл в этом направлении, и компаниям не стоит ждать, чтобы мигрировать на эту новую версию, поскольку новые функции могут значительно упростить/улучшить ваши текущие/новые DAGи и общее управление Airflow.

Благодарность

Если вы с удовольствием прочли эту статью, следите за обновлениями, поскольку мы регулярно публикуем технические статьи об Airflow и Data Stack в целом. Подписывайтесь на Astrafy в LinkedIn, Medium и Youtube, чтобы быть в курсе выхода следующей статьи.

Если вам нужна поддержка по Airflow или вашему Data Stack в целом, не стесняйтесь обращаться к нам по адресу sales@astrafy.io.

перевод: https://medium.astrafy.io/airflow-2-10-is-just-wow-cde50c20553e

No comments 3 mo big data Data Data Engineer Open Source

Databricks открыли код Unity Catalog

Знали ли вы, что Databricks открыли код Unity Catalog? Если нет, вас можно понять. В конце концов, в ту же неделю, когда это было объявлено на Databricks Data + AI Summit, новостной цикл был заполнен новостями об их приобретении компании Tabular. Несмотря на то, что Tabular привлекло всеобщее внимание, оба этих решения взаимосвязаны. Это намекает на более фундаментальный сдвиг в направлении Databricks, который изменит как сферу open source, так и коммерческий ландшафт для данных и ИИ.

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

Поговорим о Tabular

Прежде чем углубиться в ситуацию с Unity Catalog, нам нужно обсудить приобретение Tabular. Как это связано с Unity Catalog? Здесь важны три основные вещи:

Борьба за право покупки Tabular
Влияние на Apache Iceberg
Будущее открытых lakehouse-хранилищ данных

Борьба за право покупки Tabular

Много можно сказать о процессе приобретения Tabular, но стоит сфокусироваться на участниках этого процесса. Databricks были не единственными, кто делал ставки на Tabular. На самом деле, учитывая, что Tabular была продана за более чем $1 миллиард, ясно, что интерес к компании был высок и хорошо финансирован. Особенно в конкуренции выделялась компания Snowflake, еще один лидер в области аналитики. В сочетании с уже серьезными техническими инвестициями в Iceberg со стороны Databricks и Snowflake и их анонсами на саммитах Unity Catalog и Polaris, мы наблюдаем серьезные изменения в пространстве lakehouse и open source. Это будет продолжать оказывать эффект домино. Где идут Databricks и Snowflake, туда пойдет и весь остальной рынок аналитики.

Какое будущее у Apache Iceberg?

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

Теперь, под управлением Databricks, будущее менее определенно. Пока нет оснований считать, что Databricks не станет хорошим управляющим для усилий Tabular до приобретения, они покупали Tabular ради бизнес-решений, а не из альтруистических побуждений. Как только деятельность Tabular в отношении Iceberg перестанет быть необходимой, сложно предсказать, что сделает Databricks. Однако одно можно сказать точно: в отличие от Tabular, Databricks не имеет неразрывной связи с Apache Iceberg.

Хорошие новости для открытых вычислений

Однако, это не все пессимистично и неопределенно. Тот факт, что Databricks владеет Tabular, действительно запутывает фокус Tabular на Iceberg, но это также означает, что у Databricks есть еще больший интерес в поддержке Iceberg и открытой экосистемы lakehouse, проект которой они помогают развивать. Если что-то и изменится, то теперь у команды Tabular будет больше ресурсов для укрепления Iceberg в будущем. Это еще больше повысит жизнеспособность концепции открытого lakehouse.

Каждый из этих моментов важен, но вместе они показывают, что между гигантами рынка аналитики разворачивается конкуренция, связанные с возможностями роста в пространстве lakehouse. То, насколько эти события переплетены с open source, добавляет интриги. Это особенно явно в недавних объявлениях о переходе к открытым исходным кодам Unity Catalog и Polaris.

Matei Zaharia, CTO Databricks, объявляет о версии Unity Catalog с открытым исходным кодом на Databricks Data + AI Summit 2024

Конкурирующие объявления: Unity Catalog против Polaris

Вот интересный факт: конференции Snowflake Summit и Databricks Data + AI Summit часто пересекаются, и в этом году Databricks заранее решили провести свою конференцию в другое время, чтобы избежать деления внимания СМИ и рынка. Это имеет смысл. Эти конференции предназначены для большого количества анонсов, сосредоточенных на максимально возможном освещении новостей, которые важны для этих компаний.

Обе компании сделали значимые объявления, сигнализируя о будущем открытых lakehouse-хранилищ данных: Unity Catalog стал open source, и Snowflake сделала то же самое с Polaris. Если связать это с борьбой за Tabular, которая завершилась в течение двух недель обеих конференций, то можно увидеть некоторое соответствие в стратегических видениях обеих компаний.

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

Новая эра для открытых lakehouse-хранилищ

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

Почему Databricks сделал Unity Catalog open source

Собирая вышеперечисленные пункты, становится проще понять, почему Databricks решили открыть исходный код и передать Unity Catalog:

Сигнализация правильного времени для инвестиций в lakehouse: Databricks и Snowflake фактически сигнализируют, что пришло время для lakehouse. Увеличенные инвестиции от этих гигантов подчеркивают ценность архитектуры lakehouse, предоставляющей пользователям выбор без привязки к поставщику. Форматы файлов и таблиц с открытым исходным кодом уже стали стандартом, и каталоги данных оставались последним фронтом, где пользователи могли столкнуться с ограничениями. Открывая исходный код Unity Catalog, Databricks делают важный шаг к устранению этой проблемы.
Зрелость пространства lakehouse: Переход к открытому исходному коду Unity Catalog также показывает, что пространство lakehouse достигло уровня зрелости, который оправданно привлекает более крупные инвестиции. Эта зрелость касается не только технологии, но и экосистемы разработчиков, инструментов и пользователей, которые теперь могут вносить вклад и получать выгоду от инноваций с открытым исходным кодом.

Что дальше для Unity Catalog

Переход Unity Catalog на open source отмечает значительный этап, но это также вызывает вопрос: что будет дальше? Ответ лежит в расширении экосистемы решений, которые уже поддерживают видение Unity Catalog с открытым исходным кодом. Раннее принятие ведущими игроками свидетельствует о многообещающем будущем для архитектуры open lakehouse.

Архитектурные опции Unity Catalog

Многие заметные компании выразили поддержку Unity Catalog OSS, включая AWS, Nvidia, Confluent, LanceDB, StarRocks и многих других. Эти организации признают ценность открытой системы каталогов и готовы интегрироваться и инновационно развивать это основание.

Что делать с этой информацией?

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

С чего начать? Начните свое расследование с движков запросов для lakehouse. От Apache Iceberg до Unity Catalog большинство производительности зависит от выбора правильного движка. Для этого вам следует обратить внимание на StarRocks и присоединиться к Slack StarRocks, чтобы получить все советы от сообщества, которые помогут вам ориентироваться в этой новой эре для открытых lakehouse.

Перевод: https://medium.com/starrocks-engineering/why-did-databricks-open-source-unity-catalog-b228bd9be367

No comments 3 mo big data Data Data Engineer

DuckDB + Attached postgres

Давно уже прошел вебинар про DuckDB, а я еще обещал ответить на вопросы.
Один из них был про работу с postgres. Напомню, что DuckDB это встраиваемая аналитическая база данных.
т.е. Так как она встраиваемая и уже встроена в DBeaver, то пробовать я это буду именно там. И так приступим.

Создаю новую утиную базу

База пока пустая

Надо бы что то в ней создать. Сделаем пару insert и подключим внешний каталог Postgres.
Базу Postgres я подниму локально в Docker этой командой

docker run --name some-postgres -p 5432:5432 -e POSTGRES_PASSWORD=mysecretpassword -d postgres

Так как она тоже пустая там понадобятся insert. А еще я хотел попробовать прочитать данные DuckDB с s3 и записать их через подключенный postgres прямо в него. Ну например данные такси нью йорка, там где-то 2 гигабайта, будет хороший кейс нагрузки.

Запускаю Postgres

docker run --name some-postgres -p 5432:5432 -e POSTGRES_PASSWORD=mysecretpassword -d postgres

Подключаю бобра.

Теперь сделаем табличку и запишем туда пару

CREATE TABLE public.test (
  a bigint,
  b varchar,
  c float,
  cdate date
) 

INSERT INTO public.test VALUES (1,'hello', 1.24, now());
INSERT INTO public.test VALUES (2,'hello', 2.24, now());
INSERT INTO public.test VALUES (3,'hello', 3.24, now());
INSERT INTO public.test VALUES (4,'hello', 4.24, now());
INSERT INTO public.test VALUES (5,'hello', 5.24, now());
INSERT INTO public.test VALUES (6,'hello', 6.24, now());
INSERT INTO public.test VALUES (7,'hello', 7.24, now());
INSERT INTO public.test VALUES (8,'hello', 8.24, now());
INSERT INTO public.test VALUES (9,'hello', 9.24, now());

отлично

Возвращаемся в утку и будем настраивать.

Установим для начала плагины

INSTALL postgres;
LOAD postgres;

Судя по документации можно использоваться простую команду для локального postgres

ATTACH '' AS postgres_db (TYPE POSTGRES);

Но я решил использовать чуть подробное описание с параметрами.

ATTACH 'dbname=postgres user=postgres host=127.0.0.1 password=mysecretpassword port=5432' AS db (TYPE POSTGRES);

Дополнительные параметры можно узнать из доки тут https://duckdb.org/docs/extensions/postgres

Делаю SHOW ALL TABLES и вижу что то уже из Утки.

Пробуем сделать Select и кстати в дереве каталогов уже появилась моя табличка.

select * from db.public.test t

Класс, работает.

можно даже скопировать всю таблицу в утку из postgres.

Теперь попробуем пример из вебинара, прочитать данные с s3 уткой и записать их в Postgres.

Настраиваю s3:

INSTALL httpfs;
LOAD httpfs;

CREATE SECRET secret1 (
    TYPE S3,
    KEY_ID 'jvvgблаблачтотоещеjuma',
    SECRET 'jyehmo3kfитуткакаятофигняещеmikcfak3v4lv6',
    ENDPOINT 'gateway.storjshare.io'
);

Работает.

ну и пробуем писать в postgres.

CREATE table db.public.test2 as SELECT * FROM read_parquet('s3://duckdb/parquettest/tos4.parquet');

Сходу не получилось

Ошибка:

SQL Error: Invalid Error: Failed to prepare COPY "
	COPY (SELECT "City", "count_star()", "Sum" FROM "public"."test2" WHERE ctid BETWEEN '(0,0)'::tid AND '(4294967295,0)'::tid) TO STDOUT (FORMAT binary);
	": ERROR:  column "City" does not exist
LINE 2:  COPY (SELECT "City", "count_star()", "Sum" FROM "public"."t...
                      ^
HINT:  Perhaps you meant to reference the column "test2.city".

Попробуем чуть попроще типы указать и наименования полей. Вдруг поможет. Для начала так:

SELECT City, "count_star()" Cnt, ceiling(Sum) Sum FROM read_parquet('s3://duckdb/parquettest/tos4.parquet');

Запрос отработал, но это пока еще ничего не значит.

Пробуем select но он не хочет.

SQL Error: Invalid Error: Failed to prepare COPY "
	COPY (SELECT "City", "Cnt", "Sum" FROM "public"."test3" WHERE ctid BETWEEN '(0,0)'::tid AND '(4294967295,0)'::tid) TO STDOUT (FORMAT binary);
	": ERROR:  column "City" does not exist
LINE 2:  COPY (SELECT "City", "Cnt", "Sum" FROM "public"."test3" WHE...
                      ^
HINT:  Perhaps you meant to reference the column "test3.city".

А если через COPY? Тоже не получилось, написал что то такое.

copy (SELECT City, "count_star()" Cnt, ceiling(Sum) Sum FROM read_parquet('s3://duckdb/parquettest/tos4.parquet')) TO db.public.test4


SQL Error: java.sql.SQLException: Parser Error: syntax error at or near "."
org.jkiss.dbeaver.model.sql.DBSQLException: SQL Error: java.sql.SQLException: Parser Error: syntax error at or near "."
	at org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.executeStatement(JDBCStatementImpl.java:133)
	at org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.executeStatement(SQLQueryJob.java:615)
	at org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.lambda$2(SQLQueryJob.java:506)
	at org.jkiss.dbeaver.model.exec.DBExecUtils.tryExecuteRecover(DBExecUtils.java:192)
	at org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.executeSingleQuery(SQLQueryJob.java:525)
	at org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.extractData(SQLQueryJob.java:977)
	at org.jkis

А вот первый пример заработает как-то))

select * from db.public.test2

Пробуем еще раз:

CREATE table db.public.test5 as SELECT City, "count_star()" Cnt, ceiling(Sum) Sum FROM read_parquet('s3://duckdb/parquettest/tos4.parquet');

ошибка на select * from db.public.test5

SQL Error: Invalid Error: Failed to prepare COPY "
	COPY (SELECT "City", "Cnt", "Sum" FROM "public"."test5" WHERE ctid BETWEEN '(0,0)'::tid AND '(4294967295,0)'::tid) TO STDOUT (FORMAT binary);
	": ERROR:  column "City" does not exist
LINE 2:  COPY (SELECT "City", "Cnt", "Sum" FROM "public"."test5" WHE...
                      ^
HINT:  Perhaps you meant to reference the column "test5.city".

Хм)) ну как то же db.public.test2 заполнилась. Какая-то магия. Еще пока неизвестная.

Попробуем с того как начинали, но пока никак.

Кстати вот так работает: COPY db.public.test7 FROM ‘s3://duckdb/parquettest/tos4.parquet’;
Но прочитать таблицу все равно не дает.

Ну а вот и сама магия.

Если зайти в сам постгрес, то все Талицы на месте. и даже данные там есть.

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

Ну да, так и получилось

В общем вариант рабочий, но есть еще баги. Ждем фиксов.
Ну а следующий вебинар сделаю про “УТИлизацию Табло” – Будем готовить утку с Табло в s3шном соусе. :))

таблица большая в итоге загрузилась с s3.

Долго было

No comments 3 mo big data Data Data Engineer

Earlier Ctrl + ↓

Your password

Предисловие

Резюме

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

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

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

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

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

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

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

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

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

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

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

Set the basic configuration of the task to be performed