В разработке программного обеспечения управление доступом пользователей — одна из критически важных задач. От того, кто и какие действия может выполнять в приложении, напрямую зависит его безопасность, функциональность и надежность. Исторически логика авторизации часто была разбросана по всему коду приложения, что приводило к появлению архитектурного антипаттерна, известного как «Большой ком грязи» (Big Ball of Mud).

Что такое «Большой ком грязи»? Это система, в которой отсутствует четкая архитектура. Логика авторизации, выраженная в бесконечных `if-else` конструкциях, смешивается с бизнес-логикой, обработкой данных и представлением. Такую систему практически невозможно поддерживать, аудировать и масштабировать. Любое изменение в правах доступа требует переписывания кода в разных местах, что увеличивает риск ошибок и уязвимостей.

Современный подход заключается в отделении логики авторизации от основного кода приложения с помощью специализированных инструментов — механизмов политик (Policy Engines). Эти системы позволяют централизованно определять, управлять и применять правила доступа. В предоставленном материале рассматриваются три ведущих механизма: OPA (Open Policy Agent), OpenFGA и AWS Cedar.

Основной подход: Политика как код vs. Политика как данные

Ключевое различие между механизмами политик заключается в их подходе к определению правил. Это разделение можно описать как «управляемые политикой» (policy-driven) и «управляемые данными» data-driven https://www.permit.io/blog/policy-engine-showdown-opa-vs-openfga-vs-cedar.

1. Управляемые политикой (Policy-Driven)
   В этой модели основная логика авторизации описывается в виде кода на специальном декларативном языке. Данные, такие как атрибуты пользователя или ресурса, передаются в механизм во время запроса для принятия решения.

• Cedar (AWS): Яркий пример такого подхода. Cedar делает акцент на читаемости и безопасности политик. Политики пишутся так, чтобы их было легко понять и верифицировать. Joy Scharmen из StrongDM отмечает: «Cedar очень ориентирован на политики. Данные проходят через систему как эфемерный ввод, не требуя предопределенной модели данных» https://www.permit.io/blog/policy-engine-showdown-opa-vs-openfga-vs-cedar. Это идеально для систем, где важна предсказуемость и простота аудита.

2. Управляемые данными (Data-Driven)
   Здесь ядром системы являются данные, описывающие *отношения* между субъектами (пользователями) и объектами (ресурсами). Политика — это, по сути, модель, которая интерпретирует эти отношения.

• OpenFGA (на основе Google Zanzibar): Этот механизм реализует модель управления доступом на основе отношений (ReBAC). Вы определяете модель (например, «владелец документа может его удалить»), а конкретные связи («пользователь `Alice` является владельцем `document:123`») хранятся как данные https://www.permit.io/blog/opa-cedar-openfga-why-are-policy-languages-trending. Этот подход чрезвычайно масштабируем для систем со сложными иерархиями и связями, как в Google Docs или социальных сетях.

3. Гибридный подход
   Некоторые механизмы поддерживают оба подхода.

• OPA (Open Policy Agent): OPA является универсальным механизмом общего назначения https://www.permit.io/blog/policy-engines. Он позволяет как загружать данные и политики в виде «пакетов» (bundles), так и получать их динамически во время выполнения. Это дает максимальную гибкость, но требует более тщательного проектирования архитектуры.

Архитектурные модели развертывания

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

• Централизованная модель: Все сервисы обращаются к единому центральному сервису авторизации.
  • Плюсы: Единый источник правды, консистентность решений.
  • Минусы: Может стать узким местом (bottleneck) и единой точкой отказа.
• Децентрализованная модель: Механизм политик разворачивается как «сайдкар» (sidecar) рядом с каждым экземпляром приложения.
  • Плюсы: Минимальная задержка (latency), высокая отказоустойчивость.
  • Минусы: Требует синхронизации политик и данных между всеми экземплярами.
• Гибридная модель: «Управляй централизованно, авторизуй локально». Политики и данные управляются из центра, но доставляются на децентрализованные механизмы для локального принятия решений.

Для решения проблемы синхронизации в децентрализованных моделях существуют инструменты, такие как OPAL (Open Policy Administration Layer). OPAL работает поверх OPA, Cedar и OpenFGA, обнаруживая изменения в политиках и данных в реальном времени и доставляя обновления агентам https://docs.opal.ac.

Сравнение механизмов: плюсы и минусы

Итог: нет “победителя”, есть правильный инструмент

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

• Если у вас сложная система с множеством взаимосвязанных разрешений (например, совместное редактирование документов, социальная сеть), OpenFGA — ваш выбор.
• Если вам нужен универсальный инструмент для управления политиками в разных частях стека (Kubernetes, CI/CD, микросервисы) и ваша команда готова изучить новый язык, OPA предоставит максимальную гибкость.
• Если ваша главная цель — простая, безопасная и легко проверяемая авторизация в приложении, и вы цените читаемость политик, Cedar будет отличным стартом.

