Yuriy Gavrilov: posts tagged Data Mesh

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

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

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

Масштабируемые данные. 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.

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

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

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

От архитектуры data lakehouse к data mesh

Mon, 24 Mar 2025 22:35:36 +0300

Перевод: https://medium.com/adevinta-tech-blog/from-lakehouse-architecture-to-data-mesh-c532c91f7b61

От архитектуры data lakehouse к data mesh

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

От централизованного к децентрализованному: почему мы это делаем?

В начале у нас была централизованная команда данных, которая отвечала за сбор, обработку и обслуживание всех данных в организации. Мы построили data lakehouse на основе облачных хранилищ, таких как AWS S3, и движков обработки, таких как Spark и Databricks. Эта централизованная архитектура хорошо работала в начале, когда наши потребности в данных были относительно простыми.

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

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

Чтобы преодолеть эти проблемы, мы решили перейти к архитектуре data mesh. Data mesh – это децентрализованный подход к управлению данными, который наделяет конкретные бизнес-подразделения (domain) ответственностью за их собственные данные. Каждое business domain владеет своими данными, разрабатывает и обслуживает свои конвейеры данных, а также предоставляет свои данные другим domain в виде продуктов данных.

Путь к Data Mesh: этапы и решения

Наш переход к data mesh является постепенным процессом, который включает в себя несколько этапов.

Шаг 1: Выявление и приведение в соответствие Domains:

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

Шаг 2: Объявление Domain Data Owners:

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

Шаг 3: Определение продукта данных:

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

Шаг 4: Создание самостоятельной платформы данных:

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

В Adevinta мы опираемся на существующую инфраструктуру data lakehouse и развиваем ее для поддержки data mesh. Это включает в себя:

Централизованный каталог данных:** Каталог данных предоставляет всем domains доступ к метаданным и схемам данных, позволяя им обнаруживать и понимать продукты данных, доступные в организации.
Стандарты качества данных:** Централизованная команда данных поддерживает стандарты качества данных и политики, чтобы обеспечить высокое качество данных. Команды доменов несут ответственность за соблюдение этих стандартов и политик.
Аутентификация, авторизация и аудит (AAA):** Централизованная AAA защищает доступ к данным и соответствие требованиям безопасности.
Мониторинг и оповещения:** Платформа предоставляет централизованные панели мониторинга и оповещения, позволяющие domains проактивно отслеживать состояние и производительность своих конвейеров данных.

Шаг 5: Обучение, пропаганда и повторение:

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

Решения, которые нам необходимо было принять:

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

Определение границ domain:** Критически важно определить границы каждого domain четким и однозначным образом. Это гарантирует, что каждая domain четко понимает данные, за которые она несет ответственность.
Выбор технологии:** необходимо тщательно выбирать правильную технологию для data mesh. Платформа должна быть самообслуживаемой, надежной и безопасной.
Управление изменениями:** Переход к data mesh требует значительных изменений в том, как организация относится к управлению данными. Важно справиться с этими изменениями эффективным образом.

Преимущества Data Mesh

Реализовав архитектуру data mesh, мы ожидаем получить следующие преимущества:

Улучшенная скорость доставки:** domains могут самостоятельно разрабатывать и развертывать свои конвейеры данных, сокращая время, необходимое для предоставления новых продуктов данных.
Повышенное владение:** domains имеют полный контроль над своими данными, что позволяет им внедрять инновации и экспериментировать с использованием данных.
Улучшенная масштабируемость:** архитектура data mesh более масштабируема, чем централизованная архитектура, позволяя нам адаптироваться к растущему объему и сложности данных.
Повышение качества данных:** domains лучше осведомлены о своих данных, что ведет к более высокому качеству данных.

Вывод

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

Статья переведена с помощью gtp4o search preview – без доступа через VPN

Эволюция бизнес-аналитики: от монолитной к компонуемой архитектуре

Thu, 13 Feb 2025 01:23:28 +0300

