Yuriy Gavrilov: posts tagged Data Governance

Мир без Kafka: Почему Kafka не подходит для аналитики реального времени, что идет на смену)

Thu, 12 Feb 2026 13:50:00 +0300

Статья описывает переход от традиционных систем обмена сообщениями, таких как Apache Kafka, к специализированным решениям для потоковой аналитики, таким как Apache Fluss.

Основные тезисы:

Проблема Kafka: Kafka — это система хранения на основе *записей* (record-based), не имеющая нативной поддержки схем и аналитических возможностей. Это приводит к избыточному чтению данных и перегрузке сети при аналитических запросах, когда нужны только конкретные колонки, а не всё сообщение целиком.
Эволюция требований: Рынок перешел от простого перемещения данных (ingestion) к сложной аналитике реального времени и AI, что требует более эффективного хранения и доступа к данным.
Решение (Apache Fluss):
- Табличная структура:** Данные хранятся как таблицы (Log Tables для логов и PK Tables для изменяемых данных), что обеспечивает строгую типизацию.
- Колоночное хранение:** Использование формата Apache Arrow позволяет читать только нужные колонки (projection pushdown) и эффективнее сжимать данные, что снижает нагрузку на диск и сеть.
- Интеграция с Lakehouse:** Fluss нативно поддерживает многоуровневое хранение (горячие данные в Fluss, теплые/холодные в S3/Iceberg/Paimon) без лишнего копирования, обеспечивая прозрачный доступ к историческим и оперативным данным.
Вывод: Fluss в связке с Flink предлагает более дешевую, быструю и удобную архитектуру для современной аналитики реального времени, устраняя недостатки Kafka в этой области.

Ссылка на оригинал:
Why Kafka Falls Short for Real-Time Analytics (and What Comes Next

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

Во время перехода от пакетной обработки к потоковой передаче данных в реальном времени значительное внимание и импульс получил проект с открытым исходным кодом, разработанный внутри LinkedIn: Apache Kafka. Цель состояла в том, чтобы упростить перемещение данных из точки А в точку Б масштабируемым и устойчивым способом, используя модель издатель/подписчик. Kafka позволила компаниям создавать ранние конвейеры потоковой передачи данных и открыть новый класс событийно-ориентированных сценариев использования. Постоянно растущая экосистема коннекторов и интеграций ускорила внедрение и утвердила Kafka в качестве предпочтительного слоя потокового хранения. Однако, по мере того как архитектуры аналитики реального времени эволюционировали за пределы простого приема данных (ingestion), ограничения Kafka для аналитических нагрузок становились всё более очевидными.

С архитектурной точки зрения Kafka — это не аналитический движок. Это устойчивая и масштабируемая система хранения на основе записей (record-based storage system) для свежих данных в реальном времени — часто называемая «горячим слоем». Следовательно, аналитические нагрузки должны выполняться за пределами кластера Kafka, постоянно перемещая данные между системами хранения и обработки, что увеличивает сетевой трафик и накладные операционные расходы. Кроме того, Kafka нативно не обеспечивает соблюдение схем для данных, публикуемых в топиках.

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

И последнее, но не менее важное (и, возможно, самый важный аспект): Kafka — это система хранения на основе записей. Это хорошо подходит для использования в качестве очереди сообщений, например, для приема данных в реальном времени или событийно-ориентированных архитектур, но имеет значительные ограничения при решении текущих и будущих задач проектов реального времени. Движки обработки, такие как Spark и Flink, должны потреблять все данные топика, даже если требуется только часть данных события (столбцы). Результатом является ненужный сетевой трафик, снижение производительности обработки и чрезмерные требования к хранилищу.

Компоненты потокового хранения на основе записей по-прежнему будут занимать свое место в архитектуре данных. Такие решения, как Kafka и Pulsar, хорошо подходят для случаев, требующих чтения полных записей. Архитектурные паттерны, основанные на микросервисах, могут использовать вышеуказанные решения для обмена данными, отделяя функции от транспортировки сообщений для повышения производительности, надежности и масштабируемости. Чтение полных записей также полезно для конвейеров приема данных (ingestion pipelines), в которых данные будут храниться в системах долгосрочного хранения, таких как объектное хранилище (Object Storage), для исторических и архивных целей. Узкие места и ограничения возникают, когда они используются для аналитических нагрузок, требующих возможностей, выходящих за рамки простого слоя транспорта данных.

Эволюция потоковых данных

Сегодняшний разговор движим единственным аспектом: Эволюция. Другими словами, новые потребности требуют новых подходов к управлению данными. Kafka удовлетворила первоначальные потребности в потоковой передаче данных. В этой первой волне в основном доминировали конвейеры приема данных в реальном времени и дискретная (SEP, Simple Event Processing) аналитика. По сути, способность перемещать данные из точки А в точку Б и, в некоторых случаях, выполнять простую подготовку и обработку данных между ними. Kafka, в сочетании со Spark Streaming или специальными коннекторами, справлялась с этими ранними сценариями использования.

Перенесемся вперед: вторая волна привнесла сложность в потоковый конвейер. Помимо дискретной подготовки данных, сценарии использования на этом этапе требовали расширенных аналитических функций, таких как агрегация, обогащение и сложная обработка событий (CEP). Микро-батчинг (micro-batching) оказался недостаточным. Требуется новый архитектурный подход, основанный на колоночном хранении с эффективным проталкиванием проекций (projection pushdown) и прозрачным многоуровневым хранением данных (data tiering), в сочетании с движками обработки с задержкой менее секунды. `Apache Fluss` и `Apache Flink` могут выполнить это обещание и вместе составляют будущее и третью волну по шкале зрелости.

Каждая техническая статья сегодня упоминает AI/ML. Эта эволюция «третьей волны» позволяет компаниям создавать AI-конвейеры реального времени, которые внедряют передовые аналитические методы (такие как Generative AI) в потоковые данные. Это увеличивает потребность в современных системах хранения данных в реальном времени с расширенными функциями, которые распределяют данные как по быстрым потоковым, так и по историческим слоям, обеспечивая интегрированный, унифицированный доступ к бизнес-данным.

Новичок на районе

`Apache Fluss` — это современная система хранения потоковых данных в реальном времени для аналитики. Она консолидирует многолетний опыт и уроки, извлеченные из предшественников, отвечая текущим и будущим потребностям организаций. Fluss родился в эпоху, когда для питания моделей машинного обучения требуется больше данных, Лейкхаусы (Lakehouses) являются частью корпоративной экосистемы, а облачная инфраструктура является предпочтительной стратегией для компаний.

Но хранение данных — это лишь часть архитектурной головоломки. `Apache Flink` предоставляет возможности и устойчивость для обработки огромных объемов данных в реальном времени с задержкой менее секунды, обеспечивая скорость, необходимую для будущих потоковых приложений. Не ограничиваясь Flink, дополнительные движки обработки и библиотеки разрабатывают интеграции с Fluss, тем самым укрепляя экосистему.

Ниже приведены основные функции современной аналитики реального времени.

Поток как таблица (Stream as Table)

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

Log Tables (Лог-таблицы)** работают только на добавление (append-only), аналогично топикам Kafka. Такие сценарии использования, как мониторинг логов, кликстримы (clickstreams), показания датчиков, журналы транзакций и другие, являются хорошими примерами данных только для добавления. События неизменяемы и не должны изменяться или обновляться.
Primary Key (PK) Tables (Таблицы с первичным ключом)** — это изменяемые таблицы, определенные ключом. Записи сначала вставляются, а затем обновляются или удаляются с течением времени в соответствии с журналом изменений (changelog), который они представляют. Таблица PK хранит последние изменения всей таблицы, обеспечивая паттерн доступа «поиск записи» (record lookup). Сценарии использования журнала изменений, такие как балансы счетов, корзина покупок и управление запасами, могут извлечь выгоду из этого подхода. Kafka не может выполнять такое поведение, требуя внешних баз данных типа «ключ-значение» или NoSQL для отслеживания текущего статуса записи, что приводит к сложным и трудным в обслуживании решениям.

Вкратце, PK Tables обеспечивают уникальность записей на основе первичного ключа, операций `INSERT`, `UPDATE` и `DELETE`, а также предоставляют широкие возможности изменения записей. С другой стороны, Log Tables работают только на добавление; обновления записей не требуются.

Колоночное хранение (Columnar Storage)

То, как Fluss хранит данные на диске, возможно, является наиболее фундаментальным архитектурным сдвигом по сравнению с другими решениями. В отличие от Kafka, Fluss использует формат `Apache Arrow` для хранения данных в колоночном формате, что дает следующие преимущества:

Улучшенное использование хранилища**, так как хранение данных в колоночном формате требует меньше дискового пространства. Степень сжатия зависит от множества характеристик данных, но первоначальные тесты показывают многообещающее улучшение в 5 раз при использовании Apache Arrow в качестве базового формата хранения. Меньше хранилища = меньше затрат. Kafka предоставляет лишь несколько вариантов сжатия данных, которые не сравнимы с теми, что доступны в Apache Arrow «из коробки».
Эффективные запросы с использованием обрезки столбцов (column pruning).** В общем случае запрашивается или доступно менее половины атрибутов данного бизнес-события, т.е. только те имена столбцов, которые вы добавляете в ваше выражение `SELECT FROM`. Проталкивание проекции (projection pushdown) — это метод, который удаляет ненужные атрибуты (также известный как column pruning) при извлечении данных из системы хранения. Kafka работает по принципу «все или ничего» из-за своего формата хранения на основе записей.
И колоночное сжатие, и проталкивание проекции улучшат сетевой трафик — перемещение меньшего количества данных приведет к тому, что сетевые администраторы станут счастливее. С Kafka компании постоянно сталкиваются с перегрузкой сети и потенциально высокими расходами на исходящий трафик (egress costs).

Унификация с Lakehouse

Kafka была создана в эпоху Data Lake (Озер данных). С самого начала проектирования Fluss создавался для Lakehouse. Это создает большую разницу. Компании поняли, что Озера данных (или во многих случаях «Болота данных» — Data Swamps) трудно поддерживать в рабочем состоянии и окупать инвестиции в лицензии, оборудование и персонал для создания решений больших данных. К счастью, Лейкхаусы преодолевают эти проблемы. Лейкхаусы утверждают, что данные должны быть широко и легко доступны независимо от их возраста. Пакетные события и события реального времени перекрываются, и движки обработки должны иметь возможность прозрачно обращаться к обоим слоям.

Вот возможности тиринга данных (распределения по уровням) и унифицированного просмотра, которые может предоставить Fluss, в дополнение к слою горячих/свежих данных:

Теплый слой (Warm layer):** для данных возрастом от минут до часов, в основном хранящихся в решениях объектного хранения (Object Storage).
Холодный слой (Cold layer):** для данных возрастом от дней до лет. Решения Lakehouse, такие как `Apache Paimon` и `Iceberg`, являются предпочтительными платформами для этих исторических данных, питающих модели ML, ретроспективную аналитику и комплаенс.
Zero-copy data tiering (Тиринг данных без копирования):** старение данных из горячего слоя (таблицы Fluss) в теплые/холодные слои (Object Storage и Lakehouse). Это означает, что доступна единственная копия единицы данных, либо в слое реального времени, либо в историческом слое. Fluss управляет переключением между слоями, облегчая запросы и доступ. Подход Kafka опирается на дублирование данных с помощью задания потребителя/издателя, что приводит к увеличению затрат на хранение и необходимости конвертировать топики Kafka в табличный формат Lakehouse.

Светлое будущее впереди

Аналитика данных в реальном времени становится краеугольным камнем современных компаний. Цифровые бизнес-модели должны обеспечивать лучший пользовательский опыт и своевременные ответы на взаимодействия с клиентами, что заставляет компании создавать системы для использования и управления данными в реальном времени, создавая увлекательный и впечатляющий («wow») опыт. Действовать сейчас — это не просто вопрос технической осуществимости; для большинства предприятий это становится уникальным преимуществом для выживания в высококонкурентной глобальной рыночной среде.

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

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

С операционной стороны он предлагает значительные преимущества за счет снижения сложности управления, хранения и обслуживания как данных реального времени, так и пакетных данных. Эта эффективность трансформируется в прямую экономию средств, достигаемую в первую очередь за счет оптимизированного формата таблиц Fluss, двухуровневой системы хранения, основанной на температуре данных, и, наконец, минимизации общего использования ЦП конвейера с помощью проталкивания предикатов (predicate pushdown) и обрезки столбцов. В совокупности эти архитектурные элементы снижают накладные операционные расходы, связанные с обслуживанием платформы, ускоряют внедрение новых сценариев использования и облегчают бесшовную интеграцию с существующей ИТ-инфраструктурой предприятия.

Data Contracts — соглашение между производителями и потребителями данных

Sun, 08 Feb 2026 00:29:11 +0300

о книге «Data Contracts» или как договориться о данных в эпоху хаоса и вернуть им ценность

Введение: Кризис доверия в мире данных
Книга Чада Сандерсона и Марка Фримена «Data Contracts» выходит в момент глубокого кризиса в индустрии данных. Несмотря на триллионы долларов инвестиций в Modern Data Stack, облака и ИИ, компании всё чаще сталкиваются с парадоксом: данных больше, чем когда-либо, а извлекаемая ценность — под вопросом. Дашборды врут, модели ML ошибаются, а инженеры данных погребены под лавиной инцидентов. Авторы дают диагноз этой болезни: «данные долг» (data debt), и предлагают радикальное лечение: «данные контракты» (data contracts).

Часть 1: Диагноз — Эпидемия данных долга
Авторы проводят читателя через историческую эволюцию, объясняя, как мы пришли к текущему хаосу.

Золотой век и падение Хранилищ Данных: Раньше централизованные хранилища данных, созданные архитекторами, обеспечивали «единый источник истины». Это было медленно, дорого, но надежно.
Agile, микросервисы и «дамп данных»: Софтверные компании, движимые скоростью, убили роль архитектора данных. Данные перестали проектировать — их начали «сливать» в data lakes. Разрыв между командами, создающими данные (продуктовые разработчики, OLTP) и использующими их (аналитики, дата-сайентисты, OLAP), стал пропастью.
Иллюзия Modern Data Stack: Такие инструменты как Snowflake, Fivetran и dbt решили проблему «как» работать с данными, но усугубили проблему «что» и «почему». Они упростили перемещение и трансформацию беспорядочных данных, легализовав отсутствие дисциплины. Результат — взрывные затраты, непонятные SQL-запросы-монстры и полная потеря доверия.

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

Часть 2: Новый императив — Data-Centric AI
Авторы блестяще связывают кризис данных с новой парадигмой в машинном обучении. Эндрю Нг провозгласил сдвиг от model-centric AI (бесконечная настройка алгоритмов) к data-centric AI (систематическое улучшение качества данных для обучения).

Почему это важно? Модели, особенно с появлением больших языковых моделей (LLM), становятся товаром. Любой может вызвать мощнейшую модель через API. Конкурентное преимущество теперь создается не алгоритмом, а качественными, уникальными данными, на которых он обучается и работает.
Парадокс: В момент, когда бизнесу как никогда нужны чистые, надежные данные для ИИ, его инфраструктура данных наименее к этому готова. Data-Centric AI требует фундамента, которого нет — управляемого, контрактного подхода к данным.

Часть 3: Лечение — Data Contracts как API для доверия
Data Contracts — это ядро предлагаемого решения. Это не юридические документы, а машиночитаемые соглашения, оформленные как код.

Что это такое? Контракт между производителем данных (например, сервис, который генерирует события о покупках) и потребителем данных (например, команда аналитики, строящая отчет по выручке).
Что в него входит? Схема данных (типы, имена полей), семантика (что означает каждое поле, бизнес-правила), соглашения об уровне обслуживания (SLAs — частота обновления, задержка), правила обработки конфиденциальных данных (PII).
Как работает? Контракт устанавливается через API. При попытке изменить источник данных (удалить поле, изменить тип) система проверяет все зависимые контракты и либо блокирует изменение, либо требует скоординированной миграции. Это автоматизирует коммуникацию и создает «защитные ограждения».

Часть 4: Практика — Качество данных как измеримый процесс
Авторы уходят от утопии «идеальных данных» к прагматичному управлению качеством. Они предлагают измерять его через:

Опережающие индикаторы: Наличие владельцев у источников данных, уровень доверия команд к данным (измеряется через опросы), объем данных долга (сложность запросов, количество backfill-задач).
Запаздывающие индикаторы: Время простоя данных (data downtime), количество инцидентов с реальным бизнес-влиянием (например, ошибочный отзыв товара).

Главная мысль: нужно говорить с бизнесом не о «качестве», а о рисках и потерях денег из-за его отсутствия.

Заключение: Возвращение к дисциплине через инновации
«Data Contracts» — это манифест за возвращение инженерной дисциплины в мир данных, но на новом уровне. Это не призыв вернуться к медленным централизованным хранилищам. Это предложение создать децентрализованную, но управляемую экосистему данных, где скорость микросервисов сочетается с надежностью контрактов.

Книга является обязательным чтением для:

Руководителей данных (CDO, Head of Data), чтобы понять стратегический ответ на вызовы data debt и Data-Centric AI.
Инженеров данных и архитекторов, ищущих практические методы наведения порядка.
Продуктовых менеджеров и разработчиков, которые должны осознать, что их данные — это продукт для внутренних клиентов.
Дата-сайентистов и аналитиков, уставших от нестабильных данных.

Data Contracts — это больше, чем технология. Это философия сотрудничества, которая превращает данные из источника постоянных проблем в настоящий актив, способный обеспечить конкурентное преимущество в эпоху ИИ.

Приложение пример полей и контракта данных

Атрибуты контракта (обязательные и опциональные)

Атрибут	Тип	Обязательный	Описание
domain	string	Да	Домен Data Mesh
data_product	string	Да	Название дата-продукта
owner	string	Да	Контакт команды-владельца
schema	object	Да	Схема данных (Avro/JSON/Parquet)
slas	object	Да	Требования к свежести, доступности
security	object	Нет	Поля ПДн, политики доступа
quality_checks	array	Нет	Список проверок качества
consumers	array	Нет	Список команд-потребителей
lifecycle	object	Нет	Правила хранения, архивации

version: 1.0
domain: sales
owner: team-sales@company.com
data_product: customer_events
schema:
  type: avro/json
  definition: { ... }
slas:
  freshness: "5m"
  completeness: "99.9%"
security:
  pii_fields: ["email", "phone"]
  masking: dynamic
quality_checks:
  - type: null_check
    columns: ["user_id"]
  - type: range_check
    column: "amount"
    min: 0
consumers:
  - analytics_team
  - ml_team
lifecycle:
  retention_days: 365
  archive_after: 90

Еще один дата каталожик – Marmot

Sun, 08 Feb 2026 00:06:32 +0300

https://github.com/marmotdata/marmot

Marmot is an open-source data catalog designed for teams who want powerful data discovery without enterprise complexity. Built with a focus on simplicity and speed, Marmot helps you catalog assets across your entire data stack – from databases and APIs to message queues and data pipelines.

Unlike traditional catalogs that require extensive infrastructure and configuration, Marmot ships as a single binary with an intuitive UI, making it easy to deploy and start cataloging in minutes.

Built for Modern Data Teams

Deploy in Minutes: Single binary, Docker, or Kubernetes – no complex setup required
Powerful Search: Powerful query language with full-text, metadata, and boolean operators
Track Lineage: Interactive dependency graphs to understand data flows and impact
Flexible Integrations: CLI, REST API, Terraform, and Pulumi – catalog assets your way
Lightweight: PostgreSQL-backed with minimal resource requirements

От «зоопарка» технологий к Lakehouse: Итоги разговора с Вадимом Беловым

Sat, 01 Nov 2025 00:02:16 +0300

Летом в рамках стрима «Разговоры на Архитекторском» состоялась беседа с Вадимом Беловым, руководителем системной разработки больших данных в X5. Основной темой стали эволюция платформ данных, переход от классических архитектур к концепции `Lakehouse` и практические аспекты такой миграции. Ниже представлен синтез ключевых идей и выводов этой встречи.

https://t.me/analyticsfromzero/201

1. Предел «классической» архитектуры

В начале пути многие компании, включая X5, строили свои платформы на стеке проверенных, но разрозненных технологий: `Hadoop` для хранения больших объемов данных, `Greenplum` как мощная MPP-база для аналитики и `ClickHouse` для быстрых витрин. Такая архитектура работала, но со временем достигла своего предела.

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

Основные болевые точки «классического зоопарка»:

Сложность и дублирование: Данные приходилось постоянно перемещать между системами. Например, выгрузить данные в `Hadoop`, оттуда переложить в `Greenplum` для расчетов, а затем, возможно, вернуть обратно для ML-моделей на `Spark`. Каждое такое перемещение создает `staging`-слои и дубликаты данных.
Высокий TCO (Total Cost of Ownership): Поддержка нескольких разнородных систем с разными компетенциями, процессами релиза и типами оборудования обходится дорого.
Узкие горлышки: Централизованные команды и системы не успевают отвечать на растущие запросы бизнеса, требующего большей скорости и гибкости (`time-to-market`).
Технологические ограничения: Каждая система хороша для своей ниши, но имеет ограничения. Например, `Greenplum` — мощная реляционная СУБД, но из неё сложно отдавать данные для нереляционных задач, связанных с машинным обучением.

2. Lakehouse как эволюционное решение

Переход к `Lakehouse` — это не революция, а эволюция, попытка объединить лучшие черты двух миров:

`Data Lake`: Дешевое хранение огромных объемов данных любого формата.
`Data Warehouse`: Структурированность, надежность, транзакционность (`ACID`) и гарантия консистентности данных.

Ключевым моментом, сделавшим эту концепцию возможной, стало появление открытых транзакционных форматов таблиц, таких как `Apache Iceberg` и `Delta Lake`. Именно они позволили реализовать `ACID`-транзакции поверх файловых хранилищ вроде `S3`.

Центральная архитектурная идея `Lakehouse` — разделение хранения (`storage`) и вычислений (`compute`). Это дает модульность и гибкость: можно независимо масштабировать хранилище и вычислительные ресурсы, а также подменять компоненты стека без кардинальной перестройки всей системы.

3. Преимущества и новые возможности

Архитектура `Lakehouse` открывает ряд значительных преимуществ:

Унификация и сокращение дублирования: Данные хранятся в одном месте в открытом формате, а различные движки (`Trino`, `Spark` и др.) могут работать с ними напрямую, без необходимости копирования. Это снижает затраты на хранение и упрощает пайплайны.
Упрощение разработки: Благодаря поддержке `ACID` и возможности выполнять `UPDATE`/`DELETE`/`MERGE` операции, дата-инженеры могут работать с `Lakehouse` как с обычной реляционной базой данных, что снижает порог входа и упрощает поддержку.
Гибкость и снижение рисков: Модульная архитектура позволяет легко заменять компоненты. Если вычислительный движок перестал устраивать, его можно поменять, не затрагивая данные. Это снижает зависимость от одного вендора или технологии.
Новые бизнес-сценарии: Появляется возможность строить аналитические контуры, близкие к реальному времени. Используя технологии `CDC` (Change Data Capture), например, с помощью `Debezium`, можно с секундной задержкой реплицировать изменения из операционных баз прямо в `Lakehouse` и немедленно делать их доступными для аналитики.

4. Практика реализации и вызовы

В X5 в качестве основного SQL-движка для `Lakehouse` выбрали `Trino`, а для сложных обработок — `Spark`. Форматом хранения стал `Apache Iceberg`. Вадим отметил, что перенос логики с `Greenplum` на `Trino` оказался относительно простым, так как оба решения являются MPP-системами. Продвинутые возможности современных движков, такие как динамические фильтры в `Trino`, позволяют значительно ускорять запросы за счет сокращения объема данных, читаемых из хранилища cedrusdata.ru, habr.com.

Однако переход не лишен сложностей:

Data Governance:** Как управлять правами доступа, когда к одним и тем же данным могут подключаться разные движки (`Trino`, `Spark`)? Классические инструменты, вроде `Ranger`, не всегда подходят. Решением видится развитие «умных» каталогов данных (например, `Gravitino`), которые станут единой точкой для управления политиками безопасности и метаданными. (пс: хватит уже откапывать этот Ranger \ ставьте сразу OPAL :) )
Производительность:** Критически важными становятся производительность сети между `storage` и `compute`, а также возможности самого объектного хранилища (`S3-compatible`) выдерживать высокую нагрузку на чтение метаданных и мелких файлов.
Зрелость Open Source:** Многие компоненты активно развиваются, что означает частые обновления, новые возможности, но и потенциальные баги. Это требует выстраивания собственных процессов R&D и тщательного тестирования.

