В современных компаниях, активно использующих данные, часто возникает проблема “зоопарка” технологий. Данные хранятся в озере данных (Data Lake), а метаданные об этих данных — в каталогах. Со временем таких каталогов становится много: один `Hive Metastore` для унаследованной аналитики, другой — `REST Catalog` для новой платформы на Trino, третий — `JDBC Catalog` для специфичного микросервиса, а где-то в среде разработки таблицы вообще создаются напрямую в S3. Каждая система решает свою задачу, но вместе они создают хаос.

https://github.com/nimtable/nimtable

Платформенным дата-командам становится сложно управлять этим разнообразием, отслеживать состояние таблиц, проводить оптимизацию и обеспечивать единые стандарты. Именно для решения этой проблемы и был создан open-source проект Nimtable. Это не просто очередной каталог для Iceberg, а полноценная платформа для наблюдения и управления (*observability platform*) существующими каталогами из одного окна.

Что такое Nimtable?

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

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

Ключевая функциональность

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

пы: картинки можно листать, если что) там много, почти все меню.

1. Агрегация каталогов: Это главная особенность проекта. Nimtable позволяет в одном интерфейсе подключить и работать с несколькими типами каталогов Apache Iceberg, включая:
   • `REST Catalog`
   • `AWS Glue`
   • `PostgreSQL` (через JDBC)
   • Каталоги на основе S3 (`S3 Tables`)

2. Исследование и визуализация: Платформа предоставляет удобный UI для навигации по метаданным:
   • Просмотр каталогов, пространств имен (схем) и таблиц.
   • Анализ схемы таблиц, их партиций, снэпшотов и манифестов.
   • Визуализация распределения файлов и снэпшотов, что помогает быстро находить таблицы, требующие оптимизации (например, с большим количеством мелких файлов).

3. Управление оптимизацией: Nimtable не просто показывает проблемы, но и помогает их решать. Он интегрируется с внешними вычислительными движками, такими как Apache Spark или RisingWave, позволяя запускать и отслеживать задачи по обслуживанию таблиц (например, `compaction` или `expire_snapshots`) прямо из веб-интерфейса.

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

5. Собственный REST API: Помимо агрегации других каталогов, Nimtable сам может выступать в роли стандартного Iceberg REST-каталога. Это позволяет использовать его как единую точку входа для различных движков запросов (Trino, Spark, Flink).

Варианты использования в большой компании

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

• Прод-кластер Hadoop использует `Hive Metastore` для аналитических витрин.
• Аналитическая платформа на Trino работает с CedrusData Catalog, который реализует `Iceberg REST API` habr.com.
• Команда разработки для своих экспериментов использует таблицы, зарегистрированные напрямую в S3, чтобы не “загрязнять” общие каталоги.
• Какой-то сервис использует собственную `PostgreSQL` базу как JDBC-каталог.

В такой среде Nimtable становится незаменимым инструментом:

• Единая точка входа: Платформенная команда подключает все четыре каталога к Nimtable. Теперь для мониторинга состояния всех Iceberg-таблиц в компании достаточно зайти на один дашборд, не переключаясь между разными консолями и инструментами.
• Централизованная оптимизация: Инженер замечает, что в одной из таблиц на прод-кластере накопилось тысячи мелких файлов. Прямо из интерфейса Nimtable он может запустить `compaction-job` на общем Spark-кластере, выбрав нужную таблицу, независимо от того, в каком каталоге она зарегистрирована.
• Упрощение доступа: Вместо того чтобы объяснять новому аналитику, как настроить 4 разных подключения, ему можно дать доступ к Nimtable, где он сможет исследовать все доступные данные в едином, понятном интерфейсе.
• Контролируемая миграция: Если команда решит перенести таблицы из `Hive Metastore` в новый `REST Catalog`, Nimtable позволит одновременно наблюдать за источником и приемником, контролируя процесс и сверяя метаданные.

Архитектура и развертывание

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

Проект очень прост в развертывании. Самый быстрый способ начать работу — использовать Docker:

# Переходим в директорию с docker-файлами в репозитории проекта
cd docker
# Запускаем сервисы в фоновом режиме
docker compose up -d

После этого веб-интерфейс будет доступен по адресу `http://localhost:3000`.

Сравнение с другими решениями

Чтобы понять нишу, которую занимает Nimtable, сравним его с другими популярными решениями для управления метаданными.

Как видно из таблицы, Nimtable не конкурирует напрямую с каталогами вроде Nessie или Hive и другими, а дополняет их, выступая в роли “менеджера менеджеров”.

Заключение

Nimtable — это многообещающий проект, который пока не собрал много звёзд, но уже готов решать реальную боль платформенных дата-команд в крупных организациях. Вместо того чтобы создавать еще один стандарт каталога, он предлагает удобный слой абстракции для управления уже существующим “зоопарком”. Возможность в одном месте видеть, анализировать и оптимизировать таблицы из разных систем (`Hive`, `JDBC`, `REST`) делает его уникальным и крайне полезным инструментом для построения зрелой и управляемой платформы данных на базе Apache Iceberg.

Кстати, у меня после запуска он сначала жутко тупил, а потом прочихался, на третий день работы в докере))) я уже даже не надеялся, а он смог. ниче не делал) оно само) Но, видимо, если таблиц очень много, то первый запуск надо как то отдельно планировать. В общем зверь интересный и полезный, а запускать не сложно. Ну почти не сложно и баги есть. вот эту нашел например? https://github.com/nimtable/nimtable/issues/200 но это не критично.

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

Да точно, дело в ресурсах, теперь 16 файлов.

Теперь кстати хочет оптимизации)), хороший тула, можно и сломать табличку им))

Ранее писал о разных каталогах тут: https://gavrilov.info/all/rukovodstvo-po-rest-katalogam-dlya-trino-i-iceberg/

Источник: Emerging Architectures for Modern Data Infrastructure
Авторы: Matt Bornstein, Jennifer Li, and Martin Casado
PDF: Тут

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

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

Обновленные эталонные архитектуры

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

1. Единая инфраструктура данных (Unified Data Infrastructure 2.0)

Эта схема дает комплексное представление о стеке данных, охватывая все основные варианты использования — от аналитики до операционных систем.

Notes: Excludes OLTP, log analysis, and SaaS analytics apps.

Схема демонстрирует путь данных от источников (`Sources`) через этапы загрузки и транспортировки (`Ingestion and Transport`), хранения (`Storage`), обработки запросов (`Query and Processing`), трансформации (`Transformation`) до конечного анализа и вывода (`Analysis and Output`).

2. Инфраструктура для машинного обучения (Machine Learning Infrastructure 2.0)

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

Здесь показан жизненный цикл ML-модели: от трансформации данных и разработки модели (`Data Transformation`, `Model Training and Development`) до ее развертывания (`Model Inference`) и интеграции в конечные продукты (`Integration`).

Что изменилось? Стабильное ядро и “Кембрийский взрыв”

Что не изменилось: стабильность в ядре

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

• Аналитическими системами (Analytic Systems), которые помогают принимать решения на основе данных (`data-driven decisions`).
• Операционными системами (Operational Systems), которые являются основой для продуктов, использующих данные (`data-powered products`).

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

