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

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

Представьте, что 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 дней.” ( про масштаб проекта создали непредсказуемый кумулятивный эффект проблем)

И так, возникла идея проверить разные каталоги в Trino, более того при разных условиях. Ну и сделать это я сам не смогу, надо сравнивать разные результаты вместе.
А в эпоху ИИ писать самому лень, ну и вряд ли я бы решился на такую авантюру. А вот ИИ печатает быстро и не устает. Короче скрипт писал ИИ. Весь до единой буквы и отчет тоже он готовил. А вот сколько попыток было этого от него добиться я не скажу, где-то на 10 баксов. За три итерации теста выполнено 9300 запросов, не все успешны, но это уже другой вопрос.

Вот итоги:

Все подробности на гите есть и результаты.

https://github.com/YuriyGavrilov/TrinoBench/blob/main/results/Analysis_of_Compression_Algorithm_Performance_Tests_in_Trino.pdf

Экселька тут: https://github.com/YuriyGavrilov/TrinoBench/blob/main/results/test_results_raw_1-2-3_pivot.xlsx

Ссылка на гит: https://github.com/YuriyGavrilov/TrinoBench.git

Iceberg, как табличный формат, совершил революцию в управлении данными в озерах данных (data lakes), предоставив транзакционные гарантии и схематическую эволюцию для данных, хранящихся в файлах. В контексте Trino, мощного распределенного SQL-движка, Iceberg раскрывает свой потенциал, позволяя пользователям взаимодействовать с данными в озерах как с традиционными базами данных. Эта статья углубится в различные варианты хранения, сжатия и конфигурации Iceberg в Trino, рассматривая преимущества и недостатки каждого, и поможет вам сделать осознанный выбор для достижения оптимальной производительности и минимизации затрат.

Автор: Gemini Flash. 2.5

1. Форматы Хранения (File Formats)

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

a) Parquet

• Описание:** Колоночный формат хранения данных, оптимизированный для аналитических запросов. Он хранит данные в колоночной ориентации, что позволяет Trino считывать только необходимые колонки во время выполнения запросов. Parquet тесно интегрирован с концепциями Iceberg, такими как использование идентификаторов полей (Field IDs) для поддержки надежной схемы эволюции.
• Преимущества:**
  • Высокая производительность в аналитике: За счет колоночного хранения и возможности Trino применять “push-down” предикатов, Parquet обеспечивает беспрецедентную скорость для большинства аналитических запросов, избирательно считывая только необходимые данные.
  • Эффективное сжатие: Колоночная ориентация позволяет применять различные алгоритмы сжатия, оптимизированные для типов данных в каждой колонке, существенно снижая объем хранимых данных и, как следствие, затраты на хранение.
  • Нативная поддержка схемы эволюции Iceberg: Iceberg использует Field IDs, которые записываются в метаданды Parquet. Это ключевой механизм, позволяющий Iceberg поддерживать эволюцию схемы (добавление, удаление, переименование колонок) без перезаписи данных и без нарушения целостности запросов.
  • Широкая поддержка и зрелость: Parquet является фактическим стандартом для хранения аналитических данных в экосистеме больших данных и поддерживается всеми основными инструментами (Spark, Hive, Dremio, Athena, BigQuery, Snowflake и т.д.), обеспечивая отличную интероперабельность.
• Недостатки:**
  • Неэффективен для точечных запросов (point lookups): Для выборки одной или нескольких записей требуется считывать данные из нескольких колонок, что может быть менее эффективно, чем строковые форматы данных.
  • Сложность изменения данных: Изменение отдельных записей требует перезаписи целых файлов или их частей, что является общей чертой для колоночных форматов.

• Использование: **Parquet – это формат по умолчанию и наиболее рекомендуемый выбор для таблиц Iceberg в Trino. Он обеспечивает наилучший баланс производительности, эффективности хранения и простоты управления для большинства аналитических рабочих нагрузок.

b) ORC (Optimized Row Columnar)

• Описание:** Ещё один колоночный формат, разработанный специально для Apache Hive. Он имеет много сходств с Parquet, включая колоночное хранение и эффективное сжатие. Документация Iceberg подтверждает, что ORC также может хранить необходимые метаданные (например, `iceberg.id`, `iceberg.required`) в атрибутах типов ORC для поддержки схемы эволюции.
• Преимущества:**
  • Высокая производительность и эффективное сжатие: Аналогично Parquet, ORC обеспечивает отличную производительность для аналитических запросов и эффективное сжатие.
  • Расширенное индексирование: ORC часто содержит более гранулированные встроенные индексы (например, индексы позиций, Bloom-фильтры), которые могут быть полезны для некоторых специфических типов запросов.

Но Bloom-фильтры по умолчанию отключены в Trino вроде как, надо проверять этот конфиг:

• Совместимость со схемой эволюции Iceberg: Iceberg способен адаптировать ORC-схему (даже путем изменения имен колонок) для своей ID-основанной эволюции, что делает его совместимым.
• Недостатки:**
• Неэффективен для точечных запросов: Общий недостаток для всех колоночных форматов.
• Менее распространен как универсальный формат вне экосистемы Hive: Хотя ORC является основным форматом для Hive, Iceberg чаще ассоциируется с Parquet как универсальным форматом хранения для Data Lake. Это может потенциально означать меньшую поддержку или оптимизацию в некоторых не-Hive инструментах.
• Специфические моменты с отображением типов: Как видно из Iceberg documentation, существуют нюансы с отображением типов данных (например, `timestamp` и `timestamptz`) в ORC. Может потребоваться использование дополнительных атрибутов Iceberg (таких как `iceberg.timestamp-unit`) для корректной передачи семантики.
• Отсутствие “шрединга” для типа `variant`: Документация указывает, что для ORC не поддерживается “шрединг” (оптимизированное хранение) для полуструктурированного типа `variant`, что может быть ограничением для пользователей, активно работающих с такими данными.

• Использование: Хороший выбор для аналитических рабочих нагрузок, особенно если ваша существующая инфраструктура уже использует ORC, и вы хорошо знакомы с его нюансами. Однако, для новых развертываний Iceberg, **Parquet обычно является более простым и универсальным выбором по умолчанию.

c) Avro

