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, или при ограниченном бюджете. Незаменим, если вы ищете полностью открытое и гибкое решение, которое не привязывает вас к конкретному вендору.

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

Интересная штука – монитор на электронных чернилах цветных

https://onyxboox.com/boox_miraprocolor

Но дорогой конечно- 250к тык

Лучший в мире монитор для дашбордов 😁

Mira Pro Color – это первый цветной E Ink монитор от бренда ONYX BOOX. Он отлично подходит для работы с самыми разными текстами, а также со схемами, диаграммами и чертежами – в том числе и цветными, разумеется. При этом, правда, он не годится для работы с фотографиями и видео, так как его экран отображает только 4096 оттенков и является довольно медлительным (таковы, к сожалению, особенности E Ink дисплеев).

Почему стоит купить ONYX BOOX Mira Pro Color?

Главным доводом в пользу покупки ONYX BOOX Mira Pro Color является экран – даже несмотря на его недостатки, описанные выше. Дело в том, что он очень похож на лист бумаги и по этой причине не так утомляет глаза, как обычные светящиеся экраны. Кроме того, картинка на нём остаётся чёткой даже на ярком солнце, а при плохом освещении можно использовать встроенную подсветку без мерцания. Стоит отметить и высокое разрешение в режиме «16 оттенков серого» – 3200 на 1800 пикселей при диагонали 25,3” (разрешение в цветном режиме составляет 1600 на 900 пикселей).

Помимо этого, монитор ONYX BOOX Mira Pro Color примечателен возможностью регулировки не только угла наклона, но и высоты, а также возможностью поворота на 90 градусов. Есть здесь и крепление VESA 75, два динамика и порты USB-C, HDMI, mini HDMI и DisplayPort. В комплекте с монитором идут три кабеля и высококачественная подставка, которая выполнена из алюминия (как и сам монитор).

Под конец заметим, что ONYX BOOX Mira Pro Color можно использовать в паре с компьютерами на базе операционных систем Windows и macOS, а также с мобильными устройствами на базе операционных систем Android и iOS.

В чём заключается разница между Mira Pro Color и Mira Pro?

Эти модели идентичны по дизайну и габаритам, но снабжаются разными экранами. На ONYX BOOX Mira Pro Color установлен экран E Ink Kaleido 3, отображающий 4096 цветов, а на ONYX BOOX Mira Pro – экран E Ink Carta, отображающий 16 оттенков серого. Диагональ экрана в обоих случаях составляет 25,3“; разрешение в чёрно-белом режиме тоже одинаковое – 3200 на 1800 пикселей. Подсветка есть на обеих моделях, но при этом следует заметить, что ранее выпускалась версия Mira Pro без подсветки.

Свежак, начал читать 📚 Около 700 рублей стоит цифровая версия тут

Вот обзор и рецензия на книгу «Масштабируемые данные от Gemini 2.5 Pro. Высоконагруженные архитектуры, Data Mesh и Data Fabric. 2-е изд.», основанные на информации об ее оригинальном издании “Data Management at Scale” за авторством Питхайна Стренгхолта.

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

Эта книга является русским изданием работы Питхайна Стренгхолта “Data Management at Scale” и посвящена современным подходам к управлению данными в крупных организациях. Она фокусируется на архитектурных концепциях, таких как Data Mesh и Data Fabric, которые призваны решить проблемы традиционных монолитных систем, вроде централизованных озер и хранилищ данных.

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

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

Ключевые концепции, разбираемые в книге:

1. Децентрализация и Data Mesh: Книга подробно описывает архитектуру Data Mesh, впервые предложенную Жэмаком Дегани и популяризированную Мартином Фаулером. Этот подход рассматривает данные как продукт и передает владение ими командам, которые эти данные создают и лучше всего понимают https://medium.com/it-architecture/review-data-management-at-scale-fc52fda45e0b. При этом метаданные остаются централизованными, что позволяет другим командам легко находить, понимать и использовать нужные им данные.
2. Данные как продукт (Data as a Product): Это фундаментальный сдвиг в мышлении. Данные перестают быть побочным эффектом работы приложений и становятся полноценным продуктом со своим жизненным циклом, владельцем, стандартами качества и SLA. Доступ к таким продуктам данных обычно предоставляется через стандартизированные API https://www.linkedin.com/pulse/data-mesh-book-review-beyond-antti-pikkusaari.
3. Архитектурные паттерны: Автор рассматривает различные шаблоны проектирования для создания продуктов данных и организации их взаимодействия в рамках компании https://www.oreilly.com/library/view/data-management-at/9781098138851/.

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