Перевод: https://www.pracdata.io/p/the-evolution-of-business-intelligence-stack

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

Это первая часть нашей серии, посвященная эволюции архитектуры бизнес-аналитики (BI).

Введение

Ландшафт бизнес-аналитики (BI) претерпел значительные преобразования в последние годы, особенно в том, как данные представляются и обрабатываются.

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

В этой статье прослеживается эволюция BI-архитектуры через несколько ключевых этапов: от традиционных монолитных систем, через появление безголовой (headless) и бездонной (bottomless**) BI, до последних разработок в области BI-as-Code и встроенной аналитики.

** 😂 👯‍♀️

Если серьезно, то наверное лучший вариант бескрайний

Традиционная BI-архитектура: Монолитный подход

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

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

*Традиционный BI-стек*

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

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

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

Недостатки традиционных BI-инструментов

Хотя эти традиционные системы были мощными, они имели значительные накладные расходы.

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

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

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

Появление бездонных (Bottomless) BI-инструментов

В ответ на эти вызовы появилось новое поколение легких, дезагрегированных BI-инструментов. Заметные решения с открытым исходным кодом, такие как Apache Superset, Metabase и Redash, начали появляться около десяти лет назад, причем Superset, первоначально разработанный в Airbnb, приобрел особую известность в экосистеме.

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

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

Работа с задержкой запросов

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

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

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

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

Появление универсального семантического слоя

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

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

С помощью таких инструментов, как Cube и MetricFlow (теперь часть dbt Labs), например, организации могут определять свои метрики и модели данных в центральном месте, а затем подключать различные инструменты визуализации, пользовательские приложения или легкие BI-решения к этому семантическому слою.

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

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

Движение BI-as-Code

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

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

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

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

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

Ограничения BI-as-Code

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

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

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

Новая развивающаяся тенденция: BI + Встроенная аналитика

Последняя эволюция в BI-архитектуре включает интеграцию высокопроизводительных встраиваемых OLAP-движков запросов, таких как Apache DataFusion и DuckDB.

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

Новая полнофункциональная компонуемая BI-архитектура дает несколько ключевых преимуществ:

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

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

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

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

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

Внедрение в отрасли

Внедрение встраиваемых движков запросов в отрасли набирает обороты в экосистеме BI. Коммерческие поставщики возглавляют эту трансформацию: Omni интегрировала DuckDB в качестве своего основного аналитического движка, в то время как Cube.dev реализовала сложное сочетание Apache Arrow и DataFusion в своей безголовой BI-архитектуре.

Аналогичным образом, GoodData приняла эту тенденцию, реализовав Apache Arrow в качестве основы уровня кеширования своей системы FlexQuery, а Preset (Managed Superset) интегрировалась с MotherDuck (Managed DuckDB).

В области открытого исходного кода и Superset (с использованием библиотеки duckdb-engine), и Metabase теперь поддерживают встроенное подключение DuckDB с потенциальной будущей интеграцией в их основные движки.

Движение BI-as-Code также приняло встраиваемые движки. Rilldata объявила об интеграции DuckDB в 2023 году для автоматического профилирования и интерактивного моделирования при разработке панелей мониторинга, в то время как Evidence представила Universal SQL в 2024 году, основанный на реализации WebAssembly от DuckDB.

Заключение

Ландшафт бизнес-аналитики продолжает развиваться в сторону более гибких и эффективных решений.

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

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

Ландшафт открытого исходного кода в области инженерии данных 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 в таких областях, как интеграция открытых каталогов и разработка нативных библиотек
Растущая популярность одноузловой обработки данных и встроенной аналитики

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

Хроники Apache SeaTunnel

Fri, 13 Sep 2024 01:00:24 +0300

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

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

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

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

Set the basic configuration of the task to be performed

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

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