• Описание: Строковый формат данных, ориентированный на быструю сериализацию и десериализацию. Avro широко используется в Apache Kafka и для передачи данных между системами. Важно отметить, что Iceberg использует Avro в качестве формата **своих внутренних файлов метаданных (например, манифестов и метаданных таблиц), где его строковая природа и возможности сериализации очень полезны. Iceberg также описывает, как Avro может быть использован для файлов данных, включая строгие правила для отображения типов данных Avro и использование Field IDs для поддержки эволюции схемы.
• Преимущества:**
  • Отлично подходит для сериализации и передачи данных: Благодаря своей компактности и быстрой сериализации/десериализации, Avro идеален для потоковой передачи.
  • Встроенная схема (Schema-on-Read): Схема хранится вместе с данными, что обеспечивает совместимость. Iceberg расширяет это, добавляя Field IDs в схему Avro для robustной эволюции.
  • Поддержка эволюции схемы: Iceberg, благодаря внедрению Field IDs в схемы Avro и строгим правилам для `union` (например, использование `null` для опциональных полей), способен обеспечить эволюцию схемы даже для данных, хранящихся в Avro. Это технически возможно благодаря Iceberg.
• Недостатки:**
  • Крайне низкая производительность для аналитики: Это ключевой и самый серьезный недостаток Avro для аналитических рабочих нагрузок. Для запросов требуется считывать всю строку данных, даже если нужны только некоторые колонки. Это приводит к значительному избытку I/O, увеличивает потребность в памяти и катастрофически замедляет аналитические запросы по сравнению с колоночными форматами.
  • Неэффективное сжатие: Сжатие применяется ко всей строке, а не к отдельным колонкам. Это значительно снижает коэффициент сжатия по сравнению с Parquet или ORC, что приводит к увеличению объема хранимых данных и, соответственно, затрат.
  • Отсутствие “шрединга” для типа `variant`: Как и в ORC, Avro не поддерживает “шрединг” для полуструктурированного типа `variant`, что может ограничивать работу со сложными схемами.

• Использование: **Категорически не рекомендуется использовать Avro в качестве формата хранения данных для таблиц Iceberg, предназначенных для аналитических запросов в Trino. Несмотря на то, что Iceberg может технически поддерживать его для данных, это приведет к серьезному ухудшению производительности и увеличению затрат. Avro прекрасно подходит для файлов метаданных Iceberg и для потоковых данных, но не для аналитического хранения.

2. Алгоритмы Сжатия (Compression Algorithms)

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

a) Snappy

• Описание:** Высокоскоростной алгоритм сжатия, разработанный Google. Он оптимизирован для скорости сжатия и декомпрессии, а не для максимальной степени сжатия.
• Преимущества:**
  • Очень быстрая декомпрессия: Минимальное влияние на производительность запросов, что критично для активных аналитических систем.
  • Сбалансированное соотношение сжатия: Обеспечивает хорошее сокращение размера файла без значительных затрат CPU.
  • Широкая поддержка: Один из наиболее часто используемых алгоритмов сжатия в экосистеме big data.
• Недостатки:**
  • Менее эффективное сжатие: По сравнению с алгоритмами, ориентированными на максимальное сжатие (например, ZSTD), Snappy может занимать больше места на диске.

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

b) ZSTD

• Описание:** Алгоритм сжатия, разработанный Facebook, предлагающий значительно лучшую степень сжатия, чем Snappy, при сохранении приемлемой скорости сжатия/декомпрессии.
• Преимущества:**
  • Высокая степень сжатия: Заметно сокращает объем данных на диске, что приводит к значительной экономии затрат на хранение и уменьшению объема передаваемых данных (IO).
  • Хорошая скорость декомпрессии: Хотя и медленнее, чем Snappy, ZSTD всё ещё очень быстр, особенно по сравнению с GZIP, что делает его пригодным для аналитических нагрузок.
• Недостатки:**
  • Более высокое использование CPU: Процесс сжатия и декомпрессии требует больше ресурсов CPU, чем Snappy, что может немного увеличить нагрузку на вычислительные кластеры.

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

Trino использует кстати уровень 3 и его поменять пока нельзя :(

https://github.com/airlift/aircompressor/blob/3210eb16a5ec40089398c40f40ad1d177228b414/src/main/java/io/airlift/compress/zstd/CompressionParameters.java#L26

public static final int DEFAULT_COMPRESSION_LEVEL = 3;

c) GZIP

• Описание:** Широко распространенный и очень эффективный алгоритм сжатия.
• Преимущества:**
  • Очень высокая степень сжатия: Обеспечивает максимальное уменьшение размера файла, что идеально для архивирования.
• Недостатки:**
  • Очень медленная декомпрессия: Существенно замедляет операции чтения запросов, что делает его непригодным для интерактивной аналитики.
  • Высокое использование CPU: значительно увеличивает нагрузку на CPU при сжатии и декомпрессии.

• Использование: **Категорически не рекомендуется для активных аналитических данных в Iceberg. Его использование оправдано только для долгосрочного архивирования, где данные редко запрашиваются, а максимальное сжатие является единственным приоритетом. Для активных данных он значительно ухудшит производительность Trino.

d) LZ4

• Описание:** Еще один очень быстрый алгоритм сжатия, схожий по производительности со Snappy, но иногда предлагающий чуть лучшее сжатие.
• Преимущества:**
  • Очень высокая скорость: Схож со Snappy.
  • Хорошее соотношение сжатия.
• Недостатки:**
  • Схож со Snappy.

• Использование:** Альтернатива Snappy, если требуется очень высокая скорость и хорошее сжатие.

3. Конфигурация Iceberg в Trino

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

a) Конфигурация Каталога (Catalog Configuration)

В файле `etc/catalog/.properties` (например, `etc/catalog/iceberg.properties`) вы настраиваете, как Trino будет подключаться к Iceberg и где будут храниться метаданные таблиц.

connector.name=iceberg
iceberg.catalog.type=hive_metastore # или rest, hadoop
hive.metastore.uri=thrift://namenode:9083 # Если hive_metastore
# Для объектного хранилища (например, S3, MinIO)
iceberg.s3.endpoint-url=http://s3.local:9000 
iceberg.s3.region=us-east-1
iceberg.s3.access-key=YOUR_ACCESS_KEY
iceberg.s3.secret-key=YOUR_SECRET_KEY
iceberg.s3.path-style-access=true # Для некоторых S3-совместимых хранилищ

• `connector.name=iceberg`: Определяет, что используется коннектор Iceberg.
• `iceberg.catalog.type`: Определяет, какой бэкенд каталога Iceberg будет использоваться для хранения метаданных (схемы таблиц, версий и расположения файлов данных).
  • `hive_metastore`: Использует существующий Hive Metastore. Это самый распространенный вариант, если у вас уже есть Hive Metastore.
  • `rest`: Подключается к Iceberg REST Catalog (требует развертывания отдельного сервиса). Предоставляет более чистый API и может обеспечивать лучшую производительность для операций с каталогом.
  • `hadoop`: Использует HDFS для хранения метаданных Iceberg. Менее распространен для продакшн-развертываний.