Переход от «большого кома грязи» к внешним механизмам политик — это шаг к созданию более надежных, безопасных и поддерживаемых систем. Благодаря таким проектам, как OPA, OpenFGA, Cedar и инструментам вроде OPAL, разработчики получают мощные средства для построения современных систем управления доступом https://www.permit.io/blog/introduction-to-opal

OPA + OPAL == 💜

https://github.com/permitio/opal?tab=readme-ov-file

Спойлер ...

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

Оригинал тут: https://apacheseatunnel.substack.com/p/apache-seatunnel-new-positioning

Введение

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

Проблемы предыдущей архитектуры

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

1. Зависимость от сторонних движков: Для выполнения даже самых простых задач по пересылке данных требовалось развертывание и поддержка тяжеловесных кластеров Spark или Flink. Это увеличивало накладные расходы, усложняло настройку и повышало порог входа для новых пользователей.
2. Сложность конфигурации: Пользователям приходилось разбираться не только в конфигурации самого SeaTunnel, но и в настройках Spark/Flink, что часто приводило к так называемому “конфигурационному аду”.
3. Ограничения коннекторов: Разработка коннекторов была тесно связана с API Spark и Flink, что затрудняло создание универсальных коннекторов, работающих в обеих средах без изменений.
4. Низкая производительность для простых задач: Использование мощных, но громоздких движков для элементарных задач ETL (Extract, Transform, Load) было избыточным и неэффективным с точки зрения ресурсов и времени запуска.

Новое видение: унифицированная платформа с собственным движком

Чтобы решить эти проблемы и соответствовать современным требованиям, сообщество Apache SeaTunnel представило новую архитектуру, в основе которой лежит собственный вычислительный движок — SeaTunnel Engine.

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

• Легковесность и быстрота: `SeaTunnel Engine` специально оптимизирован для задач интеграции данных. Он запускается быстрее и потребляет значительно меньше ресурсов, чем полноценные кластеры Spark или Flink, что делает его идеальным для широкого круга задач.
• Унификация пакетной и потоковой обработки: Новая архитектура изначально спроектирована для бесшовной работы как с пакетными (batch), так и с потоковыми (streaming) данными. Пользователям больше не нужно поддерживать два разных стека для разных типов задач — SeaTunnel предоставляет единый интерфейс и модель выполнения.
• Упрощенная разработка коннекторов: С введением унифицированного API коннекторов (`Connector API`), разработчикам стало проще создавать новые интеграции. Коннектор, написанный для `SeaTunnel Engine`, будет работать одинаково для всех сценариев, что ускоряет расширение экосистемы.

Мультимодальная интеграция данных

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

1. Структурированные данные: Традиционная область для SeaTunnel. Поддерживается множество реляционных баз данных (MySQL, PostgreSQL), аналитических СУБД (ClickHouse, Doris) и хранилищ данных.
2. Полуструктурированные данные: Эффективная работа с NoSQL базами данных (MongoDB, Elasticsearch) и потоками событий (Kafka, Pulsar).
3. Неструктурированные данные: Расширение поддержки для озер данных (Data Lakes) и файловых систем (HDFS, S3, OSS). Это включает интеграцию с форматами вроде Apache Hudi, Iceberg и Delta Lake.

Особое внимание уделяется критически важным функциям, таким как Захват изменяемых данных (CDC) и синхронизация всей базы данных целиком. SeaTunnel теперь может считывать журналы транзакций (например, binlog в MySQL) для захвата изменений в реальном времени и применять их к целевой системе. Функция полной синхронизации позволяет в одной задаче перенести схему и все данные из одной базы в другую, что значительно упрощает миграцию.

Будущее развитие

Дорожная карта проекта включает в себя:

• Расширение экосистемы коннекторов: Добавление поддержки еще большего числа источников и приемников, включая современные SaaS-платформы и векторные базы данных для задач ИИ.
• Улучшенная поддержка озер данных: Углубление интеграции с форматами Hudi и Iceberg, поддержка эволюции схем и транзакционных операций.
• Пользовательский интерфейс: Разработка визуального интерфейса для создания и мониторинга заданий, что сделает инструмент более доступным для широкого круга пользователей.
• Повышение производительности и стабильности: Непрерывная оптимизация `SeaTunnel Engine` для еще более быстрой и надежной обработки данных.

Заключение

Apache SeaTunnel совершает важный переход от зависимого инструмента к самостоятельной, легковесной и унифицированной платформе для интеграции данных. Отказ от обязательной привязки к Spark/Flink и внедрение собственного `SeaTunnel Engine` открывают новые возможности для пользователей, которым нужно простое, но мощное решение для пакетной и потоковой обработки разнородных данных. Новое позиционирование делает SeaTunnel сильным конкурентом в мире современных ETL/ELT инструментов.

---

Выводы

Проанализировав направление развитие Apache SeaTunnel, можно сделать несколько ключевых выводов:

1. Стратегическая зрелость: Переход на собственный движок (`SeaTunnel Engine`) — это признак зрелости проекта. Команда осознала, что зависимость от универсальных, но тяжеловесных движков (Spark/Flink) является узким местом для основного сценария использования — интеграции данных. Создание специализированного движка позволяет оптимизировать производительность и снизить накладные расходы именно для этих задач.
2. Соответствие трендам: Этот шаг полностью соответствует общему тренду в индустрии данных — движению от монолитных, “умеющих все” платформ к более легковесным и специализированным инструментам. Для многих задач по перемещению и простой трансформации данных запуск Spark-кластера является избыточным. SeaTunnel теперь предлагает “золотую середину”.
3. Конкурентное позиционирование:
   • Против коммерческих SaaS ETL (Fivetran, Airbyte): SeaTunnel является мощной open-source альтернативой. Он привлекателен для компаний, которые хотят полного контроля над своей инфраструктурой, стремятся избежать зависимости от поставщика (vendor lock-in) и имеют техническую экспертизу для самостоятельного развертывания и поддержки.
   • Против специализированных CDC-инструментов (Debezium): SeaTunnel не просто захватывает изменения (CDC), а встраивает эту функциональность в полноценный конвейер интеграции. Это решение “все в одном”, которое позволяет не только извлечь данные, но и доставить их в целевую систему (например, озеро данных или хранилище) в рамках одного инструмента.
4. Фокус на “мультимодальности” — это задел на будущее. Поддержка не только реляционных баз и Kafka, но и озер данных (Hudi, Iceberg) и, в перспективе, векторных баз, говорит о том, что проект нацелен на обслуживание современных стеков данных, включая аналитику в реальном времени и конвейеры для машинного обучения (MLOps).

Рекомендации

Исходя из этого, можно дать следующие рекомендации:

1. Кому стоит обратить внимание на Apache SeaTunnel:
   • Командам, для которых Spark/Flink избыточны. Если ваша основная задача — это синхронизация данных между различными источниками (например, из MySQL в ClickHouse или из Kafka в HDFS) без сложных вычислений, `SeaTunnel Engine` может оказаться значительно более эффективным и простым в эксплуатации решением.
   • Компаниям, ищущим open-source замену коммерческим ETL-инструментам. Если у вас есть экспертиза для управления Java-приложениями и вы хотите построить гибкую, масштабируемую и экономичную платформу интеграции данных, SeaTunnel — отличный кандидат.
   • Пользователям экосистемы Apache. Проект тесно интегрируется с другими популярными проектами Apache (Doris, Hudi, Flink, Spark), что делает его естественным выбором для тех, кто уже использует эти технологии.
   • Инженерам, которым нужна унификация. Если вы устали поддерживать отдельные скрипты или инструменты для пакетной и потоковой обработки, SeaTunnel предлагает единый подход к обоим сценариям.

2. Что нужно проверить перед внедрением:
   • Экосистему коннекторов: Самое важное — убедиться, что в SeaTunnel есть готовые, стабильные коннекторы для всех ваших источников и приемников данных. Хотя сообщество активно их добавляет, покрытие может быть не таким широким, как у коммерческих лидеров рынка.
   • Функциональность CDC: Если вам нужен захват изменений в реальном времени, детально изучите поддержку вашей СУБД. Проверьте, насколько стабильно работает коннектор и какие гарантии доставки (exactly-once, at-least-once) он предоставляет.
   • Операционная сложность: Несмотря на то, что SeaTunnel стал проще, это все еще open-source инструмент, требующий мониторинга, настройки и периодических обновлений. Убедитесь, что у вашей команды есть ресурсы для его поддержки.

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

Крутой блог по всей экостистеме кафка, примеры по iceberg которые разобраны ниже

https://rmoff.net/2025/07/04/writing-to-apache-iceberg-on-s3-using-kafka-connect-with-glue-catalog/

небольшой пост про CDC от автора книги гроккаем конкурентность

https://luminousmen.com/post/change-data-capture

дока по iceberg-sink connector

https://github.com/databricks/iceberg-kafka-connect

kafka vizualizer

https://softwaremill.com/kafka-visualisation/

А тут видосик:

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

Другие типы SCD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

`DimCustomer`

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

{% snapshot customers_snapshot %}

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

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

    {% endsnapshot %}

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Apache Iceberg

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

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

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

2. Snowflake

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

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

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

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

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

Ссылки

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

https://github.com/facebookresearch/dinov3

Новая вижн моделька

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

https://arxiv.org/pdf/2504.17033

Что сделали эти ученые?

Авторы статьи dl.acm.org – Ран Дуань, Цзяи Мао, Сяо Мао, Синькай Шу и Лунхуэй Инь – нашли способ “обойти” это ограничение сортировки для ориентированных графов (где дороги односторонние) с неотрицательными весами (стоимость дорог не может быть отрицательной). Они разработали новый алгоритм, который быстрее Дейкстры на “разреженных” графах (где дорог не слишком много по сравнению с количеством точек).

В чем прорыв?

Их алгоритм работает за время, которое записывается как *O(m log^(2/3) n)*, где *m* – количество дорог, а *n* – количество точек. Это первое асимптотическое улучшение по сравнению с алгоритмом Дейкстры, который обычно работает за *O(m + n log n)*. Простыми словами, на больших, но не слишком “запутанных” картах их метод работает заметно быстрее.

Как им это удалось, простыми словами?

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