• Стратегический взгляд: Книга дает отличное высокоуровневое представление о том, как переосмыслить управление данными в масштабах всей организации. Она идеально подходит для архитекторов и руководителей, которым нужно понять «почему» и «что», а не «как» в деталях.
• Актуальность: Концепции Data Mesh и Data Fabric находятся на пике популярности. Книга помогает систематизировать знания по этим темам и понять их философские основы.
• Четкая аргументация: Автор убедительно доказывает, почему традиционные подходы к данным перестают работать при росте компании и увеличении сложности, и почему децентрализация ответственности является логичным шагом эволюции.

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

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

• Нехватка технических деталей: Книга отлично объясняет принципы, но не углубляется в конкретные технологии и инструменты. Например, она говорит о необходимости API для доступа к данным, но не предлагает детальных руководств по их созданию или выбору технологий https://www.linkedin.com/pulse/data-mesh-book-review-beyond-antti-pikkusaari.
• Полет в облаках: Один из рецензентов на Goodreads метко подмечает, что книга «предпочитает витать в облаках», не опускаясь на более низкий уровень для разъяснения тонкостей. Например, остается не до конца ясным, где проходит грань между данными, метаданными и кодом в рамках одного «продукта данных» data-management-at-scale.

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

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

• Дата-архитекторам, CDO (Chief Data Officer) и руководителям отделов данных: Для них это мастрид. Книга поможет сформировать стратегическое видение и защитить новые подходы перед бизнесом.
• Продукт-менеджерам и тимлидам: Поможет понять, как выстраивать процессы вокруг «данных как продукта» и эффективно взаимодействовать с другими командами.
• Дата-инженерам и аналитикам: Будет полезна для понимания общей картины и современных трендов, но ее нужно будет дополнять более техническими статьями и докладами для практической реализации.

Заключение

«Масштабируемые данные» Питхайна Стренгхолта — это важный и своевременный труд, который предлагает стратегический взгляд на решение проблем управления данными в больших компаниях. Это не техническое руководство, а скорее манифест и философское обоснование для перехода к децентрализованным, продуктово-ориентированным архитектурам, таким как Data Mesh.

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

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

WAIC (World Artificial Intelligence Conference) — это крупнейшая международная конференция по искусственному интеллекту, проходящая в Китае. Её ключевые аспекты:

300 000 посетителей 😱 и 1300 спикеров 😱 https://www.worldaic.com.cn – программу не ищите, ее просто нет. еще.

pdf тут http://a.gavrilov.info/data/posts/WAIC2025.pdf

1. Фокус на инновациях:
   • Демонстрация прорывных технологий, включая робототехнику и Embodied AI (физические роботы, заменяющие людей в локальных сценариях). Например, на WAIC 2024 было представлено [более 50 роботов], многие из которых дебютировали именно здесь.
   • Участие ведущих компаний (включая Alibaba, SenseTime), даже тех, кто не специализируется исключительно на ИИ.

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

3. Бизнес-экосистема:
   • Стартапы (например, SenseTime, разработчик систем распознавания лиц) привлекают многомиллионные инвестиции через WAIC.
   • Выставки и нетворкинг объединяют инвесторов, разработчиков и корпорации.

4. Тренды:
   • Акцент на практическом применении ИИ в промышленности, здравоохранении и повседневной жизни.
   • Рост темпов развития не только программных, но и аппаратных решений (роботы, сенсоры).

⚠️ Не путать с Western Association of Independent Camps WAIC https://www.waic.org — это отдельная организация, не связанная с ИИ.

Как же захотелось в Шанхай :)

Их сайт https://online2025.worldaic.com.cn у меня с компа не открылся :( вроде должна быть возможность платного участия, но онлайн.

Представляем ClickStack

Сегодня мы рады анонсировать ClickStack — новое опенсорсное решение для обсервабилити, созданное на базе ClickHouse. ClickStack предоставляет полноценное решение «из коробки» для работы с логами, метриками, трейсами и воспроизведением сессий. Оно работает на основе производительности и эффективности ClickHouse, но спроектировано как полноценный стек для обсервабилити — открытый, доступный и готовый для всех.

Оригинал статья тут: https://clickhouse.com/blog/clickstack-a-high-performance-oss-observability-stack-on-clickhouse

Подробнее тут: https://clickhouse.com/use-cases/observability?loc=o11y
Попробовать тут: https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started

