Перевод: https://www.pracdata.io/p/the-evolution-of-business-intelligence-stack

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

Это первая часть нашей серии, посвященная эволюции архитектуры бизнес-аналитики (BI).

Введение

Ландшафт бизнес-аналитики (BI) претерпел значительные преобразования в последние годы, особенно в том, как данные представляются и обрабатываются.

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

В этой статье прослеживается эволюция BI-архитектуры через несколько ключевых этапов: от традиционных монолитных систем, через появление безголовой (headless) и бездонной (bottomless**) BI, до последних разработок в области BI-as-Code и встроенной аналитики.

** 😂 👯‍♀️

Если серьезно, то наверное лучший вариант бескрайний

Традиционная BI-архитектура: Монолитный подход

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

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

*Традиционный BI-стек*

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

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

Семантический уровень завершал архитектуру, определяя ключевые показатели эффективности (KPI) и метрики, встроенные в BI-программное обеспечение.

Недостатки традиционных BI-инструментов

Хотя эти традиционные системы были мощными, они имели значительные накладные расходы.

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

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

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

Появление бездонных (Bottomless) BI-инструментов

В ответ на эти вызовы появилось новое поколение легких, дезагрегированных BI-инструментов. Заметные решения с открытым исходным кодом, такие как Apache Superset, Metabase и Redash, начали появляться около десяти лет назад, причем Superset, первоначально разработанный в Airbnb, приобрел особую известность в экосистеме.

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

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

Работа с задержкой запросов

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

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

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

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

Появление универсального семантического слоя

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

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

С помощью таких инструментов, как Cube и MetricFlow (теперь часть dbt Labs), например, организации могут определять свои метрики и модели данных в центральном месте, а затем подключать различные инструменты визуализации, пользовательские приложения или легкие BI-решения к этому семантическому слою.

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

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

Движение BI-as-Code

В последние годы наблюдается появление BI-as-Code, представляющего собой еще более легкий подход к разработке панелей мониторинга и интерактивных приложений для работы с данными.

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

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

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

Хотя Streamlit лидирует по популярности, в последние годы появились новые решения с открытым исходным кодом, такие как Evidence, Rill, Vizro и Quary, каждое из которых привносит свой собственный подход к концепции BI-as-Code.

Ограничения BI-as-Code

Инструменты BI-as-Code в настоящее время имеют ограничения с точки зрения интерактивных функций исследования данных и предоставления BI-возможностей корпоративного уровня.

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

Тем не менее, BI-as-Code все чаще используется различными способами, например, командами специалистов по обработке данных, создающими интерактивные автономные приложения, командами разработчиков продуктов, создающими встроенные функции аналитики, и аналитиками, разрабатывающими внутренние приложения для работы с данными.

Новая развивающаяся тенденция: BI + Встроенная аналитика

Последняя эволюция в BI-архитектуре включает интеграцию высокопроизводительных встраиваемых OLAP-движков запросов, таких как Apache DataFusion и DuckDB.

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

Новая полнофункциональная компонуемая BI-архитектура дает несколько ключевых преимуществ:

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

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

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

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

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

Внедрение в отрасли

Внедрение встраиваемых движков запросов в отрасли набирает обороты в экосистеме BI. Коммерческие поставщики возглавляют эту трансформацию: Omni интегрировала DuckDB в качестве своего основного аналитического движка, в то время как Cube.dev реализовала сложное сочетание Apache Arrow и DataFusion в своей безголовой BI-архитектуре.

Аналогичным образом, GoodData приняла эту тенденцию, реализовав Apache Arrow в качестве основы уровня кеширования своей системы FlexQuery, а Preset (Managed Superset) интегрировалась с MotherDuck (Managed DuckDB).

В области открытого исходного кода и Superset (с использованием библиотеки duckdb-engine), и Metabase теперь поддерживают встроенное подключение DuckDB с потенциальной будущей интеграцией в их основные движки.

Движение BI-as-Code также приняло встраиваемые движки. Rilldata объявила об интеграции DuckDB в 2023 году для автоматического профилирования и интерактивного моделирования при разработке панелей мониторинга, в то время как Evidence представила Universal SQL в 2024 году, основанный на реализации WebAssembly от DuckDB.

Заключение

Ландшафт бизнес-аналитики продолжает развиваться в сторону более гибких и эффективных решений.

Каждое архитектурное изменение принесло явные преимущества: безголовая BI обеспечила согласованность метрик между инструментами, бездонная BI снизила сложность инфраструктуры, BI-as-Code привнесла рабочие процессы разработчиков в аналитику, а встроенные движки теперь объединяют эти преимущества с высокопроизводительными возможностями запросов.

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

Перевод Open Source Data Engineering Landscape 2025

Введение

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

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

Хотя этот обзор публикуется ежегодно, соответствующий репозиторий GitHub обновляется регулярно в течение года. Не стесняйтесь вносить свой вклад, если заметите какой-либо недостающий компонент.

Методология исследования

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

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

Стек включает в себя озеро данных (S3), Parquet в качестве формата сериализации, DuckDB для обработки и аналитики, Apache NiFi для интеграции данных, Apache Superset для визуализации и PostgreSQL для управления метаданными, а также другие инструменты. Эта установка позволила мне собрать около 1 ТБ необработанных данных о событиях GitHub, состоящих из миллиардов записей, а также агрегированный набор данных, который накапливается ежедневно, в общей сложности более 500 миллионов записей за 2024 год.

Критерии выбора инструментов

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

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

Итак, без лишних слов, представляем обзор Open Source инструментов для инженерии данных 2025 года:

Обзор Open Source инструментов для инженерии данных 2025

Состояние Open Source в 2025 году

Экосистема Open Source инструментов для инженерии данных значительно выросла в 2024 году: в этом году в обзор добавлено более 50 новых инструментов, при этом удалено около 10 неактивных и архивных проектов. Хотя не все эти инструменты были запущены в 2024 году, они представляют собой важные дополнения к экосистеме.

Хотя этот рост демонстрирует постоянные инновации, в этом году также наблюдались некоторые тревожные события, связанные с изменением лицензирования. Устоявшиеся проекты, включая Redis, CockroachDB, ElasticSearch и Kibana, перешли на более закрытые и проприетарные лицензии, хотя Elastic позже объявила о возвращении к Open Source лицензированию.

Однако эти изменения были уравновешены значительным вкладом в Open Source сообщество со стороны крупных игроков отрасли. Вклад Snowflake в Polaris, открытие исходного кода Unity Catalog от Databricks, пожертвование OneHouse Apache XTable и выпуск Netflix Maestro продемонстрировали постоянную приверженность ведущих компаний отрасли разработке Open Source.

Фонд Apache сохранил свои позиции в качестве ключевого управляющего технологиями данных, активно инкубируя несколько перспективных проектов в течение 2024 года. Среди заметных проектов в инкубации были Apache XTable (универсальный формат таблиц), Apache Amoro (управление Lakehouse), Apache HoraeDB (база данных временных рядов), Apache Gravitino (каталог данных), Apache Gluten (промежуточное ПО) и Apache Polaris (каталог данных).

Фонд Linux также укрепил свои позиции в области данных, продолжая размещать такие исключительные проекты, как Delta Lake, Amundsen, Kedro, Milvus и Marquez. Фонд расширил свой портфель в 2024 году, добавив новые значительные проекты, включая vLLM, пожертвованный Калифорнийским университетом в Беркли, и OpenSearch, который был передан из AWS в Фонд Linux.

Open Source vs Open Core vs Open Foundation

Не все перечисленные проекты являются полностью совместимыми, независимыми от поставщиков Open Source инструментами. Некоторые работают по модели Open Core, где не все компоненты полной системы доступны в Open Source версии. Как правило, критически важные функции, такие как безопасность, управление и мониторинг, зарезервированы для платных версий.

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

Обзор категорий

Ландшафт инженерии данных разделен на 9 основных категорий:

* Системы хранения: базы данных и механизмы хранения, охватывающие OLTP, OLAP и специализированные решения для хранения.
* Платформа озера данных: инструменты и фреймворки для построения и управления озерами данных и Lakehouse.
* Обработка и интеграция данных: фреймворки для пакетной и потоковой обработки, а также инструменты обработки данных Python.
* Оркестрация рабочих процессов и DataOps: инструменты для оркестрации конвейеров данных и управления операциями с данными.
* Интеграция данных: решения для приема данных, CDC (Change Data Capture) и интеграции между системами.
* Инфраструктура данных: основные компоненты инфраструктуры, включая оркестрацию контейнеров и мониторинг.
* ML/AI платформа: инструменты, ориентированные на ML-платформы, MLOps и векторные базы данных.
* Управление метаданными: решения для каталогов данных, управления и управления метаданными.
* Аналитика и визуализация: BI-инструменты, фреймворки визуализации и аналитические механизмы.

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

1. Системы хранения

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