• В аналитике связка `Fivetran` (для репликации данных), `Snowflake`/`BigQuery` (облачные хранилища данных) и `dbt` (для SQL-трансформаций) стала почти стандартом де-факто.
• В операционных системах укрепились такие стандарты, как `Databricks`/`Spark`, `Confluent`/`Kafka` и `Airflow`.

Что нового: “Кембрийский взрыв”

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

1. Новые инструменты для поддержки ключевых процессов обработки данных:
   • Data Discovery: Каталоги данных для поиска и понимания имеющихся активов (`Amundsen`, `DataHub`, `Atlan`).
   • Data Observability: Инструменты для мониторинга состояния и качества конвейеров данных (`Monte Carlo`, `Bigeye`).
   • ML Model Auditing: Решения для аудита и валидации ML-моделей.

2. Новые приложения для извлечения ценности из данных:
   • Data Workspaces: Интерактивные среды для совместной работы аналитиков и Data Scientist’ов (`Mode`, `Hex`, `Deepnote`).
   • Reverse ETL: Сервисы, которые возвращают обогащенные данные из хранилища обратно в операционные системы (CRM, ERP), такие как `Census` и `Hightouch`.
   • ML Application Frameworks: Фреймворки для создания приложений на основе ML-моделей (`Streamlit`).

Три основных архитектурных шаблона (Blueprints)

Шаблон 1: Современная Business Intelligence (BI)

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

Darker boxes are new or meaningfully changed since v1 of the architecture in 2020; lighter colored boxes have remained largely the same. Gray boxes are considered less relevant to this blueprint.

• Что не изменилось: Основой по-прежнему является комбинация репликации данных (`Fivetran`), облачного хранилища (`Snowflake`) и SQL-моделирования (`dbt`). Дашборды (`Looker`, `Tableau`, `Superset`) остаются главным инструментом анализа.
• Что нового:
  • Metrics Layer: Появился активный интерес к слою метрик — системе, которая предоставляет стандартизированные бизнес-определения поверх хранилища данных (`Transform`, `LookML`). `dbt` также движется в этом направлении. ( dbt кстати открыла в общий доступ свои метрики тут
  • Reverse ETL: Этот инструмент позволяет операционализировать аналитику, отправляя результаты (например, скоринг лидов) из хранилища напрямую в `Salesforce` или `Hubspot`. ( теперь мы знаем как эта штука называется по-модному, когда кто-то просит excele’чку всунуть к табличке рядышком :) )
  • Data Workspaces: Новые приложения для более гибкого и глубокого анализа, чем стандартные дашборды.

Шаблон 2: Мультимодальная обработка данных

Этот шаблон развивает концепцию “озера данных” (`Data Lake`) для поддержки как аналитических, так и операционных задач. Часто используется компаниями, которые “мигрировали” с `Hadoop`.

• Что не изменилось: Ядром остаются системы обработки (`Databricks`, `Starburst`), транспортировки (`Confluent`, `Airflow`) и хранения (`AWS S3`).
• Что нового:
  • Архитектура Lakehouse: Получила широкое признание концепция `Lakehouse` — гибрид, объединяющий гибкость озера данных и производительность/управляемость хранилища данных. Она позволяет использовать поверх одного и того же хранилища (`S3`) множество движков: `Spark`, `Presto`, `Druid`/`ClickHouse` и др.
  • Форматы хранения: Быстрое распространение получают открытые табличные форматы, такие как `Delta Lake`, `Apache Iceberg` и `Apache Hudi`, которые привносят транзакционность и надежность в озера данных.
  • Stream Processing: Растет популярность потоковой обработки данных в реальном времени. Появляются новые, более простые в использовании инструменты (`Materialize`, `Upsolver`), а существующие (`Databricks Streaming`, `Confluent`/`ksqlDB`) наращивают функциональность.

Шаблон 3: Искусственный интеллект и машинное обучение (AI/ML)

Стек для разработки, тестирования и эксплуатации ML-моделей.

Note: Darker boxes are new or meaningfully changed since v1 of the architecture in 2020; lighter colored boxes have remained largely the same. Gray boxes are considered less relevant to this blueprint.

• Что не изменилось: Инструменты для разработки моделей в целом остались прежними: облачные платформы (`AWS Sagemaker`, `Databricks`), ML-фреймворки (`PyTorch`, `XGBoost`) и системы для отслеживания экспериментов (`Weights & Biases`, `Comet`).
• Что нового:
  • Data-Centric AI: Произошел сдвиг парадигмы в сторону подхода, ориентированного на данные. Вместо бесконечного улучшения кода модели, фокус сместился на улучшение качества и управления данными для обучения. Это привело к росту сервисов разметки данных (`Scale AI`, `Labelbox`).
  • Feature Stores: Увеличилось внедрение хранилищ признаков (`Tecton`, `Feast`) для совместной разработки и использования ML-признаков в production.
  • Pre-trained Models: Использование предобученных моделей (особенно в NLP) стало стандартом. Компании, как `OpenAI` и `Hugging Face`, играют здесь ключевую роль.
  • MLOps: Инструменты для эксплуатации моделей стали более зрелыми, особенно в области мониторинга (`Arize`, `Fiddler`) на предмет деградации качества и дрифта данных.

Гипотеза о “платформе данных”

Ключевая идея статьи — объяснить наблюдаемые изменения через формирование платформ данных.

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

Применительно к данным, “бэкенд” стека (загрузка, хранение, обработка) консолидируется вокруг небольшого числа облачных вендоров. Эти вендоры (`Snowflake`, `Databricks`) активно инвестируют в то, чтобы сделать данные легкодоступными для других через стандартные интерфейсы (например, SQL).

В свою очередь, “фронтенд” разработчики пользуются этим, создавая множество новых приложений поверх единой точки интеграции, не беспокоясь о сложностях базовой инфраструктуры. Это приводит к появлению нового класса `warehouse-native` (или `lakehouse-native`) приложений, которые работают непосредственно с данными клиента в его хранилище.

Эта модель объясняет, почему поставщики ядра данных (`Snowflake`, `Databricks`) так высоко ценятся (они борются за долгосрочную позицию платформы) и почему наблюдается взрывной рост в экосистеме инструментов (`Reverse ETL`, `Metrics Layer`) — они становятся важными компонентами, встроенными в эту новую платформенную архитектуру.

Итог и акценты в трендах

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

2. Взрывной рост экосистемы. Вокруг стабильного ядра формируется богатая экосистема вспомогательных инструментов (`observability`, `discovery`) и бизнес-приложений (`reverse ETL`, `workspaces`), которые повышают ценность данных.

3. Платформизация стека данных. Центральные хранилища данных (`Data Warehouse`, `Lakehouse`) превращаются из простых баз данных в полноценные платформы для разработки. Это открывает путь для нового поколения `warehouse-native` SaaS-приложений.

4. Операционализация данных. Тренд смещается от простой аналитики (посмотреть на дашборд) к активному использованию данных в операционных процессах бизнеса. Технологии `Reverse ETL` являются главным драйвером этого тренда.

5. Data-Centric AI. В мире машинного обучения фокус окончательно сместился с улучшения алгоритмов на улучшение данных, что стимулирует рынок инструментов для управления жизненным циклом данных в ML (`data labeling`, `feature stores`, `monitoring`).