В течение многих лет крупные инженерные команды, такие как в Netflix и eBay, выбирали ClickHouse в качестве основной базы данных для обсервабилити. Её колоночная структура, сжатие и высокопроизводительный векторизованный движок запросов сделали её идеальной для хранения «широких событий» — записей с богатым контекстом и высокой кардинальностью, которые объединяют логи, метрики и трейсы. Этот современный подход к обсервабилити (некоторые называют его «Observability 2.0») отходит от традиционной модели «трёх столпов» и устраняет сложность объединения разрозненных источников телеметрии.

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

Сегодня всё меняется. С выпуском ClickStack на базе HyperDX мы уравниваем шансы. Этот полностью опенсорсный стек включает в себя готовый коллектор OpenTelemetry, пользовательский интерфейс, разработанный для «широких событий», запросы на естественном языке, воспроизведение сессий, оповещения и многое другое.

И всё это работает на том же высокопроизводительном движке ClickHouse с высоким уровнем сжатия, которому доверяют крупнейшие имена в сфере обсервабилити.

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

С ClickStack вам не придётся выбирать — наслаждайтесь быстрым поиском и быстрыми агрегациями по данным высокой кардинальности в формате «широких событий». В больших масштабах. С открытым исходным кодом. И теперь — для всех.

Эволюция ClickHouse для обсервабилити

Всего лишь очередная задача по работе с данными

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

Именно поэтому ClickHouse уже много лет находится в основе стеков обсервабилити. От отраслевых гигантов, таких как Netflix и eBay, до стартапов в сфере обсервабилити, таких как Sentry и Dash0, ClickHouse обеспечивает работу с логами, метриками и трейсами в огромных масштабах. Её колоночное хранилище, агрессивное сжатие и векторизованный движок выполнения запросов значительно снижают затраты и обеспечивают выполнение запросов за доли секунды, что необходимо инженерам для отладки систем в реальном времени без ожидания медленных инструментов.

Всё, что вам нужно, — это «широкие события»… и колоночное хранилище

В нашей предыдущей статье «Состояние обсервабилити на основе SQL» и последующих публикациях мы подробно исследовали этот тренд. Хотя тогда мы не дали ему названия, он идеально совпадает с сегодняшним движением «Observability 2.0»: единая модель, построенная вокруг «широких событий», а не «столпов». Слишком долго команды полагались на отдельные хранилища для логов, метрик и трейсов, что приводило к фрагментации, ручной корреляции и ненужной сложности. «Широкие события» устраняют эти разрозненные хранилища, объединяя все сигналы обсервабилити в единую, запрашиваемую структуру.

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

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

Эффективность ресурсов и масштабируемость

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

По мере усложнения потребностей в обсервабилити мы поняли, что нативная поддержка JSON для полуструктурированных событий стала необходимым минимумом. ClickHouse развивался, чтобы удовлетворить эту потребность, добавив первоклассную поддержку полуструктурированных данных, сохраняя при этом преимущества колоночной обработки. Колонки создаются автоматически по мере поступления данных, и ClickHouse автоматически управляет повышением типов и ростом колонок. Это та самая «схема при записи» (schema-on-write), которая вам нужна для обсервабилити, с производительностью, сжатием и гибкостью, ожидаемыми от современного аналитического движка.

Рост популярности OpenTelemetry

Эта эволюция совпала с ростом популярности OpenTelemetry (OTel), который сейчас является стандартом де-факто для сбора телеметрии, включая логи, метрики и трейсы. Мы начали официально поддерживать и вносить вклад в OpenTelemetry Exporter для ClickHouse.

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

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

Недостающие элементы

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

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

Мы хотели чего-то более продуманного. Более простого способа для начала работы. Но самое главное — интерфейс, созданный для ClickHouse. И не просто любой интерфейс, а тот, который понимает, как строить эффективные запросы, выявлять паттерны в «широких событиях» и обеспечивать исключительный пользовательский опыт, не скрывая при этом мощь базы данных.

Наконец, хотя мы считаем, что обсервабилити на основе SQL сыграла важную роль в укреплении модели «широких событий», мы также понимали, что должны пойти навстречу пользователям. Поисковые движки, такие как стек ELK, добились успеха, потому что они предлагали нечто интуитивно понятное: естественный язык для запроса логов. Мы хотели предоставить такой же опыт нашим пользователям, но на базе ClickHouse.

Добро пожаловать, HyperDX

Именно тогда мы нашли HyperDX — опенсорсный слой для обсервабилити, специально созданный на ClickHouse. Когда HyperDX открыл исходный код своего интерфейса v2 в конце 2024 года, мы протестировали его внутри компании и быстро поняли, что это и есть недостающий элемент. Настройка была бесшовной, опыт разработчика — превосходным, и мы знали, что наши пользователи заслуживают того же.