5. Советы для бизнеса и архитекторов

Для тех, кто рассматривает переход на `Lakehouse`, Вадим Белов дал несколько ключевых советов:

Проводите R&D: Не принимайте решение на основе маркетинговых материалов. Проведите исследование на собственных данных и задачах.
Начинайте с пилота: Используйте облачные платформы для быстрого развертывания пилотного проекта. Это позволит оценить технологию, посчитать экономику и выключить кластер, когда он не нужен, сэкономив деньги.
Не трогайте `business-critical`: Не начинайте миграцию с самых критичных систем. Выберите область, где есть право на ошибку, чтобы команда могла адаптироваться к новым технологиям.
Обосновывайте деньгами: Для бизнеса главным аргументом будет экономическая эффективность: снижение TCO за счет унификации стека, отсутствия дублирования данных и более быстрого `time-to-market` для новых продуктов.

Итог встречи

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

Переход на `Lakehouse` позволяет создать более гибкую, масштабируемую и экономически эффективную архитектуру за счет разделения хранения и вычислений, а также использования открытых форматов. Однако этот путь требует зрелого подхода, инвестиций в R&D и решения новых вызовов, в первую очередь в области `Data Governance`.

Взгляд в будущее направлен на `Streaming Lakehouse`, где граница между batch- и stream-обработкой стирается, и на развитие «умных» каталогов данных, которые станут мозгом всей платформы, управляя не только метаданными, но и безопасностью, качеством и контрактами данных.

О некоторых Streaming Хаусах я уже писал ранее.

Скоро будет еще встреча

13 ноября проведут вторую серию «Разговоров на архитекторском» и в этот раз коснемся индустриальных ML платформ.

Эксперт – руководитель разработки и ML OPS в крупной технологичной компании, которую вы все знаете.

Темы:

1️⃣Платформа инференса в 2025 году. Как построить и как грамотно утилизировать большой парк современных GPU
2️⃣Классический ML и трансформерный ИИ. Может ли существовать одно без другого.
3️⃣Если ты стажер или джун и хочешь в ML, на что тебе стоит обратить внимание и что изучить

@analyticsfromzero

Построение надежных ML-систем и технический долг

Thu, 16 Oct 2025 00:27:47 +0300

Машинное обучение (ML) превратилось из чисто исследовательской дисциплины в мощный инструмент для создания сложных и полезных продуктов. Сегодня ML-системы принимают критически важные решения в медицине, финансах и автономном транспорте medium.com. Однако быстрая разработка и развертывание — лишь верхушка айсберга. Основные трудности и затраты возникают при их долгосрочной поддержке. Неожиданные сбои моделей являются одним из главных барьеров для внедрения технологий ИИ arxiv.org.

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

Часть 1. Карта жизненного цикла ML-проекта

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

Из книги масштабируемые данные

Фаза 1: Исследования (Research)

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

Запуск проекта:
- Задачи:** Четкое определение бизнес-проблемы и формулировка ML-гипотезы («Сможем ли мы предсказывать Y с помощью данных X с точностью N?»). На этом этапе важно задать фундаментальный вопрос: а нужно ли здесь вообще машинное обучение? Создается техническая инфраструктура: репозиторий в Git, проект в системе CI/CD (например, Jenkins, GitLab CI).
- Участники:** Бизнес-заказчики, продуктовые менеджеры, аналитики, специалисты по Data Science.

Проектирование данных:
- Задачи:** Поиск, сбор и интеграция данных из различных источников в единое хранилище («озеро данных»). Затем данные исследуются на предмет полноты, аномалий и качества, после чего происходит их очистка, трансформация и регистрация в качестве «очищенных» наборов данных.
- Участники:** Инженеры данных (Data Engineers), команда DWH, специалисты по Data Science.

Экспериментирование:
- Задачи:** Это сердце работы Data Scientist. Здесь происходит генерация признаков (`feature engineering`), подбор архитектуры модели, ее обучение, валидация и оценка. Критически важными шагами являются версионирование данных и кода, а также фиксация всех результатов и метрик для обеспечения воспроизводимости.
- Участники:** Специалисты по Data Science (ML/DS).

Эта фаза завершается решением: если эксперименты успешны, проект переходит в фазу эксплуатации. Если нет — он либо отправляется на новый виток исследований, либо закрывается.

Фаза 2: Эксплуатация (Operations / MLOps)

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

Ввод в эксплуатацию:
- Задачи: Код, написанный для экспериментов, часто требует серьезного рефакторинга и оптимизации для производственной среды. Строится автоматизированный конвейер (pipeline), который выполняет все шаги: от получения свежих данных до выгрузки предсказаний. Этот процесс должен быть не только автоматизированным, но и устойчивым к сбоям, что является ключевым принципом как MLOps, так и классической инженерии надежности Reliability Engineering arxiv.org.
- Участники: ML-инженеры, DevOps-инженеры, инженеры данных.

Мониторинг:
- Задачи: После развертывания работа не заканчивается. Необходимо постоянно отслеживать как технические, так и качественные показатели модели: стабильность входных данных, качество предсказаний (точность, полнота), а также бизнес-метрики. Для оценки реального влияния на продукт проводятся А/В-тесты.
- Участники: ML-инженеры, SRE (Site Reliability Engineers), аналитики, продуктовые менеджеры.

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

Часть 2. «Скрытый технический долг в системах машинного обучения»

В 2015 году исследователи из Google опубликовали знаковую работу «Hidden Technical Debt in Machine Learning Systems». Они показали, что в ML-системах технический долг накапливается быстрее и опаснее, чем в традиционном ПО.

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

Ключевые источники технического долга в ML:

Эрозия границ и связанность (Entanglement): В ML практически невозможно изолировать компоненты из-за принципа CACE («Changing Anything Changes Everything» — «Изменение чего угодно меняет всё»).
- Изменение одного признака влияет на важность всех остальных.
- Добавление нового признака `x_n+1` может полностью изменить веса старых `x_1...x_n`.

Зависимости от данных (Data Dependencies): Эти зависимости коварнее зависимостей от кода, так как их сложнее отследить статически.
- Нестабильные данные: Использование данных из другой ML-системы, которая может обновляться без вашего ведома — это бомба замедленного действия. «Улучшение» в той системе может сломать вашу.
- Недоиспользуемые данные: Со временем признаки могут становиться ненужными (Legacy Features), добавляться «пачкой» ради мнимого прироста метрик (Bundled Features) или дублировать друг друга (Correlated Features). Они не приносят пользы, но увеличивают сложность и уязвимость системы.

Антипаттерны проектирования:
- Код-клей (Glue Code): Огромное количество кода пишется для «склеивания» данных с универсальной ML-библиотекой (например, `scikit-learn`, `TensorFlow`). Авторы утверждают, что в зрелой системе ML-код может составлять всего 5%, а остальное — «клей».
- Джунгли конвейеров (Pipeline Jungles): Системы подготовки данных часто разрастаются органически, превращаясь в запутанные «джунгли» из скриптов, которые невозможно тестировать, отлаживать и развивать.
- Мертвые пути экспериментов: В коде остаются ветки `if/else` от прошлых экспериментов, которые усложняют тестирование и создают риск неожиданного поведения.

Петли обратной связи (Feedback Loops): Модель в реальном мире влияет на среду, из которой она же и получает данные для будущего обучения. Это может привести к сужению разнообразия и деградации модели, когда она начинает усиливать свои собственные прошлые решения.

Долг конфигурации (Configuration Debt): Конфигурация ML-систем (какие признаки использовать, параметры алгоритма, пороги) часто занимает больше строк, чем сам код. Ею сложно управлять, ее редко тестируют, а ошибки в ней могут приводить к катастрофическим последствиям.

Часть 3. Практические выводы

Схема жизненного цикла из Части 1 показывает, ЧТО и КОГДА нужно делать. Статья о техническом долге из Части 2 объясняет, ПОЧЕМУ и КАК это нужно делать правильно, чтобы система не развалилась через полгода.

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

Блок Экспериментирование — это фабрика по производству `кода-клея` и `недоиспользуемых признаков`. Погоня за сотыми долями процента в метрике качества часто приводит к огромному усложнению системы.
Блок Ввод в эксплуатацию без рефакторинга и целостного проектирования порождает `джунгли конвейеров`.
Блок Мониторинг — главный инструмент для обнаружения последствий технического долга: смещения данных (Data Drift) и деградации модели (Model Drift).

Заключение

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

Ниже представлен перевод и краткий пересказ ключевых идей научной статьи «Скрытый технический долг в системах машинного обучения» от D. Sculley и других исследователей из Google. Пояснения к терминам и концепциям добавлены в формате ``.

Оригинал тут: http://a.gavrilov.info/data/posts/ml-Paper.pdf

Скрытый технический долг в системах машинного обучения

Аннотация

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

1. Введение

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

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

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

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

2. Размывание границ из-за сложности моделей

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

Связанность (Entanglement). МО-системы смешивают сигналы, делая изоляцию улучшений невозможной. Это принцип CACE (Changing Anything Changes Everything — «Изменение чего угодно меняет всё»). Изменение распределения одного признака (x₁) может изменить важность или веса всех остальных признаков. Добавление или удаление признаков имеет тот же эффект. Улучшение одной модели в ансамбле может ухудшить общую точность системы, если ошибки станут более коррелированными.
Каскады исправлений (Correction Cascades). Часто возникает соблазн исправить проблему A’, которая немного отличается от уже решенной проблемы A, создав новую модель `m’` поверх существующей модели `mA`. Эта новая модель `m’` учится вносить небольшую поправку. Однако это создаёт новую зависимость от `mA`, что делает будущий анализ улучшений `mA` значительно дороже. Каскады таких исправлений могут привести к тупиковой ситуации, когда улучшение любого отдельного компонента ухудшает общую производительность системы.
Необъявленные потребители (Undeclared Consumers). Часто предсказания МО-модели становятся общедоступными (например, через логи). Другие системы могут начать тайно использовать эти данные в качестве входных. В классической инженерии это называют долгом видимости . Такие необъявленные потребители создают скрытую жёсткую связь. Любые изменения в исходной модели, даже улучшения, могут негативно и непредсказуемо повлиять на эти системы-потребители.

3. Зависимости от данных стоят дороже зависимостей от кода

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