1. “Ранний выход” (Bellman-Ford-подобная идея): Они делают несколько шагов, которые позволяют быстро найти кратчайшие пути для точек, находящихся относительно близко или имеющих небольшое количество “прыжков” от уже найденных кратчайших путей. Это похоже на то, как если бы вы сначала быстро прокладывали короткие маршруты, не заботясь о полном порядке удаленности.
2. “Разделяй и властвуй” (Dijkstra-подобная идея): Когда им нужно найти пути к более отдаленным точкам, они делят проблему на несколько более мелких и решают их рекурсивно (повторяя тот же процесс для каждой меньшей части). При этом, благодаря первому подходу, им не приходится “сортировать” слишком много точек на каждом шаге.

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

Области применения:

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

• Навигационные системы:** Прокладка маршрутов в картах (Google Maps, Яндекс.Карты).
• Сетевые протоколы:** Определение оптимальных путей для передачи данных в компьютерных сетях.
• Логистика и доставка:** Планирование маршрутов для курьеров, грузовиков.
• Робототехника:** Планирование перемещения роботов в пространстве.
• Игры:** Поиск пути для персонажей и объектов.
• Биоинформатика:** Анализ связей в биологических сетях.

Применение в работе с данными, платформами данных и федеративными SQL-движках:

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

• Графовые базы данных и аналитика:** В базах данных, ориентированных на графы (например, Neo4j, ArangoDB), часто выполняются запросы на поиск кратчайших путей между узлами. Ускорение базового алгоритма означает более быстрое выполнение таких запросов, что критично для интерактивной аналитики, анализа связей (например, мошенничество, социальные сети) и рекомендательных систем.
• Оптимизация SQL-запросов (федеративные движки SQL):** В федеративных SQL-движках, которые объединяют данные из разных источников, оптимизатор запросов должен выбрать наиболее эффективный способ получения данных. Если данные распределены в виде графов (даже логически, не обязательно физически графовая база данных), то поиск “оптимального присоединения” таблиц может быть смоделирован как задача кратчайшего пути. Более быстрый алгоритм ССКП может помочь оптимизатору запросов находить лучшие планы выполнения быстрее, особенно с развитием графовых расширений SQL.
• Платформы данных и потоковая обработка:** В системах потоковой обработки данных, где графы могут формироваться “на лету” (например, потоки событий, транзакций), необходимо оперативно вычислять кратчайшие пути для обнаружения аномалий, анализа зависимостей или определения влияния. Более быстрые алгоритмы позволят обрабатывать больший объем данных в реальном времени. Например, в мониторинге инфраструктуры может потребоваться быстро вычислять пути отказа.

Важно отметить:

• “Разреженные” графы:** Основное преимущество этого нового алгоритма проявляется на графах, где количество связей *m* не слишком велико по сравнению с квадратом количества точек *n* (т.е. граф не “полностью” связан). Это типично для многих реальных сценариев (дорожные сети, большинство социальных сетей).
• Неотрицательные веса:** Как и Дейкстра, этот алгоритм рассчитан на случаи, когда “стоимость” проезда по дороге не может быть отрицательной. Для графов с отрицательными весами существуют другие, более сложные алгоритмы, которые также улучшаются (например, https://arxiv.org/abs/2311.02520 https://arxiv.org/abs/2407.04872).

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

https://docs.lakekeeper.io – картинка как у меня не грузится сайт лейкипера. https://github.com/lakekeeper/lakekeeper/issues/1119

В мире современных озер данных (Data Lakehouse) связка Trino и Apache Iceberg стала синонимом производительности и гибкости. Но чтобы эта связка работала по-настоящему эффективно, необходим центральный элемент — каталог метаданных. И если раньше выбор был ограничен Hive Metastore или JDBC, то сегодня стандарт де-факто — это REST Catalog API.

REST-каталог — это не просто технология, это идеология. Он отделяет движок запросов от хранилища метаданных, позволяя десяткам инструментов (Trino, Spark, Flink, dbt) работать с данными через единый, универсальный и не зависящий от вендора интерфейс.

Это руководство — погружение во все доступные на рынке REST-каталоги ( почти все ). Мы оценим их готовность к продакшену в Kubernetes, уникальные преимущества и то, как они вписываются в современный стек данных.

Почему REST-каталог — это новый стандарт?

1. Централизация и универсальность: Один каталог для всех. Trino, Spark и Flink видят одно и то же состояние данных. Атомарные коммиты для нескольких таблиц и серверное разрешение конфликтов становятся возможными.
2. Гибкость развертывания: REST-сервис — это независимый, stateless-компонент, идеально подходящий для Kubernetes. Его можно легко развернуть, масштабировать и обновлять.
3. Безопасность на уровне каталога: Вы можете централизованно управлять доступом, использовать OAuth2 и даже выдавать временные учетные данные для доступа к S3, не прописывая секреты в каждом движке.
4. Поддержка всех функций Iceberg: REST API спроектирован для поддержки самых передовых возможностей Iceberg, которые не всегда доступны в старых типах каталогов.

Обзор и рейтинг REST-каталогов: Битва титанов

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

1. Project Nessie: Git для ваших данных

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

• Ключевые преимущества:
  • Git-like операции: Создавайте изолированные ветки для экспериментов (`dev`, `feature-branch`) и сливайте их в основную (`main`) атомарно. Идеально для CI/CD пайплайнов данных.
  • Декларативные транзакции: Гарантирует консистентность при одновременных операциях с несколькими таблицами.
  • Экосистема: Отличная документация, интеграция с dbt и инструменты для миграции с Hive Metastore.
• Готовность к Kubernetes: Высокая. Nessie имеет официальный Helm chart, что значительно упрощает развертывание и управление в K8s. Требует отдельного процесса для сборки мусора (Garbage Collection).
• Кому подходит: Командам, которые хотят внедрить DevOps-практики (DataOps) в работу с данными, обеспечивая изоляцию, воспроизводимость и безопасные обновления.
• GitHub: projectnessie/nessie

2. Apache Gravitino (Incubating): Универсальный федеративный мета-каталог

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

• Ключевые преимущества:
  • Федерация: Может выступать прокси для существующих каталогов (Hive, JDBC, REST), объединяя их под единым API.
  • Каскадные запросы в Trino: Позволяет одному кластеру Trino запрашивать данные из каталогов другого кластера Trino.
  • Широчайшая экосистема: Поддерживает не только Iceberg, но и реляционные СУБД, ClickHouse, и даже каталог для Kafka, позволяя управлять топиками. Есть планы по управлению метаданными ИИ/ML моделей.
  • Безопасность: Поддерживает OAuth2 и Kerberos для бэкенда Hive.
• Готовность к Kubernetes: Средняя. Проект активно развивается, но требует внимательной конфигурации. Необходимо учитывать требования к версиям Trino (например, 435-439 для некоторых функций).
• Кому подходит: Крупным организациям со сложной, гетерогенной средой, которые стремятся унифицировать управление метаданными из разных источников (Data Lake, DWH, Streaming).
• GitHub: apache/gravitino

3. Apache Amoro (Incubating, ранее Arctic): Самооптимизирующийся каталог

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

• Ключевые преимущества:
  • Автоматическая оптимизация: Встроенные механизмы для `compaction` (объединение мелких файлов) и `clustering` для поддержания высокой производительности запросов без ручного вмешательства.
  • Поддержка смешанных форматов: Может управлять не только Iceberg, но и Paimon (Flink), а также таблицами смешанного формата.
  • Экосистема: Есть интеграция с ClickHouse, Flink, Spark и Trino. Предлагается облачная версия Arctic Cloud.
• Готовность к Kubernetes: Высокая. Проект нацелен на облачные развертывания и предоставляет инструменты для автоматизации обслуживания.
• Кому подходит: Компаниям с высоконагруженными озерами данных (high-throughput data lakes), где постоянно идет запись данных, и требуется автоматическое поддержание производительности.
• Сайт: ((https://amoro.apache.org/ amoro.apache.org)

4. Lakekeeper: Крепость безопасности на Rust

Lakekeeper — это новый игрок, написанный на Rust, с абсолютным фокусом на безопасности, управлении доступом и интеграции с облаками.

• Ключевые преимущества:
  • Безопасность во главе угла: Использует Vended-Credentials для безопасного доступа к S3, интегрируется с OpenID для аутентификации и OpenFGA для детальной авторизации (Fine Grained Access).
  • Нативен для Kubernetes: Развертывается через Helm chart, может аутентифицировать сервисные аккаунты Kubernetes. Оператор в разработке.
  • Событийная архитектура: Генерирует события об изменениях (CloudEvents) в Kafka или NATS, что позволяет строить реактивные пайплайны.
  • Data Contracts: Может проверять изменения по внешним системам контрактов данных, чтобы предотвратить нарушение схем.
  • Легковесность: Единый бинарный файл без зависимостей от JVM или Python.
• Готовность к Kubernetes: Очень высокая. Это, возможно, самый “Kubernetes-native” каталог из всех, созданный с нуля для облачных сред.
• Кому подходит: Организациям, для которых безопасность, управление доступом и аудит являются главным приоритетом. Идеален для мульти-облачных и мульти-тенантных сред.
• GitHub: lakekeeper/lakekeeper

5. Denali: Минималистичная “зверюга” на Go

Denali от Bodo.ai — это антитеза сложным enterprise-системам. Его философия — максимальная простота и производительность.

• Ключевые преимущества:
  • Экстремальная легковесность: Написан на Go, менее 5000 строк кода, развертывается как один бинарный файл на ~20MB.
  • Простота развертывания: Минимальные зависимости (бэкендом может быть SQLite или PostgreSQL). Идеален для быстрых тестов и легковесных продакшен-сред.
  • Высокая производительность: Отсутствие оверхеда JVM и компилируемая природа Go.
• Готовность к Kubernetes: Высокая. Благодаря своей простоте и отсутствию состояния, Denali легко упаковывается в контейнер и управляется в Kubernetes.
• Кому подходит: Командам, которые ценят простоту, производительность и полный контроль над инфраструктурой. Отличный выбор для стартапов и проектов, где не нужна сложная федерация или enterprise-функции.
• GitHub: [Bodo-inc/denali](https://github.com/Bodo-inc/denali)

6. Tabular: Управляемый сервис от создателей Iceberg

Tabular — это не open-source проект, а полностью управляемый SaaS-продукт от сооснователей Apache Iceberg.

• Ключевые преимущества:
  • Нулевое администрирование: Вы просто получаете эндпоинт REST-каталога и используете его. Вся инфраструктура, обновления и безопасность — на стороне Tabular.
  • Надежность и поддержка: Коммерческая поддержка от экспертов, которые создали Iceberg.
  • Интеграции: Глубокая интеграция с dbt, Confluent/Kafka.
• Готовность к Kubernetes: Неприменимо. Это SaaS-решение, вы не развертываете его самостоятельно.
• Кому подходит: Компаниям любого размера, которые хотят сфокусироваться на аналитике, а не на управлении инфраструктурой.

Другие важные игроки

• Apache Polaris (Incubating): Официальная реализация REST-каталога от Apache. Цель — стать эталонной. Имеет роли, неймспейсы и документацию для продакшена, но пока менее зрелый, чем конкуренты. [polaris.apache.org](https://polaris.apache.org/)
• Databricks Unity Catalog: Мощнейший каталог, но тесно интегрированный в экосистему Databricks. Поддерживает REST API и уникальную технологию Delta Sharing для безопасного обмена данными. “Модный, молодежный” выбор для тех, кто уже живет в мире Databricks.

Сводная таблица

Пример конфигурации Trino

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

# etc/catalog/my_iceberg_catalog.properties
connector.name=iceberg
iceberg.catalog.type=rest
# URI вашего REST-сервиса
iceberg.rest-catalog.uri=http://lakekeeper-service.default.svc.cluster.local:8181/catalog
# Путь к хранилищу по умолчанию
iceberg.rest-catalog.warehouse=s3://my-warehouse/
# Настройки безопасности (пример для OAuth2)
iceberg.rest-catalog.security=OAUTH2
iceberg.rest-catalog.oauth2.token=<your-token>

Заключение: Как сделать правильный выбор?

Выбор REST-каталога — это стратегическое решение, которое определит гибкость и масштабируемость вашей платформы данных.

• 🥇 Для Enterprise с фокусом на безопасность и Kubernetes: Lakekeeper — очевидный лидер благодаря нативным K8s-интеграциям и мощным функциям безопасности.
• 🥈 Для сложных сред и федерации: Apache Gravitino предлагает уникальные возможности по объединению разрозненных источников метаданных.
• 🥉 Для чистого DataOps: Project Nessie остается лучшим в своем классе для реализации Git-подобных рабочих процессов.
• 🚀 Для быстрого старта и простоты: Denali позволяет запустить производительный каталог с минимальными усилиями.
• 💸 Когда время дороже денег: Tabular снимает всю головную боль по администрированию.

Эпоха привязки к одному инструменту прошла, поэтому ждем Cedrus Catalog с батарейками и свистелками 🤪REST-каталоги дают свободу, а Trino, и не только — возможность этой свободой воспользоваться. Выбирайте оружие по своей задаче и стройте по-настоящему открытый и мощный Data Lakehouse 🏡

ps: Конечно печатала ИИ, может не очень объективно давать оценки, но список хороший. Я ей помогал, как мог.

Ссылки:
https://github.com/projectnessie/nessie – https://projectnessie.org
https://github.com/apache/gravitino – https://gravitino.apache.org
https://github.com/apache/amoro – https://amoro.apache.org
https://github.com/lakekeeper/lakekeeper – https://docs.lakekeeper.io
https://github.com/apache/polaris – https://polaris.apache.org
https://github.com/unitycatalog/unitycatalog – https://unitycatalog.io

Все это можно быстро и просто запустить тут: https://www.ploomber.io

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

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

Категория 1: Фреймворки для создания веб-приложений и дашбордов

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

Streamlit

• GitHub Stars: 40.8k+
• Официальный сайт: streamlit.io
• GitHub Repo: streamlit

Описание и назначение: Streamlit — это, возможно, самый популярный фреймворк для быстрого создания data-приложений. Его философия — превратить скрипты в красивые веб-интерфейсы с минимальными усилиями. Приложение работает по простой модели: скрипт выполняется сверху вниз при каждом взаимодействии пользователя, что упрощает управление состоянием.

Особенности и оценка:

• Сильные стороны: Невероятная простота и скорость разработки. Идеально подходит для создания прототипов, демо и внутренних инструментов medium.com. Отличная документация и большое сообщество.
• Слабые стороны: Модель “перезапуска всего скрипта” может быть неэффективной для сложных приложений с большим количеством состояний. Кастомизация интерфейса за пределами стандартных компонентов может быть сложной задачей ai.gopubby.com.

Dash

• GitHub Stars: 23.9k+
• Официальный сайт: plotly.com/dash
• GitHub Repo: github.com/plotly/dash

Описание и назначение: Dash от создателей Plotly — это мощный фреймворк для создания аналитических веб-приложений. Он использует Flask, Plotly.js и React.js под капотом, предоставляя Python-разработчикам доступ к современным веб-технологиям.

Особенности и оценка:

• Сильные стороны: Высокая степень кастомизации и контроля. Идеален для корпоративных дашбордов и сложных приложений, требующих уникального дизайна и функциональности. Отличная интеграция с экосистемой Plotly.
• Слабые стороны: Более высокий порог вхождения по сравнению со Streamlit. Концепция “коллбэков” требует времени для освоения.

Solara

• GitHub Stars: 2.1k+
• Официальный сайт: solara.dev
• GitHub Repo: github.com/widgetti/solara

Описание и назначение: Solara позволяет создавать веб-приложения на чистом Python, используя компонентный подход, похожий на React. Он построен на базе Ipywidgets и может работать как в Jupyter Notebook, так и в виде самостоятельных приложений.

Особенности и оценка:

• Сильные стороны: Компонентная архитектура способствует созданию чистого и переиспользуемого кода. Хорошо подходит для создания масштабируемых приложений корпоративного уровня ai.gopubby.com.
• Слабые стороны: Менее известен, чем Streamlit или Dash, что означает меньшее сообщество и меньше готовых решений.

Gradio

• GitHub Stars: 39.4k+
• Официальный сайт: gradio.app
• GitHub Repo: github.com/gradio-app/gradio

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

Особенности и оценка:

• Сильные стороны: Максимальная простота для демонстрации моделей. Поддерживает различные типы ввода/вывода (текст, изображения, аудио). Легко встраивается в Jupyter/Colab и генерирует публичные ссылки для демонстрации.
• Слабые стороны: Не предназначен для создания сложных, многостраничных дашбордов. Фокус смещен на “вход -> модель -> выход”. Структура приложения `app.py` часто используется для бэкенда при создании мультимодальных инструментов ai.plainenglish.io.

Shiny for Python & Shiny Express

• GitHub Stars: 1.6k+ (Python)
• Официальный сайт: shiny.posit.co/py
• GitHub Repo: github.com/posit-dev/py-shiny

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

Особенности и оценка:

• Сильные стороны: Мощная реактивная модель позволяет создавать очень эффективные приложения. Отличная интеграция с инструментами от Posit (ранее RStudio).
• Слабые стороны: Сообщество в Python пока меньше, чем у аналогов. Реактивная модель требует особого подхода к мышлению.

Panel

• GitHub Stars: 5.4k+
• Официальный сайт: panel.holoviz.org
• GitHub Repo: github.com/holoviz/panel

Описание и назначение: Panel — это мощный фреймворк из экосистемы HoloViz. Его главная особенность — совместимость практически с любой библиотекой для визуализации в Python. Он позволяет объединять виджеты и графики в гибкие макеты.

Особенности и оценка:

• Сильные стороны: Непревзойденная гибкость и совместимость с другими библиотеками. Отлично подходит, если вы уже используете инструменты HoloViz (hvPlot, HoloViews).
• Слабые стороны: Может показаться более многословным и сложным для простых задач по сравнению со Streamlit.

Другие интересные фреймворки UI

• Chainlit (10k+ звезд): Специализированный фреймворк для быстрого создания чат-интерфейсов для LLM-агентов и приложений на базе LangChain/LlamaIndex.
• Hyperdiv (900+ звезд): Предлагает новый подход: Python-код выполняется на сервере и мгновенно синхронизирует UI в браузере. Компоненты объявляются в простом, декларативном стиле.
• Vizro (3k+ звезд): Конфигурационный фреймворк поверх Dash. Позволяет создавать дашборды через YAML или Pydantic-модели, что упрощает разработку.
• Voilà (5.8k+ звезд): Превращает Jupyter-ноутбуки в самостоятельные веб-приложения, скрывая код и оставляя только виджеты и выводы ячеек.

---

Категория 2: Бэкенд и MLOps (Развертывание и управление)

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

FastAPI

• GitHub Stars: 88.2k+
• Официальный сайт: fastapi.tiangolo.com
• GitHub Repo: github.com/tiangolo/fastapi

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

Особенности и оценка:

• Сильные стороны: Невероятная производительность. Автоматическая интерактивная документация (Swagger UI, ReDoc). Простота использования благодаря Pydantic и аннотациям типов.
• Слабые стороны: Это бэкенд-фреймворк. Для создания UI его нужно использовать в связке с фронтенд-технологиями.

vLLM

• GitHub Stars: 54.8k+
• Официальный сайт: vllm.ai
• GitHub Repo: github.com/vllm-project/vllm

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

Особенности и оценка:

• Сильные стороны: Значительно ускоряет работу LLM благодаря инновационным техникам, таким как PagedAttention. Совместимость с моделями Hugging Face. Становится стандартом для быстрого self-hosting LLM.
• Слабые стороны: Узкоспециализированный инструмент для инференса LLM.

MLflow

• GitHub Stars: 21.5k+
• Официальный сайт: mlflow.org
• GitHub Repo: github.com/mlflow/mlflow

Описание и назначение: MLflow — это платформа с открытым исходным кодом для управления полным жизненным циклом машинного обучения. Он включает в себя компоненты для отслеживания экспериментов (Tracking), упаковки кода (Projects), управления моделями (Models) и их развертывания (Registry).

Особенности и оценка:

• Сильные стороны: Комплексное решение для MLOps. Помогает стандартизировать и воспроизводить ML-эксперименты. Интегрируется с большинством ML-библиотек.
• Слабые стороны: Требует настройки и внедрения в рабочий процесс. Может быть избыточным для небольших проектов.

---

Категория 3: Интерактивные вычисления и отчетность

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

Quarto

• GitHub Stars: 4.7k+ (CLI)
• Официальный сайт: quarto.org
• GitHub Repo: github.com/quarto-dev/quarto-cli

Описание и назначение: Quarto — это система публикации научных и технических документов нового поколения от Posit. Она позволяет создавать динамические документы и презентации из Jupyter-ноутбуков или простого Markdown, смешанного с кодом на Python, R или Julia.

Особенности и оценка:

• Сильные стороны: Поддерживает множество форматов вывода (HTML, PDF, DOCX, презентации и др.). Языковая агностичность. Позволяет создавать красивые, профессиональные и воспроизводимые отчеты.
• Слабые стороны: В первую очередь это инструмент для публикации, а не для создания интерактивных real-time приложений.

Marimo

• GitHub Stars: 15.3k+
• Официальный сайт: marimo.io
• GitHub Repo: github.com/marimo-team/marimo

Описание и назначение: Marimo — это реактивная среда для Python, которая решает многие проблемы традиционных Jupyter-ноутбуков. В Marimo ноутбук — это интерактивное веб-приложение. Изменение в одной ячейке автоматически обновляет все зависимые ячейки.

Особенности и оценка:

• Сильные стороны: Реактивность обеспечивает консистентность состояния. Встроенные UI-элементы. Ноутбуки легко экспортируются в виде приложений.
• Слабые стороны: Новый инструмент с растущим, но пока небольшим сообществом. Отличается от привычного рабочего процесса в Jupyter.

---

Как выбрать подходящий инструмент?

• Для быстрого прототипа или демо модели: Streamlit или Gradio.
• Для сложного, кастомизированного корпоративного дашборда: Dash или Solara.
• Для создания бэкенда и API для вашей модели: FastAPI.
• Для максимальной производительности при развертывании LLM: vLLM.
• Для построения полноценного MLOps-цикла: MLflow.
• Для создания чат-бота на базе LLM: Chainlit.
• Для создания красивых, воспроизводимых отчетов и статей: Quarto.
• Если вы хотите попробовать реактивный, state-of-the-art ноутбук: Marimo.
• Если вы из мира R или вам нравится реактивная парадигма: Shiny for Python.

marimo is an open-source reactive notebook for Python — reproducible, Git-friendly, AI-native, SQL built-in, executable as a script, shareable as an app.

Ставим скорее..

pip install marimo && marimo tutorial intro

Ну и small data тоже любит тетрадки https://duckdb.org/docs/stable/guides/python/marimo

в общим долго рассказывать, но штука модная и крутая :) потом еще расскажу

про bi as a code можно посмотреть тут: https://gavrilov.info/all/samye-populyarnye-instrumenty-biznes-analitiki-na-osnove-koda-ob/

А тут есть пример использования  iceberg каталога R2 c Marimo https://developers.cloudflare.com/r2/data-catalog/get-started/

А так в него можно добавить AI

UW PICO 5.09                          File: /Users/yuriygavrilov/.config/marimo/marimo.toml                             

[completion]
activate_on_typing = true
copilot = "custom"
api_key = "sk-GIkXXXXXXXXXX"
model = "openai/o1"
base_url = "https://openai.api.proxyapi.ru/v1"

и чуть ниже так..

[ai.open_ai]
api_key = "sk-GIkXXXXXXXXXX"
model = "openai/o1"
base_url = "https://openai.api.proxyapi.ru/v1"

Но как полечить это я еще не разгадал:

[E 250811 22:03:05 tools:173] Failed to get MCP tools: mcp is required for MCP server connections.

а пока усложняем задачу.

Хех, работает :)

Кстати уже писал про Bi as Code тут https://gavrilov.info/all/samye-populyarnye-instrumenty-biznes-analitiki-na-osnove-koda-ob/

Но будет полезно еще почитать по WASM контейнеры и запуст их в браузере, так как вся эта история на них хорошо работает, Evidence.dev например.

UPD: https://a.gavrilov.info/my_app2/dist/ – тут можно посмотреть экспортированную демо тетрадку в формате wasm с хостингом на s3

Экспортируются тетрадки так:

uv run  marimo export html-wasm markdown-format1.md -o my_app2/dist --include-cloudflare --mode run

Потом просто надо загрузить папку my_app2 в нужную директорию в все будет работать.

А вот еще пример генерации кода c ИИ

Тут можно посмотреть пример барчата https://a.gavrilov.info/my_app3/dist/