DuckDB стал историей крупного успеха, особенно после выпуска версии 1.0, которая продемонстрировала готовность к промышленному использованию для предприятий. Новая категория встраиваемых OLAP расширилась за счет новых участников, таких как chDB (построенный на ClickHouse), GlareDB и SlateDB, что отражает растущий спрос на легкие аналитические возможности обработки.

Расширения OLAP и HTAS

Значительным событием стало распространение новых расширений OLAP, особенно в экосистеме PostgreSQL.

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

Выпуск MotherDuck pg_duckdb стал важным шагом вперед, позволив DuckDB служить встроенным механизмом OLAP в PostgreSQL. За ним последовало расширение pg_mooncake, предоставляющее собственные возможности хранения столбцов в открытых табличных форматах, таких как Iceberg и Delta. Crunchy Data и ParadeDB внесли аналогичный вклад через pg_parquet и pg_analytics соответственно, обеспечивая прямую аналитику по файлам Parquet в озерах данных.

Архитектура без дисков (Zero-Disk)

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

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

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

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

Новые системы баз данных, включая базу данных временных рядов SlateDB и Apache HoraeDB, были построены с нуля с использованием этой архитектуры, в то время как устоявшиеся системы, такие как Apache Doris и StarRocks, приняли ее в 2024 году. Другие механизмы реального времени, такие как AutoMQ и InfluxDB 3.0, все чаще применяют парадигму без дисков.

Для всестороннего анализа архитектуры без дисков и ее последствий см. подробное исследование в следующей статье: Архитектура без дисков: будущее облачных систем хранения. https://www.pracdata.io/p/zero-disk-architecture-the-future

Другие заметные разработки

После перехода Redis на проприетарную лицензию в 2024 году Valkey стала ведущей альтернативой с открытым исходным кодом, став самой звездной системой хранения на GitHub в 2024 году. Крупные облачные провайдеры быстро приняли ее: Google интегрировал ее в Memorystore, а Amazon поддерживает ее через сервисы ElastiCache и MemoryDB.

Другие заметные разработки включают ParadeDB, альтернативу Elasticsearch, построенную на движке PostgreSQL, и новые гибридные системы потокового хранения, такие как Proton от TimePlus и Fluss, представленные Ververica. Эти системы направлены на интеграцию функций потоковой передачи и OLAP с основой хранения столбцов.

2. Платформа озера данных

Поскольку пионер баз данных Майкл Стоунбрейкер одобрил архитектуру lakehouse и открытые табличные форматы как «архетип OLAP СУБД на следующее десятилетие», lakehouse остается самой горячей темой в инженерии данных.

Ландшафт открытых табличных форматов продолжал значительно развиваться в 2024 году. Четвертый основной открытый табличный формат, Apache Paimon, вышел из инкубации, предоставив возможности потоковой передачи lakehouse с интеграцией Apache Flink. Apache XTable появился как новый проект, ориентированный на двунаправленное преобразование форматов, в то время как Apache Amoro вошел в инкубацию со своим фреймворком управления lakehouse.

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

Все основные поставщики SaaS и облачных технологий улучшили свои платформы для поддержки доступа к открытым табличным форматам. Однако поддержка записи была менее распространена, причем Apache Iceberg был предпочтительным выбором для комплексной интеграции CRUD (Create, Read, Update, Delete).

Управляемые таблицы BigLake от Google, позволяющие изменять таблицы Iceberg в облачном хранилище, управляемом клиентом, недавно анонсированные таблицы S3 от Amazon с нативной поддержкой Iceberg, а также другие основные инструменты SaaS, такие как Redpanda, запускающие Iceberg Topics, и Crunchy Data Warehouse, глубоко интегрирующиеся с Apache Iceberg, являются примерами растущего внедрения и глубокой интеграции с Iceberg в экосистеме.

В будущем универсальные табличные форматы, такие как Apache XTable и Delta UniForm (Delta Lake Universal Format), могут столкнуться со значительными трудностями в навигации по потенциальному расхождению функций в различных форматах, а судьба открытых табличных форматов может отражать судьбу открытых файловых форматов, когда Parquet стал фактическим стандартом.

По мере того, как экосистема lakehouse продолжает расти, ожидается, что внедрение совместимых открытых стандартов и фреймворков в рамках платформы Open Data Lakehouse приобретет большую популярность.

Появление библиотек нативных табличных форматов

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

Яркими примерами являются Delta-rs, нативная библиотека Rust для Delta Lake со связями Python; Hudi-rs, реализация Rust для Apache Hudi с API Python, и PyIceberg, развивающаяся библиотека Python, предназначенная для улучшения доступа к табличному формату Iceberg за пределами движка Spark по умолчанию.

3. Обработка и интеграция данных

Подъем одноузловой обработки

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

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

Современные механизмы одноузловой обработки, такие как DuckDB, Apache DataFusion и Polars, стали мощными альтернативами, способными обрабатывать рабочие нагрузки, которые ранее требовали распределенных систем, таких как Hive/Tez, Spark, Presto или Amazon Athena.

Чтобы ознакомиться с полным анализом состояния одноузловой обработки, перейдите по ссылке ниже: https://www.pracdata.io/p/the-rise-of-single-node-processing или тут есть перевод https://gavrilov.info/all/rascvet-odnouzlovoy-obrabotki-brosaya-vyzov-podhodu-raspredelyon/

Потоковая обработка

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

Отмечая свое 10-летие, Flink выпустил версию 2.0, представляющую первое крупное обновление с момента дебюта Flink 1.0 восемь лет назад. Экосистема Apache Flink значительно расширилась с появлением открытого табличного формата Apache Paimon и недавно открытого движка потоковой обработки Fluss. В 2024 году ведущие облачные провайдеры все чаще интегрировали Flink в свои управляемые сервисы, последним из которых стало бессерверное решение Google BigQuery Engine для Apache Flink.

Появляющиеся движки потоковой обработки — Fluvio, Arroyo и FastStream — стремятся конкурировать с этими признанными претендентами. Fluvio и Arroyo выделяются как единственные движки на основе Rust, которые направлены на устранение накладных расходов, обычно связанных с традиционными движками потоковой обработки на основе JVM.

В главных новостях потоковой передачи с открытым исходным кодом Redpanda приобрела Benthos.dev, переименовав ее в Redpanda Connect и переведя на более проприетарную лицензию. В ответ WarpStream создал форк проекта Benthos, переименовав его в Bento и обязавшись сохранить его 100% лицензированным по MIT.

Фреймворки обработки Python

В экосистеме обработки данных Python Polars в настоящее время является доминирующей высокопроизводительной библиотекой DataFrame для задач инженерии данных (за исключением PySpark). Polars достиг впечатляющих 89 миллионов загрузок в 2024 году, отметив важный этап выпуска версии 1.0.

Однако теперь Polars сталкивается с конкуренцией со стороны API DataFrame от DuckDB, который привлек внимание сообщества своей удивительно простой интеграцией с внешними системами хранения и интеграцией без копирования (прямое совместное использование памяти между различными системами) с Apache Arrow, аналогично Polars. Обе библиотеки входят в 1% самых загружаемых библиотек Python в прошлом году.

Apache Arrow укрепил свои позиции в качестве фактического стандарта для представления данных в памяти в экосистеме обработки данных Python. Фреймворк установил глубокую интеграцию с различными фреймворками обработки Python, включая Apache DataFusion, Ibis, Daft, cuDF и Pandas 3.0.

Ibis и Daft — это другие инновационные проекты DataFrame с высоким потенциалом. Ibis имеет удобный внутренний интерфейс для различных баз данных на основе SQL, а Daft предоставляет возможности распределенных вычислений, созданные с нуля для поддержки распределенной обработки DataFrame.

Оркестрация рабочих процессов и DataOps

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

После десятилетия Apache Airflow продолжает оставаться наиболее развернутым и принятым движком оркестрации рабочих процессов с ошеломляющими 320 миллионами загрузок только в 2024 году, сталкиваясь с конкуренцией со стороны растущих конкурентов, таких как Dagster, Prefect и Kestra.

Интересно, что Kestra получил наибольшее количество звезд на GitHub в 2024 году, причем всплеск напрямую связан с объявлением о его финансировании в размере 8 миллионов долларов в сентябре, которое было опубликовано на TechCrunch. С точки зрения активности кода, Dagster продемонстрировал замечательную активность разработки с впечатляющими 27 000 коммитов и почти 6 000 закрытыми запросами на вытягивание в 2024 году.

Для всестороннего анализа состояния систем оркестрации рабочих процессов прочтите следующую статью: https://www.pracdata.io/p/state-of-workflow-orchestration-ecosystem-2025

Качество данных

Great Expectations продолжает оставаться ведущим фреймворком Python для обеспечения качества данных и валидации, также представленным в 10 лучших продуктах Databricks для данных и ИИ 2024 года, за которым следуют Soda и Pandera в практике инженерии данных. Однако есть и разочаровывающие новости: проект Data-Diff был заархивирован своим основным разработчиком, Datafold, в 2024 году.