Нестабильные зависимости от данных. Удобно использовать в качестве признаков данные из других систем. Однако если эти входные сигналы нестабильны (например, сами являются выходом другой МО-модели, которая со временем обновляется), они могут меняться. Даже «улучшения» входного сигнала могут иметь разрушительные последствия для потребляющей его системы. Распространённая стратегия смягчения — создание версионных, «замороженных» копий таких данных.
Недостаточно используемые зависимости от данных. Это входные сигналы, которые дают очень небольшой прирост производительности, но делают систему излишне уязвимой к изменениям. Они могут появиться несколькими путями:
- Устаревшие признаки (Legacy Features): Признак добавляется на ранней стадии, со временем новые признаки делают его избыточным, но его не удаляют.
- Пакетные признаки (Bundled Features): Группа признаков добавляется вместе, потому что «в пакете» они показали пользу, хотя некоторые из них по отдельности бесполезны.
- ε-признаки : Признаки, которые добавляют ради крошечного прироста точности, но при этом значительно усложняют систему.
- Коррелированные признаки (Correlated Features): Когда два признака сильно коррелируют, модель может ошибочно отдать предпочтение не причинно-следственному, а зависимому, что делает систему хрупкой, если в будущем эта корреляция изменится.

Рисунок 1: Лишь малая часть реальных МО-систем состоит из кода МО (маленький чёрный квадрат в центре).

Необходимая окружающая инфраструктура огромна и сложна.

`ML Code` — Код МО
`Configuration` — Конфигурация
`Data Collection` — Сбор данных
`Feature Extraction` — Извлечение признаков
`Data Verification` — Верификация данных
`Machine Resource Management` — Управление ресурсами
`Analysis Tools` — Инструменты анализа
`Process Management Tools` — Инструменты управления процессами
`Serving Infrastructure` — Инфраструктура для развёртывания
`Monitoring` — Мониторинг

4. Петли обратной связи

Ключевая особенность работающих МО-систем — они часто начинают влиять на собственное поведение.

Прямые петли обратной связи. Модель напрямую влияет на выбор данных для своего будущего обучения. Например, система рекомендаций показывает пользователю определённые товары; если пользователь кликает на них, эти клики используются для дообучения модели, что закрепляет её текущее поведение.
Скрытые петли обратной связи. Две отдельные системы косвенно влияют друг на друга через реальный мир. Пример: одна система выбирает товары для показа на веб-странице, а другая — связанные с ними отзывы. Улучшение одной системы (например, показ более релевантных товаров) приведёт к изменению поведения пользователей (больше кликов), что, в свою очередь, повлияет на вторую систему (какие отзывы показывать).

5. Антипаттерны МО-систем

Для академического сообщества может быть удивительно, что в реальных МО-системах лишь малая часть кода (см. Рисунок 1) отвечает непосредственно за обучение или предсказание. Остальное — это инфраструктурная «обвязка».

«Код-клей» (Glue Code) . Системный дизайн, при котором пишется огромное количество вспомогательного кода для передачи данных в универсальные МО-пакеты и из них. Этот код «приклеивает» систему к особенностям конкретного пакета, делая переход на альтернативы крайне дорогим. Иногда дешевле создать чистое нативное решение, чем использовать универсальный пакет, если 95% системы — это «код-клей».

«Джунгли конвейеров» (Pipeline Jungles). Особый случай «кода-клея», часто возникающий при подготовке данных. Системы превращаются в «джунгли» из скриптов для парсинга, объединения данных и сэмплирования, которыми сложно управлять и тестировать.
Мёртвые ветки экспериментального кода (Dead Experimental Codepaths). Часто для экспериментов в основной код добавляются временные условные ветки. Со временем они накапливаются, усложняя поддержку обратной совместимости и тестирование. Знаменитый пример — система Knight Capital, потерявшая $465 млн за 45 минут из-за непредвиденного поведения устаревшего экспериментального кода.
Долг абстракции (Abstraction Debt). В МО не хватает сильных, общепринятых абстракций, подобных реляционной базе данных в мире СУБД. Это размывает границы между компонентами системы.

Распространённые «запахи» кода в МО

«Запах» простых типов данных (Plain-Old-Data Type Smell): Использование обычных `float` или `int` вместо более насыщенных типов. Например, параметр модели должен «знать», является он порогом принятия решения или множителем.
«Запах» многоязычности (Multiple-Language Smell): Использование нескольких языков программирования в одной системе усложняет тестирование и передачу ответственности.
«Запах» прототипа (Prototype Smell): Постоянное использование отдельной среды для прототипирования может указывать на то, что основная система слишком неповоротлива и сложна для изменений. Существует опасность, что под давлением сроков прототип будет запущен в продакшен.

6. Долг конфигурации

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

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

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

7. Работа с изменениями во внешнем мире

МО-системы увлекательны тем, что они напрямую взаимодействуют с внешним миром. Но внешний мир редко бывает стабилен, что создаёт постоянные затраты на поддержку.

Фиксированные пороги в динамических системах. Часто порог принятия решения (например, для классификации письма как спама) устанавливается вручную. Если модель обновляется на новых данных, этот старый порог может стать недействительным.
Мониторинг и тестирование. Необходимо в реальном времени отслеживать поведение системы. Ключевые метрики для мониторинга:
- Смещение предсказаний (Prediction Bias): Распределение предсказанных меток должно соответствовать распределению реальных меток. Отклонение этого показателя часто указывает на проблемы.
- Ограничения на действия (Action Limits): В системах, которые выполняют действия в реальном мире (например, делают ставки на аукционе), полезно устанавливать «разумные» лимиты. Срабатывание такого лимита должно вызывать тревогу и требовать ручного вмешательства.
- Поставщики данных (Up-Stream Producers): Системы, поставляющие данные для МО-модели, должны тщательно отслеживаться и тестироваться. Любые сбои в них должны немедленно передаваться в МО-систему.

8. Другие области долга, связанного с МО

Долг тестирования данных (Data Testing Debt). Если данные заменяют код, то данные, как и код, должны тестироваться.
Долг воспроизводимости (Reproducibility Debt). Воспроизводить эксперименты в реальных системах сложно из-за рандомизации, недетерминизма параллельных вычислений и взаимодействия с внешним миром.
Долг управления процессами (Process Management Debt). В зрелых системах могут работать сотни моделей одновременно. Это порождает проблемы с массовым обновлением конфигураций, управлением ресурсами и т.д.
Культурный долг (Cultural Debt). Жёсткая граница между «исследователями МО» и «инженерами» контрпродуктивна. Важно создавать культуру, в которой удаление признаков, снижение сложности и улучшение стабильности ценятся так же высоко, как и повышение точности.

9. Выводы: Измерение и выплата долга

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

Полезные вопросы для оценки долга:

Насколько легко протестировать совершенно новый алгоритмический подход в полном масштабе?
Каково транзитивное замыкание всех зависимостей от данных?
Насколько точно можно измерить влияние нового изменения на систему?
Ухудшает ли улучшение одной модели или сигнала работу других?
Как быстро новые члены команды могут войти в курс дела?

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

Сводная статья: Основы проектирования современного хранилища данных

Tue, 16 Sep 2025 23:51:51 +0300

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

Источник: Apache SeaTunnel’s Substack
Даты: 5 сентября 2025 г. и 14 сентября 2025 г.

Часть 1: Сводный перевод статей

(I) Принципы архитектуры модели данных: Четыре уровня и семь этапов, «краеугольный камень» моделирования Data Lake и хранилищ данных

Руководство по проектированию и практическому применению Data Lake и хранилищ данных (2025) состоит из четырех последовательных частей. Следуя основной линии «архитектура модели – общие спецификации – спецификации наслоения – спецификации именования», оно позволяет системно построить современное озеро данных (data lake) и хранилище, которое может развиваться, управляться и использоваться совместно.

https://substack.com/home/post/p-172756839

(II) Полное руководство по основным стандартам проектирования хранилищ данных: от уровней и типов до жизненного цикла

Руководство по проектированию и практическому применению Data Lakehouse: стандарты моделирования и именования для Data Lakehouse (2025)» состоит из четырех прогрессивных руководств, структурированных по основной линии: Архитектура модели — Общие стандарты — Стандарты наслоения — Стандарты именования. Вместе они позволяют системно построить развиваемое, управляемое и совместно используемое современное data lakehouse.

https://substack.com/home/post/p-173419940

Часть 2: Разбор методологии — от уровней до жизненного цикла

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

Основная цель — создать «развиваемое, управляемое и совместно используемое» хранилище. Это означает, что система должна быть:

Развиваемой: Легко адаптируемой к новым источникам данных и бизнес-требованиям без необходимости полной перестройки.
Управляемой: Иметь четкие правила качества данных, безопасности и контроля доступа.
Совместно используемой: Данные должны быть понятны и доступны для разных команд и отделов компании.

Основой для этого служит подход, который статьи называют «основной линией»:

Архитектура модели: Общий план строения хранилища.
Общие спецификации: Единые правила для всей системы (например, форматы дат, стандарты кодирования).
Спецификации наслоения: Правила и состав данных для каждого архитектурного уровня.
Спецификации именования: Единые правила наименования таблиц, полей и других объектов для их легкой идентификации (например, `fct_` для таблиц фактов, `dim_` для измерений, `mart_` для витрин).

Четыре архитектурных уровня

Это — костяк всей системы, по которому данные движутся и преобразуются от “сырых” до готовых к анализу.

1. `ODS` (Operational Data Store — Оперативное хранилище данных)

Назначение: Первый слой для приема данных из различных систем-источников (базы данных сайта, CRM, ERP, мобильные приложения).
Состояние данных: «Сырые» или минимально обработанные данные. Их структура максимально приближена к оригиналу. Этот слой служит буфером и архивом.
Пример: Каждый час система автоматически копирует новые записи о заказах из базы данных интернет-магазина и данные о клиентах из CRM в отдельные таблицы в слое `ODS`. Данные хранятся “как есть”.

2. `DW` (Data Warehouse — Хранилище данных)
Это центральный и самый сложный слой, где происходит основная магия: очистка, интеграция и моделирование данных. Он делится на три подслоя:

`DWD` (Data Warehouse Detail — Детальный слой)
- Назначение: Создание «единого источника правды». Данные из `ODS` очищаются, унифицируются (например, все статусы “Доставлен”, “delivered”, “Complete” приводятся к единому формату `delivered`) и связываются между собой.
- Состояние данных: Очищенные, детализированные, исторически полные данные. Здесь хранятся все транзакции и события в их самой гранулярной форме.
- Пример: На основе сырых данных о заказах из `ODS` создается таблица `dwd_orders`, где у каждого заказа есть уникальный идентификатор, ссылка на клиента, очищенный статус и стандартизированная дата.

`DWM` (Data Warehouse Middle — Промежуточный слой / Слой моделей)
- Назначение: Агрегация и трансформация данных для бизнес-аналитики. Здесь детальные данные из `DWD` преобразуются в модели «звезда» или «снежинка», состоящие из фактов (события, транзакции) и измерений (справочники).
- Состояние данных: Структурированные, готовые для анализа данные.
- Пример: На основе `dwd_orders` создается таблица фактов `fct_sales` (содержащая количество, сумму, скидку) и связанные с ней таблицы-измерения: `dim_customers` (клиенты), `dim_products` (товары), `dim_calendar` (календарь).

`DWS` (Data Warehouse Service/Summary — Слой витрин данных)
- Назначение: Предоставление данных конечным пользователям. Витрина — это набор данных, подготовленный для конкретного отдела или задачи.
- Состояние данных: Предварительно агрегированные, узкоспециализированные данные.
- Пример: Для отдела маркетинга создается витрина `mart_marketing_performance`, где продажи агрегированы по дням, рекламным кампаниям и регионам. Это позволяет маркетологам быстро оценивать эффективность своих действий, не обращаясь к сложным моделям слоя `DWM`.

3. `APP` (Application — Слой приложений)

Назначение: Слой визуализации и потребления данных. С ним работают конечные бизнес-пользователи.
Пример: BI-системы (Power BI, Tableau, Looker), которые подключаются к витринам данных в `DWS` и строят на их основе интерактивные дашборды, графики и отчеты.

Семь этапов жизненного цикла данных

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

Сбор (Source): Определение и доступ к источникам данных (БД, API, файлы).
Загрузка (Ingestion): Перемещение данных из источников в слой `ODS`.
Хранение (Storage): Размещение сырых данных в операционном хранилище (`ODS`).
Очистка и Интеграция (Cleansing & Integration): Преобразование данных и создание детального слоя (`DWD`).
Моделирование (Modeling): Построение аналитических моделей (таблиц фактов и измерений) в слое `DWM`.
Агрегация (Aggregation/Serving): Создание витрин данных для конкретных нужд в слое `DWS`.
Визуализация и Анализ (Visualization & Analysis): Потребление данных через BI-инструменты в слое `APP`.

Итог: Создание современного хранилища данных

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

Разделение на слои решает несколько ключевых проблем:

Изоляция изменений: Изменение в системе-источнике повлияет только на слой `ODS`, а не на всё хранилище.
Надежность: Данные проходят последовательную проверку и обогащение, что повышает доверие к ним.
Производительность: Пользователи работают с быстрыми, предварительно агрегированными витринами данных (`DWS`), а не с огромными детализированными таблицами.

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

Описание патерна Slowly Changing Dimensions (SCD)

Sat, 16 Aug 2025 23:24:59 +0300

Slowly Changing Dimensions (SCD), или Медленно меняющиеся измерения, — это концепция и набор методов из области хранилищ данных (Data Warehousing), которые используются для управления изменениями в атрибутах измерений с течением времени. Измерения — это справочные таблицы, которые описывают бизнес-сущности, такие как клиенты, продукты, сотрудники, географические регионы.

Атрибуты этих сущностей (например, адрес клиента или категория продукта) меняются, но обычно не очень часто — отсюда и название “медленно меняющиеся”. Основная задача SCD — решить, как хранить эти изменения, чтобы обеспечить точность исторических отчетов www.datacamp.com.

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

Основные типы SCD

Существует несколько типов SCD, но самыми распространенными и фундаментальными являются Типы 1, 2 и 3.

---

Тип 1: Перезапись атрибута (Overwrite)

Это самый простой подход. При изменении атрибута старое значение просто перезаписывается новым.

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

Пример:
У нас есть клиент Анна Петрова, которая живет в Москве.

*Таблица `DimCustomer` до изменений:*

CustomerKey	FullName	City
:---	:---	:---
101	Анна Петрова	Москва

Анна переезжает в Санкт-Петербург. При использовании SCD Тип 1 таблица будет обновлена:

*Таблица `DimCustomer` после изменений:*

CustomerKey	FullName	City
:---	:---	:---
101	Анна Петрова	Санкт-Петербург

Теперь невозможно узнать, что раньше Анна жила в Москве.

---

Тип 2: Добавление новой строки (Add New Row)

Это самый распространенный и мощный тип SCD, так как он позволяет сохранять полную историю изменений.

Как работает:** Вместо перезаписи существующей записи, создается новая запись для той же сущности (например, того же клиента). Старая запись помечается как неактуальная (истекшая), а новая — как актуальная. Для этого в таблицу измерения обычно добавляют несколько служебных столбцов learn.microsoft.com:
- `StartDate` / `EffectiveDate` — дата, с которой запись стала актуальной.
- `EndDate` — дата, когда запись перестала быть актуальной.
- `IsCurrent` / `CurrentFlag` — флаг (например, ‘Yes’/’No’ или 1/0), показывающий, является ли эта запись текущей.
Когда использовать:** Когда сохранение истории критически важно для анализа. Это стандартный выбор для большинства атрибутов в хранилищах данных.
Преимущества:** Сохраняется полная, точная история. Позволяет проводить корректный point-in-time анализ (анализ на определенный момент времени).
Недостатки:** Увеличивается объем таблицы, так как для одного клиента может быть несколько записей. Запросы могут стать сложнее (нужно фильтровать по флагу `IsCurrent` или по диапазону дат) hevodata.com.

Пример:
Снова используем пример с Анной Петровой.

*Таблица `DimCustomer` до изменений:*

SurrogateKey	CustomerID	FullName	City	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Анна Петрова	Москва	2020-01-15	NULL	Yes

Анна переезжает 16 августа 2024 года. При использовании SCD Тип 2 таблица изменится так:

*Таблица `DimCustomer` после изменений:*

SurrogateKey	CustomerID	FullName	City	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Анна Петрова	Москва	2020-01-15	2024-08-15	No
2	101	Анна Петрова	Санкт-Петербург	2024-08-16	NULL	Yes

Теперь мы сохранили всю историю перемещений Анны.

---

Тип 3: Добавление нового атрибута (Add New Attribute)

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

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

Пример:
Анна переезжает из Москвы в Санкт-Петербург.

*Таблица `DimCustomer` до изменений:*

CustomerKey	FullName	CurrentCity	PreviousCity
:---	:---	:---	:---
101	Анна Петрова	Москва	NULL

*Таблица `DimCustomer` после изменений:*

CustomerKey	FullName	CurrentCity	PreviousCity
:---	:---	:---	:---
101	Анна Петрова	Санкт-Петербург	Москва

Если Анна переедет снова, значение “Москва” будет потеряно.

Другие типы SCD

Существуют и более сложные гибридные типы:

Тип 4 (History Table):** Основная таблица измерения хранит только текущие данные (как Тип 1), а вся история изменений выносится в отдельную таблицу. Это полезно, когда изменения происходят часто в очень больших таблицах измерений medium.com.
Тип 6 (Hybrid):** Комбинирует подходы Типов 1, 2 и 3. Например, в таблице хранятся поля для полной истории (SCD2) и одновременно поле для текущего значения (SCD1 для быстрого доступа) и предыдущего значения (SCD3 для сравнения).

Тип 4: Добавление исторической таблицы (History Table / Audit Table)

Идея: Разделить текущие данные и исторические данные в разные таблицы для оптимизации производительности.