• Параметры хранилища данных (Data Storage):** Независимо от типа каталога, фактические файлы данных Iceberg могут храниться в S3, HDFS, Google Cloud Storage, Azure Blob Storage и т.д. Вам нужно настроить соответствующие параметры в конфигурации каталога Trino для доступа к этому хранилищу (например, `iceberg.s3.endpoint-url`, `iceberg.s3.access-key` для S3).

b) Конфигурация Таблиц (Table Configuration)

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

CREATE TABLE my_iceberg_table (
    id INT,
    name VARCHAR,
    event_timestamp TIMESTAMP(6) WITH TIME ZONE,
    data_json VARCHAR -- Пример для хранения полуструктурированных данных
)
WITH (
    format = 'PARQUET', -- Формат файлов данных
    partitioning = ARRAY['WEEK(event_timestamp)', 'bucket(16, id)'], -- Стратегия партиционирования
    format_version = 2, -- Версия формата Iceberg (рекомендуется 2)
    parquet_compression = 'ZSTD', -- Алгоритм сжатия Parquet
    parquet_row_group_size = '256MB', -- Целевой размер группы строк в Parquet
    write_target_data_file_size_bytes = '536870912', -- ~512MB, Целевой размер файлов данных, записываемых Iceberg
    vacuum_max_snapshots_to_keep = 10, -- Количество последних снимков для хранения
    expire_snapshots_min_retention_ms = 86400000 -- Минимальное время удержания снимков (24 часа)
);

• `format`: Определяет формат файла данных (`’PARQUET’` или `’ORC’`). По умолчанию Iceberg использует Parquet.
• `partitioning`: Определяет стратегию партиционирования данных. Это критически важно для производительности запросов, так как Trino может пропускать целые партиции, не соответствующие условиям фильтрации. Примеры: `ARRAY[‘year(column_name)’, ‘month(column_name)’]` для временных данных, `ARRAY[‘bucket(N, column_name)’]` для равномерного распределения данных на основе хеша.
• `format_version`: Версия формата Iceberg (текущие версии 1 или 2). Рекомендуется использовать `2` для новых таблиц, так как она предлагает больше возможностей (например, поддержка удаления строк, более гибкие индексы, поддержку Positional Deletes).
• `parquet_compression`: Указывает алгоритм сжатия для Parquet файлов (`’SNAPPY’`, `’ZSTD’`, `’GZIP’`, `’LZ4’`).
• `parquet_row_group_size`: Целевой размер группы строк (row group) в Parquet файле. Рекомендуемый диапазон обычно составляет от 128MB до 512MB. Большие группы строк могут улучшить сжатие и эффективность IO, но могут замедлить запись.
• `parquet_page_size`: Размер страницы в пределах группы строк Parquet. Обычно не требует частых изменений, но может влиять на сжатие и гранулярность доступа к данным.
• `write_target_data_file_size_bytes`: Очень важный параметр. Определяет целевой размер файлов данных, которые Iceberg будет записывать. Хороший диапазон — от 128 МБ до 1 ГБ (~134217728 до 1073741824 байт). Чрезмерно маленькие файлы приводят к “проблеме маленьких файлов” (Small File Problem), что увеличивает нагрузку на метаданные и замедляет запросы. Чрезмерно большие файлы могут снизить параллелизм чтения.
• `vacuum_max_snapshots_to_keep`: Количество последних снимков таблицы, которые Iceberg должен сохранять. Важно для операций `VACUUM` и возможности откатывать таблицу к предыдущим состояниям.
• `expire_snapshots_min_retention_ms`: Минимальное время удержания снимков (в миллисекундах) до их удаления.

Подведение Итога

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

• Формат Хранения:**
  • Parquet: Явно превосходит для большинства аналитических рабочих нагрузок. Колоночная природа, эффективное сжатие, нативная интеграция Field IDs Iceberg для схемы эволюции и широкая поддержка делают его выбором по умолчанию и наиболее рекомендуемым.
  • ORC: Достойная альтернатива Parquet, особенно если ваша инфраструктура уже использует ORC. Однако, учитывая нюансы отображения типов и общий тренд, Parquet часто является предрочтительнее для новых проектов.
  • Avro: Категорически не подходит для хранения данных аналитических таблиц. Несмотря на то, что Iceberg использует Avro для своих метаданных, применение его для самих данных приведет к крайне низкой производительности и высоким затратам.

• Алгоритмы Сжатия:**
  • Snappy: Отличный компромисс между скоростью и степенью сжатия. Хорош для большинства активных данных, где скорость доступа критична.
  • ZSTD: Предпочтителен, если снижение затрат на хранение является приоритетом, и вы готовы к небольшому увеличению использования CPU. Начинает обгонять Snappy по популярности для многих сценариев.
  • GZIP: Избегайте для активных данных из-за низкой скорости декомпрессии. Используйте только для долгосрочного архивирования.

• Конфигурация:**
  • Партиционирование: Критично для ускорения запросов. Выбирайте его с умом, основываясь на шаблонах запросов и объеме данных.
  • Версия формата Iceberg (v2): Используйте для новых таблиц, чтобы получить доступ к последним возможностям.
  • Целевой размер файлов (`write_target_data_file_size_bytes`): Настройте в диапазоне 128MB-1GB, чтобы избежать проблемы маленьких файлов и обеспечить хороший параллелизм Trino.
  • Параметры сжатия и размера блоков Parquet: Настройте такие параметры, как `parquet_row_group_size` и `parquet_compression` для дальнейшей оптимизации.

Используя Iceberg с Trino, вы получаете мощную комбинацию для создания высокопроизводительных, надежных и управляемых озер данных. Тщательный выбор форматов хранения, алгоритмов сжатия и тонкая настройка конфигурации будут ключами к максимальному использованию потенциала этих технологий, обеспечивая оптимальную производительность запросов при контролируемых затратах. Начните с Parquet и Snappy/ZSTD, а затем адаптируйте конфигурацию в зависимости от ваших конкретных рабочих нагрузок и требований к стоимости.

Schema Registry (реестр схем) — критический компонент в экосистеме Apache Kafka, обеспечивающий контракты данных, управление эволюцией схем и валидацию сообщений. В 2025 году лидирующие решения — Confluent Schema Registry, Apicurio Registry, а также облачные и интегрированные варианты (AWS Glue, Redpanda). Разберем их функциональность, преимущества и недостатки.

1. Confluent Schema Registry: эталон для Kafka

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

