Big Data *

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

«Широкие» таблицы

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

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

Задача: быстро выполнять агрегирующие запросы (JOIN, GROUP BY, COUNT) по десяткам миллионов строк в офлайновых сценариях на Big Data‑платформе. Мы сравнили три подхода: Parquet + Impala в экосистеме CDH, MPP‑движок Greenplum и MPP‑СУБД StarRocks. В единой тестовой среде (SAD ~7 млн, ITEM ~3 млн записей) выполнили серию запросов JOIN + GROUP BY + ORDER BY и замерили суммарное время 10 прогонов. Показано, что внедрение MPP заметно ускоряет аналитику (типично 1–2 с на запрос), при этом StarRocks в среднем немного обходит Greenplum. В статье — методика, параметры развертывания, нюансы импорта из Oracle (CloudCanal) и сводные метрики.

Это перевод классной статьи с детальным обзором архитектур главных опенсорсных LLM: очень структурировано, доходчиво и с изумительными картиночками. И такой обзор просто обязан быть на русском языке. Поговорим про DeepSeek V3/R1, OLMo 2, Gemma 3, Mistral Small 3.1, Llama 4, Qwen3, SmolLM3, Kimi K2, GPT-OSS, Grok 2.5, GLM-4.5, Qwen3-Next.

Ну а дальше слово автору:

Прошло семь лет с момента разработки оригинальной архитектуры GPT. На первый взгляд, оглядываясь назад на GPT-2 (2019) и вперед на DeepSeek-V3 и Llama 4 (2024-2025), можно удивиться тому, насколько структурно похожими остаются эти модели.

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

Близкая планета вызывает вспышки на звезде (Close-in planet induces flares on its host star)Authors: Ekaterina Ilin et al.Comments: 23 pages, 7 figures, 3 tables. Submitted to Nature 

Наблюдения на TESS и CHEOPS показали, что у молодого G-карлика HIP 67522, вокруг которого обращаются две планеты на низких орбитах, происходят вспышки, вызванные магнитным взаимодействием с одной из планет.

Вертикальная структура и динамика диска Галактики (Vertical Structure and Dynamics of a Galactic Disk)Authors: Chanda J. Jog Comments: 223 pages, 35 figures, 379 references. Invited review for Physics Reports  Большой обзор по структуре и физике галактического диска. На удивление мало формул (с полсотни, и больше половины из них - в 4м разделе), зато много полезных графиков. Приведено много данных наблюдений и разъяснены основные процессы, отвечающие за формирование структуры диска.

Сравнение ClickHouse и StarRocks: архитектура и функциональность, типы join и модели данных (широкая таблица vs звезда), конкурентность, частые обновления (Primary Key, Merge‑on‑Read), администрирование и онлайн‑масштабирование. Приводим результаты бенчмарков SSB и TPC‑H, а также тесты загрузки (GitHub dataset). Все тестовые данные и конфигурации актуальны на 2022 год. Если вам интересно, воспроизведите эксперименты по актуальным инструкциям проектов и поделитесь результатами и замечаниями — это поможет уточнить выводы и обновить сравнение.

Говоря о серьезных кластерах в компаниях, нам часто приходится взаимодействовать со сторонними отделами и их данными. И зачастую, когда речь идет об ad-hoc, самый эффективный инструмент - Trino. Он удобен тем, что в платформе данных можно добавить каталог, который позволит по сути избежать настройки коннекшена для конечного пользователя. Просто в запросе указываешь название каталога данных и трино сам понимает, что нужно взять данные со сторонней базы данных. Но все меняется, когда выразительности SQL нам перестает хватать для выполнения поставленных задач и мы переходим в Spark. Точнее, менялось. С релизом Spark 3.0 появилась возможность взаимодействовать с внешними источниками так же просто, как в Trino.

Одним из самых важных навыков любого специалиста по данным или ML инженера является умение извлекать информативные признаки из исходного набора данных. Этот процесс называемый feature engineering (инженерия признаков), — одна из самых полезных техник при построении моделей машинного обучения.

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

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

Разумеется, feature engineering — это времязатратный, креативный и нередко утомительный процесс, требующий экспериментов и опыта.