Версионирование данных

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

Такие проекты, как LakeFS и Nessie, улучшают современные озера данных и открытые табличные форматы, такие как Iceberg и Delta Lake, за счет расширения их транзакционных уровней метаданных.

Преобразование данных

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

В настоящее время dbt сталкивается с конкуренцией в основном со стороны SQLMesh. Примечательным противостоянием в 2024 году стали дебаты SQLMesh против dbt, освещенные генеральным директором Tobiko, который заявил в социальных сетях, что SQLMesh настолько хорош, что его запретили на конференции Coalesce от dbt!

Интеграция данных

В области интеграции данных Airbyte сохранил свои лидирующие позиции, достигнув впечатляющей вехи, закрыв 13 000 запросов на вытягивание в рамках подготовки к версии 1.x. Фреймворк dlt продемонстрировал значительное созревание с выпуском версии 1.0, в то время как Apache SeaTunnel набрал обороты в качестве убедительной альтернативы.

Ландшафт фреймворков Change Data Capture (CDC) развивался с появлением новых инструментов, включая Artie Transfer и PeerDB (приобретен ClickHouse), в то время как коннекторы Flink CDC получают распространение среди платформ, использующих Flink в качестве основного движка потоковой передачи.

Центры событий (службы потоковой публикации/подписки)

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

Эта модель также обеспечивает гибкую стратегию развертывания Bring Your Own Cloud (BYOC), поскольку как вычисления, так и хранилище могут размещаться в предпочитаемой клиентом инфраструктуре, в то время как поставщик услуг поддерживает плоскость управления.

Успех WarpStream побудил крупных конкурентов принять аналогичные архитектуры. Redpanda запустила Cloud Topics, улучшив свои предложения, в то время как AutoMQ реализовала гибридный подход с быстрым уровнем кеширования для повышения производительности ввода-вывода.

Кроме того, StreamNative представила движок Ursa для Apache Pulsar, а Confluent представила свои собственные облачные кластеры Freight Clusters в 2024 году. В конечном итоге Confluent решила приобрести WarpStream, еще больше расширив свое предложение с помощью модели BYOC. Между тем, замечательный Apache Kafka стоит на распутье, которое может определить его дальнейшее направление в экосистеме.

Инфраструктура данных

Ландшафт инфраструктуры данных в 2024 году оставался в основном стабильным: Kubernetes отпраздновал свое 10-летие, сохранив при этом свои позиции в качестве ведущего движка планирования ресурсов и виртуализации в облачных средах.

В области наблюдаемости InfluxDB, Prometheus и Grafana продолжали доминировать, причем Grafana Labs обеспечила себе заметный раунд финансирования в размере 270 миллионов долларов, который укрепил долгосрочную жизнеспособность их основных продуктов, таких как Grafana, в качестве универсальных решений для наблюдаемости.

ML/AI платформа

Векторные базы данных сохранили сильный импульс с 2023 года, причем Milvus стала лидером наряду с Qdrant, Chroma и Weaviate. В настоящее время эта категория включает десять активных проектов векторных баз данных, что отражает растущую важность возможностей векторного поиска в современных архитектурах данных с поддержкой ИИ.

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

Управление метаданными

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

Однако наиболее заметные события в 2024 году произошли в управлении каталогами. В то время как в 2023 году доминировала конкуренция в открытых табличных форматах, 2024 год ознаменовал начало «войны каталогов».

В отличие от предыдущих лет, в 2024 году на рынок вышла волна новых решений для открытых каталогов, включая Polaris (открытый исходный код от Snowflake), Unity Catalog (открытый исходный код от Databricks), LakeKeeper и Apache Gravitino.

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

Все эти проекты имеют потенциал для установления нового стандарта для независимых от поставщиков открытых каталожных сервисов на платформах lakehouse. Подобно тому, как Hive Metastore стал фактическим стандартом для платформ на основе Hadoop, эти новые каталоги могут окончательно заменить давнее доминирование Hive Metastore в управлении каталогами на открытых платформах данных.

Аналитика и визуализация

В области бизнес-аналитики с открытым исходным кодом Apache Superset и Metabase остаются ведущими BI-решениями. В то время как Superset лидирует по популярности на GitHub, Metabase демонстрирует наивысшую активность разработки. Lightdash стал многообещающим новичком, получив финансирование в размере 11 миллионов долларов и продемонстрировав рыночный спрос на легкие BI-решения.

BI-as-Code решения

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

Эти инструменты позволяют разработчикам создавать интерактивные приложения и легкие BI-панели управления с помощью кода, SQL и шаблонов, таких как Markdown или YAML, имея возможность комбинировать лучшие практики разработки программного обеспечения, такие как контроль версий, тестирование и CI/CD, в рабочий процесс разработки панелей управления.

В дополнение к Streamlit и известному Evidence новые участники, такие как Quary и Vizro, набрали обороты, причем Quary, в частности, реализовал подход на основе Rust, который отличается от нормы, ориентированной на Python, в этой категории.

Компонуемый BI-стек

Эволюция декомпозиции систем не ограничивается системами хранения; она также повлияла на стеки бизнес-аналитики (BI). Появляется новая тенденция, которая сочетает в себе легкие, бездонные BI-инструменты (которые не имеют внутреннего сервера) с безголовыми встраиваемыми решениями OLAP, такими как Apache DataFusion, Apache Arrow и DuckDB.

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

BI-продукты, такие как Omni, GoodData, Evidence и Rilldata, уже включили эти движки в свои BI-инструменты и инструменты исследования данных. Как Apache Superset (с использованием библиотеки duckdb-engine), так и Metabase теперь поддерживают встроенные подключения DuckDB.

Для всестороннего анализа развивающейся компонуемой BI-архитектуры см. подробное исследование в следующей статье: https://www.pracdata.io/p/the-evolution-of-business-intelligence-stack

Перевод тут https://gavrilov.info/all/evolyuciya-biznes-analitiki-ot-monolitnoy-k-komponuemoy-arhitekt/

MPP Query Engines

В пост-Hadoop эпоху было мало инноваций и внедрения новых систем MPP (массовой параллельной обработки) с открытым исходным кодом, в то время как существующие движки продолжают развиваться.

В то время как доля Hive сокращается, Presto и Trino по-прежнему остаются лучшими движками запросов MPP с открытым исходным кодом, используемыми в производстве, несмотря на жесткую конкуренцию со стороны Spark как унифицированного движка и управляемых облачных продуктов MPP, таких как Databricks, Snowflake и AWS Redshift Spectrum плюс Athena.

Перспективы на будущее и заключение

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

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

• Дальнейшая консолидация в области открытых табличных форматов
• Продолжающаяся эволюция архитектур без дисков в системах реального времени и транзакционных системах
• Стремление к предоставлению унифицированного опыта lakehouse
• Подъем LLMOps и AI Engineering
• Расширение экосистемы lakehouse в таких областях, как интеграция открытых каталогов и разработка нативных библиотек
• Растущая популярность одноузловой обработки данных и встроенной аналитики

Лекция о низкоорбитальном спутниковом интернете в Музее криптографии

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

Основные темы лекции:

1. Современное состояние космической индустрии

• Обзор ключевых направлений: господство, прогресс и научные исследования
• Анализ структуры доходов мировой космической индустрии ($400 млрд в 2021 году)
• Динамика запусков коммерческих спутников и резкий рост их количества

2. Проблема космического мусора

• Статистика объектов на орбите (более 40 500 объектов >10 см)
• Синдром Кесслера и его последствия
• Современные методы борьбы с космическим мусором

3. Лазерная космическая связь

• История развития лазерных технологий
• Преимущества лазерной связи над радиосвязью
• Достижения в области межспутниковой связи
• Рекордная передача данных на расстоянии 31 млн км (миссия Psyche)

4. Проект Бюро 1440

• Характеристики системы: задержка <70 мс, скорость до 1 Гбит/с
• Преимущества: глобальное покрытие, защита данных
• Перспективы развития группировки спутников

Интерактивная часть

Лекция включала активное взаимодействие с аудиторией через голосования и вопросы-ответы. После основной части состоялся квиз для всех желающих.

Образовательные инициативы

Были анонсированы образовательные программы в сотрудничестве с ведущими техническими вузами

Экскурсия

По окончании лекции для зарегистрированных участников была проведена экскурсия по экспозиции “Причем здесь космос” под руководством Антона Громова.

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

Спикеры

Яна Харлан – Директор бюро Двигательные установки
Ксения Лазаренко – Директор бюро лазерные системы
Антон Громов – Ведущий системный инженер

Кстати я думал, что интернет в самолетах на бору появится быстро, но как оказывается это требует специальной сертификации оборудования, которое еще может занимать несколько лет. Так что ждем.
С РЖД, Аэрофлотом и Мегафоном они уже начали сотрудничать в этом направлении, но наземные станции для них сейчас имеют приоритет более высокий.