• Форматы схем** Avro, Protobuf, JSON Schema. confluent.io
• Совместимость:** Поддерживает 8 стратегий совместимости (BACKWARD, FORWARD, FULL и их транзитивные аналоги) confluent.io с проверкой при регистрации новой версии схемы.
• Интеграции:** Глубоко встроен в Confluent Platform (Kafka Connect, ksqlDB), предоставляет REST API, а Confluent Control Center (GUI) доступен в Enterprise-версии.
• Архитектура:** Является отдельным сервисом, хранит схемы в специальном внутреннем топике Kafka (`_schemas`). Обеспечивается высокая доступность через primary-secondary узлы.

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

• Зрелость:** Промышленный стандарт с 2015 года, обладающий богатой документацией и обширным сообществом.
• Расширенные функции:** Включает такие возможности, как Schema Linking (репликация и синхронизация схем между различными кластерами Schema Registry) и контексты схем для поддержки мультитенантности.
• Эффективное кэширование:** Клиенты запрашивают схему из кэша по ID (который передается в сообщении), значительно уменьшая накладные расходы.

Недостатки:

• Операционные затраты:** Требует отдельного развертывания, мониторинга и управления инфраструктурой, если не используется управляемый сервис.
• Стоимость:** Расширенные функции, включая Enterprise GUI и усиленную безопасность, доступны только в платных версиях Confluent Platform.

2. Apicurio Registry: гибкость open source

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

• Форматы схем:** Поддерживает не только Avro, Protobuf и JSON Schema, но и другие форматы, такие как OpenAPI, AsyncAPI, GraphQL и XML Schema.apicur.io
• Совместимость:** Предоставляет правила валидации и совместимости, включая возможность определения кастомных правил.
• Хранение:** Обладает плагинной архитектурой для Persistent Storage, поддерживая Kafka, PostgreSQL, Infinispan и in-memory хранилище.
• Интеграции:** Имеет REST API, удобную веб-консоль для управления, Kafka SerDes (сериализаторы/десериализаторы) и совместим с клиентами Confluent. apicur.io

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

• Гибкость:** Поддержка более 10 форматов спецификаций и возможность выбора СУБД для хранения данных.
• Без vendor lock-in:** Полностью open source, распространяется под лицензией Apache 2.0.
• Безопасность:** Интеграция с Keycloak (OpenID Connect) для управления доступом предоставляется бесплатно.

Недостатки:

• Сложность эксплуатации:** Отсутствие официальной managed-версии означает, что для развертывания и поддержания Apicurio Registry требуются собственные навыки администрирования.
• Ограниченная зрелость:** По сравнению с Confluent, может иметь меньше встроенных инструментов мониторинга и интеграций с другими корпоративными системами, хотя быстро развивается. Но за Confluent надо платить.

3. Альтернативные решения

AWS Glue Schema Registry

• Плюсы:** Serverless-сервис, глубокая интеграция с другими сервисами AWS (такими как Amazon MSK и Kinesis), модель оплаты по запросам.
• Минусы:** Замкнут в экосистеме AWS, может не поддерживать все продвинутые правила совместимости (например, транзитивные).

Redpanda Schema Registry

• Плюсы:** Встроен непосредственно в брокер сообщений Redpanda, что обеспечивает очень низкую задержку и API-совместимость с Confluent Schema Registry.
• Минусы:** Привязка к брокеру Redpanda, относительно меньше enterprise-функций по сравнению с Confluent.

Сравнительная таблица

Итоги: что выбрать?

1. Confluent Schema Registry — идеален для корпоративных Kafka-инфраструктур, где требуются максимальная стабильность, расширенное управление схемами и глубокая интеграция с Confluent Platform. Подходит для финансовых и регуляторных сценариев из-за своей зрелости и поддержки.

2. Apicurio Registry — лучший выбор для гибридных сред, микросервисов на gRPC/GraphQL, или при ограниченном бюджете. Незаменим, если вы ищете полностью открытое и гибкое решение, которое не привязывает вас к конкретному вендору. Еще, кстати, он интегрируется с OpenMetaData – как говорят.

3. Облачные решения (AWS Glue Schema Registry) — подойдут для стека AWS, если необходимо минимизировать операционные накладные расходы и использовать полностью управляемый сервис.

4. Интегрированные решения (Redpanda Schema Registry) — оправданы, если вы уже используете или планируете использовать Redpanda в качестве брокера сообщений.

Главный тренд 2025: Рост популярности Apicurio из-за поддержки полиглотных архитектур и принципов open source. Однако Confluent сохраняет лидерство в Kafka-centric проектах благодаря своей глубине интеграции и богатому набору функций для крупных предприятий.

Предостережение: «Бесплатные» решения (Apicurio, Redpanda) требуют операционных затрат на развертывание, мониторинг и обслуживание. Для стартапов с ограниченным бюджетом Apicurio может быть предпочтительнее; для крупных предприятий, уже инвестировавших в Kafka, Confluent часто становится естественным выбором. Миграция между системами возможна, но требует тщательной проверки совместимости схем и данных.

А у кого-то есть платная kafka?

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

Оригинал тут: https://unionailoop.substack.com/p/the-evolution-and-future-of-ai-orchestration
2 июля 2025 г. – Кетан Умаре — генеральный директор и соучредитель Union.ai. Ранее он занимал несколько руководящих должностей в Lyft, Oracle и Amazon, работая с облачными технологиями, распределенными системами хранения данных, картографией и системами машинного обучения.

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

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

Настоящим узким местом являются не модели или вычисления – это мы.

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

1. Зарождение оркестрации: ETL и микросервисы

2012 – ETL
Оркестрация впервые появилась для обеспечения ETL (извлечение, преобразование, загрузка), где планировщики, такие как Airflow, управляли приемом и преобразованием данных на больших хранилищах данных.

Диаграмма: Процесс ETL

• Извлечение:** Извлекает и проверяет данные из различных источников.
• Преобразование:** Обрабатывает и организует извлеченные данные, чтобы сделать их пригодными для использования.
• Загрузка:** Перемещает преобразованные данные в репозиторий данных.

2014 – Микросервисы
Поскольку использование постоянно растущих объемов данных стало более критичным для инноваций, возникла потребность в оркестрации микросервисов, где системы, такие как AWS Step Functions или Cadence, обеспечивали надежное выполнение вызовов сервисов и повторные попытки в транзакционных системах.

На ранних этапах оркестрация в основном сосредоточивалась на упорядочивании или определении, когда и как вызывать функцию, запускать скрипт или запускать контейнер. Трудоёмкие вычисления перекладывались на традиционные вычислительные движки, такие как Spark, AWS Batch, GCP Cloud Run или, позже, K8s. Оркестрация не касалась вычислений, и ей это было не нужно.

2. Машинное обучение: оркестрация встречается с вычислениями