Компания dbt Labs объявила о важном изменении в своей стратегии: `MetricFlow`, ключевая технология, лежащая в основе `dbt Semantic Layer`, становится полностью открытой. Проект переводится под лицензию Apache 2.0, что позволяет любому использовать, изменять и встраивать его в свои продукты. Это стратегический шаг, направленный на создание единого отраслевого стандарта для определения бизнес-метрик, особенно в свете бурного развития AI-систем.

Оригинал тут: https://www.getdbt.com/blog/open-source-metricflow-governed-metrics
А гит тут: https://github.com/dbt-labs/metricflow

Еще кстати есть https://github.com/memiiso/opendbt ( Make dbt great again! :) Может они сольются с метриками, интересно.

Проблема: почему семантический слой стал критически важен

Концепция семантического слоя, который служит промежуточным слоем для определения бизнес-логики (метрик, измерений, связей), не нова. Она уже много лет используется в BI-системах для обеспечения согласованности отчетов. Однако с появлением больших языковых моделей (LLM) и инструментов в стиле “Chat with your data” проблема вышла на новый уровень.

Когда AI-агент или LLM пытается ответить на вопрос, обращаясь напрямую к базе данных, он вынужден самостоятельно генерировать SQL-запрос. При этом модель “угадывает”, какие таблицы нужно соединить (`JOIN`), как правильно отфильтровать данные, какую использовать гранулярность по времени и какие оконные функции применить.

Проблемы такого подхода:

1. Несогласованность: Две разные модели (или даже одна и та же, но с другим запросом) могут сгенерировать разный SQL для расчета, казалось бы, одной и той же метрики. Это приводит к разным цифрам в отчетах.
2. Ошибки: LLM может не знать о тонкостях бизнес-логики, например, о том, что при расчете выручки нужно учитывать возвраты или использовать специальный финансовый календарь.
3. Потеря доверия: Когда пользователи получают противоречивые или неверные данные, доверие ко всей системе аналитики быстро падает.

Метрики не должны быть вероятностными, зависящими от “догадок” LLM при каждом вызове. Они должны быть детерминированными.

`MetricFlow` решает именно эту задачу.

Что такое MetricFlow и как он работает

`MetricFlow` — это движок, который преобразует семантические определения бизнес-понятий в готовый к выполнению и оптимизированный SQL-код. Аналитик один раз определяет метрику “Валовая маржа” на языке `MetricFlow`, и после этого любая система (BI-инструмент, AI-агент, Python-скрипт) может запросить эту метрику по имени, будучи уверенной, что получит корректный и одинаковый результат.

Ключевые изменения и их значение

1. Лицензия Apache 2.0: Это одно из главных нововведений. Apache 2.0 — это разрешительная лицензия, которая позволяет другим компаниям свободно встраивать `MetricFlow` в свои коммерческие и открытые продукты. Это снимает барьеры для принятия технологии и способствует ее распространению как стандарта.
2. Сотрудничество с Open Semantic Interchange (OSI): dbt Labs будет развивать `MetricFlow` совместно с такими партнерами, как Snowflake и Salesforce, в рамках инициативы OSI. Цель — создать единый стандарт для семантической совместимости между разными платформами, чтобы метрики, определенные один раз, одинаково работали во всех инструментах.

Как MetricFlow обеспечивает надежность AI

`MetricFlow` предоставляет открытый стандарт для метаданных и расширяемый движок, который превращает намерение (“покажи валовую маржу”) в SQL-запрос для хранилища данных.

Пример работы:

Предположим, пользователь задает AI-агенту вопрос:

“Покажи валовую маржу (%) по месяцам за прошлый квартал для Северной Америки (за вычетом скидок и возвратов, по финансовому календарю).”

Без семантического слоя LLM пришлось бы конструировать сложный запрос с нуля. С `MetricFlow` процесс выглядит так:

1. Агент распознает намерение и запрашивает у `MetricFlow` метрику `gross_margin_pct` с нужными измерениями (`region`, `fiscal_month`) и фильтрами.
2. `MetricFlow`, на основе заранее созданных определений, строит план запроса:
   • Находит нужные таблицы: `orders`, `discounts`, `returns`, `cogs` (себестоимость).
   • Применяет правильные `JOIN` между ними.
   • Применяет фильтр по региону (`North America`).
   • Группирует данные по месяцам финансового, а не календарного, года.
   • Рассчитывает числитель (выручка) и знаменатель (себестоимость) с учетом того, что популяция данных для них должна быть одинаковой.
   • Вычисляет итоговое соотношение.
3. `MetricFlow` компилирует этот план в оптимизированный SQL-запрос, специфичный для диалекта конкретного хранилища (Snowflake, BigQuery, Databricks и т.д.).
4. Запрос выполняется в хранилище, и результат возвращается пользователю.

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

Основные возможности движка:

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

`MetricFlow` vs. `dbt Semantic Layer`

Важно понимать различие между двумя компонентами:

• `MetricFlow` — это движок с открытым исходным кодом для определения и вычисления метрик. Это “сердце” системы, которое выполняет всю сложную работу по генерации SQL.
• `dbt Semantic Layer` — это коммерческий продукт dbt Labs, построенный *поверх* `MetricFlow`. Он добавляет функциональность корпоративного уровня:
  • Управление доступом (`RBAC`).
  • Версионирование определений метрик.
  • Аудит и отслеживание происхождения данных (`lineage`).
  • Надежные API и коннекторы для интеграции с BI- и AI-инструментами.

Таким образом, `MetricFlow` становится общедоступным строительным блоком, а `dbt Semantic Layer` — готовым решением для его безопасного и управляемого внедрения в компаниях.

Итог

1. dbt Labs сделала `MetricFlow` (движок для расчета метрик) полностью открытым под лицензией Apache 2.0. Это позволяет всем желающим использовать его без ограничений.
2. Главная цель — создать открытый стандарт для определения бизнес-метрик. Это особенно актуально для AI-систем, которые часто ошибаются при самостоятельной генерации SQL.
3. `MetricFlow` позволяет AI и BI-инструментам запрашивать данные по имени метрики (например, `revenue`), получая детерминированный и корректный SQL-запрос. Это повышает надежность и согласованность данных.
4. Этот шаг способствует совместимости инструментов (`interoperability`) и снижает зависимость от конкретного вендора (`vendor lock-in`). Метрики, определенные один раз, будут работать одинаково в разных системах.
5. Коммерческий продукт `dbt Semantic Layer` продолжит развиваться как решение для управления жизненным циклом метрик в корпоративной среде (безопасность, контроль версий, аудит).

С ростом популярности архитектуры Data Lakehouse усилился интерес к трём основным открытым проектам в этой области: Apache Hudi, Delta Lake и Apache Iceberg. Все три технологии продолжают активно развиваться, и в этой статье представлено актуальное сравнение их возможностей по состоянию на октябрь 2025 года.

Оригинал тут: https://www.onehouse.ai/blog/apache-hudi-vs-delta-lake-vs-apache-iceberg-lakehouse-feature-comparison