Список терминальных утилит (A-Z) с рейтингами
Полезность: ⭐️ (1–5) — оценка на основе функционала, популярности и уникальности.
Объективный рейтинг (★): рассчитан по GitHub stars (если доступно), актуальность — июль 2024.

Оригинал тут: https://terminaltrove.com/list/ ссылки то же там есть.
---

A

• act3 ⭐️⭐️⭐️⭐️ — Просмотр последних 3 запусков GitHub Actions. Для CI/CD.
  • *GitHub stars*: ★★★☆ (1.2k).
• adguardian-term ⭐️⭐️ — Мониторинг AdGuard Home. Нишевая утилита для администрирования.
• aerc ⭐️⭐️⭐️⭐️ — Мощный TUI-клиент для работы с электронной почтой. Поддержка IMAP/PGP.
• age ⭐️⭐️⭐️⭐️⭐️ — Шифрование файлов без сложностей. Стал стандартом для DevOps.
  • *GitHub stars*: ★★★★★ (7k+).
• aichat ⭐️⭐️⭐️ — Чат с GPT/Claude в терминале. Аналог ChatGPT, но с офлайн-режимом.
• aider ⭐️⭐️⭐️ — Генерация кода через ИИ (поддержка Python, JavaScript).
• aim ⭐️⭐️ — Загрузчик файлов с возобновлением. Уступает `aria2`.
• ali ⭐️⭐️⭐️ — Нагрузочное тестирование с аналитикой в реальном времени.
• amfora ⭐️⭐️ — Браузер для Gemini-протокола (альтернатива HTTP). Для энтузиастов.
• amp ⭐️⭐️⭐️ — Минималистичный TUI-редактор кода. Аналог Nano.
• angryoxide ⭐️⭐️⭐️ — WiFi-пентестинг на Rust. Для безопасности.
• aria2 ⭐️⭐️⭐️⭐️⭐️ — Мультипоточная загрузка. Незаменим для больших файлов.
  • *GitHub stars*: ★★★★★ (32k+).
• asciinema ⭐️⭐️⭐️⭐️ — Запись терминальных сессий. Интеграция с GitHub/GitLab.
• asn ⭐️⭐️ — Поиск ASN-номеров и сетевых маршрутов.
• astroterm ⭐️ — Звёздная карта в терминале. Развлекательный проект.
• atac ⭐️⭐️⭐️ — TUI-клиент для тестирования API (аналог Postman).
• atop ⭐️⭐️⭐️⭐️ — Расширенный мониторинг процессов (память, сеть, диски).
• atuin ⭐️⭐️⭐️ — История команд с шифрованием и синхронизацией.
  • *GitHub stars*: ★★★☆ (9k).

---

B

• bacon ⭐️⭐️ — Проверка кода на Rust в фоне. Для разработчиков.
• bandwhich ⭐️⭐️⭐️⭐️ — Мониторинг трафика по процессам/соединениям.
• basilk ⭐️⭐️ — Простой канбан-борд для управления задачами.
• bat ⭐️⭐️⭐️⭐️⭐️ — `cat` с подсветкой синтаксиса и навигацией.
  • *GitHub stars*: ★★★★★ (42k+).
• bbcli ⭐️ — TUI для BBC News. Мало фич.
• binsider ⭐️⭐️⭐️ — Анализ ELF-файлов (библиотеки, символы).
• bkp ⭐️⭐️ — Инструмент для резервного копирования. Устаревший.
• blink ⭐️ — Эмулятор x86-64 для Linux. Экспериментальный проект.
• bluetui ⭐️⭐️ — Управление Bluetooth. Альтернатива `bluetoothctl`.
• bluetuith ⭐️⭐️⭐️ — Более функциональный TUI для Bluetooth.
• bmon ⭐️⭐️⭐️ — Графический монитор сетевого трафика.
• bombadillo ⭐️ — Браузер для Gopher, Gemini. Экзотика.
• bottom ⭐️⭐️⭐️⭐️ — Красивый мониторинг ресурсов системы. Поддержка тем.
  • *GitHub stars*: ★★★☆ (7.5k).
• braindrop ⭐️ — TUI для сервиса Raindrop.io. Мало пользователей.
• broot ⭐️⭐️⭐️ — Навигация по файлам с предпросмотром. Для больших проектов.
• brows ⭐️⭐️ — Просмотр релизов GitHub. Нишевое применение.
• browsr ⭐️⭐️ — Файловый менеджер с поддержкой облаков (S3, FTP).
• bt ⭐️ — Файловый менеджер в виде дерева. Сырой интерфейс.
• btop ⭐️⭐️⭐️⭐️ — Интерактивный мониторинг процессов. Поддержка плагинов.
• buku ⭐️⭐️⭐️ — Менеджер закладок в терминале. Локальное хранилище.
• byobu ⭐️⭐️⭐️⭐️ — Надстройка над Tmux/SSH для удобной работы с сессиями.

---

C

• calcure ⭐️⭐️⭐️ — Календарь и менеджер задач с виджетами.
• calcurse ⭐️⭐️ — Простой календарь. Уступает современным аналогам.
• caligula ⭐️ — TUI для создания образов дисков. Не развивается.
• carbon-now-cli ⭐️⭐️⭐️ — Генератор красивого кода для соцсетей. Стильно, но нишево.
• cargo-selector ⭐️⭐️ — Выбор бинарных целей Cargo. Только для Rust.
• carl ⭐️ — Альтернатива `cal`. Недочёт: отсутствие интеграции с задачами.
• cava ⭐️⭐️⭐️ — Визуализация аудио в терминале. Интеграция с Spotify.
• cgdb ⭐️⭐️⭐️ — TUI для GDB. Удобно для отладки.
• chdig ⭐️⭐️ — Кликхаус в терминале. Для аналитиков баз данных.
• toot ⭐️⭐️⭐️ — Клиент Mastodon. Минимум функций, но работает стабильно.
• topgrade ⭐️⭐️⭐️⭐️ — Автоматическое обновление пакетов (apt, brew, npm).
  • *GitHub stars*: ★★★☆ (7k).
• tproxy ⭐️ — Прокси для TCP. Устарел на фоне `mitmproxy`.
• tracexec ⭐️ — Трассировка выполнения программ. Для разработчиков.
• tran ⭐️⭐️⭐️ — Передача файлов по P2P. Аналог Magic Wormhole.
• tre ⭐️⭐️ — Альтернатива `tree` с фильтрами.
• trippy ⭐️⭐️⭐️ — Traceroute с визуализацией. Для сетевой диагностики.
  • *GitHub stars*: ★★☆ (3.4k).
• ttyper ⭐️⭐️ — Тренажёр слепой печати. Без статистики.
• ttyplot ⭐️⭐️⭐️ — Графики в реальном времени (данные из stdin).
• tufw ⭐️ — TUI для UFW (фаервол). Избыточен для CLI-админов.
• tui-journal ⭐️⭐️ — Дневник в терминале. Нет синхронизации.
• tuime ⭐️ — Часы с настройкой цветов. Развлекательный проект.
• tuisky ⭐️⭐️ — TUI-клиент для Bluesky. Экспериментально.
• tuistash ⭐️ — TUI для Logstash. Не развивается.
• tuptime ⭐️⭐️ — Аналог `uptime` с историей перезагрузок.
• tut ⭐️ — Клиент Mastodon. Уступает `toot`.
• twitch-tui ⭐️⭐️ — Чат Twitch в терминале. Для стримеров.
• typeinc ⭐️ — Тренажёр печати. Устарел на фоне `ttyspy`.
• typespeed ⭐️ — Тест скорости печати. Без визуализации.
• typioca ⭐️ — Ещё один тренажёр печати. Нет уникальных фич.
• tz ⭐️ — Выбор часового пояса. Избыточен для современных систем.
• tzupdate ⭐️ — Автоматическое обновление часового пояса по IP.

---

U

• ugm ⭐️ — Просмотр UNIX-пользователей и групп. Устарел.
• updo ⭐️⭐️ — Мониторинг аптайма с уведомлениями. Альтернатива: Netdata.
• uuinfo ⭐️ — Генератор UUID/ULID. Для тестирования.

---

V

• viddy ⭐️⭐️⭐️⭐️ — Модернизированный `watch` с историей и пагинацией.
  • *GitHub stars*: ★★★☆ (4k).
• vignore ⭐️ — Просмотр игнорируемых файлов. Уступает `.gitignore`-плагинам.
• vim ⭐️⭐️⭐️⭐️⭐️ — Легендарный редактор. Базовый навык для разработчиков.
  • *GitHub stars*: ★★★★★ (31k+).
• visidata ⭐️⭐️⭐️⭐️ — Работа с CSV, JSON в виде таблиц. Для аналитики.
  • *GitHub stars*: ★★★☆ (7k).
• vscli ⭐️ — Запуск VSCode проектов. Нет уникальных преимуществ.
• vtop ⭐️⭐️ — Графический `top`. Уступает `btop`.

---

W

