Перевод: https://news.itsfoss.com/keith-chan-openeuler-summit/

openEuler — это не просто ОС, это платформа для создания различных ОС
Директор CNCF в Китае, Кит Чан, делится своим мнением о росте openEuler в области Cloud Native.
Абхишек

Подробнее тут: https://www.openeuler.org/en/
еще больше тут: https://www.openeuler.org/whitepaper/en/openEuler%20OS%20Technical%20Whitepaper_Innovation%20Projects_EN.pdf

Поскольку It’s FOSS внимательно следил за недавно завершившимся саммитом openEuler, мы представляем несколько бесед, которые проливают свет на openEuler и его вклад в open source.

Это третье из четырех интервью, подготовленных при поддержке openEuler. Четвертое интервью только в видео формате.

Кит Чан — директор по стратегическому планированию Linux Foundation APAC, директор CNCF в Китае и директор Hyperledger в Китае. Он делится своим мнением на недавно завершившемся саммите openEuler 2024.

В: В чем уникальная ценность openEuler в Cloud Native?

Прежде всего, поздравляю openEuler с тем, что экосистема становится все больше и больше. Мы говорим о Cloud Native уже около трех лет. Сочетание CNCF, Kubernetes и openEuler расширит возможности в различных областях благодаря встроенной поддержке openEuler в Kubernetes. Кроме того, он интегрируется со многими различными сценариями, такими как AI, Edge, Cloud, IoT. Они расширяют целую экосистему для Cloud Native разработчиков, поэтому, представьте, например, в AI, если я Cloud Native разработчик, я фактически развертываю PyTorch в различных сценариях. Встроенная поддержка PyTorch меня очень радует. В противном случае, если бы я настраивал PyTorch или Tensorflow, мне пришлось бы делать это самостоятельно. Поэтому использование openEuler и Kubernetes вместе намного лучше и проще для меня.

Q. openEuler интегрировался с CI/CD от CNCF, чтобы предложить встроенную верификацию, и уже подключены два проекта. Есть ли дальнейшие планы по этому сотрудничеству?

Это действительно очень интересно, потому что, когда мы говорим о CI/CD openEuler и проектах CNCF, это действительно хорошо. Это выдающаяся новость для Cloud Native разработчиков, потому что это предоставит им множество различных вариантов ОС. Кроме того, необходимость поддержки openEuler на различных архитектурах упрощает Cloud Native разработчикам использование различных вычислительных ресурсов. Это действительно важно для Cloud Native разработчиков. Это расширяет возможности, потому что сейчас (openEuler) доступен от различных поставщиков облачных услуг, поэтому вам очень легко загрузить эти (архитектурные) версии. Я думаю, что это действительно здорово, и мы очень рады видеть, что это происходит.

Q. По сравнению с прошлым годом, openEuler в этом году выпустила две версии, 24.03 и 24.09. Что вы считаете самым большим достижением и инновацией в openEuler в этом году?

В последней версии много хороших разработок. Например, улучшение производительности, масштабируемости, но самое главное — это AI Native OS. Это то, что ищет рынок, то, что ищет разработчик. Как я уже упоминал выше в примере, если я хочу развернуть PyTorch, потому что сейчас более 80% LLM используют PyTorch, в этом случае встроенная поддержка PyTorch в openEuler делает задачу намного проще. Таким образом, 8 AI Native OS — это действительно здорово, и я думаю, что это поможет многим компаниям, даже в разных отраслях, и облегчит им развертывание AI.

Q. Каков ваш взгляд на перспективы глобального развития openEuler? Каковы его основные конкурентные преимущества и ценность в его глобализации?

Мы много сотрудничаем в различных сценариях. Например, openEuler выступила с основным докладом на Open Source Summit Europe и рассказала об AI Cloud Native OS. Я думаю, что нам следует расширять сотрудничество и говорить о том, как дать возможность Cloud Native разработчикам и разработчикам по всему миру понять, что такое openEuler. Потому что openEuler — это не просто ОС, это платформа ОС для создания различных ОС. Я только что упомянул, что вы можете создать ОС для таких областей, как Cloud, AI, Edge, IoT и т. д. Я думаю, что openEuler готов к сотрудничеству с глобальными разработчиками, чтобы иметь больше участников по всему миру. Мы действительно ожидаем большего сотрудничества с openEuler. Таким образом, openEuler – это новая опция ОС для мира. Очень рад видеть 5-летний юбилей openEuler. Поздравляем!

ПС:
Его российская локализация: https://openscaler.ru
а тут подробно есть: https://openscaler.ru/wp-content/uploads/2023/06/Lichi_A4_44.pdf

Сбер, Личи-тех и Скала-Р активно участвуют в его развитии в России

