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/

Часть 1: Книга “I Love Logs” EVENT DATA, STREAM PROCESSING, AND DATA INTEGRATION

Джей Крепс

Оригинал тут: I_Heart_Logs-Jay_Kreps.pdf

Оригинальные идеи и рекомендации книги:

1. Лог как фундаментальная абстракция:
   • Ключевая идея: лог — это не просто текстовый файл для отладки, а упорядоченная, неизменяемая (append-only) последовательность записей (событий), снабженная уникальными, последовательно увеличивающимися номерами (offset’ами), которые служат “временем” в распределенной системе.
   • Он является “источником истины” (`source of truth`) и позволяет восстановить состояние системы.
   • State Machine Replication Principle: Если два детерминированных процесса начинают в одном состоянии и получают одинаковые входные данные в одном и том же порядке, они произведут одинаковый вывод и закончат в одном и том же состоянии. Лог обеспечивает этот “одинаковый порядок”.

2. Роль логов в базах данных:
   • Логи лежат в основе работы ACID-баз данных (commit log, transaction log) для обеспечения атомарности, изоляции и долговечности.
   • Используются для репликации данных между мастером и репликами (Change Data Capture – CDC).

3. Применения логов:
   • Интеграция данных (Data Integration): Лог становится центральной “магистралью данных” или единой “шиной событий” для всей организации. Он решает проблему интеграции “N систем с N системами” (N²) путем преобразования ее в “N систем с одним логом” (N). Крепс приводит “Иерархию потребностей Маслоу для данных” (сбор/аквизиция данных, семантика, понимание, автоматизация), подчеркивая, что без надежного сбора данных невозможно ничего другого.

• Организационная масштабируемость**: Ответственность за чистоту и формат данных лежит на *производителе* данных, а не на потребителях или центральной команде ETL.
• Потоковая обработка в реальном времени (Real-time Stream Processing): Лог — это естественное представление потока данных. Любое событие в реальном времени, база данных, изменяющаяся с течением времени, — всё это логи.
• Крепс выступает за Kappa-архитектуру как альтернативу Lambda-архитектуре.
• Критика Lambda: Дублирование логики (один и тот же расчет в batch и stream слоях), сложность оперирования.
• Альтернативная модель репроцессинга: Вместо двух отдельных фреймворков (batch и stream) — использовать единую потоковую систему, которая может пересчитывать историю, используя лог как источник исторических данных. Когда логика меняется, запускается новый потоковый Job с начала лога, записывающий результат в новую таблицу, и после догона старая таблица заменяется новой.
• Проектирование распределенных систем: Лог упрощает дизайн. Вместо того, чтобы каждая система занималась согласованностью, репликацией и восстановлением, эти функции можно передать логированию.
• Паттерн “Сервис = Лог + Serving Layer”: Лог хранит все изменения (source of truth), а “serving layer” (например, поисковая система, key-value хранилище) строит индексированные или материализованные представления на основе лога для быстрых запросов.

4. Технические особенности и оптимизации:
   • Партиционирование лога: Для горизонтального масштабирования (Kafka). Позволяет обрабатывать записи независимо, не требует глобального порядка. Порядок гарантируется только в пределах одной партиции.
   • Батчинг (Batching): Соединение мелких операций в крупные для повышения пропускной способности.
   • Zero-Copy Data Transfer: Передача данных между слоями памяти без их копирования, что улучшает производительность.
   • Log Compaction (Компактирование лога): Оптимизация хранения для “лагов изменений” (changelogs). Вместо хранения всех версий записи, оставляется только последняя версия для каждого ключа. Это позволяет восстановить *текущее* состояние, но не *всю* историю.

5. Дуальность таблиц и событий (Tables and Events Are Dual):
   • Крепс проводит аналогию с системами контроля версий (Git): история изменений (патчи) — это лог, а текущая рабочая копия — это таблица.
   • Данные могут свободно “перетекать” между состоянием (таблица) и потоком изменений (лог).

Стоило бы дополнить (2023-2024):

1. Эволюция экосистемы:
   • Книга вышла в 2014 году. С тех пор Kafka стала де-факто стандартом. Появились альтернативы Apache Pulsar его, кстати, умеет читать и писать Seatunnel :) и множество надстроек/фреймворков (Kafka Streams, Flink SQL, Materialize).
   • Рост Serverless-архитектур и их интеграция с логами (AWS Lambda, Google Cloud Functions, Azure Functions как потребители логов).
   • Повсеместное использование Kubernetes и операторов для развертывания и управления Kafka-кластерами.