# read csv
source {
  LocalFile {
  schema {
    fields {

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


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

}
}


transform {

}

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

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

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

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

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

Готово.

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

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

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

Строки есть

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

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

# JVM Heap
-Xms556m
-Xmx1512m

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

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

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

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

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

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

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

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

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

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

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


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

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

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

схемка эта:

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

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

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

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

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

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

Wed, 04 Sep 2024 21:12:47 +0300

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему мы перешли с Dremio на Trino

Fri, 19 Jul 2024 17:59:38 +0300

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

Московский художник Даниил Кудряшов https://kudryashovdd.com/allartworks

Dremio и Trino: Основные Отличия

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

Dremio имеет свои плюсы и минусы:

Плюсы:

Лёгкость в использовании и интеграции.
Поддержка современных форматов данных.
Концепция data-as-code.

Минусы:

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

И конечно отсутствие обновлений, поддержки, что фактически является тупиком в развитии для нас.

Trino

Trino, ранее известный как PrestoSQL, представляет собой SQL-движок, который отлично подходит для платформ данных, требующих высокой степени кастомизации. В отличие от Dremio, Trino выполняет запросы ровно так, как это указано в SQL, что позволяет избежать излишних выгрузок данных и оптимизировать процесс обработки запросов. Благодаря своей открытой архитектуре, Trino предоставляет гибкость в настройках и кастомизации, что является ключевым преимуществом. Trino хорошо интегрируется с такими технологиями как Iceberg и Data Build Tool, kafka и многими другими, что обеспечивает более эффективное управление данными и их структурой. Позволяет нам выполнять запросы к данным в топиках Kafka, что особенно востребовано в текущий момент, а также легко добавлять новые типы коннекторов, Dremio так не умеет.

Плюсы:

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

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

Минусы:

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

Причины Перехода

Гибкость и Настраиваемость

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

Открытая Архитектура и Сообщество

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

Экономия Ресурсов

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

Безопасность и Управление

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

Поддержка и Документация

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

Влияние на Платформу

Переход на Trino позволит нам лучше следовать Data Mesh и основным принципым, а именно:

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

Что такое Data Mesh?

Заключение

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

Всем хороших выходных! Напишите в комментариях, как вам запомнился Dremio, и что вы пожелаете новому ядру на базе Trino.

Калининград, выезд БИТа

Data Products Starburst Special Edition

Mon, 17 Jun 2024 21:14:50 +0300

Новая книга по теме “Продукты данных” на основе исходного текста с комментариями GPT

© 2023 John Wiley & Sons, Inc. Любое распространение, копирование или несанкционированное использование строго запрещено.

Продукты данных

Специальное издание Starburst
Авторы: Вишал Сингх, Рио Коматсузаки и Эндрю Мотт, MBA

---

Исходные материалы защищены авторским правом © 2023 John Wiley & Sons, Inc., Hoboken, Нью-Джерси. Никакая часть данной публикации не может быть воспроизведена, сохранена в системе или передана в любой форме или любыми средствами без предварительного письменного разрешения издателя.

---

Глава 1: Определение продуктов данных

Введение

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

Что такое продукт данных?

Быстрый поиск в интернете приведет к двум связанным, но различным терминам:

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

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

Продукты данных и data mesh

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

Обнаружимость
Доступность
Доверие
Самоописательная интероперабельность
Безопасность

Комментарий GPT: Подход data mesh подчеркивает важность децентрализации и передачи ответственности непосредственно командам разработки приложений, что может существенно повысить гибкость организации.

Улучшение бизнес-ценности

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

---

Глава 2: Создание, управление и оптимизация продуктов данных

Введение

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

Дизайн продуктов данных для ценности

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

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

Масштабирование продуктов данных

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

Управление в большом масштабе

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

Снижение стоимости владения

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

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

---

Глава 3: Персонал и процессы

Введение

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

Построение ваших команд данных

Ключевые роли включают:

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

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

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

Центральные и децентрализованные политики управления

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

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

---

Глава 4: Десять советов по внедрению продуктов данных

Сфокусируйтесь на бизнес-ценности: Технологии должны помогать разработчикам продуктов данных концентрироваться на данных и их бизнес-контексте.
Связывайте продукты данных с ключевыми показателями эффективности (KPI): Это обеспечивает их актуальность и ценность.
Учитывайте пользовательские метрики и общую стоимость владения (TCO): Это помогает оптимизировать стратегии и инвестиции в данные.
Обеспечьте управление на основе ролей и ответственности бизнеса: Это способствует доверию и правильному использованию данных.
Дизайн с учетом потребностей потребителей: Максимальная ценность достигается при внимании к потребностям и предпочтениям пользователей.
Повторное использование без создания копий: Это экономично и предотвращает раздутие данных.
Стимулируйте производство и использование данных: Избегайте теневой ИТ.
Инвестируйте в роль владельца/менеджера продуктов данных: Они обеспечивают стратегическое управление продуктами данных.
Итерация — ключ: Постоянное совершенствование гарантирует актуальность продуктов данных.
Инвестируйте в культуру вашей организации: Одобрение данных на уровне культуры способствует устойчивому успеху.

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

---

Лицензионное соглашение с конечным пользователем

Перейдите на www.wiley.com/go/eula для доступа к лицензионному соглашению для электронной книги Wiley.

---

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

Оригинал тут: Data-Products-For-Dummies.pdf

Представляем data mesh 2.0: Новая эра управления данными

Thu, 08 Feb 2024 23:27:40 +0300

Представляем data mesh 2.0: Новая эра управления данными
Вступление: Почему data mesh актуален?

Оригинал:
https://medium.com/capital-one-tech/introducing-data-mesh-2-0-a-new-era-of-data-governance-27170c7a75cb

PDF

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

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

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

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

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

Это в конечном итоге привело к серьезным проблемам с:

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

И парадигма Data Mesh была представлена для решения этого нового набора проблем в мире озера данных.

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

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

Парадигма Data Mesh основана на четырех принципах:

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

Данные как продукт
Этот принцип направлен на снижение трения и затрат на обнаружение, понимание, доверие и, в конечном итоге, использование качественных данных. Владельцы продукта данных в домене должны глубоко понимать, кто пользователи данных, как они используют данные и какие методы они предпочитают для их использования. Продукт данных, состоящий из кода, данных и метаданных, а также инфраструктуры, является архитектурным квантом архитектуры Data Mesh. https://www.oreilly.com/library/view/building-evolutionary-architectures/9781491986356/ch04.html

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

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

Федеративное вычислительное управление
Data mesh следует архитектуре распределенной системы, где существует коллекция независимых продуктов данных, сосуществующих бок о бок, но с независимым жизненным циклом, созданных и развернутых, вероятно, независимыми командами.
Однако, чтобы получить ценность в виде данных более высокого порядка, инсайтов или машинного интеллекта, необходимо, чтобы эти независимые продукты данных взаимодействовали между собой; чтобы можно было их коррелировать, создавать объединения, находить пересечения или выполнять другие операции с графами или множествами с масштабированием.
Таким образом, реализация data mesh требует модели управления, которая принимает децентрализацию и самосуверенитет домена, создавая и придерживаясь набора глобальных правил (правил, применяемых ко всем продуктам данных и их интерфейсам) для успешной взаимосовместимости и автоматического выполнения решений об управлении платформой — федеративного вычислительного управления.
Основные элементы принципов data mesh
В общем, согласно принципам data mesh:
Продукт данных является архитектурным квантом разработки концепции, владения, производства, предоставления и управления аналитическими данными.
Продукт данных представляет собой композицию всех компонентов для предоставления данных — код, данные и метаданные и инфраструктура — все в ограниченном контексте домена.
Таким образом, помимо определения и управления своими продуктами данных, каждый домен также должен поддерживать собственную инфраструктуру для создания и предоставления этих продуктов данных, соблюдая набор глобальных правил управления для обеспечения взаимодействия продуктов данных.
Подробное обсуждение принципов и архитектуры можно найти здесь. https://martinfowler.com/articles/data-mesh-principles.html

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

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

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

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

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

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

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

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

Представляем data mesh 2.0
Что, если мы заимствуем принципы data mesh и реализуем их через ряд самообслуживающих горизонтальных платформ для обработки данных, обработки и управления данными, управляемых централизованными командами?
Из мира data mesh:
Принятие идеи владения доменом продуктов данных, что повышает доверие к данным.
Включение продукта данных в логический ограниченный контекст, что дополнительно увеличивает владение и доверие.
Использование принципа самообслуживания для удовлетворения как общих, так и дополнительных потребностей в управлении у каждого домена, что значительно сокращает время выхода на рынок.
Совмещение этих принципов с принципами горизонтальных корпоративных платформ
Централизованные платформы для обработки данных — особенно управления метаданными (включая управление и правила качества данных), захвата данных, курирования, вычисления характеристик, создания и обслуживания продуктов данных — для получения преимуществ инноваций однократного применения и обработки на масштабе с более низким общим затратами и более простым управлением
Стандартизация в процессах и инструментах проектирования и выполнения времени выполнения для значительного увеличения взаимосовместимости продуктов данных при снижении затрат на выполнение
Горизонтальные платформы значительно упрощают трассировку и мониторинг, что дополнительно увеличивает доверие к данным. Использование данных для повышения качества данных и их надежности с помощью превентивных и реактивных функций уведомлений, легко реализуемых однократно на центральной платформе и использованных многими
Использование подхода Built by One Leveraged by Many (BOLM)
Сохранение преимуществ озера данных: В мире общедоступных облачных вычислений озеро данных представляет собой набор управляемых полиглотных папок, расположенных на облаке, с уже зрелой структурой управления, чтобы управлять этими папками в соответствии с их внутренними и внешними потребностями (финансы, аудит, соответствие, обмен данными с внешними организациями и т. д.). Все, что нужно организации, – это организовать эти папки в соответствии с ее потребностями.

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

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

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

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

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

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

https://www.capitalone.com/tech/cloud/

Изначально опубликовано на https://www.capitalone.com.
Автор: Арья Басу, Архитектор данных, Банковская архитектура. Арья является архитектором данных с опытом более двух десятилетий в области данных и облака. В настоящее время он работает в команде Банковской архитектуры, фокусируясь на архитектуре данных.
ЗАЯВЛЕНИЕ О РАЗГЛАШЕНИИ: © 2024 Capital One. Мнения принадлежат индивидуальному автору. Если не указано иное в этом сообщении, Capital One не связана и не одобряет ни одну из упомянутых компаний. Все товарные знаки и другая интеллектуальная собственность, использованные или отображаемые, являются собственностью их соответствующих владельцев. Capital One не несет ответственности за содержание или политику конфиденциальности связанных сторон сайтов.

Data Mesh в масштабе: Интеграция семантического уровня в крупномасштабных системах

Sun, 28 Jan 2024 21:53:56 +0300

Оригинал: https://medium.com/oolooroo/data-mesh-at-scale-integrating-semantic-layers-in-large-scale-systems-8bd1562b0fea

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

Scaling the Heights of Data Mesh: A Semantic Layer Expedition

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

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

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

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

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

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

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

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

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

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

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

...

Исследование Семантического Уровня
Определение и Цель Семантического Уровня
Семантический уровень является ключевым компонентом в современной архитектуре данных, действуя как мост между исходными данными и конечными пользователями, которым необходимо интерпретировать и использовать эти данные. Его цель – предоставить последовательный, унифицированный и понятный взгляд на данные по всей организации, независимо от сложностей или технических разнородностей в их основе.
Смысл семантического уровня заключается в абстрагировании технических деталей хранения данных, их форматов и схем, предоставляя пользователям упрощенный, ориентированный на бизнес взгляд на данные. Эта абстракция позволяет пользователям, включая тех, кто не обладает технической экспертизой, легко взаимодействовать с данными, анализировать и извлекать из них инсайты.
Основные Характеристики и Функции Семантического Уровня
Абстрагирование данных: Семантический уровень абстрагирует сложности основных структур данных, представляя упрощенный, ориентированный на бизнес взгляд. Эта абстракция позволяет пользователям фокусироваться на анализе данных, а не на сложностях управления ими.
Согласованная интерпретация данных: Он обеспечивает согласованную интерпретацию данных в организации путем стандартизации определений, метрик и KPI. Эта согласованность критична для поддержания целостности и надежности данных.
Доступность и Удобство использования: Предоставляя более доступный интерфейс, семантический уровень способствует широкому использованию данных в организации, позволяя неспециалистам в области технологий использовать данные для принятия решений.
Интеграция и Интероперабельность: Семантический уровень облегчает интеграцию данных из различных источников и форматов, способствуя интероперабельности и уменьшая риски образования сило данных.
Улучшенное Управление и Безопасность: Он поддерживает управление данными, обеспечивая контроль доступа, стандарты конфиденциальности данных и требования к соответствию, гарантируя ответственное и безопасное использование данных.
Оптимизация запросов и производительность: Для эффективной работы семантический уровень должен оптимизировать запросы, чтобы минимизировать нагрузку на основные источники данных и улучшить время ответа на запросы конечных пользователей.
Управление метаданными: Семантический уровень должен эффективно управлять метаданными, предоставляя контекст и смысл данных, что критично для понимания линейности данных.
Семантический уровень играет ключевую роль в преобразовании сырых, сложных данных в действенные идеи. Его интеграция в архитектуры Data Mesh, как обсуждается в следующем разделе, является ключевым моментом для преодоления проблем масштабирования и сложности, связанных с децентрализованными средами данных.

Semantic Layer Architecure

Интеграция Семантического Уровня в Data Mesh
Преодоление Проблем Масштабирования в Data Mesh
Интеграция семантического уровня в архитектуру Data Mesh играет ключевую роль в преодолении проблем масштабирования. Data Mesh, своей природой, включает в себя несколько децентрализованных доменов, каждый из которых имеет свои модели данных и структуры. С увеличением числа этих доменов растет сложность управления и интеграции данных в организации. Семантический уровень выступает в роли унифицирующей силы, предоставляя последовательное, охватывающее всю организацию толкование данных, независимо от их источника или формата.
Повышение Обнаружимости и Интероперабельности Данных
В среде Data Mesh семантический уровень помогает сделать данные легко обнаруживаемыми и доступными в различных доменах. Он предоставляет общий язык для данных, преодолевая различия в моделях доменов и делая возможным и эффективным анализ данных между доменами.
Интероперабельность, обеспечиваемая семантическим уровнем, гарантирует, что данные из различных доменов могут интегрироваться без проблем, уменьшая риск образования сило данных и несогласованной аналитики.
Улучшение Управления Данными
Управление данными в децентрализованной среде, такой как Data Mesh, может быть сложным. Семантический уровень способствует управлению, обеспечивая согласованные определения данных, стандарты конфиденциальности и контроль доступа во всех доменах.
Этот уровень также играет ключевую роль в управлении соблюдением, так как он может отслеживать и контролировать, как данные используются и распространяются внутри организации, обеспечивая соблюдение законодательных и регуляторных стандартов.
Содействие Гибкому Управлению Данными
Семантический уровень дает командам доменов возможность эффективнее управлять своими данными, упрощая сложности интеграции и интерпретации данных. Эта гибкость критична для бизнеса, который должен быстро реагировать на изменения на рынке или внутренние требования.
Балансировка Децентрализации с Согласованностью
Интеграция семантического уровня в Data Mesh находит баланс между децентрализацией и согласованностью. В то время как Data Mesh позволяет доменам работать независимо, семантический уровень обеспечивает унифицированное понимание и подход к данным в этих доменах. Этот баланс является ключом к достижению масштабируемости и эффективности в условиях крупномасштабных сред данных.
В заключение, интеграция семантического уровня в Data Mesh решает ключевые проблемы масштабирования, интероперабельности и управления. Он выступает в роли катализатора, который не только обеспечивает эффективную работу Data Mesh в масштабе, но также усиливает его общую ценность в управлении сложными данными.
Проблемы и Соображения при Интеграции Семантического Уровня в Data Mesh
Хотя интеграция семантического уровня в Data Mesh предлагает значительные преимущества, она также представляет уникальные проблемы и соображения. Эффективное их решение является ключом к раскрытию полного потенциала этой интеграции.
Сложности в Реализации:
Техническая сложность: Разработка и внедрение семантического уровня, который эффективно взаимодействует с несколькими децентрализованными доменами данных, может быть технически сложной задачей. Требуется глубокое понимание как архитектуры данных, так и бизнес-контекста.
Трудности Интеграции: Бесшовная интеграция семантического уровня с существующей инфраструктурой данных, особенно в организациях с устаревшими системами, может быть сложной. Этот процесс часто требует значительных модификаций существующих конвейеров данных и решений для хранения данных.
Организационные и Культурные Асп

екты
Управление Изменениями: Внедрение семантического уровня в рамках структуры Data Mesh включает значительные организационные изменения. Выработка культуры, которая принимает этот новый подход к управлению данными, является ключевым фактором успеха.
Навыки и Обучение: Внедрение семантического уровня требует специализированных навыков. Организации должны инвестировать в обучение своего персонала или привлекать новые кадры для эффективного управления и использования этого уровня.
Поддержание Качества и Согласованности Данных
Обеспечение согласованного качества данных и их определений во всех доменах становится более сложным с введением семантического уровня. Требуется непрерывный мониторинг и управление для поддержания целостности и полезности данных.
Балансировка Гибкости и Стандартизации
Хотя семантический уровень способствует стандартизации интерпретации данных, важно уравновешивать это с гибкостью, необходимой для различных доменов. Нахождение правильного баланса критично для того, чтобы семантический уровень не стал узким местом или не помешал инновациям, специфичным для домена.
Масштабируемость и Оптимизация Производительности
По мере роста объема данных важно обеспечить эффективное масштабирование семантического уровня, сохраняя при этом высокую производительность. Это требует тщательного планирования и непрерывной оптимизации.
Управление и Соблюдение Законов
Внедрение семантического уровня включает в себя решение сложных проблем управления и соблюдения законов, особенно в регулируемых отраслях. Гарантировать, что семантический уровень соответствует всем соответствующим законам и нормативам, является важным.
Для решения этих проблем и учета соображений организации должны принять стратегический и всесторонний подход к интеграции семантического уровня в их архитектуру Data Mesh. Ключ к успеху заключается в тщательном планировании, понимании уникальных потребностей организации и непрерывных итерациях и усовершенствования.

Заключение и Перспективы
Сводка Основных Находок
В данной статье была рассмотрена ключевая роль семантического уровня в увеличении масштабируемости и эффективности архитектур Data Mesh. Интеграция семантического уровня решает фундаментальные проблемы в рамках Data Mesh, особенно в областях масштабируемости, интероперабельности и управления, предоставляя унифицированный, последовательный взгляд на данные в разнообразных доменах.
Значимость Семантического Уровня в Data Mesh
Семантический уровень выступает как существенный активатор для Data Mesh, особенно в масштабных и сложных средах данных. Он упрощает доступ и анализ данных, обеспечивает согласованную интерпретацию данных и способствует лучшему управлению и соблюдению. Эти факторы являются ключевыми для раскрытия полного потенциала Data Mesh, позволяя организациям более эффективно и отзывчиво использовать свои данные.
Проблемы и Стратегические Соображения
Несмотря на значительные выгоды, интеграция семантического уровня в Data Mesh не обходится без своих трудностей. Среди них – техническая сложность, необходимость специализированных навыков, поддержание качества данных и поиск баланса между стандартизацией и гибкостью. Решение этих проблем требует стратегического подхода, опирающегося на крепкое руководство, эффективное управление изменениями и непрерывную адаптацию и обучение.
Будущие Последствия и Развитие
В перспективе интеграция семантических уровней в архитектуры Data Mesh собирается сыграть ключевую роль в эволюции практик управления данными. По мере развития технологий мы можем ожидать:
Технологические Достижения: Дальнейшие разработки в области искусственного интеллекта и машинного обучения могут усовершенствовать возможности семантических уровней, делая их более динамичными и интеллектуальными в обработке сложностей данных.
Более Широкое Принятие и Созревание: По мере того как больше организаций применяют эту интеграцию, лучшие практики и методологии, вероятно, будут созревать, предоставляя более стандартизированные подходы к внедрению.
Влияние на Культуру Данных: Ожидается, что эта интеграция повлияет на организационные культуры данных, акцентируя более коллективный и демократизированный подход к управлению данными.
Инновации в Управлении Данными: Непрерывное развитие семантических уровней в архитектурах Data Mesh, вероятно, стимулирует инновации, предлагая новые способы управления и извлечения ценности из данных.
В заключение, интеграция семантического уровня в Data Mesh представляет собой значительный прогресс в области архитектуры данных. Он обещает сделать Data Mesh более масштабируемым, управляемым и эффективным, особенно в сложных и богатых данными средах. По мере того как эта область продолжает развиваться, она несомненно представит новые вызовы и возможности, но потенциальные выгоды для организаций в более эффективном использовании их данных являются существенными и убедительными.

Немного про Data Mesh

Thu, 14 Dec 2023 21:48:28 +0300

What Is Data Mesh?

А еще недавно вышла книга на русском про дата мех (мех как то пушистее звучит)

Yuriy Gavrilov: posts tagged Data Mesh

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

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

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

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

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

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

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

Заключение

От архитектуры data lakehouse к data mesh

От архитектуры data lakehouse к data mesh

Эволюция бизнес-аналитики: от монолитной к компонуемой архитектуре

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

Введение

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

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

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

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

Open Source vs Open Core vs Open Foundation

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

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

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

Хроники Apache SeaTunnel

Set the basic configuration of the task to be performed

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

Почему мы перешли с Dremio на Trino

Dremio и Trino: Основные Отличия

Trino

Причины Перехода

Гибкость и Настраиваемость

Открытая Архитектура и Сообщество

Экономия Ресурсов

Безопасность и Управление

Поддержка и Документация

Влияние на Платформу

Заключение

Data Products Starburst Special Edition

Новая книга по теме “Продукты данных” на основе исходного текста с комментариями GPT

© 2023 John Wiley & Sons, Inc. Любое распространение, копирование или несанкционированное использование строго запрещено.

Продукты данных

Оглавление

Глава 1: Определение продуктов данных

Введение

Что такое продукт данных?

Продукты данных и data mesh

Улучшение бизнес-ценности

Глава 2: Создание, управление и оптимизация продуктов данных

Введение

Дизайн продуктов данных для ценности

Масштабирование продуктов данных

Управление в большом масштабе

Снижение стоимости владения

Глава 3: Персонал и процессы

Введение

Построение ваших команд данных

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

Центральные и децентрализованные политики управления

Глава 4: Десять советов по внедрению продуктов данных

Лицензионное соглашение с конечным пользователем

Представляем data mesh 2.0: Новая эра управления данными

Data Mesh в масштабе: Интеграция семантического уровня в крупномасштабных системах

Немного про Data Mesh