А тут можно еще глубже поизучать как в целом жить с open source: https://stepik.org/course/212389/promo

Перевод: https://www.pracdata.io/p/the-rise-of-single-node-processing

Введение

В 2024 году наблюдается растущий интерес к одноузловым системам обработки данных. Инструменты вроде DuckDB, Apache DataFusion и Polars привлекли внимание сообщества и стали невероятно популярными. Этот тренд — не просто технологический прогресс, а переосмысление подходов к аналитике данных.

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

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

---

Переосмысление «больших данных»

Последнее десятилетие компании активно внедряли стратегии big data, инвестируя в распределённые системы вроде Hadoop и Spark. Однако исследования показывают, что большинству компаний «большие данные» не нужны.

Итоги анализа:

• Jordan Tigani (основатель Google BigQuery): медианный объём данных у активных пользователей BigQuery — менее 100 ГБ.
• Исследование 500 млн запросов Amazon Redshift:
  • 99% обрабатывали менее 10 ТБ данных;
  • 90% сессий работали с менее чем 1 ТБ;
  • 98% таблиц содержат меньше миллиарда строк.

Вывод: Для 90% запросов достаточно одноузловых систем вместо распределённых (Spark, Trino, Athena).

---

Паттерны рабочих нагрузок и старение данных

1. Эффект старения данных
Доступ к данным резко сокращается со временем:

• Горячие данные (0–48 часов): обработка ETL-пайплайнами.
• Тёплые данные (2–30 дней): основа аналитических запросов.
• Холодные данные (30+ дней): редко запрашиваются (сохранены для истории или аудита).

Исследование Meta и eBay подтверждает: 95% обращений к данным происходят в первые 48 часов. В «золотой» аналитической зоне 95% запросов выполняются в течение 30 дней.

2. Правило 90/10
90% рабочих нагрузок приходится на 10% данных (за 30 дней). Даже при хранении данных год, аналитики в основном работают с последними 30 днями.

---

Эволюция оборудования: масштабирование вверх вместо распределения

Рост возможностей одноузловых систем:

• В 2006 году (эпоха Hadoop) серверы имели 1 CPU и 2 ГБ RAM.
• Сегодня облачные инстансы (например, AWS EC2) предлагают 64+ ядер и 256+ ГБ RAM.

Экономика масштабирования:

• Стоимость крупных инстансов (например, m5.16xlarge) сопоставима с расходами на несколько мелких узлов (например, 8 × m5.2xlarge) при одинаковой мощности.

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

---

Производительность одноузловых систем
DuckDB, Apache DataFusion и другие движки используют:

• Векторизованное выполнение запросов;
• Параллелизм;
• Оптимизацию использования памяти.

Примеры роста скорости:

• Переход с Postgres на DuckDB дал ускорение в 4–200 раз (Vantage).
• DuckDB превзошёл коммерческие хранилища на TPC-DS до 300 ГБ (Fivetran).

---

Причины выбрать одноузловую обработку

1. Простота: Меньше сложности, чем в распределённых системах.
2. Эффективность: Реализация до 80% кода на C/C++ (против 10% в распределённых движках).
3. Совместимость: Интеграция с облачными хранилищами, языками программирования, BI-инструментами.

---

Ограничения

• Не все движки эффективно используют многоядерные CPU.
• Пропускная способность RAM/CPU может стать узким местом.
• Очень большие наборы данных (>1 ТБ) всё ещё требуют распределения.

---

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

Главный вывод: Выбирайте инструмент под конкретную задачу, а не следуйте трендам. Будущее — за балансом между мощью одноузловых систем и гибкостью распределённых решений.

---

Полный дословный перевод:

Введение

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

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

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

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

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

Переосмысление больших данных

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

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

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

Джордан Тигани, один из инженеров-основателей Google BigQuery, проанализировал шаблоны использования и обнаружил, что медианный размер хранилища данных среди активных пользователей BigQuery составляет менее 100 ГБ.

Ещё более показательным является анализ полумиллиарда запросов, выполненных в Amazon Redshift и опубликованных в статье:

• Более 99% запросов обработали менее 10 ТБ данных.
• Более 90% сеансов обработали менее 1 ТБ.

В статье также говорится, что:

• Большинство таблиц содержит менее миллиона строк, и подавляющее большинство (98%) — менее миллиарда строк. Большая часть этих данных достаточно мала, чтобы её можно было кэшировать или реплицировать.

Этот анализ показывает, что при пороговом значении для больших данных в 1 ТБ более 90% запросов находятся ниже этого порога.

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

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

Шаблоны рабочей нагрузки и быстрое устаревание данных

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

Выявляются два ключевых шаблона: эффект устаревания данных и правило 90/10 для аналитических рабочих нагрузок.