2. Управление схемами (Schema Management):
   • Книга упоминает структурированные логи, но не углубляется в детали. Сегодня критически важен Schema Registry (например, Confluent Schema Registry или http://apicur.io) для обеспечения совместимости схем данных в логах и управления их версиями. Это предотвращает “data swamp” и делает логи действительно надежным источником данных.

3. Качество данных и Observability:
   • Помимо “структуры”, важна *семантика* и *качество* данных. Мониторинг “data quality”, “data lineage” (происхождение данных) и “data governance” становятся ключевыми.
   • Observability: Трассировка событий через лог-пайплайн (например, OpenTelemetry), сбор метрик (lag потребителей, пропускная способность, ошибки) с Prometheus/Grafana.

4. Безопасность (Security):
   • Шифрование данных в пути (TLS) и в состоянии покоя (at-rest encryption).
   • Аутентификация и авторизация (RBAC) для продюсеров и потребителей Kafka.
   • Аудит доступа к логам.

5. Паттерны микросервисной архитектуры:
   • Event Sourcing и CQRS стали стандартными паттернами.
   • Saga Pattern для координации распределенных транзакций между микросервисами, часто реализуемых через лог.
   • Data Mesh: Принцип, что данные должны рассматриваться как продукт. Команда-владелец домена отвечает за свой “дата-продукт” и предоставляет его через лог, который является частью этого “продукта”.

6. Real-time Analytics и ML:
   • Пайплайны с логами используются для обучения и инференса ML-моделей в реальном времени. Например, логи кликов для рекомендательных систем.
   • Появление GPU-ускоренных фреймворков для потоковой обработки (например, NVIDIA RAPIDS).

7. Антипаттерны и ошибки: Конкретные примеры из практики, как неправильное внедрение логов может привести к проблемам.

---

Часть 2: Современный взгляд Логи: Кровеносная система Data-Driven компаний

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

В эпоху распределенных систем, микросервисов, Big Data и искусственного интеллекта, когда скорость обработки информации определяет конкурентное преимущество, традиционные подходы к интеграции и обработке данных трещат по швам. Книга, которая у вас в руках – это переосмысление ключевых идей Джея Крепса, соавтора Apache Kafka, о том, как “скромный” лог превратился из технической детали в центральный архитектурный примитив.

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

---

Глава 1: Лог: Недооцененный фундамент современных систем

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

Что такое Лог? Глубже, чем кажется.
Представьте себе не просто текстовый файл, а упорядоченную, неизменяемую последовательность записей. Каждая запись добавляется в конец. Это фундаментальное отличие от базы данных, где данные можно изменять “на месте”. В логе ни одна запись не удаляется и не меняется. Вместо этого, новые изменения *добавляются* как новые записи.

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

Принцип State Machine Replication: Волшебство порядка
Это краеугольный камень распределенных систем. Он гласит:

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

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

*Пример из практики*: Банковский счет. Вместо хранения одного числа (текущий баланс), мы храним лог всех транзакций: “снятие 1000 руб.”, “поступление 5000 руб.”. Текущий баланс – это всего лишь функция, которая суммирует все записи в логе до текущего момента. Если банк “забудет” состояние баланса, он всегда может его восстановить, проиграв лог всех транзакций.

Логи в базах данных: Невидимый двигатель
Внутри любой надежной реляционной базы данных или NoSQL-хранилища уже давно работает лог: `commit log` или `transaction log`. Он гарантирует, что даже при сбое системы, транзакции не будут потеряны, а данные останутся согласованными (свойства ACID). Механизмы репликации баз данных (например, бинарные логи MySQL или WAL PostgreSQL) – это по сути потоковая передача записей из такого лога. Это и есть Change Data Capture (CDC) – захват изменений данных.

Дополнение (2023-2024):

• Структурированные логи и схемы: Для машинного чтения и обработки логам необходим строгий формат. Сегодня это почти всегда JSON, Apache Avro или Google Protocol Buffers.
  • Рекомендация: Используйте Schema Registry**. Это централизованное хранилище ваших схем, которое позволяет эволюционировать схемы логов, не ломая обратную совместимость. Оно критически важно для долгосрочной жизнеспособности вашей data-инфраструктуры. Без Schema Registry ваши логи быстро превратятся в “data swamp” – болото неструктурированных, непонятных данных.
• Лог как Event Stream: В современных архитектурах каждый чих в системе – это событие. Логи веб-сервера, действия пользователя, метрики микросервисов, изменения в БД – все это может быть представлено как лог событий.

Ошибки, которых стоит избегать:

1. “Лог для людей, а не для машин”: Если вы используете логи только для чтения человеком при отладке, вы упускаете их колоссальный потенциал как источника данных для других систем.
2. Отсутствие структурированности: Произвольные текстовые сообщения в логах делают их крайне сложными для автоматического анализа и интеграции. Всегда! используйте структурированные форматы.
3. Игнорирование порядка: Если события записываются без гарантии порядка, вы никогда не сможете надежно воспроизвести состояние системы или построить корректные агрегаты.

---

Глава 2: Данные как потоки: Интеграция через Логи

Одна из самых болезненных проблем в больших компаниях – это интеграция данных. Исторически это решалось кастомными ETL (Extract, Transform, Load) пайплайнами, где каждая система “говорила” с каждой. Такая модель приводит к экспоненциальному росту сложности (N² соединений для N систем).

Централизованная шина событий: Революция в интеграции
Идея Крепса: вместо N² соединений, создайте универсальный централизованный лог, который будет выступать в роли “шины событий” или “артерии данных”.

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

```mermaid
graph LR
A[Система 1 (Продюсер)] -- Публикует --> C(Центральный Лог)
B[Система 2 (Продюсер)] -- Публикует --> C
C -- Потребляет --> D[Система A (Потребитель)]
C -- Потребляет --> E[Система B (Потребитель)]
C -- Потребляет --> F[Система C (Потребитель)]
```

Вместо множества прямых соединений между A-D, A-E, A-F, B-D, B-E, B-F, мы получаем лишь несколько соединений к центральному логу. Сложность снижается с N² до N.

Иерархия потребностей данных по Маслоу (адаптировано Крепсом):

1. Аквизиция/Сбор данных: Самый важный базовый уровень. Без надежного, полного и структурированного сбора данных не имеет смысла говорить о чём-то другом. Многие компании пытаются “прыгнуть” сразу к ИИ и машинному обучению, имея хаотично собираемые данные. Это обратная логика.
2. Семантика: Понимание значения данных, их контекста, метаданных.
3. Понимание: Способность строить отчеты, визуализации.
4. Автоматизация: Реализация сложных алгоритмов, прогнозов.

Задача интеграции данных лежит в основе этой иерархии. Логи — это инструмент для её решения.

Дополнение (2023-2024):

• Data Mesh и Data Products: Эта концепция идеально ложится на идею центрального лога. Каждая команда-владелец домена (например, “Клиенты”, “Заказы”) становится ответственной за свой “Data Product”. Этот продукт включает в себя данные (часто в виде топиков лога), их схемы, качество, доступность и документацию.
  • Рекомендация: Внедряйте `Data Contracts`. Это соглашения между командами о структуре и семантике данных, которые они передают через лог, аналогично API-контрактам.
• Cloud-Native решения:
  • Managed Kafka: Облачные провайдеры предлагают управляемые сервисы Kafka (Confluent Cloud, AWS MSK, Azure Event Hubs). Это снимает бремя операционного управления.
  • CDC: Инструменты вроде Debezium позволяют легко интегрировать изменения из традиционных баз данных (PostgreSQL, MySQL, MongoDB) напрямую в Kafka в реальном времени, превращая их в логи событий.
• Трансформации данных: Где делать ETL?
  • Source-side: Продюсер должен публиковать максимально чистые, канонические данные.
  • Stream-side: Для добавления обогащённых данных или агрегатов могут быть использованы потоковые процессоры (см. Глава 3), создающие новые, производные топики лога.
  • Sink-side: Минимальные трансформации при загрузке в целевые системы (например, для специфичных схем БД хранилища).

Ошибки, которых стоит избегать:

1. “Big Ball of Mud”: Не пытайтесь создавать слишком сложные ETL-пайплайны внутри самого лога. Идеально, если лог остаётся “сырым” источником событий, а трансформации и обогащения происходят в отдельных потоковых приложениях.
2. Отсутствие ownership: Если нет четкой ответственности за данные, опубликованные в логе, они быстро теряют качество. Команда-производитель должна быть “владельцем” своих данных в логе.
3. Blindly копирование всего: Не все данные нужны всем. Фильтруйте и маршрутизируйте данные к нужным потребителям, чтобы не перегружать системы и сократить расходы.

---

Глава 3: Потоковая обработка в реальном времени и не только

Логи и потоковая обработка неотделимы друг от друга. Лог — это естественная модель для потока событий.

Что такое потоковая обработка? Шире, чем кажется.
Крепс расширил определение потоковой обработки. Это не просто “обработка данных по мере их поступления и затем отбрасывание”. Это непрерывная обработка данных, способная выдавать результаты с низкой задержкой, но при этом иметь дело с историческими данными (то есть, лог можно переиграть).

От Lambda к Kappa: Парадокс репроцессинга
Традиционная Lambda-архитектура предполагала два параллельных пути обработки:

• Batch-слой (партия): Высокая задержка, высокая точность, обработка всей истории (например, Hadoop MapReduce).
• Speed-слой (скорость): Низкая задержка, возможно, меньшая точность, обработка только новых данных (например, Storm).
  Результаты из обоих слоев объединяются для получения полной картины.

Проблема Lambda: Дублирование бизнес-логики. Один и тот же расчет должен быть написан и поддерживаться дважды, на двух разных фреймворках (например, HiveQL/Spark для batch и Flink/Storm для stream). Это приводит к ошибкам, задержкам в разработке и высоким операционным издержкам.

Kappa-архитектура (Преимущество лога): Изобретая колесо заново, но лучше.
Крепс предложил элегантную альтернативу — Kappa-архитектуру, которая устраняет необходимость в отдельном batch-слое. Идея проста:

1. Храните все сырые данные в логе (Kafka): Настройте достаточно длинный `retention` (срок хранения), например, 30, 90 дней или даже дольше, если это необходимо для исторического анализа.
2. Единый потоковый процессор: Используйте один фреймворк (например, Apache Flink, Kafka Streams) для обработки данных. Этот же код обрабатывает как новые, так и исторические данные.
3. Репроцессинг без боли: Если вам нужно изменить логику обработки или исправить ошибку:
   • Запустите новый экземпляр потокового Job.
   • Он начинает читать данные с начала лога.
   • Результаты записываются в новую целевую таблицу/топик.
   • Как только новый Job “догонит” текущее время, переключите потребителей с “устаревшей” целевой таблицы на “новую”.
   • Остановите и удалите старый Job и старую таблицу.

```mermaid
graph TD
    A[Исходный Лог (Kafka)]
    B[Старый Processing Job (v1)]
    C[Новый Processing Job (v2)]

    A -- Читает с offset 0 --> C
    A -- Читает с текущего offset --> B

    B -- Записывает в --> D[Старая Выходная Таблица]
    C -- Записывает в --> E[Новая Выходная Таблица]

    F[Приложение]-->D
    subgraph Reprocessing
        C
    end
    subgraph Switch
        direction LR
        F --> G[Переключить на E]
        G --> H[Удалить D, остановить B]
    end
```

Дополнение (2023-2024):

• Фреймворки:
  • Apache Flink**: Де-факто стандарт для сложных stateful-вычислений с `exactly-once` семантикой. Поддерживает `event time`, `watermarks` (для обработки событий, пришедших не по порядку) и гибкие окна агрегации.
  • Kafka Streams / ksqlDB**: Для более простых задач обработки в рамках экосистемы Kafka. Идеально для микросервисов.
  • Apache Spark Streaming / Structured Streaming**: Позволяет использовать привычные API Spark для потоков.
• Работа с состоянием (Stateful Processing): Многие потоковые задачи требуют сохранения состояния (например, подсчёт уникальных пользователей за час). Современные фреймворки (Flink) позволяют хранить это состояние отказоустойчиво, часто используя RocksDB локально и чекпоинты в удаленном хранилище (S3/HDFS).
• Real-time OLAP / Data Warehousing: Появляется класс решений, которые строят агрегаты и индексы напрямую из логов для интерактивных аналитических запросов (например, ClickHouse, Apache Druid, Materialize).
• GPU-ускорение: Для ML-инференса и сложных расчетов на потоках, где время критично (например, обнаружение аномалий, фрод-мониторинг), начинают использоваться GPU-ускоренные библиотеки (NVIDIA RAPIDS).

Ошибки, которых стоит избегать:

1. Игнорирование late data: События в реальном мире не всегда приходят по порядку. Используйте `watermarks` и `event time` для корректной обработки “поздних” данных.
2. Репроцессинг “на потом”: Откладывание возможности репроцессинга приводит к накоплению технического долга и невозможности быстро исправлять ошибки в логике. Заложите её в архитектуру с самого начала.
3. Чрезмерное усложнение: Не пытайтесь написать собственный потоковый движок. Используйте проверенные фреймворки, они уже решили большинство проблем с распределенностью, отказоустойчивостью и производительностью.

---

Глава 4: Логи как фундамент для отказоустойчивых систем

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

Паттерн “Сервис = Лог + Serving Layer”
В этом паттерне логика сервиса разделяется на две основные части:

1. Лог (The Log): Выступает как *единственный источник истины* для всех изменений состояния сервиса. Все записи (события, команды) сначала попадают в лог.
2. Serving Layer (Слой обслуживания/запросов): Это набор вычислительных узлов, которые подписываются на лог и строят локальные, оптимизированные для запросов, представления данных (индексы).
   • Пример: Пользователь хочет обновить свой профиль. Запрос на обновление фиксируется как событие в логе. Serving Layer, потребляя это событие, обновляет свою локальную копию данных (например, в базе данных или поисковом индексе Elasticsearch). Когда пользователь запрашивает профиль, запрос идет в Serving Layer.
   • Преимущество: Serving Layer может быть оптимизирован под конкретный тип запроса (например, Elasticsearch для полнотекстового поиска, Redis для быстрого key-value доступа), но при этом получать все данные из единого, надежного лога.

```mermaid
graph TD
    A[Client] --> B[API Gateway/Микросервис записи]
    B -- Записывает событие/изменение --> C(Центральный Лог)

    C -- Подписывается --> D[Serving Layer 1 (напр. Elasticsearch)]
    C -- Подписывается --> E[Serving Layer 2 (напр. Redis Cache)]
    C -- Подписывается --> F[Serving Layer 3 (напр. Data Warehouse)]

    A -- Читает --> D
    A -- Читает --> E
```

Преимущества такой архитектуры:

• Отказоустойчивость и восстановление: Если Serving Layer упадет, он может полностью восстановить свое состояние, “проиграв” лог с самого начала или с последнего чекпоинта. Лог является его бэкапом.
• Изоляция сбоев: Падение одного Serving Layer не влияет на способность других Serving Layer’ов продолжать работу.
• Детерминированность: Гарантия порядка из лога обеспечивает согласованность данных во всех Serving Layer’ах.
• Горизонтальное масштабирование: Лог можно партиционировать (делим данные на части), и каждый Serving Layer может обрабатывать одну или несколько партиций, что позволяет добавлять узлы по мере роста нагрузки.
• Отсутствие блокировок: Поскольку записи идут в лог, а чтение происходит из Serving Layer, это значительно снижает конкуренцию и улучшает параллелизм.

Log Compaction: Компактирование истории
Не всегда нужно хранить полную историю каждого изменения. Например, если вы отслеживаете текущее местоположение курьера, вам нужна только *последняя* координата, а не весь его путь.

• Log Compaction (компактирование лога) – это процесс, при котором для каждого ключа в логе сохраняется только его *последнее* значение, а все предыдущие дубликаты удаляются.
  Это позволяет логу действовать как changelog (журнал изменений), который, будучи проигранным с начала, воссоздаст *текущее* состояние распределенной таблицы.
• Пример: Kafka умеет выполнять компактирование топиков, что идеально подходит для хранения состояния Key-Value пар (например, текущие балансы счетов, последние известные IP-адреса).

Дополнение (2023-2024):

• Event Sourcing: Паттерн, при котором основное состояние приложения сохраняется как последовательность событий в логе, а не как изменяемое состояние в базе данных. Состояние агрегатов получается путем применения всех событий.
• Command Query Responsibility Segregation (CQRS): Часто используется вместе с Event Sourcing. Команды (изменения) записываются в лог, а запросы (чтения) обслуживаются из оптимизированных для чтения материализованных представлений, построенных из того же лога.
• Saga Pattern: Для координации долгих распределенных транзакций между множеством микросервисов, лог событий часто используется как механизм асинхронной связи и координации. Каждый сервис публикует событие о завершении своей части работы, а координатор Саги реагирует на эти события.
• Kubernetes Operators: Для управления сложностью распределенных лог-систем, таких как Kafka, существуют Kubernetes Operators, которые автоматизируют развертывание, масштабирование, восстановление и обновление кластеров.
• Observability (наблюдаемость): Логи — это не только данные, но и инструмент для понимания поведения системы. Добавьте трассировку (`trace_id` в события) для отслеживания пути запроса через множество микросервисов и логов. Анализируйте `consumer lag` (отставание потребителей) как ключевую метрику здоровья потоковой системы.

Ошибки, которых стоит избегать:

1. “Я напишу свою Kafka”: Построение надежной распределенной лог-системы чрезвычайно сложно. Используйте проверенные решения (Kafka, Pulsar).
2. Забыть о версионировании: Изменения в структуре событий могут сломать старых потребителей. Используйте Schema Registry и стратегии совместимости схем (backward/forward compatibility).
3. Ручное управление состоянием: Не пытайтесь управлять состоянием stateful-приложений вручную. Доверьте эту задачу фреймворкам потоковой обработки, которые используют лог для отказоустойчивости.

---

Глава 5: Безопасность, Надежность и Операционная Эффективность

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

Безопасность (Security): Доверяй, но проверяй

1. Шифрование данных:
   • В пути (In-transit Encryption): Всегда используйте TLS (Transport Layer Security) для обмена данными между клиентами (продюсерами/потребителями) и брокерами лога, а также между самими брокерами.
   • В состоянии покоя (At-rest Encryption): Шифруйте данные на диске, где хранятся логи. Это может быть реализовано на уровне операционной системы, файловой системы или диска (LUKS, AWS EBS Encryption).
2. Аутентификация и Авторизация (Authentication & Authorization – RBAC):
   • Аутентификация: Убедитесь, что только доверенные клиенты могут подключаться к лог-системе (например, с помощью SASL/Kerberos, SSL-сертификатов или OAuth 2.0).
   • Авторизация (RBAC): Применяйте принцип наименьших привилегий. Контролируйте, кто может записывать в конкретные топики, а кто может читать из них. Отдельные приложения могут иметь разрешения только на чтение из определённых топиков и запись в свои собственные выходные топики.
3. Аудит (Auditing): Включите логи аудита для всех действий в лог-системе (кто, когда, что изменил или прочитал).

Надежность (Reliability): Будьте готовы ко всему

1. Репликация данных: Для обеспечения надежности критически важные данные должны быть реплицированы. В Kafka это достигается за счет репликации партиций между брокерами. Определите `replication factor` (фактор репликации) в зависимости от критичности данных (обычно 3).
2. Диспетчер сбоев (Disaster Recovery):
   • Внутрикластерная отказоустойчивость: Лог-система должна быть способна выдержать отказ отдельных узлов или зон доступности (Availability Zones) без потери данных.
   • Географическая репликация: Для защиты от сбоев целых дата-центров используйте мульти-кластерные развертывания с гео-репликацией (например, MirrorMaker2 для Kafka).
3. Idempotence Producers: Убедитесь, что продюсеры могут повторно отправлять сообщения при сбоях без создания дубликатов, достигая `at-least-once` или `exactly-once` семантики.
4. At-least-once, At-most-once, Exactly-once Semantics: Понимайте и выбирайте подходящую семантику доставки сообщений для каждого пайплайна. `Exactly-once` сложнее всего, но обеспечивает максимальную точность.

Операционная Эффективность (Operational Efficiency): Не замедляйтесь

1. Партиционирование: Правильное партиционирование топиков критически важно.
   • Должно быть достаточно партиций для параллельной обработки.
   • Ключи партиционирования должны распределять нагрузку равномерно.
   • Ошибка: Недостаточное количество партиций может привести к узким местам. Слишком много партиций усложняет управление и увеличивает нагрузку на брокеры.
2. Батчинг (Batching): Соединяйте мелкие записи в большие “пакеты” перед отправкой в лог. Это значительно уменьшает накладные расходы на I/O и сетевые операции.
3. Zero-Copy: Используйте механизмы, позволяющие передавать данные из лога напрямую в сетевой сокет, минуя буферы приложения для копирования. Это снижает нагрузку на CPU.
4. Мониторинг: Ключ к здоровой системе.
   • Метрики брокеров: CPU, память, диск I/O, сетевой трафик, количество сообщений, пропускная способность.
   • Метрики топиков: Размер, количество партиций, скорость записи/чтения.
   • Метрики потребителей: Consumer Lag (отставание потребителей) — это самая важная метрика. Если `consumer lag` растет, значит, потребитель не справляется с нагрузкой, и данные накапливаются.
   • Алерты: Настройте оповещения на критические метрики (высокий `consumer lag`, ошибки записи/чтения, недоступность брокеров).
5. Логирование и Трассировка: Стандартизируйте форматы логов приложений, отправляющих и потребляющих данные из лога. Включите корреляционные ID (`trace_id`, `span_id`) для отслеживания событий через всю распределенную систему (например, с помощью OpenTelemetry).
6. Управление ресурсами: Убедитесь, что у брокеров лога достаточно ресурсов (CPU, RAM, диск I/O) для обработки пиковых нагрузок. Используйте быстрые диски (SSD/NVMe).

Дополнение (2023-2024): Chaos Engineering

• Для проверки устойчивости вашей лог-инфраструктуры к сбоям, регулярно проводите эксперименты в контролируемой среде.
• Примеры**: Имитация отказа брокера (убиваем процесс), сетевые проблемы (Partition), перегрузка диска, увеличение задержки для потребителя. Это помогает выявлять слабые места *до* того, как они проявятся в продакшене.

---

Заключение: пошаговый план к Data-Driven Будущему

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

Краткие выводы:

• Лог — это источник истины: Он хранит историю изменений в гарантированном порядке.
• Лог упрощает: Он решает проблемы интеграции (N² → N), репликации и восстановления.
• Лог масштабирует: Благодаря партиционированию и оптимизациям, таким как батчинг и zero-copy.
• Лог — это кровь в организме данных: Без него невозможно построить гибкую, реактивную и отказоустойчивую архитектуру.
• Kappa лучше Lambda: Одна кодовая база для realtime и batch обработки.

Ваш пошаговый план к Data-Driven Архитектуре, управляемой логами:

1. Начните с аудита источников данных:
   • Определите, какие данные генерируются вашими системами, какие из них критически важны, какие меняются со временем.
   • Поймите, где находятся “узкие места” в текущей интеграции.

2. Выберите платформу логов:
   • Выбор: Apache Kafka — это де-факто стандарт. Рассмотрите Apache Pulsar как альтернативу, если вам нужна расширенная гибкость.
   • Развертывание: Для начала можно использовать управляемые облачные сервисы (Confluent Cloud, AWS MSK, Azure Event Hubs) или самостоятельно развернуть Kafka в Kubernetes с помощью операторов. Не пытайтесь строить свой велосипед.

3. Внедрите Schema Registry:
   • Это не опция, а обязательное условие.
   • Соберите команды, которые генерируют данные, и начните совместно разрабатывать строгие схемы для каждого типа событий (Avro/Protobuf).
   • *Рекомендация*: Внедрите процесс `data contract` – соглашения между командами о формате и семантике данных.

4. Инструментируйте ключевые сервисы для публикации в лог:
   • Начните с одного или двух высоконагруженных сервисов.
   • Используйте Change Data Capture (CDC) (например, Debezium) для выгрузки изменений из баз данных в лог.
   • Для новых сервисов и пользовательских действий изначально проектируйте их как Event Sourcing-системы, публикующие события в лог.

5. Настройте базовых потребителей и хранилища:
   • Автоматизируйте загрузку данных из лога в ваше основное аналитическое хранилище (Data Warehouse, Data Lake, например, S3/HDFS + Spark/Hive).
   • Подключите первый “реальный” потребитель, например, систему мониторинга, которая отслеживает ключевые показатели бизнеса на основе событий из лога.

6. Разверните платформу потоковой обработки:
   • Начните с Apache Flink или Kafka Streams. Они позволят вам обрабатывать данные из лога, обогащать их, агрегировать и создавать новые, производные потоки данных.
   • *Рекомендация*: Сначала решайте простые задачи (агрегаты, фильтрация), затем переходите к более сложным (stateful processing, windowing).

7. Сосредоточьтесь на Observability и Автоматизации:
   • Внедрите комплексный мониторинг всей лог-инфраструктуры (брокеры, топики, потребители) с ключевыми метриками (consumer lag!).
   • Настройте алерты.
   • Автоматизируйте процессы развертывания, масштабирования и восстановления лог-компонентов.

8. Имплементируйте принципы безопасности:
   • Шифрование, аутентификация, авторизация. Пусть это будет часть каждого нового внедрения.

9. Готовьтесь к репроцессингу:
   • Убедитесь, что ваши логи хранят достаточно истории (длительный retention).
   • Проектируйте свои потоковые приложения с учетом возможности запуска нового экземпляра для пересчета исторических данных.

10. Примите философию Data Mesh:
    • Меняйте культуру: поощряйте команды владеть своими данными как продуктами.

---

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

https://openai.com/open-models/

Для большой модели надо h100, а маленькая попроще и требует всего 16gb.

Ну и главное: удаляем сразу, если заметим, что клянчит деньги и просит купить меня :)