Примечание: Если выбор формата вызывает сложности, обратите внимание на проект Apache XTable (Incubating), который обеспечивает интероперабельность между Hudi, Delta и Iceberg, позволяя использовать несколько форматов одновременно.

Сравнение возможностей

Функциональность записи

Ключевые отличия:

• Hudi предлагает наиболее продвинутые механизмы управления конкуренцией, включая неблокирующий контроль (NBCC)
• Только Hudi поддерживает настоящий Merge-on-Read без компромиссов производительности
• Hudi предоставляет встроенные инструменты для дедупликации через первичные ключи

Метаданные таблиц

Важные особенности:

• Hudi использует оптимизированный формат HFile для метаданных, что значительно ускоряет поиск
• Только Hudi поддерживает настоящие первичные ключи как в реляционных БД
• Hudi предлагает более гибкий подход к партиционированию через кластеризацию

Функциональность чтения

Сервисы таблиц

Поддержка экосистемы

Все три формата имеют широкую поддержку в экосистеме данных:

• Apache Spark, Flink, Trino, DBT – полная поддержка чтения/записи во всех форматах
• Kafka Connect – Hudi и Iceberg имеют нативную поддержку, Delta – только проприетарную
• Облачные платформы (AWS, GCP, Azure) – все три формата поддерживаются с некоторыми ограничениями
• Snowflake – нативная поддержка Iceberg, Hudi через XTable

Производительность: TPC-DS бенчмарки

Согласно независимым тестам:

• Hudi и Delta показывают сопоставимую производительность
• Iceberg consistently отстаёт по скорости выполнения запросов

Важно: При сравнении производительности учитывайте, что Hudi по умолчанию оптимизирован для mutable-нагрузок (upsert), в то время как Delta и Iceberg – для append-only. Для честного сравнения используйте `bulk-insert` режим в Hudi.

Ключевые дифференцирующие возможности

Инкрементальные пайплайн

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

Управление конкуренцией

В то время как все три системы поддерживают оптимистический контроль конкуренции (OCC), только Hudi предлагает:

• Неблокирующий контроль конкуренции (NBCC)
• Файл-уровневую гранулярность блокировок
• Возможность работы с асинхронными сервисами таблиц без остановки записи

Merge-on-Read

Только Hudi предоставляет полнофункциональный Merge-on-Read, который позволяет:

• Балансировать между производительностью записи и чтения
• Использовать row-ориентированные форматы для стриминга и column-ориентированные для аналитики
• Выполнять компактизацию асинхронно

Кластеризация vs Эволюция партиций

• Iceberg: Partition Evolution – изменение схемы партиционирования для новых данных
• Hudi: Гибридный подход – coarse-grained партиционирование + fine-grained кластеризация с возможностью эволюции без перезаписи данных

Многомодальное индексирование

Только Hudi предлагает асинхронную подсистему индексирования, поддерживающую:

• Bloom, hash, bitmap, R-tree индексы
• 10-100x ускорение point lookup запросов
• 10-30x общее ускорение запросов в реальных нагрузках

Реальные кейсы использования

Peloton

• Увеличение частоты ингестии с 1 раза в день до каждых 10 минут
• Снижение времени выполнения снапшот-заданий с 1 часа до 15 минут
• Экономия затрат через оптимизацию использования EMR-кластеров

ByteDance/TikTok

• Обработка таблиц объемом 400+ PB
• Ежедневный прирост данных на уровне PB
• Пропускная способность >100 GB/s на таблицу
• Выбор Hudi из-за открытости экосистемы и поддержки глобальных индексов

Walmart

• Использование Merge-on-Read для снижения задержек
• Нативная поддержка удалений для GDPR/CCPA compliance
• Row versioning для обработки out-of-order данных

Инновации сообщества

Многие ключевые функции data lakehouse были впервые реализованы в Hudi:

Заключение

Критерии выбора

Выбирайте Apache Hudi если:

• Ваши workload’ы содержат значительное количество обновлений и удалений
• Требуется низкая задержка от конца в конец
• Нужны продвинутые возможности управления конкуренцией
• Важна производительность point lookup запросов
• Требуется гибкое управление layout данных через кластеризацию

Рассмотрите Delta Lake если:

• Вы используете экосистему Databricks
• Workload’ы преимущественно append-only
• Достаточно базовых возможностей управления конкуренцией

Apache Iceberg может подойти если:

• Основная задача – работа с очень большими объемами данных в cloud storage
• Требуется скрытое партиционирование с эволюцией
• Workload’ы в основном аналитические с минимальными обновлениями

Итоговые рекомендации

1. Для зрелых production-нагрузок с frequent updates, high concurrency и low latency требованиями Apache Hudi предлагает наиболее полный набор возможностей.

2. Не ограничивайтесь сравнением “галочек” – оценивайте производительность на своих данных и workload’ах.

3. Рассмотрите Apache XTable если невозможно определиться с одним форматом или требуется интероперабельность между системами.

4. Учитывайте roadmap проекта – Hudi продолжает лидировать в инновациях, что может быть важно для долгосрочных инвестиций.

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

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

https://t.me/analyticsfromzero/201

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог встречи

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

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

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

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

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

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

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

Темы:

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

@analyticsfromzero

Часть 1: “Bar is sooooooooo high” – https://nekrolm.github.io/blog.html

Это исповедь инженера, уволившегося из Amazon Web Services (AWS) после трех лет работы. Основная причина — чудовищный стресс и выгорание, вызванные спецификой корпоративной культуры и рабочих процессов, несмотря на престижность компании (FAANG) и высокую компенсацию.

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