Эффект устаревания данных

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

• Активные данные (0-48 часов): в основном из конвейеров ETL.
• Теплые данные (2-30 дней): составляют большую часть аналитических запросов.
• Холодные данные (30+ дней): редко используются, но часто хранятся для соответствия требованиям или исторического анализа.

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

В нашем анализе озера данных петабайтного масштаба мы обнаружили, что необработанные данные остаются активными только в течение 48 часов, причем 95% доступа приходится на это время, в основном со стороны нисходящих конвейеров ETL. В зоне Analytics (Gold) активный период длится около 7 дней, и 95% запросов выполняются только в течение 30 дней.

Правило 90/10 для аналитических рабочих нагрузок

Этот эффект устаревания приводит к правилу 90/10 в аналитических рабочих нагрузках:

• Если общий активный и теплый период составляет 30 дней и приходится на 90% рабочих нагрузок, то, при годовом сроке хранения, более 90% рабочих нагрузок получают доступ менее чем к 10% данных.

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

Эволюция оборудования и переосмысление масштабирования вверх

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

Обоснование и мотивация стратегии масштабирования по горизонтали (scale-out), которая стала популярной с появлением Hadoop в середине 2000-х годов в области обработки данных, заключаются в необходимости объединения нескольких машин для решения проблем масштабирования, что позволяет эффективно обрабатывать большие наборы данных в разумные сроки и с приемлемым уровнем производительности.

Интегрируя несколько машин в распределенные системы, мы фактически создаем единый большой блок, объединяя ресурсы, такие как ОЗУ, ЦП, дисковое пространство и пропускную способность, в одну большую виртуальную машину.

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

В 2006 году, когда появился Hadoop MapReduce, первые инстансы AWS EC2 (m1.small) имели всего 1 ЦП и менее 2 ГБ ОЗУ. Сегодня облачные провайдеры предлагают инстансы с 64+ ядрами и 256 ГБ+ ОЗУ, что кардинально меняет ситуацию с возможностями одноузловой обработки.

Изучение эволюции сбалансированных инстансов EC2 с точки зрения памяти и ЦП (с соотношением 1:4) на протяжении многих лет выявляет экспоненциальный рост, поскольку эти инстансы со временем становятся все более мощными.

Экономика масштабирования вверх (Scale-Up) против масштабирования по горизонтали (Scale-Out)

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

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

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

Используя семейство инстансов m5 от AWS в качестве примера, независимо от того, масштабируетесь ли вы вверх с помощью одного инстанса m5.16xlarge или масштабируетесь по горизонтали с помощью восьми инстансов m5.2xlarge, цена за час останется той же.

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

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

Это поднимает критический вопрос:

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

Аргумент производительности для одноузловой обработки

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

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

Многочисленные тесты показывают эти улучшения производительности:

• Vantage сообщила, что при переходе с Postgres на DuckDB для анализа затрат на облако они увидели улучшение производительности в диапазоне от 4X до 200X.
• Тесты генерального директора Fivetran с использованием наборов данных TPC-DS показали, что DuckDB превосходит коммерческие хранилища данных для наборов данных размером менее 300 ГБ.
• Эксперимент с 1 миллиардом строк поддельных данных о заказах, сравнивающий DuckDB с Amazon Athena.

Почему стоит выбрать одноузловую обработку?

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

• Они значительно упрощают архитектуру системы, устраняя сложность распределенных систем. Это упрощение снижает эксплуатационные расходы, облегчает отладку и снижает порог входа для команд, работающих с данными.
• Они часто обеспечивают лучшее использование ресурсов. Без накладных расходов на сетевую связь и распределенную координацию больше вычислительной мощности можно выделить для фактической обработки данных. Эта эффективность напрямую приводит к экономии затрат и повышению производительности.
• Они предлагают отличную интеграцию с современными рабочими процессами обработки данных. Такие движки, как chDB и DuckDB, могут напрямую запрашивать данные из облачного хранилища, бесперебойно работать с популярными языками программирования и органично вписываться в существующие конвейеры обработки данных.
• Встраиваемая природа некоторых из этих движков обеспечивает бесшовную интеграцию с существующими системами — от расширений PostgreSQL, таких как pg_analytics и pg_duckdb, до различных современных инструментов Business Intelligence — расширяя аналитические возможности без нарушения установленных рабочих процессов.

Проблемы и ограничения

Хотя одноузловая обработка предлагает много преимуществ, важно признать её ограничения.