А вот квенчик красавчик: ai molodca)

но он знал ))

почти

trinking...

...
But the trick is that when "А" fell, it becomes "а" (lowercase?), but maybe not. Wait, another angle: in Russian, the phrase "А упала" could be a pun. Because "упала" means fell, but "а" is also the word for "and" in some contexts, but here it's the letter. Wait, maybe the answer is that only the "и" (which means "and") is left? Because the sentence is "А и Б сидели на трубе": A and B were sitting on the pipe. So the letters A, the word "и" (and), and B. So if A fell and B disappeared, then the "и" is left. Because the "и" is part of the phrase. Wait, that's a common riddle. Let me confirm.
...

Недавняя статья компании YADRO на Хабре, “Где живут LLM”, стала редким и ценным окном в реальную практику построения корпоративного инференс-кластера. Команда не только поделилась своей архитектурой, но и честно рассказала о проблемах, что делает их опыт вдвойне полезным. Спасибо им за это!

 🚀🚀🚀 https://habr.com/ru/companies/yadro/articles/930304/

Их кейс можно брать за основу, давайте разберем его и проведем небольшой анализ стека для работы с LLM — от низкоуровневых движков на GPU до low-code платформ для конечных пользователей. Этот разбор покажет, почему определенные технологические решения становятся стандартом и что необходимо для построения не просто работающей, а по-настоящему эффективной и масштабируемой AI-экосистемы.