• `Bar is sooooooooo high`: “Планка неимоверно высока”. Означает, что требования для повышения (промоушена) настолько завышены, что достичь их практически невозможно, даже если ты уже выполняешь работу на следующем уровне. Это создает ощущение бега на месте.
• `RSU (Restricted Stock Units)`: Акции компании, которые выдаются сотруднику, но он получает их не сразу, а по частям в течение нескольких лет. Это способ удержания ценных кадров. Автор отказался от ~£100k, не дождавшись очередного получения акций.
• `FAANG`: Акроним для гигантов технологической индустрии: Facebook (теперь Meta), Amazon, Apple, Netflix, Google. Символ престижной и высокооплачиваемой работы в IT.
• `Return-to-office`: “Возвращение в офис”. Политика компании, обязывающая сотрудников работать из офиса определенное количество дней в неделю.
• `Oncall`: “Дежурство”. Период, когда инженер должен быть доступен 24/7 для решения экстренных проблем с продакшн-системами. В статье это источник огромного стресса из-за сложности системы и широкого круга обязанностей.
• `Leadership Principles`: “Принципы лидерства”. 16 “заповедей” Amazon, которые должны направлять поведение сотрудников. Автор иронично использует их, чтобы показать, как в реальности они превращаются в инструменты бюрократии и давления.
• `Receive shouldertaps`: “Получать ‘похлопывания по плечу’”. Метафора, означающая постоянные отвлечения, прерывания и запросы от коллег и менеджеров, которые мешают сосредоточиться на основной задаче.
• `Let’s keep rollout aside`: “Давайте пока не будем думать о раскатке”. Фраза менеджера, которая говорит о том, что процесс релиза настолько сложный, долгий (от месяца до года) и рискованный, что его даже не пытаются планировать и оценивать.
• `Customer Obsession`: “Одержимость клиентом”. Один из принципов лидерства. В статье показана его гипертрофированная форма, когда нужно реагировать даже на падение одного запроса из миллиона.
• `Correction-of-errors document (COE)`: Документ с разбором ошибок. Его написание и защита перед высшим руководством — крайне неприятная процедура после любого сбоя.
• `Bar Rising`: “Поднятие планки”. Процесс ревью и “прожарки” на митингах, где любая идея подвергается шквалу критики и сомнений, что ведет к выработке синдрома самозванца. пс: у кого-то “паяльники” рабочий инструмент, а у матерых компаний “градусники для мяса”. 🤣 Что поделать, идут дальше, контролируют степень “прожарки” в виде ежедневных опросов, что бы не подгорало.
• `Ownership`, `Operational Excellence`: Другие принципы лидерства, которые на практике означают, что дежурный инженер несет полную ответственность за гигантскую и запутанную систему.
• `In pain`: “Страдает”. Эмоционально окрашенный термин для описания клиента с проблемой, используемый для создания срочности.
• `Disagree and Commute`: “Не согласен, но езди в офис”. Ироничная переделка принципа `Disagree and Commit` (“Не согласен, но поддерживай решение”). Отражает отношение к принудительному возвращению в офис.
• `GenAI`: Генеративный Искусственный Интеллект. Автор описывает неадекватную истерию вокруг этой темы в компании.
• `Bellow benchmarks`: “Ниже эталонных показателей”. Результат анонимных опросов удовлетворенности, который показывает, что команда недовольна, и приводит к игре в “мафию” — поиску виноватых.

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

Футбол кстати вовлекает 40% населения, а количество зрителей финала чемпионата может достигать 1,5 млрд. человек.

Стоимость бренда UFC – 4 млрд$, но цифра уже устарела, 11 дек. 2024 г. — $10 миллиардов, — Глава UFC оценил, а в августе этого года Paramount приобрела права на трансляцию UFC за $7,7 млрд. Сейчас оценка где-то 11млрд. За один просмотр выручка c трансляции одного боя может достигать 180$ млн.

А вот Люк как запомнился, “Он говорил на языке страсти, а не KPI”

Ну вы все уже знаете. 81 сервис пострадал, +800 компаний где-то, даже медиум лежал.

Облака, белогривые лошадки,
Облака, что вы мчитесь без оглядки
Не смотрите вы пожалуйста свысока,
А по небу прокатите нас облака... Трям! Здравствуйте!»))

Рецепт выгорания от Amazon или почему “планка так высока”

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

Причина кроется в самой культуре, парадоксальным образом описанной через знаменитые `Leadership Principles` Amazon. Принцип `Insist on Highest Standards` (“Настаивайте на высочайших стандартах”) на практике превращается в бюрократическую “прожарку” (`Bar Rising`), где любая инициатива тонет в бесконечных согласованиях и документах. Чтобы выпустить даже небольшое изменение, нужно “просмотреть все варианты будущего”, как Доктор Стрэндж, и защитить свое решение перед армией сомневающихся.

Вершиной этой культуры становится процесс релиза. Фраза менеджера `Let’s keep rollout aside` говорит сама за себя: раскатка изменений в продукте, через который проходит 30% интернет-трафика, — это настолько болезненный и непредсказуемый процесс, что его предпочитают даже не обсуждать. Проект, сделанный за 2 недели, может добираться до пользователей полтора года. Как пишет автор, это лучший рецепт для выгорания: “Заставьте программистов писать код, не дайте им увидеть результат и при этом дергайте их в разные стороны”.

Эти “подергивания” (`shouldertaps`) — еще один гвоздь в крышку гроба мотивации. Дежурства (`oncall`) превращают инженера в универсального солдата, который должен ориентироваться в сотнях дашбордов, десятках видов логов и нести `Ownership` за все, что происходит. При этом `Customer Obsession` доходит до абсурда: приходится разбираться с падением одного запроса из миллиона, потому что клиент `in pain`.

На фоне этого — постоянные увольнения, принудительное “возвращение в офис” (`Disagree and Commute`) и неадекватная `GenAI`-истерия. В итоге “планка” (`bar is so high`) для карьерного роста оказывается не стимулом, а стеной, о которую разбиваются амбиции. Это история о том, как система, созданная для минимизации рисков в огромном масштабе, начинает пожирать человеческий ресурс, превращая талантливых инженеров в выгоревших статистов.

Стихотворение в стиле АЙ да Пушкина :)  🤖

Три года в царстве AWS,
Где каждый день — суровый стресс.
Прощай, гигант, твой дом высок,
Но дух мой страждет и продрог.

Чтоб строчку кода в мир пустить,
Трактат надобно сочинить.
На том совете господа
Тебя осудят без труда.

“А точно ль цель сия верна?
Вся ль сложность вами учтена?”
Идёт полгода, год второй,
А код твой спит, еще не в строй.

Дежурства мрак, клиент “in pain”,
И кашель рвёт грудину мне.
И планка та, что так горда,
Лишь множит горе и года.

Оставлю акций бренный звон,
Покину сей хрустальный трон.
Свободным быть — вот мой удел,
Прощай, Amazon, я улетел.

Часть 2: О статье про Spotify (“Platform Takes The Pain”)

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

Суть и смысл статьи

Основная идея — Spotify столкнулся с проблемой масштабирования. Их культура полной автономии команд, где каждая сама отвечала за свой конвейер сборки и доставки (CI/CD), привела к хаосу: более 300 команд использовали 200+ разных, небезопасных версий CI-системы Jenkins. Перед выходом на IPO аудиторы указали на это как на серьезный риск.

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

Решением стала смена парадигмы в работе платформенных команд под лозунгом `Platform Takes The Pain` (“Платформа забирает боль на себя”).

Устройство, культура и особенности Spotify

1. Культура “старого” Spotify (до трансформации):
   • Хорошо:
     • Полная автономия: Команды (`squads`) были абсолютно независимы, что давало им чувство сопричастности и ускоряло принятие решений в малом масштабе.
     • Сильная идентичность: У каждой команды была своя “комната” (`squad room`), оформленная в уникальном стиле, что создавало сильную командную связь.
     • Скорость и гениальные инженеры: В компании были “звёзды” (“employee number 10”), которые могли писать код день и ночь и знали всё об инфраструктуре.
   • Не очень:
     • Хаос и фрагментация: Более 200 CI-систем — яркий пример. Это приводило к дублированию работы и уязвимостям.
     • “Rumor Driven Development” (“Разработка, основанная на слухах”): Чтобы что-то узнать, нужно было “похлопать по плечу” нужного человека. Не было единого источника информации, что замедляло новичков и приводило к созданию костылей.
     • Проблемы с онбордингом: Новичку требовалось более 60 дней, чтобы сделать свои первые 10 Pull Request.
     • Хрупкость: Если ключевой инженер уходил в отпуск, система могла остаться без поддержки.