Как работает:** Создаются две таблицы:
1. Таблица измерения (Dimension Table): Хранит *только* текущие, самые последние данные. Эта таблица по своей сути работает как SCD Тип 1 (данные просто перезаписываются). Она маленькая, быстрая и идеально подходит для большинства запросов, где история не нужна.
2. Историческая таблица (History Table): Хранит всю историю изменений. Каждый раз, когда в основной таблице происходит изменение, старая версия строки (до обновления) добавляется в историческую таблицу. Эта таблица часто содержит служебные поля, как в SCD Тип 2 (`StartDate`, `EndDate`, `Version`), для отслеживания временного периода.
Когда использовать:** Когда у вас есть очень большая таблица измерений (например, десятки миллионов клиентов), и большинство аналитических запросов относится только к текущим данным. Разделение таблиц позволяет сделать эти частые запросы очень быстрыми, не жертвуя при этом возможностью проводить глубокий исторический анализ при необходимости.
Преимущества:**
- Высокая производительность для запросов к текущим данным.
- Логическое разделение данных: актуальные и исторические.
Недостатки:**
- Усложнение ETL/ELT процесса, так как нужно управлять двумя таблицами.
- Анализ, требующий одновременного доступа к историческим и текущим данным, усложняется, так как требует `JOIN` или `UNION` между двумя таблицами.

Пример:
Клиент Анна Петрова переезжает из Москвы в Санкт-Петербург.

*Таблицы до изменений:*

`DimCustomer` (основная таблица)

CustomerID	FullName	City
:---	:---	:---
101	Анна Петрова	Москва

`HistoryCustomer` (историческая таблица) – *пустая*

*Процесс изменения:*

Перед обновлением основной таблицы, текущая строка (Анна в Москве) копируется в `HistoryCustomer`.
Затем основная таблица `DimCustomer` обновляется новым значением.

*Таблицы после изменений:*

`DimCustomer` (всегда хранит только актуальные данные)

CustomerID	FullName	City
:---	:---	:---
101	Анна Петрова	Санкт-Петербург

`HistoryCustomer` (накапливает историю)

HistoryID	CustomerID	FullName	City	StartDate	EndDate
:---	:---	:---	:---	:---	:---
1	101	Анна Петрова	Москва	2020-01-15	2024-08-15

Тип 5: Гибридный подход (Mini-Dimension + Type 1 Outrigger)

Идея: Вынести часто меняющиеся атрибуты из большой таблицы измерений в отдельную “мини-таблицу”, чтобы избежать “раздувания” основной таблицы.

Как работает:**
1. Из основной таблицы измерения (например, `DimCustomer`) выделяется группа атрибутов, которые часто меняются вместе (например, “Тарифный план”, “Статус подписки”).
2. Создается отдельная таблица — “мини-измерение” (например, `DimSubscriptionProfile`) — только для этих атрибутов. Эта мини-таблица управляется по SCD Тип 2 (добавление новой строки для каждого уникального набора значений).
3. В основной таблице `DimCustomer` эти атрибуты удаляются, и вместо них добавляется один внешний ключ (например, `SubscriptionProfileKey`), который ссылается на мини-измерение.
4. Этот ключ в основной таблице `DimCustomer` обновляется по принципу SCD Тип 1 (просто перезаписывается), указывая на *актуальную* запись в мини-измерении.
Когда использовать:** В очень больших (широких и/или с большим количеством строк) таблицах измерений, где лишь небольшая группа атрибутов меняется относительно часто. Это позволяет отслеживать историю этих атрибутов, не создавая новую многомиллионную запись в основной таблице при каждом изменении.
Преимущества:**
- Экономия места и контроль над ростом основной таблицы измерения.
- Позволяет вести детальную историю для подгруппы атрибутов.
Недостатки:**
- Более сложная модель данных, требующая дополнительных `JOIN`.
- Может быть сложнее для понимания конечными пользователями.

Пример:
Клиент Иван меняет свой тарифный план.

*Таблицы до изменений:*

`DimCustomer`

CustomerKey	FullName	SubscriptionProfileKey
:---	:---	:---
202	Иван Иванов	55

`DimSubscriptionProfile` (мини-измерение, управляется по SCD2)

ProfileKey	Plan	Status	IsCurrent
:---	:---	:---	:---
55	Basic	Active	Yes

*Процесс изменения:* Иван переходит на план “Premium”.

В `DimSubscriptionProfile` добавляется новая строка для “Premium”, а старая помечается как неактуальная.
В `DimCustomer` у Ивана обновляется ключ `SubscriptionProfileKey`.

*Таблицы после изменений:*

`DimCustomer` (здесь изменился только ключ)

CustomerKey	FullName	SubscriptionProfileKey
:---	:---	:---
202	Иван Иванов	56

`DimSubscriptionProfile` (здесь хранится вся история)

ProfileKey	Plan	Status	IsCurrent
:---	:---	:---	:---
55	Basic	Active	No
56	Premium	Active	Yes

Тип 6: Гибридный (Комбинация Типа 1, 2 и 3)

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

Как работает: Этот тип строится на основе **SCD Тип 2 (добавление новой строки для истории), но с добавлением атрибутов из SCD Тип 1 (перезапись) для упрощения некоторых запросов.
- Основная структура — это SCD Тип 2: есть строки для каждой исторической версии с полями `StartDate`, `EndDate` и `IsCurrent`. Поле атрибута (например, `City`) хранит значение, актуальное на тот исторический период.
- Дополнительно в таблицу добавляется столбец `CurrentCity`. Этот столбец для *всех* записей одного клиента (и исторических, и текущей) всегда хранит актуальное на данный момент значение (поведение SCD Тип 1).
Когда использовать:** Когда аналитикам часто нужно отвечать на два типа вопросов:
1. “Каким был город клиента на момент продажи?” (Используется историческое поле `City`).
2. “Каковы продажи всем клиентам, которые *сейчас* живут в Москве, за всю историю?” (Используется поле `CurrentCity` для фильтрации).
Преимущества:**
- Невероятная гибкость анализа без сложных `JOIN` или подзапросов для определения текущего состояния.
Недостатки:**
- Усложнение ETL/ELT. При изменении адреса нужно не только создать новую строку и закрыть старую, но и обновить поле `CurrentCity` во всех предыдущих строках для этого клиента. Это может быть ресурсозатратно.

Пример:
Снова Анна, переезжающая из Москвы в Санкт-Петербург.

*Таблица `DimCustomer` до изменений:*

SurrogateKey	CustomerID	City	CurrentCity	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Москва	Москва	2020-01-15	NULL	Yes

*Процесс изменения:*

Старая строка “закрывается” (обновляется `EndDate`, `IsCurrent` = ‘No’).
Создается новая актуальная строка.
Во всех строках для CustomerID=101 поле `CurrentCity` обновляется до “Санкт-Петербург”.

*Таблица `DimCustomer` после изменений:*

SurrogateKey	CustomerID	City	CurrentCity	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Москва	Санкт-Петербург	2020-01-15	2024-08-15	No
2	101	Санкт-Петербург	Санкт-Петербург	2024-08-16	NULL	Yes

Теперь можно легко отфильтровать по `City` для исторического анализа или по `CurrentCity` для анализа в разрезе текущего состояния.

Ссылки для дальнейшего изучения

Microsoft Fabric:** Slowly changing dimension type 2 https://learn.microsoft.com/en-us/fabric/data-factory/slowly-changing-dimension-type-two — Хорошее описание и пример реализации SCD Тип 2.
DataCamp:** Mastering Slowly Changing Dimensions (SCD) https://www.datacamp.com/tutorial/mastering-slowly-changing-dimensions-scd — Комплексный учебник по основным типам SCD.
HevoData:** Slowly Changing Dimensions(SCD): Types with Examples https://hevodata.com/learn/slowly-changing-dimensions/ — Детальное объяснение всех основных типов с примерами.
ThoughtSpot:** Slowly Changing Dimensions (SCD): 4 Types & How to ...https://www.thoughtspot.com/data-trends/data-modeling/slowly-changing-dimensions-in-data-warehouse — Еще один ресурс с обзором и сравнением типов SCD.

Идея: Концептуальная архитектура: SCD на стеке Lakehouse + Data Mesh + dbt

Основная идея заключается в создании надежных, версионируемых и децентрализованных “продуктов данных”, одним из которых является таблица измерений с полной историей (SCD). (Автоматическая)

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

Lakehouse (Основа): Это наша физическая среда. Мы используем открытое озеро данных (например, S3, ADLS) для хранения, а поверх него — табличный формат Apache Iceberg. Iceberg предоставляет нам ACID-транзакции, эволюцию схемы и, что самое важное для SCD, атомарные и эффективные операции `MERGE` (`UPDATE`/`INSERT`/`DELETE`) на уровне строк прямо в озере данных.

Data Mesh (Философия организации): Вместо централизованной команды данных, мы принимаем философию Data Mesh. A “Команда домена Клиенты” несет полную ответственность за все данные, связанные с клиентами. Их задача — предоставить остальной компании высококачественный продукт данных под названием `dim_customers`. Этот продукт должен включать полную историю изменений (SCD Type 2).

ETL/ELT (Процесс): Это конвейер, по которому данные текут от источника к потребителю.
- Extract & Load: Исходные данные (например, изменения в базе данных клиентов) захватываются с помощью CDC (Change Data Capture) инструментов типа Debezium и попадают в **Kafka. Оттуда они загружаются (Load) в “бронзовый” слой нашего Lakehouse (в сыром виде, в таблицы Iceberg).
- Transform: Здесь в игру вступает **dbt. Команда домена использует `dbt` для преобразования сырых данных из бронзового слоя в готовую к использованию модель в “серебряном” слое — нашу таблицу `dim_customers`.

dbt (Инструмент автоматизации SCD): `dbt` является сердцем автоматизации. Он не просто выполняет SQL-скрипты. У него есть встроенный функционал для реализации SCD Type 2, который называется `Snapshots`.

---

Сценарий 1: Автоматическое формирование SCD с помощью `dbt snapshots`

Это наиболее распространенный, надежный и идиоматический способ реализации идеи.

Как это работает:

Источник: У нас есть “бронзовая” таблица `bronze_customers`, которая содержит текущее состояние всех клиентов. Эта таблица обновляется периодически (например, раз в час) новыми данными из Kafka.
dbt Snapshot: В проекте `dbt` команда домена создает файл “снэпшота” (`snapshot/customers_snapshot.sql`). Внутри него описывается, как `dbt` должен отслеживать изменения.

{% snapshot customers_snapshot %}

    {{
        config(
          target_schema='silver',
          unique_key='customer_id',
          strategy='check',
          check_cols=['address', 'email', 'phone_number'],
          updated_at='last_modified_at',
        )
    }}

    select * from {{ source('bronze', 'customers') }}

    {% endsnapshot %}

Автоматизация: Оркестратор (например, Airflow) запускает команду `dbt snapshot` по расписанию.
Что делает dbt “под капотом”:
- Он сравнивает записи из исходной таблицы (`bronze_customers`) с текущими записями в целевой таблице (`silver.customers_snapshot`).
- Используя `unique_key` (`customer_id`), он находит совпадающие записи.
- С помощью стратегии `check` он проверяет, изменилось ли значение в любом из столбцов, перечисленных в `check_cols`.
- Если изменение обнаружено:
  - Он обновляет старую запись в целевой таблице, проставляя ей дату окончания актуальности (`dbt_valid_to`).
  - Он вставляет новую строку с обновленными данными и датой начала актуальности (`dbt_valid_from`).
- `dbt` генерирует одну атомарную операцию `MERGE` для таблицы Iceberg, которая эффективно выполняет все эти обновления и вставки за одну транзакцию.

Результат: В `silver.customers_snapshot` мы получаем идеальную таблицу SCD Type 2, которая обновляется автоматически и надежно, без написания сложной логики `MERGE` вручную.

Описание патерна Write-Audit-Publish

Sat, 16 Aug 2025 22:46:33 +0300

Кстати, хорошо ложится на git-like подход работы с данными.

Ссылка: https://habr.com/ru/articles/93773

Write-Audit-Publish (WAP) — это патерн проектирования в инженерии данных, предназначенный для повышения надежности и качества данных перед тем, как они станут доступны конечным потребителям (аналитикам, дашбордам, другим системам).

Основная цель WAP — предотвратить попадание некорректных, неполных или ошибочных данных в “production” среду. Вместо того чтобы записывать данные напрямую в целевую таблицу, процесс разделяется на три изолированных этапа lakefs.io.

Как это работает?

Процесс WAP состоит из трех логических шагов:

Write (Запись)
На этом этапе данные (новые или обновленные) записываются в промежуточную, изолированную область. Это может быть отдельная таблица, временный каталог в озере данных или, что более современно, отдельная ветка (branch) в табличном формате, таком как Apache Iceberg. Ключевой момент — эти данные не видны конечным потребителям.

Audit (Аудит/Проверка)
После записи данные в изолированной области подвергаются всесторонней проверке. Этот этап — сердце патерна. Проверки могут включать:

Технические проверки: соответствие схеме данных, отсутствие `NULL` в ключевых полях, уникальность идентификаторов.
Бизнес-логика: проверка на соответствие бизнес-правилам (например, сумма заказа не может быть отрицательной).
Статистические проверки: выявление аномалий и выбросов.
Сравнительные проверки: сверка с данными из других таблиц или систем.
Если аудит не пройден, данные остаются в изоляции для анализа и исправления, не затрагивая при этом рабочую среду.

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

Примеры использования и реализации

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

1. Apache Iceberg

Apache Iceberg, открытый табличный формат для озер данных, идеально подходит для реализации WAP благодаря своей поддержке ветвления (branching) и тегирования (tagging), похожей на Git.

Write: Новые данные записываются не в основную ветку `main`, а в отдельную ветку, например `ingestion_updates_20240816`.
Audit: Запросы на проверку качества данных выполняются исключительно к данным в этой новой ветке.
Publish: Если проверки прошли успешно, основная ветка `main` “перематывается” (fast-forward) на состояние ветки `ingestion_updates_20240816`. Эта операция метаданных происходит мгновенно и атомарно. Если проверки не пройдены, ветка просто удаляется www.tabular.io

Этот подход также позволяет координировать обновления для нескольких таблиц, используя общее имя ветки, проводить перекрестные проверки, а затем публиковать все изменения одновременно для обеспечения консистентности www.tabular.io.

2. Snowflake

В облачном хранилище данных Snowflake патерн WAP также может быть эффективно реализован.

Write: Данные загружаются во временную или “staging” таблицу.
Audit: С помощью SQL-запросов и инструментов, таких как `Snowflake Tasks`, выполняются проверки данных в этой staging-таблице.
Publish: Если данные корректны, они атомарно переносятся в основную, “production” таблицу с помощью команды `MERGE`, которая позволяет эффективно вставлять, обновлять и удалять строки за одну операцию www.getorchestra.io. Для отслеживания изменений в исходных таблицах часто используются `Snowflake Streams`.

Ключевые преимущества WAP

Повышение доверия к данным: Пользователи могут быть уверены, что данные, которые они видят, прошли строгую проверку качества.
Надежность конвейеров данных (pipelines): Сбои в процессе трансформации или загрузки не нарушают целостность данных в основной системе.
Изоляция и атомарность: Изменения либо применяются целиком, либо не применяются вовсе, что исключает “грязное чтение”.
Улучшенная отладка: Если данные не прошли аудит, они остаются в изолированной среде, где инженеры могут легко их проанализировать и исправить ошибку.

В итоге, WAP позволяет перейти от оркестрации, основанной на “успешности выполнения задачи”, к оркестрации, основанной на “готовности и качестве данных” www.tabular.io

Ссылки

Общее описание и важность патерна: What Is Write-Audit-Publish and Why Should You Care? lakefs.io
Реализация с Apache Iceberg: Write – Audit- Publish (WAP) Pattern – Tabular www.tabular.io
Пример реализации на AWS с Apache Iceberg: Write-Audit-Publish Pattern with Apache Iceberg on AWS www.guptaakashdeep.com
Реализация в Snowflake: Data Engineering Patterns: Write-Audit-Publish (WAP) – Snowflake www.getorchestra.io

Масштабируемые данные. 2-е изд. (Data Management at Scale)

Fri, 20 Jun 2025 21:28:47 +0300

Свежак, начал читать 📚 Около 700 рублей стоит цифровая версия тут

Вот обзор и рецензия на книгу «Масштабируемые данные от Gemini 2.5 Pro. Высоконагруженные архитектуры, Data Mesh и Data Fabric. 2-е изд.», основанные на информации об ее оригинальном издании “Data Management at Scale” за авторством Питхайна Стренгхолта.

Обзор и рецензия на книгу «Масштабируемые данные. 2-е изд.» Питхайна Стренгхолта

Эта книга является русским изданием работы Питхайна Стренгхолта “Data Management at Scale” и посвящена современным подходам к управлению данными в крупных организациях. Она фокусируется на архитектурных концепциях, таких как Data Mesh и Data Fabric, которые призваны решить проблемы традиционных монолитных систем, вроде централизованных озер и хранилищ данных.

О чем эта книга?

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

Ключевые концепции, разбираемые в книге:

Децентрализация и Data Mesh: Книга подробно описывает архитектуру Data Mesh, впервые предложенную Жэмаком Дегани и популяризированную Мартином Фаулером. Этот подход рассматривает данные как продукт и передает владение ими командам, которые эти данные создают и лучше всего понимают https://medium.com/it-architecture/review-data-management-at-scale-fc52fda45e0b. При этом метаданные остаются централизованными, что позволяет другим командам легко находить, понимать и использовать нужные им данные.
Данные как продукт (Data as a Product): Это фундаментальный сдвиг в мышлении. Данные перестают быть побочным эффектом работы приложений и становятся полноценным продуктом со своим жизненным циклом, владельцем, стандартами качества и SLA. Доступ к таким продуктам данных обычно предоставляется через стандартизированные API https://www.linkedin.com/pulse/data-mesh-book-review-beyond-antti-pikkusaari.
Архитектурные паттерны: Автор рассматривает различные шаблоны проектирования для создания продуктов данных и организации их взаимодействия в рамках компании https://www.oreilly.com/library/view/data-management-at/9781098138851/.