2017 – ML-конвейеры
ML привнесло новые требования: дорогие вычисления и отказоустойчивость.

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

Эти потребности породили оркестраторы ML-конвейеров, такие как Flyte, которые до сих пор являются открытыми решениями для оркестрации, на которые полагается большинство команд.

2021 – Управляемая оркестрация ML
По мере того как оркестрация ML становилась более сложной, она ложилась более тяжелым бременем на команды ML, данных и платформ, которым нужно было поддерживать инфраструктуру. Им нужны были системы оркестрации, которые определяли DAG (ориентированный ациклический граф), выделяли ресурсы, управляли жизненным циклом задач и чисто масштабировались до нуля.

Платформы оркестрации, такие как Union.ai, Prefect и Airflow, появились для снятия инфраструктурной нагрузки с оркестрации. С появлением эпохи ИИ они стали гораздо популярнее для команд, создающих рабочие процессы ИИ/ML, как критически важную часть своей работы.

3. Агентные системы: оркестрация в эпоху ИИ

2025 – ИИ и агентная оркестрация
Сейчас мы вступаем в новую фазу: оркестрацию интеллектуальных агентов и систем ИИ.

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

1. Они зависят от интеграций. Агенты часто полагаются на внешние инструменты (API, базы данных, модели), и эти взаимодействия должны управляться.
2. Они принимают динамические решения. Агенты часто уточняют результаты за несколько проходов, подобно настройке гиперпараметров или рекурсивному исключению признаков в ML.
3. Они делегируют. Один агент может вызывать другого, который может разветвляться на новые инструменты или рабочие процессы.
4. Они требуют вычислений. Рассмотрим агентов, которые решают парсить веб или выполнять код. Если мы думаем об агентах как о программистах, то быстро понимаем, что оркестрация без доступа к вычислениям ограничивает их автономию.

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

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

Будущая инфраструктура разработки ИИ

“По некоторым оценкам, более 80% проектов ИИ терпят неудачу – это вдвое превышает процент неудач проектов в области информационных технологий, которые не связаны с ИИ”. – RAND

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

• Динамические рабочие процессы:** в отличие от статических DAG, динамические рабочие процессы позволяют агентам и системам ИИ принимать решения на лету во время выполнения.
• Гибкая интеграция инфраструктуры:** оркестрация должна происходить по облакам и кластерам, в некоторых случаях динамически переключаясь на источник наиболее доступных вычислений.
• Кросс-командное выполнение:** эти платформы должны объединять отдельных лиц, команды и агентов в единой среде разработки совместно, безопасно и надежно.
• Наблюдаемость, надежность и управление:** агенты и рабочие процессы могут работать автономно в черном ящике. Платформы разработки ИИ должны обеспечивать прозрачность для рассуждений, сбоев, происхождения данных и использования ресурсов.
• Масштаб:** большие данные становятся больше. Вычислительная мощность востребована как никогда. Платформы должны надежно справляться с требованиями к масштабированию, присущими этим системам.

Заключение:

Слой инфраструктуры разработки ИИ

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

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

Агенты и современные ML-системы требуют нового слоя в наших технологических стеках: инфраструктуры разработки ИИ.

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

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

Будущее оркестрации обеспечивает основу для слоя инфраструктуры разработки ИИ, будучи:

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

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

Вопрос больше не “как запустить этот конвейер?”, а “как позволить системам решать, что запускать, когда запускать и как делать это надежно в масштабе?”

CRISP-ML(Q) (Cross-Industry Standard Process for Machine Learning with Quality Assurance) — это современная процессная модель для управления жизненным циклом ML-проектов. Она была разработана как эволюция классической методологии CRISP-DM (Cross-Industry Standard Process for Data Mining, 1999 г.), которая остается одной из самых популярных методологий для проектов по анализу данных datascience-pm.com. CRISP-ML(Q) адаптирует и расширяет CRISP-DM, добавляя этапы, критичные для промышленного машинного обучения: обеспечение качества, мониторинг и поддержку моделей в продакшене.

Возникновение CRISP-ML(Q) продиктовано статистикой: значительная часть ML-проектов (по некоторым оценкам, 75-85%) не достигали поставленных целей из-за отсутствия стандартизации, проблем с данными и недооценки операционных рисков. В отличие от CRISP-DM, который сосредоточен в первую очередь на процессе анализа данных medium.com, CRISP-ML(Q) охватывает полный жизненный цикл — от бизнес-постановки до эксплуатации ML-систем, делая основной акцент на обеспечении качества на каждом шаге mdpi.com.

Кстати ранее писал про The Big Book of MLOps – 2nd Edition: https://gavrilov.info/all/sintez-the-big-book-of-mlops-2nd-edition/

А еще тут добавлю про ZenML pdf’ку и https://github.com/zenml-io/zenml

Ключевые фазы методологии (6 этапов)

CRISP-ML(Q) структурирует процесс разработки ML-решений в шесть основных взаимосвязанных и итеративных фаз:

1. Понимание бизнеса и данных (Business Understanding & Data Understanding)
   На этом начальном этапе определяются и понимаются бизнес-цели проекта (например, снижение времени обработки заявки на 20%), а также ключевые показатели эффективности (KPI). Эти бизнес-цели затем переводятся в конкретные задачи машинного обучения. Одновременно проводится глубокий анализ данных: исследуется их доступность, качество, потенциальные проблемы (пропуски, аномалии) и нормативные ограничения (например, GDPR), а также оцениваются необходимые ресурсы. На этом этапе могут использоваться инструменты типа ML Canvas для оценки осуществимости проекта.

2. Инженерия данных (Data Engineering)
   Эта фаза включает всестороннюю подготовку данных для моделирования. Это очистка данных (обработка пропущенных значений, удаление или корректировка выбросов), их трансформация (нормализация, стандартизация), балансировка классов (методы oversampling/undersampling), а также генерация новых, более информативных признаков (feature engineering). Важным нововведением здесь является внедрение Data Unit Tests для предотвращения ошибок и поддержания качества данных до их использования в моделях.

3. Моделирование машинного обучения (Machine Learning Modeling)
   На этом этапе команда выбирает подходящие алгоритмы машинного обучения, учитывая такие ограничения, как интерпретируемость модели, вычислительные ресурсы и требования к времени отклика. Происходит обучение моделей, настройка гиперпараметров и оценка их производительности на валидационных наборах данных. Для обеспечения воспроизводимости и отслеживаемости всех экспериментов фиксируются метаданные: используемые гиперпараметры, версии датасетов, окружение выполнения. Применяются такие инструменты, как MLflow и Kubeflow.