2. Трансформация и новая культура:
   • Мантра `Platform Takes the Pain`: Платформенные команды перестали быть просто создателями инструментов “в стол”. Они стали сервис-провайдером для внутренних клиентов — других команд разработчиков. Их новой задачей стало не просто создать инструмент, а взять на себя ответственность за его внедрение (`adoption`). Они приходили в команды и помогали им мигрировать, забирая на себя самую нудную и сложную работу.
   • `Backstage` — решение проблемы “слухов”: Чтобы победить `Rumor Driven Development`, Spotify создали единый портал для разработчиков — `Backstage` engineering.atspotify.com.
     • Устройство: Это центральный каталог, где можно найти информацию о любом сервисе, его владельце, документации, API и дежурном инженере.
     • Главная особенность: `Backstage` построен на плагинах. Это значит, что центральная команда не стала “бутылочным горлышком”. Любая команда может написать свой плагин для `Backstage`, чтобы добавить нужную ей функциональность. Это гениальное решение, которое централизует информацию, но децентрализует владение и развитие платформы.
   • Переосмысление автономии: В Spotify поняли, что автономия ради автономии бессмысленна. Настоящая цель автономии — влияние (`impact`). Если команда автономна, но изолирована и ее работа не приносит пользы, это плохая автономия. Новые стандарты и инструменты вроде `Backstage` не убили автономию, а, наоборот, дали командам больше влияния, убрав рутину и упростив взаимодействие.

*На Backstage кстати можно строить порталы IDP https://internaldeveloperplatform.org/what-is-an-internal-developer-platform/

Чем Spotify отличается от других (например, от Amazon из первой статьи)?

Итоги

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

Основные выводы:

1. Платформа должна служить разработчикам, а не диктовать им условия. Модель `Platform Takes The Pain` — это то, чему стоит поучиться многим компаниям.
2. Централизуйте информацию, а не контроль. Инструмент вроде `Backstage` с плагинной архитектурой — мощное решение для сохранения скорости и автономии в большом масштабе.
3. Культура не высечена в камне. Она должна адаптироваться к размеру и задачам компании. Spotify смогли переосмыслить “автономию”, привязав её к реальному влиянию на продукт.

Для компаний, стремящихся к росту, опыт Spotify

sciencedirect.com — это дорожная карта по построению эффективной и при этом человечной инженерной организации. А для инженеров, выбирающих место работы, это маркер здоровой культуры: ищите компании, которые борются с трением, а не создают его. Как говорится, если в компании есть свой `Backstage` — это хороший знак. Если же там “let’s keep rollout aside” — возможно, стоит бежать.

Если коротко – оригинал по ссылке выше

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

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

Однако эта свобода существует в рамках так называемых «благоприятствующих ограничений» (`enabling constraints`). Эти ограничения — не приказы сверху, а скорее общие правила и инструменты, которые помогают командам работать слаженно, не создавая хаоса. Исследование основано на ретроспективах с командами, интервью с менеджерами и анализе внутренних данных Spotify.

Основные рекомендации и стратегии, применяемые в Spotify

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

1. Выравнивание (Alignment) вместо контроля: Вместо того чтобы указывать командам, *что* и *как* делать, компания создает условия для естественной синхронизации.
   • `TechRadar` (Технологический радар): Это централизованный, но коллективно управляемый список одобренных технологий, языков программирования и фреймворков. Команды не могут использовать абсолютно любую технологию, что упрощает поддержку, обмен инженерами и совместную работу над кодом.
   • Запросы на комментарии (`RFCs – Requests for Comments`): Для крупных изменений, затрагивающих несколько команд, используется формальный процесс RFC. Это позволяет собрать обратную связь и достичь консенсуса до начала реализации.
   • «Золотые пути» (`Golden Paths`): Это готовые шаблоны и руководства для выполнения стандартных задач (например, создание нового микросервиса). Это снижает когнитивную нагрузку на инженеров и обеспечивает единообразие.

2. Управление общей кодовой базой:
   • «Слабое владение кодом» (`Weak Code Ownership`): У каждого компонента кода есть команда-владелец, но любая другая команда может предлагать изменения через пул-реквесты (`Pull Requests`). Команда-владелец обязана рассмотреть эти изменения. Это предотвращает возникновение «узких мест» и поощряет коллективную ответственность за продукт.
   • Самостоятельное управление зависимостями: Команды могут договариваться между собой и передавать владение кодовыми репозиториями, чтобы уменьшить зависимости и ускорить свою работу.

3. Сетевые структуры и обмен знаниями: Компания активно развивает горизонтальные связи, минуя формальную иерархию.
   • Гильдии (`Guilds`): Это добровольные сообщества по интересам (например, гильдия веб-разработчиков или гильдия по качеству). Они служат для обмена знаниями, выработки лучших практик и решения общих проблем.
   • Культура взаимопомощи и внутренние инструменты: Использование корпоративного Slack и внутреннего аналога Stack Overflow поощряет открытый обмен информацией. Репутация инженера или команды отчасти зависит от их готовности помогать другим.
   • «Встраивание» (`Embedding`): Практика временного (до трех месяцев) «одалживания» инженеров между командами. Это помогает быстро передавать экспертизу, решать проблемы с зависимостями и укреплять социальные связи.

Что выходит?

• Масштабируемая автономия возможна и эффективна. Модель Spotify доказывает, что можно предоставить командам значительную свободу даже в очень крупной организации. Ключ к успеху — в способности команд к самоорганизации, сотрудничеству и коллективному принятию решений.
• Автономия требует ответственности и согласованности. Свобода не работает без «благоприятствующих ограничений». Именно эти рамки позволяют всей системе оставаться управляемой и двигаться в одном направлении.
• Основные барьеры для автономии не всегда связаны с менеджментом. Главными препятствиями являются технические и организационные зависимости между командами, недостаточная зрелость самих команд (неумение управлять своими процессами) и нехватка нужных компетенций.
• Существует «цепь автономии». Производительность всей системы ограничена ее самым медленным и наименее автономным звеном. Проблемы одной команды быстро становятся проблемами для многих других, которые от нее зависят.
• Главный вызов — поддержание модели при росте. По мере роста компании поддерживать культуру автономии и эффективные горизонтальные связи становится все сложнее. Это требует постоянных усилий и адаптации существующих практик.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по созданию надежных ML-систем

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

1. Целостный подход к надежности. ML-система — это не только модель. Это данные, признаки, код, конвейеры и мониторинг. Цель — не просто высокая точность, а построение надежной и заслуживающей доверия системы ieeexplore.ieee.org.

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

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

4. Проактивный мониторинг. Настройте алерты на аномалии во входных данных (data drift), падение качества предсказаний (model drift) и нарушение ключевых бизнес-метрик. Это ваш радар для обнаружения скрытого технического долга в реальном времени.

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

6. Кросс-функциональные команды и культура. Жесткое разделение ролей «исследователь» (Data Scientist) и «инженер» (ML Engineer) — корень многих проблем. Наиболее успешные команды — это гибридные группы, где инженеры и исследователи работают вместе. Такая культура ценит не только прирост точности, но и упрощение системы, удаление лишних признаков и снижение общей сложности.

Заключение

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

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

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

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

Аннотация

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно еще почитать тут: https://habr.com/ru/articles/955536/

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

🆚 Arc vs. GigAPI: Сравнительная таблица

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