Недавно я наткнулся на интересный инструмент — Upgini. Следуя тренду на использование Large Language Models (LLM), Upgini применяет GPT от OpenAI, чтобы автоматизировать процесс feature engineering для ваших данных.

Подробнее о python библиотеке Upgini можно почитать на GitHub странице проекта. У проекта уже 345 звездных оценок, что является показателем востребованности и полезности функционала.

👉 GitHub - upgini/upgini: Data search library for Machine Learning

Привет! Этот пост — перевод очень хардовой статьи про внутренности vLLM и того, как устроен инференс LLM. Переводить было сложно из-за англицизмов и отсутствия устоявшегося перевода многих терминов, но это слишком классная статья, и она обязана быть на русском языке! А дальше — слово автору:

От paged attention, непрерывного батчинга, кэширования префиксов , specdec и т.д. — до мульти-GPU и мультинодового динамического сервинга LLM под нагрузкой.

В этом посте я постепенно представлю все основные системные компоненты и продвинутые функции, которые составляют современную систему инференса LLM с высокой пропускной способностью. И детально разберу, как внутри работает vLLM.

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

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

В этой статье мы детально рассмотрим поведение аналитических движков при выполнении отдельного TPC-DS запроса на одном узле.

Это глубоко технический текст, в котором мы увидим, как (1) три родственных движка (Impala, StarRocks и Doris) с трудом справляются с конкурентной нагрузкой, (2) разработчики StarRocks и Doris затачивают дефолты своих движков под бенчмарки, (3) Trino реализует эффективный шедулер запросов, но имеет ряд дефектов, ухудшающих производительность, (4) Presto строит хорошие планы запросов, но демонстрирует катастрофически плохую производительность из-за отсутствия буквально одной фичи. Ну а победит, конечно, наш движок CedrusData.

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

1. Анализ рабочей нагрузки и требований
2. Разработка схемы данных
3. Настройка хостовых машин
4. Настройка конфигурации Cassandra
5. Настройка топологии кластера
= ВЫ НАХОДИТЕСЬ ЗДЕСЬ =
6. Подключение Prometheus Cassandra Exporter
7. Подключение Prometheus Node Exporter
8. Вывод всех метрик в Grafana
9. Проведение нагрузочного тестирования
10. Дополнительный тюнинг по результатам теста

В этой части мы возьмём простой советский...

Данные без информации — это просто цифры. Чтобы они «заговорили», их нужно извлечь и преобразовать. Для этого существуют ETL‑системы, а для анализа данных и визуализации — BI и Data Science.

Сегодня бизнес выбирает между тремя классами ETL-решений...

LangChain или LangGraph? Какой фреймворк для ии-агентов выбрать? А может быть LangSmith? Или LangFuse? LangFlow? Если вы сходу не отличаете все эти Lang-что-то там между собой или просто хочется побольше узнать о внутренностях LangChain и LangGraph, то добро пожаловать в эту статью, которую мне хотелось сделать фундаментальной, чтобы ответить сразу на все возникающие вокруг LangChain вопросы.

Поговорим про архитектурные различия между LangChain и LangGraph, их подходы, посмотрим как это выглядит в коде, поищем лучшие точки применения и взглянем на сформированную экосистему вокруг.

Когда работаешь в B2B, быстро понимаешь: выигрывает не тот, кто «продает коробку», а тот, кто помогает клиенту зарабатывать больше и тратить меньше. Маркетинг здесь предельно прагматичен: сперва — понять реальные боли и ограничения целевого рынка, затем — убрать их так, чтобы ключевые метрики клиента пошли вверх. Наш рынок — компании, где трудозатраты и управляемость персонала напрямую бьют по марже. А значит, наша задача — не слежка за временем ради галочки, а повышение прибыльности за счет гибкого управления персоналом.

Именно поэтому мы прошли путь от «учета ради контроля» к «управлению ради эффективности». Мы начали с прозрачной фиксации явок и автоматизации табелей — там, где деньги утекали из-за ошибок, переработок и человеческого фактора. Но запрос бизнеса быстро изменился: дефицит кадров, колебания спроса, рост издержек. Ответом стала WFM-логика: прогноз нагрузки, шаблоны под производственный план, биржа смен, распределение смен по навыкам и ограничениям ТК.