Сильные стороны

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

Критика и слабые стороны

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

Нехватка технических деталей: Книга отлично объясняет принципы, но не углубляется в конкретные технологии и инструменты. Например, она говорит о необходимости API для доступа к данным, но не предлагает детальных руководств по их созданию или выбору технологий https://www.linkedin.com/pulse/data-mesh-book-review-beyond-antti-pikkusaari.
Полет в облаках: Один из рецензентов на Goodreads метко подмечает, что книга «предпочитает витать в облаках», не опускаясь на более низкий уровень для разъяснения тонкостей. Например, остается не до конца ясным, где проходит грань между данными, метаданными и кодом в рамках одного «продукта данных» data-management-at-scale.

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

Кому стоит читать эту книгу?

Дата-архитекторам, CDO (Chief Data Officer) и руководителям отделов данных: Для них это мастрид. Книга поможет сформировать стратегическое видение и защитить новые подходы перед бизнесом.
Продукт-менеджерам и тимлидам: Поможет понять, как выстраивать процессы вокруг «данных как продукта» и эффективно взаимодействовать с другими командами.
Дата-инженерам и аналитикам: Будет полезна для понимания общей картины и современных трендов, но ее нужно будет дополнять более техническими статьями и докладами для практической реализации.

Заключение

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

Книга блестяще отвечает на вопрос «Зачем?», но оставляет читателю самому искать ответ на вопрос «Как?». Если вы архитектор или менеджер, отвечающий за стратегию данных, эта книга станет для вас ценным источником идей. Если вы инженер, ищущий готовые рецепты, — будьте готовы к тому, что это лишь отправная точка для дальнейших исследований.

Кабанчик отдыхает :) начинаем разводить рептилий 🐊

Ваш браузер не поддерживает видео.

Как навести порядок в хаосе данных: стратегия для бизнеса

Tue, 15 Apr 2025 21:13:12 +0300

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

Основное это RAG, втаскивание смысловых значение и аккумулирование всего в виде FAQ.

https://telegra.ph/Kak-navesti-poryadok-v-haose-dannyh-strategiya-dlya-biznesa-03-31

Мой фреймворк управления данными (Статья)

Sun, 30 Mar 2025 22:15:27 +0300

Оригинал: https://medium.com/zs-associates/my-data-governance-framework-c1879486bc09

За последние 10+ лет у меня была возможность быть автором или внести вклад в более чем 100 стратегий и фреймворков управления данными в различных отраслях. Хотя у каждой организации есть свои уникальные вызовы, я обнаружил, что определенный общий фреймворк неизменно служил эффективной отправной точкой для внедрения управления данными.

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

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

Стратегия

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

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

Области компетенции

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

Политики, стандарты и соответствие требованиям.** Управление начинается с четко определенных политик и стандартов, которые устанавливают правила, руководящие принципы и требования соответствия для управления данными во всей организации. Политики определяют, что необходимо сделать, устанавливая ожидания в отношении таких тем, как доступ к данным, качество и защита, а стандарты определяют, как эти ожидания реализуются с помощью конкретных процедур или пороговых значений. Важно отметить, что управление должно также включать возможность подтверждения соответствия этим политикам и стандартам посредством механизмов мониторинга, отчетности и аудита, обеспечивая подотчетность и соответствие нормативным требованиям.
Управление данными.** Может показаться немного странным иметь «управление данными» в качестве компетенции в рамках управления данными, но оно служит уникальной и основополагающей цели. Эта компетенция определяет и реализует роли, обязанности и подотчетность во всей модели управления. Она обеспечивает организационную основу, которая поддерживает все другие компетенции, разъясняя, кто отвечает за принятие каких решений и деятельность, как назначается право собственности и как координируется деятельность по управлению между бизнесом и ИТ. Это включает в себя определение владельцев данных, распорядителей, руководителей доменов, путей эскалации и форумов по управлению.
Метаданные и каталогизация.** Метаданные – данные о данных – необходимы для понимания, организации и управления информационными активами. Эта компетенция сочетает в себе управление метаданными с инструментами каталогизации и обнаружения данных для предоставления централизованного инвентаря активов данных, включая бизнес-определения, технические метаданные и происхождение данных. Управление метаданными также включает в себя определение минимальных стандартов метаданных, установление того, какие метаданные необходимо собирать и поддерживать, и где. Каталог данных строится на этой основе, делая метаданные доступными для поиска и доступными, позволяя пользователям находить, понимать и доверять данным, с которыми они работают. Это способствует прозрачности и демократизации данных, позволяя большему количеству пользователей в организации получать доступ к необходимым им данным.
Архитектура данных.** Эта статья посвящена фреймворку управления данными, а не архитектуре предприятия или фреймворку архитектуры решений. Таким образом, роль архитектуры данных здесь конкретно ограничена теми аспектами, которые пересекаются с управлением данными. Сюда входит обеспечение того, чтобы посредством программ изменений, процессов проектирования решений и механизмов архитектурного управления правильные средства контроля и соображения по управлению данными были встроены на раннем этапе жизненного цикла новых систем, потоков данных и процессов. Это соответствие имеет решающее значение, поскольку отдача от инвестиций в управление данными значительно выше, когда оно внедряется на этапе проектирования, а не когда средства контроля управления ретроспективно устанавливаются после создания и развертывания систем. Таким образом, архитектура данных становится фактором, способствующим устойчивому управлению данными в масштабах предприятия в соответствии с политикой.
Управление качеством данных.** Высококачественные данные являются основой надежной аналитики, искусственного интеллекта, нормативной отчетности и повседневных бизнес-операций. Эта компетенция охватывает ряд действий, которые обеспечивают соответствие данных цели, и ее обычно можно разбить на несколько различных областей. Во-первых, она начинается с понимания данных и формулирования четких бизнес-требований – какие данные необходимы, на каком уровне точности, своевременности или полноты и для какой цели. После установления этих требований организации могут обеспечить, чтобы правильные средства контроля качества данных были встроены в операционные процессы для предотвращения проблем в источнике (например, правила проверки в формах или автоматические проверки в каналах данных). Отдельная, но тесно связанная компетенция фокусируется на измерении самого качества данных, используя определенные метрики и методы профилирования для оценки данных по отношению к бизнес-требованиям. Кроме того, компетенция качества данных может включать в себя управление проблемами: структурированный процесс для выявления, документирования, отслеживания и устранения проблем с данными. Это позволяет организациям не только реагировать на проблемы с данными, но и анализировать основные причины и внедрять долгосрочные улучшения, обеспечивая надежность данных с течением времени.
Мастер-данные и справочные данные.** Управление мастер-данными и справочными данными управляет основными бизнес-сущностями данных (например, клиентами, продуктами, поставщиками), чтобы устранить дублирование, повысить согласованность и обеспечить единый источник истины. Во многих организациях эта компетенция поддерживается платформой управления мастер-данными (MDM). Платформа MDM обеспечивает централизованные рабочие процессы, создание золотой записи, сопоставление данных и синхронизацию между системами. Она играет решающую роль в обеспечении согласованности, целостности и точности данных, особенно для общекорпоративной отчетности и обработки транзакций.
Безопасность данных.** Безопасность данных обеспечивает защиту конфиденциальных, критически важных и регулируемых данных от несанкционированного доступа, неправильного использования или раскрытия в соответствии с политиками управления и схемами классификации данных. Это включает в себя внедрение и мониторинг контроля доступа на основе ролей, шифрование, токенизацию, маскирование, протоколы безопасной передачи данных и разделение обязанностей. Эффективное управление безопасностью данных также гарантирует, что меры безопасности соответствуют утвержденным политикам использования данных и регулярно тестируются и подтверждаются посредством проверок соответствия требованиям и оценок рисков.
Этика и конфиденциальность.** Технически, эту область можно интерпретировать как подпадающую под действие “Политики, стандарты и соответствие требованиям”, поскольку многие этические требования и требования конфиденциальности в конечном итоге регулируются посредством формальной политики. Однако часто стоит выделять их отдельно из-за их растущей актуальности и заметности – особенно с ростом искусственного интеллекта, алгоритмического принятия решений и усилением нормативного контроля. Эта компетенция фокусируется на обеспечении ответственного, справедливого и прозрачного использования данных путем определения этических принципов, практик конфиденциальности, процессов управления согласием и стратегий защиты персональных данных. Учитывая, насколько централизованными стали доверие и подотчетность в организациях, движимых данными, рассмотрение этики и конфиденциальности как отдельных компетенций помогает обеспечить, чтобы она получала необходимую видимость, право собственности и ресурсы.
Грамотность в области данных и культура.** Управление – это не только контроль, или не должно быть. Речь также идет о том, чтобы предоставить людям возможность эффективно и ответственно использовать данные. Эта компетенция способствует повышению грамотности в области данных, снабжая бизнес-пользователей и технических пользователей обучением, знаниями и инструментами, необходимыми им для интерпретации, доверия и действий на основе данных. Она включает в себя информационные кампании, образовательные ресурсы, передовые методы и поддержку самообслуживания для развития культуры, основанной на данных, во всей организации.

Адаптация фреймворка

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

Безопасность данных и архитектура данных** иногда явно не выделяются как часть фреймворка компетенции управления данными. Во многих организациях они рассматриваются как ответственность ИТ-функции или функции технологий, и предполагается, что соображения управления встроены в более широкие процессы архитектурного управления и управления безопасностью.
Грамотность в области данных** иногда переименовывается или перефразируется, называя ее управлением изменениями, расширением возможностей данных, пропагандой данных или продвижением данных. Во всех случаях основная цель, которая заключается в расширении возможностей пользователей и развитии культуры, основанной на данных, остается очень похожей.
Этика и конфиденциальность** иногда полностью встроены в более широкую компетенцию “Политики, стандарты и соответствие требованиям”, особенно когда этические принципы и принципы конфиденциальности уже формально кодифицированы посредством политических инструментов. В этих случаях основное внимание уделяется пониманию соответствующих нормативных требований (например, GDPR, HIPAA или законов, связанных с искусственным интеллектом), преобразованию их в действенные политики и стандарты, а затем обеспечению соответствия посредством структур управления, обучения и механизмов надзора.
Некоторые организации проявляют интерес к выделению возможности искусственного интеллекта или аналитики в качестве отдельной компетенции или управлению ими (“Управление искусственным интеллектом”). Лично я считаю, что большая часть того, что требуется для обеспечения надежной аналитики и искусственного интеллекта, может и должна обрабатываться с помощью существующих компетенций. Тем не менее, небольшое число организаций, с которыми я работал, предпочли рассматривать это как отдельную компетенцию, особенно когда управление моделями искусственного интеллекта/машинного обучения является текущим приоритетом.

Реализация (внедрение и исполнение)

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

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

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

Основные роли и обязанности**

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

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

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

Клиент** – Информация о физических или юридических лицах, которые покупают или используют ваши продукты или услуги.
Продукт** – Информация о предлагаемых товарах или услугах, в том числе структура, цены и описания.
Поставщик** – Информация о поставщиках, их контрактах и результатах их деятельности.
Финансовый** – Записи о доходах, расходах, бюджетах и других финансовых транзакциях.
Сотрудник** – Информация о персонале, в том числе роли, вознаграждение и история отдела кадров.
Продажи** – Данные о покупках, транзакциях и деятельности, приносящей доход.
Запасы и цепочка поставок** – Отслеживает уровни запасов, перемещение товаров и процессы доставки.
Маркетинг и кампании** – Захватывает кампании, расходы на рекламу и стратегии таргетинга.
Соответствие требованиям и нормативным требованиям** – Данные, используемые для выполнения юридических, аудиторских и нормативных обязательств.
Цифровая и веб-аналитика** – Измеряет, как пользователи взаимодействуют с цифровыми платформами и веб-сайтами.

Технологическое обеспечение

Технологии играют решающую роль в том, чтобы сделать управление данными практичным и масштабируемым. Хотя эти технологии соответствуют ключевым областям компетенции управления данными, они не сопоставляются 1:1, поскольку многие компетенции поддерживаются более широкими технологическими стеками или интегрированными решениями. Кроме того, то, как организации структурируют и развертывают эти технологии, может значительно варьироваться в зависимости от их размера, отрасли и зрелости данных.

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

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

Примеры: Collibra, Informatica Axon, Alation Stewardship Workbench
Качество данных.** Обеспечение высокого качества данных требует специализированных инструментов мониторинга, профилирования, очистки и исправления. Эти решения выявляют несоответствия, отсутствующие значения и ошибки, позволяя командам исправлять проблемы с данными в режиме реального времени и обеспечивать соблюдение стандартов качества данных в разных системах.

Примеры: Informatica Data Quality, Talend, Ataccama ONE
Каталог данных и наблюдаемость.** Каталоги данных предоставляют центральный инвентарь активов данных, объединяя метаданные, происхождение и бизнес-определения для повышения обнаружения и прозрачности данных. Все чаще каталоги объединяются с инструментами наблюдаемости данных для мониторинга работоспособности, свежести и поведения данных в режиме реального времени. Некоторые инструменты также предлагают автоматическое сканирование и классификацию данных по всему ландшафту данных.

Примеры: Alation, Collibra, BigID
Управление мастер-данными.** Платформы MDM необходимы для управления основными бизнес-сущностями, такими как клиенты, продукты и поставщики. Эти инструменты поддерживают сопоставление данных, создание золотой записи, рабочие процессы проверки и синхронизацию мастер-данных в разных системах. Они являются ключом к обеспечению согласованности в масштабах предприятия, удалению дубликатов и единому источнику истины для ключевых доменов данных.

Примеры: Informatica MDM, Reltio
Решения для обеспечения безопасности данных.** Эта категория включает в себя инструменты, которые управляют контролем доступа, шифрованием, маскированием, токенизацией и безопасной передачей данных. Она также поддерживает рабочие процессы запросов на доступ к данным, гарантируя, что только авторизованные пользователи могут получить доступ к конфиденциальным или классифицированным данным на основе политик управления и классификации данных.

Примеры: Immuta, Privacera, Microsoft Purview Data Security
Мониторинг этики, конфиденциальности и соответствия требованиям.** Эти инструменты поддерживают обеспечение соблюдения и мониторинг этичного использования данных, правил конфиденциальности (например, GDPR, HIPAA) и внутренних политик. Они предоставляют возможности для управления правами субъектов данных, отслеживания согласия, контрольных журналов и мониторинга использования, которые имеют решающее значение для укрепления доверия и выполнения нормативных обязательств.

Примеры: BigID, OneTrust, Collibra Protect

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

Управление управлением данными

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

Политики и стандарты**

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

Политика** говорит, что необходимо сделать. Это четкое правило, например, “данные о клиентах должны быть защищены”.
Стандарт** говорит, как это сделать. Он дает подробности, например, “зашифруйте данные о клиентах и храните их в течение 3 лет”.
Форумы управления**

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

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

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

Управление изменениями**

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

Заключение

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

DataHub 1.0

Sun, 30 Mar 2025 21:05:32 +0300

DataHub 1.0 уже здесь! Получите максимальную отдачу от нового UX

00:00:00 Введение и анонсы

• Приветствие участников и анонс гостей.
• Мэгги расскажет об обновлении дорожной карты DataHub.
• Паулина и Анна представят новый UX DataHub 10.
• Харшел из команды DataHub поделится новостями от Block.
• Шершанка, технический директор и соучредитель, подведет итоги.

00:01:01 Анонс DataHub 10

• Анонс DataHub 10 и ссылки на блог и видеоролики.
• Видео о начале проекта DataHub.

00:02:33 Важность DataHub

• DataHub как важный компонент инфраструктуры.
• Переход на DataHub и отключение собственного инструмента lineage.
• Расширение модели DataHub для поддержки элементов данных.

00:04:11 Обновления дорожной карты DataHub

• Мэгги рассказывает о последних обновлениях DataHub.
• Четыре столпа: открытие, управление, метаданные и наблюдаемость.
• Фокус на открытии данных и интеграции с новыми инструментами.

00:05:09 Открытие данных

• Фокус на человеко-ориентированном понимании данных.
• Интеграция с новыми инструментами, такими как MLflow и Cockroach DB.
• Разработка новых интеграций, включая Hex и Vertex AI.

00:07:32 Управление данными

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

00:10:52 Наблюдаемость данных

• Обеспечение доступности и демократизация качества данных.
• Централизованное отслеживание и разрешение инцидентов.
• Улучшения в утверждениях и расширенный поток инцидентов.

00:12:53 Основные направления проекта

• Фокус на API и SDK для автоматизации регистрации, обогащения и поиска данных.
• Важность качества обслуживания и аудита ведения журнала.
• Улучшение отслеживаемости событий в центре обработки данных.

00:13:40 Пакет SDK для Python

• Работа над улучшением пакета SDK для Python версии 2.
• API для регистрации, обогащения и извлечения данных.
• Вклад в документацию для улучшения понимания улучшений.

00:14:42 Учетные записи служб

• Внедрение учетных записей служб для команд.
• Управление автоматизацией и рабочими процессами.
• Призыв к обратной связи и сотрудничеству.

00:15:41 Будущие обновления и DataHub Cloud