• w3m ⭐️ — Консольный браузер. Устарел.
• weechat ⭐️⭐️⭐️⭐️ — Чат для IRC/Matrix. Мощная кастомизация.
• wg-cmd ⭐️⭐️ — TUI для WireGuard. Для сетевых администраторов.
• wget ⭐️⭐️⭐️⭐️⭐️ — Стандарт для загрузки файлов. Незаменим.
• wiki-tui ⭐️⭐️⭐️ — Поиск в Wikipedia. Быстро, но минималистично.
• wiper ⭐️ — Очистка диска. Лучше использовать `ncdu`.
• wireman ⭐️ — TUI для gRPC. Экспериментальный.
• wordgrinder ⭐️ — Процессор для текста. Устаревший интерфейс.
• wtf ⭐️ — Dashboard для личной информации. Мало интеграций.

---

X

• xh ⭐️⭐️⭐️⭐️ — Удобная альтернатива `curl`. Подсветка JSON.
  • *GitHub stars*: ★★★☆ (14k).
• xplr ⭐️⭐️⭐️ — Файловый менеджер с плагинами. Конкурирует с `nnn`.

---

Y

• yai ⭐️⭐️ — ИИ-помощник для команд. Уступает `aichat`.
• yazi ⭐️⭐️⭐️⭐️ — Быстрый файловый менеджер на Rust. Асинхронный ввод-вывод.
  • *GitHub stars*: ★★★☆ (6k).
• youplot ⭐️⭐️ — Построение графиков в терминале. Для быстрой визуализации.
• youtube-dl ⭐️⭐️⭐️⭐️ — Легендарный загрузчик видео. Вытесняется `yt-dlp`.
• youtube-tui ⭐️⭐️ — YouTube в терминале. Только просмотр, нет загрузки.
• yr ⭐️ — Погода в терминале. Нет подробного прогноза.
• yt-dlp ⭐️⭐️⭐️⭐️⭐️ — Форк `youtube-dl` с улучшениями. Совместим с современными сайтами.
  • *GitHub stars*: ★★★★★ (56k+).

---

Z

• zeit ⭐️ — Трекер времени. Без интеграций с календарями.
• zeitfetch ⭐️ — Информация о системе. Уступает `neofetch`.
• zellij ⭐️⭐️⭐️⭐️ — Мультиплексор с вкладками и плагинами. Конкурент Tmux.
  • *GitHub stars*: ★★★☆ (15k).
• zenith ⭐️⭐️⭐️ — Мониторинг ресурсов. Удобный интерфейс.
• zoxide ⭐️⭐️⭐️⭐️⭐️ — Умная навигация по директориям. Использует частоту посещений.
  • *GitHub stars*: ★★★★★ (14k).
• zrok ⭐️ — P2P-сервис. Недоработанный функционал.

---

Топ-5 по объективному рейтингу

1. bat (42k+ ★)
2. yt-dlp (56k+ ★)
3. vim (31k+ ★)
4. aria2 (32k+ ★)
5. zoxide (14k+ ★)

---

Примечания:

• Рейтинг полезности: ● 1–3 — нишевые или ограниченные по функционалу утилиты; ● 4–5 — Must-have для большинства пользователей.
• Объективный рейтинг отсутствует, если проект:
  • Молодой (меньше 1k ★).
  • Нет данных (лицензия, приватный репозиторий).
  • Нет активности разработки (более 2 лет).
• Для DevOps/SRE приоритетны: `age`, `aria2`, `btop`, `topgrade`.

Проверьте полную версию списка [здесь](https://github.com/topics/terminal-tools). Обновление раз в месяц.

Или тут Или тут.

А вот дополнительный еще рейтинг:

Топ-15 терминальных утилит
Рейтинг основан на полезности (⭐), популярности (GitHub stars) и функциональности.

---

1. `bat` ⭐️⭐️⭐️⭐️⭐️
   Современная замена `cat` с подсветкой синтаксиса и навигацией. Незаменим для чтения кода и логов.
   *GitHub stars*: ★★★★★ (42k+).

2. `yt-dlp` ⭐️⭐️⭐️⭐️⭐️
   Продвинутый загрузчик видео с поддержкой YouTube, Twitch и 1000+ сайтов.
   *GitHub stars*: ★★★★★ (56k+).

3. `vim` ⭐️⭐️⭐️⭐️⭐️
   Легендарный текстовый редактор с бесконечной кастомизацией. Для кода, конфигов и больших файлов.
   *GitHub stars*: ★★★★★ (31k+).

4. `aria2` ⭐️⭐️⭐️⭐️⭐️
   Мультипоточный загрузчик с поддержкой торрентов и HTTP/FTP. Максимальная скорость для больших файлов.
   *GitHub stars*: ★★★★★ (32k+).

5. `zoxide` ⭐️⭐️⭐️⭐️⭐️
   Умная навигация по директориям. Учит ваши привычки и ускоряет доступ к часто используемым путям.
   *GitHub stars*: ★★★★★ (14k+).

6. `age` ⭐️⭐️⭐️⭐️⭐️
   Простое и надёжное шифрование файлов. Стандарт для передачи секретов в DevOps.
   *GitHub stars*: ★★★★☆ (7k+).

7. `btop` ⭐️⭐️⭐️⭐️
   Мониторинг ресурсов системы (CPU, RAM, сеть) с красивым интерфейсом и кастомизацией.
   *GitHub stars*: ★★★★☆ (10k+).

8. `curl` ⭐️⭐️⭐️⭐️⭐️
   Инструмент для работы с HTTP-запросами, тестирования API и скачивания данных.
   *GitHub stars*: Не учитывается (входит в coreutils).

9. `tmux` ⭐️⭐️⭐️⭐️⭐️
   Терминальный мультиплексор с сессиями, окнами и вкладками. Для параллельной работы с несколькими задачами.
   *GitHub stars*: ★★★★★ (30k+).

10. `tig` ⭐️⭐️⭐️⭐️
    TUI для просмотра истории Git. Идеален для анализа коммитов и веток.
    *GitHub stars*: ★★★★☆ (12k+).

11. `htop` ⭐️⭐️⭐️⭐️
    Интерактивный мониторинг процессов. Удобнее стандартного `top`.
    *GitHub stars*: ★★★★☆ (12k+).

12. `fzf` ⭐️⭐️⭐️⭐️⭐️
    Fuzzy-поиск для файлов, истории команд и всего, что можно отобразить в терминале.
    *GitHub stars*: ★★★★★ (57k+).

13. `delta` ⭐️⭐️⭐️⭐️
    Красивое отображение diff-ов Git с подсветкой синтаксиса.
    *GitHub stars*: ★★★★☆ (11k+).

14. `zellij` ⭐️⭐️⭐️⭐️
    Современный мультиплексор с панелями и плагинами. Конкурент `tmux`.
    *GitHub stars*: ★★★★☆ (15k+).

15. `topgrade` ⭐️⭐️⭐️⭐️
    Обновление всех пакетов и настроек одной командой (apt, brew, npm, cargo и т.д.).
    *GitHub stars*: ★★★★☆ (8k+).

---

Почему они в топе?

• Универсальность: Каждая утилита закрывает ключевые потребности (работа с кодом, сетью, системами).
• Эффективность: Ускоряют рутинные задачи (например, `zoxide` вместо `cd` + `ls`).
• Поддержка сообщества: Высокий рейтинг GitHub гарантирует актуальность и безопасность.

Для кого:

• DevOps/SRE — `age`, `aria2`, `btop`.
• Разработчики — `bat`, `delta`, `tig`.
• Любители автоматизации — `topgrade`, `zoxide`.

_Список составлен на основе актуальных данных (июль 2024). Полный перечень утилит можно найти [здесь](https://github.com/topics/terminal-tools)._

Распределенное машинное обучение с помощью Bacalhau Bluesky Bot

Использование моделей машинного обучения стало проще, чем когда-либо!
Шон М. Трейси

22 января 2025

Оригинал: https://blog.bacalhau.org/p/distributed-ml-with-the-bacalhau
Бот: https://github.com/bacalhau-project/bacalhau-bluesky-bot

---

Некоторое время назад мы выпустили Bacalhau Bluesky Bot (профиль Bluesky). Мы подумали, что это будет интересный способ показать людям, насколько просто интегрировать существующие приложения и сервисы с сетью Bacalhau, а также дать возможность пользователям запускать задачи.

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

Что он делает?

В первой версии Bacalhau Bluesky Bot вы могли запускать задачи, отправляя команды, как в Bacalhau CLI. Например:

```
@jobs.bacalhau.org job run
```

Мы сделали это так, чтобы люди, знакомые с CLI, сразу понимали, что можно делать с помощью бота, а те, кто никогда не использовал CLI, могли познакомиться с Bacalhau, не настраивая всю сеть.

Теперь мы немного отошли от интерфейса CLI, чтобы показать более специализированные сценарии использования. Начиная с сегодняшнего дня, вы можете классифицировать любое изображение, отправив его Bacalhau Bluesky Bot с прикрепленной картинкой в посте. Bacalhau использует YOLO для обнаружения объектов на изображении и отправляет результат обратно — всё это занимает менее 30 секунд!

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

В принципе работы Bacalhau Bluesky Bot мало что изменилось, просто добавился код для обработки задач классификации и возврата результатов после их выполнения.

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

```
@jobs.bacalhau.org classify
```

Бот читает ваш пост, получает URL изображения и отправляет задачу в сеть Bacalhau Bot Network. Эта сеть ничем не отличается от обычной сети Bacalhau, за исключением того, что взаимодействовать с ней можно только через Bacalhau Bluesky Bot.

Бот загружает шаблонный файл `job.yaml`, который указывает контейнер для выполнения задачи, и передает переменные для загрузки вашего изображения и его классификации.

После загрузки YAML-файла он преобразуется в JSON и отправляется через API в оркестратор Bacalhau, который запускает задачу и возвращает ID задачи.

Оркестратор анализирует сеть и назначает задачу на любой доступный вычислительный узел.

Узел, получивший задачу, использует переменные окружения из `job.yaml`, чтобы загрузить изображение из CDN Bluesky, а затем применяет YOLO для классификации объектов на изображении.

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

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

Пока всё это происходит, Bacalhau Bluesky Bot отслеживает задачу и через 30 секунд использует возвращенный UUID, чтобы получить классифицированное изображение и метаданные из общего хранилища объектов.

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

Попробуйте сами!

Эти изменения уже доступны! Просто зайдите в Bluesky под своим аккаунтом и отправьте пост:

```
@jobs.bacalhau.org classify
```

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

Заключение

Мы создали Bacalhau Bluesky Bot, чтобы показать, насколько просто интегрировать продукты, приложения и платформы с Bacalhau. Если у вас есть идея, как можно использовать распределенные вычисления, дайте нам знать! Мы всегда рады услышать интересные и инновационные идеи, которые продвигают распределенные вычисления вперед!

Работает :)

@jobs.bacalhau.org classify

и даже так :)