Фундамент: Архитектура инференс-кластера

В основе кластера YADRO лежат проверенные и мощные компоненты, ставшие индустриальным стандартом:

• Оборудование: Серверы с NVIDIA H100.
• Оркестрация: Kubernetes.
• Движок инференса: vLLM.

Ключевым и очень показательным решением стал выбор vLLM вместо, казалось бы, более нативного для NVIDIA Triton Inference Server. Аргументация YADRO проста и прагматична: с vLLM «намного проще добавлять новые модели», и он «изначально предоставляет OpenAI-совместимые REST API».

Это идеально отражает главный тренд в LLM Serving. Triton — это универсальная рабочая лошадка, мощная, но требующая серьезной подготовки: конвертации моделей в форматы вроде TensorRT и часто создания дополнительной «обвязки» для предоставления удобного API. vLLM, напротив, это специализированный инструмент, заточенный именно под LLM. Благодаря своей ключевой инновации — PagedAttention, которая кардинально оптимизирует управление памятью для KV-кэша, — он обеспечивает высочайшую пропускную способность и простоту использования «из коробки».

Средний слой: Production-ready операции и масштабирование

Переход от тестов к эксплуатации всегда вскрывает «узкие места». Опыт YADRO — прекрасное тому подтверждение.

1. Проблема шлюза (Gateway): Команда обнаружила, что популярный прокси LiteLLM, хотя и удобен для старта, становится узким местом при нагрузке выше 50 одновременных запросов. Их решение — разработка собственного `LLM Gateway` на Go — является абсолютно верным шагом для высоконагруженных систем. Такой шлюз берет на себя аутентификацию, логирование, rate-limiting и, что самое главное, умную маршрутизацию запросов. Для тех, кто не готов к собственной разработке, в экосистеме появляются готовые решения, такие как vllm-router, специально созданные для балансировки нагрузки между фермами vLLM-инстансов. https://docs.vllm.ai/en/stable/deployment/integrations/production-stack.html