Ключевые отличия в подходах: Arc и GigAPI

Arc: Максимальная простота и скорость для старта

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

• Идеология: “Батарейки в комплекте”. Arc предоставляет готовое решение с ACID-транзакциями, time travel и эволюцией схемы “из коробки”. Он спроектирован для максимальной простоты развертывания и сверхбыстрого приема данных.
• Сценарий использования: Идеален для R&D, прототипирования и внутренних проектов, где нужна высокая производительность без сложной настройки.
• Ключевой компромисс: Лицензия AGPL-3.0 требует, чтобы любое сетевое приложение, использующее Arc, также открывало свой исходный код. Это делает его неприменимым для многих коммерческих продуктов.

GigAPI: Операционная мощь для продакшена

GigAPI gigapi — это не база данных, а скорее интеллектуальный операционный слой или шлюз, который работает поверх ваших данных.

• Идеология: “Оркестратор и оптимизатор”. GigAPI фокусируется на промышленной эксплуатации и автоматизации рутинных задач. Его микросервисы (`merge`, `move`, `drop`) следят за здоровьем хранилища: уплотняют мелкие файлы, перемещают старые данные в дешевое S3-хранилище и удаляют их по истечении срока жизни (TTL).
• Сценарий использования: Построение зрелого, экономически эффективного и надежного пайплайна для временных рядов в production-среде. Разрешительная лицензия MIT делает его отличным выбором для бизнеса.
• Ключевое преимущество: Архитектурная гибкость и фокус на снижении эксплуатационных расходов (OpEx).

А где же DuckLake?

DuckLake — это не база данных, а открытый табличный формат и расширение для DuckDB ducklake. Его цель — упростить создание Lakehouse, используя SQL в качестве слоя метаданных ducklake blog.

Представьте, что у вас есть набор Parquet-файлов в S3. Чтобы работать с ними как с единой таблицей и иметь транзакции, традиционно нужен сложный компонент вроде Hive Metastore или Nessie. DuckLake предлагает более простой путь:

Используйте обычную SQL-базу (например, DuckDB, SQLite или даже Postgres) для хранения всей метаинформации о файлах, версиях и схеме.

Таким образом, DuckLake — это фундаментальный строительный блок, а не готовое приложение. Он конкурирует с Apache Iceberg и Delta Lake, предлагая более простую альтернативу. Недавние обновления даже добавили совместимость с Iceberg, что делает его еще более мощным инструментом ducklake.select.

Сравнение с рынком: Альтернативы и выбор

Когда что выбирать?

• Выберите Arc, если вам нужен максимально быстрый старт для прототипа или внутреннего проекта, вы не боитесь альфа-версии и вас полностью устраивает лицензия AGPL-3.0.

• Выберите GigAPI, если вы строите продакшн-систему, вам важна автоматизация рутинных задач (compaction, tiering, TTL) и нужна разрешительная лицензия MIT для коммерческого использования.

• Используйте DuckLake, если вы уже работаете с DuckDB и хотите построить свой собственный, простой Lakehouse на базе Parquet-файлов, избегая сложности стека Hadoop/Spark.

• Обратитесь к ClickHouse/Druid, когда нужны жесткие SLA, горизонтальное масштабирование и высокий параллелизм для тысяч одновременных пользователей.

• Рассмотрите QuestDB/Timescale, если приоритетом является предельно простой опыт работы с TSDB или глубокая интеграция с экосистемой Postgres.

Заключение

Arc, GigAPI и DuckLake — яркие представители тренда на прагматичные и экономичные решения для данных.

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

Их появление говорит о том, что рынку нужны не только монструозные системы, но и решения с оптимальным соотношением “простота/стоимость/функциональность”.

Вот так выглядит:

services:
  gigapi:
    image: ghcr.io/gigapi/gigapi:latest
    container_name: gigapi
    hostname: gigapi
    restart: unless-stopped
    volumes:
      - ./data:/data
    ports:
      - "7971:7971"
      - "8082:8082"
    environment:
      - PORT=7971
      - GIGAPI_ENABLED=true
      - GIGAPI_MERGE_TIMEOUT_S=10
      - GIGAPI_ROOT=/data
      - GIGAPI_LAYERS_0_NAME=default
      - GIGAPI_LAYERS_0_TYPE=fs
      - GIGAPI_LAYERS_0_URL=file:///data
      - GIGAPI_LAYERS_0_GLOBAL=false
      - GIGAPI_LAYERS_0_TTL=12h
      - GIGAPI_LAYERS_1_NAME=s3
      - GIGAPI_LAYERS_1_TYPE=s3
      - GIGAPI_LAYERS_1_URL=s3://gateway.XXXXX/test/gigapi
      - GIGAPI_LAYERS_1_AUTH_KEY=XXXXX
      - GIGAPI_LAYERS_1_AUTH_SECRET=XXXXX
      - GIGAPI_LAYERS_1_GLOBAL=true
      - GIGAPI_LAYERS_1_TTL=0

А данные пишем так:

cat <<EOF | curl -X POST "http://localhost:7971/write?db=mydb" --data-binary @/dev/stdin
weather,location=us-midwest,season=summer temperature=82
weather,location=us-east,season=summer temperature=123
weather,location=us-west,season=summer temperature=111
EOF

Первый раз нужно отправить сообщение, что бы создалась база.

файлики пишет, но че то пока не на s3, видимо надо дождаться как они переедут с кеша на s3

Выше пример не сработал, точнее он работал, но не копировал данные на s3

вот это рабочий вариант

# docker-compose.yml
version: '3.8'

services:
  gigapi:
    build: . 
    container_name: gigapi
    restart: unless-stopped
    volumes:
      - ./gigapi_data:/data
    ports:
      - "7971:7971"
      - "8082:8082"
    environment:
      # --- Общие настройки GigAPI ---
      - GIGAPI_ROOT=/data 
      - HTTP_PORT=7971
      - LOGLEVEL=info
      - GIGAPI_UI=true

      # --- Конфигурация Слоя 0: Локальный кэш на диске ---
      - GIGAPI_LAYERS_0_NAME=local_cache
      - GIGAPI_LAYERS_0_TYPE=fs
      - GIGAPI_LAYERS_0_URL=file:///data/cache
      - GIGAPI_LAYERS_0_GLOBAL=false
      - GIGAPI_LAYERS_0_TTL=10m

      # --- Конфигурация Слоя 1: Хранилище Storj S3 ---
      - GIGAPI_LAYERS_1_NAME=storj_s3
      - GIGAPI_LAYERS_1_TYPE=s3
      - GIGAPI_LAYERS_1_URL=s3://gateway.storjshare.io/test/gigapi/data?url-style=path
      - GIGAPI_LAYERS_1_AUTH_KEY=XXXXXX
      - GIGAPI_LAYERS_1_AUTH_SECRET=XXXXX
      - GIGAPI_LAYERS_1_GLOBAL=true
      - GIGAPI_LAYERS_1_TTL=0

И пришлось серты обновить

# Dockerfile

# Берем за основу официальный образ gigapi
FROM ghcr.io/gigapi/gigapi:latest

# Переключаемся на пользователя root для установки пакетов
USER root