Детали тут и примеры: https://habr.com/ru/companies/astralinux/articles/870074/

PS: A-Tune активно используется в китайской ОС OpenEuler и его российской версии OpenScaler, а теперь еще и Astra групп им интересуется.

Анализ статьи и утилиты A-Tune для оптимизации настроек ОС применительно к запуску кластера Trino

Нейроночки такое пишут, все можно не читать, а сразу переходить к делу и статье:

Статья на Habr посвящена утилите A-Tune, разработанной для автоматической оптимизации настроек операционной системы (ОС) под конкретные рабочие нагрузки. Утилита использует методы машинного обучения для анализа характеристик системы и подбора оптимальных параметров, таких как управление ресурсами CPU, памятью, дисковыми операциями и сетевыми настройками.

Основные возможности A-Tune:

1. Анализ и классификация рабочих нагрузок: A-Tune определяет тип нагрузки (например, CPU-intensive, I/O-intensive) и настраивает параметры ОС для максимальной производительности.
2. Автоматическая настройка параметров ОС: Утилита изменяет параметры ядра Linux, планировщиков, управления памятью и других подсистем.
3. Поддержка различных сценариев использования: A-Tune может быть полезна для баз данных, веб-серверов, виртуализации и других задач.

Применимость к кластеру Trino:

Trino (ранее PrestoSQL) — это распределенный SQL-движок для выполнения аналитических запросов на больших объемах данных. Его производительность зависит от:

• Оптимизации использования CPU и памяти.
• Эффективного управления сетевыми соединениями.
• Минимизации задержек при операциях ввода-вывода (I/O).

Потенциальная польза A-Tune для Trino:

1. Оптимизация CPU и памяти: A-Tune может настроить параметры ядра и планировщики для оптимального распределения ресурсов между узлами кластера.
2. Улучшение производительности I/O: Утилита может оптимизировать параметры файловой системы и дисковых операций, что важно для Trino, так как он активно работает с данными.
3. Сетевые настройки: A-Tune может улучшить производительность сети, что критично для распределенных запросов в кластере Trino.

Оценка эффективности:

• Потенциальный эффект: A-Tune может дать заметный прирост производительности, особенно если кластер Trino работает на “сырых” настройках ОС, которые не оптимизированы под конкретную нагрузку.
• Ограничения: Эффективность A-Tune зависит от корректности классификации нагрузки и точности подбора параметров. Для Trino, который имеет специфические требования к ресурсам, может потребоваться дополнительная ручная настройка.
• Тестирование: Для оценки реального эффекта рекомендуется провести тестирование на тестовом кластере Trino с использованием A-Tune и сравнить производительность до и после оптимизации.

Вывод:

Утилита A-Tune может быть полезной для оптимизации кластера Trino, особенно если настройки ОС не были ранее адаптированы под его нагрузку. Однако для достижения максимального эффекта рекомендуется сочетать использование A-Tune с ручной настройкой параметров, специфичных для Trino. Тестирование в реальных условиях поможет точно оценить потенциальный прирост производительности.

Или вот такой ответ в режиме рассуждений:

Анализ утилиты A-Tune для оптимизации настроек кластера Trino

Введение:
A-Tune — это утилита, использующая машинное обучение для оптимизации настроек операционной системы (ОС) на основе характеристик нагрузки. В этом анализе оценивается потенциальная эффективность A-Tune при оптимизации кластера Trino, распределенного движка SQL с конкретными требованиями к CPU, памяти, вводу-выводу и сетевым настройкам.

Основные соображения:

1. Точность классификации рабочих нагрузок:
   • A-Tune классифицирует рабочие нагрузки и применяет соответствующие оптимизации. Точность этой классификации критична для Trino, который может иметь уникальный профиль рабочей нагрузки. Если A-Tune может эффективно идентифицировать и оптимизировать для конкретных потребностей Trino, это может быть очень полезно.

2. Легкость интеграции:
   • Сложность интеграции A-Tune с Trino является важным фактором. Если настройка проста, это добавляет ценность; однако, обширная конфигурация могла бы нивелировать потенциальные выигрыши в производительности.

3. Сравнение с существующими инструментами:
   • Необходимо учитывать, предлагают ли A-Tune уникальные преимущества по сравнению с существующими инструментами оптимизации Trino или лучшими практиками. Если это так, A-Tune становится более привлекательным.

4. Метрики производительности и бенчмарки:
   • Конкретные данные о повышении производительности необходимы для оценки эффективности A-Tune. Бенчмарки, специфичные для рабочих нагрузок Trino, предоставили бы ценные сведения.

5. Случаи из практики и опыт пользователей:
   • Изучение случаев из практики или опыта пользователей с использованием A-Tune на подобных рабочих нагрузках может предоставить практические сведения о его реальной производительности.

6. Совместимость с ОС:
   • Подтверждение совместимости A-Tune с ОС, на которой работает Trino (обычно Linux), является критическим для его применимости.

7. Легкость использования:
   • Кривая обучения для использования A-Tune должна быть управляемой. Если для его использования требуется глубокое знание настройки ОС, он может не быть доступен для всех пользователей.

Заключение:

A-Tune может быть полезным инструментом для оптимизации кластеров Trino, автоматизируя настройки ОС. Однако его эффективность зависит от точности классификации рабочих нагрузок, легкости интеграции и масштаба улучшений производительности. Для оценки его полезности следует:

• Оценить точность A-Tune в обработке конкретных профилей рабочих нагрузок Trino.
• Оценить легкость настройки и обслуживания в среде Trino.
• Сравнить его преимущества с существующими инструментами оптимизации.
• Изучить доступные метрики производительности и случаи из практики.
• Убедиться в совместимости с подлежащей ОС.
• Рассмотреть удобство использования инструмента и кривую обучения.

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

А вы что думаете?

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

Умеет работать с файлами и картинками. Переводы делает очень хорошо.

Сеточка интересна своей реализацией режима рассуждений. Работает немного странно. Базовый язык в ней видимо английский. Если ей написать в этом режиме «что ты умеешь?», то будет примерно так: вы написали на русском языке, что ты умеешь? Я должна ответить…
Еще умеет искать в интернете, очень полезная опция.

Опция поиска в интернете

Оригинал: https://apachedolphinscheduler.substack.com/p/dolphinscheduler-and-seatunnel-vs

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

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

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

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

---

1. DolphinScheduler vs Apache Airflow

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

1. Распределенное планирование задач:
   • Поддержка распределенной архитектуры, способность обрабатывать крупномасштабное планирование задач.
   • Легкое масштабирование узлов задач, динамическое распределение ресурсов и балансировка нагрузки.
   • Высокая доступность, поддержка множества типов задач и сложных зависимостей между ними, что делает его идеальным для производственных сред уровня предприятия.

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

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

4. Интеграция с экосистемой больших данных:
   • Глубокая интеграция с экосистемами больших данных (например, Hadoop, Hive, Spark, Flink), поддержка множества типов задач (Shell, Python, SQL, MapReduce и т.д.).
   • Расширение возможностей интеграции данных через плагины.

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