HyperDX принёс всё, что мы искали: https://github.com/hyperdxio/hyperdx

• Сбор данных на основе стандартов:** HyperDX с самого начала использовал OpenTelemetry, что идеально совпало с нашими инвестициями в экспортёр OpenTelemetry для ClickHouse.
• Опенсорс в первую очередь:** Мы считаем, что надёжные инструменты для обсервабилити должны быть доступны всем, и HyperDX разделяет эту философию. Его облачно-нативная архитектура обеспечивает простую и экономичную эксплуатацию.

Помимо соответствия стандартам, HyperDX создан с учётом особенностей ClickHouse. Команда серьёзно относится к оптимизации запросов, так что вам не придётся об этом думать. Пользовательский интерфейс тесно связан с движком, обеспечивая быструю и надёжную производительность там, где миллисекунды имеют значение, особенно во время расследования инцидентов.

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

Простота ClickStack означает, что каждый слой масштабируется независимо. Нужна более высокая пропускная способность приёма данных? Просто добавьте больше шлюзов коллектора OpenTelemetry. Нужно больше ресурсов для запросов или хранения? Масштабируйте ClickHouse напрямую. Эта модульная конструкция позволяет легко расти вместе с вашими данными и вашей командой — без полной перестройки стека.

С момента приобретения HyperDX мы сосредоточились на упрощении продукта и расширении его гибкости. Вы можете использовать схему по умолчанию для бесшовной настройки «из коробки» или использовать собственную схему, адаптированную под ваши нужды. Как и в случае с самим ClickHouse, мы понимаем, что универсального решения не существует, и гибкость — ключ к масштабированию.

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

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

Возможно, самое важное — стек стал проще. С утверждением OpenTelemetry в качестве повсеместного стандарта все данные теперь поступают через OTel-коллектор. Настройка по умолчанию использует продуманную схему для быстрого старта, но пользователи могут изменять или расширять её по мере необходимости. Стек является нативным для OpenTelemetry, но не эксклюзивным для него: благодаря открытой схеме HyperDX может работать и с вашими существующими пайплайнами данных и схемами.

Заключение и взгляд в будущее

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

Наша приверженность открытому исходному коду гарантирует, что ClickStack останется доступным для всех — от развёртываний с одним сервисом до систем объёмом в несколько петабайт. Мы продолжим инвестировать как в ядро базы данных для высокопроизводительной обсервабилити, так и в интеграции с уже зарекомендовавшими себя инструментами, такими как Grafana, обеспечивая бесшовную совместимость с существующими стеками.

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

Начните свой путь с ClickStack, ознакомившись с нашим руководством по началу работы в документации.

Начните работать с ClickHouse Cloud сегодня и получите $300 в виде кредитов. По окончании 30-дневного пробного периода вы можете продолжить работу по плану с оплатой по мере использования или связаться с нами, чтобы узнать больше о наших скидках за объём. Посетите нашу страницу с ценами для получения подробной информации.

----

Что предлагается?

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

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

---

Поиск, дашборды и оповещения

ClickStack объединяет логи, метрики, трейсы и воспроизведение сессий на одной платформе с помощью интерфейса HyperDX. Оптимизированный для ClickHouse, он поддерживает быстрый поиск в стиле Lucene и полный доступ по SQL для углубленного анализа с использованием более 100 встроенных функций.
Создавайте дашборды и оповещения с минимальной настройкой. Выявляйте аномалии с помощью дельт событий и ускоряйте анализ первопричин, используя паттерны событий.

Хранилище на базе ClickHouse

Работая на базе ClickHouse, HyperDX выполняет поиск по терабайтам данных за секунды и ежедневно принимает миллиарды событий высокой кардинальности. ClickStack поставляется с оптимизированными схемами, что устраняет необходимость в ручной настройке и позволяет вам сосредоточиться на получении инсайтов.

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

Сбор данных

ClickStack нативно поддерживает стандарт OpenTelemetry, собирая логи, метрики и трейсы в виде «широких событий» — записей с богатым контекстом, которые объединяют данные обсервабилити в ClickHouse.
Благодаря нативной поддержке JSON, ClickHouse эффективно обрабатывает развивающиеся, полуструктурированные данные. Поля создаются автоматически при приёме данных, а сжатое колоночное хранилище обеспечивает быстрые запросы и высокую степень сжатия без необходимости предварительного определения схемы.

---

Хотите собрать свой собственный стек?