4. Оценка качества ML-моделей (Quality Assurance)
   Это одна из ключевых отличительных фаз CRISP-ML(Q), выделенная в отдельный этап. Здесь проводится всестороннее тестирование модели: оценка ее устойчивости к зашумленным данным, проверка ключевых метрик (accuracy, F1-score, ROC-AUC) и глубокий анализ справедливости (fairness) для выявления и устранения потенциальных смещений в предсказаниях. Решение о переходе к развертыванию принимается только после того, как модель достигнет заданных пороговых значений качества (например, precision > 0.9). Эта фаза может включать проверку надежности, стабильности и объяснимости модели mdpi.com.

5. Развертывание (Deployment)
   На этом этапе обученная и проверенная модель интегрируется в производственную среду. Развертывание может осуществляться различными способами: как REST-API, микросервис или встроенный плагин. Используются стратегии безопасного развертывания, такие как A/B-тестирование, канареечные релизы или сине-зеленое развертывание. Обязательной частью этой фазы является наличие четкого плана отката на предыдущую версию в случае возникновения сбоев или неожиданной деградации производительности.

6. Мониторинг и поддержка (Monitoring & Maintenance)
   После развертывания модели начинается фаза непрерывного мониторинга её производительности в реальных условиях. Это критически важно, так как модели машинного обучения могут терять свою эффективность со временем из-за дрейфа данных (concept drift или data drift). Мониторинг включает отслеживание метрик производительности модели, выявление аномалий и автоматическое переобучение при падении метрик или существенном изменении распределения входных данных. Также на этом этапе происходит сбор новых данных, которые могут быть использованы для последующего ретренинга моделей, замыкая цикл улучшения mdpi.com.

Таблица 1: Сравнение CRISP-DM и CRISP-ML(Q)

Таблица 2: Детализация Задач по Фазам CRISP-ML(Q)

Принципы обеспечения качества (QA)

CRISP-ML(Q) интегрирует принципы обеспечения качества на каждом этапе цикла разработки ML:

• Риск-ориентированный подход: Для каждой фазы идентифицируются потенциальные риски (например, смещение данных, переобучение, дрейф модели), и разрабатываются методы их минимизации. Примеры включают использование кросс-валидации, объяснимых моделей (таких как SHAP для интерпретации предсказаний) и тщательное логирование экспериментов.
• Документирование: Поддерживается строгая документация требований, версий данных, используемых метрик оценки и любых изменений в пайплайне. Инструменты типа Model Cards Toolkit могут использоваться для создания прозрачных отчетов о моделях.
• Автоматизация пайплайнов: Для обеспечения воспроизводимости и эффективности процессов активно используются автоматизированные конвейеры (data pipelines, ML pipelines).

pic. Этапы оценки рисков

MLOps: Концепция, Инструменты и Сравнение с Apache Airflow

MLOps — это, по сути, инженерная дисциплина, сосредоточенная на автоматизации и масштабировании жизненного цикла ML-систем, включая CI/CD (непрерывная интеграция/непрерывная поставка) для моделей, автоматизированное тестирование и мониторинг в продакшене mdpi.com.
CRISP-ML(Q), напротив, является процессной моделью, которая задает последовательность шагов и необходимых активностей для успешного выполнения ML-проекта.

Таким образом, они дополняют друг друга:

• CRISP-ML(Q) определяет “что делать” и “когда делать” на каждом этапе жизненного цикла ML-проекта, фокусируясь на методологии и целях.
• MLOps предоставляет инструменты и практики для реализации этих “что делать”, отвечая на вопрос “как делать”.

Apache SeaTunnel и Apache DolphinScheduler в контексте MLOps

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

• Apache SeaTunnel: Этот фреймворк является высокопроизводительным, распределенным решением для интеграции и синхронизации больших объемов данных news.apache.org. Он позволяет быстро и эффективно перемещать данные между различными источниками (например, базы данных, облачные хранилища, Kafka) и потребителями данных.
  > В контексте MLOps, SeaTunnel играет ключевую роль в:
  > – Подготовке данных: Автоматизация сбора, очистки и трансформации данных для обучения и переобучения моделей. Это включает потоковую ETL/ELT обработку, что обеспечивает актуальность и качество обучающих данных.
  > – Получении данных для мониторинга: Сбор метрик производительности модели и данных о её входящих запросах из различных систем для последующего анализа дрейфа данных или деградации производительности.
  > – Интеграции с ML-платформами: SeaTunnel может выступать в качестве универсального коннектора для передачи данных в хранилища признаков (feature stores) или напрямую в тренировочные пайплайны.
  > Фактически, SeaTunnel унифицирует процесс синхронизации и интеграции данных, поддерживая разнообразные источники и цели, необходимые для обработки больших объёмов данных в ML-системах. blog.devgenius.io. Например, его можно использовать для эффективного сбора данных для поиска сходства между книгами с помощью больших языковых моделей apacheseatunnel.medium.com.

• Apache DolphinScheduler: Это распределенная платформа для оркестрации рабочих процессов (workflow orchestration) с возможностью визуализации и мониторинга dolphinscheduler and seatunnel vs airflow and nifi. Если Apache SeaTunnel занимается *движением данных*, то DolphinScheduler отвечает за *управление последовательностью задач*.
  > В MLOps DolphinScheduler может использоваться для:
  > – Оркестрации ML-пайплайнов: Автоматизация запуска задач по подготовке данных (с помощью SeaTunnel), обучению моделей, их оценке, развертыванию и мониторингу. Он позволяет определять зависимости между задачами, управлять их выполнением по расписанию или по событию, а также обрабатывать ошибки.
  > – Управление ресурсами: Эффективное распределение вычислительных ресурсов для различных этапов ML-рабочих процессов.
  > – Мониторинг рабочих процессов: Предоставление наглядных дашбордов для отслеживания статуса пайплайнов, выявления узких мест и оперативного реагирования на сбои. blog.devgenius.io.

SeaTunnel и DolphinScheduler против Apache Airflow

Обычно для оркестрации рабочих процессов в MLOps применяется Apache Airflow. Однако, в определенных сценариях, комбинация Apache DolphinScheduler и Apache SeaTunnel может предложить преимущества:

• Apache Airflow: Широко используется для создания, планирования и мониторинга программно определенных рабочих процессов (DAGs – Directed Acyclic Graphs) risingwave.com. Он обладает высокой гибкостью и огромным комьюнити.
• Преимущества DolphinScheduler + SeaTunnel в MLOps:
  • Специализация: SeaTunnel специализируется на высокопроизводительной передаче данных, что делает его более эффективным для задач, связанных с перемещением и синхронизацией больших объемов данных, часто возникающих в ML. Airflow, с другой стороны, является более общим оркестратором.
  • Визуализация и удобство: DolphinScheduler часто отмечается за его более интуитивный графический интерфейс и drag-and-drop функциональность, что может упростить создание и управление ML-пайплайнами для пользователей с меньшим опытом программирования, чем в Airflow, который требует написания кода на Python для DAGs. dev.to. DolphinScheduler поддерживает модель “Workflow as Code”, но дополняется более удобной визуализацией.
  • Распределенная архитектура: DolphinScheduler изначально разрабатывался как распределенная система, что может быть преимуществом для очень больших и сложных рабочих процессов, эффективно распределяя нагрузку.
  • Комплексное решение для данных: Сочетание DolphinScheduler с SeaTunnel предоставляет более цельное решение для управления как потоками данных, так и рабочими процессами, тогда как Airflow требует интеграции с отдельными инструментами для обработки данных.

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

Примеры MLOps-платформ: Databricks и ZenML

На рынке существуют как открытые, так и коммерческие MLOps-платформы, которые объединяют различные инструменты для реализации полного цикла ML-разработки:

• Databricks: Эта компания является одним из лидеров в области озер данных (Data Lakehouse) и MLOps. Их платформа предоставляет интегрированную среду для полной цепочки MLOps: от подготовки данных с использованием Apache Spark (ядра платформы Databricks risingwave.com), обучения моделей, управления экспериментами (MLflow, разработанный Databricks) до развертывания и мониторинга. “The big book of MLOps от Databricks” — это всеобъемлющее руководство, которое детализирует их подход к построению MLOps-систем, подчеркивая важность воспроизводимости, автоматизации и совместной работы.
• ZenML: Это Extensible MLOps фреймворк, ориентированный на Developer Experience. ZenML позволяет создавать портативные, воспроизводимые и масштабируемые MLOps-пайплайны, абстрагируя пользователей от сложности базовой инфраструктуры. Он поддерживает множество интеграций с другими популярными ML-библиотеками и платформами (например, TensorFlow Extended, PyTorch, Kubeflow, MLflow), позволяя командам выбирать лучшие инструменты для своих задач, сохраняя при этом единую MLOps-структуру. ZenML фокусируется на “workflow-as-code” и модульности, что делает его гибким решением для различных MLOps-сценариев.

Из россияйских есть Neoflex Dognauts она обеспечивает полный цикл разработки и эксплуатации
ML-моделей для решения задач бизнеса. Это единая платформа корпоративного MLOps позволяет управлять всем жизненным циклом DS/ML от постановки бизнес-задач до управления внедренными моделями Neoflex Dognauts

Коммерческая реализация WhaleOps

На рынке существуют и коммерческие реализации платформ, основанные на технологиях Apache и тесно интегрированные с принципами CRISP-ML(Q) и MLOps. Одним из ярких примеров является компания WhaleOps Technology. linkedin.com Основанная в августе 2021 года ключевыми участниками проектов Apache DolphinScheduler и Apache SeaTunnel, WhaleOps специализируется на создании решений для DataOps и MLOps. github.com Платформа WhaleOps предлагает комплексный набор инструментов, который помогает компаниям внедрять и управлять ML-моделями в продакшене, используя открытые стандарты и обеспечивая высокий уровень автоматизации и контроля качества на всех этапах жизненного цикла модели. cn.linkedin.com Такая интеграция open-source фреймворков и коммерческих платформ позволяет организациям строить масштабируемые и надежные ML-системы, полностью соответствующие лучшим практикам, описанным в CRISP-ML(Q).

Практические кейсы применения

CRISP-ML(Q) применяется в различных отраслях для создания надежных и управляемых ML-решений:

• Предиктивное обслуживание в Mercedes-Benz: Использование CRISP-ML(Q) для прогнозирования поломок автомобилей. На фазе мониторинга был выявлен дрейф данных, вызванный изменением условий эксплуатации, что потребовало своевременного переобучения моделей для поддержания их точности.
• Кредитный скоринг в банках: На фазе оценки качества (QA) методики CRISP-ML(Q) помогли обнаружить смещение модели против клиентов старше 60 лет. Это позволило скорректировать модель перед её развертыванием, обеспечив справедливость и соответствие этическим нормам.

Критика и ограничения

Несмотря на свои преимущества, CRISP-ML(Q) имеет и некоторые ограничения:

• Сложность внедрения: Для небольших проектов или стартапов, возможно, будет избыточным следование всем детальным процедурам CRISP-ML(Q) из-за требований к документации и ресурсам.
• Нехватка инструментов: Хотя MLOps предоставляет множество инструментов, некоторые аспекты QA, такие как автоматизированная проверка этики или полностью автоматизированное управление дрейфом данных, все еще требуют активного участия человека и не всегда полностью автоматизированы.

Заключение

CRISP-ML(Q) — это наиболее полная и зрелая методология для управления промышленными ML-проектами. Она успешно закрывает пробелы CRISP-DM за счет:

1. Системного обеспечения качества (QA) на всех этапах жизненного цикла.
2. Эффективного эксплуатационного мониторинга развернутых моделей.
3. Пристального внимания к воспроизводимости всех экспериментов и моделей.

Для достижения максимального успеха в ML-проектах рекомендуется комбинировать методологические рамки CRISP-ML(Q) с инженерными практиками MLOps. Интеграция мощных open-source фреймворков, таких как Apache SeaTunnel и Apache DolphinScheduler, а также использование комплексных MLOps-платформ, как Databricks или ZenML, и коммерческих решений вроде WhaleOps, позволяет автоматизировать и масштабировать эти процессы. Дальнейшее развитие методологии, вероятно, будет направлено на стандартизацию этических аудитов и дальнейшую автоматизацию процессов обработки дрейфа данных, делая ML-системы ещё более надёжными и управляемыми.

Источники

• Оригинальная статья CRISP-DM: https://medium.com/voice-tech-podcast/cross-industry-standard-process-for-data-mining-crisp-dm-9edc0c5e3a1
• CRISP-DM и его популярность: https://www.datascience-pm.com/crisp-dm-still-most-popular/
• CRISP-ML(Q) и MLOps: https://www.mdpi.com/2076-3417/11/19/8861
• Руководство по выбору алгоритма: https://www.kdnuggets.com/2020/05/guide-choose-right-machine-learning-algorithm.html
  image-194.png.jpg