Недостатки DolphinScheduler

• Ограниченная поддержка больших AI-моделей: В настоящее время отсутствует надежная поддержка планирования задач для AI и больших моделей, экосистема для инструментов машинного обучения находится на ранней стадии развития.

Преимущества Apache Airflow

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

2. Богатая экосистема плагинов:
   • Большое количество плагинов, поддерживаемых сообществом (300+ официальных плагинов), что решает разнообразные задачи интеграции и обработки данных.

3. Поддержка глобального сообщества:
   • Активное сообщество пользователей по всему миру, обширная документация и учебные ресурсы.

Недостатки Apache Airflow

1. Ограниченные возможности распределенного планирования:
   • Уступает DolphinScheduler в сценариях крупномасштабного планирования задач, часто возникают проблемы с производительностью.

2. Сложность конфигурации и управления:
   • Требует знания Python, что может привести к значительному объему кода при организации сложных рабочих процессов, менее дружелюбен для нетехнических пользователей.

---

2. SeaTunnel vs Apache NiFi

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

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

2. Легковесность и высокая производительность:
   • Оптимизированная реализация поддерживает высокую пропускную способность данных, превосходя NiFi по производительности.
   • Эффективное использование ресурсов для сложных задач синхронизации данных.

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

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

5. Обеспечение качества данных:
   • Возможность преобразования, проверки и очистки данных во время синхронизации, что гарантирует надежность данных.

Недостатки SeaTunnel

1. Конфигурация через файлы:
   • В настоящее время задачи определяются через конфигурационные файлы, что может быть сложнее для пользователей, привыкших к интерфейсам drag-and-drop.

2. Ограниченная возможность кастомизации:
   • По сравнению с архитектурой плагинов NiFi, разработка пользовательских плагинов в SeaTunnel более сложна.

Преимущества Apache NiFi

1. Графический интерфейс:
   • Интерфейс drag-and-drop для определения и управления потоками данных, что делает его удобным для нетехнических пользователей.

2. Расширяемость и гибкость:
   • Архитектура NiFi позволяет легко расширять и настраивать функции для удовлетворения различных потребностей интеграции и обработки данных.
   • Поддержка плагинов для интеграции пользовательских процессоров, задач отчетности и других компонентов.

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

Недостатки Apache NiFi

1. Более низкая производительность:
   • Уступает SeaTunnel в сценариях с высокой нагрузкой и задачами с низкой задержкой.

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

---

3. Итог

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

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

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

---

О Apache SeaTunnel

Apache SeaTunnel — это простая в использовании, высокопроизводительная распределенная платформа для интеграции данных, поддерживающая синхронизацию огромных объемов данных в реальном времени и способная стабильно и эффективно синхронизировать сотни миллиардов данных в день.

Присоединяйтесь к сообществу Apache SeaTunnel и способствуйте развитию открытого исходного кода!

• Официальный сайт
• GitHub
• Slack
• Twitter

Присоединяйтесь к нам сейчас! ❤️❤️

Оригинал: https://www.constellationr.com/blog-news/how-generative-ai-has-supercharged-future-work

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

Большинство отраслевых исследований подтверждают это. Например, крупное исследование недавно показало, что компании в странах, активно внедряющих ИИ, могут увеличить свой ВВП на 26% к 2035 году. Более того, то же исследование прогнозирует, что мировая экономика получит выгоду в размере ошеломляющих $15,7 трлн за счет доходов и экономии к 2030 году благодаря трансформационной силе ИИ. Для специалистов по знаниям или руководителей бизнеса внедрение генеративного ИИ открывает широкий спектр новых возможностей, помогая оставаться конкурентоспособными на постоянно меняющемся рынке, одновременно повышая эффективность, инновации и рост.

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

Генеративный ИИ, большие языковые модели, базовые модели, приложения ИИ и будущее работы

Реализация ценности генеративного ИИ при преодолении вызовов

На мой профессиональный взгляд, способность генеративного ИИ создавать полезный, впечатляюще синтезированный текст, изображения и другие типы контента практически без усилий на основе нескольких текстовых подсказок уже стала важной бизнес-возможностью, которую стоит предоставить большинству работников знаний. В моих исследованиях и экспериментах с этой технологией многие рабочие задачи выигрывают от увеличения скорости выполнения в 1,3–5 раз. Есть и другие, менее измеримые преимущества, связанные с инновациями, разнообразием ввода и альтернативными издержками. Генеративный ИИ также может предоставлять особенно ценные типы контента, такие как код или форматированные данные, которые обычно требуют значительного опыта и/или обучения для создания. Он также способен проводить углубленный анализ сложных, узкоспециализированных материалов, включая юридические документы и даже медицинские диагнозы.

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

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

1. Смещение данных: Генеративные модели ИИ работают только на основе данных, на которых они обучены, и если данные содержат встроенные предубеждения, модель будет их воспроизводить. Это может привести к непредвиденным последствиям, таким как сохранение нежелательных практик или исключение определенных групп людей.
2. Интерпретируемость моделей: Генеративные модели ИИ могут быть сложными, и их результаты трудно интерпретировать, что может затруднить для бизнеса понимание того, как было принято то или иное решение или рекомендация. Это отсутствие объяснимости может привести к недоверию или скептицизму, особенно в ситуациях с высокими ставками, хотя со временем эта проблема, вероятно, будет решена.
3. Киберугрозы: Как и любая технология, обрабатывающая и хранящая конфиденциальные данные, генеративные модели ИИ могут быть уязвимы для кибератак, таких как взломы, утечки данных, злонамеренные атаки или, что более коварно, отравление входных данных. Компании должны принимать соответствующие меры для защиты своих ИИ-систем и данных от этих рисков.
4. Юридические и этические соображения: Использование генеративного ИИ может вызывать юридические и этические вопросы, особенно если оно используется для принятия решений, влияющих на жизнь людей, таких как найм или кредитные решения. Компании должны убедиться, что их использование ИИ соответствует юридическим и этическим стандартам и не нарушает права на конфиденциальность или другие права. Некоторые генеративные ИИ-системы, используемые сегодня, могут нарушать законы о конфиденциальности, что уже привело к действиям со стороны таких стран, как Италия.
5. Чрезмерная зависимость от ИИ: Со временем чрезмерная зависимость от генеративных моделей ИИ может привести к утрате человеческого суждения и принятия решений, что может быть вредным в ситуациях, когда требуется вмешательство человека, но необходимые навыки уже утрачены. Компании должны найти правильный баланс между использованием ИИ и человеческой экспертизой.
6. Обслуживание и устойчивость: Генеративные модели ИИ требуют постоянного обслуживания и обновлений для сохранения эффективности, что может быть трудоемким и дорогостоящим. По мере масштабирования использования ИИ компании также должны обеспечить наличие ресурсов и инфраструктуры для поддержки своих ИИ-систем, особенно когда они начинают создавать собственные базовые модели для корпоративных знаний. Также важно следить за тем, чтобы ресурсоемкость больших языковых моделей не приводила к чрезмерному потреблению энергии.

Успех с универсальным ИИ на рабочем месте

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

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

1. Четкие руководящие принципы и политики ИИ: Установите четкие руководящие принципы и политики по использованию ИИ-инструментов, включая вопросы конфиденциальности данных, безопасности и этические аспекты. Убедитесь, что эти политики четко доведены до сотрудников и легко доступны.
2. Обучение и подготовка: Обеспечьте сотрудников всесторонним обучением и подготовкой по эффективному и безопасному использованию ИИ-инструментов. Это включает обучение самим технологиям и решениям, а также соответствующим юридическим и этическим аспектам, которые они должны соблюдать. Платформы цифровой адаптации также могут быть особенно полезны для ускоренного внедрения ИИ-инструментов на рабочем месте.
3. Структуры управления ИИ: Установите четкие структуры управления для контроля за использованием ИИ-инструментов в организации. Это включает назначение ответственности и выделение бюджета для контроля ИИ-систем, установление четких линий связи и обеспечение наличия соответствующих проверок и балансов.
4. Надзор и мониторинг: Установите процессы постоянного надзора и мониторинга ИИ-инструментов, чтобы убедиться, что сотрудники используют их эффективно и безопасно. Это включает мониторинг производительности ИИ-систем, соблюдение политик и руководящих принципов, обеспечение использования согласованных моделей по всей организации и мониторинг потенциальных предубеждений или этических проблем.
5. Сотрудничество и обратная связь: Поощряйте сотрудничество и обратную связь между сотрудниками, использующими ИИ-инструменты, а также между сотрудниками и руководством. Это включает создание каналов для обратной связи и предложений по улучшению, обмен лучшими практиками использования ИИ, а также формирование культуры сотрудничества и непрерывного обучения навыкам ИИ.
6. Создание четких этических принципов: Компании должны установить четкие этические принципы для использования ИИ-инструментов на рабочем месте, основанные на таких принципах, как прозрачность, справедливость и подотчетность. Эти принципы должны быть доведены до всех сотрудников, использующих ИИ-инструменты.
7. Проведение этических оценок воздействия: Перед внедрением ИИ-инструментов компании должны проводить этические оценки воздействия, чтобы выявить и устранить потенциальные этические риски и убедиться, что инструменты соответствуют ответственной практике, а также этическим принципам и ценностям компании.
8. Мониторинг предубеждений ИИ: Компании должны регулярно отслеживать предубеждения в ИИ-инструментах как на этапе разработки, так и после внедрения. Это включает мониторинг предубеждений в данных, используемых для обучения инструментов, а также в результатах, которые они производят.
9. Обеспечение прозрачности: Компании должны обеспечивать прозрачность в использовании ИИ-инструментов, включая то, как они работают, как принимаются решения и как используются данные. Это включает предоставление объяснений для решений, принимаемых ИИ-инструментами, и обеспечение их понятности для сотрудников и других заинтересованных сторон.
10. Соблюдение нормативных требований: Компании должны убедиться, что использование ИИ-инструментов соответствует всем соответствующим нормативным требованиям, включая законы о конфиденциальности данных и правила, связанные с дискриминацией и предубеждениями в портфеле ИИ-инструментов.

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

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

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