# Обновляем список пакетов и устанавливаем корневые сертификаты.
# Эта команда сначала пытается использовать 'apt-get' (для Debian/Ubuntu).
# Если эта команда завершается с ошибкой (оператор ||), то
# выполняется вторая команда с 'apk' (для Alpine).
# Это делает Dockerfile более универсальным.
RUN if command -v apt-get &> /dev/null; then \
        apt-get update && apt-get install -y --no-install-recommends ca-certificates && apt-get clean && rm -rf /var/lib/apt/lists/*; \
    elif command -v apk &> /dev/null; then \
        apk add --no-cache ca-certificates; \
    else \
        echo "Error: Neither apt-get nor apk found. Cannot install ca-certificates." >&2; \
        exit 1; \
    fi

# Возвращаемся к стандартному пользователю (если он есть)
# USER gigapi

Там кстати еще чатгпт апи можно вставить

И дашборды есть еще

Еще про s3 подобные архитектуры:
https://gavrilov.info/all/sozdaem-streaming-lakehouse-za-chas-rukovodstvo-po-risingwave-la

*25 сентября 2025 г.*
*Мика Уайлд, Алекс Грэм, Жером Шнайдер*

https://blog.cloudflare.com/cloudflare-data-platform/

На неделе разработчиков в апреле 2025 года мы анонсировали публичную бета-версию R2 Data Catalog, полностью управляемого каталога Apache Iceberg поверх объектного хранилища Cloudflare R2. Сегодня мы развиваем эту область тремя новыми запусками:

• Cloudflare Pipelines получает события, отправленные через Workers или HTTP, преобразует их с помощью SQL и загружает в Iceberg или в виде файлов в R2.
• R2 Data Catalog управляет метаданными Iceberg и теперь выполняет постоянное обслуживание, включая уплотнение (compaction), для повышения производительности запросов.
• R2 SQL — наш собственный распределенный SQL-движок, разработанный для выполнения запросов петабайтного масштаба к вашим данным в R2.

Вместе эти продукты составляют Платформу данных Cloudflare (Cloudflare Data Platform) — комплексное решение для приема, хранения и запроса аналитических данных.

Как и все продукты Платформы для разработчиков Cloudflare , все они работают на нашей глобальной вычислительной инфраструктуре. Они построены на открытых стандартах и совместимы. Это означает, что вы можете использовать свой собственный движок запросов для Iceberg — будь то PyIceberg, DuckDB или Spark, — подключаться к другим платформам, таким как Databricks и Snowflake, и не платить за исходящий трафик (egress fees) при доступе к вашим данным.

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

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

Как мы пришли к созданию Платформы данных?

Мы запустили объектное хранилище `R2 Object Storage` в 2021 году с радикальной ценовой стратегией: никакой платы за исходящий трафик (egress fees) — это плата за пропускную способность, которую традиционные облачные провайдеры взимают за выгрузку данных, фактически держа ваши данные в заложниках.

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

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

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

Однако пользователям все еще приходилось управлять всей инфраструктурой метаданных самостоятельно. Мы поняли, что можем решить эту проблему, и так появился `R2 Data Catalog` — наш управляемый каталог Iceberg. Но оставалось несколько пробелов:

1. Как загружать данные в таблицы Iceberg?
2. Как оптимизировать их для повышения производительности запросов?
3. Как извлекать ценность из данных, не размещая собственный движок запросов?

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

Cloudflare Pipelines

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

Созданные на базе `Arroyo` (движка потоковой обработки, который мы приобрели в этом году), `Pipelines` получают события, преобразуют их с помощью SQL-запросов и направляют (sinks) в R2 и R2 Data Catalog.

`Pipelines` организованы вокруг трех ключевых объектов:

• Streams (Потоки): Способ получения данных в Cloudflare. Это надежные буферизованные очереди, которые принимают события по HTTP или через привязку к Cloudflare Worker.
• Sinks (Приемники): Определяют место назначения ваших данных. Мы поддерживаем загрузку в R2 Data Catalog, а также запись необработанных файлов в R2 в формате JSON или Apache Parquet.
• Pipelines (Конвейеры): Соединяют потоки и приемники через SQL-преобразования, которые могут изменять события перед их записью.

Например, вот конвейер, который принимает события из источника данных о кликах (clickstream) и записывает их в Iceberg, отфильтровывая ботов и события, не являющиеся просмотрами страниц:

INSERT into events_table
SELECT
 user_id,
 lower(event) AS event_type,
 to_timestamp_micros(ts_us) AS event_time,
 regexp_match(url, '^https?://([^/]+)')[1] AS domain,
 url,
 referrer,
 user_agent
FROM events_json
WHERE event 'page_view'
 AND NOT regexp_like(user_agent, '(?i)bot|spider');

SQL-преобразования позволяют вам:

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

`Cloudflare Pipelines` доступны сегодня в открытой бета-версии. Во время беты мы не взимаем плату за `Pipelines`, однако хранение и операции в `R2` оплачиваются по стандартным тарифам blog.cloudflare.com.

R2 Data Catalog

Мы запустили открытую бету `R2 Data Catalog` в апреле и были поражены откликом blog.cloudflare.com. Начать работу с Iceberg стало просто — не нужно настраивать кластер баз данных или управлять инфраструктурой.

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

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

Сегодня мы запускаем поддержку уплотнения в `R2 Data Catalog`. Включить его для вашего каталога очень просто:

$ npx wrangler r2 bucket catalog compaction enable mycatalog

Во время открытой беты мы не взимаем плату за `R2 Data Catalog`. Ниже наши предполагаемые будущие цены:

*\*цены могут быть изменены до официального выпуска.*

R2 SQL

Иметь данные в `R2 Data Catalog` — это только первый шаг. Реальная цель — извлечь из них ценность. Традиционно это означает настройку и управление Spark, Trino или другим движком запросов. А что, если бы вы могли выполнять запросы прямо на Cloudflare?

Теперь можете. Мы создали движок запросов, специально разработанный для `R2 Data Catalog` и пограничной инфраструктуры Cloudflare. Мы называем его R2 SQL, и он доступен сегодня в виде открытой беты.

Выполнить запрос к таблице `R2 Data Catalog` с помощью Wrangler так же просто, как:

$ npx wrangler r2 sql query "{WAREHOUSE}" "SELECT user_id, url FROM events WHERE domain = 'mywebsite.com'"

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

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

Подводя итоги

Сегодня вы можете использовать Платформу данных Cloudflare для приема событий в `R2 Data Catalog` и их запроса через `R2 SQL`. В первой половине 2026 года мы планируем расширить возможности всех этих продуктов, включая:

• Интеграцию с `Logpush`, чтобы вы могли преобразовывать, хранить и запрашивать свои логи прямо в Cloudflare.
• Пользовательские функции через `Workers` и поддержку обработки с состоянием для потоковых преобразований.
• Расширение функционала `R2 SQL` для поддержки агрегаций и объединений (joins).

Хакатао по дешевке :)

Налетай, торопись покупай живопись

Мне у хакатао медведь нравится :) оч крутой

https://superrare.com/artwork/eth/0xb932a70A57673d89f4acfFBE830E8ed7f75Fb9e0/25999

UPD:

Ушла королева))