В гонке за следующей волной «умных» систем большие языковые модели (LLM) берут на себя неожиданные роли. Одна из самых интересных — использовать такие модели как «судей» для оценки других моделей. Подход уже экономит командам массу ручной работы, но остаются вопросы: способен ли LLM уловить каждую тонкую ошибку? Что происходит в ситуациях, где критичны человеческая интуиция или глубокая предметная экспертиза?

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

С распространением сценариев real-time аналитики, lakehouse & modern BI всё чаще сталкиваются две флагманские аналитические СУБД: ClickHouse и StarRocks. Одна из ключевых конкурирующих битв ведётся не на маркетинговом поле, а в производительности, гибкости архитектур и удобстве поддержки сложных аналитических схем.

ClickHouse, будучи зрелым и широко используемым решением, зарекомендовал себя как очень быстрый колонковый движок, оптимизированный для агрегаций, фильтров и чтения узкого поднабора колонок из огромных объёмов данных. ClickHouse+2Instaclustr+2 Он эффективен в задачах логов, телеметрии, веб-аналитики и других OLAP-нагрузках, где схемы часто «расстилаются» — с минимальным числом джоинов и высокой степенью денормализации. Decube+2Wikipedia+2

Однако подход ClickHouse — оптимизация работы с плоскими таблицами и минимизация связанных таблиц — становится ограничением, когда бизнес-сценарии требуют моделирования звёздной схемы (fact + dimension) и выполнения динамических запросов с join’ами. В таких случаях ClickHouse часто вынужден либо смягчать нагрузку через ETL денормализацию, либо сталкиваться с трудоёмкими запросами. CelerData+2StarRocks+2

Вот где StarRocks начинает оспаривать лидерство. Он предлагает архитектуру, ориентированную на эффективные join и агрегации “на лету”, поддерживая материализованные представления (MV), которые автоматически обслуживаются и подменяются при выполнении запросов. DZone+3StarRocks+3StarRocks+3 В бенчмарках StarRocks часто показывает преимущество: в тестах на SSB (набор из 13 запросов) StarRocks в среднем быстрее ClickHouse почти вдвое. StarRocks Docs+2CelerData+2

При пиковых нагрузках отчётные и аналитические системы сталкиваются с лавиной схожих агрегирующих запросов: растёт загрузка CPU и увеличиваются задержки. В StarRocks эту проблему решает Query Cache — кэширование промежуточных результатов агрегаций в памяти с их последующим переиспользованием. В реальных сценариях даёт 3–17× ускорение, работает для семантически эквивалентных запросов, перекрывающихся партиций и append-only данных. Внутри — лучшие практики, пример настройки и метрики диагностики.

Чтобы понять, какие технологии будут определять рынок завтра, компании опираются на прогнозы/отчёты аналитиков или анализируют патенты. Но есть источник, который часто опережает и патенты – научные публикации. Далее о том, как я проанализировала 134195 научных статей 2025 года, чтобы ответить на вопрос, на какие технологии делать ставку прямо сейчас.

Выпуск 448

Пределы космологии (The limits of cosmology)Authors: Joseph SilkComments: 23 pages, Gen Relativ Gravit 57, 127 (2025) 

Если вы думаете, что известный космолог-теоретик пишет про теорию, то вы ошибаетесь! Силк внезапно втопил за лунные проекты. И это не только низкочастотные радионаблюдения на другой стороне Луны, но и совершенно фантастические (очень дорого и сложно) проекты гравитационно-волновых детекторов (типа LIGO, Virgo) на Луне (там низкий сейсмический шум, и можно уйти на низкие частоты).

Радиопроекты могут быть реализованы в середине этого века. Гравволновые - точно нет. Но интересно, что Силк погружает все это в интересный и понятно описанный контекст космологических задач (отсюда и название статьи). Так что читать все равно интересно. Вот это и впрямь научная фантастика!

А еще… затронем ИИ и прочие захватывающие темы.

Поводом написания этой статьи послужил подслушанный диалог:

— А на чем у вас агенты написаны?

— У нас на MCP!

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

Именно это предлагаю и сделать в статье, а также замерить MCP, чтобы ответить на вечный вопрос: сколько сжирает MCP, подключать ли его вообще или и так сойдет?