Большие языковые модели (LLM) особенно интересны в качестве основы для ИИ-инструментов на рабочем месте, поскольку они представляют собой мощные базовые модели, обученные на огромном объеме открытых текстовых данных. Поставщики инструментов на основе LLM, как правило, идут одним из нескольких путей: большинство из них строят свои решения на существующих проприетарных моделях, специально настроенных/оптимизированных для определенных поведений или результатов, или позволяют выбирать модель, что дает компаниям возможность использовать языковые или базовые модели, которые они уже проверили. Некоторые также выбирают промежуточный путь, начиная с известных, высокопроизводительных моделей, таких как GPT-4 от OpenAI, и добавляя к ним свои собственные улучшения.

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

• AI21’s Jurassic-2
• Anthropic’s Claude
• Cohere’s LLMs
• Google’s Pathways Language Model (PaLM)
• Hugging Face’s BLOOM
• Meta’s LLaMA
• NVIDIA’s NeMo
• OpenAI’s GPT-3.5 и GPT-4

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

Ведущие ИИ-инструменты для работы

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

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

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

• Bard — выход Google на рынок ассистентов знаний на основе LLM.
• ChatGPT — универсальный ассистент знаний, который запустил текущий бум генеративного ИИ.
• ChatSpot — ассистент по контенту и исследованиям от Hubspot для маркетинга, продаж и операций.
• Docugami — ИИ для управления бизнес-документами, использующий специализированную базовую модель для бизнес-документов.
• Einstein GPT — ассистент по контенту, аналитике и взаимодействию для платформы Salesforce.
• Google Workspace AI Features — Google добавил ряд генеративных ИИ-функций в свою платформу для повышения производительности.
• HyperWrite — помощник для бизнес-писательства, ускоряющий создание контента.
• Jasper for Business — умный создатель контента, который помогает сотрудникам оставаться в рамках бренда при создании внешнего контента.
• Microsoft 365 Copilot/Business Chat — ИИ-ассистент для создания контента и бизнес-чаты, работающие на основе контекстных данных пользователя.
• Notably — платформа для бизнес-исследований с поддержкой ИИ.
• Notion AI — еще одно бизнес-решение в популярной категории ассистентов по контенту и писательству.
• Olli — аналитические/BI-панели для предприятий, созданные с использованием ИИ.
• Poe by Quora — чат-бот-ассистент знаний, использующий ИИ-модели Anthropic.
• Rationale — инструмент для принятия бизнес-решений с использованием ИИ.
• Seenapse — инструмент для генерации бизнес-идей с поддержкой ИИ.
• Tome — ИИ-инструмент для создания презентаций PowerPoint.
• WordTune — универсальный помощник для писательства.
• Writer — ИИ-ассистент для писательства.

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

В будущих материалах об ИИ и будущем работы я буду исследовать вертикальные ИИ-решения на основе LLM/базовых моделей для юридической сферы, HR, здравоохранения, финансовых услуг и других отраслей/функций. Наконец, если у вас есть стартап в области ИИ для бизнеса, который a) в основном использует базовую модель в своей работе, b) имеет платящих корпоративных клиентов и c) вы хотели бы быть добавленным в этот список, пожалуйста, напишите мне. Вы также можете связаться со мной для брифингов по поставщикам ИИ на рабочем месте или консультаций для клиентов.

Перевод сделал DeepSeek v3

Утро Россия 1 – 19.12.2024 – Смотрим.ру

Обновлено 28 августа 2024 г., 10:08 по восточному времени

Лес Абенд — отставной ветеран American Airlines с 34-летним стажем, пытающийся вновь обрести страсть к пилотированию самолетов на нижних эшелонах — без помощи второго пилота.

Оригинал: https://www.flyingmag.com/jumpseat/replacing-airline-pilots-with-ai

Традиционные кабины пилотов претерпевают трансформационные изменения.

2 мая на авиабазе Эдвардс в Калифорнии министр ВВС США Фрэнк Кендалл поднялся на борт испытательного F-16, получившего название VISTA (Variable In-Flight Simulator Test Aircraft – Многоцелевой самолет-тренажер с изменяемыми параметрами полета), оснащенного платформой искусственного интеллекта. Министр Кендалл и пилот-испытатель на заднем сиденье наблюдали за полетом, не прикасаясь к органам управления, в то время как другой F-16, управляемый человеком, имитировал воздушный бой с VISTA.

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

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

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

За девять лет полетов на Boeing 777 я всегда поражался тому, насколько стабильно автоматика выполняла плавную посадку самолета, особенно выравнивание и приземление. Из-за негласного соперничества между моими навыками и возможностями машины я редко позволял системе автоматической посадки завершить свою работу до самой бетонной полосы, если только погодные условия не диктовали иного. Это были отношения любви/ненависти.

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

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

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

F-16 VISTA развивал свой генеративный ИИ для маневрирования в воздушном бою как с помощью данных, полученных на специально оборудованных симуляторах, так и с самого самолета. Помимо этой информации, я уверен, что ВВС держат проект в строжайшей тайне. Но я просто сделаю безопасное предположение, что галлюцинации исключены из уравнения.

Искусственный общий интеллект (ИОИ или AGI) — это концепция технологии, которой большинство боится. Для тех, кто моего возраста, ИОИ — это причина, по которой персонаж стрелка Юла Бриннера из фильма “Мир Дикого Запада” 1973 года действует убийственно, выходя за рамки своего человеческого программирования. Но эта фаза технологии в основном теоретическая. Компьютеры пока не способны развивать свой собственный интеллект или личность вне данных, которые были введены или извлечены.

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

Когда я перешел на Boeing 767 с Jurassic Jet (B-727), самолета, который все еще управлялся с помощью шкивов, тросов и капризного автопилота, идея управления машиной с помощью переключателей на верхней панели была чужда моему существу. Однажды во время тренировки на симуляторе я взбунтовался и отключил автопилот, выразив свое недовольство нашему проверяющему. Я убедил его позволить мне с честью выполнить посадку на одном двигателе собственными руками, пообещав с этого момента соблюдать протокол автоматизации авиакомпании. В конце концов, я поддался технологии, но это была борьба.

В качестве примера использования ИИ в кабине пилота авиалайнера рассмотрим следующий сценарий: рейс XYZ находится в 30 минутах от прибытия в международный аэропорт имени Джона Ф. Кеннеди (KJFK). Сообщается, что RVR (Дальность видимости на ВПП) находится на минимальном уровне. Если заход на посадку выполнен, и необходим уход на второй круг, делает ли самолет еще одну попытку или следует на запасной аэродром по плану полета или куда-либо еще?

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

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

В июле 1989 года капитан Al Haynes из United Airlines, управлявший DC-10, знаменито скоординировал один из самых значительных моментов, связанных с управлением ресурсами экипажа. Когда у самолета произошла катастрофическая, нелокализованная поломка двигателя после того, как диск вентилятора отделился от двигателя № 2 (центрального), перерезав все гидравлические линии, самолет можно было контролировать только с помощью дифференциальной тяги. Из 296 пассажиров и членов экипажа на борту 184 выжили после «невозможной посадки» в Су-Сити, штат Айова.

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

Двадцать лет спустя рейс 1549 US Airways приземлился на реку Гудзон после того, как стая гусей попала в оба двигателя на относительно небольшой высоте, что привело к двойному отказу двигателей. По моей оценке, ИИ мог бы создать отвлечение, которое могло бы помешать быстрым решениям и действиям, предпринятым капитаном Чесли «Салли» Салленбергером и вторым пилотом Джеффри Скилзом.

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

ПС: Фуф, пилоты спят спокойно :) замены в горизонте не видно, только контуры 😀