Нужен собственный пайплайн или схема? Интерфейс HyperDX не зависит от схемы и работает с любым пайплайном телеметрии, подключаясь к любому экземпляру ClickHouse для полного контроля над вашими данными обсервабилити.
Создаёте свой собственный стек? ClickHouse предоставляет все необходимые инструменты: высокопроизводительный движок SQL, приём данных по HTTP, масштабируемое хранилище MergeTree и материализованные представления для трансформации данных в реальном времени. Для гибкой работы с дашбордами используйте плагин для Grafana, чтобы сопоставлять данные из ClickHouse с другими источниками.

---

Снизьте ваши затраты на обсервабилити

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

✨ Простое развертывание и обслуживание

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

📄 Откройте для себя обсервабилити в реальном времени

ClickHouse спроектирован для обработки огромных объёмов непрерывных потоков входящих данных, поддерживая скорость приёма данных в гигабайты в секунду, при этом обеспечивая доступность новых данных для поиска с задержкой менее секунды.
Созданный для самых интенсивных нагрузок в реальном времени, HyperDX использует мощный набор функций агрегации и анализа ClickHouse с глубокими оптимизациями для обеспечения молниеносных запросов в системе обсервабилити.

💡 Не только для обсервабилити

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

Инструментируйте ваши приложения

Отслеживайте каждый лог, API-запрос, запрос к БД и многое другое всего несколькими строками кода. Инструментируйте и наблюдайте за своим стеком за считанные минуты с ClickStack.

Опубликовано 21.10.2023. Изменено 06.11.2023.

Оригинал: https://unixdigest.com/articles/we-have-used-too-many-levels-of-abstractions-and-now-the-future-looks-bleak.html

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

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

Слишком мало и слишком много всё портит.

Какая польза от абстракции, когда она ломается и никто больше не понимает, как работает технология “под капотом”?

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

Сегодня программистов и системных администраторов больше не существует, вместо них у нас есть DevOps и даже DevSecOps, в которых индустрия очень старательно пытается втиснуть каждую отдельную задачу в должностную инструкцию одного человека. Специалисты по технологиям должны выполнять разработку (Dev), безопасность (Sec) и операции (Ops), то есть системное администрирование, но поскольку ни один человек не может по-настоящему освоить все это, нам нужно автоматизировать как можно больше, чтобы сэкономить деньги и избежать сложностей человеческого социального взаимодействия между различными техническими отделами. В результате современному специалисту по технологиям enseñan только тому, как использовать конкретные инструменты, и он или она очень мало знает о технологии “под капотом”.

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

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

Да, давайте все вернемся к кодированию на ассемблере!

— Саркастический комментарий высокомерного разработчика

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

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

— Кен Томпсон

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

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

Советы изучающим технологии:

1. Никогда не следуйте за хайпом или трендами.
2. Будьте любопытны. Не просто изучайте инструменты, старайтесь понять, как работает базовая технология.
3. Если возможно, попробуйте хотя бы один раз вручную сделать то, что, например, делает для вас инструмент конфигурации.
4. Если возможно, попробуйте посмотреть код инструмента. Даже базовое понимание кода может быть очень ценным.
5. Сохраняйте любопытство. Продолжайте учиться. Экспериментируйте. Погружайтесь глубже в интересующие вас технологии. Если возможно, создайте домашнюю лабораторию и используйте ее как игровую площадку для обучения и слома вещей.
6. Ставьте под сомнение все. Особенно то, что вам кажется бессмысленным. Не думайте, что кто-то знает лучше — так вы быстро превратитесь в слепого последователя. Иногда кто-то действительно знает лучше, но не делайте такого вывода по умолчанию. И будьте смелыми! Стойте на стороне правды и своих убеждений, даже если это заставляет вас чувствовать себя одиноким.

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

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

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

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

Примерно полгода назад я наткнулся на несколько фронтенд-веб-разработчиков, которые не знали, что веб-сайт можно создать без инструмента развертывания и что JavaScript вообще не нужен, даже если веб-сайт принимает платежи. Я спросил об этом своего друга, который в то время преподавал программирование на Python, и он сказал:

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

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

Если, например, я веб-разработчик, будь то фронтенд или бэкенд, или занимаюсь так называемой “интеграционной работой” и создаю веб-сайты без особого кодирования или каких-либо знаний о TCP/IP, DNS, HTTP, TLS, безопасности и т. д., используя только готовые инструменты или фреймворки, то это сделает меня примерно таким же полезным, как обезьяна с динамометрическим ключом, когда что-то пойдет не так.