2. Продвинутое масштабирование в Kubernetes: В статье упоминается горизонтальное автомасштабирование (HPA) по CPU. Для GPU-сервисов это неэффективно. Современный подход требует более точных триггеров:
   • Масштабирование по GPU:** Использование `DCGM Exporter` от NVIDIA для сбора метрик утилизации GPU и настройка HPA или KEDA (Kubernetes Event-driven Autoscaling) по этим данным.
   • Масштабирование по очереди:** vLLM предоставляет метрику `vllm_requests_waiting` (количество запросов в очереди). Это лучший показатель реальной нагрузки: как только очередь растет, система добавляет новые поды с моделями.

3. Мониторинг (Production Metrics): Для стабильной работы 24/7 критически важно отслеживать специфичные метрики vLLM в реальном времени через Prometheus и Grafana:
   • Производительность:** Time to First Token (TTFT) и Time per Output Token (TPOT).
   • Нагрузка:** `vllm_requests_running` (в обработке) и `vllm_requests_waiting` (в очереди).
   • Состояние памяти:** `vllm_gpu_cache_usage_perc` (процент использования KV-кэша). Рост этой метрики — прямой предвестник ошибки нехватки памяти (OOM).

Верхний уровень: Платформы и интерфейсы для пользователей

Самый мощный бэкенд бесполезен без удобного доступа. YADRO упоминают, что предоставили пользователям интерфейсы через Dify и собственный WebUI, что выводит нас на уровень приложений и пользовательского опыта.

• Dify: Low-code платформа для создания AI-приложений. Dify — это не просто чат, а открытая LLM Ops платформа, позволяющая быстро создавать и развертывать AI-приложения. С помощью визуального конструктора даже нетехнические специалисты могут собирать сложные воркфлоу, включая чат-ботов, RAG-системы (поиск по базам знаний) и AI-агентов. Dify подключается к инференс-кластеру по OpenAI API и служит мостом между мощным бэкендом и конечными бизнес-задачами.