• Подробное описание CRISP-ML(Q) на Medium: https://medium.com/@desmondonam/understanding-the-crisp-ml-q-1e8c5bbfb8cb
• Apache SeaTunnel (официальный проект): news.apache.org
• SeaTunnel – эволюция архитектуры: blog.devgenius.io
• SeaTunnel для поиска (пример): apacheseatunnel.medium.com
• DolphinScheduler и SeaTunnel vs Airflow и NiFi: dev.to
• DolphinScheduler – Workflow as Code + SageMaker: blog.devgenius.io
• Apache Airflow vs Spark: risingwave.com
• WhaleOps Technology (LinkedIn): linkedin.com
• WhaleOps Technology (GitHub): github.com
• WhaleOps Technology (LinkedIn CN): cn.linkedin.com
• Databricks: (“The big book of MLOps от Databricks” – ссылка на книгу, если доступна, или на соответствующий раздел сайта Databricks. Например: databricks.com)
• ZenML: zenml.io/

Битва персональных AI-суперкомпьютеров ( подготовил DeepSeek 😁 и спасибо ему за это )
Если чего, то эти игрушки для подходят для запуска средних моделей у себя дома. Железа должно хватит.
Впрочем битва только начинается. посмотрим, что еще выйдет. А пока наслаждаемся тем, что есть.

Введение: Эра доступного AI-железа

Революция генеративного ИИ сместила фокус с облачных кластеров на персональные устройства. В 2025 году два решения претендуют на звание «AI-суперкомпьютер на столе»: NVIDIA DGX Spark (ранее Project DIGITS) и Orange Pi AI Studio Pro. Оба обещают экзафлопсную производительность, но с разной философией. Разберем их детально, используя данные из официальных анонсов, тестовых обзоров и сообществ (включая [Habr](https://habr.com/ru/companies/bothub/news/872002/) и [Reddit](https://www.reddit.com/r/LocalLLaMA/comments/1im141p/orange_pi_ai_studio_pro_mini_pc_with_408gbs/)).

---

1. Аппаратная платформа: Архитектура и Производительность

NVIDIA DGX Spark

• Чипсет: GB10 Grace Blackwell Superchip – гибрид 20-ядерного ARM-процессора (Cortex-X925 + Cortex-A725) и GPU Blackwell с Tensor Core 5-го поколения .
• Память: 128 ГБ LPDDR5X с единым адресным пространством (CPU+GPU), что критично для обработки моделей до 200B параметров без перегрузок .
• Производительность: 1 PFLOPS при FP4 с поддержкой спарсности. Для моделей >200B параметров два устройства связываются через ConnectX-7, достигая 405B .
• Энергоэффективность: Потребляет ~120–240 Вт, работает от розетки 220 В .

Orange Pi AI Studio Pro

• Чипсет: Huawei Ascend 310s с NPU, заявленная производительность – 352 TOPS (INT8) в Pro-версии .
• Память: До 192 ГБ LPDDR4X (в конфигурации Pro), но без унификации. Пользователи Reddit отмечают проблемы с пропускной способностью при загрузке LLM >70B параметров .
• Масштабируемость: Нет аналога NVLink. Для больших моделей требуется ручная оптимизация через swap-файлы .
• Охлаждение: Инженерные образцы склонны к перегреву при длительной нагрузке, что требует дополнительного кулера .

Резюме: DGX Spark выигрывает в балансе памяти и вычислений, Orange Pi предлагает сырую мощность TOPS, но страдает от архитектурных ограничений.

---

2. Программная экосистема: Готовность к работе

NVIDIA

• Стек: Полная предустановка DGX OS + CUDA, NeMo, RAPIDS, поддержка PyTorch/Jupyter. Бесшовная интеграция с NGC-каталогом и облаком DGX .
• Развертывание: Локальная тонкая настройка (fine-tuning) моделей до 70B параметров с последующим деплоем в дата-центр без переписывания кода .
• Для разработчиков: Поддержка Windows через WSL2, что упрощает миграцию с ПК .

Orange Pi

• ПО: Базовые образы Ubuntu/OpenEuler. Для работы AI требуется CANN-Toolkit (только через Docker), установка которого занимает 5–6 часов из-за зависимостей .
• Поддерживаемые фреймворки: ONNX, TensorFlow, Caffe. Нет поддержки PyTorch напрямую! Экспорт LLM (например, Whisper) возможен только через ONNX с ручной конвертацией .
• Сообщество: Документация – преимущественно на китайском. Англоязычные гайды фрагментарны, а на Reddit жалуются на сложность отладки .

Резюме: NVIDIA предлагает enterprise-решение «из коробки», Orange Pi требует экспертных знаний и времени для настройки.

---

3. Сценарии использования: Для кого эти устройства?

• NVIDIA DGX Spark:
  • Исследователи: Локальный запуск Llama 3 70B или GPT-4-class моделей.
  • Корпорации: Разработка edge-приложений для робототехники (Isaac) или медвизуализации (Clara) с гарантией совместимости .
  • Стартапы: Прототипирование агентов ИИ с помощью NIM-микросервисов .

• Orange Pi AI Studio Pro:
  • Энтузиасты: Эксперименты с компьютерным зрением (YOLO) на дешевом железе.
  • Нишевые проекты: Развертывание специфичных моделей (например, для обработки сенсорных данных), где не нужна интеграция с облаком.
  • Китайский рынок: Альтернатива Jetson Orin для вузов и госпредприятий .

---

4. Цена и Доступность

• NVIDIA: От $3000, доступен с мая 2025 через партнеров (например, Dell, Supermicro) .
• Orange Pi: Цена не объявлена, но аналоги (Atlas 200I DK) стоили ~$500. Ориентировочно Pro-версия – $700–$1000. Важно: нет глобальных поставок; покупка только через AliExpress .

Итоговая таблица сравнения

Заключение: Что выбрать?

• NVIDIA DGX Spark – выбор для тех, кому нужен промышленный инструмент с минимумом настройки. Идеален для команд, внедряющих ИИ в продукты с последующим масштабированием. Демократизация без жертв .
• Orange Pi AI Studio Pro – экспериментальная платформа для тех, кому важен TOPS/$ и кто готов бороться с китайской документацией. Подойдет для R&D в условиях санкционных ограничений или бюджетных проектов .

Тренд: Оба устройства подтверждают сдвиг ИИ в сторону edge-вычислений. Но если NVIDIA ведет к «персонализации суперкомпьютеров», то Orange Pi остается хардварным хаком для избранных. Ориентируйтесь на задачи: для стартапа или лаборатории – DGX Spark; для образовательных целей или кастомных задач – Orange Pi, если вы готовы к боли.

*«AI будет мейнстримом в каждом приложении для каждой индустрии»* (Дженсен Хуанг, NVIDIA ). В 2025 это звучит как констатация факта, а не прогноз.

Почитать подробнее можно тут:
https://www.nvidia.com/en-us/products/workstations/dgx-spark/
или тут
http://www.orangepi.cn/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-AI-Studio-Pro.html