ClickHouse уже не один: StarRocks показывает, что lakehouse-аналитика может быть проще и быстрее»
С распространением сценариев 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
Читать: https://habr.com/ru/articles/956334/
#ru
@big_data_analysis | Другие наши каналы
С распространением сценариев 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
Читать: https://habr.com/ru/articles/956334/
#ru
@big_data_analysis | Другие наши каналы
👍3
LLM в роли «судьи» vs. человеческая оценка: почему вместе — лучше
В гонке за следующей волной «умных» систем большие языковые модели (LLM) берут на себя неожиданные роли. Одна из самых интересных — использовать такие модели как «судей» для оценки других моделей. Подход уже экономит командам массу ручной работы, но остаются вопросы: способен ли LLM уловить каждую тонкую ошибку? Что происходит в ситуациях, где критичны человеческая интуиция или глубокая предметная экспертиза?
Реальность такова: человеческие ревьюеры по-прежнему обеспечивают уровень контекстного понимания, которому ИИ пока не соответствует. Поэтому вместо того чтобы противопоставлять методы, многие в индустрии приходят к связке «LLM-судья + человеческая оценка» как к наиболее эффективной комбинации. В этой статье разберём, что такое LLM-судья, как он соотносится с человеческой оценкой и почему гибридный подход имеет наибольший смысл.
Читать: https://habr.com/ru/articles/956374/
#ru
@big_data_analysis | Другие наши каналы
В гонке за следующей волной «умных» систем большие языковые модели (LLM) берут на себя неожиданные роли. Одна из самых интересных — использовать такие модели как «судей» для оценки других моделей. Подход уже экономит командам массу ручной работы, но остаются вопросы: способен ли LLM уловить каждую тонкую ошибку? Что происходит в ситуациях, где критичны человеческая интуиция или глубокая предметная экспертиза?
Реальность такова: человеческие ревьюеры по-прежнему обеспечивают уровень контекстного понимания, которому ИИ пока не соответствует. Поэтому вместо того чтобы противопоставлять методы, многие в индустрии приходят к связке «LLM-судья + человеческая оценка» как к наиболее эффективной комбинации. В этой статье разберём, что такое LLM-судья, как он соотносится с человеческой оценкой и почему гибридный подход имеет наибольший смысл.
Читать: https://habr.com/ru/articles/956374/
#ru
@big_data_analysis | Другие наши каналы
Как мы перешли от контроля рабочего времени сотрудников к оптимизации управления персоналом
Когда работаешь в B2B, быстро понимаешь: выигрывает не тот, кто «продает коробку», а тот, кто помогает клиенту зарабатывать больше и тратить меньше. Маркетинг здесь предельно прагматичен: сперва — понять реальные боли и ограничения целевого рынка, затем — убрать их так, чтобы ключевые метрики клиента пошли вверх. Наш рынок — компании, где трудозатраты и управляемость персонала напрямую бьют по марже. А значит, наша задача — не слежка за временем ради галочки, а повышение прибыльности за счет гибкого управления персоналом.
Именно поэтому мы прошли путь от «учета ради контроля» к «управлению ради эффективности». Мы начали с прозрачной фиксации явок и автоматизации табелей — там, где деньги утекали из-за ошибок, переработок и человеческого фактора. Но запрос бизнеса быстро изменился: дефицит кадров, колебания спроса, рост издержек. Ответом стала WFM-логика: прогноз нагрузки, шаблоны под производственный план, биржа смен, распределение смен по навыкам и ограничениям ТК.
Читать: https://habr.com/ru/articles/956692/
#ru
@big_data_analysis | Другие наши каналы
Когда работаешь в B2B, быстро понимаешь: выигрывает не тот, кто «продает коробку», а тот, кто помогает клиенту зарабатывать больше и тратить меньше. Маркетинг здесь предельно прагматичен: сперва — понять реальные боли и ограничения целевого рынка, затем — убрать их так, чтобы ключевые метрики клиента пошли вверх. Наш рынок — компании, где трудозатраты и управляемость персонала напрямую бьют по марже. А значит, наша задача — не слежка за временем ради галочки, а повышение прибыльности за счет гибкого управления персоналом.
Именно поэтому мы прошли путь от «учета ради контроля» к «управлению ради эффективности». Мы начали с прозрачной фиксации явок и автоматизации табелей — там, где деньги утекали из-за ошибок, переработок и человеческого фактора. Но запрос бизнеса быстро изменился: дефицит кадров, колебания спроса, рост издержек. Ответом стала WFM-логика: прогноз нагрузки, шаблоны под производственный план, биржа смен, распределение смен по навыкам и ограничениям ТК.
Читать: https://habr.com/ru/articles/956692/
#ru
@big_data_analysis | Другие наши каналы
От LangChain к LangGraph: детально разбираемся с фреймворками и всей Lang-экосистемой
LangChain или LangGraph? Какой фреймворк для ии-агентов выбрать? А может быть LangSmith? Или LangFuse? LangFlow? Если вы сходу не отличаете все эти Lang-что-то там между собой или просто хочется побольше узнать о внутренностях LangChain и LangGraph, то добро пожаловать в эту статью, которую мне хотелось сделать фундаментальной, чтобы ответить сразу на все возникающие вокруг LangChain вопросы.
Поговорим про архитектурные различия между LangChain и LangGraph, их подходы, посмотрим как это выглядит в коде, поищем лучшие точки применения и взглянем на сформированную экосистему вокруг.
Читать: https://habr.com/ru/articles/956940/
#ru
@big_data_analysis | Другие наши каналы
LangChain или LangGraph? Какой фреймворк для ии-агентов выбрать? А может быть LangSmith? Или LangFuse? LangFlow? Если вы сходу не отличаете все эти Lang-что-то там между собой или просто хочется побольше узнать о внутренностях LangChain и LangGraph, то добро пожаловать в эту статью, которую мне хотелось сделать фундаментальной, чтобы ответить сразу на все возникающие вокруг LangChain вопросы.
Поговорим про архитектурные различия между LangChain и LangGraph, их подходы, посмотрим как это выглядит в коде, поищем лучшие точки применения и взглянем на сформированную экосистему вокруг.
Читать: https://habr.com/ru/articles/956940/
#ru
@big_data_analysis | Другие наши каналы
⚡2
Low/No-Code ETL vs классический подход: что выбрать бизнесу
Данные без информации — это просто цифры. Чтобы они «заговорили», их нужно извлечь и преобразовать. Для этого существуют ETL‑системы, а для анализа данных и визуализации — BI и Data Science.
Сегодня бизнес выбирает между тремя классами ETL-решений...
Читать: https://habr.com/ru/companies/modusbi/articles/957212/
#ru
@big_data_analysis | Другие наши каналы
Данные без информации — это просто цифры. Чтобы они «заговорили», их нужно извлечь и преобразовать. Для этого существуют ETL‑системы, а для анализа данных и визуализации — BI и Data Science.
Сегодня бизнес выбирает между тремя классами ETL-решений...
Читать: https://habr.com/ru/companies/modusbi/articles/957212/
#ru
@big_data_analysis | Другие наши каналы
👍3
Развёртывание боевого кластера Cassandra. Часть 4
Это продолжение цикла, рассказывающего о практике развёртывания небольшого, но вполне производственного кластера Cassandra. В первой, второй и третьей частях мы продвинулись вперед вот по такому плану:
1. Анализ рабочей нагрузки и требований
2. Разработка схемы данных
3. Настройка хостовых машин
4. Настройка конфигурации Cassandra
5. Настройка топологии кластера
= ВЫ НАХОДИТЕСЬ ЗДЕСЬ =
6. Подключение Prometheus Cassandra Exporter
7. Подключение Prometheus Node Exporter
8. Вывод всех метрик в Grafana
9. Проведение нагрузочного тестирования
10. Дополнительный тюнинг по результатам теста
В этой части мы возьмём простой советский...
Читать: https://habr.com/ru/articles/957238/
#ru
@big_data_analysis | Другие наши каналы
Это продолжение цикла, рассказывающего о практике развёртывания небольшого, но вполне производственного кластера Cassandra. В первой, второй и третьей частях мы продвинулись вперед вот по такому плану:
1. Анализ рабочей нагрузки и требований
2. Разработка схемы данных
3. Настройка хостовых машин
4. Настройка конфигурации Cassandra
5. Настройка топологии кластера
= ВЫ НАХОДИТЕСЬ ЗДЕСЬ =
6. Подключение Prometheus Cassandra Exporter
7. Подключение Prometheus Node Exporter
8. Вывод всех метрик в Grafana
9. Проведение нагрузочного тестирования
10. Дополнительный тюнинг по результатам теста
В этой части мы возьмём простой советский...
Читать: https://habr.com/ru/articles/957238/
#ru
@big_data_analysis | Другие наши каналы
👍2
Бенчмарк lakehouse-движков, часть 1: StarRocks и Doris падают под нагрузкой, Presto аутсайдер, CedrusData быстрее всех
В этой статье мы детально рассмотрим поведение аналитических движков при выполнении отдельного TPC-DS запроса на одном узле.
Это глубоко технический текст, в котором мы увидим, как (1) три родственных движка (Impala, StarRocks и Doris) с трудом справляются с конкурентной нагрузкой, (2) разработчики StarRocks и Doris затачивают дефолты своих движков под бенчмарки, (3) Trino реализует эффективный шедулер запросов, но имеет ряд дефектов, ухудшающих производительность, (4) Presto строит хорошие планы запросов, но демонстрирует катастрофически плохую производительность из-за отсутствия буквально одной фичи. Ну а победит, конечно, наш движок CedrusData.
Хочу, чтобы подгорело
Читать: https://habr.com/ru/companies/cedrusdata/articles/955896/
#ru
@big_data_analysis | Другие наши каналы
В этой статье мы детально рассмотрим поведение аналитических движков при выполнении отдельного TPC-DS запроса на одном узле.
Это глубоко технический текст, в котором мы увидим, как (1) три родственных движка (Impala, StarRocks и Doris) с трудом справляются с конкурентной нагрузкой, (2) разработчики StarRocks и Doris затачивают дефолты своих движков под бенчмарки, (3) Trino реализует эффективный шедулер запросов, но имеет ряд дефектов, ухудшающих производительность, (4) Presto строит хорошие планы запросов, но демонстрирует катастрофически плохую производительность из-за отсутствия буквально одной фичи. Ну а победит, конечно, наш движок CedrusData.
Хочу, чтобы подгорело
Читать: https://habr.com/ru/companies/cedrusdata/articles/955896/
#ru
@big_data_analysis | Другие наши каналы
🆒2
Мультиагентный фреймворк CrewAI: разбор архитектуры и внутренностей
CrewAI — фреймворк интересный. Он похож на самый быстрый способ удивить своего босса: легкий, у него очень низкий порог входа, он по дизайну нацелен на мультиагентность и из него можно очень быстро собирать MVP с вау-эффектом. В статье поговорим о том как создавать агентов на фреймворке, что у них внутри, где фреймворк хорош, а куда брать его не нужно.
Мультиагентная система без подходящей задачи — это, как говорится, токены на ветер, поэтому мы сколотим банду агентов, которые нам будут анализировать arxiv-статьи про LLM и посмотрим как это работает.
Читать: https://habr.com/ru/articles/957384/
#ru
@big_data_analysis | Другие наши каналы
CrewAI — фреймворк интересный. Он похож на самый быстрый способ удивить своего босса: легкий, у него очень низкий порог входа, он по дизайну нацелен на мультиагентность и из него можно очень быстро собирать MVP с вау-эффектом. В статье поговорим о том как создавать агентов на фреймворке, что у них внутри, где фреймворк хорош, а куда брать его не нужно.
Мультиагентная система без подходящей задачи — это, как говорится, токены на ветер, поэтому мы сколотим банду агентов, которые нам будут анализировать arxiv-статьи про LLM и посмотрим как это работает.
Читать: https://habr.com/ru/articles/957384/
#ru
@big_data_analysis | Другие наши каналы
Наука для бизнеса: что внедрять завтра (анализ 134 195 научных работ 2025 года)
Чтобы понять, какие технологии будут определять рынок завтра, компании опираются на прогнозы/отчёты аналитиков или анализируют патенты. Но есть источник, который часто опережает и патенты – научные публикации. Далее о том, как я проанализировала 134195 научных статей 2025 года, чтобы ответить на вопрос, на какие технологии делать ставку прямо сейчас.
Читать: https://habr.com/ru/articles/956220/
#ru
@big_data_analysis | Другие наши каналы
Чтобы понять, какие технологии будут определять рынок завтра, компании опираются на прогнозы/отчёты аналитиков или анализируют патенты. Но есть источник, который часто опережает и патенты – научные публикации. Далее о том, как я проанализировала 134195 научных статей 2025 года, чтобы ответить на вопрос, на какие технологии делать ставку прямо сейчас.
Читать: https://habr.com/ru/articles/956220/
#ru
@big_data_analysis | Другие наши каналы
⚡2
Внутри vLLM: Анатомия системы инференса LLM с высокой пропускной способностью
Привет! Этот пост — перевод очень хардовой статьи про внутренности vLLM и того, как устроен инференс LLM. Переводить было сложно из-за англицизмов и отсутствия устоявшегося перевода многих терминов, но это слишком классная статья, и она обязана быть на русском языке! А дальше — слово автору:
От paged attention, непрерывного батчинга, кэширования префиксов , specdec и т.д. — до мульти-GPU и мультинодового динамического сервинга LLM под нагрузкой.
В этом посте я постепенно представлю все основные системные компоненты и продвинутые функции, которые составляют современную систему инференса LLM с высокой пропускной способностью. И детально разберу, как внутри работает vLLM.
Читать: https://habr.com/ru/articles/957748/
#ru
@big_data_analysis | Другие наши каналы
Привет! Этот пост — перевод очень хардовой статьи про внутренности vLLM и того, как устроен инференс LLM. Переводить было сложно из-за англицизмов и отсутствия устоявшегося перевода многих терминов, но это слишком классная статья, и она обязана быть на русском языке! А дальше — слово автору:
От paged attention, непрерывного батчинга, кэширования префиксов , specdec и т.д. — до мульти-GPU и мультинодового динамического сервинга LLM под нагрузкой.
В этом посте я постепенно представлю все основные системные компоненты и продвинутые функции, которые составляют современную систему инференса LLM с высокой пропускной способностью. И детально разберу, как внутри работает vLLM.
Читать: https://habr.com/ru/articles/957748/
#ru
@big_data_analysis | Другие наши каналы
⚡2