• Open WebUI: Персональный и безопасный доступ к моделям. Если Dify — это конструктор приложений, то Open WebUI — это универсальный и безопасный «кабинет» для прямого взаимодействия с моделями. Как отмечается в документации, это «расширяемая, многофункциональная и удобная платформа для самостоятельного хостинга, предназначенная для работы полностью в автономном режиме» docs.vllm.ai). Open WebUI предоставляет привычный интерфейс в стиле ChatGPT, но с расширенными возможностями: работа с локальными документами (RAG), веб-браузинг в чатах и управление доступом для команд — всё это в защищенном контуре компании https://www.repocloud.io/details/?app_id=271.

Инструменты для разработчиков: Интеграция в рабочий процесс

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

• Continue.dev: Open-source расширение для VS Code/JetBrains, которое превращает внутренний инференс-кластер в полноценного AI-ассистента, работающего прямо в IDE.
• OpenAI SDK и LiteLLM: Использование этих библиотек на стороне клиентских приложений — золотой стандарт. Они позволяют разработчикам абстрагироваться от деталей реализации бэкенда и работать с унифицированным, удобным API.

Кстати у litellm.ai есть демка их прокси сервера заходим Username: admin Password: sk-1234
https://demo.litellm.ai/ui

Итоги и выводы

Опыт YADRO — это отличный срез современной инженерной практики в области LLM. Его комплексный анализ позволяет сформировать полную картину production-ready AI-экосистемы, которая состоит из нескольких ключевых слоев:

1. Бэкенд: Специализированные движки (vLLM) на Kubernetes стали де-факто стандартом для высокопроизводительного инференса.
2. API и Ops: OpenAI-совместимый API — это универсальный «язык» для всех компонентов системы. Для масштабирования необходим кастомный Gateway/Router (как у YADRO) и продвинутое автомасштабирование по метрикам GPU и длине очереди.
3. Приложения и GUI: Low-code платформы (Dify) позволяют быстро создавать бизнес-решения, а интерфейсы вроде Open WebUI или LibreChat предоставляют сотрудникам безопасный и многофункциональный доступ к моделям.
4. DevX (Developer Experience): Интеграция в IDE (Continue.dev) и использование стандартизированных SDK делают LLM по-настоящему удобным инструментом для разработчиков.

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

Ссылки Основная: https://habr.com/ru/companies/yadro/articles/930304/

• https://docs.vllm.ai/en/latest/deployment/frameworks/open-webui.html
• https://www.repocloud.io/details/?app_id=271
• https://docs.digitalocean.com/products/marketplace/catalog/open-webui/
• https://www.pondhouse-data.com/blog/integrating-n8n-with-open-webui
• https://www.requesty.ai/blog/openwebui-vs-librechat-which-self-hosted-chatgpt-ui-is-right-for-you
• LibreChat

Оригинал тут: RAW Hollow – революция в управлении данными от Netflix

Или тут 👉 https://hollow.how/raw-hollow-sigmod.pdf

Пояснения для тех, кто не знаком с темой

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

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

• Распределенные системы: Это означает, что Netflix не использует один огромный компьютер. Вместо этого у них тысячи маленьких компьютеров (серверов), расположенных в разных точках мира, которые работают вместе, чтобы обеспечить бесперебойный сервис.
• In-Memory: “В памяти” означает, что данные хранятся прямо в оперативной памяти сервера (как в вашем компьютере, когда вы запускаете программы), а не на медленном жестком диске. Это делает доступ к данным невероятно быстрым.
• Co-Located: “Совместно размещенный” означает, что данные хранятся на том же самом сервере, где работает программа, которой эти данные нужны. Не нужно отправлять запрос по сети на другой сервер, чтобы получить данные, что экономит время.
• Object Store: Это не традиционная реляционная база данных с таблицами. Вместо этого данные хранятся как объекты (подобно файлам или записям), что более гибко.
• Hollow (оригинальный): Это была технология Netflix для очень быстрого чтения данных. Она позволяла хранить целые каталоги данных в памяти для моментального доступа, но не позволяла изменять эти данные. Представьте, что это очень быстрая, но только для чтения, копия огромной книги.
• RAW Hollow (Read After Write Hollow): Это развитие Hollow. Теперь можно не только читать, но и записывать данные, сохраняя при этом молниеносную скорость. Добавлена возможность изменять “книгу”, причем изменения мгновенно становятся видны другим, а система гарантирует, что данные не потеряются.
• CAP Theorem: Это фундаментальная концепция в распределенных системах. Она утверждает, что из трех свойств – согласованность (Consistency), доступность (Availability), устойчивость к разделению (Partition tolerance) – можно одновременно гарантировать только два. Netflix же, благодаря RAW Hollow, предлагает гибкость в выборе: можно работать в режиме максимальной доступности (AP), где данные становятся согласованными со временем, или в режиме максимальной согласованности (CP), где данные всегда актуальны, но могут быть короткие задержки.

Важное в статье

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

2. Эволюция от Hollow: RAW Hollow является развитием уже зарекомендовавшей себя технологии Hollow, которая использовалась Netflix более 10 лет как кеш *только для чтения*. Новая версия добавляет возможность записи и гарантии атомарности и согласованности.

3. Архитектура RAW Hollow:
   • Writers (Записывающие): Точка входа для всех операций записи. Используют Zookeeper для выбора лидера и синхронную репликацию для обеспечения долговечности данных. Способны обрабатывать до 1000 записей в секунду с нагрузкой 10 КБ.
   • Logkeepers (Хранители логов): Простая, но надежная инфраструктура для долговечности. В памяти хранят циклический лог, обеспечивая быструю фиксацию записей. Высокая отказоустойчивость за счет развертывания в нескольких зонах доступности AWS.
   • Producers (Производители): Синхронизируют данные из Logkeepers и распространяют их через внутренний паб/саб сервис Netflix (Gutenberg) на Writers и Local Clients. Создают снимки данных каждые 30 секунд для долгосрочного хранения в S3, что обеспечивает надежность на уровне “11 девяток”.
   • Local Clients (Локальные клиенты): Самая уникальная особенность. Каждое приложение-клиент поддерживает полную, материализованную копию всего набора данных в своей памяти. Это позволяет осуществлять операции чтения без сетевых задержек (микросекунды). Получают обновления в реальном времени от Logkeepers.

4. Свойства ACID и согласованность:
   • Атомарность: Гарантируется через API Bulk Update, где все операции в транзакции либо выполняются полностью, либо не выполняются вовсе.
   • Согласованность: Поддерживается за счет всесторонней валидации схемы. API Conditional Bulk Update позволяет применять предварительные условия для предотвращения состояний гонки.
   • Изоляция: Реализован уровень Read Committed, предотвращающий “грязные” чтения.
   • Долговечность: Обеспечивается синхронной репликацией на Logkeepers и регулярными снимками в S3.

5. Гибкость модели согласованности (CAP Theorem):
   • Eventually Consistent (AP-система по умолчанию): Приоритет доступности и отказоустойчивости. Чтения мгновенны, обновления распространяются быстро, но временные несоответствия могут быть (идеально для рекомендаций).
   • Strong Consistency (CP-система по запросу): Позволяет запрашивать сильную согласованность для отдельных операций. Клиент временно синхронизируется с последними изменениями. Это позволяет достичь баланса между производительностью и точностью данных для критически важных операций (например, финансовые транзакции).