• Опрос о будущих обновлениях DataHub и DataHub Cloud.
• DataHub Cloud как управляемый сервис с дополнительными возможностями.
• Переход к повестке дня и представлению UX-дизайнеров.

00:16:47 Дизайн продуктов в DataHub

• Инвестиции в дизайн продуктов в DataHub.
• Важность дизайна для инноваций и постоянного совершенствования.
• Использование данных и отзывов пользователей для улучшения продукта.

00:18:44 Принципы дизайна

• Философия дизайна: простота, обратная связь, последовательность.
• Создание системы проектирования в Figma и Storybook.
• Внедрение токенов и принципов для компонентов.

00:19:43 Примеры изменений

• Изменения в цветах и стилях кнопок и диаграмм.
• Введение специальных дизайнерских жетонов.
• Постепенные обновления пользовательского интерфейса.

00:20:54 Панель навигации и структурированные свойства

• Улучшение панели навигации для удобства пользователей.
• Гибкость отображения структурированных свойств.
• Постоянное совершенствование продукта на основе отзывов пользователей.

00:23:37 Введение и принципы последовательности

• Обсуждение предварительных просмотров вкладки “Стоп”.
• Введение в принципы согласованности и последовательности.
• Создание графической библиотеки для визуализации данных.

00:24:02 Итеративность и визуализация данных

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

00:25:46 Новые функции и панель вкладок

• Введение новой панели вкладок “Статистика”.
• Улучшение представления данных для пользователей.
• Демонстрация новых функций и взаимодействий.

00:28:27 Взаимодействие с пользователями

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

00:31:19 Обнаружение данных с агентами ИИ

• Введение в тему обнаружения данных с агентами ИИ.
• Представление Сэма Осборна и его роли в компании Block.
• Обзор управления данными и блокчейна в компании.

00:32:39 Проблемы и перспективы управления данными

• Переход на облачный сервис Data Hub.
• Проблемы и возможности каталогизации данных.
• Введение агентов ИИ для улучшения управления данными.

00:34:33 Демонстрация работы с Cloud Desktop

• Cloud Desktop настроен для взаимодействия с LLM.
• Возможность задавать вопросы о данных, связанных с домашними животными.
• Программа ищет данные на сервере Data Hub и предоставляет резюме.

00:35:23 Анализ данных и ключевые показатели

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

00:37:05 Использование Slack и Data Hub

• Возможность использовать Slack для планирования изменений в Data Hub.
• Программа помогает определить, на какие данные повлияет изменение.
• Возможность узнать, кому нужно сообщить об изменениях.

00:38:38 Демонстрация работы с Goose

• Goose – агент искусственного интеллекта с открытым исходным кодом.
• Интеграция с локальной и удаленной системами через расширения.
• Пример использования для поиска данных и владельцев данных.

00:43:39 Демонстрация работы в среде IDE

• Проект DBT с использованием идентификатора на базе искусственного интеллекта.
• Возможность проверять изменения в Data Hub и их влияние.
• Программа помогает избежать проблем и обеспечивает безопасность.

00:45:59 Введение в агентов искусственного интеллекта

• Агенты организуют контекстное управление разговорами с LLM.
• Интеграция с системами через протокол MCP.
• Агенты взаимодействуют с LLM и внешними службами данных.

00:47:50 Модель контекстного протокола MCP

• MCP – открытый стандарт для использования данных и инструментов в контексте взаимодействия с ИИ.
• Охватывает аспекты запроса данных, вызова служб и чтения/записи информации.
• Может использоваться для конкретных случаев использования и внешних серверов.

00:48:41 Агенты и спецификация MCP

• Представлен агент искусственного интеллекта с открытым исходным кодом codename goose.
• Спецификация MCP выпущена компанией Anthropic и является стандартным протоколом для ИИ.
• Обсуждается сотрудничество с ACRIL и улучшения Python SDK для приложений ИИ.

00:49:45 Демонстрация и использование codename goose

• Codename goose поддерживает стандарт MCP и позволяет подключаться к различным моделям и поставщикам.
• Демонстрационное видео показывает, как codename goose помогает в выполнении различных задач и упрощении рабочих процессов.

00:50:12 Интеграция и улучшения

• Агенты, стандарты MCP и центр обработки данных помогают быстрее подключать пользователей и интегрироваться с внутренними службами.
• Обсуждаются улучшения Python SDK для поиска сущностей и lineage, оптимизированных для интеграции с ИИ.

00:51:16 Будущее MCP

• В спецификацию MCP добавлены элементы авторизации с помощью OAuth и элементы для выборки и потоковой передачи.
• Ожидается появление множества официальных и неофициальных серверов MCP для различных приложений и сервисов.

00:51:50 Философия Data Hub

• Спецификация MCP вписывается в философию Data Hub, подчеркивающую важность стандартов и переносимости.
• Внедряются стандарты Open Lineage, Iceberg REST Catalog и MCP Model для более эффективного взаимодействия с метаданными.

00:53:02 Рекомендации и советы

• Видео на YouTube и ресурсы на GitHub подробно рассказывают о стандарте MCP.
• Профессиональный совет: делайте сеансы короткими, обобщайте данные и записывайте их в текст для предотвращения разрыва контекстного окна.

00:53:57 Заключение

• Агенты искусственного интеллекта и центр обработки данных помогают в обнаружении данных.
• Проект codename goose и его интеграция с Data Hub являются важными шагами в развитии ИИ.

00:54:38 Введение и прогресс проекта

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

00:55:50 Проблемы и решения центра обработки данных

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

00:56:32 Важность контекста для различных ролей

• Потребители данных ищут доверие и доступность данных.
• Специалисты по обработке данных беспокоятся о своевременности и изменениях.
• Руководители команд следят за доступом и использованием данных.

00:57:25 Управление искусственным интеллектом

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

00:59:16 Переход к машинно-ориентированному управлению

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

01:00:53 Заключение и благодарности

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

AI-агенты для хранилищ данных

Mon, 10 Mar 2025 21:46:43 +0300

Перевод: AI-агенты для хранилищ данных

Оригинал: https://dzone.com/articles/ai-agents-for-data-warehousing

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

Автор: Аджай Таниконда · 04 марта 2025 · Анализ

Термин “хранилище данных” был впервые введен в 1980-х годах и относится к практике хранения данных из различных источников внутри организации. Собранные данные затем используются для отчетности, принятия решений, точной аналитики, улучшения понимания клиентов и обработки специальных запросов.

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

DW Agent AI относится к агентам с искусственным интеллектом, которые оптимизируют различные аспекты хранилищ данных, от автоматизации ETL/ELT до оптимизации запросов и расширенной аналитики. Эти агенты используют алгоритмы машинного обучения, обнаружение аномалий и методы адаптивной оптимизации для улучшения обработки данных. Благодаря автоматизации они сокращают ручное вмешательство, повышают точность данных и оптимизируют скорость выполнения запросов, особенно на облачных платформах, таких как Google Cloud, AWS Redshift и Snowflake.

Google Cloud предлагает расширенную экосистему для хранилищ данных и аналитики, используя сервисы на основе искусственного интеллекта, такие как BigQuery, Cloud Dataflow и другие.

В этой статье мы рассмотрим, как DW Agent AI преобразует хранилища данных, сосредоточив внимание на его роли в автоматизации ETL/ELT, обработке данных на основе искусственного интеллекта, прогнозной аналитике и отчетности в реальном времени. Мы также обсудим практическую реализацию DW Agent AI и преимущества, которые он приносит современным предприятиям. Итак, как именно AI-агенты улучшают процесс хранилища данных, особенно в контексте анализа данных?

Понимание необходимости AI-агентов в хранилищах данных

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

Чтобы по-настоящему понять влияние AI-агентов на хранилища данных, мы должны рассмотреть пример использования. Представьте себе компанию, использующую аналитику на основе искусственного интеллекта для улучшения отчетности данных в Google Cloud.

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

Вот как AI-агенты могут помочь процессу хранилища данных с помощью анализа данных для обеспечения отчетности в Google Cloud:

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

Автоматизация ETL с DW Agent AI

Когда дело доходит до хранилищ данных, AI-агенты играют решающую роль в автоматизации ETL/ELT. ETL (Extract, Transform, Load) — это процесс сбора данных из нескольких источников, преобразования их в структурированный формат и загрузки в централизованное хранилище данных для углубленного анализа.

Традиционно процесс ETL/ELT сталкивался с рядом проблем. Извлечение данных вручную из различных источников является сложным, трудоемким и требует значительных ресурсов для обеспечения совместимости с предопределенной моделью данных. Кроме того, ручные процессы подвержены ошибкам и несоответствиям, которые могут поставить под угрозу целостность данных. AI-агенты устраняют эти неэффективности, автоматизируя процесс ETL/ELT, делая интеграцию данных плавной и значительно сокращая операционные издержки.

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

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

Обработка эволюции источника/схемы.** AI-агенты могут эффективно обнаруживать новые источники данных, извлекать релевантную информацию и обновлять важные наборы данных в режиме реального времени. Автоматическое обнаружение изменений схемы и адаптация ETL-конвейеров. Это приводит к минимальному количеству человеческих ошибок и оптимизирует процесс сбора данных.
Преобразование данных с помощью искусственного интеллекта.** С помощью алгоритмов машинного обучения AI-модели могут очищать, нормализовать и представлять данные в структурированном формате, что потребовало бы от традиционных инструментов ETL много времени.
Оптимизация инкрементной загрузки.** Идентификация дельт и интеллектуальное управление приемом данных с использованием системы отслеживания изменений данных (CDC) на основе машинного обучения.
Гарантия качества данных:** Применение разработанных AI-агентами средств обнаружения аномалий для выявления несоответствий, отсутствующих значений и дублирующихся записей до того, как они повлияют на последующую аналитику.
Самовосстанавливающиеся конвейеры.** Без какого-либо вмешательства человека AI-агенты могут не только идентифицировать несоответствия, но и исправлять их, что является революционным. Например, AI может обнаруживать смещение схемы в потоковых данных и автоматически корректировать преобразования, а не вызывать сбои.

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

Примеры использования анализа данных с AI-агентами

*Анализ данных*

Сбор и хранение данных

Основываясь на нашем текущем примере, компания использует Google Cloud для сбора и хранения любых релевантных необработанных данных в различных форматах. Некоторые из этих форматов включают JSON, CSV и т. д. Google Pub/Sub облегчает прием данных в режиме реального времени и связь между микросервисами, обеспечивая бесперебойную интеграцию. Это обеспечивает плавный прием и обработку данных в Google Cloud.

Обработка и оптимизация данных на основе искусственного интеллекта

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

Использование интеграции BigQuery AI.** AI-агенты используются и внедряются в BigQuery для удаления ошибок и дубликатов, а также для стандартизации категоризации продуктов в примере использования розничной компании.
Cloud dataflow для ETL.** AI-агенты улучшают процесс ETL с помощью Cloud Dataflow и преобразуют такие данные, как конвертация валют и расчеты скидок из необработанных источников.
Внесение корректировок.** AI-агенты уточняют и структурируют данные, обеспечивая их оптимизацию для анализа тенденций.
Адаптивная оптимизация запросов.** Использование методов обучения с подкреплением для постоянного улучшения планов выполнения запросов на основе исторической рабочей нагрузки.
Автоматизация материализованных представлений.** Динамическое создание и обновление материализованных представлений для ускорения часто используемых агрегаций и объединений.
Настройка параллельной обработки.** Оптимизация распределенного выполнения запросов путем интеллектуального распределения вычислительных ресурсов на основе моделей рабочей нагрузки.
Интеллектуальное индексирование.** Автоматическая рекомендация индексов и управление ими для повышения производительности запросов без чрезмерных затрат на хранение.

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

Прогнозная аналитика и обнаружение аномалий

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

Реальный вариант использования AI-агентов для хранилищ данных в этом контексте может включать следующее:

Прогнозирование продаж с помощью прогнозирования временных рядов.** С помощью AI-агентов компании могут анализировать исторические данные о продажах, чтобы предсказать, что их ждет в будущем. Помимо базового прогнозирования, AI может анализировать сезонность и рекламное воздействие для улучшения прогностических данных. Использование моделей глубокого обучения, таких как LSTM и архитектуры на основе Transformer, для прогнозирования спроса, продаж и операционных показателей.
Анализ клиентов и обнаружение аномалий.** AI-агенты анализируют модели покупок и поведение клиентов. Это позволяет компаниям разрабатывать персонализированные маркетинговые стратегии для улучшения оборота. Использование AI-моделей, таких как Isolation Forest и Autoencoders, для выявления необычных закономерностей в финансовых транзакциях, системных журналах и поведении клиентов.
Анализ запасов и аналитика в реальном времени.** AI-агенты могут идентифицировать запасы, которые продаются не оптимально. Таким образом, компания может оптимизировать свои стратегии пополнения запасов для обеспечения улучшения продаж. Развертывание предварительно обученных моделей в хранилищах данных для немедленной оценки и вывода, обеспечивающее оперативное понимание.

Отчетность в реальном времени и BI, улучшенная с помощью ИИ

После завершения обработки и анализа данных AI-агенты могут автоматизировать создание отчетов с помощью инновационных инструментов отчетности Google Cloud. Вот как работает процесс:

Looker от Google Cloud.** Используя Looker и интеграцию с AI, компании могут создавать интерактивные панели мониторинга. Это позволяет заинтересованным сторонам компании всегда иметь важную информацию о KPI (Key Performance Indicators, ключевые показатели эффективности). Примером отчетности на основе искусственного интеллекта может служить функция обнаружения AI-driven аномалий Looker. Автоматически сгенерированные аналитические данные с использованием естественного языка (например, функция Explain в Looker)
Отчеты с голосовым управлением.** С помощью NLP в Google Cloud AI-powered чат-боты могут предоставлять отчеты с голосовым управлением, которые помогают менеджерам и заинтересованным сторонам с упрощенными версиями данных.
Оповещения и уведомления.** Настраивая оповещения, AI-агенты могут запускать алармы и другие важные уведомления, чтобы ничего не осталось незамеченным.

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

Практическая реализация AI-агентов в хранилищах данных: DW Agent AI

DW Agent AI — это платформа, которая демонстрирует практическое применение искусственного интеллекта в хранилищах данных. Она преобразует базовые запросы в оптимизированные версии, используя такие методы, как:

Взаимодействие с данными на естественном языке
Автоматизация создания инсайтов
Оптимизация системы

Например, AI-агенты могут оптимизировать запросы для уменьшения сканирования данных в BigQuery:

Исходный запрос:

```sql
SELECT * FROM large_table WHERE status = ‘active’;
```

AI-оптимизированный запрос:

```sql
SELECT id, name, status
FROM large_table
WHERE status = ‘active’
AND created_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
```

Этот запрос применяет отсечение разделов (partition pruning), уменьшая объем сканируемых данных в BigQuery.

Каковы преимущества AI-агентов в хранилищах данных?

Когда дело доходит до внедрения AI-агентов в процессы хранилищ данных в Google Cloud, мы получаем несколько преимуществ, в том числе:

Больше никаких ручных усилий.** Когда дело доходит до избыточных и повторяющихся задач, AI устраняет их, преобразовывая роль инженеров в стратегических экспертов. Таким образом, инженерам и ученым по данным не нужно будет беспокоиться о фактическом извлечении данных; они могли бы использовать уже собранные данные, чтобы получить исключительные сведения.
Улучшенная точность.** Системы на основе искусственного интеллекта сведут к минимуму человеческие ошибки, гарантируя, что собранные данные будут точными, согласованными и более работоспособными.
Улучшенная масштабируемость.** Благодаря бессерверной инфраструктуре Google Cloud масштабируемость становится намного проще с ростом объемов данных. Это особенно полезно, поскольку уменьшается вероятность потери данных и подобных ошибок.
Экономичность.** Традиционная система хранилища данных требует не только различных инструментов, но и всей рабочей силы, чтобы всегда быть начеку. Когда мы внедряем оптимизацию на основе искусственного интеллекта, вы не только сокращаете использование облака, но и операционные издержки невозможно отрицать.

Будущее AI-агентов в хранилищах данных

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

Когда мы смотрим в будущее, AI в хранилище данных обязательно получит развитие. Мы можем увидеть бум хранилищ данных, которые будут самооптимизироваться без участия людей. Это может сэкономить время, деньги и усилия, когда компаниям необходимо анализировать данные и принимать важные решения. Примерами этого могут быть автономные хранилища данных (такие как автоматическая оптимизация Snowflake), автоматическое масштабирование BigQuery от Google и настройка ресурсов на основе искусственного интеллекта.

Окончательный вердикт

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

Расцвет одноузловой обработки: Бросая вызов подходу – распределённое решение в первую очередь

Sun, 23 Feb 2025 21:05:19 +0300

Перевод: https://www.pracdata.io/p/the-rise-of-single-node-processing

Введение

В 2024 году наблюдается растущий интерес к одноузловым системам обработки данных. Инструменты вроде DuckDB, Apache DataFusion и Polars привлекли внимание сообщества и стали невероятно популярными. Этот тренд — не просто технологический прогресс, а переосмысление подходов к аналитике данных.

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

Недавний пост «Почему одноузловые системы набирают обороты в обработке данных» в LinkedIn вызвал неожиданно живой отклик сообщества, что подчеркнуло возросший интерес к теме. В этой статье мы рассмотрим её подробнее.

---

Переосмысление «больших данных»

Последнее десятилетие компании активно внедряли стратегии big data, инвестируя в распределённые системы вроде Hadoop и Spark. Однако исследования показывают, что большинству компаний «большие данные» не нужны.

Итоги анализа:

Jordan Tigani (основатель Google BigQuery): медианный объём данных у активных пользователей BigQuery — менее 100 ГБ.
Исследование 500 млн запросов Amazon Redshift:
- 99% обрабатывали менее 10 ТБ данных;
- 90% сессий работали с менее чем 1 ТБ;
- 98% таблиц содержат меньше миллиарда строк.

Вывод: Для 90% запросов достаточно одноузловых систем вместо распределённых (Spark, Trino, Athena).

---

Паттерны рабочих нагрузок и старение данных

1. Эффект старения данных
Доступ к данным резко сокращается со временем:

Горячие данные (0–48 часов): обработка ETL-пайплайнами.
Тёплые данные (2–30 дней): основа аналитических запросов.
Холодные данные (30+ дней): редко запрашиваются (сохранены для истории или аудита).

Исследование Meta и eBay подтверждает: 95% обращений к данным происходят в первые 48 часов. В «золотой» аналитической зоне 95% запросов выполняются в течение 30 дней.

2. Правило 90/10
90% рабочих нагрузок приходится на 10% данных (за 30 дней). Даже при хранении данных год, аналитики в основном работают с последними 30 днями.

---

Эволюция оборудования: масштабирование вверх вместо распределения

Рост возможностей одноузловых систем:

В 2006 году (эпоха Hadoop) серверы имели 1 CPU и 2 ГБ RAM.
Сегодня облачные инстансы (например, AWS EC2) предлагают 64+ ядер и 256+ ГБ RAM.

Экономика масштабирования:

Стоимость крупных инстансов (например, m5.16xlarge) сопоставима с расходами на несколько мелких узлов (например, 8 × m5.2xlarge) при одинаковой мощности.

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

---

Производительность одноузловых систем
DuckDB, Apache DataFusion и другие движки используют:

Векторизованное выполнение запросов;
Параллелизм;
Оптимизацию использования памяти.

Примеры роста скорости:

Переход с Postgres на DuckDB дал ускорение в 4–200 раз (Vantage).
DuckDB превзошёл коммерческие хранилища на TPC-DS до 300 ГБ (Fivetran).

---

Причины выбрать одноузловую обработку

Простота: Меньше сложности, чем в распределённых системах.
Эффективность: Реализация до 80% кода на C/C++ (против 10% в распределённых движках).
Совместимость: Интеграция с облачными хранилищами, языками программирования, BI-инструментами.

---

Ограничения

Не все движки эффективно используют многоядерные CPU.
Пропускная способность RAM/CPU может стать узким местом.
Очень большие наборы данных (>1 ТБ) всё ещё требуют распределения.

---

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

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

---

Полный дословный перевод:

Введение

В 2024 году наблюдался растущий интерес к фреймворкам одноузловой обработки, при этом такие инструменты, как DuckDB, Apache DataFusion и Polars, привлекли повышенное внимание и завоевали беспрецедентную популярность в сообществе специалистов по данным.

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

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

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

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

Переосмысление больших данных

Последнее десятилетие многие предприятия изо всех сил пытались внедрить стратегии больших данных, при этом многие компании вкладывали значительные средства в фреймворки распределенной обработки, такие как Hadoop и Spark.

Однако недавние анализы выявили удивительную правду: у большинства компаний на самом деле нет “больших данных”.

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

Джордан Тигани, один из инженеров-основателей Google BigQuery, проанализировал шаблоны использования и обнаружил, что медианный размер хранилища данных среди активных пользователей BigQuery составляет менее 100 ГБ.

Ещё более показательным является анализ полумиллиарда запросов, выполненных в Amazon Redshift и опубликованных в статье:

Более 99% запросов обработали менее 10 ТБ данных.
Более 90% сеансов обработали менее 1 ТБ.

В статье также говорится, что:

Большинство таблиц содержит менее миллиона строк, и подавляющее большинство (98%) — менее миллиарда строк. Большая часть этих данных достаточно мала, чтобы её можно было кэшировать или реплицировать.

Этот анализ показывает, что при пороговом значении для больших данных в 1 ТБ более 90% запросов находятся ниже этого порога.

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

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

Шаблоны рабочей нагрузки и быстрое устаревание данных

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

Выявляются два ключевых шаблона: эффект устаревания данных и правило 90/10 для аналитических рабочих нагрузок.

Эффект устаревания данных

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

Активные данные (0-48 часов): в основном из конвейеров ETL.
Теплые данные (2-30 дней): составляют большую часть аналитических запросов.
Холодные данные (30+ дней): редко используются, но часто хранятся для соответствия требованиям или исторического анализа.

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

В нашем анализе озера данных петабайтного масштаба мы обнаружили, что необработанные данные остаются активными только в течение 48 часов, причем 95% доступа приходится на это время, в основном со стороны нисходящих конвейеров ETL. В зоне Analytics (Gold) активный период длится около 7 дней, и 95% запросов выполняются только в течение 30 дней.

Правило 90/10 для аналитических рабочих нагрузок

Этот эффект устаревания приводит к правилу 90/10 в аналитических рабочих нагрузках:

Если общий активный и теплый период составляет 30 дней и приходится на 90% рабочих нагрузок, то, при годовом сроке хранения, более 90% рабочих нагрузок получают доступ менее чем к 10% данных.

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

Эволюция оборудования и переосмысление масштабирования вверх

Возможности одноузловых систем экспоненциально выросли со времен зарождения больших данных.

Обоснование и мотивация стратегии масштабирования по горизонтали (scale-out), которая стала популярной с появлением Hadoop в середине 2000-х годов в области обработки данных, заключаются в необходимости объединения нескольких машин для решения проблем масштабирования, что позволяет эффективно обрабатывать большие наборы данных в разумные сроки и с приемлемым уровнем производительности.

Интегрируя несколько машин в распределенные системы, мы фактически создаем единый большой блок, объединяя ресурсы, такие как ОЗУ, ЦП, дисковое пространство и пропускную способность, в одну большую виртуальную машину.

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

В 2006 году, когда появился Hadoop MapReduce, первые инстансы AWS EC2 (m1.small) имели всего 1 ЦП и менее 2 ГБ ОЗУ. Сегодня облачные провайдеры предлагают инстансы с 64+ ядрами и 256 ГБ+ ОЗУ, что кардинально меняет ситуацию с возможностями одноузловой обработки.

Изучение эволюции сбалансированных инстансов EC2 с точки зрения памяти и ЦП (с соотношением 1:4) на протяжении многих лет выявляет экспоненциальный рост, поскольку эти инстансы со временем становятся все более мощными.

Экономика масштабирования вверх (Scale-Up) против масштабирования по горизонтали (Scale-Out)

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

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

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

Используя семейство инстансов m5 от AWS в качестве примера, независимо от того, масштабируетесь ли вы вверх с помощью одного инстанса m5.16xlarge или масштабируетесь по горизонтали с помощью восьми инстансов m5.2xlarge, цена за час останется той же.

Эта эволюция оборудования имеет важные последствия для решений по архитектуре системы, поскольку:

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

Это поднимает критический вопрос:

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

Аргумент производительности для одноузловой обработки

Современные одноузловые движки обработки используют передовые методы для достижения впечатляющей производительности.

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

Многочисленные тесты показывают эти улучшения производительности:

Vantage сообщила, что при переходе с Postgres на DuckDB для анализа затрат на облако они увидели улучшение производительности в диапазоне от 4X до 200X.
Тесты генерального директора Fivetran с использованием наборов данных TPC-DS показали, что DuckDB превосходит коммерческие хранилища данных для наборов данных размером менее 300 ГБ.
Эксперимент с 1 миллиардом строк поддельных данных о заказах, сравнивающий DuckDB с Amazon Athena.

Почему стоит выбрать одноузловую обработку?

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

Они значительно упрощают архитектуру системы, устраняя сложность распределенных систем. Это упрощение снижает эксплуатационные расходы, облегчает отладку и снижает порог входа для команд, работающих с данными.
Они часто обеспечивают лучшее использование ресурсов. Без накладных расходов на сетевую связь и распределенную координацию больше вычислительной мощности можно выделить для фактической обработки данных. Эта эффективность напрямую приводит к экономии затрат и повышению производительности.
Они предлагают отличную интеграцию с современными рабочими процессами обработки данных. Такие движки, как chDB и DuckDB, могут напрямую запрашивать данные из облачного хранилища, бесперебойно работать с популярными языками программирования и органично вписываться в существующие конвейеры обработки данных.
Встраиваемая природа некоторых из этих движков обеспечивает бесшовную интеграцию с существующими системами — от расширений PostgreSQL, таких как pg_analytics и pg_duckdb, до различных современных инструментов Business Intelligence — расширяя аналитические возможности без нарушения установленных рабочих процессов.

Проблемы и ограничения

Хотя одноузловая обработка предлагает много преимуществ, важно признать её ограничения.

Некоторые движки по-прежнему сталкиваются с проблемами полного использования всех доступных ядер ЦП на больших машинах, особенно по мере увеличения количества ядер. Пропускная способность иерархии памяти между ОЗУ и ЦП может стать узким местом для определенных рабочих нагрузок.
При чтении из облачного хранилища, такого как S3, скорость передачи данных через одно соединение может быть ограничена, хотя это часто можно смягчить с помощью параллельных соединений и интеллектуальных стратегий кэширования. И, естественно, остаются рабочие нагрузки, включающие очень большие наборы данных, которые превышают доступную память и хранилище, требующие распределенной обработки.

Заключение

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

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

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

Спасибо автору ALIREZA SADEGHI и оригиналу: https://www.pracdata.io/p/the-rise-of-single-node-processing

Ландшафт открытого исходного кода в области инженерии данных 2025

Thu, 13 Feb 2025 01:14:33 +0300

Перевод Open Source Data Engineering Landscape 2025

Введение

Сфера Open Source инструментов для инженерии данных продолжает стремительно развиваться, демонстрируя значительный прогресс в области хранения, обработки, интеграции и аналитики данных в 2024 году.

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

Хотя этот обзор публикуется ежегодно, соответствующий репозиторий GitHub обновляется регулярно в течение года. Не стесняйтесь вносить свой вклад, если заметите какой-либо недостающий компонент.

Методология исследования

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

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

Стек включает в себя озеро данных (S3), Parquet в качестве формата сериализации, DuckDB для обработки и аналитики, Apache NiFi для интеграции данных, Apache Superset для визуализации и PostgreSQL для управления метаданными, а также другие инструменты. Эта установка позволила мне собрать около 1 ТБ необработанных данных о событиях GitHub, состоящих из миллиардов записей, а также агрегированный набор данных, который накапливается ежедневно, в общей сложности более 500 миллионов записей за 2024 год.

Критерии выбора инструментов

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

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

Итак, без лишних слов, представляем обзор Open Source инструментов для инженерии данных 2025 года:

Обзор Open Source инструментов для инженерии данных 2025

Состояние Open Source в 2025 году

Экосистема Open Source инструментов для инженерии данных значительно выросла в 2024 году: в этом году в обзор добавлено более 50 новых инструментов, при этом удалено около 10 неактивных и архивных проектов. Хотя не все эти инструменты были запущены в 2024 году, они представляют собой важные дополнения к экосистеме.

Хотя этот рост демонстрирует постоянные инновации, в этом году также наблюдались некоторые тревожные события, связанные с изменением лицензирования. Устоявшиеся проекты, включая Redis, CockroachDB, ElasticSearch и Kibana, перешли на более закрытые и проприетарные лицензии, хотя Elastic позже объявила о возвращении к Open Source лицензированию.

Однако эти изменения были уравновешены значительным вкладом в Open Source сообщество со стороны крупных игроков отрасли. Вклад Snowflake в Polaris, открытие исходного кода Unity Catalog от Databricks, пожертвование OneHouse Apache XTable и выпуск Netflix Maestro продемонстрировали постоянную приверженность ведущих компаний отрасли разработке Open Source.

Фонд Apache сохранил свои позиции в качестве ключевого управляющего технологиями данных, активно инкубируя несколько перспективных проектов в течение 2024 года. Среди заметных проектов в инкубации были Apache XTable (универсальный формат таблиц), Apache Amoro (управление Lakehouse), Apache HoraeDB (база данных временных рядов), Apache Gravitino (каталог данных), Apache Gluten (промежуточное ПО) и Apache Polaris (каталог данных).

Фонд Linux также укрепил свои позиции в области данных, продолжая размещать такие исключительные проекты, как Delta Lake, Amundsen, Kedro, Milvus и Marquez. Фонд расширил свой портфель в 2024 году, добавив новые значительные проекты, включая vLLM, пожертвованный Калифорнийским университетом в Беркли, и OpenSearch, который был передан из AWS в Фонд Linux.

Open Source vs Open Core vs Open Foundation

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

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

Обзор категорий

Ландшафт инженерии данных разделен на 9 основных категорий:

* Системы хранения: базы данных и механизмы хранения, охватывающие OLTP, OLAP и специализированные решения для хранения.
* Платформа озера данных: инструменты и фреймворки для построения и управления озерами данных и Lakehouse.
* Обработка и интеграция данных: фреймворки для пакетной и потоковой обработки, а также инструменты обработки данных Python.
* Оркестрация рабочих процессов и DataOps: инструменты для оркестрации конвейеров данных и управления операциями с данными.
* Интеграция данных: решения для приема данных, CDC (Change Data Capture) и интеграции между системами.
* Инфраструктура данных: основные компоненты инфраструктуры, включая оркестрацию контейнеров и мониторинг.
* ML/AI платформа: инструменты, ориентированные на ML-платформы, MLOps и векторные базы данных.
* Управление метаданными: решения для каталогов данных, управления и управления метаданными.
* Аналитика и визуализация: BI-инструменты, фреймворки визуализации и аналитические механизмы.

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

Системы хранения

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

DuckDB стал историей крупного успеха, особенно после выпуска версии 1.0, которая продемонстрировала готовность к промышленному использованию для предприятий. Новая категория встраиваемых OLAP расширилась за счет новых участников, таких как chDB (построенный на ClickHouse), GlareDB и SlateDB, что отражает растущий спрос на легкие аналитические возможности обработки.

Расширения OLAP и HTAS

Значительным событием стало распространение новых расширений OLAP, особенно в экосистеме PostgreSQL.

Эти расширения позволяют легко расширять базы данных OLTP, преобразовывая эти системы в HTAP (гибридная транзакционная/аналитическая обработка) или новый механизм базы данных HTAS (гибридное транзакционное аналитическое хранилище), который интегрирует безголовое хранилище данных, такое как озера данных и lakehouse, с транзакционными системами баз данных.

Выпуск MotherDuck pg_duckdb стал важным шагом вперед, позволив DuckDB служить встроенным механизмом OLAP в PostgreSQL. За ним последовало расширение pg_mooncake, предоставляющее собственные возможности хранения столбцов в открытых табличных форматах, таких как Iceberg и Delta. Crunchy Data и ParadeDB внесли аналогичный вклад через pg_parquet и pg_analytics соответственно, обеспечивая прямую аналитику по файлам Parquet в озерах данных.

Архитектура без дисков (Zero-Disk)

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

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

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

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

Новые системы баз данных, включая базу данных временных рядов SlateDB и Apache HoraeDB, были построены с нуля с использованием этой архитектуры, в то время как устоявшиеся системы, такие как Apache Doris и StarRocks, приняли ее в 2024 году. Другие механизмы реального времени, такие как AutoMQ и InfluxDB 3.0, все чаще применяют парадигму без дисков.

Для всестороннего анализа архитектуры без дисков и ее последствий см. подробное исследование в следующей статье: Архитектура без дисков: будущее облачных систем хранения. https://www.pracdata.io/p/zero-disk-architecture-the-future

Другие заметные разработки

После перехода Redis на проприетарную лицензию в 2024 году Valkey стала ведущей альтернативой с открытым исходным кодом, став самой звездной системой хранения на GitHub в 2024 году. Крупные облачные провайдеры быстро приняли ее: Google интегрировал ее в Memorystore, а Amazon поддерживает ее через сервисы ElastiCache и MemoryDB.

Другие заметные разработки включают ParadeDB, альтернативу Elasticsearch, построенную на движке PostgreSQL, и новые гибридные системы потокового хранения, такие как Proton от TimePlus и Fluss, представленные Ververica. Эти системы направлены на интеграцию функций потоковой передачи и OLAP с основой хранения столбцов.

Платформа озера данных

Поскольку пионер баз данных Майкл Стоунбрейкер одобрил архитектуру lakehouse и открытые табличные форматы как «архетип OLAP СУБД на следующее десятилетие», lakehouse остается самой горячей темой в инженерии данных.

Ландшафт открытых табличных форматов продолжал значительно развиваться в 2024 году. Четвертый основной открытый табличный формат, Apache Paimon, вышел из инкубации, предоставив возможности потоковой передачи lakehouse с интеграцией Apache Flink. Apache XTable появился как новый проект, ориентированный на двунаправленное преобразование форматов, в то время как Apache Amoro вошел в инкубацию со своим фреймворком управления lakehouse.

В 2024 году Apache Iceberg зарекомендовал себя как ведущий проект среди фреймворков с открытым табличным форматом, отличающийся расширением своей экосистемы и метриками репозитория GitHub, включая большее количество звезд, форков, запросов на вытягивание и коммитов.

Все основные поставщики SaaS и облачных технологий улучшили свои платформы для поддержки доступа к открытым табличным форматам. Однако поддержка записи была менее распространена, причем Apache Iceberg был предпочтительным выбором для комплексной интеграции CRUD (Create, Read, Update, Delete).

Управляемые таблицы BigLake от Google, позволяющие изменять таблицы Iceberg в облачном хранилище, управляемом клиентом, недавно анонсированные таблицы S3 от Amazon с нативной поддержкой Iceberg, а также другие основные инструменты SaaS, такие как Redpanda, запускающие Iceberg Topics, и Crunchy Data Warehouse, глубоко интегрирующиеся с Apache Iceberg, являются примерами растущего внедрения и глубокой интеграции с Iceberg в экосистеме.