• Некоторые движки по-прежнему сталкиваются с проблемами полного использования всех доступных ядер ЦП на больших машинах, особенно по мере увеличения количества ядер. Пропускная способность иерархии памяти между ОЗУ и ЦП может стать узким местом для определенных рабочих нагрузок.
• При чтении из облачного хранилища, такого как S3, скорость передачи данных через одно соединение может быть ограничена, хотя это часто можно смягчить с помощью параллельных соединений и интеллектуальных стратегий кэширования. И, естественно, остаются рабочие нагрузки, включающие очень большие наборы данных, которые превышают доступную память и хранилище, требующие распределенной обработки.

Заключение

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

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

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

Спасибо автору ALIREZA SADEGHI и оригиналу: https://www.pracdata.io/p/the-rise-of-single-node-processing

перевод: DeepSeek R1 × SeaTunnel: Лидерство в революции интеллектуальной интеграции данных следующего поколения

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

Apache SeaTunnel — проект с открытым исходным кодом для интеграции данных, созданный в Китае и разрабатываемый в рамках глобального сотрудничества, — становится основным движком интеллектуальной обработки данных. Благодаря встроенной интеграции с LLM, прорывным возможностям работы с векторными данными и бесшовной интеграции с более чем 100 источниками данных, он переосмысливает возможности управления корпоративными данными.

Выпуск 2.3.7 стал поворотным моментом благодаря глубокой интеграции технологии DeepSeek LLM, возвестив эру обработки данных «под управлением LLM».

Почему SeaTunnel доминирует в интеграции данных в эпоху LLM?

Традиционные инструменты ETL сталкиваются с тремя критическими проблемами в эпоху LLM:

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

SeaTunnel преодолевает эти барьеры благодаря трем революционным возможностям:

···

1. Встроенная интеграция LLM

Усиление конвейеров данных, управляемых моделями
Модуль преобразования SeaTunnel теперь изначально интегрирован с DeepSeek и другими LLM, что позволяет напрямую вызывать модели для:

• Очистки текста и семантического улучшения
• Распознавания намерений
• Динамического создания правил

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

···

2. Векторный движок

Соединение LLM и хранилищ данных
Начиная с версии 2.3.6, SeaTunnel стал пионером в поддержке векторных баз данных (Milvus и др.), а версия 2.3.7 обеспечивает трехкратное повышение производительности обработки векторов.

Пример использования в бизнесе:
Платформы электронной коммерции теперь могут:

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

···

3. Мастерство работы с неструктурированными данными

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

···
Достижение экспоненциальной ценности: LLM + интеграция данных

Интеллект в реальном времени
На базе движка SeaTunnel Zeta:

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

Экосистема из более чем 160 коннекторов
Готовая интеграция с:

• Традиционными базами данных (MySQL, Oracle)
• Облачными платформами (S3, BigQuery)
• Сервисами SaaS (Salesforce, Zendesk)
• Платформами LLM (OpenAI, DeepSeek)

Встроенные возможности ИИ
Текущая версия 2.3.7 уже поддерживает:

• Преобразование LLM
• Операции встраивания

Запланированные функции:

• Поддержка пользовательских функций Python
• Усовершенствованные операторы для неструктурированных данных

···
DeepSeek + SeaTunnel: Реальное влияние

Схема внедрения в организациях

• Автоматическая маркировка данных
  Классификация отзывов о продуктах по категориям «Качество», «Доставка», «Обслуживание»
• Семантический механизм рекомендаций
  Сопоставление продуктов с использованием вложений поисковых запросов
• Автоматизация AI-Ops
  Создание диагностических отчетов из системных журналов (на 70% быстрее MTTR)
• Анализ настроений
  Количественная оценка моделей жалоб клиентов в чатах поддержки
• Мультимодальная обработка
  Извлечение ключевой информации из PDF-файлов/изображений посредством интеграции двоичных потоков

···
Дорожная карта: Где LLM встречается с инженерией данных

Амбициозная повестка дня сообщества включает:
🔮 Расширение векторной базы данных — интеграция с Pinecone
🤖 Автоматическая генерация ETL — создание правил на основе DeepSeek
🖥️ Бескодовая конфигурация LLM — визуальный конструктор конвейеров
🎓 Обучение пользовательских моделей — интегрированная платформа RLHF

···
SeaTunnel, самый быстрорастущий проект интеграции данных (более 8,3 тыс. звезд на GitHub), предлагает :

Делиться вариантами использования (WeChat: 18819063834) для отраслевых решений

···
Новая граница данных

В этом слиянии LLM и инженерии данных Apache SeaTunnel переосмысливает парадигмы интеграции. Будь то упрощение внедрения ИИ или ускорение трансформации предприятия, он становится швейцарским ножом для интеллектуальных конвейеров данных.

Перевод: 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. В противном случае, затраты времени и усилий могут не оправдать его использование.

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

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

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

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

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