6. Производительность и масштабируемость:
   • Чтение: Микросекунды, так как данные “co-located”.
   • Запись: До 1000 записей/сек (10 КБ полезной нагрузки), задержка распространения обновлений — миллисекунды.
   • Масштаб данных: До 100 миллионов записей на сущность, благодаря эффективному сжатию.

7. Применение в реальном мире: RAW Hollow уже активно используется в более чем 160 критически важных сервисах Netflix (Tier-0), включая:
   • Управление метаданными видео (каталоги контента).
   • Системы рекомендаций и персонализации.
   • Управление сетевой инфраструктурой CDN (Open Connect).
   • Управление идентификацией и доступом (OneID).
   • Потенциал для игр, финансовых услуг (рыночные данные, борьба с мошенничеством), электронной коммерции.

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

---

Вывод ИИ

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

---

Шаги по применению (для внедрения аналогичного подхода)

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

1. Анализ требований и выявление “боли”:
   • Определите, какие ваши сервисы страдают от высокой задержки чтения, непредсказуемой производительности баз данных или сложностей с синхронизацией кэшей.
   • Оцените, укладываются ли ваши наборы данных в категории “малые” или “средние” (помещаются ли в оперативную память). Слишком большие dataset’ы не подходят для RAW Hollow-подобных решений.

2. Исследование существующих решений:
   • Прежде чем разрабатывать что-то свое, изучите готовые ин-мемори базы данных (Redis, Apache Ignite, GemFire/Pivotal CloudFoundry Data Services) и распределенные кэши. Hollow/RAW Hollow — это более низкоуровневое и кастомизированное решение.
   • Оцените возможность использования Apache Kafka или подобных систем для потоковой обработки изменений, как это делает Netflix.

3. Проектирование архитектуры:
   • Модель данных: Разработайте оптимальную схему данных, которая будет эффективно храниться в памяти и обеспечивать быстрый доступ. Учитывайте возможности сжатия и индексирования.
   • Модель согласованности: Для каждого компонента или операции четко определите требуемый уровень согласованности (сильная или конечная). Это критический шаг.
   • Компоненты: Определите необходимые компоненты, аналогичные Writers, Logkeepers, Producers и Local Clients.
     • Writers: Как будут приниматься и обрабатываться запросы на запись? Нужен ли механизм выбора лидера?
     • Durability Layer: Как будет обеспечиваться долговечность данных? Локальные логи? Репликация? Архивация в S3-подобные хранилища?
     • Change Propagation: Как изменения будут распространяться между узлами и клиентами? Нужен эффективный механизм паб/саб.
     • Local Data Stores: Как данные будут храниться в памяти клиентов/сервисов? Как будут обновляться?
   • Отказоустойчивость: Разработайте механизмы для обработки сбоев отдельных компонентов (например, падение Writer, Logkeeper), восстановления после сбоев и обеспечения непрерывной работы.

4. Выбор технологий и инструментов:
   • Для координации: Zookeeper или Consul для выбора лидера и управления распределенным состоянием.
   • Для потоковой обработки/паб/саб: Kafka, Pulsar или Kinesis.
   • Для хранения снимков: S3-совместимые хранилища.
   • Для in-memory хранения: Возможно, придется использовать кастомные структуры данных или библиотеки для работы с памятью в выбранном языке программирования (например, Java ByteBuffer для эффективного управления памятью).

5. Разработка и реализация PoC (Proof of Concept):
   • Начните с небольшой, изолированной PoC, чтобы проверить ключевые концепции: co-located storage, запись, распространение изменений, согласованность.
   • Измерьте производительность и задержку на ранних этапах.

6. Тестирование и оптимизация:
   • Нагрузочное тестирование: Проверьте систему под высокой нагрузкой чтения и записи.
   • Chaos Engineering: Внедряйте контролируемые сбои (как Netflix с Chaos Monkey), чтобы убедиться в устойчивости системы.
   • Мониторинг: Встройте комплексные системы мониторинга и логирования для отслеживания состояния, производительности и проблемных мест во всех компонентах.

7. Развертывание и эксплуатация:
   • Постепенное развертывание в производственной среде, начиная с менее критичных сервисов.
   • Обеспечение операционных процедур: обновление, резервное копирование, восстановление, масштабирование.

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

Оригинал тут: British Airways: Кошмар на Новоселье

Статья Евгения Кагановича, управляющего партнера APT Group, “British Airways: Кошмар на Новоселье” детально описывает катастрофическое открытие Терминала 5 (Т5) аэропорта Хитроу 28 марта 2008 года. Этот инцидент, получивший широкую огласку и вызвавший парламентские слушания, стал ярким примером того, как даже самый тщательный планирование и миллиардные инвестиции могут обернуться провалом из-за целого комплекса взаимосвязанных проблем. История Т5 и British Airways (BA) является поучительным кейсом для любого масштабного проекта, подчеркивая важность комплексного тестирования, управления персоналом, интеграции систем и готовности к непредвиденным обстоятельствам.

Структура и Основные Моменты

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

Глава 1: Не пятница, но тринадцатое

• Предпосылки открытия Т5: ** Хитроу был перегружен, неэффективен, и Багаж часто терялся или задерживался, что делало Амстердам предпочтительным транзитным хабом для многих британцев. British Airways работали из трех разных терминалов, что создавало логистические трудности.
• Ожидания от Т5: ** Терминал 5, стоивший 4,3 миллиарда фунтов (около 8 миллиардов долларов по тогдашнему курсу), был призван стать шедевром, флагманским хабом для British Airways, объединяющим их операции под одной крышей с современной инфраструктурой и высокотехнологичной багажной системой.
• Факты: ** Строительство длилось 17 лет, а его открытие сопровождалось визитом королевы Елизаветы II. Пропускная способность багажной системы – 12 000 сумок в час.

Глава 2: Не тринадцатое, но пятница

• Торжественное открытие: ** 14 марта 2008 года королева Елизавета II официально открыла Т5. Терминал поражал масштабом (самая большая однопролетная крыша в Европе), технологиями (беспилотные поезда, такси, новая станция метро, ветки Heathrow Express и Crossrail) и роскошью (филиал Harrods, ресторан Гордона Рамзи, Galleries для бизнес-класса).
• Подготовка к переезду: ** Беспрецедентный объем работ по координации переезда British Airways и еще 45 авиакомпаний, включая изменение навигации, информирование пассажиров и персонала.
• Тестовая эксплуатация: ** Проводились семимесячные тесты с участием 15 тысяч человек.

Глава 3: Ночь перед торжеством

• Переезд BA: ** Активный перенос оборудования и багажа из Т1 в Т5.
• Сложность Хитроу: ** Автор подчеркивает, что Хитроу – это уникальный аэропорт с ритмом “кардиограммы курильщика”, работающий не круглосуточно, но с интенсивными волнами прибытий и отбытий, требующий слаженной работы.
• Проблемы накануне: ** Несмотря на тесты, в предпоследний день произошел инцидент с пассажиром на ВПП, что добавило нервозности.