В будущем универсальные табличные форматы, такие как Apache XTable и Delta UniForm (Delta Lake Universal Format), могут столкнуться со значительными трудностями в навигации по потенциальному расхождению функций в различных форматах, а судьба открытых табличных форматов может отражать судьбу открытых файловых форматов, когда Parquet стал фактическим стандартом.

По мере того, как экосистема lakehouse продолжает расти, ожидается, что внедрение совместимых открытых стандартов и фреймворков в рамках платформы Open Data Lakehouse приобретет большую популярность.

Появление библиотек нативных табличных форматов

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

Яркими примерами являются Delta-rs, нативная библиотека Rust для Delta Lake со связями Python; Hudi-rs, реализация Rust для Apache Hudi с API Python, и PyIceberg, развивающаяся библиотека Python, предназначенная для улучшения доступа к табличному формату Iceberg за пределами движка Spark по умолчанию.

Обработка и интеграция данных

Подъем одноузловой обработки

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

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

Современные механизмы одноузловой обработки, такие как DuckDB, Apache DataFusion и Polars, стали мощными альтернативами, способными обрабатывать рабочие нагрузки, которые ранее требовали распределенных систем, таких как Hive/Tez, Spark, Presto или Amazon Athena.

Чтобы ознакомиться с полным анализом состояния одноузловой обработки, перейдите по ссылке ниже: https://www.pracdata.io/p/the-rise-of-single-node-processing или тут есть перевод https://gavrilov.info/all/rascvet-odnouzlovoy-obrabotki-brosaya-vyzov-podhodu-raspredelyon/

Потоковая обработка

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

Отмечая свое 10-летие, Flink выпустил версию 2.0, представляющую первое крупное обновление с момента дебюта Flink 1.0 восемь лет назад. Экосистема Apache Flink значительно расширилась с появлением открытого табличного формата Apache Paimon и недавно открытого движка потоковой обработки Fluss. В 2024 году ведущие облачные провайдеры все чаще интегрировали Flink в свои управляемые сервисы, последним из которых стало бессерверное решение Google BigQuery Engine для Apache Flink.

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

В главных новостях потоковой передачи с открытым исходным кодом Redpanda приобрела Benthos.dev, переименовав ее в Redpanda Connect и переведя на более проприетарную лицензию. В ответ WarpStream создал форк проекта Benthos, переименовав его в Bento и обязавшись сохранить его 100% лицензированным по MIT.

Фреймворки обработки Python

В экосистеме обработки данных Python Polars в настоящее время является доминирующей высокопроизводительной библиотекой DataFrame для задач инженерии данных (за исключением PySpark). Polars достиг впечатляющих 89 миллионов загрузок в 2024 году, отметив важный этап выпуска версии 1.0.

Однако теперь Polars сталкивается с конкуренцией со стороны API DataFrame от DuckDB, который привлек внимание сообщества своей удивительно простой интеграцией с внешними системами хранения и интеграцией без копирования (прямое совместное использование памяти между различными системами) с Apache Arrow, аналогично Polars. Обе библиотеки входят в 1% самых загружаемых библиотек Python в прошлом году.

Apache Arrow укрепил свои позиции в качестве фактического стандарта для представления данных в памяти в экосистеме обработки данных Python. Фреймворк установил глубокую интеграцию с различными фреймворками обработки Python, включая Apache DataFusion, Ibis, Daft, cuDF и Pandas 3.0.

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

Оркестрация рабочих процессов и DataOps

В 2025 году категория оркестрации рабочих процессов с открытым исходным кодом продолжает оставаться одним из самых динамичных сегментов экосистемы инженерии данных, включающей более 10 активных проектов, от устоявшихся платформ, таких как Apache Airflow, до недавно открытых движков, таких как Maestro от Netflix.

После десятилетия Apache Airflow продолжает оставаться наиболее развернутым и принятым движком оркестрации рабочих процессов с ошеломляющими 320 миллионами загрузок только в 2024 году, сталкиваясь с конкуренцией со стороны растущих конкурентов, таких как Dagster, Prefect и Kestra.

Интересно, что Kestra получил наибольшее количество звезд на GitHub в 2024 году, причем всплеск напрямую связан с объявлением о его финансировании в размере 8 миллионов долларов в сентябре, которое было опубликовано на TechCrunch. С точки зрения активности кода, Dagster продемонстрировал замечательную активность разработки с впечатляющими 27 000 коммитов и почти 6 000 закрытыми запросами на вытягивание в 2024 году.

Для всестороннего анализа состояния систем оркестрации рабочих процессов прочтите следующую статью: https://www.pracdata.io/p/state-of-workflow-orchestration-ecosystem-2025

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

Great Expectations продолжает оставаться ведущим фреймворком Python для обеспечения качества данных и валидации, также представленным в 10 лучших продуктах Databricks для данных и ИИ 2024 года, за которым следуют Soda и Pandera в практике инженерии данных. Однако есть и разочаровывающие новости: проект Data-Diff был заархивирован своим основным разработчиком, Datafold, в 2024 году.

Версионирование данных

Версионирование данных остается важной темой в 2024 году, поскольку продолжаются усилия по внедрению возможностей современных систем управления версиями, таких как Git, в озера данных и lakehouse.

Такие проекты, как LakeFS и Nessie, улучшают современные озера данных и открытые табличные форматы, такие как Iceberg и Delta Lake, за счет расширения их транзакционных уровней метаданных.

Преобразование данных

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

В настоящее время dbt сталкивается с конкуренцией в основном со стороны SQLMesh. Примечательным противостоянием в 2024 году стали дебаты SQLMesh против dbt, освещенные генеральным директором Tobiko, который заявил в социальных сетях, что SQLMesh настолько хорош, что его запретили на конференции Coalesce от dbt!

Интеграция данных

В области интеграции данных Airbyte сохранил свои лидирующие позиции, достигнув впечатляющей вехи, закрыв 13 000 запросов на вытягивание в рамках подготовки к версии 1.x. Фреймворк dlt продемонстрировал значительное созревание с выпуском версии 1.0, в то время как Apache SeaTunnel набрал обороты в качестве убедительной альтернативы.

Ландшафт фреймворков Change Data Capture (CDC) развивался с появлением новых инструментов, включая Artie Transfer и PeerDB (приобретен ClickHouse), в то время как коннекторы Flink CDC получают распространение среди платформ, использующих Flink в качестве основного движка потоковой передачи.

Центры событий (службы потоковой публикации/подписки)

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

Эта модель также обеспечивает гибкую стратегию развертывания Bring Your Own Cloud (BYOC), поскольку как вычисления, так и хранилище могут размещаться в предпочитаемой клиентом инфраструктуре, в то время как поставщик услуг поддерживает плоскость управления.

Успех WarpStream побудил крупных конкурентов принять аналогичные архитектуры. Redpanda запустила Cloud Topics, улучшив свои предложения, в то время как AutoMQ реализовала гибридный подход с быстрым уровнем кеширования для повышения производительности ввода-вывода.

Кроме того, StreamNative представила движок Ursa для Apache Pulsar, а Confluent представила свои собственные облачные кластеры Freight Clusters в 2024 году. В конечном итоге Confluent решила приобрести WarpStream, еще больше расширив свое предложение с помощью модели BYOC. Между тем, замечательный Apache Kafka стоит на распутье, которое может определить его дальнейшее направление в экосистеме.

Инфраструктура данных

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

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

ML/AI платформа

Векторные базы данных сохранили сильный импульс с 2023 года, причем Milvus стала лидером наряду с Qdrant, Chroma и Weaviate. В настоящее время эта категория включает десять активных проектов векторных баз данных, что отражает растущую важность возможностей векторного поиска в современных архитектурах данных с поддержкой ИИ.

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

Управление метаданными

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

Однако наиболее заметные события в 2024 году произошли в управлении каталогами. В то время как в 2023 году доминировала конкуренция в открытых табличных форматах, 2024 год ознаменовал начало «войны каталогов».

В отличие от предыдущих лет, в 2024 году на рынок вышла волна новых решений для открытых каталогов, включая Polaris (открытый исходный код от Snowflake), Unity Catalog (открытый исходный код от Databricks), LakeKeeper и Apache Gravitino.

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

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

Аналитика и визуализация

В области бизнес-аналитики с открытым исходным кодом Apache Superset и Metabase остаются ведущими BI-решениями. В то время как Superset лидирует по популярности на GitHub, Metabase демонстрирует наивысшую активность разработки. Lightdash стал многообещающим новичком, получив финансирование в размере 11 миллионов долларов и продемонстрировав рыночный спрос на легкие BI-решения.

BI-as-Code решения

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

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

В дополнение к Streamlit и известному Evidence новые участники, такие как Quary и Vizro, набрали обороты, причем Quary, в частности, реализовал подход на основе Rust, который отличается от нормы, ориентированной на Python, в этой категории.

Компонуемый BI-стек

Эволюция декомпозиции систем не ограничивается системами хранения; она также повлияла на стеки бизнес-аналитики (BI). Появляется новая тенденция, которая сочетает в себе легкие, бездонные BI-инструменты (которые не имеют внутреннего сервера) с безголовыми встраиваемыми решениями OLAP, такими как Apache DataFusion, Apache Arrow и DuckDB.

Эта интеграция устраняет несколько пробелов в BI-стеке с открытым исходным кодом, таких как собственная способность запрашивать внешние озера данных и lakehouse, сохраняя при этом преимущества легких, дезагрегированных архитектур.

BI-продукты, такие как Omni, GoodData, Evidence и Rilldata, уже включили эти движки в свои BI-инструменты и инструменты исследования данных. Как Apache Superset (с использованием библиотеки duckdb-engine), так и Metabase теперь поддерживают встроенные подключения DuckDB.

Для всестороннего анализа развивающейся компонуемой BI-архитектуры см. подробное исследование в следующей статье: https://www.pracdata.io/p/the-evolution-of-business-intelligence-stack

Перевод тут https://gavrilov.info/all/evolyuciya-biznes-analitiki-ot-monolitnoy-k-komponuemoy-arhitekt/

MPP Query Engines

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

В то время как доля Hive сокращается, Presto и Trino по-прежнему остаются лучшими движками запросов MPP с открытым исходным кодом, используемыми в производстве, несмотря на жесткую конкуренцию со стороны Spark как унифицированного движка и управляемых облачных продуктов MPP, таких как Databricks, Snowflake и AWS Redshift Spectrum плюс Athena.

Перспективы на будущее и заключение

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

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

Дальнейшая консолидация в области открытых табличных форматов
Продолжающаяся эволюция архитектур без дисков в системах реального времени и транзакционных системах
Стремление к предоставлению унифицированного опыта lakehouse
Подъем LLMOps и AI Engineering
Расширение экосистемы lakehouse в таких областях, как интеграция открытых каталогов и разработка нативных библиотек
Растущая популярность одноузловой обработки данных и встроенной аналитики

DolphinScheduler and SeaTunnel vs AirFlow and NiFi

Mon, 13 Jan 2025 23:42:39 +0300

Оригинал: https://apachedolphinscheduler.substack.com/p/dolphinscheduler-and-seatunnel-vs

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

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

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

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

---

1. DolphinScheduler vs Apache Airflow

Преимущества DolphinScheduler

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

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

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

Интеграция с экосистемой больших данных:
- Глубокая интеграция с экосистемами больших данных (например, Hadoop, Hive, Spark, Flink), поддержка множества типов задач (Shell, Python, SQL, MapReduce и т.д.).
- Расширение возможностей интеграции данных через плагины.

Простота развертывания и масштабируемость:
- Скрипты для быстрого развертывания и поддержка контейнеризации (например, Docker и Kubernetes), что упрощает обслуживание и масштабирование.

Недостатки DolphinScheduler

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

Преимущества Apache Airflow

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

Богатая экосистема плагинов:
- Большое количество плагинов, поддерживаемых сообществом (300+ официальных плагинов), что решает разнообразные задачи интеграции и обработки данных.

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

Недостатки Apache Airflow

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

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

---

2. SeaTunnel vs Apache NiFi

Преимущества SeaTunnel

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

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

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

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

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

Недостатки SeaTunnel

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

Ограниченная возможность кастомизации:
- По сравнению с архитектурой плагинов NiFi, разработка пользовательских плагинов в SeaTunnel более сложна.

Преимущества Apache NiFi

Графический интерфейс:
- Интерфейс drag-and-drop для определения и управления потоками данных, что делает его удобным для нетехнических пользователей.

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

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

Недостатки Apache NiFi

Более низкая производительность:
- Уступает SeaTunnel в сценариях с высокой нагрузкой и задачами с низкой задержкой.

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

---

3. Итог

Сильные стороны DolphinScheduler и SeaTunnel

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

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

---

О Apache SeaTunnel

Apache SeaTunnel — это простая в использовании, высокопроизводительная распределенная платформа для интеграции данных, поддерживающая синхронизацию огромных объемов данных в реальном времени и способная стабильно и эффективно синхронизировать сотни миллиардов данных в день.

Присоединяйтесь к сообществу Apache SeaTunnel и способствуйте развитию открытого исходного кода!

Присоединяйтесь к нам сейчас! ❤️❤️

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

Sat, 05 Oct 2024 22:10:17 +0300

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

Alchemesh core concepts

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

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

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

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

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

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

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

Data domains

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

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

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

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

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

Вид data domain

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

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

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

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

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

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

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

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

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

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

Data product

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sat, 05 Oct 2024 21:29:56 +0300

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

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

Sat, 05 Oct 2024 20:56:17 +0300

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

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

Предисловие

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

КЕЙС
Maritime Data Space Finland

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Data products, data space и data mesh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глоссарий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Издатель
Sitra

Прогноз
23

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

ISSN (PDF)
2737-1042

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

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

Fri, 04 Oct 2024 20:17:00 +0300

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

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

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

Yuriy Gavrilov: posts tagged Data Governance

Мир без Kafka: Почему Kafka не подходит для аналитики реального времени, что идет на смену)

Эволюция потоковых данных

Новичок на районе

Поток как таблица (Stream as Table)

Колоночное хранение (Columnar Storage)

Унификация с Lakehouse

Светлое будущее впереди

Data Contracts — соглашение между производителями и потребителями данных

о книге «Data Contracts» или как договориться о данных в эпоху хаоса и вернуть им ценность

Приложение пример полей и контракта данных

Еще один дата каталожик – Marmot

От «зоопарка» технологий к Lakehouse: Итоги разговора с Вадимом Беловым

1. Предел «классической» архитектуры

2. Lakehouse как эволюционное решение

3. Преимущества и новые возможности

4. Практика реализации и вызовы

5. Советы для бизнеса и архитекторов

Итог встречи

Построение надежных ML-систем и технический долг

Часть 1. Карта жизненного цикла ML-проекта

Фаза 1: Исследования (Research)

Фаза 2: Эксплуатация (Operations / MLOps)

Часть 2. «Скрытый технический долг в системах машинного обучения»

Ключевые источники технического долга в ML:

Часть 3. Практические выводы

Рекомендации по созданию надежных ML-систем

Заключение

Скрытый технический долг в системах машинного обучения

Аннотация

1. Введение

2. Размывание границ из-за сложности моделей

3. Зависимости от данных стоят дороже зависимостей от кода

4. Петли обратной связи

5. Антипаттерны МО-систем

Распространённые «запахи» кода в МО

6. Долг конфигурации

7. Работа с изменениями во внешнем мире

8. Другие области долга, связанного с МО

9. Выводы: Измерение и выплата долга

Сводная статья: Основы проектирования современного хранилища данных

Часть 1: Сводный перевод статей

(I) Принципы архитектуры модели данных: Четыре уровня и семь этапов, «краеугольный камень» моделирования Data Lake и хранилищ данных

(II) Полное руководство по основным стандартам проектирования хранилищ данных: от уровней и типов до жизненного цикла

Часть 2: Разбор методологии — от уровней до жизненного цикла

Четыре архитектурных уровня

Семь этапов жизненного цикла данных

Итог: Создание современного хранилища данных

Описание патерна Slowly Changing Dimensions (SCD)

Основные типы SCD

Тип 1: Перезапись атрибута (Overwrite)

Тип 2: Добавление новой строки (Add New Row)

Тип 3: Добавление нового атрибута (Add New Attribute)

Другие типы SCD

Тип 4: Добавление исторической таблицы (History Table / Audit Table)

Тип 5: Гибридный подход (Mini-Dimension + Type 1 Outrigger)

Тип 6: Гибридный (Комбинация Типа 1, 2 и 3)

Ссылки для дальнейшего изучения

Сценарий 1: Автоматическое формирование SCD с помощью `dbt snapshots`

Описание патерна Write-Audit-Publish

Как это работает?

Примеры использования и реализации

1. Apache Iceberg

2. Snowflake

Ключевые преимущества WAP

Ссылки

Масштабируемые данные. 2-е изд. (Data Management at Scale)

Обзор и рецензия на книгу «Масштабируемые данные. 2-е изд.» Питхайна Стренгхолта

О чем эта книга?

Сильные стороны

Критика и слабые стороны

Кому стоит читать эту книгу?

Заключение

Как навести порядок в хаосе данных: стратегия для бизнеса

Мой фреймворк управления данными (Статья)

DataHub 1.0

AI-агенты для хранилищ данных

Перевод: AI-агенты для хранилищ данных

Расцвет одноузловой обработки: Бросая вызов подходу – распределённое решение в первую очередь

Ландшафт открытого исходного кода в области инженерии данных 2025