Greengage DB: новый open-source монстр MPP-аналитики. Конец эпохи Greenplum?*
Что, если Greenplum пережил перерождение?
Новый проект Greengage DB возвращает PostgreSQL в большую игру — теперь с авто-масштабированием, чистым ядром и реальной совместимостью.
Разбираемся, почему этот форк может стать «Linux для аналитики».
Читать: https://habr.com/ru/articles/954506/
#ru
@big_data_analysis | Другие наши каналы
Что, если Greenplum пережил перерождение?
Новый проект Greengage DB возвращает PostgreSQL в большую игру — теперь с авто-масштабированием, чистым ядром и реальной совместимостью.
Разбираемся, почему этот форк может стать «Linux для аналитики».
Читать: https://habr.com/ru/articles/954506/
#ru
@big_data_analysis | Другие наши каналы
👍1
Я «уволил» LLM с должности «мозга» проекта. И его производительность взлетела
Помните свой первый «вау‑эффект» от LLM?
Я помню. Возможность вести диалог, генерировать код, получать ответы на сложные вопросы — казалось, мы получили идеального партнера по мышлению.
Но эйфория быстро угасла когда я начал использовать LLM для реальных, долгосрочных задач: рефакторинга сложного кода, написания архитектурной документации, анализа бизнес‑задач. И здесь проявилась фундаментальная проблема — «забывание».
Читать: https://habr.com/ru/articles/954742/
#ru
@big_data_analysis | Другие наши каналы
Помните свой первый «вау‑эффект» от LLM?
Я помню. Возможность вести диалог, генерировать код, получать ответы на сложные вопросы — казалось, мы получили идеального партнера по мышлению.
Но эйфория быстро угасла когда я начал использовать LLM для реальных, долгосрочных задач: рефакторинга сложного кода, написания архитектурной документации, анализа бизнес‑задач. И здесь проявилась фундаментальная проблема — «забывание».
Читать: https://habr.com/ru/articles/954742/
#ru
@big_data_analysis | Другие наши каналы
Оптимизация источников данных для ML моделей
В этой статье хочется поделиться собственной методикой оптимизации источников данных для кредитного скоринга и представить ключевые результаты реальных замеров на российском рынке.
Читать: https://habr.com/ru/articles/954826/
#ru
@big_data_analysis | Другие наши каналы
В этой статье хочется поделиться собственной методикой оптимизации источников данных для кредитного скоринга и представить ключевые результаты реальных замеров на российском рынке.
Читать: https://habr.com/ru/articles/954826/
#ru
@big_data_analysis | Другие наши каналы
Книга: «Грокаем структуры данных»
Каждый разработчик знает, насколько важны структуры данных. Без них не обходится ни один серьезный проект, будь то оптимизация запросов, работа с Big Data или просто написание чистого и эффективного кода. Не зря же на собеседованиях постоянно спрашивают про деревья, хеш-таблицы и сложность алгоритмов!
Вы только приступили к изучению структур данных? Хотите освежить знания, полученные в ходе обучения? В этой книге нет заумной математики, скучных доказательств и абстрактной теории. Вместо этого — понятные объяснения, рабочие примеры и реальные кейсы, с которыми ежедневно сталкиваются разработчики. Вы узнаете, как с помощью правильных структур данных ускорить поиск, эффективнее управлять очередями задач или, например, оптимизировать хранение данных.
Книга построена по принципу «от простого к сложному»: начинается с базовых структур, таких как массивы и связанные списки, и постепенно переходит к более сложным — стекам, очередям, деревьям, хеш-таблицам и графам. Каждая глава содержит практические примеры, упражнения и наглядные иллюстрации, которые помогают закрепить материал. Вся теория подкреплена примерами на Python — одном из главных языков современной разработки.
Если вы хотите не просто использовать структуры данных, а понимать их и применять осознанно — эта книга для вас.
Читать: https://habr.com/ru/companies/piter/articles/954670/
#ru
@big_data_analysis | Другие наши каналы
Каждый разработчик знает, насколько важны структуры данных. Без них не обходится ни один серьезный проект, будь то оптимизация запросов, работа с Big Data или просто написание чистого и эффективного кода. Не зря же на собеседованиях постоянно спрашивают про деревья, хеш-таблицы и сложность алгоритмов!
Вы только приступили к изучению структур данных? Хотите освежить знания, полученные в ходе обучения? В этой книге нет заумной математики, скучных доказательств и абстрактной теории. Вместо этого — понятные объяснения, рабочие примеры и реальные кейсы, с которыми ежедневно сталкиваются разработчики. Вы узнаете, как с помощью правильных структур данных ускорить поиск, эффективнее управлять очередями задач или, например, оптимизировать хранение данных.
Книга построена по принципу «от простого к сложному»: начинается с базовых структур, таких как массивы и связанные списки, и постепенно переходит к более сложным — стекам, очередям, деревьям, хеш-таблицам и графам. Каждая глава содержит практические примеры, упражнения и наглядные иллюстрации, которые помогают закрепить материал. Вся теория подкреплена примерами на Python — одном из главных языков современной разработки.
Если вы хотите не просто использовать структуры данных, а понимать их и применять осознанно — эта книга для вас.
Читать: https://habr.com/ru/companies/piter/articles/954670/
#ru
@big_data_analysis | Другие наши каналы
👍4
Актуальные вопросы по ИИ и перспективным технологиям
Эксперты Gartner дают краткие ответы на свежие вопросы клиентов о перспективных технологиях.
Фокус на принятии решений: когда инвестировать в агентный ИИ и DSLM, какие метрики измерять и как масштабировать без потери контроля.
Читать: https://habr.com/ru/articles/954788/
#ru
@big_data_analysis | Другие наши каналы
Эксперты Gartner дают краткие ответы на свежие вопросы клиентов о перспективных технологиях.
Фокус на принятии решений: когда инвестировать в агентный ИИ и DSLM, какие метрики измерять и как масштабировать без потери контроля.
Читать: https://habr.com/ru/articles/954788/
#ru
@big_data_analysis | Другие наши каналы
Собираем собственный ЦОД. 30 петабайт дискового пространства для предобучения моделей
Как потратить почти полмиллиона долларов, чтобы собрать в центре Сан-Франциско хранилище данных объёмом 30 петабайт
Мы собрали в центре Сан-Франциско центр для хранения данных с общим дисковым пространством, где хранятся видеоданные общей длительностью 90 миллионов часов. Зачем? Мы предобучаем модели, чтобы разобраться с использованием компьютеров. Дело в том, что видео гораздо крупнее, чем текстовые данные. Например, на обучение такой текстовой БЯМ как LLaMa-405B требуется ~60 ТБ текстовых данных, а на хранение видео нужно в 500 раз больше текстового пространства. За хранение всей этой информации на серверах AWS пришлось бы выложить 12 миллионов долларов в год, поэтому мы пошли другим путём и арендовали пространство в колокационном центре в Сан-Франциско. Так нам удалось снизить эти расходы примерно в 40 раз (до $354 тысяч в год, считая издержки на устаревание).
Читать: https://habr.com/ru/articles/955002/
#ru
@big_data_analysis | Другие наши каналы
Как потратить почти полмиллиона долларов, чтобы собрать в центре Сан-Франциско хранилище данных объёмом 30 петабайт
Мы собрали в центре Сан-Франциско центр для хранения данных с общим дисковым пространством, где хранятся видеоданные общей длительностью 90 миллионов часов. Зачем? Мы предобучаем модели, чтобы разобраться с использованием компьютеров. Дело в том, что видео гораздо крупнее, чем текстовые данные. Например, на обучение такой текстовой БЯМ как LLaMa-405B требуется ~60 ТБ текстовых данных, а на хранение видео нужно в 500 раз больше текстового пространства. За хранение всей этой информации на серверах AWS пришлось бы выложить 12 миллионов долларов в год, поэтому мы пошли другим путём и арендовали пространство в колокационном центре в Сан-Франциско. Так нам удалось снизить эти расходы примерно в 40 раз (до $354 тысяч в год, считая издержки на устаревание).
Читать: https://habr.com/ru/articles/955002/
#ru
@big_data_analysis | Другие наши каналы
❤1
Данные WhatsApp и Telegram для ML-моделей: тренд или серый рынок?
В этой статье я расскажу про новый тип данных для российского рынка - данные Whatsapp и Telegram: насколько они ценны и насколько легальны.
Читать: https://habr.com/ru/articles/955024/
#ru
@big_data_analysis | Другие наши каналы
В этой статье я расскажу про новый тип данных для российского рынка - данные Whatsapp и Telegram: насколько они ценны и насколько легальны.
Читать: https://habr.com/ru/articles/955024/
#ru
@big_data_analysis | Другие наши каналы
Данные WhatsApp и Telegram для ML-моделей: тренд или серый рынок?
В этой статье я расскажу про новый тип данных для российского рынка - данные Whatsapp и Telegram: насколько они ценны и насколько легальны.
Читать: https://habr.com/ru/articles/955030/
#ru
@big_data_analysis | Другие наши каналы
В этой статье я расскажу про новый тип данных для российского рынка - данные Whatsapp и Telegram: насколько они ценны и насколько легальны.
Читать: https://habr.com/ru/articles/955030/
#ru
@big_data_analysis | Другие наши каналы
Продвинутый анализ на PySpark: учимся работать с рекуррентными соотношениями
Обработка и анализ временных последовательностей (временных рядов) достаточно часто встречающаяся задача. Обычно она решается с помощью идентичных подходов и методов. Однако когда анализ временного ряда предполагает выражение каждого последующего элемента через предыдущие, возникают проблемы с эффективностью реализации такого анализа. Это особенно актуально в контексте больших данных.
В данной статье я продемонстрирую подход к анализу и вычислению рекуррентных соотношений. В качестве примера будет представлена реализация на базе Apache Spark и Python метода экспоненциальной скользящей средней с использованием DataFrame API. Мы рассмотрим метод агрегации данных, совместимый со Spark Connect, который был добавлен в версию 3.1 (для Scala - начиная с версии фреймворка 3.0), а именно – функцию aggregate.
Читать: https://habr.com/ru/companies/axenix/articles/952278/
#ru
@big_data_analysis | Другие наши каналы
Обработка и анализ временных последовательностей (временных рядов) достаточно часто встречающаяся задача. Обычно она решается с помощью идентичных подходов и методов. Однако когда анализ временного ряда предполагает выражение каждого последующего элемента через предыдущие, возникают проблемы с эффективностью реализации такого анализа. Это особенно актуально в контексте больших данных.
В данной статье я продемонстрирую подход к анализу и вычислению рекуррентных соотношений. В качестве примера будет представлена реализация на базе Apache Spark и Python метода экспоненциальной скользящей средней с использованием DataFrame API. Мы рассмотрим метод агрегации данных, совместимый со Spark Connect, который был добавлен в версию 3.1 (для Scala - начиная с версии фреймворка 3.0), а именно – функцию aggregate.
Читать: https://habr.com/ru/companies/axenix/articles/952278/
#ru
@big_data_analysis | Другие наши каналы
👍2
Apache Cloudberry — открытое будущее Greenplum. Сравнение, архитектура, перспективы
Если вы работаете с аналитическими базами данных, то наверняка слышали о Greenplum — одном из самых мощных MPP-решений (Massively Parallel Processing) на базе PostgreSQL.
Однако в последние годы в экосистеме PostgreSQL появилось новое имя — Apache Cloudberry.
На первый взгляд, это ещё один форк Greenplum.
Но на деле Cloudberry — переосмысление архитектуры MPP-СУБД, выполненное с уважением к наследию Greenplum, но с современным кодом, ядром PostgreSQL 14+, открытым управлением через Apache Foundation и амбициозной целью стать по-настоящему открытой аналитической платформой уровня DWH.
Читать: https://habr.com/ru/articles/955244/
#ru
@big_data_analysis | Другие наши каналы
Если вы работаете с аналитическими базами данных, то наверняка слышали о Greenplum — одном из самых мощных MPP-решений (Massively Parallel Processing) на базе PostgreSQL.
Однако в последние годы в экосистеме PostgreSQL появилось новое имя — Apache Cloudberry.
На первый взгляд, это ещё один форк Greenplum.
Но на деле Cloudberry — переосмысление архитектуры MPP-СУБД, выполненное с уважением к наследию Greenplum, но с современным кодом, ядром PostgreSQL 14+, открытым управлением через Apache Foundation и амбициозной целью стать по-настоящему открытой аналитической платформой уровня DWH.
Читать: https://habr.com/ru/articles/955244/
#ru
@big_data_analysis | Другие наши каналы
Сбер заменил ИИ до 25% разработчиков — от джунов до лидов
Сбер заменил ИИ до 25% IT-команды: тысячи разработчиков и тестировщиков уволены под видом «оптимизации», банк говорит об автоматизации
Читать: «Сбер заменил ИИ до 25% разработчиков — от джунов до лидов»
#ru
@big_data_analysis | Другие наши каналы
Сбер заменил ИИ до 25% IT-команды: тысячи разработчиков и тестировщиков уволены под видом «оптимизации», банк говорит об автоматизации
Читать: «Сбер заменил ИИ до 25% разработчиков — от джунов до лидов»
#ru
@big_data_analysis | Другие наши каналы
😁2
BI в закрытом контуре: технические вызовы развертывания и эксплуатации
Бизнес-аналитику чаще внедряют в облаке или гибридной инфраструктуре. Но что делать, если по требованиям безопасности выход интернет недоступен, а BI‑система должна работать только внутри корпоративной сети?
Эта статья будет полезна архитекторам, DevOps‑инженерам и администраторам, которым нужно развернуть BI‑платформу в изолированной среде. На примере Modus BI мы разберём ключевые технические трудности и покажем решения, проверенные в реальных проектах.
Читать: https://habr.com/ru/companies/modusbi/articles/954862/
#ru
@big_data_analysis | Другие наши каналы
Бизнес-аналитику чаще внедряют в облаке или гибридной инфраструктуре. Но что делать, если по требованиям безопасности выход интернет недоступен, а BI‑система должна работать только внутри корпоративной сети?
Эта статья будет полезна архитекторам, DevOps‑инженерам и администраторам, которым нужно развернуть BI‑платформу в изолированной среде. На примере Modus BI мы разберём ключевые технические трудности и покажем решения, проверенные в реальных проектах.
Читать: https://habr.com/ru/companies/modusbi/articles/954862/
#ru
@big_data_analysis | Другие наши каналы
Arc: Убийца ClickHouse на стероидах из DuckDB и Parquet? Разбираем новый движок для time-series
Привет, Хабр! Если последние годы вас не отпускала фантомная боль от вечного выбора между ураганной скоростью ClickHouse, невозмутимой простотой SQLite и порой адской сложностью настройки InfluxDB, — возможно, вы, как и мы, дождались чего-то по-настоящему нового.
На горизонте появился проект Arc от команды Basekick Labs. Это не просто очередная попытка, а дерзкая заявка на соединение всего лучшего из мира time-series и lakehouse-подхода. Забудьте о тяжёлых серверах и мучительной шардированной архитектуре. Arc предлагает:
Читать: https://habr.com/ru/articles/955536/
#ru
@big_data_analysis | Другие наши каналы
Привет, Хабр! Если последние годы вас не отпускала фантомная боль от вечного выбора между ураганной скоростью ClickHouse, невозмутимой простотой SQLite и порой адской сложностью настройки InfluxDB, — возможно, вы, как и мы, дождались чего-то по-настоящему нового.
На горизонте появился проект Arc от команды Basekick Labs. Это не просто очередная попытка, а дерзкая заявка на соединение всего лучшего из мира time-series и lakehouse-подхода. Забудьте о тяжёлых серверах и мучительной шардированной архитектуре. Arc предлагает:
Читать: https://habr.com/ru/articles/955536/
#ru
@big_data_analysis | Другие наши каналы
👍2
GigAPI — это лёгкий «тайм-серии-лейкхаус» на базе DuckDB + Parquet с FDAP-стеком
Если вы когда-нибудь собирали аналитику по кликам, метрикам или логам, то знаете цену вопроса: хочется SQL за миллисекунды, хранение в дёшёвом объектном хранилище, минимум «танцев» с кластером и—если повезёт—MIT-лицензию без ловушек. На одном берегу — «тяжёлые» распределённые OLAP-системы (ClickHouse, Pinot, Druid), на другом — специализированные TSDB (InfluxDB, TimescaleDB, QuestDB). Между ними набирает силу «озёрный» подход: складывать сырые события в Parquet, а считать — встраиваемым движком с Arrow/FlightSQL поверх.
GigAPI как раз из этой когорты: DuckDB + Parquet, чтение из локального диска или S3, запросы через FlightSQL (gRPC) и HTTP, режимы
Читать: https://habr.com/ru/articles/955560/
#ru
@big_data_analysis | Другие наши каналы
Если вы когда-нибудь собирали аналитику по кликам, метрикам или логам, то знаете цену вопроса: хочется SQL за миллисекунды, хранение в дёшёвом объектном хранилище, минимум «танцев» с кластером и—если повезёт—MIT-лицензию без ловушек. На одном берегу — «тяжёлые» распределённые OLAP-системы (ClickHouse, Pinot, Druid), на другом — специализированные TSDB (InfluxDB, TimescaleDB, QuestDB). Между ними набирает силу «озёрный» подход: складывать сырые события в Parquet, а считать — встраиваемым движком с Arrow/FlightSQL поверх.
GigAPI как раз из этой когорты: DuckDB + Parquet, чтение из локального диска или S3, запросы через FlightSQL (gRPC) и HTTP, режимы
writeonly/readonly/compaction, один контейнер для старта и понятная философия «делай просто, делай быстро». Проект обещает суб-секундные аналитические запросы, компактизацию и дружбу с FDAP-миром (Arrow/DataFusion/Parquet/Flight) — всё то, что нравится инженерам, уставшим от «зоопарков» сервисов.Читать: https://habr.com/ru/articles/955560/
#ru
@big_data_analysis | Другие наши каналы
Зачем бизнесу GPT-платформа, а не просто LLM: опыт JET & Yandex GPT Lab
Меня зовут Антон Чикин, я руковожу отделом интеллектуального анализа в «Инфосистемы Джет». В статье я попробую показать на практическом примере, почему корпоративный ИИ нельзя свести к установке готовой LLM — и что именно приходится выстраивать вокруг неё, чтобы получить реальную ценность для бизнеса.
Этот материал будет полезен тем, кто отвечает за внедрение ИИ в компаниях среднего и крупного масштаба: ИТ-директорам, архитекторам корпоративных систем, специалистам по информационной безопасности и тем, кто рассматривает генеративный ИИ как инструмент автоматизации бизнес-процессов.
Читать: https://habr.com/ru/companies/jetinfosystems/articles/956042/
#ru
@big_data_analysis | Другие наши каналы
Меня зовут Антон Чикин, я руковожу отделом интеллектуального анализа в «Инфосистемы Джет». В статье я попробую показать на практическом примере, почему корпоративный ИИ нельзя свести к установке готовой LLM — и что именно приходится выстраивать вокруг неё, чтобы получить реальную ценность для бизнеса.
Этот материал будет полезен тем, кто отвечает за внедрение ИИ в компаниях среднего и крупного масштаба: ИТ-директорам, архитекторам корпоративных систем, специалистам по информационной безопасности и тем, кто рассматривает генеративный ИИ как инструмент автоматизации бизнес-процессов.
Читать: https://habr.com/ru/companies/jetinfosystems/articles/956042/
#ru
@big_data_analysis | Другие наши каналы
Пожиратель токенов (или нет): анатомия протокола MCP для ИИ-агентов
Поводом написания этой статьи послужил подслушанный диалог:
А на чем у вас агенты написаны?
У нас на MCP!
Для меня MCP всегда был просто протоколом, то есть именно способом отправки и обработки запросов. А когда я слушал выступления или читал некоторые статьи о том, как плох/хорош MCP, меня не покидало ощущение чего-то странного. Но все же решил, что это от незнания, и я чего-то не понимаю. А когда не понимаешь, но очень хочешь понимать, то самый лучший способ — это взять и разобраться.
Именно это предлагаю и сделать в статье, а также замерить MCP, чтобы ответить на вечный вопрос: сколько сжирает MCP, подключать ли его вообще или и так сойдет?
Читать: https://habr.com/ru/articles/956150/
#ru
@big_data_analysis | Другие наши каналы
Поводом написания этой статьи послужил подслушанный диалог:
А на чем у вас агенты написаны?
У нас на MCP!
Для меня MCP всегда был просто протоколом, то есть именно способом отправки и обработки запросов. А когда я слушал выступления или читал некоторые статьи о том, как плох/хорош MCP, меня не покидало ощущение чего-то странного. Но все же решил, что это от незнания, и я чего-то не понимаю. А когда не понимаешь, но очень хочешь понимать, то самый лучший способ — это взять и разобраться.
Именно это предлагаю и сделать в статье, а также замерить MCP, чтобы ответить на вечный вопрос: сколько сжирает MCP, подключать ли его вообще или и так сойдет?
Читать: https://habr.com/ru/articles/956150/
#ru
@big_data_analysis | Другие наши каналы
Обзоры препринтов научных статей в области астрофизики за сентябрь 2025 года
Выпуск 448
Пределы космологии (The limits of cosmology)Authors: Joseph SilkComments: 23 pages, Gen Relativ Gravit 57, 127 (2025)
Если вы думаете, что известный космолог-теоретик пишет про теорию, то вы ошибаетесь! Силк внезапно втопил за лунные проекты. И это не только низкочастотные радионаблюдения на другой стороне Луны, но и совершенно фантастические (очень дорого и сложно) проекты гравитационно-волновых детекторов (типа LIGO, Virgo) на Луне (там низкий сейсмический шум, и можно уйти на низкие частоты).
Радиопроекты могут быть реализованы в середине этого века. Гравволновые - точно нет. Но интересно, что Силк погружает все это в интересный и понятно описанный контекст космологических задач (отсюда и название статьи). Так что читать все равно интересно. Вот это и впрямь научная фантастика!
А еще… затронем ИИ и прочие захватывающие темы
Обещаю, будет интересно…
Читать: https://habr.com/ru/articles/956210/
#ru
@big_data_analysis | Другие наши каналы
Выпуск 448
Пределы космологии (The limits of cosmology)Authors: Joseph SilkComments: 23 pages, Gen Relativ Gravit 57, 127 (2025)
Если вы думаете, что известный космолог-теоретик пишет про теорию, то вы ошибаетесь! Силк внезапно втопил за лунные проекты. И это не только низкочастотные радионаблюдения на другой стороне Луны, но и совершенно фантастические (очень дорого и сложно) проекты гравитационно-волновых детекторов (типа LIGO, Virgo) на Луне (там низкий сейсмический шум, и можно уйти на низкие частоты).
Радиопроекты могут быть реализованы в середине этого века. Гравволновые - точно нет. Но интересно, что Силк погружает все это в интересный и понятно описанный контекст космологических задач (отсюда и название статьи). Так что читать все равно интересно. Вот это и впрямь научная фантастика!
А еще… затронем ИИ и прочие захватывающие темы
Обещаю, будет интересно…
Читать: https://habr.com/ru/articles/956210/
#ru
@big_data_analysis | Другие наши каналы
🆒2
При всплесках нагрузки: StarRocks Query Cache обеспечивает кратное ускорение
При пиковых нагрузках отчётные и аналитические системы сталкиваются с лавиной схожих агрегирующих запросов: растёт загрузка CPU и увеличиваются задержки. В StarRocks эту проблему решает Query Cache — кэширование промежуточных результатов агрегаций в памяти с их последующим переиспользованием. В реальных сценариях даёт 3–17× ускорение, работает для семантически эквивалентных запросов, перекрывающихся партиций и append-only данных. Внутри — лучшие практики, пример настройки и метрики диагностики.
Читать: https://habr.com/ru/articles/956308/
#ru
@big_data_analysis | Другие наши каналы
При пиковых нагрузках отчётные и аналитические системы сталкиваются с лавиной схожих агрегирующих запросов: растёт загрузка CPU и увеличиваются задержки. В StarRocks эту проблему решает Query Cache — кэширование промежуточных результатов агрегаций в памяти с их последующим переиспользованием. В реальных сценариях даёт 3–17× ускорение, работает для семантически эквивалентных запросов, перекрывающихся партиций и append-only данных. Внутри — лучшие практики, пример настройки и метрики диагностики.
Читать: https://habr.com/ru/articles/956308/
#ru
@big_data_analysis | Другие наши каналы
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 | Другие наши каналы