Хитроу

Глава 4: Неидеальный шторм

• День открытия (28 марта 2008): ** Первый рейс прибыл успешно, но затем начался хаос. [bbc.co.uk](http://news.bbc.co.uk/2/hi/uk_news/7319679.stm)
  • Багажный коллапс: ** Багажная система вышла из строя – чемоданы не появлялись, появлялись беспорядочно, ленты блокировались. 8000 чемоданов оказались утерянными.
  • Проблемы с персоналом: ** Сотни сотрудников не смогли попасть на свои рабочие места из-за неработающих пропусков и систем авторизации. [bbc.co.uk](http://news.bbc.co.uk/2/hi/uk_news/7322453.stm)
  • Отмена рейсов: ** Было отменено 68 рейсов, а затем и другие.
  • Коллапс коммуникации: ** Сайты BA и Хитроу рухнули, колл-центры были перегружены.
  • “Эвакуация флота”: ** Чтобы избежать полного коллапса, Вилли Уолш, гендиректор BA, приказал самолетам вылетать пустыми или без багажа, чтобы освободить перроны.
  • Причины коллапса (по версии статьи): **
    1. Халатность в управлении персоналом: неработающие пропуска (проблема BAA), отсутствие инструкций. 235 тысяч пропусков нуждались в перерегистрации.
    2. Сбой RMS (Resource Management System): портативные компьютеры для управления персоналом не использовались или были не понятны грузчикам.
    3. Проблема с передачей данных между старой (IBM) и новой (Vanderlande) багажными системами. Старая система не передавала временный идентификатор сумки в новую.

Глава 5: Пони бегает по кругу

• Второй день: ** Несмотря на подготовку персонала, проблемы продолжились. Багажная система отказывалась принимать чемоданы к регистрации из-за сбоев в распознавании меток, особенно транзитных сумок. Тысячи сумок были сброшены во двор.
• Хаос и критика: ** Отсутствие контроля над ручной кладью, драки, переполненные и грязные туалеты, магазины без покупателей.
• Проблема №1: RFID: ** Газеты ошибочно предположили, что проблема в штрих-кодах и предложили использовать RFID-метки, не понимая масштаба задачи.

Глава 6: Надежда не умирает никогда

• Продолжение хаоса: ** Т5 превратился в лагерь беженцев. Количество утерянных сумок достигло 28 000. [bbc.co.uk](http://news.bbc.co.uk/2/hi/uk_news/7323198.stm)
• Политический скандал: ** Инцидент привлек внимание премьер-министра и королевы, нанеся ущерб репутации страны.
• Суть проблемы: ** Проблема заключалась в том, что старая система IBM не передавала временный идентификатор транзитных сумок в новую систему Vanderlande.
• Решение: ** После экстренного совещания с участием BAA и IBM была обеспечена передача идентификаторов.

Глава 7: Что делать, когда никто не виноват

• Возобновление работы: ** На шестой день багажная система заработала полноценно.
• Новый сбой: “reconciliation”: ** Система остановилась из-за правила “reconciliation” – на борту не может быть багажа пассажира, не присутствующего на рейсе. Из-за ошибок в перезагрузке системы после временного отключения этой функции логистическая система ошибочно заблокировала отправление багажа.
• Финальное решение: ** Перезагрузка сервера с правильными настройками, и система начала работать без сбоев.
• Судьба потерянного багажа: ** 23 205 потерянных сумок были перебраны вручную. Груз для Европы отправлен в Милан, для США – в хаб FedEx в Мемфисе. Процесс репатриации занял 5 недель, 400 сумок так и не были найдены.

Выводы

1. Кумулятивный эффект: Проблемы, по отдельности преодолимые, при их совпадении и масштабе проекта привели к катастрофическим последствиям. Открытие Т5 продемонстрировало, что высокотехнологичные системы требуют безупречной интеграции не только с технической, но и с человеческой составляющей.
2. Важность человеческого фактора: Оказалось, что даже самая совершенная система бесполезна, если персонал не обучен, не может авторизоваться или не понимает, как работать с ней. Проблемы с пропусками и RMS стали катализатором коллапса на старте.
3. Недооценка интеграции: Ключевой технической причиной стал сбой в передаче данных между старой и новой багажными системами. Это показывает, что даже при проектировании новой системы нельзя игнорировать ее совместимость с существующей инфраструктурой.
4. Стойкость и лидерство: Несмотря на огромный провал, British Airways и аэропорт Хитроу под руководством Вилли Уолша смогли быстро выявить и устранить критические проблемы. Уолш, который не только сохранил свой пост, но и достиг выдающихся успехов, стал примером эффективного кризисного менеджмента.
5. Наследие Т5: Несмотря на катастрофическое открытие, Терминал 5 получил награду “Лучший терминал мира” Skytrax с 2011 по 2016 год, что свидетельствует о его высочайшем качестве после устранения первоначальных проблем.

Заключение ИИ

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

Интересные цитаты

• “Если бы речь шла о кинематографе, то нужно было бы вообразить, что бы случилось, если б Стивен Спилберг, Леонардо ди Каприо и Джордж Клуни уговорили британскую корону вложить в их фильм 8 миллиардов долларов по тогдашнему курсу, заставили бы монарха лично презентовать премьеру, а при этом съемки продлились бы 17 лет, на премьере случился обрыв пленки, а фильм провалился в прокате, на фестивалях и в прессе.”
• “Это было равносильно переселению во дворец из коммунальной квартиры.”
• “Аэропорт был ареной непрерывной битвы.”
• “Жизнь Хитроу – это кардиограмма курильщика. Она идет идет неровными волнами.”
• “Пассажиры… быстро прошли иммиграционный контроль и моментально получили свой багаж... На выходе из багажного зала они щедро делились своим восторгом с многочисленными журналистами. На часах было около 5.30. К этому времени из Гонконга прибыл рейс ВА28, пассажиры которого тоже быстро прошли иммиграционный контроль и спустились в зал выдачи багажа... На подходе был следующий рейс из Гонконга, но багаж с рейса 28 не появился на багажной ленте, а сам рейс даже не фигурировал на табло зала выдачи багажа.”
• “Сюжет с отсутствием персонала на рабочих местах дьявольски напоминал рекламный ролик самой British Airways. Where is everybody?”
• “Хаос перекинулся на другие терминалы...”
• “Десятки самолетов взмывали в небо пустыми с обеих взлетных полос – без багажа и, в основном, без пассажиров, тысячами остававшихся в переполненном терминале.”
• “Ирландский парень Вилли Уолш сказал исторические слова: «The buck stops here». Что нужно понимать как «теперь все вопросы – ко мне».”
• “Человечество уже стояло на пороге получения точного ответа на важнейший вопрос: что лучше – ужасный конец или бесконечный ужас...”
• “И все заработало как надо. Тогда шкаф с серверами заперли на новый ключ, ключ закопали, лопату сломали. И больше к этому вопросу не возвращались. Никогда!”
• “Кретинизм и масштабность самого явления потрясали и сотрясали.”
• “Если подобный вопрос, возникший в Гонконге, в условиях пустого терминала решался два года, то в работающем Хитроу был решен за 11 дней.” ( про масштаб проекта создали непредсказуемый кумулятивный эффект проблем)